Data Transfer Service A Migration tool to replace current X400 messaging between NHS workflow applications

Submitter: Richard Corbridge Sponsorship: Gwyn Thomas 1.

1.1

Introduction
This paper proposes a technical solution to support a secure transport infrastructure to transfer data between NHS organisations and NHS organisations 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 eGIF compliance secure data transfer infrastructure (i.e. HTTPS secure Hypertext Transfer Protocol). 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 1 see 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 Technology See Appendix 6. Data Transfer Service Functional Specification (version 1.2) See Appendix 4 Data Transfer File Interface Specification (version 1.2) See Appendix 5

1.2

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 period of the NHS Managed Message Handling Service.

1.3

The first workflow application community scheduled to use this standard for migrating 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. The technological concept of the DTS has already been implemented with great success in the NHS Numbers for Babies (NN4B) project.

1.4 2

Compliance with Requirements for Strategic Information Standards

The technologies that support the secure data transfer in the solution specified in 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. The architecture of the strategy specified in this submission is considered to meet an agreed set of purposes, these are: Compliance with the requirements of Domain to Domain Encryption for 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 Data Protection 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.

2.1

2.2

3
3.1

Strategy Overview
The NHS has historically utilised the X.400 messaging standard to support data 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. The DTS (Data Transfer Service) is a technological solution that has been specifically 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 workflow applications to exchange information

3.2

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 Hypertext Transfer Protocol Message Transfer Agent transfer messages between computers Managed Server Service a service provided within the core NHS Messaging Service designed for organisations who do not wish to own or operate their own MTA. Secure Sockets Layer is the e-GIF specified standard for transport security.

HTTP MTA

MSS

SSL

3.3.2 DTS Server

Central MTA (MSS) eSMTP The Data Transfer Server performs two primary functions. First, it supports Application 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. Data Transfer Server HTTP / SSL 128 HTTP / SSL 128 bit 3.3.3 DTS Client bit Encrypted Encrypted 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. DTS Client DTS Client Application Application

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.1 Client File Interface - Folder Structure DTS Root defined in client configuration file IN used by the DTS Client to deposit data and status information to be received by Host Application OUT used by the Host Application to copy data to be sent by the DTS Client SENT used by the DTS Client to copy sent data for use by the Host Application TEMP - used by the DTS Client for any intermediate files during its processing 3.3.4.2 Client 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.3 Client 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 From Subject DTSID Compress WorkflowID DataChecksum StatusRecord MessageType To Local ID PartnerID Encrypted ProcessID IsCompressed

3.3.5 Client with the Data Transfer Server Interface

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 bit encryption 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.1 Administration For each DTS Client, password protected user accounts users can be configured that will allow defined levels of access to view the web-based administration and data transfer tracking system. 3.3.7.2 Data 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 Identifier DTS Client Identifier Partner Identifier 3.3.7.3 Data 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

Local Identifier DTS Client Identifier Partner Identifier Workflow ID Process ID Tracking Record for the Transfer o Date and Time of event o Event description

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.

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 Vision 3.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 IT 3.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 the impact of improved IT to be made early, with sustained, incremental

increases in functionality. A preparatory Phase 0 is needed from April 2002 March 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 0 April 2002 March 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 1 April 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 IT projects Implementation and Support National IT services portfolio established StHA investment plans accepted (and funding agreed) by National Programme Director

Appendix 3 Statement of Approval for Technical Security Aspects of Data Transfer Service from NHS Information Authority Security Board (January 2003 Board Meeting)
-----Original Message----From: Doyle John Sent: 22 January 2003 14:33 To: Corbridge Richard; Welsh Bel Subject: NHSnet Security Board - DTS Richard, Security Board considered the DTS Security Policy and the encryption standard today....Minute below

BT Syntegra - Data Transfer Service The NHSnet Security Board reviewed the DTS Security Policy and considered the compliance of the encryption provision against the stated clinical security requirements for Domain to Domain encryption. The Board accept the Security Policy for the Service as meeting requirements and request that updates or amendments be copied to the Board Secretary. Encryption provision within the service is 128bit SSL encryption at the transport layer which ensures the security of clinical and other edi messages from the originating domain through to the DTS centre where the message is transferred within a secure environment to the outbound 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 the requirement for Domain to Domain encryption. Although in this instance a more precise description would be "Inter - Domain Encryption", the level of security imposed does more than equate to that specified.

