1. Emergency Care Data Set (ECDS)
Systems Supplier Show and Tell March 2017
Aaron Haile, ECDS engagement lead (Royal College of Emergency Medicine)
Peter Sherratt, ECDS implementation lead (NHS Digital)
Tom Hughes, ECDS Lead Clinician (Royal College of Emergency Medicine)
Stuart Baskerville, Simon Richards, Sarga Moore – MESH Team (NHS Digital)
Version: v0.1.1
The ECDS project is a collaborative project between the Department of Health, the Royal College of Emergency Medicine, NHS England, NHS Digital, NHS Improvement, NHS Providers and Public Health England. This document has been produced on behalf
of the ECDS Project Board in collaboration with the organisations listed above.

2. Before we start Next webinar focused on Suppliers is 29th March @ 2pm.
We’ve enabled “PC audio” so you can listen on your PC speakers as well as phone
We are recording the webinar for the benefit of others
Previous (provider) webinars have been recorded and links are available
We’ll be going through some things in more detail on this call
General update
MESH
National Tariff considerations (high level) QA
Most people will be muted – please send your comments and questions via the WebEx chat function, or raise your hand
We’ll share the following after the meeting:
The slides
The links to the recordings
The transcript of the QA session along with written answers
Next webinar focused on Suppliers is 29th 2pm.
Send your comments to :

3. Quick progress update
The SCCI process is on track for ISN publication – mid-April 2017
The XSD file has now been assured and will be published in the next couple of weeks
Any feedback – let us know now
We’ll re-issue the draft XSD files as some people had problems with the original .RAR file
Results of the Provider webinar
The poll gave us 89.6 “confidence weighted” departments and an average confidence of 58.38% (up nearly 3%) which would translate to about 140 EDs if consistent throughout England.
That’s based on a much bigger sample size of 75 Trusts covering 160 EDs, meaning over 40% of all Trusts gave us an answer.

4. What is MESH?
MESH is a secure application-to-application messaging service
Message Exchange for Social Care and Health
NHS Digital developed and managed service
Functional replacement for DTS
Use of robust, secure and modern Spine Core infrastructure
Messaging Exchange for Social Care and Heath which is a replacement for the BT managed Data Transfer Service. This was the last part of the BT Spine Contract, which has now ended.
MESH has been developed by the HSCIC Digital Delivery Centre – which oversees a number of key national applications and infrastructure for health and social care IT including SUS and Spine.
Functionally equivalent to DTS, although has increase validation such as individual client certificates.
Uses the Spine Core infrastructure which means active/passive resilience, transparent failover, auditing and Spine Core support

5. Key facts about MESH 13+ million messages exchanged every month
7500 active accounts
9000+ organisations
NHS Digital Service
Use of robust, secure and modern Spine infrastructure
Expanded uses
Usage stats increasing every month

6. Who uses MESH?
The main users of MESH are general practices and pathology departments
Other users include:
Exeter systems
National screening services
National services e.g. CQRS and GPES
111 services
Ministry of Defence sites
Transfer of Care (discharges)
GPs and pathology departments account for 60 per cent of all DTS traffic
Most service users have their DTS arrangements managed by their system supplier, a small minority don’t, and we are engaging directly with these organisations and providing support

7. DTS/MESH user types
We can categorise service users into three main types.
System suppliers
Service users (who have their DTS/MESH arrangements managed by their supplier)
Service users who manage their own DTS/MESH arrangements

8. How does MESH work? Messages comprises Maximum file size up to 100Mb
Control (.ctl) file – addressing information
Attachment (.dat) file – renamed attachment
Maximum file size up to 100Mb
MESH client controls delivery
Polls MESH mailbox
Simple delivery mechanism
Out folder for sending
In folder for receiving
Delivery/non-delivery reports generated
Simple message format – comprises 2 files – Control and DAT files – Control defines the routing of the message, the DAT is the payload e.g. Word document renamed to .DAT
Current maximum size limit is 100Mb for the DAT file, but developing MESH to handle larger files.
Simple polling mechanism – polls every 10 minutes to check for files to download and send. Can handle multiple mailboxes in a single installation.
MESH client – Files to send are placed into the OUT folder - <message>.ctl and <message>.dat
Files downloaded are placed in the IN folder.
Includes the ability to generate delivery and non-delivery reports
Uncollected files are deleted after 5 days and a NDR sent to the originator

