Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Please refer to your local sales partner for a HL7 specification.

It's available in the support area at custo med website, Healthcare-IT.

Introduction

custo diagnostic is a server based software (referenced as "software"), intended to support physicians to acquired, analyze, document and report cardio pulmonary observations. The inherent patient, order and observation database can be interfaced via HL7, DICOM and GDT to an superior system. This document describes the typical use of the HL7 interface version 5.6.4 and above and addresses the HL7 communication partner. It is not a comprehensive description, because it should focus on the typical usage. In case more information fields / data is necessary, please refer to your authorized custo med partner to see specific options to use specific mappings of data fields. 

The intention is not, to give a deep insight about the configuration in our service applications to configure this options. Typical use / default does not imply, that the software has activated this options out of the box. Some manual configuration work is necessary by the authorized custo diagnostic vendor / implementer.

Starting from the typical data handling / workflows regarding patients, orders, tenants ("Mandant"), etc the last sections covers the typically used segments to establish these usage. 

ToDo 

FHo: Alles nochmal mit Mapping Tabelle abgleichen

Dev: Alle ## Einträge nachschauen/ergänzen.

Content

Table of Contents

General HL7 information

...

All typical character sets supported.

In general, custo diagnostic is configured to export via Windows-1252 (global for all export messages)

...

TCP/IP Socket

File based

...

  • ADT
  • ORM
  • ORR
  • ORU
  • DFT
  • MDM
  • ACK

The message types must be licenced individually - which means not all installations provide all message types.

...

In general custo diagnostic supports the null value for receiving messages.

...

Patient Data Logic (ADT)

The role of custo diagnostic in HL7 context is to act as a consumer for patient data, process incoming orders and/or exporting results via HL7.  

ADT Messages

Supported messages:  A01, A02, A03, A04, A05, A08, A11, A12, A13, A23, A29, A38, A40, A42, A43, A45 (further message types can be defined).

Patient / Visit Identification

custo diagnostic uses by default the patient ID from PID-3-1 and Visit-ID from PV1-19 to identify the patient/visit. In case these are not unique, an appropriate tenant system must be configured.

These IDs are processed as a string - in contrast to an numeric value. This means - a patient "0001234" is not the same as patient "1234".  

Please note, that most custo diagnostic feature assume, that Patient and Visit IDs are present. In systems where one of these information is not available, some functions will by default not work the way they are defined by HL7. (e.g. Merging/Moving). Please contact custo med in advance, to discuss the appropriate configuration in circumstances where Patient- or Visit-ID are not available. 

Creating and Updating Patient / Visit information

In case a patient does not exists in custo diagnostic, by default, custo diagnostic creates the patient and visit by each of theses ADT messages. For example, a patient/visit can be created in custo diagnostic by an A08 message - without any admission message.

In case a patient/visit already exists in custo diagnostic, it is updated by default by each ADT message.  (please also see "Null Value" in section "General HL7 information" ).

In some environments, a patient is only created via Order-Messages and Merge/Move-Messages. (can be configured). 

This behavior can be configured - meaning that it can be stipulated which message creates a patient/visit (e.g. only ADT^A01), and/or which messages updates a patient/visit information. 

Discharge Patient / Visit

When receiving a discharge message (A03) - open observation requests (orders) are deleted.  Other behavior can be configured (deletion of visit, delegation of observation etc.)

PV1-45 is used to set the discharge date of the patient.   

##bitte prüfen - ich glaube es wird nicht der zeitstempel der nachricht/des events verwnedet, sonddern eben pv1-45. Wie ist dies mit der entlassnachricht`?)

Deleting Patients / Visits

Patients and visits can be deleted in custo diagnostic by A23, A29. A deletion means that it is marked as deleted and will be purged by the next purge-run which by default runs each night. 

Tenant System

Tenant Systems (german "Mandant") can be configured in different ways to separate orders/observation and/or patients/visits. 

The tenant system must be defined, by default the tenant information is expected in MSH-6 by custo diagnostic, and will be send back in MSH-4.

This must be a biunique definition, meaning one specific code for MSH-6 should point to one specific tenant and vice versa. In case several facilities should be part of one tenant in custo diagnostic, we strictly recommend to solve this on the HIS side.

Sample:

...

Receiving (e.g. ORM)

MSH-6-1 (code)

...

Sending (e.g. ORU)

MSH-4-1

...

Order Data / Order Entry Workflow

The software supports all messages to provide a full HL7 order-entry workflow and methods to update the superior system about the current order status.

Orders

