by Rahul Bhagat
Patient location is an important field and used by many different clinical systems. I remember it being used in an Infection Control system to track the movement of patients who had antibiotic resistant infections (MRSA).
PV1-7/PV1-8/PV1-9/PV1-17/PV1-52: Doctors & Other Healthcare Providers
These fields contain the identifying information of doctors and other healthcare providers who are caring for or were involved in the care of the patient. PV1-7 is for the attending doctor, PV1-8 is for the referring doctor, PV1-9 is for doctor(s) consulted on the case, PV1-17 is for the doctor who admitted the patient (inpatient) and PV1-52 is for other healthcare providers like nurses and physiotherapist who are involved in the care of the patient.
These fields too are complicated compound fields but only a few components are used. The first component is the “ID Number” and it is used to uniquely identify the doctor. In Toronto, every doctor has a unique CPSO (College of Physicians and Surgeons of Ontario) number, which is often used as the ID number. But you can use a local or internal ID. As long as the number uniquely identifies a doctor, it is good to go.
Second to seventh components of the field are for the doctor’s name. I would always populate the sixth and the seventh component with DR and MD respectively. After all, it takes years of toil to acquire those letters, so the least I could do was make sure it was part of the doctor’s name.
The ninth component of the field is for the organization that assigned the “ID number” (first component) to the doctor. So if the CPSO number were being used then “CPSO” would go in this field.
PV1-19: Visit Number
Every patient visit to a healthcare facility is assigned a unique number called a visit number. This field holds that number. Before we answer why we need to assign a unique ID to every patient visit, you need to know how healthcare records are organized.
Healthcare records are organized in a hierarchy. At the top is the patient record, which is identified by the PID-3 (Patient Identifier) field. For each patient record, there could be one or more accounts, which are identified by an account number. These account numbers are found in the PID-18 (Patient Account Number) field. An account number is used for billing purposes to which all patient expenses are charged. Each account could have one or more patient visit (PV1-19) fields associated with it. So for a recurring visit like dialysis or physiotherapy, you can have a dedicated account to which all related visits are billed. And for one-off visits, such as an emergency, you have a separate account, both under the same patient record.
Now to the question why we need to assign a unique ID to every patient visit. A patient visit can lead to an order for a lab test, medication or some other service. By having a unique ID for every visit, it is easier to track orders by the visit number. A visit number also makes it easier to merge patient records.
This is an important field and it is almost always populated.
PV1-44/PV1-45: Admit & Discharge Date/Time
These fields are used to capture the date and time of patient admittance and discharge. They are obviously used for inpatient visits but are sometimes also used for emergency patients and outpatients.
Order Message - Order Entry
It is time to turn our attention to another important group of HL7 messages called order messages. Their details are in Chapter 4 of the HL7 spec.
We call them order messages because messages in this group are used to order for supplies and services. It is only because of these messages that a system is able to electronically request medication from pharmacy, order a lab test, or request a patient’s meal through the TV.
The HL7 spec defines an all-purpose order message type called a General Order message ORM^O01. This message type can be used to place different types of orders - medication, lab test, supply etc.
ORM^O01 has two very important segments - a Common Order Segment (ORC) and an Order Detail Segment. ORC is straightforward and we cover it in detail further below.
The Order Detail segment changes with the type of order being placed. Usually, it is an OBR (Observation Request segment), but for diet orders, it changes to ODS, for pharmacy, to RXO and for supply orders it is RQD. This is necessary to account for the unique information needed by different order types.
Things changed after version 2.3. Specialized order messages with a fixed message structure were created. These were OMG^O19 for clinical orders, OML^O21 for lab orders, OMD^O03 for diet orders, RDE^O11 for pharmacy orders, and so on.
It was recommended that these specialized order messages be used going forward, but ORM^O01 is such a widely used and entrenched message type that it continues to be the dominant and most important order message. If you learn about only ORM^O01 and OBR segment, it will take probably care of 80% of cases. For others, you can always turn back to the HL7 spec.
Before we take a closer look at segments ORC and OBR, let’s get some important concepts out of the way.
Placer/Filler
Whenever an order is being placed for supplies and services, there are at least two systems involved in the transaction. The system that places the order and the system that fills the order (or provides the service). In HL7 parlance, a “Placer” is the system that places the order and a “Filler” is the system that fulfills the order or provides the services/supplies.
Suppose a physician enters an order for a blood test in the HIS (hospital information system), which converts that order into an HL7 message and sends it to the lab system. Here the HIS is the “placer” and the lab system, which fills the order, is the “filler”.
It is not necessary for the placer and the filler to be separate systems; they can be the same system. For example, when an order is placed internally within a department.
Every time an order is created, the placer assigns it a unique number (Placer Order Number) before sending it to the filler. When the filler receives the order, it also assigns a unique number to the order (Filler Order Number) before any further processing is done. These numbers are very important and you will often need them for tracking and debugging order messages.
Order Control
Not every order goes through the same process. An order could be modified, cancelled, or put on hold. To account for all these different situations, ORC has an order control field (ORC-1) to communicate the current status of the order to the filler.
When the placer first creates an order, the status of the order is set to NW (New Order). Subsequently, if that order needs to be cancelled, the placer sends another order message with the same placer number as that of original order but the status is set to OC (Order Cancelled).
When the filler reads this second message, it will go ahead and cancel the order in its system. After cancellation, an acknowledgement with the order status CR (Cancelled as Requested) is sent back.
There are a lot of codes for order statuses and they are all there in Chapter 4 of the HL7 spec. Just to give you a taste, if the filler is not able to cancel the order, because maybe the test has already been performed, it will send back an acknowledgement with code UC (Unable to Cancel).
Segment Rules
The way ORC and Order Detail segments (OBR, ODS, RXO etc.) show up in a message can be confusing at times. But there are rules and if you know them, understanding the occurrence of these segments in a message becomes pretty straightforward.
For the sake of simplicity, we will use OBR for order detail segment.
Both ORC and OBR contain details of an order and there are many fields that are common between these two segments. A rule of thumb with these overlapping fields is that the value in ORC always overrides the value in OBR.
The best way to distinguish between these segments is to see ORC as the control segment and OBR as the data segment. Yes, they are both data segments but from the perspective of an order, ORC contains only the meta-data of an order, such as the status of the order, placer ID and filler ID. OBR, on the other hand, contains actual order details like what is being ordered and the
details of the specimen (blood, urine etc.).
For a new order, you need an ORC/OBR pair to define the complete order. An ORC will spell out all the meta-data information and the OBR will contain the actual details of the order. However, for cancellation of an existing order, there is no need for an OBR. Just an ORC with the cancel (CA) status is enough.
There is another thing to keep in mind about order messages. A single HL7 message can have more than one order. It will just have more than one occurrence of an ORC/OBR pair or multiple ORC segments (for the case where more than one order is being cancelled).
Let’s take a look at these segments now.
ORC – Common Order Segment
As mentioned earlier, an ORC segment is like the control segment of an order. It contains meta-data information about the order and is required in every order message. There are thirty fields in this segment but as you must have guessed, not everything is used.
ORC-1: Order Control
This is the only required field in the ORC segment and it is the most important field. It contains a two character “control code” to determine the status of the order. There are too many order control codes so I am just going to list the three categories that they are grouped under.
• Request from Placer (New Order - NW, Cancel Order - CA etc.)
• Acknowledgement from Filler (Order Accepted - OK, Cancelled as Requested - CR etc.)
• Notification from filler (Order Cancelled - OC, Unable to Cancel - UC etc.)
ORC-2 & ORC-3: Placer Order Number/Filler Order Number
ORC-2 (Placer Order Number) is the unique order number assigned by the placer of the order. This field is duplicated in the OBR segment (OBR-2). Either the ORC-2 or the OBR-2 should always be valued. Both of them cannot be empty. However, it is all right if both fields are populated, as long as they have the same value.
Similarly ORC-3 (Filler Order Number) is the unique order number assigned by the filler system. This field also has a duplicate in the OBR segment (OBR-3) and if it is not valued in the ORC, then it should be populated in the OBR.
ORC-7: Quantity/Timing
This field is not used anymore. Two new segments, TQ1 and TQ2 have taken over the role of defining the amount of medication, the frequency, the interval, the duration of administration and other details of an order.
These details become important for orders that involve activities like dispensing medication, making observations or collecting specimens.
The field is duplicated in the OBR segment (OBR-27).
ORC-12: Ordering Provider
This field contains the identifying information of the doctor/healthcare provider who placed the order. It is duplicated in the OBR segment (OBR-16) and should always be valued. If it is not present in the ORC, then it should definitely be there in the OBR segment.
ORC-21, 22, 23: Ordering Facility’s Contact Information
These fields are optional. They contain the name, address and the phone number of the organization that placed the order. In other words, it contains the placer’s contact information. These fields become relevant if the order is going to an external organization for processing, for example a private lab.
OBR – Order Detail Segment
There are many different flavors of order detail segment but the most common flavor is the OBR segment, which we will discuss here. It is used extensively in lab, radiology and other general order messages.
An OBR can be seen as a bridge segment between order and result messages. It is like the requisition form that goes with an order and comes back signed and filled with the result.
Some important fields in the OBR segment, from the placer point of view, are discussed below.
OBR-2 & OBR-3: Placer Order Number/Filler Order Number
As discussed earlier, OBR-2 (Placer Order Number) is a duplicate of the ORC-2 field. It holds the unique placer order number.
Similarly, OBR-3 (Filler Order Number) is the unique filler order number. It is a duplicate of the ORC-3 field.
OBR-4: Universal Service Identifier
This is the most important field in an order message. It is a required field and is mandatory because it holds the order code for whatever is being ordered. Without this code, filler won’t know what the order is for.
OBR-7 & OBR-8: Observation Date/Time & Observation End Date/Time
These fields are relevant only in situations where a sample is being collected for an order (blood for a blood test) or an observation is being taken (body temperature, blood pressure, etc.). If the observation is taken over a period of time, then both OBR-7 and OBR-8 are populated. For cases that are a single point in time, such as getting a blood sample, then only OBR-7 is populated.
OBR-16: Ordering Provider
This field contains the identifying information of the doctor/healthcare provider who placed the order. It is a duplicate of ORC-12. The ordering provider information should always be present in an order message. If it is not present in the ORC segment, then it should definitely be valued in the OBR segment (OBR-16).
OBR segment has many other important and commonly used fields, such as OBR-22 (Result Status Change Date/Time) and OBR-25 (Result Status) but they are populated by the filler system and sent back with the result message. We discuss them in the result message.
Result Message – Observation Reporting
Result messages complete the communication loop between the placer and the filler applications. Earlier, we saw order messages being used by placers to electronically order for supplies and services. Many of these orders generate observations and results that the filler sends back to the placer. HL7 messages that carry these results are known as result messages.
Unlike orders, there is just one type of result message, ORU^R01 (Unsolicited Observation Message). This message type is used extensively for sending all kinds of results - lab results, patient observations, clinical reports and many others. There is another type of result message, OUL^R21, for automating lab systems, but I have never seen it used. We don’t need to waste time on it.
The result message is covered in detail in Chapter 7 of the HL7 spec. It uses many of the same segments used by other message types (PID, PV1, ORC and OBR) but also defines a very important segment, the OBX (Observation/Result Segment). OBX segment is for the data in a result.
To get a good handle on the result message, you will need to know how results are organized in an HL7 message.
There are two ways in which a result/observation is reported through HL7. Text oriented reports (Narratives) and structured reports. Text oriented reports are formatted for human readability, so they are like a paper report with sentences and paragraphs. Structured reports, on the other hand, are meant for processing by the software. Here, the content of the report is distributed within the fields of the segments.
Both structured and text oriented reports are sent as ORU^R01 messages and follow the same message structure. The difference lies in the way OBX segments are populated. We will look at this difference when we discuss OBX segment.
Information in a result message is organized in a hierarchy. At the top of the hierarchy is the patient, which is represented by the PID segment. Each patient (PID) can have one or more result (OBR) in the message.
The OBR segment acts like the report header. It contains attributes common to all results in a set of tests. For those who don't know, lab tests & diagnostics are usually ordered as a set (or a battery or a panel) of many separate tests. When a doctor orders for the “vitals” of a patient, what she is asking for is the blood pressure, pulse and temperature of the patient. An order for an “electrolytes panel” means a blood test to measure the levels of sodium, potassium, chloride and carbon dioxide in the blood. All these are individual tests with their own results.
Individual test results are written in the OBX segment. One OBX segment holds the result for one test. So, a report for an “electrolytes panel” will have one header (OBR) followed by four OBX segments with the r
esult for sodium, potassium, chloride and carbon dioxide levels in the blood.
To recap, at the top of the hierarchy is the PID segment representing the patient. Each PID can have one or more OBR segments, which is the header for a result set. Each OBR can have one or more OBX segments to capture the result of individual tests within an order.
The hierarchy doesn't end here. You can have an SPM (Specimen) segment under the OBX which itself can have OBXs under it. It does get complicated, but for an overview the PID-OBR-OBX hierarchy is good enough. This gives you the foothold to learn further.
Let’s revisit the OBR segment now from the filler point of view.
OBR – Observation Request Segment
In a result message, an OBR segment serves as the report header for a test. A message can have multiple OBR segments, which just means that the message contains result for multiple order sets.
The OBR segment also acts like the turnaround document between the placer and the filler systems. The OBR in the order message contains fields populated by the ordering system (placer). The filler system uses the same OBR in the result message and populates additional filler fields and sends it back to the placer system.
A great example is the OBR-2/OBR-3 pair. The OBR-2 field holds the Placer ID, which is populated by the placer. The OBR-3 field is left empty when this order message is sent. When the filler responds either with an acknowledgement or the result, it populates the OBR-3 field with the Filler ID. Keep in mind that the result message also retains the OBR-2 value originally populated by the placer.
Some other fields commonly populated by the filler in an OBR segment include:
