Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »


The purpose of this page is to capture the goals and requirements to enhance ELR reporting in the context of the COVID pandemic, and in that context provide clear guidance to all parties in the communication flow to enhance their contributions to enhance the ELR transaction to a Public Health Authority. 

This is meant to be a working document that we rapidly evolve based on latest understanding. Once it is believed to be sufficiently complete and accurate it will be published elsewhere as a guidance document.


Hans Buitendijk - Cerner, HL7 Orders & Observations Co-Chair, EHRA Standards & Interoperability Chair

David Burgess - LabCorp, HL7 Orders & Observations Co-Chair

Freida Hall - Quest Diagnostics

Jason Hall - CDC

Janet Hamilton - CSTE

Riki Merrick - APHL, HL7 Orders & Observations Co-Chair, IHE Pathology and Laboratory Medicine Co-Chair

Craig Newman - Altarum, HL7 Public Health Co-Chair

Andrea Pitkus

Dan Rutz - Epic, IHE ???

Kathy Walsh - LabCorp

Michael Waters - FDA


  • AOE - Ask at Order Entry
  • eCR - Electronic Case Report
  • eDOS - Electronic Directory of Services implementation guide or transaction according to that guide
  • ELR - Electronic Lab Reporting implementation guide or transaction according to that guide
  • IICC - IVD Industry Connectivity Consortium
  • LOI - Laboratory Order Interface implementation guide or transaction according to that guide
  • LRI - Laboratory Results Interface implementation guide or transaction according to that guide
  • O - Optional
  • PD1 - 
  • PHA - Public Health Authority
  • PID - 
  • RE - Required but may be Empty

Current Challenges

When ELRs are sent to PHA it does not contain sufficient demographic, ask-at-order-entry data, and device information as is necessary to enable further analysis.  While some of that data could be part of a subsequent eCR, if the data is already available at time or order and ELR transmission before an eCR is available (or the next eCR is available) helps accelerate the process.

Through the process from ordering to reporting, there is a need to:

  • have the ability to document/collect the data (particularly certain ask-at-order-entry information in context of specific tests),
  • document as part of the order that data (recognizing that in various settings the data is just not available yet, or the urgency does not allow for collection/documentation at that time),
  • communicate the data (ensure a consistent format/standard is available) to the performing laboratory directly or through the provider's laboratory to the reference lab performing the test (where the performing lab does not have direct, electronic access to that data in the ordering provider's system)
  • retain the data in the laboratory to be able to include it in the ELR
  • communicate the ELR with all available data to the PHA (ensure a consistent format/standard is available)

There are numerous challenges along in this flow in terms of data not being able to be collected, not being documented, not using standard vocabulary, not including it in the order, not forwarding certain data, dropping standard vocabulary, not retaining data, not communicating data available to the PHA.  The challenges this guidance is looking at is ensuring that the relevant data can be communicated from ordering provider through a potential intermediary lab to the performing lab and on to PHA as an ELR in a complete, standard, consistent format and vocabulary.

Currently the specific challenges in that area are:

  • Device identification data is not included in device/test documentation
    • The latest LIVD guide does not include an ability for the relevant identifier for each test kit.
  • Deployed lab order implementation guides do not include the guidance on how to convey all the relevant ask-at-order-entry questions and answers recognizably and consistently.
    • The latest eDOS guide has the commonly used set of AOEs with standard LOINC codes and where applicable answer sets, but is not complete to cover the latest updates.
    • The latest LOI guide addresses the ability to communicate all relevant data, including any AOEs, but is not deployed in active use.
    • Upgrading to the latest LOI guide is a major lift for everybody, so although desired for the mid/long-term, it is not a good short-term recommendation.
  • Deployed lab reporting implementation guides do not include he guidance on how to convey all the relevant ask-at-order-entry questions and answers recognizably and consistently, nor the relevant device information, nor sufficient clarity on minimum desired demographic data (some fields may need to be marked RE rather than O, or X).
    • The latest LRI guide (that now includes ELR) accommodates the ability to send any relevant AOEs, but may need more specificity on other patient demographic data already available in PID or PD2, while it does need guidance on how to convey the relevant device/test kit(s) used to perform the test.
    • Upgrading to the latest LRI guide is a major lift for everybody, so although desired for the mid/long-term, it is not a good short-term recommendation.

As indicated before, there are many other challenges to ensure that data if fully, accurate, and consistently documented and communicated, including use of encoded standard vocabulary (at least along with any local coding that remains relevant), but that is not addressed here.  Our goal is to provide guidance on how to address the above challenges in the necessary implementation guides that can be deployed as quickly as possible and as consistent as possible across ALL jurisdictions.