Bel, Draft as promised JD John C Doyle NHSnet Snr. Security Manager 07966 435194 http://nww.nhsia.nhs.uk/security www.nhsia.nhs.uk/nhsnet

Appendix 4 Data Transfer Service Functional Specification (version 1.2)

CONTENTSDATA TRANSFER SERVICE A MIGRATION TOOL TO REPLACE CURRENT
X400 MESSAGING BETWEEN NHS WORKFLOW APPLICATIONS Submitter: Richard Corbridge 1 1 1 1 2 2 7 8

Sponsorship: Gwyn Thomas 1. 2 3 Introduction Compliance with Requirements for Strategic Information Standards Strategy Overview

Appendix 1 e-GIF specification for cryptographic algorithms Appendix 2 Delivering 21 Century IT Support for the NHS - National Strategic Programme (Section 3)
st

Appendix 3 Statement of Approval for Technical Security Aspects of Data Transfer Service from NHS Information Authority Security Board (January 2003 Board Meeting) 10 Appendix 4 Data Transfer Service Functional Specification (version 1.2) INTRODUCTION Background Service Summary DTS CLIENT Client Site Configuration DTS Client Send DTS Client Receive DTS Client Log Process Control DTS SERVER DTS Server Send DTS Server Receive DTS ADMINISTRATION Register with DTS - Migration from X.400 Register with DTS - New Site DTS Access Administration Unregister from DTS Data Transfer Tracking 11 13 13 13 14 14 16 19 21 21 23 23 25 27 27 27 28 28 29

REFERENCES GLOSSARY CONFIGURATION CONTROL Change details DTS CLIENT PARAMETER FILE EXAMPLE Appendix 5 Data Transfer Service File Interface Specification (version 1.2) INTRODUCTION Background DTS Client Overview DTS CLIENT FILE INTERFACE Directory/File Structure File Interface Transaction Sequence Identifier Control File File Interface Maintenance DATA TRANSFER OUT Transactions IN Data Transactions IN Status Transactions REFERENCES GLOSSARY CONFIGURATION CONTROL Change details APPENDIX A - DTS CONTROL FILE XML FORMAT EXAMPLE

30 30 31 31 32 33 34 34 34 35 35 35 36 36 38 39 39 40 41 44 44 45 45 46

Appendix 6 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 Technology 47

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 Transfer Agents (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

MTA

X.400

NHS REGISTRATION SERVICE

EDIG

eSMTP DTS SERVER MTA DTS CLIENT TRADING PARTNER TRADING PARTNER

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 supporting the 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 DESCRIPTION Y/ OPTIONAL ClientIdentity M Site specific identity for the DTS Client. Equivalent to username. This will be generated during the registration of the Client. ClientAuthenticat M Site specific authentication token ion 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 of the 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 Server SecondaryURL O Secondary DTS server URL.

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 Parameter controlling the 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 Parameter controlling the generation of reports indicating that the transfer of the Data Files to the DTS Server has succeeded. Default - N Parameter controlling the generation of reports indicating that the poll to the DTS Server to check for received transfers has succeeded or failed. Default - N Parameter controlling the copying of sent Data Transfer files into the SENT folder on successful Transfer to the DTS Server. Default - N File Polling Period parameter controlling the polling period that the DTS Client will use between checks for Data Files from the EDI Application. Value seconds 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. Value minutes Default -15

DelayReport

Y N

TransferReport

Y N

PollReport

Y N

SaveSent

Y N

FilePoll

1 to 600

ServerRetry

0 to 10

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 a standard 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 mandatory configuration items then the DTS Client will write an error report to the DTS Client Log file and close down. If the Client Parameter file does not specify the optional configuration items then the DTS Client will use the default values for those parameters. 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.

DTSCINI.03

DTSCINI.04

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 DTS File Interface Specification, [Reference 2].

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 file the EDI data to be transferred. 2. Control file containing the information required to send the EDI data file to its recipient. 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 on information 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 send them 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. 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 Client will generate a Report Control file with a Status Record

DTCSEN-03

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 Transfer Files 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 or error 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 and the 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. An entry will be made in the local log file with the success or error status as described in function point DTCSEN-10. 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 Server via the registration facility defined in the document EDI Gateway Functional Specification, [Reference 3]. The userid and password will be configured on the DTS Client via 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. An entry will be made in the local log file with the success or

error status as described in function point DTCSEN-10. 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 transfer details. 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 the DTS 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 as described in function point DTCSEN-10. DTCSEN-09 If the DTS Client transfer to the DTS Server does not complete successfully, 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 or error 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 Status Success 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.

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 be configurable 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 the DTS 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 the next poll event. 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 be transferred to the Client in sequence. On successful completion of the transfer the DTS Client will uncompress 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. An entry will be made in the local log file with the success or error status as described in function point DTCSEN-10. 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.

DTCREC-04

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 be placed 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, Description THE 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

complete any operation it is currently performing and shutdown. 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 it will 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 it will 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 signal will 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 will complete the transfer. If the Client is in the process of receiving a data transmission it will complete the transfer.

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 Message Service 2. Deposit the data into a DTS mailbox for collection via the Trading Partner DTS Client. The DTS Server will log all send transaction data in order to provide the following facilities;
1. 2. 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. Provide access to the delivery tracking information to EDI application administrators via a Web Browser 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 an Invalid From address Status record. An entry will be made in the Tracking Log as described in DTSSEN-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 in DTSSEN-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.

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 to verify 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 the receiving 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 successful then 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) Action Transfer 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 with the following information;
From To Date / Time Subject Local Transaction Identifier (from the Control File) DTS Transaction Identifier (DTS generated unique identifier) Action Transfer to recipient mailbox

