Orders

Laboratory Order

1.  Laboratory Order. 
   1. Recommend listing LOINC as the code system for this element in accord with other HL7 Implementation Guides (CDA, FHIR, V2), public health reporting regulations, and use of this codesystem. 
   2. Additionally, guidance such as mapping to a LOINC where OrderObs is Order Only or Both can aid implementers on which LOINCs to support.
   3. Guidance should also indicate that this item applies to any and all laboratory orders initiated by an ordering provider (medical/legal order requisition), as well as reflex orders (added by the performing laboratory if previous criteria are met in accord with CMS.)  Some HIT vendors consider some of the “laboratory orders” especially reflex testing in microbiology and blood bank are considered by some as “workflow add ons” and not the same as lab orders, and thus do not have the same functionality for them such as LOINC encoding.  With these reflex orders, one or more result items and a field for their values are added/reflexed, allowing entry of result values, and charges for billing for the additional work.  In other cases, quite a few LIS vendors allow adding of sensitivity panel orders for cultures, resulting in an order, ~12 antimicrobial sensitivity results with their respective LOINCs, and values for each that are either numeric or mapped to SNOMED CT qualifier values for the result values of sensitive, resistant, etc. However, the sensitivity panel order (e.g. gram positive antibiotic panel, gram negative antibiotic panel) is not released outside the LIS, thus the HER, and more importantly public health are not receiving these and the LOINCs that would be mapped to them in exchanges. Some LIS and/or HER vendors are only sending the top level laboratory order such as Urine culture and its LOINC and not any of the reflex orders such as gram stain, colony count, antibiotic sensitivities, other confirmatory testing, etc.  This also occurs with some blood bank testing.
   4. Additional guidance on vendor certification needed to support different all the different types (structures/models) of lab orders would be helpful as well. 
      1. The first is the single orderable and resultable such as a Hemoglobin that is an order and a hemoglobin result.  Some LIS and HER vendors may represent these together in the same data dictionary while others may represent in the order in an order dictionary (and it’s LOINC map), and the result in a result dictionary (and it’s LOINC map).  Either way, the order and it’s LOINC should be available. 
      2. The second type of order is a simple panel such as Complete Blood Count (CBC) or Basic Metabolic Panel (BMP) which is an order panel with its LOINC.  Each order panel is comprised of one or more results and their values.  A CBC would have results of a Hemoglobin (HGB), Hematocrit (HCT), White Cell Count (WBC), Red Blood Cell Count (RBCs), etc., each mapped to it’s own LOINC for the result. 
      3. The third type of order is the reflex order, which is another order added or reflexed by the laboratory to an existing order and specimen if results of the first order meet established criteria.
         1. A common reflex order is “UA If,” whereby a urinalysis is performed on a specimen and if there are bacteria, a positive leukocyte esterase, or white cells seen, a reflex order for a Urine Culture is ordered on the specimen and performed to avoid delays in patient care.
         2. CMS has requirements for definitions by a medication review panel as to what is included in a reflex order and potential results.  Here’s an example of one entity’s guidelines and policy on reflex testing: https://hcahealthcare.com/util/forms/ethics/policies/regulatory-compliance-support/REGSLAB010-a.pdf 
         3. Reflex orders can be complex with one to five levels of orders reflexed on to the original order. One example is the Lupus Anticoagulant Reflex Panel Order:  LOINC 75515-7 Lupus anticoagulant aPTT and dRVVT screening panel W Reflex   or LOINC 75881-3 Lupus anticoagulant aPTT, dRVVT and PT screening panel W Reflex  These reflex tests are in accord with clinical protocols and CLSI guidelines.
      4. The fourth type of order is known as the physician one click order, tiered order, profile order, or similar names.  In this case, a single order name is provided for the ordering provider in the EHR. However, behind the scenes, either the EHR (the sender side) or the LIS (receiver side) explode the order out into multiple orders and results that are performed on the patient.
         1. One example is a Stroke Order Panel (the top or parent order), whereby when exploded out, entails a second tier (the second child order layer) comprised of a CBC panel order, BMP panel order, and PT/INR panel order.  Each of these has their own results and their values that grouped together comprise the test. 
         2. There may not yet be a LOINC code available for the Stroke Order panel, but there are LOINCs for the child order panels like the CBC, BMP and PT/INR, as well as the result items like Hgb, Hct, WBC, etc.
   5. Guidance should indicate that all laboratory orders, including pathology, genomics, cytogenetics, blood bank, etc. would be considered a Laboratory Data Element.
   6. There are a number of entities that use different names for laboratory orders such as referring to them as procedures. When different USCDI data elements are chosen to represent Laboratory orders, often they may not be structured in the same way, be missing information, have different encoding and thus may be inoperable.  For receivers of these exchanges such as public health, they need to support 3 different ways these Laboratory Orders may be modeled and exchanged and may miss critical information if all 3 means are not supported by senders and receivers. This leads to unnecessary burden on all, so Laboratory Orders using FHIR Service Request is supported.
      1. This is likely due to SNOMED CT Procedure hierarchy including laboratory orders and given SNOMED CT is the laboratory order terminology used in some countries outside the US.  It may also be that for billing laboratory orders are mapped to Current Procedure Terminology (CPT) codes.  No matter the reason a number of entities have been representing USCDI laboratory order data elements as USCDI Procedures and/or FHIR Procedure Resource. Laboratory Orders should not be represented as such nor encoded with SNOMED CT Procedure hierarchy codes in the US. I’ve seen the CBC represented as a FHIR Procedure Resource.
      2. Similarly, Laboratory Orders are also being represented as a FHIR Observation Resource, FHIR Observation.component Resource, and/or FHIR Observation based upon linkage to another FHIR Observation Resource, especially when one of more results (as part of a order panel) are reported together in a Laboratory Report using FHIR Diagnostic Report Resource.  There is a need to keep lab results, which are part of each panel order together in reporting to avoid incorrect information exchanges that may pose a patient safety risk.  For example FHIR Diagnostic Report Resource does not natively support the structure of the results (FHIR Observations) reported.  Composition is one way being investigated to preserve the panel structure so “Interpretations” from one panel are not mixed up with “Interpretations” from another panel in the same report.  It also aids in keeping pathology, genomics, radiology and other report section content together.  One way to achieve this grouping is to have each set of result observations use “based upon” to reference the Laboratory order in FHIR Service Request from which it originates.  However, not all implementations are using this approach in favor of using Observation Resources noted above to represent the Laboratory Order such as a CBC and then use Obsevation.component or Observation based upon referencing the CBC and other FHIR Observations to represent the lab results. 
      3. This approach creates a discordant use of the LOINC codesystem as now Observations are being used to represent Laboratory Orders and Laboratory Observations. Thus an Order only LOINC code would be mapped to a Laboratory Order represented as a FHIR Observation.  Any quality checks of ensuring FHIR Observations are not mapped to LOINC Order Only codes can no longer be used as recommended above.  One can no longer assume that LOINC Order only codes are mapped to only orders and may flag these as mapping errors.
      4. In general, Lab Orders whether in USCDI or in USCDI + use cases should all be standardized to the same code system requirements, as well as be aligned with CLIA and other regulatory requirements depending on where they are utilized in information systems and flows.

