NOTE: HHS has published their implementation guidance table: https://www.hhs.gov/sites/default/files/hhs-guidance-implementation.pdf - this link now gets a 404 error, so here is the lab guidance pdf for now: 

Revision Log:

12/20/2022: Added the actual pdf document, since the HHS guidance link is broken

9/9/2022: Updated the OTC reporting guidance document so that the "Performing Organization Address (OBX-24)" does NOT use any state (OBX-24.4) or zip code (OBX-24-5)

3/8/2022: Updated with link to reporting guidance changes on CDC webpage effective 4/4/2022: https://www.cdc.gov/coronavirus/2019-ncov/lab/data-and-reporting.html and added a link to FAQs around OTC reporting

3/3/2022: Updated At Home test document and reference to SARS-CoV-2 variant spreadsheet.

4/13/2021: Updated the word document in the section on reporting variants of concern to fix some errors in the example messages - track changes on (and please accept my apologies for missing those!) 

3/29/2021: Added a section on reporting variants of concern - CDC will publish this guidance soon (section: Reporting variants of concern) - it was published 4/10/2021 here: https://www.cdc.gov/coronavirus/2019-ncov/lab/resources/reporting-sequencing-guidance.html

11/3/2020: Updated the SCT code description for fever from 426000000^Fever over 104F^SCT to 426000000^Fever greater than 100.4 Fahrenheit^SCT to match HHS implementation guidance.6000000 | Fever greater than 100.4 Fahrenheit (finding) |

9/21/2020: Added note to NOT send Symptom Onset Date AOE, when unknown (as that creates a change in datatype).

9/14/2020: Updated syntax for the Device Identifier, when using the UDI definition (numeric values accessible via the FDA GUUID database)(section Device Identification).

Introduction

The purpose of this page is to capture the goals and requirements to enhance ELR reporting in the context of the COVID pandemic, in light of HHS guidance, 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. 

Contributors

 Definitions

• AOE - Ask at Order Entry
• eCR - Electronic Case Report (can be reported using CDA or FHIR) - is complimentary dataflow
• eDOS - Electronic Directory of Services implementation guide or transaction according to that guide
• CLIA- Clinical Laboratory Improvement Amendments
• ELR - Electronic Lab Reporting implementation guide or transaction according to that guide - in this context the referened guide is R1 (2010 with clarification and errata)
• EUA - Emergency Use Authorization
• IICC - IVD Industry Connectivity Consortium
• LDT - Laboratory Developed Test 
• LIS/LIMS - Laboratory Information System (Clinical Labs) or Laboratory Information Management System (Public Health Labs)
• 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 - Patient Demographics 
• PHA - Public Health Authority
• PID - Patient Identification Segment
• PV1 - Patient Visit Segment
• RE - Required but may be Empty (Must support)
• R - Required
• UDI - Unique Device Identifier

Current Challenges

When ELRs are sent to PHA at times, they may not contain sufficient demographic, and other data as required by public health by law.  This guidance aims to facilitate collection and transmission of these vital data at order entry, for transmission to the performing laboratory and on to the respective PHA.  While some of the data may be part of a provider eCR report to public health, eCR is out of scope for this discussion, but ELR data would need to be aligned with eCR reporting.  These data often available at order entry, and their transmission to the performing laboratory and in that lab's ELR report, may be the first notice to PHA and accelerate PHA processes.

Currently, the following are the data flows that would be impacted:  

• Device manufacturer(s) provide(s) label information with UDI(s) and insert information to the laboratory to enable them to validate their test system (EUA, LDT) in accord with regulations like CLIA (i.e. §493.1253).  (Same information is provided to test performers using waived testing device(s).)  
  • Format:  package label(s) with barcode UDI(s), 
• Performing laboratory/test performer builds test orders, results, result values, reference ranges, AOEs, and associated test information in their LIS/LIMS; configures interfaces from their instruments to their LIS/LIMS and/or sets up capabilities for manual results entry in LIS/LIMS; and configures interfaces from performing laboratory LIS/LIMS to/from ordering provider EHRs, other laboratory LIS/LIMS, and PHAs to support transmission and receipt of data for orders, results, public health reporting, etc.
  • Format (in lab interfaces):  IHE-LAW, ASTM
  • Format (external interfaces):  HL7 v2.x orders/results, LOI (future), LRI, ELR
