Draft Submission

8/3/2019 Draft Submission

1/49

Data Transfer Service A Migration tool to replacecurrent X400 messaging between NHS workflow

applications

Submitter: Richard Corbridge

Sponsorship: Gwyn Thomas

1. Introduction

1.1 This paper proposes a technical solution to support a secure transport

infrastructure to transfer data between NHS organisations and NHSorganisations and local authorities. The strategy specified in this submission

is considered to achieve the encryption provision needed to comply with the

stated security requirements for application to application workflow

messaging that carry clinical and patient identifiable information. The

technical solution proposed will enable workflow applications currently

utilising the X.400 Managed Message Handling Service to migrate onto an e-

GIF compliance secure data transfer infrastructure (i.e. HTTPSsecure

Hypertext Transfer Protocol).

1.2 This paper is supported by the following documentation:

Extract from e-GIF (electronic Government Interoperability Framework)

document, version 4 part 2, Technical Policies and Specifications 25th

April 2002, section 6.1. table 1see Appendix 1

Delivering 21st

Century IT Support for the NHS - National Strategic

Programme(June 2002)see Appendix 2

Statement of Approval for Technical Security Aspects of Data Transfer

Service from NHS Information Authority Security Board (January 2003

Board Meeting)see Appendix 3

Statement of Approval from the Design Authority with reference to the

strategic fit of the Data Transfer Service when considered in relation to the

required programme of works for the National Programme for Information

TechnologySee Appendix 6.

Data Transfer Service Functional Specification (version 1.2)SeeAppendix 4

Data Transfer File Interface Specification (version 1.2)See Appendix 5

The strategy specified in this submission to the Information Standards Board (ISB)

requires approval as an NHS Draft Standard to support the achievement of migration

from X.400 to eSMTP. Any uses of the DTS beyond this scope will be submitted to

ISB for further approval. The lifespan of the DTS (as specified in this submission),

and therefore the life of this Draft Standard will determined by the contractual periodof the NHS Managed Message Handling Service.


2/49

1.3 The first workflow application community scheduled to use this standard formigrating off the X.400 messaging infrastructure are the NHAIS (Exeter)

systems. The subsequent communities of NHS workflows to use this

migration standard are NHS-Wide Clearing Service (NWCS), Central

Registration and General Practice systems.

1.4 The technological concept of the DTS has already been implemented withgreat success in the NHS Numbers for Babies (NN4B) project.

2 Compliance with Requirements for Strategic InformationStandards

2.1 The technologies that support the secure data transfer in the solution specifiedin this submission comply with the transport security standards covered within

the e-GIF (electronic Government Interoperability Framework) document,

version 4 part 2, Technical Policies and Specifications 25th April 2002,

section 6.1.

2.2 The architecture of the strategy specified in this submission is considered tomeet an agreed set of purposes, these are:

Compliance with the requirements of Domain to Domain Encryptionfor clinical workflows, as defined in Delivering 21st Century IT

Support for the NHS

To afford the appropriate levels of security to sensitive and personal

health information to comply with the requirements of the DataProtection Act 1998.

Common law duty of confidence.

Transfer of sensitive and personal health information between NHS

organisations and NHS organisations and local authorities as defined in

the Health Act 1999 section 31.

3 Strategy Overview

3.1 The NHS has historically utilised the X.400 messaging standard to supportdata transfers between EDI (electronic data interchange) systems and clinical /business workflow applications. In order to comply with e-GIF and

International Internet standards, the NHS made a strategic decision to migrate

workflow applications off the X.400 messaging standard.

3.2 The DTS (Data Transfer Service) is a technological solution that has beenspecifically developed for the NHS to enable workflows to migrate off the

X.400 messaging standard. The principle objectives for the DTS development

were to support: -

A standardised, e-GIF compliant, infrastructure for NHS workflowapplications to exchange information


3/49

Separation of NHS workflow application handshaking /acknowledgement function from underlying messaging protocol layers

Simplify implementation of 128 bit encrypted connection between

NHS workflow applications

Improved management information for data transfers between NHS

workflow applications (web-based message tracking)

3.3 The DTS has the following key components:

DTS Server

DTS Client

Client File Interface

Security

Administration and Data Transfer Tracking

3.3.1 Service Summary

The following diagram shows the key components of the DTS.

Abbreviation of DTS components

eSMTP enhanced Simple Mail Transfer Protocol is the e-GIF specified

standard for mail transfer

HTTP Hypertext Transfer Protocol

MTA Message Transfer Agenttransfer messages between

computers

MSS Managed Server Servicea service provided within the core

NHS Messaging Service designed for organisations who do not

wish to own or operate their own MTA.

SSL Secure Sockets Layer is the e-GIF specified standard for

transport security.

3.3.2 DTS Server

The Data Transfer Server performs two primary functions. First, it supports

the transfer of data to and from the Data Transfer Clients that reside on the

clinical / business applications. Secondly, it supports communications to and

from the eSMTP component of the NHS Messaging Service.

3.3.3 DTS Client

The Data Transfer Client supports the transfer of data to and from the clinical /

business applications in a secure manner using the Data Transfer Server.

HTTP / SSL 128 bit

Encrypted

HTTP / SSL 128 bit

Encrypted

Data Transfer

Server

Central MTA

(MSS)

Application

DTS Client

Application

DTS Client

eSMTP

Application


4/49

When transferring data from the end-site application, the Client will transfer

data that has been downloaded by the application over an encrypted link.

The local configuration of the DTS Client is defined in a Client configuration

file. All activities undertaken by the DTS Client is recorded to a local Log

File.

3.3.4 Client File Interface

A file-based interface has been developed to pass a data file and an associated

control file from the Host Application to the DTS Client.

3.3.4.1Client File Interface - Folder Structure

DTS Rootdefined in client configuration file

INused by the DTS Client to deposit data and status information tobe received by Host Application

OUTused by the Host Application to copy data to be sent by the

DTS Client

SENTused by the DTS Client to copy sent data for use by the HostApplication

TEMP - used by the DTS Client for any intermediate files during its

processing

3.3.4.2Client File Interface Transactions

For each transaction or data transfer the following activities occur: -

Each individual data transfer consists of a data file and a control file

A status report is generated for each transaction, that can be viewed

via a web-based message tracking system

3.3.4.3Client File Interface Control File Elements

The Control File has been developed using XML (extensible Mark-up

Language) which supports the e-GIF compliance objectives of the DTS

development.

AddressType MessageType

From To

Subject Local ID

DTSID PartnerID

Compress Encrypted

WorkflowID ProcessID

DataChecksum IsCompressed

StatusRecord

3.3.5 Client with the Data Transfer Server Interface


5/49

The client transfers data, sent by the application, to the Data Transfer Server

for onward transmission. The client periodically polls the Data Transfer

Server, to check if there are any messages to be retrieved. If there are, it will

then transfer them.

3.3.6 Security

When a data transfer is initiated the following activities occur:

Confidentiality:

The client will transfer the data to the server via an SSL 128 bitencryption between DTS Client and DTS Server over NHSnet.

Authentication:

The DTS Client will authenticate to the DTS Server using a UserID

and password

The DTS Server will undertake an NHSnet DNS (domain name

system) lookup of the Internet Protocol address of the Host Application

machine.

3.3.7 Web-based Administration and Data Transfer Tracking

3.3.7.1Administration

For each DTS Client, password protected user accounts users can beconfigured that will allow defined levels of access to view the web-based

administration and data transfer tracking system.

3.3.7.2Data Transfer Tracking System - Search / Filter Functionality

The following criteria can be used by authorised users to search for

information about previous data transfers:

Date and time period

To Address

Local IdentifierDTS Client Identifier

Partner Identifier

3.3.7.3Data Transfer Tracking System - Reports

The following criteria can be used by authorised users to produce reports

about previous data transfers:

