emsdocs

This document is commercial-in-confidence. The recipient of this document agrees to hold all information presented within as confidential and agree not to use or disclose, or allow to use or disclosure of the said information to unauthorized parties, directly or indirectly, irrespective of the acceptance or rejection of the presentation or at any time before, during or after an agreement has been reached, without prior written consent.

HL7 Messaging & Integration with EMS

Document History

Version	Date	Who	Notes
v0.1 - Draft	20/04/2021	Lee Dyson	First draft
v0.2 - Draft	21/04/2021	Lee Dyson	Fix typos, and feedback from ric@medilogik
v1.0 - Release	28th June 2021	Robert McNaught	Consistency updates
v1.1 - Release	30th June 2021	Robert McNaught	amended plantuml section
v1.2 - Release	16th Jul 2021	Robert McNaught	Disclaimer
v1.3 - Release	29th Sept 2021	Robert McNaught	Formatting and fixes

• HL7 Messaging \& Integration with EMS
  • Document History
  • Background
  • HTTPS
  • VPN
  • Standards
  • Typical Scenario
    • Message Format
    • ACKS
    • Message Stream
  • Environments
  • Network Considerations
  • Endpoints
  • Security
    • IP Address Ranges
    • Certificate-based Authentication
  • Typical Implementation Steps
    • 1. Establish Network Environment
      • MEDILOGIK
      • Customer
    • 2. Agree EMS Implementation Model
      • Basic Scenario
      • Extended Scenarios
    • 3. Agree Messaging Specifications
  • Reference Specifications

Background

Traditional HL7 v2.x uses a standard TCP socket connection. i.e. the message sender (client) system opens a connection to the recipient (server) system, to send a message. It is common practice for the client to leave the TCP socket open, and for subsequent messages to be sent over the existing established connection.

Individual messages are enveloped in special framing characters. This is know as MLLP - Minimum Lower Level Protocol. MLLP does support traffic over TLS encrypted connections, however, MLLP connections within an organization’s internal private LAN, MLLP connections are usually not encrypted.

MEDILOGIK’s EMS web application is hosted in an NHS approved data centre with full access to the Internet and NHS HSCN network. Cloud EMS users access the hosted version of the application with a web-browser over an HTTPS connection - i.e. all traffic between EMS and the user is encrypted.

Similarly, MEDILOGIK employ secure HTTPS connections to handle all messaging traffic between a customer site and EMS.

A typical EMS integration scenario is illustrated in the diagram below. Messaging is usually handled by the customer’s Integration Engine (often referred to as a TIE - Trust Integration Engine in NHS settings).

Without going into the specifics of HL7 message Type, and message Content, this document describes the integration environment of a typical EMS Cloud implementation.

HTTPS

When client and server are on different networks (for example when separated by the N3, HSCN, Internet, or other WAN), additional measures must be implemented to ensure that HL7 messages are encrypted in transit.

Additionally as messages are being sent to a remote server, the sending application needs to know that they are sending their messages to the correct intended recipient application. Likewise, the recipient applications needs to know that a message received was sent by a recognized and authorised sender.

HTTPS as a transport provides a number of benefits which make it more suitable for securely carrying traffic across a public network:-

• Encryption Each HTTP request is individually encrypted - negating the need for a point-to-point VPN tunnel
• Authorization & Authentication - Client and Server certificates prove the identity of each end party. Sender and Recipient are cryptographically guaranteed to each other.
• Firewall & Proxy friendly connectivity. Most internet/web traffic is carried over HTTPS. As such, existing network infrastructure and security practices can be applied to HL7-over-HTTPS. HL7-over-HTTPS is easily connected through firewalls, and organizations’ existing proxy servers.

The use of HL7 over HTTPS is increasingly common in the NHS, the large hosted EPR systems (e.g. Lorenzo) use HL7-over-HTTPS, and as HL7-FHIR based interfaces become more common, the use of HTTPS as a transport for messaging will likely become the default.

The ability to send HL7 message over HTTPS is native to most messaging / integration engines. Intersystems Ensemble, Orion Rhapsody, NextGen Mirth , Microsoft Biztalk etc all NATIVELY support HL7 over HTTPS.

VPN

MEDILOGIK do not support point-to-point VPN connections for messaging traffic.

• Point-to-point VPNs can be difficult to setup and maintain.
• Require customer-specific customization, hence do not scale well at the MEDILOGIK side.
• Actively consume resources at sender and recipient routers and firewalls, even when idle.

Standards

• https://hapifhir.github.io/hapi-hl7v2/hapi-hl7overhttp/specification.html

• https://www.hl7.org/fhir/security.html#http

Typical Scenario

Message Format

• Messages are in plain HL7v2.4 format (i.e. caret-and-pipe), with a few minor concessions to the use of HTTPS transport.
• Message segments are terminated with CR
• HL7 framing characters (28/11) are NOT required, as the body of the HTTP request itself provides framing.
• At a transport level, standard HTTP Response Semantics are employed
• Where the message body is received and processed as an HL7 message, then the recipient will return a HTTP 200/OK response code with an appropriate HL7 ACK message in the response body.
• Other HTTP response codes (4xx or 5xx) are used to indicate that the message was not processed as a HL7 message, due to some other error (e.g. unexpected error condition on server, or unrecognized message format from sender). In this case, the HTTP response body may not contain a valid HL7-NAK message.