• Performing laboratory maps national code systems (i.e. LOINC, SNOMED CT) for test(s) performed with their device(s) into their LIS/LIMS for use in messages LRI, LRI, etc.  AOEs, test orders, and results are mapped to LOINC, while SNOMED CT is used for qualitative test result values, specimen types (i.e. swab), specimen source (i.e. left nares).  
  • Format: paper, LIVD-IICC spreadsheet format, LIVD-FHIR (future)
• Performing laboratory builds information required for test ordering (in accord with §493.1241 Standard: Test request) into their paper or electronic CLIA Specimen Collection Manual.  AOEs for orderable tests should include their code system mappings.  The performing laboratory informs the ordering provider (EHR) or referral laboratory (LIS) (who informs their ordering providers) of required data elements for test requests (orders) including relevant AOEs.  For consumer/home testing, home specimen collection, or where Direct to Consumer (DTC) Testing is allowed, a system shall be in place to collect the required data elements from the consumer and/or ordering provider about the patient being tested.
  • Format: Paper, eDOS IG, FHIR order catalog (future)
• The ordering provider (via their EHR or order entry system) must include all required data available at the time of order entry on the test request (order message) directly to the performing laboratory or indirectly via a referral laboratory that forwards the required information to the performing laboratory.  Both laboratories may be responsible for ELR submission depending on jurisdictional requirements and at a minimum, the performing laboratory.  
  • Format: Paper, web portal (pdf or structured data), HL7 v2.3 and higher using ORM, HL7 v2.5 and higher OML, HL7 LOI IG (future)
• The performing lab using their LIS/LIMS reports results back to the ordering provide directly (to their EHR or portal system) or to the referral laboratory (to their LIS/LIMS or portal)  which sends the results to the ordering provider (to their EHR or portal system).  The patient may receive their results via phone, their EHR, or other online portal or application, from the performing laboratory directly, especially in jurisdictions where Direct to Consumer testing (DTC) is allowed;  from the ordering provider, or PHA.
  • Format: Paper, fax, telephone, webportal (pdf or structured data), HL7 interfaces in any version using ORU, HL7 LRI IG (future)
• The performing laboratory with their LIS/LIMS has capabilities to receive and store all test request information from senders including AOEs and code mappings so they can be associated with patient results, device(s) utilized in performing testing, and any other required data elements to be leveraged in reporting to the provider, referral laboratory if applicable, and PHA.  The performing laboratory communicates all required information for reportable conditions in accord with all pertinent regulations/laws (i.e. CLIA, HHS, PH jurisdictions) and their timelines for reporting.
  • Format: Paper, telephone, flatfile, various HL7 v2.x formats, ELR IG,

• The Public Health Agency forwards the information as appropriate (e.g., de-identified) to HHS for sharing with and use by federal agencies (i.e. CDC, FEMA, White House, FDA)
  • Format: flatfile, HL7 v2.3.1, ELR R1, NMI formats (for cases), various other file formats

As certification to HL7 ELR R1 IG is not required for EHRs, nor LISs, and adoption of certified ELR capabilities is voluntary under CMS' Meaningful Use/Promoting Interoperability program for providers, while not addressed in other programs for Laboratory (e.g., CLIA), while states introduce further variations, and lab order transaction formats are not addressed anywhere, implementations across all data flows vary widely and production use of HL7 EHR R1 IG is limited.  Additionally, the ELR reporting enhancements could almost all be addressed with the latest HL7 LRI R1 STU R3 IG, but that has not been adopted by anybody, since it was not included in MU regulation. 

Additionally, as the PHA onboards the lab, they may accept a variety of fields, formats as long as they are receiving key information.  Also it's unclear if point of care testing locations like pharmacies, drive up/drive through testing sites or state national guard collection sites for COVID-19 are 1) reporting ELR at all, 2) providing all required information and 3) those reporting on paper requisitions will not be providing LOINC or SNOMED CT codes and are often lacking demographics, specimen source and other required PHA elements. 

Throughout the data collections and flows there are numerous challenges  in terms of data not being able to be collected (even if it could be available), 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. 

Currently the specific challenges in that area are:

• 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 at this time.
  • 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 the 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 in form of the PH_component) accommodates the ability to send any relevant AOEs, but may need more specificity on other patient demographic data already available in PID, PV1 or PD1, and will need added 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.
• Device identification data is not included in lab results reporting
  • While the device identification (at least manufacturer and model) is available (either by label/insert/documentation or the LIVD-IICC spreadsheet, not all device identification information of interest is available in a way that the result can include automatically all device identification information for the relevant test kit/reagent, instrument platform, manual kit, and/or emergency use authorization as needed, ideally the UDI(s), but at least the model and manufacturer. 

As indicated before, there are many other challenges to ensure that data is fully, accurately, 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.

In short, 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 with vocabulary, with the least amount of effort to meet the deadlines.

Existing Implementation Guides

Considering the existing implementation guides and updates to them in flight, upgrading to the latest versions would support most of the requirements and address the challenges outlined above, but still would require various updates to address all requirements.  The following updates need to be made in the base implementation guides for a next version to include the short-term Implementation Guidance provided in the next section.

• LIVD-FHIR
  • 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
  • CLIA test request requirements listed under Resources below.
  • Update the value sets for race and ethnicity
• LRI
  • Add LAB_PH_HHS_ELR_Guidance_Component to enable pre-adoption of latest ELR capabilities in earlier versions or HL7 ELR guidance or other HL7 v2.x based guidance:
    • Guidance on how to convey device identification information
      • Report information about the manufacturer and model in OBX-17 (can repeat to accommodate the test kit and the instrument)
      • Report instance information (i.e. the serial number / UDI) in OBX-18 (can repeat), changing usage of OBX-18 to RE
      • Use of PRT when communicating parsed UDI components and possible addiiton of device relationships
    • Support for test order date by changing usage of ORC-15 to RE
    • Create the MSH-21 component ID
    • Update the value sets for race and ethnicity
    • Update conformance statement around OBX-14 timing
    • Identify use of OBX-29 as part of this profile

We suggest that HHS works with the key stakeholders and HL7 to pursue these updates as quickly as possible to enable adoption.  In the meantime, the following section outlines the specific short-term guidance to make substantive progress that also prepares the industry for future adoption of the guides referenced above.

Implementation Guidance for Immediate Use

As adoption of the latest guides is not an option short term, we recommend to adopt the following specific guidance to enable communication of the data in the HHS guidance.

This guidance is based on the technique of pre-adopting the relevant capabilities from more current HL7 v2 versions in context of the latest applicable implementation guides referenced in the prior section, which is an acceptable approach that is reflected in many HL7 implementation guides already.  Thus this can be added to any existing HL7 v2.x based ELR specification, recognizing that certain software and integration engines may not recognize and therefore fail "mixed" content without further work.

General

• Data Elements
  • Use proper segments per Mapping Tables below for PID, ORC, OBR, and if applicable to your version of HL7 SPM fields.
    • If the guide indicates they are optional or not supported, apply the usage as listed in the Optionality column below.
    • If not possible, then use OBX segments using LOINC codes as identified above or in Appendix A of eDOS R2 STU 3.
  • For socio-demographic relevant data for population level analytics, use the fields in PID and consider them RE.  These include:
    • race
    • sex
    • ethnicity
  • Although not a specific requirement for HHS, if you need to convey the clinical relevant values for for interpretation of lab result for the following data, use AOE OBX as provided by the lab:
    • race
    • ethnicity
    • sex
• 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 R1 STU 3 Section 1.4.10 and 6.15 for specification on how to add AOEs using pre-adopted OBX capabilities. 
    • Include Profile LAB_PH_HHS_ELR_Guidance_Component in MSH-21 (LAB_PH_HHS_ELR_Guidance_Component^^2.16.840.1.113883.9.259^ISO): so receiving system recognizes it may contain OBX segments that are based on HL7 v2.8.2.
    • Use eDOS R2 STU 3 Appendix A for an initial list of AOEs in addition to any listed above
    • AOEs are sent as OBX segments after the OBR it applies to, but before the SPM.
    • AOE OBX segments include OBX-29 as pre-adopted element (from v2.8.2) that is valued "QST" (from HL70936_USL in the Lab Value Set Companion_Guide)
    • It is expected that the AOE description in the message is drawn from LOINC.
• Results - Any ELR to PHA
  • Use LRI R1 STU 3 Section 8.11 and 13.3.3 for specification on how to add/forward AOEs with the result using OBX segments that are based on HL7 v2.8.2.
  • Include Profile LAB_PH_HHS_ELR_Guidance_Component in MSH-21 (LAB_PH_HHS_ELR_Guidance_Component^^2.16.840.1.113883.9.259^ISO):
    • so receiving system recognize it may contain OBX segments that are based on HL7 v2.8.2.
      • can apply additional conformance testing based on OBX-29 values to modify the usage of
        • OBX-14
        • OBX-23, OBX-24 and OBX-25 in ELR R1
    • Adjust usage of ORC-15 and OBX-18 from O to RE and declare the respective datatypes for those fields
  • Use Device Identification guidance below.
  • AOEs are sent as OBX segments after the OBR it applies to, but before the SPM.

The following identifies for each of the data elements called out by the HHS guidance where in a v2 message it should be communicated. 

Mapping Tables

The embedded spreadsheet includes tabs for each of the tables below as an alternative format.

Optionality Legend: O-Optional, R-Required (cannot be blank), RE-Required but can be empty if not available, ND-Not Desired by HHS, NF-Not Forwarded to HHS, C-Conditional

Demographic Data

Order Data

Ask at Order Entry

Valueset for Y/N/U - Use PHINVADS valueset (Y/N from HL70136 and UNK from V3 Nullflavor) that is used for Case notifications: https://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.114222.4.11.888.  U is replaced with UNK below, except as noted in the implementation guidance.

Note that the following OBX fields are not usually expected for AOEs:

• OBX-6 Units, except for Patient Age (and any other AOEs that might require units of measure)
• OBX-7 Reference Range
• OBX-8 Interpretation code
• OBX-17 and -18 Method/Device
• OBX-19 Analysis date/time
• When populating OBX-23 Performing organization name, OBX-24 Performing organization address and OBX-25 Performing organization medical director should be valued with the applicable information for the provider organization that collected the data.

Note that various AOEs do not have published LOINC codes yet.  These have been created in the 2.69 pre-release and are marked with "2.69-pre".  Once published they should be communicated with the published release number, likely "2.69".

Note that HHS and CDC are working on finalizing wording of the AOEs and associated LOINC coding.  That may result in a different LOINC code and/or a change in questions.  We will update this section as soon as HHS and CDC finalize the wording and associated LOINC coding.

NOTE: July 28th Updates are captured in red font below

Specimen Collection

Test Result

Device Identification

There are four components that are potentially of interest for which to include an "identifier":

• Testkit/reagent - This is the most important one to communicate.  If multiple test kits/reagents are used, all need to be included.
• Instrument Platform - This is needed if the test kit/reagent is used off-label with a different instrument OR multiple instrument platforms were used as well.
• Manual kit - This is needed if the test was performed manually.
• Emergency Use Authorization -  This can be used when a particular combination of testkit/reagent(s) and instrument platform(s) is used that is authorized by an EUA.  In this case the individual test kit/reagent(s) and instrument platform(s) do not need to be communicated as well.

There is no need to include identification information for calibrators, controls, or collection devices.

These devices can be identified as a kind of using three different approaches:

• Model Name
  • The most likely information available for a testkit/reagent or instrument platform is a model name (unofficial or official); usually when combined with the name of the manufacturer it is unique.
• Emergency Use Authorization Identifier
  • Defines the particular combination of testkit/reagent(s) and instrument platform(s) is used that is authorized by an EUA as listed on the FDA website: https://www.fda.gov/medical-devices/coronavirus-disease-2019-covid-19-emergency-use-authorizations-medical-devices/vitro-diagnostics-euas#individual-molecular
  • The combination of the value listed in the "Manufacturer" column and the value listed in the "Diagnostic (Letter of Authorization)" - including all spaces and special characters (except (TM) or (R)) creates the official name for this EUA
    • a "+" at the end of the Diagnostic might indicate a significant update and consitutes a new entry in the table
    • The goal is to provide that string in the CDC LIVD mapping file in the "Equipment UID" column, identifying the "Equipment UID Type" as EUA. e.g for the following EUA:
      • COVID-19 Coronavirus Real Time PCR Kit Jiangsu Bioperfectus Technologies Co., Ltd.
      • 
  • A smiliar identifier can be created for Lab Developed Tests (LDT) based on Appendix A table by combining "Laboratory" and "Letter Granting Inclusion under EUA", e.g. for the following
    • 
    • Cormeum SARS-CoV-2 Assay_Cormeum Laboratory Services
• Device Identifier (AP:  Question has arisen that for COVID-19, most EUA tests do NOT have UDIs.  They do have GTINs as shown in data below.  Thanks Riki!  Do we wish to include GTIN where UDI is not available?  )
  • This must then be the device identifier according to the UDI definition by the FDA
  • The manufacturer would have made this available, e.g. through their LIVD spreadsheet or otherwise and this likely would have been configured into the LIS so it need not be entered by a user at time of testing.

The device identification information will be captured in either OBX-17 when describing the kind and OBX-18 when describing an instance.

In order to differentiate which of the devices is being described we propose a list of abbreviations to represent each kind (for use in OBX-17)

Sept 14, 2020 update:

In OBX-17 use OBX-17.1 for the device identification information using the format <Model name or Diagnostic (Letter of Authorization)>_<Manufacturer name>_<Abbreviation for the type> and in OBX-17.3 "99ELR". For Device ID omit "_<Manufacturer name>" resulting in <Device ID>_<Abbreviation for the type> in OBX-17.1. 

Best place to obtain these values is the CDC LIVD file (https://www.cdc.gov/csels/dls/sars-cov-2-livd-codes.html):

<Model name or Diagnostic (Letter of Authorization)>_<Manufacturer name> is provided in the  in Testkit Name ID (column M); the <Abbreviation for the type> in Testkit Name ID Type (column N)  and concatenate: <Testkit Name ID>_<Testkit Name ID Type>.

<Device ID> in Equipment UID (column O); the <Abbreviation for the type> is in Equipment UID Type (column P)

Using Abbotts ID Now as example:

Using the EUA ID = ID NOW COVID-19_Abbott Diagnostics Scarborough, Inc. EUA
Using the Device ID = 10811877011269_DII^^99ELR

Where OBX-17.1 length limits interfere with the full identification use the following approach:

OBX-17: ID NOW COVID-19_Abb#^^99ELR

Full ID for the NTE: ID NOW COVID-19_Abbott Diagnostics Scarborough, Inc._EUA

Alternatively these devices can be identified as the specific instance used in testing by their UDI as defined by FDA (for use in OBX-18).

• UDI Carrier
  • The full representation of the barcode in human readable form.
  • Likely only obtained through scanning.

Since the OBX-17 and OBX-18 fields can repeat, multiple values can be communicated.  While the newer PRT segment can improve on this somewhat, it still would require a new field to maintain these relationships.  Shifting to FHIR where this already can be addressed is not realistic in the timelines needed and given most LIS/LIMS currently lack FHIR functionality.  However, given the likely configurations being used, we do not believe we need to address that yet while data curation in the analtyics phase can address this challenge. 

Reporting variants (of concern)

Added 3/29/2021

With the rise of more variants some variants require close tracking to ascertain if they have clinical implications (higher infection rates, or more severe illness). Which variants are of concern may vary over time and not all may remain of importance, while new ones may be detected in the future, so for now we opted to use ST datatype to report them. For the researchers and epidemiologists the sequence itself may be of importance as well, so we are including the ID assigned by the lab to the sequence (PLT2397^Filler Lab Assigned Genetic Sequence Identifier^PLT) - this is the one that is expected to be sent at minimum, and optionally a pointer to the sequence stored in the GISAID (96766-1^GISAID sequence accession number^LN) or Genbank database (87396-8^GenBank accession number^LN) or potentially also NCBI's Sequence Read Archive Number (SRA# = PLT2251^NCBI Sequence Read Archive Number [Identifier]^PLT ) or NCBI's Sample Accession Number (SAMN#) for the BioSample data repository (PLT2402^NCBI's BioSample data repository Accession Number (Identifier)^PLT). All of these identifiers ideally should be sent as CX, datatype, using 'ACSN' as the identifier type in CX.5, but may be sent as ST.

NOTE: PLT2397 has been assigned a NEW LOINC = 98062-3^Sequencing study identifier^LN. 

NOTE: The example messages in this document provide ORC segments with every OBR, but some PHAs may be able to handle ONLY the FIRST ORC segment.

Here is a list of PLR codes that represent the SARS-CoV-2 variants of interest / concern, in case you need some codes: https://confluence.hl7.org/download/attachments/4489770/SARS-CoV-2_PLR_VOC_VOI_r3.xlsx?api=v2 - UPDATED 7/22/2021 = this file is is not being updated on a regular basis, but APHL has a list of ALL PLR codes with a column indicating if VOC or VOI that can be accessed in row 24 of this page: https://app.smartsheet.com/b/publish?EQBCT=b585e5a5e0c2430398db60b0f0d5c72e - since Feb2022 APHL is publishing the SNOMED CT concept IDs in the APHL namespace extension (1000284) instead of the legacy PLR codes - still in the same place though - file is now called "SARS-CoV-2_APHLSCT_Codes.xlsx".

Note that PHINVADS has a valueset: https://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.114222.4.11.3301 that contains 3 US extension SNOMED CT concepts, that have not officially been published. Due to the fluent nature of variants we do not plan on requesting more SNOMED CT concepts for the PLR codes and these code may not ever be published, so use with caution.

Example messages: - updated 6/16/2021 based on updated guidance: 

OFFICAL CDC GUIDANCE PUBLISHED HERE: https://www.cdc.gov/coronavirus/2019-ncov/lab/resources/reporting-sequencing-guidance.html

Reporting at Home Tests

Added 4/30/2021:

Please follow this guidance document when reporting at home tests:  - UPDATED WITH THIS document 3/3/2022 to support 4 different levels of OTC tests:  - here are the example HL7 messages, one for each level: OTC_Reporting_TestMessages.zip

Added this link 3/8/2022:  Over-The-Counter (OTC) Home Testing and CLIA Applicability Frequently Asked Questions - Updated March 4, 2022

Updated 9/9/2022: Update the "Performing Organization Address (OBX-24)" to NOT use any state (OBX-24.4) or zip code (OBX-24-5) - see updated guidance document: 

Flat File

ONLY if no HL7 v2.x support then use flat file to HL7 converter excel file - first box on this page: https://preparedness.cste.org/?page_id=136.  But if you have a HL7 v2 feed continue to use and upgrade as quickly as possible.

If you do not have an HL7 v2 feed, work with your PHA to determine when you can put that in place.

Issues

Open Issues

• If the ELR R1 is in use and supports PI attestation, will inclusion/adoption of this guidance invalidate that attestion.

Closed Issues

• Device ID examples that didn't make it into the table yet:
  • Is there expectation that LDTs 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? see scenarios below.
    • May wish to distinguish LDTs using IVD reagents for a different non 510 k /EUA approved specimen type versus a LDT with totally different reagents, such as own reagents created from scratch.  RM: I DID NOT use this as the speciment type is in SPM - but assume this should be like CDC test run on Abbott m2000 - choice of either the model name or the device ID
    • If LDT uses commercial test kit reagents with UDI on IVD platform with UDI, but with modification (i.e. specimen, reporting) that makes it LDT, expect reagent UDI and instrument UDI can be sent as specified, but should confirm with FDA whether an issue as would appear same as non LDT. RM - did not add to table

• Do we need multiple test kits? Ed will check if 1 or 2 UDIs

  • ROMA is a 2 step immunoassay.  see https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4996955/

  • On LIVD, would those be multiple IVD Test Codes?  Multiple devices/test kits?

  • If only device identifier, OBX-18 can handle multiple

  • If UDI Carrier or UDI, multiple PRTs can handle that. 

  • Roche also has a ROMA Assay on the Elecsys anlayzer:  https://www.accessdata.fda.gov/cdrh_docs/pdf15/K153607.pdf
    
  • ADDRESSED

• Some of the AOEs may be able to be answered based on 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, e.g., use PID/PD1/PV1/PV2/NK1 (occupation) - I got some feedback, that UNLESS the element is already in ELR R1 (like PV1-2), OBX segments will be easiest in the short term to add to the surveillance system.
  • Understanding is some drive up/drive through COVID testing sites are using paper requisitions for ordering, so data elements would be required on paper req to performing lab, who would enter them into their results reporting to PHA ELR message (if provided!).
  • ADDRESSED
• Options for differentiating OBX for AOE vs OBX for results:  (Hans Buitendijk  can we delete this note since we talked about this?AP Note:  The AOE question and response, would be represented as a result and result value.  The LOINC is likely the same for the AOE question and result in most cases.  However, they may have an order ID/identifier for the AOE, and a result ID for the result field to distinguish the two uses of the same data item.  Also is this question on the ELR/LRI?)
  • NOTE: I used the OBX-29 in all of these example messages; we will need to update the OBX-14 conformance statement ELR-051 that compares OBX-14 to OBR-7 and SPM-17: based on OBX-29 is valued 'RSLT' or is not valued 'QST"?
  • LOINC code  
  • OBX-29 as in LOI/LRI 
  • In eDOS, AOE is represented in OMC-4, while OMC-11 defines the allowed answers and OMC-9 defines the expected datatype of the answers and OMC-6 describes the location where it can be found in the message instances.
  • In LOI, AOE is represented in OBX after the OBR it belongs to.
  • ADDRESSED
• 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) Current version of the file (still submject to change: 
  • Suggest to allow for Direct Messaing to convey the file. Riki: need to check with the PHA, what transport mechanism they allow, but I don't see why it shouldn't be an option
  • Why not just use ELR in xml format via Direct? Riki: Because this is for manual data entry
  • ADDRESSED
• What shall we point to for LIVD latest guide? If this is for the link to the LIVD specification, I think we need to use the IICC site (since IVD on FHIR is not yet published) - if to the COVID specific LOINC listing on the CDC site - that is embedded in the HHS guidance etter and also already in Resources for Background
  • ADDRESSED

Resources for Background

• Link to current guidance: https://www.hhs.gov/sites/default/files/covid-19-laboratory-data-reporting-guidance.pdf
• Link to FAQ document: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4996955/ - THIS LINK IS NOT CORRECT - I ASSUME IT SHOULD GO TO THE CDC FAQs? - those are here: https://www.cdc.gov/coronavirus/2019-ncov/lab/reporting-lab-data.html#faqs
• Information Blocking Actors:  https://www.healthit.gov/cures/sites/default/files/cures/2020-03/InformationBlockingActors.pdf  (Includes labs)
• Information Blocking Definition:  https://www.healthit.gov/topic/information-blocking
• USCDI Data Classes, Elements and Standards:  https://www.healthit.gov/isa/sites/isa/files/2020-03/USCDI-Version1-2020-Final-Standard.pdf
• CLIA regulations:  https://www.ecfr.gov/cgi-bin/text-idx?SID=1248e3189da5e5f936e55315402bc38b&node=pt42.5.493&rgn=div5
  • CLIA Order/test request/requisition info as aligned to HHS requirements is below.  Items I bolded apply to most of the AOEs, such as 8).

  • §493.1241   Standard: Test request.

    (a) The laboratory must have a written or electronic request for patient testing from an authorized person.

    (b) 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.

    (c) The laboratory must ensure the test requisition solicits the following information:

    (1) The name and address or other suitable identifiers of the authorized person requesting the test and, if appropriate, the individual responsible for using the test results, or the name and address of the laboratory submitting the specimen, including, as applicable, a contact person to enable the reporting of imminently life threatening laboratory results or panic or alert values.

    (2) The patient's name or unique patient identifier.

    (3) The sex and age or date of birth of the patient.

    (4) The test(s) to be performed.

    (5) The source of the specimen, when appropriate.

    (6) The date and, if appropriate, time of specimen collection.

    (7) For Pap smears, the patient's last menstrual period, and indication of whether the patient had a previous abnormal report, treatment, or biopsy.

    (8) Any additional information relevant and necessary for a specific test to ensure accurate and timely testing and reporting of results, including interpretation, if applicable.

    (d) The patient's chart or medical record may be used as the test requisition or authorization but must be available to the laboratory at the time of testing and available to CMS or a CMS agent upon request.

    (e) If the laboratory transcribes or enters test requisition or authorization information into a record system or a laboratory information system, the laboratory must ensure the information is transcribed or entered accurately.