To Address

From Address

Subject


6/49

Local Identifier

DTS Client Identifier

Partner Identifier

Workflow ID

Process ID

Tracking Record for the Transfer

o Date and Time of evento Event description


7/49

Appendix 1 e-GIF specification for cryptographic algorithms

The following specifications are to be used to meet the requirements of the IAG

Security Framework where appropriate.

IP security IP-SEC (RFC2402/2404)

IP encapsulation security ESP (RFC2406)

Transport security SSL v3/TLS (RFC 2246)

Certain e-government information is sensitive in that it might contain personal or

commercially confidential information, but it does not fall within the definitions of

government classified information. For the protection of such information, e.g. data

and private keys, the following specifications are advised:

Encryption algorithms - 3DES, AES, Blowfish

For signing - RSA, DSA

For key transport - RSA, DSA

For hashing - SHA-1, MD5

The above is not exhaustive and is intended as a guide.


8/49

Appendix 2 Delivering 21st Century IT Support for the NHS -National Strategic Programme (Section 3)

3 STRATEGY

3.1 Strategic decisions required to deliver the Vision3.1.1 There are a number of critical strategic elements that must be in place to

deliver the IT vision for the NHS. These are:

an increase in the level of national direction given for IT by evolving

and simplifying the management structure and responsibilities

within both the DH and NHS at regional and local levels;

a phased approach to deliver change quickly focus at any one

time on quickly delivering a limited portfolio of activity, nationally,

that can be built on by subsequent phases;

management of increased levels of funding with clear central

direction and control;

a structured partnering approach with Industry to deliver new IT

systems across the NHS;

coordination, acceleration and where appropriate simplification of

procurements to ensure we get value for money while moving at a

fast pace, and do not add unnecessary time and cost to our industry

supplier base. We will consider radical outsourcing options that add

pace and value to the programme;

changed working practices in the NHS; benchmark progress against best practice companies.

3.2 Create National Direction for IT3.2.1 The full details of the Management Structure are given in Appendix 1. In

summary there will be:

a ministerial taskforce chaired by Lord Hunt

a single DH Director (Sir John Pattison) who will be responsible for

the programme and report to Lord Hunt and the Chief

Executive/Permanent Secretary, Nigel Crisp

a newly appointed National IT Programme Director working to Sir

John empowered to deal directly with the Strategic Health

Authorities and manage those funds held centrally for this

programme. The National Director will work with the Information

Policy Unit and NHS Information Authority. a Chief Information Officer appointed by each Strategic Health

Authority to ensure there is appropriate funding and effective IT

management for every PCT and NHS Trust to implement and use

the core IT solutions determined at national level

capacity in PCT and NHS Trusts to implement the local elements of

the national programme

a workstream to develop the capability in the NHS to underpin the

above.

3.3 Phases of delivery

3.3.1 Set out below are the phases of the programme delivery that allow theimpact of improved IT to be made early, with sustained, incremental


9/49

increases in functionality. A preparatory Phase 0 is needed from April

2002March 2003. Phase 1 will concentrate on some key tools and

pieces of infrastructure. Successive phases will then add to the portfolio,

with increasing sophistication of function built onto proven infrastructure

and data quality.

Phase 0April 2002March 2003 - Firm Scope

Infrastructure

Define data standards

Define interchange standards

100% Consultants with PCs

Application services

Create first stage of National Health Record Service

Agree XML based EPR System Specification, using open standards

Implementation and Support

Work with OGC and e-Envoy to streamline procurement

Begin increase of NHS IT capacity and capability

Phase 1April 2003 to December 2005 Firm scope

Infrastructure

Broadband access (>128kbs) to every clinician & support staff in

the NHS, increased bandwidth to minimum - 2Mbps between

trusts and across NHS Net Gateways

Access and authentication available for all NHS staff,

implementation of National NHS Directory Service

Domain to domain encryption implemented

Application Services

National Bookings Service, implemented

National Prescriptions service, 50% implemented

All PCTs, NHS Trusts actively implementing elements of EPRs

Full National Health Record Service implemented, and accessible

nationally for out of hours reference

National Patient Record Analysis Service established for 100% of

NHS transactions;

Provision of e-learning materials through the NHS U

Quality Management

Establishment of a Faculty of Health Informatics in the NHS U.

Implementation of Gateway procedures for Information and ITprojects

Implementation and Support

National IT services portfolio established

StHA investment plans accepted (and funding agreed) by National

Programme Director


10/49

Appendix 3 Statement of Approval for Technical SecurityAspects of Data Transfer Service from NHS Information AuthoritySecurity Board (January 2003 Board Meeting)

-----Original Message-----From: Doyle JohnSent: 22 January 2003 14:33To: Corbridge Richard; Welsh BelSubject: NHSnet Security Board - DTS

Richard,Security Board considered the DTS Security Policy and the encryption standardtoday....Minute below

BT Syntegra - Data Transfer Service

The NHSnet Security Board reviewed the DTS Security Policy and considered the complianceof the encryption provision against the stated clinical security requirements for Domain toDomain encryption.

The Board accept the Security Policy for the Service as meeting requirements and requestthat updates or amendments be copied to the Board Secretary.

Encryption provision within the service is 128bit SSL encryption at the transport layer whichensures the security of clinical and other edi messages from the originating domain through tothe DTS centre where the message is transferred within a secure environment to theoutbound transfer, which is also secured by 128bit SSL encryption of the transport layer, to

the recipient domain. The NHSnet Security Board accept this method as meeting therequirement for Domain to Domain encryption. Although in this instance a more precisedescription would be "Inter - Domain Encryption", the level of security imposed does morethan equate to that specified.

Bel,Draft as promised

JDJohn C DoyleNHSnet Snr. Security Manager07966 435194http://nww.nhsia.nhs.uk/securitywww.nhsia.nhs.uk/nhsnet
http://nww.nhsia.nhs.uk/securityhttp://nww.nhsia.nhs.uk/securityhttp://www.nhsia.nhs.uk/nhsnethttp://www.nhsia.nhs.uk/nhsnethttp://www.nhsia.nhs.uk/nhsnethttp://nww.nhsia.nhs.uk/security


11/49

Appendix 4 Data Transfer Service Functional Specification(version 1.2)

CONTENTSDATA TRANSFER SERVICE A MIGRATION TOOL TO REPLACE CURRENTX400 MESSAGING BETWEEN NHS WORKFLOW APPLICATIONS 1

Submitter: Richard Corbridge Sponsorship: Gwyn Thomas 11. Introduction 2 Compliance with Requirements for Strategic Information Standards 23 Strategy Overview 2

Appendix 1e-GIF specification for cryptographic algorithms 7Appendix 2Delivering 21stCentury IT Support for the NHS - National Strategic Programme

(Section 3) 8Appendix 3Statement of Approval for Technical Security Aspects of Data Transfer Service from

NHS Information Authority Security Board (January 2003 Board Meeting) 10Appendix 4Data Transfer Service Functional Specification (version 1.2) 11

INTRODUCTION 13Background 13Service Summary 13

DTS CLIENT 14Client Site Configuration 14DTS Client Send 16DTS Client Receive 19DTS Client Log 21Process Control 21

DTS SERVER 23DTS Server Send 23DTS Server Receive 25

DTS ADMINISTRATION 27

Register with DTS - Migration from X.400 27Register with DTS - New Site 27DTS Access Administration 28Unregister from DTS 28Data Transfer Tracking 29


12/49

REFERENCES 30GLOSSARY 30CONFIGURATION CONTROL 31

Change details 31DTS CLIENT PARAMETER FILE EXAMPLE 32

Appendix 5Data Transfer Service File Interface Specification (version 1.2) 33INTRODUCTION 34

Background 34 DTS Client Overview 3

DTS CLIENT FILE INTERFACE 35Directory/File Structure 35File Interface 35