Status Failure

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 be uncompressed. 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 Record Date / 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 message into 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 in the 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.

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. 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-04

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 with the following information;
From To Date / Time Subject Local Transaction Identifier (from the Control File or SMTP message/DSN) DTS Transaction Identifier (DTS generated unique identifier) Action Transfer to recipient mailbox

Status Success DTSREC-06 If the data transfer from another DTS mailbox or eSMTP is not successful then the DTS Server will generate a Tracking log record with the following information;
From To Date / Time Subject Local Transaction Identifier (from the Control File message/DSN) DTS Transaction Identifier (DTS generated unique identifier) Action Transfer to recipient mailbox

Status Failure

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 Transfer events; 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 the administration 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 Service account 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

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, which will 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. A facility will be provided to allow Clients configured for the Exeter File 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.

DTSADM-03

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.

The Client username and password will be removed from the DTS. The Client SMTP address will be removed from the DTS. Any uncollected Data Transfers in the Client Mailbox will be purged.

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 be allowed 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 Address Local 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

Local Identifier DTS Identifier Partner Identifier Workflow Id Process Id Tracking Record data for the Transfer Date and Time of event Event description Status Status Description

References
1. 2. 3. Data Transfer Service Proposal DTS File Interface Specification EDI Gateway Functional Specification Issue 1.0 Issue 1.0 Issue 1.0

Glossary
TERM CA DNS DR DSN DTS EDI MIME MTA MTSID NDR SMTP DESCRIPTION Certificate Authority Domain Name Service Delivery Report Delivery Service Notification Data Transfer Service Electronic Data Interchange Multipurpose Internet Mail Extensions Message Transfer Agent Message Transfer Service Identity Non Delivery report Simple Message Transfer Protocol

Configuration Control
Sector/Customer Unit: Health Project: NHS Message Service
Data Transfer Service A84202F

Authors: Phil Reed Responsible Authority: Mike Smithson

Version: 1.1 Status: Draft Date of last 31 August 2010 change:

Syntegra 2010

Change details
Section
All All 3.2 1 1.1 1.2

Issue

Owner
Phil Reed Phil Reed Phil Reed

Date
20-12-2002 14-1-2003 28-1-2003 Issue 1

Details of change
Changes after NHSIA comment

DTS Client Parameter File Example

