draft submission
TRANSCRIPT
-
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.
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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 -
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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
REFERENCES 44GLOSSARY 44CONFIGURATION CONTROL 45
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
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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.
-
8/3/2019 Draft Submission
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
O 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
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
O Parameter controlling the
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
-
8/3/2019 Draft Submission
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].
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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.
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 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.
An entry will be made in the local log file with the success or
-
8/3/2019 Draft Submission
19/49
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 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.
-
8/3/2019 Draft Submission
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.
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.
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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
will complete the transfer.
If the Client is in the process of receiving a data transmission it
will complete the transfer.
-
8/3/2019 Draft Submission
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.
-
8/3/2019 Draft Submission
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
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
StatusFailure
-
8/3/2019 Draft Submission
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.
-
8/3/2019 Draft Submission
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
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)
ActionTransfer to recipient mailbox
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
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)
ActionTransfer to recipient mailbox
StatusFailure
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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.
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
34/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 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
REFERENCES 45GLOSSARY 45CONFIGURATION CONTROL 46
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
-
8/3/2019 Draft Submission
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.
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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.
-
8/3/2019 Draft Submission
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.
-
8/3/2019 Draft Submission
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.
-
8/3/2019 Draft Submission
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
Version 1.0 M Version of Control File
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
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.
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.
-
8/3/2019 Draft Submission
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
Version 1.0 M Version of Control File
AddressType SMTP M Type of Address.
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
M SMTP address of the recipient.
Subject SMTP
Subject
O Subject of the Data Transfer as for
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
Transfer. This is specific to the
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.
-
8/3/2019 Draft Submission
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.
-
8/3/2019 Draft Submission
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
Version 1.0 M Version of Control File
AddressType SMTP M Type of Address.
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
M SMTP address of the recipient.
From the original OUT Transaction
Control File.
This will not be specified for
the Poll Fail and Poll reportstatus reports
Subject SMTP
Subject
O Subject of the Data Transfer as for
SMTP email subject. From theoriginal OUT Transaction Control
File, if specified.
This will not be specified for
the Poll Fail and Poll report
status reports
LocalId 255
characters
O From the original OUT Transaction
Control File.
This will not be specified for
the Poll Fail and Poll report
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.
-
8/3/2019 Draft Submission
44/49
WorkflowId 32
characters
O From the original OUT Transaction
Control File if specified.
This will not be specified for
the Poll Fail and Poll report
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
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
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
-
8/3/2019 Draft Submission
47/49
APPENDIX A - DTS Control File XML Format Example
1.0
SMTP
Data
EDI Data
Exeter99-20021216101210
DTS20021216101210-927652
Y
N
Exeter-GP-IOS
< IsCompressed >Y
20021216102012
Transfer to DTS Server
Success
0
-
8/3/2019 Draft Submission
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] -
8/3/2019 Draft Submission
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