Transaction Sequence Identifier 36Control File 36File Interface Maintenance 38

DATA TRANSFER 39OUT Transactions 39

IN Data Transactions 4 IN Status Transactions 4


Change details 45APPENDIX A - DTS CONTROL FILE XML FORMAT EXAMPLE 46

Appendix 6Statement of Approval from the Design Authority with reference to the strategic fit

of the Data Transfer Service when considered in relation to the required programme of works for

the National Programme for Information Technology 47


13/49

INTRODUCTION

Background

The NHS Messaging Service currently supports two messaging standards, the X.400

standard, on which the original NHS Messaging Service was based, and extended

SMTP (eSMTP), which is the standard chosen for all future messaging. There is

therefore a requirement to migrate all messaging across to the new eSMTP standard.

The NHS Information Authority, in conjunction with Syntegra, already has a

programme of work in place to migrate interpersonal e-mail users and their systems.

The EDI Gateway Service will provide translation serviced between the X.400 and

SMTP domains for EDI messages.

In order to facilitate the migration of individual EDI applications the Data Transfer

Service (DTS) was proposed as an alternative to the use of on site Message TransferAgents (MTA).

Service Summary

The DTS service has three key components;

1. DTS Client

2. DTS Server

3. Enhancements to the NHS Registration System

This Functional Specification details the facilities to be provided by the Data Transfer

Service.The DTS components are shown shaded within the in the following message service

schematic diagram.

TRADING

PARTNER

eSMTP

X.400

TRADING

PARTNER

EDIG

MTA

DTS SERVER

TRADING

PARTNER

DTS CLIENT

NHS

REGISTRATION

SERVICE

MTA


14/49

DTS Client

The following Sections describe the functions to be provided by the DTS Client

application.1. Site Specific Client Configuration

2. Sending Data

3. Receiving Data

4. Logging

5. Process Control

Client Site Configuration

The DTS Client will run as a separate application on the system platform supportingthe EDI Application at a site.

There is site-specific information that needs to be set up to identify and authorise the

Client to the DTS Service. These data items are mandatory.

In addition there are optional Site specific configuration options which may be set up

to control the reporting of status information. These parameters are optional.

The following table details the DTS Client configuration parameters.

DATA ITEM VALUES MANDATOR

Y/

OPTIONAL

DESCRIPTION

ClientIdentity M Site specific identity for the DTS

Client. Equivalent to username.

This will be generated during the

registration of the Client.

ClientAuthenticat

ion

M Site specific authentication token

for the DTS Client. Equivalent to

password.

This will be generated during the

registration of the Client and can be

managed via the NHS registration

Service Web Interface.

