HL7 Message Types

Below is a description of HL7 inbound and outbound message types that are supported. Outbound message type descriptions also include what actions in Open Dental cause an outbound message.

Generic HL7 Message Structure, eCW HL7 Message Structure, LabCorp HL7 Definition

Inbound Messages

ACK - General Acknowledgment Message: In TCP/IP mode, every message sent by Open Dental should be acknowledged by the receiving software. If an acknowledgment is not received within 5 seconds of sending a message, an event log warning will be entered and the message will be resent within 6 seconds.

ADT - Patient Demographics Message: Updates patient demographic information. If an inbound ADT message is defined, changes made to patient information within Open Dental may be overwritten by the next inbound ADT message for the patient.

PPR -Patient Problem Message: Either adds a new problem or updates an existing problem, based on the problem action field, usually PPR-1. The problem code in PPR-3.0 must be a SNOMED code identified by SNM (not case sensitive) in PPR-3.2. There must be a problem in the Open Dental database with the same SNOMED code assigned, and there must be a unique identifier with assigning authority root in PPR-4.0 and PPR-4.2 respectively. Start and stop dates are allowed in PPR-7 and PPR-9 respectively, but either or both can be omitted and the problem will still be inserted. If the patient has an active problem with this SNOMED code in their medical chart, but the unique identifier received does not refer to the existing problem, the existing problem will be marked inactive and the new problem will be inserted and linked to the unique identifier. If the patient has an active problem with this SNOMED code and the unique identifier does reference the existing problem, the start and stop dates will be updated and the problem status will be set to active.

SIU - Schedule Information Unsolicited Message: Used when Open Dental assumes the role of an auxiliary application. In this role, Open Dental does not modify the schedule. Appointments are inserted from these inbound messages without regard to operatories or schedules or overlaps. For this reason, when Open Dental is the auxiliary application the Appointment module is hidden. If it was not hidden, there would be errors when the operatories were drawn and all of the appointments for the day were overlapping in the same operatory.

SRM - Schedule Request Message: Used when Open Dental assumes the role of the filler application. In this role, Open Dental maintains and controls the schedules of the providers and operatories. So appointments are created and modified in Open Dental and a definition for an inbound SIU message should NOT be in the enabled HL7 definition. There may, however, be an outbound SIU message defined for communicating appointment information to another software (see Outbound Messages - SIU). Another software may, however, request modifications to existing appointments in Open Dental. These requests are received in the form of an SRM message with event type S03. Only some of the appointment details can be modified by an inbound SRM. The appointment cannot be moved or have the length adjusted, since the external software has no knowledge of the operatory/provider schedules and openings. An inbound SRM message can change the provider (both dentist and hygienist), the confirmation status, the clinic, and the note for the specified appointment. There is also support for breaking an appointment, using an SRM with event type S04 (see the Open Dental HL7 Interface Specifications for an explanation of the different event types).

Outbound Messages

ACK - General Acknowledgment Message If the enabled HL7 definition is set to TCP/IP mode, every message received will be acknowledged by an outbound ACK message. If the message was successfully parsed and processed, the message will contain AA (Application Accept) in MSA-1. If there was an error with the message structure or if a required element was not included in the message, the MSA-1 field will contain AE (Application Error).

ADT - Patient Demographics Message Outbound ADT messages communicate new patient information or updates to existing patient information. ADT messages will be created if there is a definition for an outbound ADT in the enabled HL7 definition in the following situations.

DFT - Detailed Financial Transaction Message Outbound DFT messages communicate information about procedures completed in Open Dental. They can also be used to transmit treatment plan PDFs. DFTs are created and sent if there is a definition for an outbound DFT in the enabled HL7 definition in the following situations.

SIU - Schedule Information Unsolicited Message SIU messages are sent to communicate appointment related changes to an external application. Five event types are used by Open Dental in outbound SIU messages. S12 - New Appointment, S13 - Appointment Rescheduling, S14 - Appointment Modification, S15 - Appointment Cancellation, and S17 - Appointment Deletion. The following is a list of actions in Open Dental that will trigger an SIU message with the specified event type.

SRR - Schedule Request Response Message An SRR - Schedule Request Response Message is generated and sent in response to an SRM - Schedule Request Message. The SRR notifies the application responsible for sending the SRM whether the requested modification took place or not. Since the only appointment modification supported are updating the appointment note, setting the dentist or hygienist, updating the confirmation status, changing the ClinicNum of the appointment, or setting the appointment status to Broken, the response to an SRM message is usually to confirm that the requested modification took place. The only situations that a requested modification would not be performed is if the patient referenced by the SRM could not be found, the appointment referenced could not be found, an appointment and a patient were located but the patient located is not the patient on the appointment, or some other error occurred during the processing of the message. In these situations, the SRM will still trigger an SRR, but the SRR will have the acknowledgment code AE (Application Error) in the MSA-1 field.

As long as the patient is found, the appointment exists, the patient on the appointment and the patient referenced by the PID segment are the same patient, and the message is able to be processed correctly (not malformed), the SRM will be acknowledged with acknowledgment code AA (Application Accept) in the MSA-1 field.