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.
EMS Standard Results Messaging
Document History
| Version | Date | Who | Notes |
|---|---|---|---|
| v0.1 - Draft | 5th Dec 2017 | Lee Dyson | First draft. |
| v0.2 - Draft | 7th June 2021 | Lee Dyson | Typos. |
| v1.0 - Release | 28th June 2021 | Robert McNaught | Consistency updates |
| v1.1 - Release | 16th Jul 2021 | Robert McNaught | Disclaimer |
| v1.2 - Release | 29th Sept 2021 | Robert McNaught | Formatting and fixes |
| v1.21- Release | 25th October 2021 | Lee Dyson | MDM details |
Introduction
EMS Results messages are based on a standard HL7 v2.4 interpretation of the ORU^R01 Unsolicited Result message.
A good definition of the standard message types can be found at ORU 2.4 Caristix
As EMS uses the open-source “HAPI” libraries to create HL7 messages, the HL7 data-types employed in each field are true to the formal definition.
Results messages produced by EMS are actually FHIR R4 DiagnosticReport messages. EMS’s integration server translates the FHIR message into an HL7 v.24 ORU^R01 message. Standard HL7 “pipe-and-caret” messaging is more widely supported by NHS Trusts than the more recent (and more volatile) FHIR messaging standard.
The EMS integration service delivers ORU^R01 messages (typically) to the customer’s TIE. Once the message have been delivered to the TIE (and ACK’d by the TIE), the customer is free to route this message onwards to internal document consumers (e.g. EDMS systems, clinical portals, Docman / EDT, Sci-Store etc.)
The interface can also be configured to produce output documents as MDM^T02 messages in place of the default ORU^R01 messages.
Message Flow
Message Structure
[] - Optional
{} - Repeating
ORU
MSH
PID
[PD1]
PV1
[ORC]
OBR
{OBX}
MDM
MSH
EVN
[PD1]
PID
PV1
TXA
OBX
Sample ORU Result Message
MSH|^~\&|EMS|TEST|COMPUCARE|TEST|20190226140143||
ORU^R01^ORU_R01|78f5fbb07ed24678a4a1|P|2.4|||AL
PID|||CA7230505^^^RJ7^MRN~1234567890^^^NHS^NH||Officer^Alisha||19201020120000||||195 Cheesecake Road^^^^JB9 4HB
ORC|SC|MLEMS_146958|||CM
OBR|1|MLEMS_146958|MLEMS_146958|Colon
OBX|1|ED|Colon||EMS^application/pdf^^BASE64^JVBERi0xLj…. LOTS of BASE-64 Binary Here.....redacted…..zk4NjUKJSVFT0YK||||||F|||20190226110014
Note:
- A single message will contain a single PDF report
- PDF Binary content is delivered in a single OBX segment
- There is a single PV1
- There is a single ORC
- There is a single OBR
Sample MDM Result Message
MSH|^~\&|EMS|EMS|XXX|XXX|20200114093540||MDM^T02^MDM_T02|c82c9f0bc58521a8acf4|P|2.4|||AL
EVN||20200114093437+0000
PD1|||^^D83033|G7103137
PID||1234567890 ^^^NH^NHS|12345^^^^MRN||JustEMSFamily^JustEMS JustEMSMiddle||19880502120000|F|||Just EMS^Address1^^^NR1 1AA
PV1|1||^^^MEDILOGIK|||||C4295091^JustEMSFamily^JustEMS JustEMSMiddle^^^Dr.||301||||||||||||EMS||MEDILOGIK
TXA|1|CUS^Colon^Colonoscopy^EXT||20200114093437||||||||MLEMS_1914
OBX|1|PDF|||JVBERi0x....Base64...LvY2EgMQo+P
MSH
Please Refer to EMS Standard Segment Definitions
PID
The PID segment emitted in ORU result messages is sparsely populated. Patient Identifiers, name, sex and date of birth
PV1
| Segment | Name | Value | Notes |
|---|---|---|---|
| 1 | SetId | ||
| 2 | Patient Class | I, OP |
patientManagementMapper |
| 3 | Patient Location | PL | locationMapper output (requesting Location Reference) |
| 7 | Attending Doctor | report.Performer / Primary Endoscopist | |
| 8 | Referring Doctor | Requestor | |
| 10 | Hospital Service | 301 |
Specialty Code |
ORC
| Segment | Name | Values | Notes |
|---|---|---|---|
| 1 | Order Control | SC |
Always SC for results |
| 2 | Placer Order Number | report Id | |
| 3 | Filler Order Number | Same value as ORC:2 |
|
| 5 | Order Status | CM |
or reportStatusMapper output |
| 6 | Response flag | D |
|
| 18 | Entering Device | EMS |
Used as a place-holder to ensure all prior fields are present |
OBR
| Segment | Name | Value | Notes |
|---|---|---|---|
| 2 | Placer Order Number | ||
| 3 | Filler’s Order Number | Often the same as OBR:2 |
|
| 4 | Universal Service Identifier | ||
| 4.1 | Code | ||
| 4.2 | Description | ||
| 7 | Observation Date Time | Effective date of report | |
| 16 | Ordering Provider | Consultant name / code of Requester. Data Type: XCN | |
| 22 | Results Report Status Change | Same value as OBR:7 |
|
| 25 | Report Status | F, I |
Final / Interim |
| 32 | Principle Report Interpreter | NDL |
Code + name of consultant AUTHORIZING the report |
| 43 | Escort Required | N |
Used as place holder to ensure all prior fields are present |
OBX
Various OBX formats are supported
| Segment | Name | Value | Notes |
|---|---|---|---|
| 2 | Value Type | ED, TX |
ED for PDF reports, TX for textual comments |
| 3 | Observation Identifier | ||
| 3.1 | Code | ||
| 3.2 | Description | ||
| 5 | ObservationValue | Varies | Result |
| 5.1 | Source Application | EMS |
|
| 5.4 | ED Encoding | BASE64 |
Base64 for PDF |
| 5.5 | Binary Content | Actual Base 64 content of PDF | |
| 11 | Report Status | F, I |
output from reportStatusMapper |
| 13 | Checksums | 99999:XXXXXXXXXXXXX |
Where 99999 is the length in bytes of the un-packed PDF content, and XXXXXXXXXXXXX is the hex MD5 checksum of the unpacked binary PDF content |
| 14 | Time of Observation | Report “issued” date/time | |
| 16 | Responsible Observer | Primary Endoscopist / Performer |
Note:
- Standard OBX segment contains the BASE-64 encoded PDF binary content.
- For systems NOT requiring or accepting of the PDF content, a fixed text notification (e.g. A result is available - please see ICE) can be sent as a “TX” OBX segment.
- The actual text of the message in
OBX:5can be configured at runtime. Supporting meta-data (e.g. patient Id, episode Id) from the EMS result message can be substituted in the textual comment, for use (e.g.) as a parameter to a viewer / in-context URL. - Repeated OBX segments may be used to contain site-specific flags
Example URL that can be used to open EMS in context
https://customer-test.medilogik.cloud/ava/app/redirect/patient?mrn=[insert mrn here]
https://customer-test.medilogik.cloud/ava/app/redirect/patient?nhs=[insert nhs here]
https://customer-test.medilogik.cloud/ava/app/redirect/patient?chi=[insert chi here]
https://customer-test.medilogik.cloud/ava/app/redirect/episode-within-history/[insert episode ID here]
Note:
- These are not provided in the outbound messages but as referenced above the relevant patient supporting metadata can be provided in the message for use with a customer created URL.
TXA
| Segment | Name | Value | Notes |
|---|---|---|---|
| 1 | Set ID | 1 |
|
| 2 | Document Type Definition | ID |
|
| 2.1 | CUS |
Custom | |
| 2.2 | Code | EMS Procedure Code e.g. COLON |
|
| 2.3 | Description | EMS Procedure Description | |
| 2.4 | Visibility | ST |
e.g. default = EXT this is set via environment variable txa.documenttype.visibility |
| 4 | Activity Date/Time | DT |
Result |
| 12 | Document Identifier | EI |
Report ID |
EVN
| Segment | Name | Value | Notes |
|---|---|---|---|
| 2 | Recorded Date Time | DT |
Effective date / time of the report |
Round Trip Data
A need arises whereby a placer (or ordering ) system needs to see specific data items in the corresponding report or result message to allow it to be filed correctly, or linked to the original order message.
This data-item is important to the placer system, but has absolutely no meaning or relevance to EMS.
EMS accommodates this scenario through the notion of “round trip data” items. These are data-items which are included in the initial order or referral message, and pass all the way through EMS to be included in the subsequent result message from EMS.
EMS does not parse, interpret or otherwise use these data-items, but simply saves them in the database so that they can be included in the consequent outbound result message.
Common uses for Round Trip Data items include:-
- PV1-19 Spell number
- Cerner PID-18 FINNBR
- Miscellaneous user-specific flags