InterfaceRoot M The file system path to the root ofthe DTS Client File Interface. (As

defined in the DTS Client File

Interface Specification, [Reference

2].

LogPath M The file system path to the folder

for the DTS Local Log Files.

CertPath M Path to the DTS Service CA

Certificate. Used to authenticate the

DTS Server to the DTS Client

PrimaryURL M Primary DTS server URL used to

connect to the DTS ServerSecondaryURL O Secondary DTS server URL.


15/49

For possible future use.

CollectReport Y

N

O Parameter controlling the

generation of reports by the DTS

Client, indicating that it has taken

responsibility for the Data Transfer

files.

Default - N

DelayReport Y

N


generation of reports from the DTS

Client indicating that the transfer is

delayed if it fails to transfer the

Data Files to the DTS Server but

the Client is configured to retry.

Default - N

TransferReport Y

N

O Parameter controlling thegeneration of reports indicating that

the transfer of the Data Files to the

DTS Server has succeeded.

Default - N

PollReport Y

N


generation of reports indicating that

the poll to the DTS Server to check

for received transfers has succeeded

or failed.

Default - NSaveSent Y

N

O Parameter controlling the copying

of sent Data Transfer files into the

SENT folder on successful Transfer

to the DTS Server.

Default - N

FilePoll 1 to 600 O File Polling Period parameter

controlling the polling period that

the DTS Client will use between

checks for Data Files from the EDI

Application.Valueseconds

Default - 60

ServerPoll 10 to 60 O Server Polling Period parameter

controlling the polling period that

the DTS Client will use between

checks for Data Files from the DTS

Server.

Valueminutes

Default -15


16/49

ServerRetry 0 to 10 O Server Retries parameter

controlling the number of retries

that the DTS Client should perform,

before aborting, if the transfer of

Data Files to the DTS Server Fails.

Default - 3

The DTS Client configuration information will be specified in the DTS Client

Parameter file. The file system Path to the Parameter file will be specified as a

parameter on DTS Client application startup.

Each parameter will be on a separate line.

The configuration parameters will be in XML format as defined in section DTS

Client Parameter File Example.

In the future it may be desirable to provide an application to maintain the DTS Client

parameter file, however the initial specification will be a text file produced using astandard text editor.

The following function points detail the DTS Client initial configuration functions.

DTSCINI.01 The DTS Client will read the Client Parameter file on start-up and

use the parameters contained to configure the client handling of Data

Transfers.

If the Client Configuration file does not exist then the DTS

Client will write an error report to the DTS Client Log file and

close down.

DTSCINI.02 If the Client Parameter file does not specify the mandatoryconfiguration items then the DTS Client will write an error report to

the DTS Client Log file and close down.

DTSCINI.03 If the Client Parameter file does not specify the optional

configuration items then the DTS Client will use the default values

for those parameters.

DTSCINI.04 If the DTS Client cannot interpret a configuration parameter then it

will ignore it and continue processing the Client Parameter File. The

DTS Client will write an error report specifying the error parameter

text.

DTS Client Send

The Data Transfer Service will provide the facilities for a registered and configured

EDI Application to transfer EDI Data to external Trading Partners;1. Connected to the DTS

2. Via the eSMTP Service

3. Via the eSMTP Service and EDI Gateway to the X.400 Service

The interface between the EDI Application and the DTS client will be a simple

operating system file structure, the interface is defined in detail in the document DTSFile Interface Specification, [Reference 2].


17/49

To initiate the transfer of EDI data via the DTS the sending application will copy two

files into the OUT folder. Two files will be used in the transaction;

1. Data filethe EDI data to be transferred.

2. Control filecontaining the information required to send the EDI data file to itsrecipient.

The DTS Client will process the EDI Data Transfer in different ways, depending on

the information based on the following information;

1. Per transfer, specified in the Control File.

The Client will only perform one optional operation on the Data Transfer based oninformation in the Control File. If the compress control indicates that the data

can be compressed and the encrypted control is set to no, then the Client will

compress the Data file before sending to the DTS Server.

2. All transfers, based on details in the DTS Client Configuration file.

If the Collect Report parameter is set then the DTS Client will generate a report

indicating that it has taken responsibility for the Data Files as soon as it detects

them.

If the Delay Report parameter is set then the DTS Client will generate a report

indicating that the transfer is delayed if it fails to transfer the Data Files to the

DTS Server but is configured to retry before aborting the transfer.

If the Transfer Report parameter is set then the DTS Client will generate a

report indicating that the transfer of the Data Files to the DTS Server has

succeeded.

If the Copy Send parameter is set then the DTS Client will copy the Data

Transfer files into the SENT folder on their successful transfer to the DTS Server.

The following function points detail the DTS Client send functions.

DTCSEN-01 The DTS Client will check the OUT folder periodically for data to

be transferred.

If no Data Files are detected then the DTS Clint will wait for the

next poll event.

If Data Files are detected then the DTS Client will process them.

If multiple Data Files are detected then the DTS Client will sendthem in sequence.

DTCSEN-02 The polling period for checking for outgoing data will be

configurable via a parameter in the DTS Client configuration file as

described in the section Client Site Configuration.

DTCSEN-03 When the DTS Client detects data to be transferred it will initiate the

transfer process by moving the files from the OUT folder to the

TEMP folder. The DTS Client will validate the Data File and

associated Control File.

If the Collect Report handling is configured then DTS Clientwill generate a Report Control file with a Status Record


18/49

indicating that it has taken responsibility for the Data Files. The

report will be placed in the IN folder.

If the DTS Client identifies a problem with the Data TransferFiles it will generate a Report Control file with a Status Record

indicating the error status. The report will be placed in the IN

folder.

An entry will be made in the local log file with the success orerror status as described in function point DTCSEN-10.

DTCSEN-04 If the Control File indicates that the EDI data file can be compressed

then the DTS Client will compress the Data File before sending it.

If the Compress parameter in the Control File is set to Y andthe Encrypted parameter is set to N then the DTS Client will

compress the file.

If the Compress parameter is absent or set to N then the file

will not be compressed.

If the Encrypted parameter is absent or set to Y then the file

will not be compressed.

If the compress action fails then the Data file will be sent as is.

An entry will be made in the local log file with the success or

error status as described in function point DTCSEN-10.

DTCSEN-05 If the initial processing of the Data Files is successful then the DTS

will establish a SLL encrypted connection to the DTS Server and

authenticate the DTS Server via the Server Certificate.

The DTS Server Certificate will be authenticated by reference to

the Certificate Authority Certificate supplied with the DTS

Client.

If the DTS Server is not authenticated then the DTS Client will

abort the transfer and return a Report Control file with a Status

Record indicating the error status in the IN folder.



DTCSEN-06 The DTS Client will authenticate itself to the DTS Server by

supplying a userid and password.The userid and password will be configured on the DTS Servervia the registration facility defined in the document EDI

Gateway Functional Specification, [Reference 3].

The userid and password will be configured on the DTS Clientvia parameters in the DTS Client configuration file as described

in section 2.1.

If the DTS Client is not authenticated then the DTS Server will

abort the transfer. The DTS Client will generate a Report Control

file indicating the error in the IN folder.



19/49


DTCSEN-07 If the DTS Server and Client authentication is successful then the

DTS Client will transfer the Data and Control files to the DTS

Server.

If the DTS Client parameter file specifies Copy Sent, then on

successful completion of the transfer the DTS Client will;

Update the Control file with the success status and transferdetails.

Copy the Data file and updated Control files to the Sent

Folder.

An entry will be made in the local log file with the success status

as described in function point DTCSEN-10.

DTCSEN-08 If the transfer of the data and Control files fails to complete

successfully the DTS Client may attempt to resend the data if

configured to do so.The number of retries will be configurable via a parameter in theDTS Client configuration file as described in section 2.1.

If the Delay Report parameter is set in the DTS Client

parameter file, then the DTS Client will generate a Report

Control File indicating that the transfer has failed but the Client

will retry.

An entry will be made in the local log file with the error status asdescribed in function point DTCSEN-10.

DTCSEN-09 If the DTS Client transfer to the DTS Server does not completesuccessfully, after retrying for the configured number of times, the

DTS Client will abort the transfer.

A Report Control file will be generated indicating the error status

and placed in the IN folder.

An entry will be made in the local log file with the success orerror status as described in function point DTCSEN-10.

DTCSEN-10 The DTS Client will log all success and error events in a local log

file. The information recorded will be as follows;

Date / Time of event

StatusSuccess or error

Transaction details

Event details

Error details

DTS Client Receive

EDI Data Transfers will be received into DTS connected Trading Partners from

either;1. The eSMTP message service.


20/49

2. Other DTS Connected trading Partners.

The EDI message data will be held on the DTS Server in a mailbox associated with

the individual DTS Client. The message data will be transferred to the Client via a

DTS Client initiated receive transaction.

Also Data Transfer status reports may be received from the DTS Server.

The DTS Client will initiate all data transfers with the DTS Server to receive data

transfers.

DTCREC-01 The DTS Client will periodically poll the DTS Server for data to be

received.

The polling period for polling for incoming data will beconfigurable via a parameter in the DTS Client configuration file

as described in section 2.1.

DTCREC-02 The DTS Client will connect to the DTS Server to check whether

there is data to be transferred and to initiate the transfer if there is.

The DTS Client will establish a SLL encrypted connection to theDTS Server as described in DTCSEN-05.

The DTS Client will authenticate itself to the DTS Server as

described in DTCSEN-06.

DTCREC-03 If there is no data to be transferred from the DTS Server mailbox

associated with the DTS Client authentication details, then the DTS

Server will communicate this status to the DTS Client.

The DTS Client will close the SSL connection and wait for thenext poll event.

DTCREC-04 If there is data to be transferred from the DTS Server mailbox then

the DTS Server will transfer the message Data and Control files to

the DTS Client.

If multiple Data Transfers are outstanding they will betransferred to the Client in sequence.

On successful completion of the transfer the DTS Client willuncompress the Data file if required and copy the data file and

Control file to the IN folder.The DTS Client will close the SSL connection and wait for the

next poll event.



DTCREC-05 If the transfer of the Data and Control files fails to complete

successfully the DTS Client will not attempt to reconnect to receive

the data until the next poll period.

An entry will be made in the local log file with the error status as

described in function point DTCSEN-10.


21/49

DTREC-06 If the DTS Client configuration is set up for PollReport then it will

report on the success or failure of the poll to the DTS Server.

If the Poll to the DTS Server was successful then a control file

will be placed in the IN folder indicating that the poll was

successful.

If the Poll to the DTS Server failed then a control file will beplaced in the IN folder describing the error.

DTS Client Log

The DTS Client will maintain a local log file in the EDI Application host file system.

It will write a record of all success, failure and error events to the Local Log file for

support and diagnostic purposes.

The log entries will include the following data items;

Date (DDMMYYY)

Time (HH:MM:SS)

Event

Status

Status Code

Description

The format of each Log entry will be a single line per entry with the above data items

comma separated as follows;

Date, Time, Event, Status, Status Code, DescriptionTHE DTS Client will perform the following local log file maintenance functions.

DTCLOG-01 The DTS Client will rollover Log files on a daily basis. The log file

will be held in a LOG directory under the file system PATH root

configured for the DTS File Interface root as defined in section 2.1.

DTCLOG-02 The DTS Client will delete any log file in the LOG directory which

is over 20 days old.

Process Control

Facilities will be provided to control the operation of the DTS Client application via

operating system signals when it is executing.

The following facilities will be provided;

1. Shutdown

2. Suspend operations

3. Restart operations

4. Poll the OUT folder

DTCCON-01 When the DTS Client receives the SHUTDOWN signal it will


22/49

complete any operation it is currently performing and shutdown.

If the Client is in the process of sending a data transmission itwill complete the transfer.

If the Client is in the process of receiving a data transmission itwill complete the transfer.

DTCCON-02 When the DTS Client receives the SUSPEND signal it will complete

any operation it is currently performing and suspend all operations

If the Client is in the process of sending a data transmission it

will complete the transfer.

If the Client is in the process of receiving a data transmission itwill complete the transfer.

DTCCON-03 When the DTS Client receives the START signal it will start

processing.

If the Client was not in a suspended state then the start signalwill be ignored.

DTCCON-04 When the DTS Client receives the POLL signal it will complete any

operation it is currently performing and will then poll the OUT tray.

If the Client is in the process of sending a data transmission it


If the Client is in the process of receiving a data transmission it



23/49

DTS Server

DTS Server Send

When the DTS Client sends data to the DTS Server the server will either;

1. Convert the data to a SMTP message and send it out to the eSMTP MessageService

2. Deposit the data into a DTS mailbox for collection via the Trading Partner DTSClient.

The DTS Server will log all send transaction data in order to provide the following

facilities;1. Where the required information is returned by the receiving system, correlate SMTP Delivery

Service Notifications with the sent data record to provide a transfer delivery tracking.

2. Provide access to the delivery tracking information to EDI application administrators via a WebBrowser interface.

DTSSEN-01 On receipt of the Data and Control files, the DTS Server will use the

Client authentication details to verify the From SMTP address in

the Control File.

If the specified from address does not match the Client details then

The transfer will be aborted.

The DTS Server will generate a Report Control File with anInvalid From address Status record.

An entry will be made in the Tracking Log as described inDTSSEN-05.

DTSSEN-02 If the recipient of the data transfer is registered on the DTS the DTS

Server will generate a DTS received message in the recipient DTS

mailbox. This will be transferred when the recipient DTS Client

connects to receive data. The received message handling is as

defined in function point DTSREC-01.

A unique DTS Identifier will be generated and inserted into the

Control File.

A Status record entry will be added to the Control File

An entry will be made in the Tracking Log as described inDTSSEN-04.

DTSSEN-03 If the recipient of the data transfer is not registered on the DTS the

DTS Server will generate a SMTP message using the Data file and

the information in the Control file.


24/49

The Data file will be uncompressed if required.

The Data file will be converted to a SMTP MIME attachment.

The SMTP message recipient will be specified as the To

SMTP address from the Control File

The SMTP message originator will be specified as the From

SMTP address in the Control File.

The DTS Server will use the Client authentication details toverify the From SMTP address in the Control File. If correct

this will be used in the SMTP From field.

The Subject will be set from the Subject field from the Control

File.

A Unique DTSid will be generated. This will be specified as the

ENVID in the mailto command for the SMTP message. If thereceiving MTA supports RFC1891 then this identifier will be

returned in a Delivery Service Notification (DSN) as the

original envelope id. This can then be used to correlate

delivery notifications with the original message for message

delivery tracking.

If the conversion of the EDI data to SMTP message is successfulthen the SMTP message will be sent to its recipient via the

eSMTP Service.

An entry will be made in the Tracking Log as described in

DTSSEN-04.

DTSSEN-04 If the data transfer to another DTS mailbox or the eSMTP Service is

successful then the DTS Server will generate Tracking log record

with the following information;From

To

Date / Time

Subject

Local Transaction Identifier (from the Control File)

DTS Transaction Identifier (DTS generated unique identifier)

ActionTransfer to recipient mailbox or send to eSMTP

Status - Success

DTSSEN-05 If the data transfer to another DTS mailbox or eSMTP is not

successful then the DTS Server will generate a Tracking log record


To

Date / Time

Subject

Local Transaction Identifier (from the Control File)


ActionTransfer to recipient mailbox

StatusFailure


25/49

DTSSEN-06 If the data transfer to another DTS mailbox or eSMTP is not

successful then the DTS Server will generate a Report Control File

with a non delivery Status record.

The Control File will be copied into the originator DTS mailbox,

for collection by the originator DTS Client.

DTS Server Receive

The DTS Server will receive Data Transfers from;

1. Other DTS Client connected Trading Partners

2. SMTP Connected Trading Partners

Additionally the DTS Server will receive Delivery Service Notifications from SMTP

connected Trading Partners.

The following function points define the handling of Data Transfers received by the

DTS Server.

DTSREC-01 If the received message data is from a DTS Client, and the recipient

is also a DTS Client, then the DTS Server will copy the Data file and

an updated Control File into the recipient mailbox for collection.

If the received Data file is compressed then it will not beuncompressed.

The Control File will be as received from the Originator but will

have the following information added to it;

a) DTS Transaction Identifier