Supported Message:   ORM^O01

Typical workflow:  custo diagnostic receives orders and show them as a worklist to the users. One order is (by default) identified by the Placer Number, and may contain several observation requests, identified by Alternate Order ID. A clinical question is visible to the user, which can contain a free text, The intention of the clinical question is to avoid unstructured communication by E-Mail/Phone etc. 
The user choose the requested observation, and custo diagnostic determines the diagnostic mode by the service identified given in OBR-4, e.g. Spirometry, Resting-ECG, Holter.

When receiving an order, the software also supports additional information (optional):

...

Even this information is transferred with an order - it is stored/updates the visit information. 

The following units are supported:

  • Weight:   kg, ##
  • Height:    m, cm, ##

Order Status

The acquired recording may be processed several times in the custo software by several users, before it is finally reported. This workflow must be stipulated for the specific customer and may vary for the different ECG types (like holter, Resting-ECG). 

custo supports three methods to update the superior system (placer of the order) about the current state of the observation:

  • ORR Messages
  • ORU Status Messages  (OBR-1/OBR-5)
  • Observation Result Status in (OBX-11)

Furthermore the software can be configured, that only specific users/results with specific status can be transferred to the superior system. 

Sending Observation Status via ORR / ORU Messages

ORR Message and / or ORU Status Messages can be configured on special activity / events.

The following events can be activated:

...

Observation Result Status

The following result Status is part of the of the OBX-Segment, when sending the results.

...

The order was canceled / the evaluation was deleted. 

Observation Results (ORU)

Supported Message Type:  ORU^R01

As mentioned above, an order / observation may be processed in different steps by different persons. This implies, that it may be send with different observation status several times to hte place, as stipulated for this specific installation and observation type.  The observation gets and internal filler ID as soons as the observation is created. 

In most installations, the manually typed in Report-Text (german "Befund") and a created PDF-File (also base64-embedded) are the most important data of the observation. 

When the orders are processed, custo diagnostic adds an internal "Filler ID" . This can be configured by a fixed length consecutive number, with an arbitrary alphanumeric prefix, e.g. "CM00001234", or an GUID (OBR-3, ORC-3)

Sending specific observation data

custo diagnostic can send specific observation data. The most common one is the manually typed in report (referenced as AKT_BEF) or the entire observation (referenced as FILE_PDF) as PDF / base64 embedded, but more than hundred specific numeric values can be defined. One or more of the listed observation data can be exported in the same message. Alternatively one message per observation data can be send. 

Sample - Outgoing ORU Message with Formatted-Text Report and Base64-encoded PDF-File

e.g. AKT_BEF contains the typed in report, marked with (OBX-11) "F" → Final. 

Code Block
MSH|^~\&|||||20210604110853.844+0200||ORU^R01^ORU_R01|2401|P|2.5|||NE|NE|D 
PID|1||197051008||Benson^Joe||19570213|M|||Trebeck Street 14^^Tedworth, South^^10417 
PV1|1|U|H1A^^B377T^IM^^^3^5e||||||||||||||||3044281008||K 
ORC|SC|12345|CM0000000001||CM 
OBR|1|12345|CM0000000001|EKG03^EKG03|||20210602160514|||||||20210602160514||||||||20210604103235||||||||||&Supervisor 
OBX|1|ED|FILE_PDF^PDF File||^^pdf^Base64^JVBERi0xLjQKJcOiw6MKMSAwIG9iago8PAovVGl0bGUgKP7AGMAdQBzAHQAbwBfAGQAaQBhA ... olJUVPRgo=||||||F 
OBX|2|FT|AKT_BEF^Report|1|normofrequenter Sinusrhythmus\.br\Steiltyp||||||F

PDF Files

custo recommends to transfer the PDF-Files bas64 embedded as shown in sample above.  In case this is not possible, the software can export the PDF-File on a file store / share, in general it should be located on the same host custo diagnostic server is executed. By default, the PDF-Filename is equivalent to the GUID (can be configured) of the observation. Already existing files with this filename are overwritten.

We recommend to move the file to another store while processing the referencing ORU/MDM message. We do not recommend, to use the referenced file share as a long-lasting "archive".

