On this page:

13.8Processing ORU (Results) Messages

 

This page outlines considerations when processing Orders and Observations.

13.8.1Unsolicited Observation Request (ORU^R01)

 

ORU^R01 messages contain details about a result of some sort (expressed in HL7 v2.x via the OBR segment), and a series of observations attached to this result.

These messages are typically used to convey Laboratory reports (e.g. from an HIS to an archive, or from an LIS to an HIS). They are also often used to convey other types of clinical reports such as Radiology reports, Notes, etc.

Observation Identification

When converting an HL7 v2.x ORU^R01 message into equivalent FHIR resources, one significant challenge is how to uniquely identify OBX segments and associate them with their Observation resources.

The design of the OBX segment in the HL7 v2.x standard does not provide a field in which an identifier may be provided for the individual observation; however, the outer report receives a unique identifier via the OBR-2 (placer order number) and/or OBR-3 (filler order number) fields.

This can be an issue when an observation request is updated. For example, consider a preliminary lab report that is received with five OBX segments in an ORU^R01 message. Subsequently, another ORU^R01 message is received that updates this report and now includes the original five OBX segments as well as five new ones. There is no trivial way for the system to know which OBX segments correspond to existing Observation resources, and which OBX segments correspond to new Observation resources.

Smile CDR has several strategies for dealing with this problem, each of which has trade-offs but any of which can be used to produce acceptable results. These strategies are configured via the hl7v2_fhir_mapper_obr.observation_identification_mode configuration property.

This property may have one of several values:

  • DELETE_ALL – When using this mode, every time an ORU^R01 message is processed, any existing Observation resources that are referenced by the DiagnosticReport resource are deleted and a new set is created. In other words, if an ORU^R01 message is updating a previously saved report, all previously created Observation resources for that report are deleted, and a new set is created.

    This strategy can be useful because it is generally guaranteed to produce consistent results. As such it is the default configuration. However, it does have a significant disadvantage in that it provides no convenient means of tracing the history of an individual Observation since an update manifests itself as a delete and a create rather than an update. It can also lead to a large number of unneccesary repository data changes (deletes and creates) if many updates are received for individual results that don't actually contain many changes.

  • USE_PARENT_IDENTIFIER_AND_OBX_CODE – This mode attempts to create a unique identifier for the observation by creating a value for Observation.identifier that uses the system drawn from DiagnosticReport.identifier.system and a constructed value for Observation.identifier.value consisting of DiagnosticReport.identifier.value, followed by a dash (-), followed by the observation code value found in OBX-3.1 (Observation Identifier Code).

    This strategy can produce more useful results for updates since any existing unchanged Observation resources will not result in spurious changes in the repository. It also means that modifications to existing Observation resources will be reflected as updates to existing resources, which is much more natural to repository clients.

    There are two important trade-offs to consider when using this strategy:

    • First, any duplicate OBX-3.1 values found within a single PATIENT_ORDER group in a source message will result in a processing failure, and the message will be rejected. This is because unless the identifier code is unique within the message, it is not possible to generate a unique identifier for the Observation. For many sending systems this is not an issue but for some it may be.

    • Second, any OBX segments that are removed from an update message will not result in the corresponding Observation resource being deleted. This is generally desirable behaviour but it should be considered when implementing this strategy.