b) Status RecordDate / Time transferred to the recipient mailbox.

An entry will be made in the Tracking Log as described in DTSREC-05.

DTSREC-02 If the received message is from eSMTP the DTS Server will convert the messageinto a Data and Control file format. The Data and Control files will then be copied

into the recipient mailbox for collection.

The SMTP MIME attachment will be converted to Data file format

The SMTP message recipient will be specified as the To SMTP address inthe Control File

The SMTP message originator will be set as the From SMTP address in the

Control File.

The Subject will be set to the Subject field from the Control File.

If specified the ENVID will be copied to the Sender Local Id in the Control

file.

If ENVID is not specified then the message-id will be copied to the Sender

Local Id in the Control file.

A unique DTS identifier will be generated and specified as the

DTS identifier in the Control file.

A Status record entry will be added to the Control File.

An entry will be made in the Tracking Log as described in

DTSREC-05.


26/49

DTSREC-03 If the received message is a positive Delivery Service Notification

from SMTP then the DTS Server will;

Generate a data transfer audit trail record in the Tracking Log

with original local identifier and associate original message DTS

identifier if it can be correlated.

DTSREC-04 If the received message is a negative Delivery Service Notification

from SMTP then the DTS Server will;

Convert it to Control file format and put into the recipient

mailbox with original Data Transfer local identifier and DTS

identifier if it can be correlated.

Generate a data transfer audit trail record in the Tracking Log

with original Data Transfer local identifier and DTS identifier if

it can be correlated.

A Status record entry will be inserted into the Control File

indicating the failure to deliver.DTSREC-05 If the data transfer from another DTS mailbox or the eSMTP Service

is successful then the DTS Server will generate Tracking log record


To

Date / Time

Subject

Local Transaction Identifier (from the Control File or SMTP message/DSN)



StatusSuccessDTSREC-06 If the data transfer from another DTS mailbox or eSMTP is not

successful then the DTS Server will generate a Tracking log record


To

Date / Time

Subject

Local Transaction Identifier (from the Control File message/DSN)



StatusFailure


27/49

DTS Administration

Facilities will be provided via Web Browser to the NHS Registration Service to

manage the DTS Client connection to the DTS Service and to track Data Transferevents;

1. Register with DTS

2. DTS access Administration

Change Client password

Exeter File Copy Facility

Unregister from DTS

3. Data Transfer Tracking

The facilities to be provided to manage the DTS access are dependent on theadministration models and the workflow required between the NHSIA and the site

connecting to the DTS. The following functions define the baseline facilities.

Register with DTS - Migration from X.400

Initially it is envisaged that most DTS registrations will be performed as part of the

EDI System Migration from X.400 to SMTP.

The facilities to be provided via the NHS Registration Service for this activity are

documented in the EDI Gateway Functional Specification, [Reference 3].

Register with DTS - New Site

For new EDI Systems or systems that have migrated to SMTP before connecting to

DTS a facility will be provided to register with the DTS as a single operation. No

migration facilities will be provided via this process.

EDI system administrators performing the registration with the DTS will require a

NHS Registration Service login account. This will be authorised by NHSIA and set up

using the current NHS Registration account management facilities. The NHSIA will

be able to authorise the registration with the DTS as part of the account set up facility.

The new site Register with DTS facility will be provided via the NHS Registration

Service Web Browser interface.

DTSNREG-01 If authorised to register with the DTS, the NHS Registration Serviceaccount will have the facility to Register a new connection to the

DTS Service. This will generate the following information required

to configure the DTS Client for the connection and to allow the

Transfer of data via the service.

DTS Userid

DTS password

DTS Client SMTP address

The account user will then be asked to confirm the Registration and


28/49

the DTS set up will be implemented on the DTS Server.

DTS Access Administration

Once an EDI System is registered to use the DTS Service the administration facility

will allow the site administrator to perform the following functions via the Web

Browser interface;

1. Change DTS password used by the DTS Client to access the DTS Service.

2. Configure the Exeter File Copy for the Client

3. Perform the Exeter File Copy

DTSADM-01 If authorised to register with the DTS the NHS Registration Service

account will have the facility to Change the password used to access

the DTS Service. This will generate a new DTS password, whichwill need to configured on the DTS Client.

The account user will then be asked to confirm the new

password and the change will be implemented on the DTS

Server.

DTSADM-02 A facility will be provided to allow the DTS Client Administrator to

set up the Exeter File Copy Facility. This will cause the DTS Service

