Sense Medical

This specification is currently a work in progress.

Events Processed

ADT^A01 - Admit Patient

An A01 event is intended to be used for "Admitted" patients only. An A01 event is sent as a result of a patient undergoing the admission process which assigns the patient to a bed. It signals the beginning of a patient’s stay in a healthcare facility.

Cortex will update both patient demographic information from the PID segment, as well as visit information when processing this message.

Updates to admit information are sent as a subsequent ADT^A01 message.

Structure:

ADT^A02 - Transfer Patient

An A02 event is issued as a result of the patient changing his or her assigned physical location. 

Cortex will update both patient demographic information from the PID segment, as well as visit information when processing this message. 

To cancel a transfer, a new ADT^A02 message should be sent, reversing the locations.

Structure:

ADT^A03 - Discharge Patient

An A03 event signals the end of a patient’s stay in a healthcare facility. It signals that the patient’s status has changed to "discharged" and that a discharge date has been recorded. The patient is no longer in the facility.

For non-admitted patients, an A03 event signals the end of a patient’s visit to a healthcare facility. It could be used to signal the end of a visit for a one-time or recurring outpatient who is not assigned to a bed. It could also be used to signal the end of a visit to the Emergency Department.

Cortex will update both patient demographic information from the PID segment, as well as visit information when processing this message.

Updates to patient discharge information are sent as a subsequent ADT^A04 message.

Structure:

ADT^A04 - Register Patient

This event signals that the patient has arrived or checked in as a one-time, or recurring outpatient, and is not assigned to a bed. Typically Emergency Department visits.

Cortex will update both patient demographic information from the PID segment, as well as visit information when processing this message.

Updates to patient registration information are sent as a subsequent ADT^A04 message.

Structure:

ADT^A11 - Cancel Patient Admit

For "admitted" patients, the A11 event is sent when an A01 (admit/visit notification) event is cancelled, either because of an erroneous entry of the A01 event, or because of a decision not to admit the patient after all.

For "non-admitted" patients, the A11 event is sent when an A04 (register a patient) event is cancelled, either because of an erroneous entry of the A04 event, or because of a decision not to check the patient in for the visit after all.

Structure:

ADT^A13 - Cancel Discharge

ADT^A28 - Create New Patient

This event allows the creation of a patient record in Cortex before any admission or visit events take place.

HL7 2.4 defines the PV1 segment as required to maintain backward compatibility with previous releases. However, a "pseudo-optional" PV1 can be achieved by valuing PV1-2 - patient class to N - not applicable. Cortex does not require the presence of the PV1 segment at all for this event.

Structure:

ADT^A31 - Update Person Information

This event allows for the updating of patient demographic information outside of the context of a visit. Many systems can be quite noisy with theses messages, so Cortex will selectively process these messages only for patient who have a current visit in progress. This event is ignored for those patients who do not have a visit in progress. 

HL7 2.4 defines the PV1 segment as required to maintain backward compatibility with previous releases. However, a "pseudo-optional" PV1 can be achieved by valuing PV1-2 - patient class to N - not applicable. Cortex does not require the presence of the PV1 segment at all for this event.

Structure:

ADT^A40 - Merge Patient

An A40 event is used to signal a merge of records for a patient that was incorrectly filed under two different identifiers. The "incorrect source identifier" identified in the MRG segment (MRG-1 - prior patient identifier list) is to be merged with the required "correct target identifier" of the same "identifier type code" component identified in the PID segment (PID-3 - patient identifier list). The "incorrect source identifier" would then logically never be referenced in future transactions.

Structure:

Segment Definitions

MSH - Message Header Segment

Example:

MSH|^~\\&|||||20190527223546||ADT^A01|18234123946123|P|2.4||||

EVN - Event Segment

Example:

EVN|A01|20190527223546||||20190527223400|

PID - Patient Identifier Segment

Examples:

PID|1||81231314^^^&2.16.840.1.113883.2.18.66.3.1.1~ZZZ0016^^^&2.16.840.1.113883.2.18.2~TEM1234^^^&2.16.840.1.113883.2.18.2||Bloggs^Joe^John^^Mr^^D||19391009|M||99^Not Stated||||||||||||99^Not Stated^NZHIS||||||||N

PV1 - Patient Visit Segment

MRG - Merge Patient Information Segment

Data Types

CX - Extended Composite ID with Check Digit

Example: 

ZZZ0016^^^&2.16.840.1.113883.2.18.2 (Usage as New Zealand NHI patient identifier)

PL - Patient Location

Example: 

WD 16^01^04^&FZZ999-B&FAC^^^^Ward 16 (Usage as New Zealand location within a MoH defined facility)

XPN - Extended Person Name

Example:

Bloggs^Joe^