<DTSConfig> <ClientIdentity>dts10233</ClientIdentity> <ClientAuthentication>password23</ClientAuthentication> <InterfaceRoot>/apps/dtsclient</InterfaceRoot> <CertPath>/apps/dtsclient/cert</ CertPath> <LogPath>/apps/dtsclient/log</LogPath> <PrimaryURL>dts.nhs.uk</PrimaryURL> <SecondaryURL></SecondaryURL> <CollectReport>N</CollectReport> <DelayReport>N</DelayReport> <TransferReport>N</TransferReport> <SaveSent>N</SaveSent> <FilePoll>120</FilePoll> <ServerPoll>15</ServerPoll> <ServerRetry>3</ServerRetry> </DTSConfig>

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 1 Submitter: Richard Corbridge ..................................................................................................... 1

Sponsorship: Gwyn Thomas ............................................................................................................. 1 1. 2 3 Introduction............................................................................................................................. 1 Compliance with Requirements for Strategic Information Standards..................................... 2 Strategy Overview ................................................................................................................... 2

Appendix 1 e-GIF specification for cryptographic algorithms ..................................................... 7 Appendix 2 Delivering 21st Century IT Support for the NHS - National Strategic Programme (Section 3) ........................................................................................................................................ 8 Appendix 3 Statement of Approval for Technical Security Aspects of Data Transfer Service from NHS Information Authority Security Board (January 2003 Board Meeting) ................................. 10 Appendix 4 Data Transfer Service Functional Specification (version 1.2) ................................. 11 INTRODUCTION 13

Background ........................................................................................................................................ 13 Service Summary ............................................................................................................................... 13 DTS CLIENT 14

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

DTS Server Send ................................................................................................................................ 23 DTS Server Receive ........................................................................................................................... 25 DTS ADMINISTRATION 27

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

REFERENCES GLOSSARY CONFIGURATION CONTROL

30 30 31

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

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

Background ........................................................................................................................................ 35 DTS Client Overview...................................................................................................................... 35 DTS CLIENT FILE INTERFACE 36

Directory/File Structure ...................................................................................................................... 36 File Interface ...................................................................................................................................... 36 Transaction Sequence Identifier ..................................................................................................... 37 Control File .................................................................................................................................... 37 File Interface Maintenance ............................................................................................................ 39 DATA TRANSFER 40

OUT Transactions .............................................................................................................................. 40 IN Data Transactions ..................................................................................................................... 41 IN Status Transactions ................................................................................................................... 42 REFERENCES GLOSSARY CONFIGURATION CONTROL 45 45 46

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

Appendix 6 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 Technology ................................................................... 48

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 specified recipient. Receive Application data from the central DTS Server for delivery to the local Application. 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.

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; <DTS Client root> IN OUT TEMP SENT The <DTS Client root> 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 status information to be received by the Host Application. The OUT directory will be used by the HOST Application to copy data to be sent by 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 <siteid><APP><sequence_id>.dat Control File - <siteid><APP><sequence_id>.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 - <siteid><APP><sequence_id>.ctl

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 <siteid> and <APP> will uniquely identify the data transfer files, <siteid> will uniquely identify the client site. The DTS Client userid should be used for this value. <APP> 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 applied by 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.

DATA ITEM Version AddressType MessageTyp e

VALUES/ SIZE 1.0 SMTP Data Report

MANDATOR Y/ OPTIONAL M M M

DESCRIPTION

Version of Control File Identifies the type of Address. SMTP only initially. Identifies the type of Transfer Data will have a data file and a control file. Report will have a control file.

From

SMTP address SMTP address SMTP Subject 255 characters

To

Subject LocalId

O O

Identifies the originator of the Data Transfer. SMTP address of the originator. Identifies the recipient of the Data Transfer. SMTP address of the recipient. Subject of the Data Transfer as for SMTP email subject. 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 Each Data Transfer will be associated with a DTS Identifier as it passes through the DTS Server. This will allow for correlation with local and partner ids. If specified, the identifier (or SMTP message id) from received Data Transfers. Flag to indicate that the Data File can be compressed by the Client. Default NO Flag to indicate that the Data File has been encrypted by the Host Application. 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. For future use. Identifier to specify the type of processing that might be required before forwarding to the recipient. Field to be used for a checksum for the Data file.

DTSId

100 characters

PartnerId

255 characters Y N

Compress

Encrypted

Y N

WorkflowId

32 characters

ProcessId

32 characters

DataChecksu m

IsCompresse d StatusRecord

Y N