Code Block
MSH|^~\&|||||20210604125019.69+0200||ORU^R01^ORU_R01|2701|P|2.5|||NE|NE|D
PID|1||197051008||Benson^Joe||19570213|M|||Trebeck Street 14^^Tedworth, South^^10417
PV1|1|U|H1A^^B377T^IM^^^3^5e||||||||||||||||3044281008||K
ORC|SC|12345|CM0000000001||CM
OBR|1|12345|CM0000000001|EKG03^EKG03|||20210602160514|||||||20210602160514||||||||20210604103235||||||||||&Supervisor
OBX|1|RP|FILE_PDF^PDF File||\E\\E\myserver\E\theshare\E\30c5ef4b-a5db-4b26-beab-d6922d4a4d47.pdf^^pdf||||||P
OBX|2|ST|AKT_BEF^Report|1|Dnormofrequenter Sinusrhythmus\.br\Steiltyp||||||P

The reference pointer to the file    \\myserver\theshare\30c5ef4b-a5db-4b26-beab-d6922d4a4d47.pdf    use the \E\ to escape the backslash. (can be deactivated). 

Measurement-Values

The software analyzes the recorded evaluation - e.g. ECG values, execute several algorithms and produces hundreds of physiologicial / statistical data - named "Measured Values". A list of possible measured values can be obtained from the manufacturer of the software or the implementer. The export of these values is normally not activated.

Exemplary, we use here the the measured Values:

  • Heart Rate, Resting (HF_R): The heart rate for a resting patient, e.g. 71 beats per minute. 
  • Heart Axis Type (H_AXIS_TYPE): This is an physiological type, reflecting the direction of the main activation of the heart. e.g. "vertical heart".
  • QT Time (QT_Zeit): This is an (statistical) timespan between the Q and the T-wave of an ECG graph, e.g. 374 milliseconds.
Code Block
MSH|^~\&|||||20210604131051.208+0200||ORU^R01^ORU_R01|3301|P|2.5|||NE|NE|D
PID|1||197051008||Benson^Joe||19570213000000+0100|M|||Trebeck Street 14^^Tedworth, South^^10417
PV1|1|U|H1A^^B377T^IM^^^3^5e||||||||||||||||3044281008||K ORC|SC|12345|CM0000000001||CM
OBR|1|12345|CM0000000001|EKG03^EKG03|||20210602160514|||||||20210602160514||||||||20210604125008||||||||||&Supervisor
OBX|1|ST|AKT_BEF^Report|1|Demo-EKG||||||P
OBX|2|NM|HF_R^Heart Rate, Resting|1|71|^bpm|||||P
OBX|3|FT|H_AXIS_TYPE^Heart axis type|1|vertical heart||||||P
OBX|4|NM|QT_ZEIT^QT Time|1|374|^ms|||||P

It is recommended to use the OBX-3-1 as a filter, and OBX-3-2 as the text which is shown to a user. 

Operation Results via MDM

Supported Message Types:    MDM^T01, MDM^T02, MDM^T07, MDM^T08, MDM^T11

Independently from ORU, custo diagnostic can also transfer data via MDM to another system. 

The MDM export is typically used to transfer PDF-Files. (For historical reasons other exports may be possible via MDM: Picture Data (PNG), DICOM Waveform, RTF-File - but these options may no longer supported). 

DICOM: In general, the separate DICOM store functionality should be used, instead of the HL7 export. 

The MDM message contains a TXA and OBX segment, which points to the file in the file share / or covers the PDF as base64 embedded.

HL7 Segments

This HL7-Segements section describes the typical used data fields and components - it is not a complete mapping list, because it should focus on a reasonable usage of the system. 

Components which are affected by the workflow are described in the above data handling / workflow sections.

Optionality Key

Incoming

...

Outgoing

...

MSH - Segment

...

Sending Application. 

Incoming: Expected value can be configured (default empty) in custo diagnostic and works as a filter - meaning messages with deviant content in MSH-3 are ignored.

Outgoing: Sending Application, e.g. "CUSTO" can be configured in custo diagnostic.

...

Sending Facility

Incoming: Expected value can be configured in custo diagnostic and works as a filter - meaning messages with deviant content in MSH-4 are ignored. 

Outgoing: Sending Application, e.g. "CUSTO" can be configured in custo diagnostic. When a tenant system (german "Mandantensystem") is configured, this field contains the information about the tenant. See "Tenant System" above. 

...

Receiving Application

Incoming: Expected value can be configured (default empty) in custo diagnostic and works as a filter - meaning messages with deviant content in MSH-3 are ignored.

Outgoing: Receiving Application, can be configured (default empty) in custo diagnostic e.g. "HIS".

...

Receiving Facility

Incoming:  Expected value can be configured in custo diagnostic and works as a filter - meaning messages with deviant content in MSH-3 are ignored.  When a tenant system (german "Mandantensystem") is configured, this field should contain the information about the tenant. See "Tenant System" above. 

