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
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
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
Observationresources that are referenced by the
DiagnosticReportresource 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
Observationresources for that report are deleted, and a new set is created.
Observationsince an update manifests itself as a
createrather 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.identifierthat uses the system drawn from
DiagnosticReport.identifier.systemand a constructed value for
DiagnosticReport.identifier.value, followed by a dash (
-), followed by the observation code value found in
OBX-3.1(Observation Identifier Code).
Observationresources will not result in spurious changes in the repository. It also means that modifications to existing
Observationresources will be reflected as updates to existing resources, which is much more natural to repository clients.
OBX-3.1values found within a single
PATIENT_ORDERgroup 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.
OBXsegments that are removed from an update message will not result in the corresponding
Observationresource being deleted. This is generally desirable behaviour but it should be considered when implementing this strategy.