Field to indicate that the Data file is compressed. Status information on the status of the Data Transfer. This will contain the following information; Date Time Event Status Success or Error Status Code Description

File Interface Maintenance

There is a need for the files in the File Interface directories to be managed. 1. IN The DTS Client will copy received Data Transfer files and report files to the IN 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. OUT DTS 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 SENT directory. i.e. to use, delete or archive the data files. 5. TEMP The TEMP directory is private to the DTS Client, the DTS Client will manage the contents of the directory.

Data Transfer
The Control File will contain different information depending on the circumstances. The following sections describe the different contents for the following 1. Out Transaction Host Application sends data via Client 2. In Data Transactions - Host Application receives data via Client 3. In Status Transaction Client 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 VALUES/ MANDATOR DESCRIPTION ITEM SIZE Y/ OPTIONAL Version M Version of Control File 1.0 AddressType MessageTyp e From To Subject LocalId SMTP Data M M Type of Address. Identifies the type of Transfer, the OUT Transaction will have a data file and a control file. SMTP address of the originator. SMTP address of the recipient. Subject of the Data Transfer as for SMTP email subject. Local Identifier of the Data Transfer. This is specific to the Host Application sending via the Client. Not applicable in the OUT Transaction. Not applicable in the OUT Transaction. Optional flag to indicate that the data file can be compressed. Optional flag to indicate that the data file is encrypted. Optional Flag indicating the workflow, e.g. IOS.

SMTP address SMTP address SMTP Subject 255 characters

M M O O

DTSId PartnerId Compress Y N Encrypted Y N WorkflowId 32 characters

O O O

ProcessId

32 characters

DataChecksu m IsCompresse d StatusRecord

O O O

Optional Flag indicating processing to be performed at the DTS Server. For Future use. Not applicable in the OUT Transaction. Not applicable in the OUT Transaction. 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 VALUES/ MANDATOR DESCRIPTION ITEM SIZE Y/ OPTIONAL Version M Version of Control File 1.0 AddressType MessageTyp e From To Subject LocalId DTSId 100 characters SMTP Data M M Type of Address. Identifies the type of Transfer, the IN Data Transaction will have a data file and a control file. SMTP address of the originator. SMTP address of the recipient. Subject of the Data Transfer as for SMTP email subject. Not applicable in the IN Data Transaction. DTS Identifier for the Data Transfer. This can be used to identify the Transfer for Tracking purposes. Partner identifier of the Data Transfer. This is specific to the Host Application sending the data. E.g. SMTP message Identifier. Not applicable in the IN Data Transaction. Not applicable in the IN Data Transaction. Optional Flag indicating the workflow, e.g. IOS.

SMTP address SMTP address SMTP Subject

M M O O O

PartnerId

255 characters

Compress Encrypted WorkflowId 32 characters

O O O

ProcessId DataChecksu m IsCompresse d StatusRecord

O O O O

Not applicable in the IN Data Transaction. Not applicable in the IN Data Transaction. Not applicable in the IN Data Transaction. Status information on the status of the Data Transfer. Date Time Event - Delivery Status Success

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 : Optional Status 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 will retry. 4. Transfer Fail : DTS Client has failed to transfer to DTS Server and has aborted the transfer 5. TransferReport : Optional DTS Client has successfully transferred to the DTS Server 6. Server Fail : DTS Server failed to transmit the data. 7. Poll Fail : Optional DTS Client has attempted to poll the DTS Server but has failed. 8. PollReport : Optional - DTS Client has polled the DTS Server successfully. 9. Non Delivery : Negative Delivery Service Notification received from SMTP service. 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.

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 VALUES/ MANDATOR DESCRIPTION ITEM SIZE Y/ OPTIONAL Version M Version of Control File 1.0 AddressType MessageTyp e From SMTP Report M M Type of Address. Identifies the type of Transfer, the IN Status Transaction will Control File. 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 SMTP address of the recipient. From the original OUT Transaction Control File. This will not be specified for the Poll Fail and Poll report status reports Subject of the Data Transfer as for SMTP email subject. From the original OUT Transaction Control File, if specified. This will not be specified for the Poll Fail and Poll report status reports From the original OUT Transaction Control File. This will not be specified for the Poll Fail and Poll report status reports DTS Identifier for the Data Transfer. This will only be specified if the Status Report comes from the DTS Server. Not applicable in the IN Status Transaction. Not applicable in the IN Status Transaction. Not applicable in the IN Status Transaction.

SMTP address

To

SMTP address

Subject

SMTP Subject

LocalId

255 characters

DTSId

100 characters

PartnerId Compress Encrypted

O O O

WorkflowId

32 characters

From the original OUT Transaction Control File if specified. This will not be specified for the Poll Fail and Poll report status reports. Not applicable in the IN Status Transaction. Not applicable in the IN Status Transaction. Not applicable in the IN Status Transaction. 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

ProcessId DataChecksu m IsCompresse d StatusRecord

O O O O

References
4. 5. 6. Data Transfer Service Proposal Data Transfer Service Functional Specification EDI Gateway Functional Specification Issue 1.0 Issue 1.0 Issue 1.0

Glossary
TERM DNS DR DSN DTS EDI MIME MTA MTSID NDR SMTP DESCRIPTION Domain Name Service Delivery Report Delivery Service Notification Data Transfer Service Electronic Data Interchange Multipurpose Internet Mail Extensions Message Transfer Agent Message Transfer Service Identity Non Delivery report Simple Message Transfer Protocol

Configuration Control
Sector/Customer Unit: Health Project: NHS Message Service
Data Transfer Service A84201F

Authors: Phil Reed Responsible Authority: Mike Smithson

Version: 1.2 Status: Draft Date of last 31 August 2010 change:

Syntegra 2010

Change details
Section
All All Section 2 1 1.1 1.2

Issue

Owner
Phil Reed Phil Reed Phil Reed

Date
20-12-2002 15-1-2003 21-1-2003 Issue 1 Issue 1.1

Details of change

Changes to file name format requested by NHSIA

APPENDIX A - DTS Control File XML Format Example

<DTSControl> <Version>1.0</Version> <AddressType>SMTP</AddressType> <MessageType>Data</MessageType> <From>exeter99@dts.nhs.uk</From> <To>edi.G12345@trust.nhs.uk</To> <Subject>EDI Data</Subject> <LocalId>Exeter99-20021216101210</LocalId> <DTSId>DTS 20021216101210-927652</DTSId> <PartnerId></PartnerId> <Compress>Y</Compress> <Encrypted>N</Encrypted> <WorkflowId>Exeter-GP-IOS</ WorkflowId> <ProcessId></ProcessId> <DataChecksum></ DataChecksum> < IsCompressed >Y</ IsCompressed > <StatusRecord> <DateTime>20021216102012</ DateTime> <Event>Transfer to DTS Server</Event> <Status>Success</Status> <StatusCode>0</StatusCode> <Description></Description> </StatusRecord> </DTSControl>

Appendix 6 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 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 Stephen To: 'Robino@ase.co.uk' Cc: Corbridge Richard ; Reid Scott Sent: Monday, May 19, 2003 6:28 PM Subject: FW: Support letter from the DA Robin, Please see the email thread below, your name has been forwarded onto me in reference to getting a viewpoint from the Design Authority about the Data Transfer Service that is currently being prepared for implementation within the service. What I am hoping to arrange is for someone from the Design Authority attend a demonstration 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 produced about the DTS, giving a viewpoint of how this service fits into the wider plans of the National Programme. This statement is being requested by the Information Standards Board in relation to a submission the DTS Project has made to ISB for this new service. Can you help, and if yes when would be a convenient time for you to attend a demonstration 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 of Approval for the DTS (with particular reference to the strategic future plans for the NHS-wide Clearing Service).

Richard, I am now able to provide the positive response that you require, from the Design Authority, to move 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 reprocurement 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 Richard Sent: 08 June 2003 10:00 To: Powell Steve; 'Andy.truscott@npfit.nhs.uk'' Cc: Humphries Stephen Subject: RE: Support letter from the DA Importance: 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 appropriate strategic solution to allow the NWCS service to migrate from the X.400 service in the appropriate time scales. These words need only indicate the current NWCS service and the current DTS service and need 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 the X.400 service, you may remember that this is extremely expensive and to the limit of its legality. Any help you can offer in this, we have 6 million monthly messages to migrate in just 150 days. Many thanks Richard Corbridge