Outgoing: Receiving Facility, can be configured (default empty) in custo diagnostic e.g. "HIS".

...

Message Type.  By default, custo diagnostic sends Messagetype^Event^Message-Structure, e.g.  ORU^R01^ORU_R01. 

...

Version ID (see section General HL7 information)

...

Accept Acknowledge

see below "Accept / Application Acknowledge"

...

Application Acknowledge

Receiving: ignored.    Sending: Always set to "NE"

see below "Accept / Application Acknowledge"

...

Character Set

Receiving messages: custo diagnostic considers the character set specified in MSH-18.

custo diagnostic can be configured to use a specific character set. In general Windows-1252 is used and send out via MSH-18. The general setting is used for alle outgoing messages. 

Accept / Application Acknowledge

custo diagnostic supports message acknowledge, but not application acknowledge.

Message Acknowledge can be configured for each channel / message type. While for TCP/IP socket connections message acknowledge is mandatory, it can be activated/deactivated for message transfer via files. 

This means, when receiving a message MSH-15 / MSH-16 is ignored, because the general configuration is taken. When sending a message, MSH-15 will depict the configuration in custo diagnostic. MSH-16 will always be "NE".

PID - Segment

##Required sind patienten name/vorname, geburtsdatum?, Patienten-nummer, geschlecht? Stimmt das? 

...

PID-3-1 is used to identify the patient in custo diagnostic.

It must be unique in one custo diagnostic installation, otherwise an appropriate tenant system must be used (see tenant system above).

...

PID-5-1, PID-5-2, PID-5-3, PID-5-4, PID-5-6:  Family Name, Given Name, Second Name, Suffic, Degree/Title 

Required: PID-5-1

...

Administrative Sex. Supported Values are F, M, ?? Other Values are interpeted as ... 

...

PV1 - Segment

...

Patient Visit price indicator. ###

...

Visit-ID. The visit id is used to identify the visit in custo diagnostic It must be unique in one custo diagnostic installation, otherwise an appropriate tenant system must be used (see "tenant system" above).

...

ORC - Segment

...

See OBR-1 / OBR-5

...

OBR - Segment

...

Order Control

The combination of OBR-1 and OBR-5 can be configured as order control:

Default:

OBR-1OBR-5Usage
NW*New order
XO*Change Order
not configurednot configuredDelete scheduled datetime
CA*Cancel Order

By default, OBR-5 is not evaluated, but can be configured to specific values. In this case the combination of OBR-1 and OBR-5 must match.

Outgoing: See also  "Sending Observation Status via ORR / ORU Messages"

...

Outgoing:  Consecutive Number with an alphanumeric prefix, e.g. "CM00001234" or a GUID,.

This can be configured by a fixed length consecutive number, with an arbitrary alphanumeric prefix, e.g. "CM00001234", or an GUID e.g. "36eea93b-bc1b-4769-a84e-4ebeaaaf387e"

...

OBR-4-1/OBR-4-2 contains information about the type of observation which should by executed.

OBR-4-1 is a coded value which must be defined/agreed between interface partner.

OBR-4-2 when incoming, OBR-4-2 is shown to the user, e.g. "Resting ECG", must be defined/agreed between interface partner.

OBR-4-1 and OBR-4-2 is required, other components optional. 

Outgoing: The software sends OBR-4 as received with the order. 

...

OBX-Segment

...

observation identifier, see below

OBX-3-1 code, OBX-3-2 text/human readable

...

Observation Result Status. (see above, section "Observation Result Status")

1) Incoming: See section "Orders"

Most used OBX-3 Codes:

...

Points to an PDF-File, including path. 

...

TXA-Segment

(Use Case: PDF Export)

...

(Use Case: PDF Export)

Physical Transport

custo diagnostic server supports TCP/IP socket based (recommended) and file based communication.

TCP/IP socket communication

For HL7 socket communication custo diagnostic server can act as an server or client.

In general for incoming messages (e.g. ADT) custo diagnostic server listens as a server for incoming connections. For safety and security reasons, the sending IP must be whitelisted. 

In general for outgoing messages (e.g. ORU) custo diagnostic server acts as client and initiates the socket to the counterpart. 

File based communication

custo diagnostic can poll for HL7-files in file locations, process the files and deletes them. 

custo diagnostic can write HL7 files to a specific file locations.

By default, the custo diagnostic server operates by Local System account on the windows host, meaning that the service is able to access all local files but no remote file share, residing on a different windows host.