Reference table
HL7 v2
Lists the HL7 version 2 message types orophin handles, the segments read and written, and the direction each interface runs.
Pensieve exchanges HL7 v2 messages with the laboratory, registration and order systems a hospital already runs, and this page lists the HL7 version 2 message types orophin handles, the segments the platform reads and writes, and the direction each interface runs. The bridge frames each message and carries it across the boundary, and the platform reads and writes the segments the standard defines.
Message types
Each message is identified by its type, and an order message is refined by its order control code. A message of a type outside the set below reads back a clean rejection that names the reason, so an unsupported message is answered rather than dropped.
| Message type | Purpose | Direction |
|---|---|---|
| ORU^R01 | Laboratory and radiology results returned against an order | Received |
| ADT^A01, ADT^A04 | Admit or register a patient | Received |
| ADT^A02 | Transfer a patient between locations | Received |
| ADT^A03 | Discharge a patient | Received |
| ADT^A08 | Update patient or visit details | Received |
| ORM^O01, OML^O21 | Place or change an order | Sent or received |
| ORR^O02, ORL^O22 | A laboratory's acknowledgement of an order | Received |
A results feed and a registration feed arrive from the hospital's systems into the record. An order message runs in either direction, as an external system places an order into Pensieve or as Forge routes an order out to a laboratory, and the laboratory's acknowledgement returns on the order response.
Segments read and written
The platform reads a fixed set of segments on the way in and writes a fixed set on the way out. The table names each segment, what it carries, and where it is used.
| Segment | Carries | Where it is used |
|---|---|---|
| MSH | The sending and receiving systems, the message type and a control identifier | Read on every message and written on every reply |
| PID | The patient's identifiers, name, date of birth and sex | Read on results and visit messages |
| PV1 | The visit class, the attending clinician and the location | Read on visit messages |
| ORC | The order control code with the placer and filler numbers | Read and written on order messages |
| OBR | The ordered test or study and its accession | Read on results and written on outbound orders |
| OBX | One result value with its units, reference range and abnormal flag | Read on results |
| MSA | The acknowledgement verdict and the control identifier it answers | Written on every reply |
| ERR | The location and the reason for a rejected message | Written on a rejection |
Acknowledgement verdicts
A sending system reads one of three application verdicts, built on the trusted side and carried back unchanged by the bridge. The raw message is stored durably at receipt, so a verdict reports whether the content applied, and the message itself is held either way.
| Verdict | Meaning |
|---|---|
| Accepted | The message mapped and validated, and the record took it. |
| Application error | The message was received and held, and a fault stopped it applying, so the sender may resend. |
| Rejected | The message was received and held, and its content fell outside what the record accepts. |
A rejection keeps the message
Structural receipt stores the raw message before validation runs, so even a rejected message stays available for review and replay. The verdict marks the message rather than removing it.
Character sets and delimiters
The platform decodes each message with the character set the header declares rather than an assumed default, so a patient name written in an Indian script arrives intact through the record. This matters where a registration feed carries names across several scripts within one working day.
The delimiters that separate the fields are read from the message header rather than assumed, so a sender that varies them is read correctly. Reading both the character set and the delimiters from the message itself keeps the parse faithful to what the sender wrote.
Update semantics
An update message distinguishes a field left out from a field explicitly emptied, and the platform honours that distinction on the way into the record. An omitted field leaves the stored value as it stood, while an explicitly emptied field clears it.
This governs how a patient-update message revises a held record: a feed that omits a phone number preserves the one on file, and a feed that sends an empty phone number clears it. Carrying the distinction through the parse keeps an update from wiping a value it meant to leave alone.
Common confusions
Which way does an order message run?
An order message runs in both directions. An external system places an order into Pensieve, and Forge routes an order out to a laboratory, with the laboratory's acknowledgement returning on the order response message.
Does an accepted verdict mean the result was verified?
An accepted verdict means the message mapped and validated and reached the record. Clinical verification of a result is a separate step a person takes in the record, held apart from the interface verdict.
What decodes a non-Latin name?
The platform reads the character set the message header declares and decodes the message accordingly, so a name in an Indian script is carried through as the sender wrote it.
Map an incoming feed's fields to the record in mapping fields, and see the resources on the FHIR interface.