We understand that there may be a desire/need to send the original order to PHA directly as well to get earlier insight into certain tests ordered including PHI, particularly during an emergency (as that may invade patient privacy unnecessarily during "normal" situations), but when that interest becomes a requirement, the guidance for the ordering flow is sufficient as the starting point and being extended based on local PHA emergency mandates on how much (or not) PHI is to be removed before forwarding it.  That guidance should be as consistent as possible as well, but we will address that when an actual requirement in any jurisdiction is raised.


The following data set is desired to be made available as part of an ELR as much is is available upon placing the order and to the extent that the Laboratory has access to any additions before the ELR is sent.

Demographic Data

1Patient ageRequired-HHS

2Patient raceRequired-HHS

3Patient ethnicityRequired-HHS

4Patient sexRequired-HHS

5Patient residence zip codeRequired-HHS

6Patient residence countyRequired-HHS

7Patient name (Last name, First name, Middle Initial)Optional-PHA

8Patient street addressOptional-PHA

9Patient phone number with area codeOptional-PHA

10Patient date of birthOptional-PHA

Order Data

1Ordering provider addressOptional-PHA

2Ordering provider phone numberOptional-PHA

3Ordering provider name and NPI (as applicable)Required-HHS

4Ordering provider zipRequired-HHS

5Date test ordered (date format)Required-HHS

6Test ordered – use harmonized LOINC codes provided by CDCRequired-HHS

Ask at Order Entry

SeqNameOptionalityAllowable AnswersComments
1First test
2Employed in healthcare?
3Symptomatic as defined by CDC?
4Symptomatic = Y then Date of Symptom Onset
5Hospitalized? Y/N/U
7Resident in a congregate care setting (including nursing homes, residential care 
for people with intellectual and developmental disabilities, psychiatric treatment 
facilities, group homes, board and care homes, homeless shelter, foster care or other setting)


Specimen Collection

1Date specimen collected (date format)Required-HHS

Test Result

1Performing facility name and/or CLIA number, if knownRequired-HHS

2Performing facility zip codeRequired-HHS

3Device IdentifierRequired-HHS

4Test result – use appropriate LOINC and SNOMED codes, as defined by the Laboratory In Vitro Diagnostics (LIVD) Test Code Mapping for SARS-CoV-2 Tests provided by CDCRequired-HHS

5Test result – use appropriate LOINC and SNOMED codes, as defined by the Laboratory In Vitro Diagnostics (LIVD) Test Code Mapping for SARS-CoV-2 Tests provided by CDCRequired-HHS

6Test Result date (date format)Required-HHS

Updates to Implementation Guides

The following updates need to be made in the base implementation guides

  • LIVD
    • Add the device identifier for the test kit in the correct resource (DeviceDefinition or ObservationDefinition?)
      •  Need a product reference uid to identify the ObservationDefinition OR is it really on the DeviceDefinition?
        • If on the ObservationDefintion, need to re-include ObservationDefinition.identifier 0..*
          • identifier.type = "product-reference-identifier"
          • identifier.system = TBD (for uid)
        • If on the DeviceDefinition .....
    • Add the assigning authority as well.  This is particularly important for OBX-18.3 if the identifier is not an official device identifier.
  •  eDOS
    • Add new AOEs to master list, but nothing needed for the rest
  •  LOI
    • None?
  • LRI
    • Add guidance on how to convey device identification information

Implementation Guidance


  • Immediately
    • Orders - Any HL7 v2 ORM or OML message in place between ordering provider and Laboratory as well as Laboratory and Reference Laboratory where the tests are outsourced.
      • Use LOI Rn Section X, Y, Z for specification on how to add AOEs
      • Include Profile ABC in MSH-21 so receiving system recognizes it may contain OBX segments that are based on HL7 v2.8.1
      • Use eDOR Rn Section X, Y, Z for master list of AOEs PLUS [whatever list Riki is adding if maintained separately for now]
      • Use Mapping Spreadsheet below for PID and OBR fields that are RE if not R.
    • Results - Any ELR to PHA
      • Use LRI Rn Section X, Y, Z for specification on how to add/forward AOEs with the result
      • Use Mapping Spreadsheet below for PID, OBR, and OBX fields that are RE if not R.
      • Use Device Identifier guidance below
  • Strongly Recommended
    • Adopt LIVD as quickly as possible to stay informed on latest LOINC mappings and device identification information
    • Adopt eDOS as quickly as possible to stay informed on latest AOEs per test.
    • Adopt LOI Rn as quickly as possible to enable most consistent and complete communication of Lab orders.
    • Adopt LRI Rn as quickly as possible to enable most consistent and complete communication of ELR.

