This page is part of the FHIR Specification (v0.0.82: DSTU 1). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions
Published by: HL7 Orders and Observations Workgroup
Primary Author: Eric M Haas, Health eData Inc.
This Observation Profile is part of the The USLabOrder and USLabReport Implementation Guides. Its scope is US Realm ambulatory care and is based upon existing regulatory requirements for Laboratories and Electronic Health Record Systems (EHR-S) for ordering clinical laboratory results. The content has been modeled after the joint HL7 and The Standards and Interoperability (S and I) Framework Laboratory Orders and Results Interface Initiatives and the HL7 Lab Order Conceptual Specification and V3 Lab Normative Standard. However, much of the content is likely to be useable outside the ambulatory space and in other jurisdictions.
Four Observation profiles are defined to cover the various kinds of result values that are generated by laboratories and Ask at Order entry ('AOE') questions. These profiles are:
These profile are referenced in the USLab DiagnosticReport profile for one or more lab test results. They are also referenced for ask at order ("AOE") questions, other clinically relevant questions and for reporting prior results when requesting a test order using the USLabOrder DiagnosticOrder. Although not specified in this implementation, it may be used in other resources as well.
For the purposes of this profile, all elements listed in the differential profile view are Supported which means that the Laboratory Order/Results Sender SHALL be capable of supplying these elements and or extensions to the Laboratory Order/Results Receiver if the data is available. For the Laboratory Order/Results Receiver Supported means they SHALL consuming the supplied the elements and or extensions sent by the Laboratory Order/Results Sender.
In addition, for the Observation.code element, Supported means that the Laboratory Order/Results Sender SHALL be capable of supplying both the LOINC and the local code if both exist and the Laboratory Order/Results Receiver SHALL be capable of consuming both if they exist. For the Observation.valueCodeableConcept, Supported means that the Laboratory Order/Results Sender SHALL be capable of supplying both the SNOMED CT and the local code if both exist and the Laboratory Order/Results Receiver SHALL be capable of consuming both if they exist.
Both the Laboratory Receiver and Laboratory Sender MAY use the information to control their display of the information.
Profiles: | |
USLabObsCode | US Realm laboratory result using CodeableConcept Data Type for non-numeric results |
USLabObsQuantity | US Realm laboratory result using Quantity Data Type for numeric results |
USLabObsOther | US Realm laboratory result using one of Attachment|dateTime|Period|SampledData|string|timeData Type for results. |
USLabObsRange | US Realm laboratory result using Range Data Type for numeric results |
USLabObsRatio | US Realm laboratory result using Ratio Data Type for numeric results |
USLabObsPanel | US Realm panel observation |
Extensions: | |
uslabspecimenrejectreason | Specimen Rejection Reason : This extension describes the reason if a test is cancelled for specimen related reason. |
uslabobservationkind | Kind of observation : This extension is used to classify the kind of observation in Observation.value for laboratory reporting and to differentiate between actual test results, responses to filler questions when ordering tests and other unsolicted responses. This may be required to drive operational functionality. |