9. MESH – Future State N3 Internet Facing MESH Server Direct API Lab
MESH Client
MESH Client
GP Practice
TLS
TLS
Animation of how MESH works.

10. Introducing the MESH client
Java based client (JVM 1.7)
SSL mutual authentication using Java Keystore
Supported on Windows server and client, Linux, Solaris, SCO, AIX, HP-UX
Wizard-based installation
Automatic Updates
Command-line support
Can be run as a Windows service
MESH will re-use the DTS mailbox settings so DTS addressing will work.
Requires a Java Virtual Machine to be installed.
Supported on OSs that have a JVM of 1.7 or later (although does work with 1.6) . Linux now supported.
Wizard-based installation that prompts user for the DTS installation location to re-use the folders.
Supports auto-update mechanism that will update the MESH client if a new version is available
MESH client launched from the command line in the same way as the DTS client and can therefore be run as a service under windows.

11. Installation pack
Pack Contents
Wizard install tool
Installation guide
Certificate management
Running as a service
Interface Spec
WorkflowID guidance
Example config file

12. MESH Server API New feature with MESH HTTP based API
Enables suppliers to integrate directly with MESH
Replaces MESH/DTS client
EMIS first live deployment
Specification available
Exposing the API used by the MESH client to send/receive
Enables Systems to talk directly to MESH without the need for a client

13. MOLES MESH OnLine Enquiry Service (MOLES)
Functional replacement for DTS Registration and Tracking Service (RATS)
Smartcards required to access the service
User/organisation administration
Message Tracking, Trading Partner Report, Mailbox Lookup
API
Usernames and Passwords will be transferred to MOLES as will the organisational information.
Current RATS functionality will be transferred to MOLES and will allow user/mailbox administration and message tracking.
Message tracking API will also be supported for querying message statuses.

14. Testing Environment Available for Testing Testing of:
MESH client
DTS client with the adapter ( to be withdrawn)
MOLES
Message Tracking API
MESH Server API
Further details at
Issues raised via the SA Service Desk –
Testing is key:
MESH client testing – ensuring the client systems work the same way as DTS
DTS client – ensure the DTS Adapter works in the same way as DTS
Moles – Familiarise yourself with the new interface
Message Tracking API – integration with existing systems
MESH Server API – suppliers wanting to test the new API to send/receive messages without the need for the client

15. Migration Progress DTS to MESH
Central Service migrated from BT in January 2016
Initial deadline for transfer 30 June
Decommissioning period July to 30 September
DTS Adapter closed 1 October
IP Whitelist process instigated to limit and control access
Extended use requires specific individual approval
All new installations via MESH Client or API
@ 3rd October 95% complete
Testing is key:
MESH client testing – ensuring the client systems work the same way as DTS
DTS client – ensure the DTS Adapter works in the same way as DTS
Moles – Familiarise yourself with the new interface
Message Tracking API – integration with existing systems
MESH Server API – suppliers wanting to test the new API to send/receive messages without the need for the client

16. MESH Roadmap
MESH client support for larger files using file chunking (20Gb)
MESH Endpoint Lookup
Web interface to find MESH mailbox
RESTful API interface available
Initially ODS Code and WorkflowId (message type)
Expanding to NHS Number and D.O.B
MESH Internet Gateway
Extends use to Internet access
MESH User Interface
Webmail style interface to MESH
N3 access via smartcard
Internet access via one time passcode
Looking at new developments for MESH:
Looking at supporting file chunking to support larger files – would need to know volumetrics on this before suppliers start using this – available in August with a new MESH client
EndPoint Lookup – available within MOLES and as an API for suppliers to integrate too – allows MESH mailboxes to be searched via ODS (Org code) and WorflowID
MESH Internet Gateway – extends the accese to MESH/MESH API on the Internet – available in the next couple of months
MESH UI – provide a webmail style interface for non-technical users to send/receive messages via MESH – generates the control and DAT file in the background, provides MOLES message tracking in the same UI
Available on both N3 and Internet – available end of 2016

17. MESH User Interface Looking at new developments for MESH:
Looking at supporting file chunking to support larger files – would need to know volumetrics on this before suppliers start using this – available in August with a new MESH client
EndPoint Lookup – available within MOLES and as an API for suppliers to integrate too – allows MESH mailboxes to be searched via ODS (Org code) and WorflowID
MESH Internet Gateway – extends the accese to MESH/MESH API on the Internet – available in the next couple of months
MESH UI – provide a webmail style interface for non-technical users to send/receive messages via MESH – generates the control and DAT file in the background, provides MOLES message tracking in the same UI
Available on both N3 and Internet – available end of 2016

