DSTU2

This page is part of the FHIR Specification (v1.0.2: DSTU 2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

A.2.1 Purpose

The FHIR USLab Order Implementation focuses on identifying the requirements, specifications and standards, and on providing the implementation guidance for electronic ordering of laboratory tests in the US Realm using the FHIR in the RESTful framework. The scope of the Laboratory Orders Interface Use Case includes requirements to enable a the US Realm using the FHIR in the RESTful framework. The scope of the Laboratory Orders Interface Use Case includes requirements to enable a particular implementation of Electronic Health Record System (EHR-S) to use standardized structured data in a defined inter-organizational laboratory transaction. The Use Case requirements are directed at laboratory test orders between an Ambulatory Provider's EHR-S and a Laboratory's Laboratory Information System (LIS). Future versions of this implementation may harmonize with existing guides to extend interoperability of laboratory results across care settings, e.g., acute care.

A.2.1 Audience

This guide is designed for use by analysts and developers who require guidance on FHIR resources, elements and specific extensions relative to the Laboratory Results Interface (LRI) initiative and HL7 Lab Order Conceptual Specification. Users of this guide must be familiar with the details of the FHIR Specification and resource processing. This guide is not intended to be a tutorial on that subject.

A.2.1 Conventions

This guide adheres to the following conventions:

  • The guide is constructed assuming the implementer has access to the FHIR Specification. Although some information from the standard is included in this implementation guide, much information from the standard has not been repeated here.
  • The guide is constructed assuming the implementer SHALL conform to the FHIR RESTful API
  • The rules defined in the FHIR Conformance Profile were used to document the use case for, and constraints applied to, the resources described in this guide.

A.2.1 Use Case - Ambulatory Care Setting

This use case was developed as a collaborative effort between the HHS/ONC Standards and Interoperability Framework Laboratory Orders Initiative, the California Health Care Foundation, and the HL7 Orders and Observations Work Group.

This guide defines the following terms from the historic paper-based workflows in relation to the supported use cases for electronic exchange of laboratory order information to the OML message structure as:

A.2.1.1 Definitions

  • Measurement - a single observation value or calculation recorded using a single Observation Resource. Note that multiple representations of the same measurement may require multiple observations, e.g., quantitative and qualitative statement of the same measurement.
  • Orderable Test or Laboratory Order - a DiagnosticOrder Resource item requesting one or more measurements (Observation Resources).
  • Requisition - One or more Orderable Test(s) transmitted as a new or appended DiagnosticOrder Resource.

A.2.1.2 Scope

EHR-S and a LIS in an ambulatory care setting. This includes new, scheduled, add-on laboratory orders and the cancellation of laboratory orders that were previously placed. This Use Case has four scenarios:

  • Scenario 1: Electronic Ordering of New or Scheduled Laboratory Test(s)
  • Scenario 2: Electronic Ordering of Add-On Laboratory Test(s)
  • Scenario 3: Requesting the Cancellation of a Previously Placed Laboratory Order by the Order Placer
  • Scenario 4: Laboratory Cancellation of a Previously Placed Laboratory Order

A.2.1.2.1 In Scope

  • Electronic ordering of laboratory tests and/or panels in the ambulatory setting for the US Realm.
  • Defining the core data elements required for ordering ambulatory laboratory tests and/or panels.
  • Laboratory Order Placer (i.e., Ordering Provider) may designate other non-order placers to receive results.
  • Harmonization of data elements that are used in both laboratory orders and results.

A.2.1.2.2 Out of Scope

  • Requesting Status on a Previously Placed Laboratory Order Electronic ordering of laboratory tests and/or panels in an acute care setting, internally within a laboratory, referral orders placed between laboratories, and laboratory orders outside the US Realm.
    • Note that the authors of this guide did not validate whether constraints on components should be loosened to support these use cases. This will be addressed in a future version, including definition of minimal incremental profiles to support these use cases. Until such time, implementers are not discouraged from attempting to use this guide for those use cases but should recognize that they may not be able to remain fully conformant. The authors invite comments from implementers on their experience to inform the next version.
  • Concepts related to: order queues, clearing houses, or other transport-level mechanisms and protocols that may be used to transfer or hold laboratory orders for later retrieval by a laboratory selected to perform the laboratory service.
  • Multi-order status requests (for one patient or multiple patients).
  • Specification of the required/supported error condition codes as part of acknowledgments in REST or with a FHIR Resource.
  • Laboratory orders not transmitted electronically.
  • Secondary uses of laboratory order data.
  • The human mechanisms required to resolve differences between the order identifier and the specimen label.
  • Specimen labeling and transport.
  • Physical transport level confirmations.
  • Interactions between the LIS and EHR System for add-on orders beyond the transmission of the order (to address scenarios such as insufficient specimen or late arrivals of add-on orders).

A.2.1 Actors

There are two actors that have responsibilities related to the conformance profiles defined in this document:

  • Laboratory Order Sender - The originator of the DiagnosticOrder Resource Instance that declares conformance to "RESTful FHIR" and FHIR profiles defined in this guide. This actor is the Organization Resource referenced through the .orderer (Practitioner) Resource within FHIR.
  • Laboratory Order Receiver - The receiver of the DiagnosticOrder Resource Instance that declares conformance to "RESTful FHIR" and FHIR profiles defined in this guide. This actor is implied within FHIR. ( i.e. not explicitly referenced in the DiagnosticOrder Resource Instance or the linked resources).

A.2.1 Orders for Ambulatory Care Context Diagram

Figure 2-1. Context Diagram

Figure 2-1. Context Diagram

A.2.1.1 User Story

A.2.1.1.1 Use Case Assumptions

  • Providers (.orderer) securely access clinical information through an EHR system.
  • Users have a need to exchange laboratory order data between ambulatory care EHRs and laboratories.
  • An EHR system has the ability to manage a laboratory order, including generating the laboratory requisition and sending it to a laboratory.
  • Requisitions are defined by laboratory practice and their exact instantiation is determined by trading partner agreement.
  • An EHR system is capable of generating an order electronically and is capable of receiving and processing acknowledgments, results and cancellations.
  • A LIS is capable of receiving orders and cancellation requests, and generating acknowledgments and cancellation notifications.
  • The Laboratory is capable of receiving laboratory orders electronically and in standardized structured format.
  • The EHR System and LIS both use data models that include discrete representations of patients, clinician end-users, laboratory requisitions, laboratory orders (which include tests and panels), and laboratory test results (minimally at the level of individual analytes).
  • The USLabResult Profile and the USLabOrder Profile will be synchronized with the goal that a laboratory that receives an order conforming to the USLabOrder Profile should be capable of responding with a message conforming to the USLabResult Profile.
  • Appropriate security and transport protocols, patient identification methodology, order identification methodology, patient consent, privacy and security procedures, coding, vocabulary, error handling, and normalization standards have been agreed to by all relevant participants.
  • Legal and governance issues regarding data access authorizations, data ownership, and data use are in effect.
  • Established network and policy infrastructure exists to enable consistent, appropriate, and accurate information exchange across provider systems, data repositories and locator services. This includes, but is not limited to:
    • Methods to identify and authenticate users;
    • Methods to identify and determine Providers of care;
    • Methods to enforce data access authorization policies;
    • Methods to ensure the veracity of data;
  • Detailed audit trails are kept as necessary by all participating systems.
  • Security and privacy policies, procedures and practices are commonly implemented to support acceptable levels of patient privacy and security; i.e. HIPAA, HITECH and EHR certification criteria.

A.2.1.1.2 Pre-Conditions

Note: The pre- and post-conditions may not apply to all scenarios.

  • The Provider (.orderer) has performed all of the necessary checks for medical necessity, insurance eligibility and any needed pre-authorizations.
  • After a Provider (.orderer) enters a laboratory order, the EHR system generates an electronic laboratory requisition containing pertinent information as well as appropriate identifiers, such as patient, order, and specimen.
  • The Laboratory's test compendium has been entered (manually or via automation) into the EHR system.
  • Information for the cancellation requests for laboratory orders has been accurately captured within the EHR System.
  • All appropriate billing information is available within the EHR system.
  • Specimens are labeled in accordance with established policies and procedures for specimen submission and can be linked to the order 4

4CLSI. Specimen Labels: Content and Location, Fonts, and Label Orientation; Approved Standard. CLSI document AUTO12-A. Wayne, PA: Clinical and Laboratory Standards Institute; 2011; ISBN 1-56238-748-0; ISSN 0273-3099, Volume 31 Number 7.

A.2.1.1.3 Post-Conditions

  • Laboratory orders are successfully transmitted electronically from the Provider's (.orderer) EHR System to the Laboratory's LIS. The Receiving Laboratory electronically transmits acknowledgment of receipt of the laboratory order. The received order may be placed into an electronic queue for further processing depending on laboratory workflow (although order queues are out of scope for this Use Case).
  • Specimen(s) associated with the laboratory order are collected and, if necessary, transported to the laboratory.
  • The laboratory processes the laboratory order and associated specimen(s). This step may include retrieval and processing of laboratory orders from a queue or list of received orders. Order queues may be used in the LIS to hold electronic laboratory orders until associated specimens are received and the appropriate patient matching and registration occur (although order queues are out of scope for this Use Case). After patient matching and registration, the electronic order may be electronically processed in the LIS.
  • If the laboratory order and specimen(s) are satisfactory for testing the laboratory will perform, or attempt to perform, the test(s).
  • The laboratory test result is obtained, entered/released in the LIS, and sent to the Provider's (.orderer) EHR System. This is covered within the Laboratory Results Interface Use Case.
  • Successfully transmit laboratory order cancellation request from the Provider's (.orderer) EHR system to the Laboratory's LIS.
  • The Laboratory's LIS has electronically received the laboratory order cancellation request.
  • The Laboratory's cancellation of a requisition (one or more orders) or an individual order has been electronically received by the Provider's (.orderer) EHR System. Note that cancellation of part of an order must be done through a DiagnosticResult Resource as defined in the USLabResult Profile.

A.2.1.1.4 Scenario 1 - Electronic Ordering Of New Or Scheduled Laboratory Test(S)

Using an EHR System, a Provider (Order Placer) orders one or more new laboratory tests or scheduled laboratory tests (including future tests) to be performed by a laboratory.

A.2.1.1.4.1 Functional Requirements

todo

A.2.1.1.4.2 Sequence Diagram for Electronic Ordering Of New Or Scheduled Laboratory Test(s)

Figure 2-3

REST behavior: USLabOrder Orderer is the server (i.e. in Pull mode)

Figure 2-2

REST behavior: USLabOrder Receiver is the server (i.e. in Push mode)

A.2.1.1.5 Scenario 2 - Electronic Ordering Of Add-On Laboratory Test(S)

Using an EHR System, a Provider (Order Placer) adds one or more additional tests to a previously transmitted test requisition. Note that if there is no need to relate the additional order to the specimen associated with a prior order, the regular new order must be followed. At the time the provider requests an order to be added, this may occur when the specimen is already drawn or still needs to be drawn. The provider may not know which situation is in place. Therefore, this guide suggests that until there is more clarity on how the provider's ordering system is updated with specimen collection information, the provider's add-on order request is communicated as a regular order and may use, if known:

  • The .identifier, when using non-unique order numbers, of the original order; and/or
  • The .identifier that was used when the original order was placed; and/or
  • The Specimen.identifier or other specimen data of the specimen the order is intended to be added to.

Using the first two methods make it appear, other than the transaction date/time, as if the order was placed together and consistent with the original order. The third method clearly associates the new order with the same specimen that was already collected for a prior order. Note that depending on the state of the order fulfillment, the Laboratory may not be able to perform the requested test against the intended specimen as it may be too late for a number of reasons (e.g., insufficient specimen, specimen too old).

A.2.1.1.6 Scenario 3 - Requesting The Cancellation Of A Previously Placed Laboratory Order

The Provider (.orderer) determines that one or more orders from a previously transmitted electronic laboratory requisition needs to be canceled and requests via the EHR that the Laboratory cancel the performance of the laboratory order(s). Since the Provider does not know how far the Laboratory has progressed with the performance of the test, or may not even have received the specimen, the Provider must use the USLabOrder DiagnosticOrder Cancel Profile. The Laboratory determines whether the test can be canceled, or whether the order has progressed too far to cancel. Laboratories must use the USLabReport DiagnosticResult Cancel Profile. Once the Provider receives any preliminary or final results, the test cannot be canceled anymore and the Provider shall not use the USLabOrder DiagnosticOrder Cancel Profile. anymore.

A.2.1.1.6.1 Functional Requirements

todo

A.2.1.1.6.2 Sequence Diagram

Figure 2-4

REST behavior: USLabOrder Orderer is the server (i.e. in Pull mode)

Figure 2-5

REST behavior: USLabOrder Receiver is the server (i.e. in Push mode)

A.2.1.1.7 Scenario 4 - Laboratory Cancellation Of A Previously Placed Laboratory Order

The Laboratory may cancel laboratory orders and send a cancellation notification message to the Provider (Order Placer) because it is unable to perform the laboratory order, independent of the Provider requesting cancellation. This applies to an original/initial order or an add-on order. Laboratories can cancel a test request received by the LIS (or queue for this purpose) any time before the test report (preliminary or final) is transmitted to the provider(s). Laboratories must use the USLabReport DiagnosticResult Cancel Profile. See that Implementation Guide for details.

A.2.1 Key Technical Decisions

A.2.1.1 Profile And Component Architecture

This guide uses FHIR profiles on the following resource to define a minimum set of requirements to enable the successful exchange of laboratory orders:

  • DiagnosticOrder
  • DiagnosticReport
  • Organization
  • Media
  • Organization
  • Patient
  • Practitioner
  • Specimen

The main objective is to ensure that EHR systems and Laboratory systems can exchange laboratory orders with minimum if any modifications from one combination to another combination of software, while maintaining flexibility to enable software developers to provide more capabilities using the same core Resource definitions.

A.2.1.2 Use Of Vocabulary Standards

This guide calls for specific vocabulary standards for the exchange of laboratory information such as LOINC and SNOMED. Standard vocabularies, particularly coded laboratory tests and their results, enable automated decision support for patient healthcare, as well as for public health surveillance of populations. Value Sets resource are provided as part of this implementation.

A.2.1.3 Scope Of Implementation

Due to receiving system variations and need, this guide does not specifically indicate for each field whether to store it or not. This is left to the individual system's scope and purpose.

A.2.1.4 Ask At Order Entry (AOE) Observations

Ask at Order Entry (AOE) responses are recorded as observations that provide critical information for the calculation or interpretation of some lab results or to satisfy state and federal health agency mandated information gathering requirements, e.g., for blood lead testing. Not every order will have the need for AOE questions and associated observations. The lab will indicate if and which AOEs to include with the order in their test compendium. Examples of the type of information gathered from a patient include employment information, pregnancy status, the date of the last menstrual period, mother's age, and questions about family and personal history. In some cases there may be AOEs that request the outcome of previous results phrased as a question, e.g., "Was your previous pap abnormal?" AOE responses can take several formats, including but not limited to

  • Yes/No (and coded) to answer questions like "Is this your first pregnancy?"
  • A code drawn from a value set to provide a coded response to, e.g., "What ethnicity do you consider yourself to be?"
  • A number with units for the mother's age
  • A date format for the patient's last menstrual period.

.supporting information element with type Reference(Observation) must be used in the DiagnosticOrder Resource to convey these Ask at Order Entry questions.

Although not strictly asked at order entry, other supporting clinical information about the patient collected during specimen collection, e.g., fasting status of the patient, are considered AOE observations for purposes of this guide and must be communicated using the .supporting information element with type Reference(Observation) as well.

LOINC shall be used as the standard coding system for AOE questions if an appropriate and valid LOINC code exists. The LOINC and local code describing the question will be placed in Observation.name element. Appropriate and valid status is defined in the LOINC Manual Section 11.2 Classification of LOINC Term Status. If a local coding system is in use, both the LOINC and the local code should also be sent to help with identification of coding issues. When no valid LOINC exists, the local code may be the only code sent.

A.2.1.4.1 Special Considerations

Note that various Ask at Order Entry questions may appear to have specific elements in FHIR Resources. When a clinically relevant value is asked through an Ask at Order Entry question it must be conveyed through the OBX segments as described above as these values are used for clinical interpretations rather than through a seemingly similar FHIR element. The following provide specific examples and guidance whether to use a FHIR element or the supporting information element with type Reference(Observation). This is list is not meant to be exhaustive:

  • Date of Birth - Always use Patient.birthDate and should never be asked as an AOE as there is only one at any point in time.
  • The extension us-core-race(http://hl7.org/fhir/StructureDefinition/us-core-race) is provided for demographic (administrative/billing), not clinical use and is bound to define five race categories as prescribed by federal standards. The lab must provide an AOE for those tests where Race drives the interpretation of results. The value must be determined by the Ordering Provider and must be sent as the .supporting information element with type Reference(Observation). Note that state and/or national regulations may dictate other behaviors.
  • The extension us-core-ethnicity(http://hl7.org/fhir/StructureDefinition/us-core-ethnicity) is provided for demographic (administrative/billing), not clinical use and is bound to specify two ethnicity categories as prescribed by federal standards. The lab must provide an AOE where Ethnicity drives the interpretation of results. The value must be determined by the Ordering Provider and must be sent as the .supporting information element with type Reference(Observation. Note that state and/or national regulations may dictate other behaviors.

More specific race and ethnicity values are available, but not limited to, those found v3 Code System Race and v3 Code System Ethnicity.

A.2.1.5 Communication Of Other Clinical Information Or Prior Results

Should the need arise to send results not obtained at the time of order entry or specimen collection and/or those requiring full results report structure such as culture/sensitivity reports. Use the USlabOrder DiagnosticReport priorResults extension.

A.2.1 Error Handling

Refer to the FHIR Specification on REST status codes and the use of the OperationOutcome Resource when further information about the transaction error is needed. Note: The error handling specifications are currently not fully defined for this implementation.

A.2.1 Additional Implementation Guidance - Other

A.2.1.1 Clinical Laboratory Improvement Amendments Considerations

In the United States, clinical laboratory testing of human specimens is regulated by the Clinical Laboratory Improvements Amendments of 1988 (CLIA). Several sections of the regulations implementing CLIA impact how electronic laboratory data is formatted for the US Realm and these are outlined in this section. Impacted areas include mandatory test request requirements. CLIA Regulation Specifics .

A.2.1.2 Mandatory Ordering Requirements

Section 493.1241 of the CLIA Regulations requires the laboratory to have a written or electronic request for patient testing from an authorized person, and defines items that must appear as part of a clinical laboratory test request . The laboratory may accept oral requests for laboratory tests if it solicits a written or electronic authorization within 30 days of the oral request and maintains the authorization or documentation of its efforts to obtain the authorization.

Interpretative guidelines on the elements required in a test requisition . Specific fields impacted include the following:

FHIR element CLIA Requirement.
Patient.name The patient's name or unique patient identifier.
Patient.gender The sex and age or date of birth of the patient.
DiagnosticOrder.orderer The name and address or other suitable identifiers of the authorized person requesting the test.
DiagnosticOrder.orderer The individual responsible for using the test results.
Practitioner.organization The name and address of the laboratory submitting the specimen.
Practitioner.telecom|Organization.telecom Contact person to enable the reporting of imminently life threatening laboratory results or panic or alert values.
DiagnosticOrder.name The test(s) to be performed.
DiagnosticOrder.supportingInformation For Pap smears, the patient's last menstrual period, and indication of whether the patient had a previous abnormal report, treatment or biopsy.
Specimen.type The source (type) of the specimen, when appropriate.
Specimen.collection.collected[x] The date and, if appropriate, time of specimen collection.
DiagnosticOrder.supportingInformation Any additional information relevant and necessary for a specific test to ensure accurate and timely testing and reporting of results, including interpretation, if applicable.

A.2.1.3 Glossary

  • Analyte: Component represented in the name of a measurable quantity. It is the most granular level at which measurements are made and always represented using a single Observation segment group
  • Cancellation: Act of cancelling the order.
  • Electronic Health Record: Clinical information for a specific patient that is stored electronically within an EHR-S. Electronic Health Record System (EHR-S) This IG uses this term in the same context as stated in the "HL7 EHR System Functional Model White Paper" Section 4 Definitions (HL7 2004 www.hl7.org): "It is important to note that the DSTU does not attempt to establish another definition for EHR Systems, but chooses to utilize existing definitions that include the concept of EHR Systems as a system (at least one) or a system-of- systems that cooperatively meet the needs of the end user."
  • Future Order: A future order is an order with a start date/time where that start date/time indicates the earliest time the specimen can be collected.
  • Laboratory: A facility or organization that performs laboratory testing on specimens for the purpose of providing information for the diagnosis, prevention, treatment of disease or impairment, or assessment of health for humans. Laboratory Information System (LIS) An information system that receives, processes, and stores information related to laboratory processes. LIS may interface with HIS and EHR applications. This definition is very minimal and omits many features and capabilities that are typically associated with laboratory information systems. This minimal characterization is intentional, as to include the broadest possible set of LIS systems in the use case. The minimal nature of the definition by no means excludes LIS with significantly greater capabilities.
  • Laboratory Order: a DiagnosticOrder Resource item requesting one or more measurements (Observation Resources). Synonymous with a Requisition when referring to a single DiagnosticOrder Resource item.
  • Laboratory Order System: Software, either stand-alone or as part of an EHR system, used by a Provider (Order Placer) to manage a laboratory order, including generating the laboratory requisition and sending it to a laboratory. Typically a laboratory order system is an integral part of an order management system that enables users to manage orders for many different types of services, procedures, supplies, etc. Since this guide only focuses on data exchange relative to laboratory orders it is purposely using a very limited definition.
  • Laboratory Requisition: A set of information that constitutes an official request for one or more laboratory tests to be performed on an individual patient. A laboratory requisition is specified in a clinical setting and communicated to a laboratory as a discrete paper or electronic artifact. Laboratory requisitions always include at least one test order. In terms of a FHIR order transaction it represents one or more DiagnosticOrders Resource item(s).
  • Newborn: The precise cutoff when a patient is considered a newborn or an infant is subject to interpretation and this guide does not intend to provide a definitive answer to that. For further background the reader is directed to the following resources:
  • Orderable Test: A request to perform an individual test or panel. It always refers to a single DiagnosticOrder Resource item. and may have one or more associated analytes (bservations).observations
  • Panel: While there are differences in the meanings of the terms "panel" among various laboratories, for the purposes of this guide, it is defined as a grouping of procedures that measure multiple analytes from a single specimen (or multiple specimens in some cases) and can be requested through one laboratory order. This is also referred to as a battery. For example, a CBC or a urinalysis may be referred to as a panel.
  • Order Set: A set of laboratory orders that involve multiple tests and panels and that may require multiple specimens, but can be requested as a single unit for convenience. For example, a "diabetic order set profile" might include a CBC, a glycosylated hemoglobin test, and a urinalysis. The term "panel" is frequently used interchangeably with "order set", thus an order set profile that contains a variety of laboratory test orders that may be on its own or be combined with other test orders (e.g., radiology image, consult, etc.) can be considered an order set. Order sets shall not be communicated to the laboratory. Request for Cancellation (RFC) Request by the Provider (Order Placer) not to perform the order.
  • Test: A medical procedure or named set of related procedures that involves analyzing one analyte using a single sample of blood, urine, or other specimen from a patient for the purpose of diagnosing a disease or medical condition, planning or evaluating treatment, or monitoring the course of a disease.