HL7 2.5
Configuration, message types, structure, examples (as of: Februar 2021).
Configuration#
The HL7 interface is currently only available for export. For clinical information systems, an external program call should be used to import patients from the system into the ControlCenter.
Both available interfaces can be configured in the configuration area of the ControlCenter.
In the Export section, configure the interface as shown below. In the Message type drop-down list you can select the interface to be used, currently ORU or MDM.
In case the external system deletes the PDF during import, create a copy of the document in the Advanced Archiving section.
In addition to the exchange of HL7 messages via the file system, the AmbulApps system also supports the exchange via the HL7 MLLP protocol. If you want to use this, select MLLP as Export type and provide the IP and port of the HL7 listener.
In the Medical data section, the structured data can be configured. Only data types that are configured here are exported to the external system.
MDM^T02#
- Original document notification and content
When the form filling process in AmbuPRAX/AmbuDOC is complete, the PDF file can be transmitted to the HIS/RIS/DMS. For this purpose, the AmbulApps backend supports the HL7 MDM message.
If structured data is also to be transmitted in the HL7 message, the ORU interface should be used instead.
Message structure#
An ORU^R01 message is composed of the following segments:
| Segment | Description | Fields | Mandatory Conditional Optional | Comment |
|---|---|---|---|---|
| MSH | Message header | all fields given in the example below | mandatory | |
| PID | Patient identification | segment number (PID-1) | mandatory | |
| PV1 | Patient visit | all fields given in the example below | conditional, mandatory, only if the allocation is done at case level. | Mandatory, only if the assignment is made at case level. The case-specific information is transmitted in the PV1 segment. |
| TXA | Document notification segment | all fields given in the example below | mandatory | |
| OBX 1 | Observation segment | all fields given in the example below | mandatory | |
| OBX 2 | Document description | all fields given in the example below | mandatory | OBX-5 is used as a document description and as a title. |
| OBX n | Observation results | all fields given in the example below | optional |
Structured data (observation results) Starting with the OBX|3| field, structured data can be transmitted within the scope of MDM. This data has been stored by the patient in the form and saved in a structured manner. In the best case, the HIS/RIS can read this data and write it to the corresponding fields. This includes, for example, height and weight, allergies, previous illnesses, etc. Alternatively, the data can also be transferred to the patient file as unstructured findings.
| Segment | Content |
|---|---|
| OBX 3.1 | "code": contains a code that uniquely identifies the content. This is to be defined in consultation with the HIS/RIS. On the AmbulApps side, these are freely configurable within the digital forms. |
| OBX 3.2 | "category": for easy identification of the content, a readable designation of the content is also given (e.g. anamnesis, family anamnesis, CAVE, score, findings...) |
| OBX 4.1 | contains the document ID |
| OBX 5.1 | the structured data itself as text, all content with the same code is written in an OBX and separated with commas (,) |
Sample message#
Here is a sample message created in ControlCenter:
ORU^R01#
- Unsolicited transmission of an observation message
When the form filling process in AmbuPRAX/AmbuDOC is complete, the PDF file AND the structured data can be transmitted to the HIS/RIS/DMS. For this purpose, the AmbulApps backend supports the HL7 ORU message.
Message structure#
An ORU^R01 message is composed of the following segments:
| Segment | Description | Fields | Mandatory Conditional Optional | Comment |
|---|---|---|---|---|
| MSH | Message header | all fields given in the example below | mandatory | |
| PID | Patient identification | segment number (PID-1) | mandatory | |
| PV1 | Patient visit | conditional, mandatory, only if the allocation is done at case level. | Mandatory, only if the assignment is made at case level. The case-specific information is transmitted in the PV1 segment. | |
| OBX 1 | Observation segment | all fields given in the example below | mandatory | |
| OBX 2 | Document description | all fields given in the example below | mandatory | OBX-5 is used as a document description and as a title. |
| OBX n | Observation results | all fields given in the example below | optional |
Structured data (observation results) Starting with the OBX|3| field, structured data can be transmitted as part of the ORU. This data has been stored by the patient in the form and saved in a structured manner. In the best case, the HIS/RIS can read this data and write it into the corresponding fields. This includes, for example, height and weight, allergies, previous illnesses, etc. Alternatively, the data can also be transferred to the patient file as unstructured findings.
| Segment | Content |
|---|---|
| OBX 3.1 | "code": contains a code that uniquely identifies the content. This is to be defined in consultation with the HIS/RIS. On the AmbulApps side, these are freely configurable within the digital forms. |
| OBX 4.1 | "category": for easy identification of the content, a readable designation of the content is also given (e.g. anamnesis, family anamnesis, CAVE, score, findings...) |
| OBX 5.1 | the structured data itself as text |
Example message#
This is a sample message created in ControlCenter: