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 and above.
Starting from the HL7 Message types, the document describes the conetent of each HL7 segment. The last sections describes the data handling (patient / order / observation / tenant), meaning the typical workflow / lifecycle of the data in custo diagnostic.
(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 custo diagnostic vendor / implementer.)
General Data Used
Drübergehen DTM Format?
""
Gewicht / Größe / Medication
Key
Not listed fields are ignored
Default configuration - can be confgured in some extent.
Receiving / Sending seen from custo diagnostic perspective
optional - not reuqired, in some cases must be activated in custo diagnostic.
i - ignored.
Supported Message Types
The software supports the following message types.
- ADT
- ORM
- ORR
- ORU
- DFT
- MDM
- ACK
The message types must be licenced individually - which means not in all installations all message types will be available.
HL7 Segments
Optionality Key
Incoming
| r | required | This value is required for a proper function of the software |
| o | optional | This value is not required but may be used for some functionality in custo diagnostic. |
| i | ignored | This value is ignored |
Outgoing
| s | send | This value will be send by default, in case the data is available |
| so | send optiontal | This value will be send, in case it is agreed between the communication partners. |
MSH - Segment
| Field | o/r/i | s/so | Default Usage |
|---|---|---|---|
| MSH-3 | o | so | 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. |
| MSH-4 | o | so | 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" below. |
| MSH-5 | o | so | 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". |
| MSH-6 | o | so | 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" below. Outgoing: Receiving Facility, can be configured (default empty) in custo diagnostic e.g. "HIS". |
| MSH-7 | r | s | Date/Time Of Message, see HL7 Standard. ##DTM## |
| MSH-9 | r | s | Message Type. By default, custo diagnostic sends Messagetype^Event^Message-Structure, e.g. ORU^R01^ORU_R01. |
| MSH-10 | r | s | Message Control ID, see HL7 Standard |
| MSH-12 | r | s | Version ID, Outgoing: Custo diagnostic supports Version 2.3, 2.5 ##Verhalten bei eingehenden Nachrichten noch prüfen, wenn 2.7 2.9 oder 1.5 o.ä. drin steht## |
| MSH-13 | r | s | Sequence Number, see HL7 Standard |
| MSH-15 | s | Accept Acknowledge see below "Accept / Application Acknowledge" | |
| MSH-16 | i | s | Application Acknowledge Receiving: ignored. Sending: Always set to "NE" see below "Accept / Application Acknowledge" |
| MSH-18 | i | s | Character Set Receiving messages: custo diagnostic considers the character set specified in MSH-18 (##bitte prüfen). custo diagnostic can be configured to use a specific character set. In general Windows-1252 is used and send out via MSH-18. This one 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
### Hier bitte alles aus default Mapping übernehmen.###
z.B. PID-3, r, Patient-ID, see HL7 Standard. 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 below).
Required sind patienten name/vorname, geburtsdatum?, Patienten-nummer, geschlecht?
| Field | o/r/i | s/so | Default Usage |
|---|---|---|---|
| PID-3 | r | s | 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 below). |
| PID-8 | r ? | s | Administrative Sex. Supported Values are F, M, ?? Other Values are interpeted as ... ##zu prüfen## |
PV1 - Segment
##bitte aus default mapping ergänzen## Ist wahrscheinlich alles optional
Auch die möglichen WErte für PV1-2 und PV1-21 wären interssant.##
| Field | o/r/i | s/so | Default Usage |
|---|---|---|---|
| PV1-19 | r | s | 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 below). |
| PV1-44 | o | - | Admission Date: custo diagnostic can store this information, even it is not shown in the user interface. Its done for future usage. |
| PV1-45 | o | - | Discharge Date/Time: custo diagnostic can store the discharge date/time to filter out discharged patients in patient search lists. It can be defined, how custo diagnostic interpretes an empty discharge date/time - either als missing, unknown information, or as the information, that the discharge date should be deleted in custo diagnostic. |
ORC - Segment
| Field | o/r/i | s/so | Default Usage |
|---|---|---|---|
| ORC-1/ORC-5 | r | See OBR-1 / OBR-5 | |
| ORC-16 | o | ORC-16-2: Order Control Code Reason / Clinical questions, shown to the user before processing the observation request. |
OBR - Segment
##bitte prüfen, ob hier alles aus default mapping drin ist
| Field | o/r/i | s/so | Default Usage | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| OBR-1 / OBR-5 | r | s/so | Order Control The combination of OBR-1 and OBR-5 can be configured as order control: Default:
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 Obervation Status via ORR / ORU Messages" | |||||||||||||||
| OBR-2 | r | s | Placer ID | |||||||||||||||
| OBR-3 | i | s | Outgoing: Consecutive Number with an alphanumeric prefix, e.g. "CM00001234" or some GUID, e.g. "36eea93b-bc1b-4769-a84e-4ebeaaaf387e" | |||||||||||||||
| OBR-4 | r | s | OBR-4 contains information about the type of observation which should by executed. OBR-4-1 is a coded value which must be defined. OBR-4-2 when incomfing, OBR-4-2 is shown to the user, e.g. "Resting ECG" OBR-4-1 and OBR-4-2 is requried, other components optional. ##bitte prüfen - when OBR-4-2 in eingehender Nachricht abweichen zur Konfiguration in "Untersuchung" - welcher Text wird dabei angezeigt - der aus der Konfig, oder der aus der Nachricht? Outgoing: The software sends OBR-4 as received with the order. | |||||||||||||||
| OBR-5 | see OBR-1 | |||||||||||||||||
| OBR-20 | o | Incoming: Flexible text-fields which can be used to show additional information regarding this order to the user. | ||||||||||||||||
| OBR-21 | o | Incoming: Flexible text-fields which can be used to show additional information regarding this order to the user. |
Patient Data Logic (ADT)
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
custo diagnostic accepts by default the following message types (further message types can be defined)
##bitte Liste einfügen##
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 (except delete messages A23, A29, ##DS-709##). 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. (see "Null Value").
This behavior can be configured - meaning that it can be stipulated which message creates a patient/visit (e.g. only ADT^A01), and 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.
##bitte prüfen
Tenant System
Tenant Systems can be configured in different ways to separate 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:
| Tenant (Description) | MSH-6 (code) | |
|---|---|---|
| Sea View Hospital | SVH | |
| Lake Hospital | LH |
By default, custo diagnostic send back the tenant code in MSH-4.
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
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):
| OBX-3-1 | OBX-3-2 |
|---|---|
| BODY WEIGHT | Weight |
| BODY HEIGHT | Height |
| MEDICATION | Medication |
Even this information is transfered with an order - it is stored/updates the visit information.
Order Status
The acquired recording may be processed several times in the software by several users, before it is finally reported. This workflow must be stipulated for the specific customer.
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.
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.
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:
| Activity/Event | ORC-1 / ORC-5 |
|---|---|
| Order request accepted | by default not activated |
| Order request updated | by default not activated |
| Examination starts | SC / SC |
| Examination is finished | SC / CM |
| Order request will be deleted | SC / CA |
| Order request will be reset | by default not activated |
| Examination will be deleted | by default not activated |
Observation Result Status
The following result Status is part of the of the OBX-Segment, when sending the results.
##bitte nochmal OBX prüfen. Stimmt OBX-25?
| OBX-11/OBX-25 | Meaning |
|---|---|
| R | The results are entered or automatically generated. |
| P | The results are preconfirmed, in general not by an accountable person. |
| F | The results are confirmed by an accountable person. |