ACKS

ACKS are end-to-end into EMS

The EMS integration server will return an application-level ACK/NAK from EMS itself. i.e. Any ACK message received from EMS means that the message has been delivered and processed into EMS.

Message Stream

Due to the normal behaviour of HTTP over TCP/IP connections and the possilbity of the sender being a multi-threaded client, it is possible for individual HL7 messages sent over HTTPS to be routed via different network paths and to arrive at the recipient out of sequence.

To enforce message sequence, the sender MUST ensure that subsequent messages are NOT sent until an ACK message has been received for the previous message. Ensemble, Rhapsody, Mirth and BizTalk all have the requisite functionality to support this single-threaded ACK/NAK behaviour.

Environments

MEDILOGIK typically setup a TEST and a PROD environment for each customer. These are completely separate and distinct:

• Separate interface servers
• Separate applcation servers
• Separate database servers
• Separate IP addresses, firewall rules and routing.

Network Considerations

Messages INTO EMS are typically transported across the Internet into the EMS Azure Data Centre.

Messages FROM EMS INTO the Trust can be sent via the Internet, but many Trusts prefer that incoming messages arrived via the HSCN network. This is the default method of connection from EMS to the customer’s TIE for Results messages.

All messages between EMS and the customer’s TIE are HTTPS / TLS encrypted.

Endpoints

Messaging endpoints for messages into EMS are of the form:-

• https://XXXX.api.medilogik.cloud/ for the PROD environment
• https://XXXX-test.api.medilogik.cloud/ for the TEST environment.

where XXXX is the customer short code assigned by MEDILOGIK.

Security

All messaging traffic is carried inside HTTPS transport and as such messages are encrypted as they transit the networks between the Trust’s private LAN and the MEDILOGIK servers in an Azure data centre.

IP Address Ranges

During the early stages of the project, the network teams will agree IP address ranges to be used for messaging traffic. It is the responsibility of each party to ensure that messaging traffic is only permitted from pre-agreed IP address ranges, and that suitable controls are in-place to prevent un-authorized parties from connecting to these endpoints.

Certificate-based Authentication

In addition to Firewall rules based on IP address ranges, messaging with EMS can also authenticated via the use of SSL certificates.

• In each transaction, the SERVER (i.e. the message recipient, or listening party) will expose a valid server certificate.
• The CLIENT (i.e the message Sender ) will present a valid recognised client certificate.
• The server must refuse incoming connections from clients who do not present the correct client certificate

Hence both client and server can be assured of the identity of the other party.

Typical Implementation Steps

1. Establish Network Environment

MEDILOGIK

• Create customer short code, and DNS entries for messaging endpoints
• Provide customer with inbound URL (EMS receives HL7 messages)
• Spin up TEST ADT interface
• Provide customer with outbound HSCN IP address range (EMS sends HL7 messages from here)
• Spin up TEST Results interface

Customer

• Create https: endpoint URL for receipt of messages from EMS - this must be visible and accessible from the HSCN
• Expose “valid” Server cert for TIE - cert needs to agree with DNS name of the server
• Local firewall change to allow traffic IN from EMS cloud to TIE URL
• Local firewall change to allow traffic OUT from the local TIE to EMS messaging service

2. Agree EMS Implementation Model

EMS supports a number of messaging models depending upon the customer’s business flows and their PAS / EPR messaging capabilities. This will have been discussed and agreed during the EMS sales process.

At it’s simplest, EMS’s Basic configuration supports inbound ADT messages and outbound reports.

Basic Scenario

• ADT “Demographic” messages from PAS to EMS - ADT^A28,A31,A40
• ORU “Results” messages from EMS to PAS - ORU^R01 with PDF content

Extended Scenarios

• PAS Scheduling, appointments are managed on PAS and HL7 SIU messages sent to EMS
• Referrals Only, appointments are managed in EMS initial referral HL7 REF messages sent to EMS
• Order Comms - Results + Statuses - ORM, OMG, ORR, ORU HL7 messages bi-directional with full support for EMS vetting + appointment booking

All three extended scenarios result in a ServiceRequest being made to EMS. The ServiceRequest has a minimum dataset that MUST be met in order to use the interface. Population of the data is not sufficient, the data must be accurate and reflect the PAS and EMS configurations.

There are two outcomes from the ServiceRequest:

• the request gets to the ‘vetting’ stage of an episode within EMS.
• the request gets to the ‘daily list’.

3. Agree Messaging Specifications

HL7 message types and field-by-field message specifications.

Reference Specifications

The following specification documents describe specific message formats and contents in more detail

• EMS Standard Segment Definitions
• ADT Specification
• Order Comms Specification
• Referrals Specification
• Scheduling Specification
• Outbound Results Specification
• TrakCare -> EMS Referral Message Handling
• Default Reference Data
• EMS Minimum Dataset for Extended Messaging