18. Summary Simple interface for sending/receiving messages
Live now – handles 13m+ message per month
Different client solutions available
24x7 support
Planned roadmap of product development
As discussed.

19. ECDS Q&A Feedback Technical Output Spec changes
January addendum updates have now been made and covered the following:
Updated definitions
Some formats have had ‘min’ and/or ‘max’ added e.g. all SNOMED codes are now ‘min n6 max n18’
Format change to some ODS codes, from ‘min an5 max an9’ to ‘min an3 max an5’
Data item specific changes are outlined in the Jan – March 2017 Addendum which we will circulate
EMERGENCY CARE PLACE OF INJURY (LATTITUDE AND LONGITUDE) has been split into two data items
CLINICAL TRIAL IDENTIFIER & DISEASE OUTBREAK NOTIFICATION are now grouped under there own group ‘ Research and Outbreak Notification’
Question – Now that changes have been made following schema testing is it useful to share v6.2 of the ECDS or should we wait until we publish the ISN in April?
2. Mandated & Required data items
All mandated items in the schema will need to flow as part of CDS Type 011 else the submission will fail validation
Some ‘Required’ fields must also be submitted from October 2017 to satisfy the CQUIN. These fields are:
EMERGENCY CARE ACUITY (SNOMED CT) /
EMERGENCY CARE CHIEF COMPLAINT (SNOMED CT)
EMERGENCY CARE DIAGNOSIS (SNOMED CT) (including CODED CLINICAL ENTRY SEQUENCE NUMBER and DIAGNOSIS QUALIFIER)
PROFESSIONAL REGISTRATION ENTRY IDENTIFIER/ PROFESSIONAL TIER (EMERGENCY CARE) & CARE PROFESSIONAL DISCHARGE RESPONSIBILITY INDICATOR (EMERGENCY CARE) to identify the Discharging clinician
EMERGENCY CARE ATTENDANCE SOURCE (SNOMED CT)
EMERGENCY CARE DISCHARGE STATUS (SNOMED CT)

20. ECDS Q&A continued… 3. Use of flags 4. Discharge fields
Chief Complaint and Diagnosis code sets also include flags for certain information. These flags are designed to support implementation and use of the data set by ‘flagging’ certain information to note, please see below:
Injury – Whether the chief complaint or diagnosis is likely to be the result of an injury, indicates that the injury data items should be collected.
Male/Female – Whether specific conditions are specifically male or female to avoid data quality issues e.g. pregnant males
Ambulatory Emergency Care (AEC) – these are conditions that map to the current list of diagnoses that are suitable for ambulatory care.
Notifiable Disease – Indicates that this is a Notifiable disease and should be restrained
Allergy – these conditions are associated with allergic reactions and would help trigger the ED IT system to collect and send information about possible allergy cause as part of the discharge summary / electronic message.
4. Discharge fields
The previous CDS field ‘A&E Disposal code’ conflated discharge information and this has now been broken down into three individual items to provide more accurate information relating to outcomes and where patients go after the ED:
Emergency Care Discharge status – Captures whether treatment took place within the ED, if the patient was streamed to another service (NHSE update from last week regarding GP streaming) or if the patient left before treatment was complete.
Emergency Care Discharge Destination – Identifies the intended destination of the patient following discharge from the Emergency Care Department such as ‘Home’, ‘Ward’ or ‘AEC’.
Emergency Care Discharge Follow up – Identifies the specific service to which a patient was referred for continuing care following an Emergency Care Attendance such as ‘GP’, ‘Community Psych Services’ or No referral’.

21. Send your comments to : ECDS@nhs.net
Before we finish
What timescales are XML brokers working to for going through the assurance process?
Tell us what’s driving your timescales and what could potentially be done to help if necessary
Release of ECDS spec 6.3
Final XML file set
3. We are looking to identify early adopter sites which would go live during September and potentially even as early as August 2017
Come back to us if you have any sites that are interested
4. Are there any particularly difficult parts of the spec you’re struggling with?
Send your comments to :

22. Future webinars….
Future topics will include:
The transition period
Guidance materials that will be available
The early adopters scheme
Let us know anything particular you’d like us to cover again or in more detail
Next webinar focused on Suppliers is 29th 2pm
Send your comments to :