to store all Data Transfers received for the Clint for 15 days.

DTSADM-03 A facility will be provided to allow Clients configured for the ExeterFile Copy facility to resend received Data Transfers.

The administrator will enter the date and time from which files

are to be resent.

The administrator will confirm the resend.

On confirmation the DTS Server will flag and Data Transfers

received after the specified date and time so that they will be

resent when the Client next connects to the DTS.

Unregister from DTS

The facility will be provided to remove a Client registration with the DTS Service.

DTSDEL-01 If authorised to register with the DTS the NHS Registration Service

account will have the facility to delete the client registration.

The account user will then be asked to confirm the change before

it is implemented.


29/49

The Client username and password will be removed from theDTS.

The Client SMTP address will be removed from the DTS.

Any uncollected Data Transfers in the Client Mailbox will bepurged.

Data Transfer Tracking

DTS Client administrators will be provided with the facilities to view Data Transfer

tracking information stored on the DTS Server via the NHS Registration Service Web

Browser interface.

DTSATR-01 The Tracking interface will allow the input of various filter

information to select the Data Transfer to track. Partial entry will beallowed on addresses and Identifiers.

Date and time period

To Address

From Address

Local Identifier

DTS Identifier

Partner Identifier

DTSATR-02 The Tracking facility will return a summary list of all of the

matching Tracking records.

A maximum of 50 entries will be returned

The returned records will be restricted the to those involving the

SMTP addresses associated with the login account.

Date and time of Transfer

To Address

From AddressLocal Identifier

DTS Identifier

Partner Identifier

DTSATR-03 The Tracking facility will allow the selection of an individual Data

Transfer from the summary list and will display the full Tracking

information for the entry;

To Address

From Address

Subject


30/49

Local Identifier

DTS Identifier

Partner Identifier

Workflow IdProcess Id

Tracking Record data for the Transfer

Date and Time of event

Event description

Status

Status Description

References

1. Data Transfer Service Proposal Issue 1.0

2. DTS File Interface Specification Issue 1.0

3. EDI Gateway Functional Specification Issue 1.0

Glossary

TERM DESCRIPTION

CA Certificate Authority

DNS Domain Name Service

DR Delivery Report

DSN Delivery Service Notification

DTS Data Transfer Service

EDI Electronic Data Interchange

MIME Multipurpose Internet Mail Extensions

MTA Message Transfer Agent

MTSID Message Transfer Service IdentityNDR Non Delivery report

SMTP Simple Message Transfer Protocol


31/49

Configuration Control

Sector/Customer Unit: Health Project: NHS Message Service

Data Transfer Service

A84202F

Authors: Phil Reed Version: 1.1

Responsible Authority: Mike Smithson Status: Draft

Date of last

change:31 August 2010

Syntegra 2010

Change details

Section Issue Owner Date Details of change

All 1 Phil Reed 20-12-2002 Issue 1

All 1.1 Phil Reed 14-1-2003 Changes after NHSIA comment

3.2 1.2 Phil Reed 28-1-2003


32/49

DTS Client Parameter File Example

dts10233password23

/apps/dtsclient

/apps/dtsclient/cert

/apps/dtsclient/log

dts.nhs.uk

N

N

N

N

12015

3


33/49

Appendix 5 Data Transfer Service File Interface Specification(version 1.2)

CONTENTSDATA TRANSFER SERVICE A MIGRATION TOOL TO REPLACE CURRENT

X400 MESSAGING BETWEEN NHS WORKFLOW APPLICATIONS 1Submitter: Richard Corbridge .................................................................................. ................... 1Sponsorship: Gwyn Thomas ............................................................ ................................................. 11. Introduction............................................................................................................................. 12 Compliance with Requirements for Strategic Information Standards....... .............................. 23 Strategy Overview ........................................................................................ ........................... 2

Appendix 1e-GIF specification for cryptographic algorithms ............... ...................................... 7Appendix 2Delivering 21

stCentury IT Support for the NHS - National Strategic Programme

(Section 3) ....................................................................................... ................................................. 8Appendix 3Statement of Approval for Technical Security Aspects of Data Transfer Service from

NHS Information Authority Security Board (January 2003 Board Meeting) ................................. 10Appendix 4Data Transfer Service Functional Specification (version 1.2) ................................. 11

INTRODUCTION 13Background ............................................................................................................ ............................ 13Service Summary ............................................................................................................................... 13

DTS CLIENT 14Client Site Configuration.......................................................... .......................................................... 14DTS Client Send................................................................................................................................. 16DTS Client Receive ........................................................ .............................................................. ...... 19DTS Client Log .............................................................................................. .................................... 21Process Control .................................................................................................................................. 21

DTS SERVER 23DTS Server Send .................................................................................................... ............................ 23DTS Server Receive ....................................................................................... .................................... 25

DTS ADMINISTRATION 27Register with DTS - Migration from X.400 ...................................................................... ................. 27Register with DTS - New Site ............................................................. ............................................... 27DTS Access Administration .............................................................................................. ................. 28Unregister from DTS ................................................................ .......................................................... 28Data Transfer Tracking ...................................................................................................................... 29


34/49


Change details ................................................................................................ .................................... 31DTS CLIENT PARAMETER FILE EXAMPLE 32

Appendix 5Data Transfer Service File Interface Specification (version 1.2) ............................. 33INTRODUCTION 35

Background ............................................................................................................ ............................ 35DTS Client Overview ............................................................ .......................................................... 35

DTS CLIENT FILE INTERFACE 36Directory/File Structure ............................................................ .......................................................... 36File Interface ...................................................................................................................................... 36

Transaction Sequence Identifier ................................................................ ..................................... 37Control File ................................................................ .............................................................. ...... 37File Interface Maintenance ..................................................................... ....................................... 39

DATA TRANSFER 40OUT Transactions .................................................................................................. ............................ 40

IN Data Transactions ............................................................................................ ......................... 41IN Status Transactions .................................................................... ............................................... 42


Change details ................................................................................................ .................................... 46APPENDIX A - DTS CONTROL FILE XML FORMAT EXAMPLE 47

Appendix 6Statement of Approval from the Design Authority with reference to the strategic fit

of the Data Transfer Service when considered in relation to the required programme of works for

the National Programme for Information Technology ............................................................. ...... 48


35/49

Introduction

Background

The NHS Messaging Service currently supports two messaging standards, the X.400

standard, on which the original NHS Messaging Service was based, and extended

SMTP (eSMTP), which is the standard chosen for all future messaging. There is

therefore a requirement to migrate all messaging across to the new eSMTP standard.

Currently many EDI Application connections to the X.400 service are via on site

Message Transfer Agent (MTA) servers. The migration and ongoing support of these

MTAs was perceived to be difficult and expensive.

Syntegra therefore proposed to provide the Data Transfer Service (DTS) which would

provide a simple client application to run on the Host Application Server connecting

to a centrally managed Data Transfer Server.This document defines the interface between the DTS Client and the host application.

DTS Client Overview

The DTS Client will run as a separate application on the server platform supporting

the host Application. It will perform the following functions;

Send Application data to the central DTS Server for delivery to the specifiedrecipient.

Receive Application data from the central DTS Server for delivery to the localApplication.

Provide delivery and error status indications to the local Host Application.

The DTS Client will interface to the Host Application via the file interface defined in

this document.


36/49

DTS Client File Interface

The DTS Client will transfer data to and from the Host Application via a simple file

based interface.The following sections define the file-based interface;

1. Directory/File structure

2. Control Information

3. Status Information

Directory/File Structure

The DTS Client will make use of the following file system directory/folder structure

to transfer data to and from the Host Application;

IN

OUT

TEMP

SENT

The is the path to the DTS Client Interface top level

directory/folder. The DTS Client root path will be specified to the DTS Client as a