APHL suggests to update the data element to reduce ambiguity

Based on the current definition for this element of "Provider-authored request for the performance of a laboratory test." APHL would map this to the first CLIA element in Standard: Test request https://www.ecfr.gov/current/title-42/section-493.1241 "§493.1291(a) = The laboratory must have a written or electronic request for patient testing from an authorized person.", for which many required elements are further identified in the regulation. This seems to be more than a single data element.
If the intent was for this data element to represent the Ordered Test/Panel Code that identifies the test(s) to be performed as called out in "§493.1291(c)(4) = The test(s) to be performed.", then this element should be renamed to reflect that and it's definition should be updated as defined in USCDI+ as Laboratory Test/Panel Code (https://uscdiplus.healthit.gov/uscdi?id=uscdi_record&table=x_g_sshh_uscdi_uscdi_elements&sys_id=808c53d81bd5b110f7052f84604bcbb5&view=sp) - this element is what can be mapped to a single data element in V2 = OBR-4 (Universal Service Identifier) (https://www.hl7.eu/refactored/segOBR.html#238), in CDA = Not usually present unless using a battery organizer = ClinicalDocument/component/structuredBody/ component/section/ …/ entry/act/…/entryRelationship/organizer.code and in FHIR to ServiceRequest.code (https://build.fhir.org/servicerequest-definitions.html#ServiceRequest.code) and in USCore https://hl7.org/fhir/us/core/StructureDefinition-us-core-servicerequest-definitions.html#key_ServiceRequest.code, where it is 1..1, so required. This element can be mapped to LOINC, where the basic attribute Order vs. Observation = "order only" or "both"