Device Identification

  • It is expected that some test kits will not have an official Device Identifier, so any unique device identifier will do.  For purposes of this discussion that is considered a Device Identifier
  • As the collection of this identifier may vary or require more/less development/implementation effort, it appears that one must be able to collect just the Device Identifier, just the UDI Carrier (the barcode read in HRF form or AIDC, although the latter was not really referenced in the examples), or a combination of both with possibly other parsed elements of the UDI components of the UDI Carrier.
  • Ideally, the LIS should configure the Device Identifier provided in the LIVD file (IICC .csv or FHIR .json file).  Then it can be passed along in the test.
    • Issue: is IVD Test Code always related to exactly one test kit?
  • Outline for LRI
    • If the Device Identifier is included on the LIVD file provider to the Lab by the device manufacturer as part of the mapping definition to LOINC, the LIS could include that information in its configuration so that when a test result comes through that involves a known test kit, it can auto-populate that field for ELR.  It is assumed that LIS-s do not have that capability today, so may not immediately have that available.  Nor was it confirmed that upon receiving the test results from a device for a a particular IVD test code the test kit Device Identifier would be unambiguously known and if not passed on. 
    • If only device identifier is available (from LIS configured flow or entered manually as the device identifier), use OBX-18
      • EI.1 =
      • EI.2 =
      • EI.3 = 
    • If a barcode is scanned (UDI Carrier) then EITHER:
      1. parse the Device Identifier and put it into OBX-18 per above
      2. Include the UDI Carrier into PRT-10 according to the UDI Pattern R2 guidance in the HL7 v2 section on page 13
        1. Optional
          1. include all the parsed elements as well according to UDI Pattern Release 2 in the HL7 v2 section (page 14) for Device Identifier and Production Identifier
          2. PRT-4 must be set to xyz
    • If only the UDI Carrier is provided, then the receiver (PHA, FDA) needs to parse the Device Identifier to enable comparison with the LIVD files or other analysis, filtering, etc. 
      • Issue: It was not determined that would be o.k., but we noted that requiring just the Device Identifier may complicate workflows to collect that data and/or impose extra capabilities on the LIS beyond a simple scan.

Mapping Spreadsheet

Use this spreadsheet to collect options and comments around the proposed mapping of the HHS elements to various places in Order and result messages.

Open questions on spreadsheet

  • Suggest to organize by data types.  IF there is a need to link back to a sequence on an HHS spreadsheet, let's use HHS ID and I'll fix the in-line tables above accordingly to have the link.
  • Suggest to replace Must Support with RE for consistency with guides.
  • Unclear whether the optionalities by guide are current or recommended.
  • Some of the AOEs may be able to be aswered with knowledge in the system (e.g. is patient hospitalized = Patient class is inpatient in encounter)
    • We should do an analysis of which of these HHS questions are available in the EHR-S (and in what format) and then decide on the best way to share that data
    • Options for differentiating OBX for AOE vs OBX for results:
      • LOINC code
      • ELR R1 expects OBX after SPM for patient age - could put others there
      • Use a separate OBR for EPI important information
      • OBX-29 in LOI/LRI
  • While communication of a .csv or flat file from performing lab to PHA, if the above guidance cannot be implemented in time, is out of scope of HL7 to define format, we could make some suggestions on what to include to match with the ELR transaction that it needs to match up with.  
    • APHL is creating a flatfile format for this purpose (not csv, but rather tab delimited) - the elments in this flatfile are all mapped to the respective ELR R1 location, so that transformation could occur at the sender or receiver side (conversion tooling for the PHAs is being discussed)
    • Suggest to allow for Direct Messaing to convey the file.
    • Why not just use ELR in xml format via Direct?
  • Since ELR is subject to certification and the provider is supposed to use the certified version, there must be clarity that pre-adoption of the AOEs according to the latest LRI IG sections is permissible.

Open Issues

From the LIVD call chat that needs to be reviewed whether above covered everything

From Andrea Pitkus PhD, MLS(ASCP)CM to Everyone: 01:25 PM
thanks Ed! There are also UDIs for control and QC, which would be out of scope. The other question is how is UDI captured and mapped in LIS. Do LISs need to add functionality so it can be sent electronically?
From Andrea Pitkus PhD, MLS(ASCP)CM to Everyone: 01:33 PM
Pam and I were discussion LDTs. Is there expectation they would have a UDI and how would that be acquired? If not, what is entered when there is no UDI? N/A? Is field blank?
From Andrea Pitkus PhD, MLS(ASCP)CM to Everyone: 01:45 PM
Can we discuss UDI for manual test kits and LDTs (non analyzer performed tests)?
From Ralf Herzog to Everyone: 01:45 PM
Sorry, need to leave today earlier. Wish you all a nice weekend and CU next week Bye Ralf
From Andrea Pitkus PhD, MLS(ASCP)CM to Everyone: 01:45 PM
From Andrea Pitkus PhD, MLS(ASCP)CM to Everyone: 02:05 PM
 Test I'm thinking of is the ROMA that is a 2 step immunoassay. Ed will check if 1 or 2 UDIs


Resources for Background

  • No labels