Processing Results Feeds
This page outlines considerations when processing Orders and Observations.
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.
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.
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).
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.
OBX-3.1 values found within a single ORDER_OBSERVATION 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.
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.