configuration item in the DTS Client Parameter File. The DTS Client will read this

file when it starts up to configure site/implementation specific parameters.The IN directory will be used by the DTS Client to deposit data and statusinformation to be received by the Host Application.

The OUT directory will be used by the HOST Application to copy data to be sentby the DTS Client.

The SENT directory will be used by the DTS Client to copy sent data for use by

the Host Application.

The TEMP directory will be used by the DTS Client for any intermediate files

during its processing.

File Interface

Where data is to be transferred, e.g. sending or receiving data, the file interface will

contain two files;

Data File.dat

Control File - .ctl

Where only status information is to be transferred e.g. delivery status information or

error indication the transaction will be a single file. Note this will only be sent from

the DTS Client to the Host Application.

Report File - .ctl


37/49

The Data file will contain the data to the transferred. This may be in any form and will

be treated by the DTS Client and Server as an arbitrary data file. The only operation

that the Client may perform on the Data file is to compress it if the information in the

associated Control File allows it to do so.

The Control file will contain the information required to identify, transmit and audit

the Data File.The Report File will contain information to identify the transaction being reported on

and the status report information.

The combination of and will uniquely identify the data transfer files,

will uniquely identify the client site. The DTS Client userid should beused for this value.

an optional value used to allow different applications on the platform to

use the same client to transfer files. (This will prevent the risk of one application

overwriting the file created by another application using the same sequence id.)

Transaction Sequence Identifier

The Transaction Sequence Identifier, sequence_id, will be incorporated into the file

names used in the transaction between the Host Application and the DTS Client. The

Sequence Identifier will identify the Data File and any associated Control File.

The term Transaction in this context is limited to the transfer of data between the

Host Application and the Client or vice versa. It is not intended to use this to associate

the reporting of status information back to the Host Application.

The Sequence Identifier will be unique for each transaction.

Where Data and Control files are involved in a transaction the Sequence Identifier

will be the same for both files.Transactions initiated by the Host Application will have the Sequence Identifier

applied by the Host Application. The Host Application must maintain and control

the Application Sequence Identifier.

Transactions initiated by the DTS Client will have the Sequence Identifier appliedby the Client. The DTS Client will maintain and control the Client Sequence

Identifier.

Sequence numbers will be 8 digits starting at 00000001 through to 99999999.

After 99999999 the sequence will start again at 00000001.

Control File

The control file will be in XML format as defined in the Appendix A - APPENDIX A

- DTS Control File XML Format Example.

The Control File and Report File will be the same format but will contain different

information depending on the transaction.

The Control and Report file data structure is defined in the following table.

Mandatory elements must be supplied

Optional elements may be ignored or specified with no data.


38/49

DATA

ITEM

VALUES/

SIZE

MANDATOR

Y/

OPTIONAL

DESCRIPTION

Version 1.0 M Version of Control File

AddressType SMTP M Identifies the type of Address.

SMTP only initially.

MessageTyp

eData

Report

M Identifies the type of Transfer

Data will have a data file and a

control file.

Report will have a control file.

From SMTP

address

M Identifies the originator of the Data

Transfer. SMTP address of the

originator.

To SMTPaddress

M Identifies the recipient of the DataTransfer. SMTP address of the

recipient.

Subject SMTP

Subject

O Subject of the Data Transfer as for

SMTP email subject.

LocalId 255

characters

O Local Identifier of the Data

Transfer. This is specific to the

Host Application sending via the

Client. This will allow for

correlation with DTS Ids

DTSId 100characters

O Each Data Transfer will beassociated with a DTS Identifier as

it passes through the DTS Server.

This will allow for correlation with

local and partner ids.

PartnerId 255

characters

O If specified, the identifier (or SMTP

message id) from received Data

Transfers.

Compress Y

N

O Flag to indicate that the Data File

can be compressed by the Client.

Default NO

Encrypted Y

N

O Flag to indicate that the Data Filehas been encrypted by the Host

Application.

WorkflowId 32

characters

O Identifier for the workflow that the

Data Transfer is part of. This may

be used for reporting and to define

processing at the DTS Server.

ProcessId 32

characters

O For future use. Identifier to specify

the type of processing that might be

required before forwarding to the

recipient.

DataChecksu

m

O Field to be used for a checksum for

the Data file.


39/49

IsCompresse

dY

N

O Field to indicate that the Data file is

compressed.

StatusRecord O Status information on the status of

the Data Transfer.

This will contain the followinginformation;

Date

Time

Event

StatusSuccess or Error

Status Code

Description

File Interface Maintenance

There is a need for the files in the File Interface directories to be managed.

1. INThe DTS Client will copy received Data Transfer files and report files to theIN directory.

2. IN - It is the responsibility of the Host Application to manage the IN directory. i.e.

to use, delete or archive the data files.3. OUTDTS Client will move Data Transfer files from the OUT directory once it

has successfully transferred it to the DTS Server.

If configured to do so the DTS Client will copy sent Data Transfer files to the

SENT directory.

4. SENT - It is the responsibility of the Host Application to manage the SENTdirectory. i.e. to use, delete or archive the data files.

5. TEMPThe TEMP directory is private to the DTS Client, the DTS Client willmanage the contents of the directory.


40/49

Data Transfer

The Control File will contain different information depending on the circumstances.

The following sections describe the different contents for the following1. Out TransactionHost Application sends data via Client

2. In Data Transactions - Host Application receives data via Client

3. In Status TransactionClient reporting on status / events.

OUT Transactions

OUT Transactions are those from the Host Application via the DTS Client to the DTS

Server. The requirements for the Control File are to identify the recipient of the data

and to identify the transfer for audit purposes.

The following table shows the data items for this Transaction.DATA

ITEM

VALUES/

SIZE

MANDATOR

Y/

OPTIONAL

DESCRIPTION


AddressType SMTP M Type of Address.

MessageTyp

eData M Identifies the type of Transfer, the

OUT Transaction will have a data

file and a control file.

From SMTPaddress M SMTP address of the originator.

To SMTP

address

M SMTP address of the recipient.

Subject SMTPSubject


SMTP email subject.

LocalId 255

characters

O Local Identifier of the Data


Host Application sending via the

Client.

DTSId O Not applicable in the OUT

Transaction.

PartnerId O Not applicable in the OUT

Transaction.

Compress Y

N

O Optional flag to indicate that the

data file can be compressed.

Encrypted Y

N

O Optional flag to indicate that the

data file is encrypted.

WorkflowId 32characters

O Optional Flag indicating theworkflow, e.g. IOS.


41/49

ProcessId 32

characters

O Optional Flag indicating processing

to be performed at the DTS Server.

For Future use.

DataChecksu

m

O Not applicable in the OUT

Transaction.

IsCompressed

O Not applicable in the OUTTransaction.

StatusRecord O Not applicable in the OUT

Transaction.

IN Data Transactions

In Data Transactions are those from the DTS Server via the DTS Client to the Host

Application. The requirements for the Control File are to identify the recipient of the

data and to identify the transfer for audit purposes.

The following table shows the data items for this Transaction.DATA

ITEM

VALUES/

SIZE

MANDATOR

Y/

OPTIONAL

DESCRIPTION



MessageTyp

eData M Identifies the type of Transfer, the

IN Data Transaction will have a

data file and a control file.

From SMTPaddress M SMTP address of the originator.

To SMTPaddress


Subject SMTP

Subject


SMTP email subject.

LocalId O Not applicable in the IN Data

Transaction.

DTSId 100characters

O DTS Identifier for the Data

Transfer. This can be used to

identify the Transfer for Tracking

purposes.

PartnerId 255characters

O Partner identifier of the Data


Host Application sending the data.

E.g. SMTP message Identifier.

Compress O Not applicable in the IN Data

Transaction.

Encrypted O Not applicable in the IN Data

Transaction.

WorkflowId 32characters

O Optional Flag indicating theworkflow, e.g. IOS.


42/49

ProcessId O Not applicable in the IN Data

Transaction.

DataChecksu

m

O Not applicable in the IN Data

Transaction.

IsCompresse

d

O Not applicable in the IN Data

Transaction.StatusRecord O Status information on the status of

the Data Transfer.

Date

Time

Event - Delivery

StatusSuccess

IN Status Transactions

Status Transactions will be sent from the DTS Client to the Host Application. The

requirements for the Control File are to identify the Data Transfer involved and the

status.

Status Transactions will be sent to the Host Application from the DTS Client in the

following circumstances. Configuration of the DTS Client to report on the event will

be configurable via the DTS Client Configuration file.

1. Collect Error : The Client has detected an error with the OUT Transaction files.

2. CollectReport : OptionalStatus Report indicating that the DTS Client has taken

responsibility for the Data Transfer files in the OUT Transaction.

3. DelayReport : Optional - DTS Client has failed to transfer to DTS Server but willretry.

4. Transfer Fail : DTS Client has failed to transfer to DTS Server and has aborted thetransfer

5. TransferReport : OptionalDTS Client has successfully transferred to the DTSServer

6. Server Fail : DTS Server failed to transmit the data.

7. Poll Fail : OptionalDTS Client has attempted to poll the DTS Server but hasfailed.

8. PollReport : Optional - DTS Client has polled the DTS Server successfully.

9. Non Delivery : Negative Delivery Service Notification received from SMTPservice.

10.Server Authentication Error : DTS Server authentication failed.

11.Client Authentication Error : DTS Client authentication failed.

The Status Transactions will specify the same Data Transfer information as the

Original Data Transfer Control File (where possible). This will allow the Host

Application to identify which Data Transfer the Status report is about.


43/49

All Status information regarding success or failure will be specified in the Tracking

Records data elements in the report file.

The following table shows the data items for this Transaction.

DATA

ITEM

VALUES/

SIZE

MANDATOR

Y/

OPTIONAL

DESCRIPTION



MessageTyp

eReport M Identifies the type of Transfer, the

IN Status Transaction will Control

File.

From SMTP

address

M SMTP address of the originator.

From the original OUT Transaction

Control File.

This will not be specified for

the Poll Fail and Poll report

status reports

To SMTP

address


From the original OUT Transaction

Control File.


the Poll Fail and Poll reportstatus reports

Subject SMTP

Subject


SMTP email subject. From theoriginal OUT Transaction Control

File, if specified.



status reports

LocalId 255

characters

O From the original OUT Transaction

Control File.



status reports

DTSId 100characters

O DTS Identifier for the Data

Transfer.

This will only be specified if

the Status Report comes from

the DTS Server.

PartnerId O Not applicable in the IN Status

Transaction.

Compress O Not applicable in the IN Status

Transaction.

Encrypted O Not applicable in the IN StatusTransaction.


44/49

WorkflowId 32

characters

O From the original OUT Transaction

Control File if specified.



status reports.

ProcessId O Not applicable in the IN Status

Transaction.

DataChecksu

m

O Not applicable in the IN Status

Transaction.

IsCompresse

d

O Not applicable in the IN Status

Transaction.

StatusRecord O Status information on the status of

the Data Transfer. See Error!

Reference source not found. for

the list of Events, codes and

Descriptions.Date

Time

Event

Status

Status Code

Description


45/49

References

4. Data Transfer Service Proposal Issue 1.0

5. Data Transfer Service Functional Specification Issue 1.0

6. EDI Gateway Functional Specification Issue 1.0

Glossary

TERM DESCRIPTION

DNS Domain Name Service

DR Delivery Report

DSN Delivery Service Notification

DTS Data Transfer ServiceEDI Electronic Data Interchange

MIME Multipurpose Internet Mail Extensions

MTA Message Transfer Agent

MTSID Message Transfer Service Identity

NDR Non Delivery report

SMTP Simple Message Transfer Protocol


46/49

Configuration Control

Sector/Customer Unit: Health Project: NHS Message Service

Data Transfer Service

A84201F

Authors: Phil Reed Version: 1.2

Responsible Authority: Mike Smithson Status: Draft

Date of last

change:31 August 2010

Syntegra 2010

Change details

Section Issue Owner Date Details of change

All 1 Phil Reed 20-12-2002 Issue 1

All 1.1 Phil Reed 15-1-2003 Issue 1.1

Section 2 1.2 Phil Reed 21-1-2003 Changes to file name format requested by NHSIA


47/49

APPENDIX A - DTS Control File XML Format Example

1.0

SMTP

Data

[email protected]

[email protected]

EDI Data

Exeter99-20021216101210

DTS20021216101210-927652

Y

N

Exeter-GP-IOS

< IsCompressed >Y

20021216102012

Transfer to DTS Server

Success

0


48/49

Appendix 6 Statement of Approval from the Design Authority withreference to the strategic fit of the Data Transfer Service whenconsidered in relation to the required programme of works for theNational Programme for Information Technology

The Design Authority (DA) has provided a statement with reference to how the Data

Transfer Service (DTS) relates to the programme of works for the National

Programme for Information Technology.

The DTS Project Team demonstrated the DTS specification and functionality to the

DA and then made for following request for a Statement of Approval for the DTS.

----- Original Message -----From:Humphries StephenTo:'[email protected]'

Cc:Corbridge Richard;Reid ScottSent: Monday, May 19, 2003 6:28 PMSubject: FW: Support letter from the DA

Robin,

Please see the email thread below, your name has been forwarded onto me inreference to getting a viewpoint from the Design Authority about the Data TransferService that is currently being prepared for implementation within the service. What Iam hoping to arrange is for someone from the Design Authority attend ademonstration of the Data Transfer Service (DTS) at the Syntegra's offices in Leeds.

It is then hoped that a statement from the Design Authority may then be producedabout the DTS, giving a viewpoint of how this service fits into the wider plans of theNational Programme. This statement is being requested by the InformationStandards Board in relation to a submission the DTS Project has made to ISB for thisnew service.

Can you help, and if yes when would be a convenient time for you to attend ademonstration a Syntegra's office.

Regards Steve

Subsequent to the above request and demonstration of the DTS, Steve Powell from

the DA emailed the DTS Project Team to provide the following Statement ofApproval for the DTS (with particular reference to the strategic future plans for the

NHS-wide Clearing Service).
mailto:[email protected]:[email protected]:[email protected]:'[email protected]'mailto:'[email protected]'mailto:'[email protected]'mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:'[email protected]'mailto:[email protected]


49/49

Richard,

I am now able to provide the positive response that you require, from the Design Authority, tomove the existing NWCS service from the x.400 service over to DTS. As we have discussed(and you point out in your mail below), this decision has been made outside of the re-procurement of NWCS and the ongoing discussions about the long term messaging solution

for the NHS.

If you need any further assistance please give me a call.

Regards

Steve-----Original Message-----From: Corbridge RichardSent: 08 June 2003 10:00To: Powell Steve; '[email protected]''

Cc: Humphries Stephen

Subject: RE: Support letter from the DAImportance: High

Steve, Andy

This is now an urgent request.

All we need from the DA is some words to indicate that the DTS solution is an appropriatestrategic solution to allow the NWCS service to migrate from the X.400 service in theappropriate time scales.

These words need only indicate the current NWCS service and the current DTS service andneed not be linked in any way to the re-procurement of either. The reason why this is so

urgent is that we need an ISB statement to allow NWCS to migrate of the X.400 service,therefore the implication of not doing this and leaving NWCS as is is the extension of theX.400 service, you may remember that this is extremely expensive and to the limit of itslegality.

Any help you can offer in this, we have 6 million monthly messages to migrate in just 150days.

Many thanks

Richard Corbridge

Draft Submission

Documents

Transcript of Draft Submission