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 51 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- University of Wisconsin-Madison

Dan Rutz - Epic, IHE ???

Kathy Walsh - LabCorp

Michael Waters - FDA


  • 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
  • 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
  • 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
  • RE - Required but may be Empty (Must support)
  • R - Required

Current Challenges

When ELRs are sent to PHA at times, they may not contain sufficient demographic, and other data as is necessary required by public health by law.  While some of that data could be part of a subsequent eCR, if the data is already available at time of order and ELR transmission before an eCR is available (or the next eCR is available) helps accelerate the process.  eCR is out of scope for this discussion., although important too, and so data would need to be aligned with it.

Currently, the following are the messages/data flows that would be impacted.  Performing Lab CLIA Specimen Collection Manual (including orders, results, AOEs) to EHR  or referring lab LIS to populate/inform orders.  Then the ordering Provider/Lab EHR or LIS to the performing lab LIS.  Then the Performing Lab (public health lab or hospital or referral lab) back to ordering provider EHR or lab LIS (for referral specimens).  Then Performing Lab LIS or EHR (for integrated systems) to Public Health via ELR.  Then Public Health Agency to federal agencies (deidentified summary report.  Riki, what is this called exactly?).  (AP:  Are any steps missing in the workflow/messaging that would carry the data below?  Would be nice if we could have a box flow diagram illustrating, perhaps with numbers.  Then the numbers can be integrated in the table for the data elements below so it's clear for implementers which ones apply to orders, ELR, PHA summary, or all, etc. as I think it's a bit fuzzy from some of the call comments.  Would also help to ensure all the data would flow from interoperability perspective and a data element isn't omitted.)

As certification to ELR by EHRs, and certainly not Labs (AP:  Could someone clarify what is meant as many LISs are certified for ELR functionality and for EHs attesting to these measures in MU1-3.  It is inaccurate as stated. Am I reading correctly? LISs are certified as part of Health IT  Some such as Orchard are LIS vendors only and have no EHR products, but still report ELR) using the ELR R1 standard, and that eligible hospitals are not required to select ELR for their PI program, ELR adoption is not as high as desired, while implementation vary greatly between using HL7 v2.3.1 through HL7 v2.5.1 based messages or the HL7 ELR IG.  For the remainder of laboratories (i.e. blood banks, reference labs, government/DOD labs, independent labs), they need to meet each jurisdictions laboratory reporting requirements based upon local requirements that may be HL7 v2.3.1 based or HL7 2.51 ELR IG based, while messages may or may not contain LOINC or SNOMED CT codes or other fields   If 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. 

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), either at the point of order entry by the provider, or at the point of specimen collection by the collector.
  • document all available data 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) (AP. This has been available for over a decade)

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 with vocabulary.

Currently the specific challenges in that area are:

  • Device identification data is not included in device/test documentation
    • The latest LIVD guidance (IICC spreadsheet) nor the balloted but not yet published LIVD FHIR based IG 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 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 or PD1, 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 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.

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 date of birthRE-PHAThis is the preferred fieldIt is required for PHA, not desired for HHS
2Patient ageC-PHA, RE-HHS

If Patient Date of Birth is not available, then include the age at time of specimen collection using the methodless LOINC in case it is not in a dedicated field.

ELR already states that if date of birth is not present, then need age.

For reporting from PHA to CDC/HHS, when DOB may not be included or in ELR, when DOB is not available

3Patient raceRE-HHSUsed for socio-demographic

Clarify whether this is for socio-demographic or clinical purposes.

If for socio-demographic purpose, some jurisdictions used to not allow collection of this information - is that still the case? If so, will this superseed those regulations?

RM: this is for socio-demographic purposes, so expect in PID-10

4Patient ethnicityRE-HHSUsed for socio-demographic

Some jurisdictions used to not allow collection of this information - is that still the case? If so, will this supercede those regulations?

RM: this is for socio-demographic purposes, so expect in PID-22

5Patient sexRE-HHSUsed for socio-demographic

Clarify whether this is for socio-demographic or clinical purposes.

RM: this is for socio-demographic purposes, so expect in PID-8

6Patient residence zip codeRE-HHS

Some jurisdictions consider a combination of age, sex and zipcode PII, because of the population densitiy - need to accommodate that by allowing creation of regions (and that may be better done in the county field)

7Patient residence countyRE-HHS

Some jurisdictions consider a combination of age, sex and county PII, because of the population density - need to accommodate that by allowing creation of regions

ELR requires use of numeric FIPS 5-2 codes

  • County is hard to get since encoding of the county is not maintained in some/many areas.
  • We do have a slot .RM: PID-11.9
8Patient name (Last name, First name, Middle Initial)R -PHA
It is required for PHA, not forwarded to HHS (e.g., CDC)
9Patient street addressRE-PHA
It is required for PHA, not forwarded to HHS (e.g., CDC)
10Patient phone number with area codeRE -PHA
It is required for PHA, not forwarded to HHS (e.g., CDC)

Order Data

1Ordering provider addressRE-PHA
It is required for PHA, not forwarded for HHS
2Ordering provider phone numberRE-PHA
It is required for PHA, not forwarded for HHS
3Ordering provider name and NPI (as applicable)RE-HHSIf not provider, then ordering facility ORC-21

For some testing there may not be a specific ordering provider (e.g. employment related testing, mass screening) - it is a CLIA requirement so need to ensure that this is provided

What about ordering provider for home test (if through doctor office or on-line doctor who ordered).

For drive-thru it is possibly the Surgeon General

4Ordering provider zipRE-HHS

For some low density areas, this may provide too much identification in the HHS feeds

Concern has been raised that this may be hard to decide which to pick, for providers, that have more than one practice location

5Date test ordered (date format)RE-HHSGoing with ORC-15

Change the ORC-15 from O to RE

  • Question about having it available from the order or request.
  • Here are the definitons from V2.9 - ORC-37 is the right field, but it does not yet exist in V2.5.1
6Test ordered – use harmonized LOINC codes provided by CDCRequired-HHSAs structured and fully encoded as possible.  This is what is in OBR-4 at time of sending to PHA.

Currently no order code look up available - nor guidance on which LOINC to pick for which order

RM: Since the HHS mandate/guidance/FAQ document point to LIVD, I think we wil add guidance there (either as additional column (not currently part of the format) or as a tab with guidance language and then provide direction where in the LIVD to look for what part

Should this really be what the provider really ordered, vs. what OBR-4 actually contains going to ELR?  We interpret this as OBR-4 as valued at time of ELR.  

Hans: Check with HHS CIO who wants this and why.

Ask at Order Entry

SeqNameDefinitionOptionalityAllowable AnswersComments
1First test

  • Does this refer exclusively to the type of test being ordered? E.g. if a provider is ordering a COVID-19 serology test, but the patient has had a PCR test done in the past, would we say Y or N?  
  • Is it reasonable to assume that this is “first test known to this organization?” since it’s possible that the patient has had other tests through other means (e.g. walk-up clinics, or at a separate ED, etc.)?
  • This is to be asked of patient.  That is a concern as we would want to default to existing data where we can.
  • If this can be derived (e.g., system has a test already on record) then o.k. to default.  Otherwise need to be asked.
  • Is it relevant for previous test for diagnostic, screening, or research.
  • CSTE had 40+ Epidemiologist on and had additional questions, no answers;
    • Is there clarification between first diagnostic test and first screening test?
    • How would PH use this info?
  • Hans to check with HHS CIO office.
2Employed in healthcare?Working in a high-risk setting with patients who could be a super spreader. (first responders, front line clinicians, environmental staff, therapists, in direct contact with patients or in their location)


  • What is scope? Include Physician, Nurses, Environmental, Therapists.
  • Is it to ascertain risk to those treating patients?
  • Riki to check with CSTE on scope.
  • Valueset for Y/N/U - expanded Yes/No is HL70353, BUT not suing U, is using UNK; there is HL70239, but it is called event expected, that is using U - I think using UNK instead of U is common and we should just point to the PHINVADS valueset (Y/N from HL70136 and UNK from V3 Nullflavor) that is used for Case notifications:
  • PROPOSED question to use in LOINC: Patient is employed in a healthcare setting?
3Symptomatic as defined by CDC?Symptomatic per current CDC guidance at time of order for the reportable condition/illness
4Symptomatic = Y then Date of Symptom Onset

Will use this LOINC = 11368-8 Illness or injury onset date and time = LOINC from


Hospitalized due to suspected reportable condition? Y/N/U

Replace with: Patient was hospitalized because of this condition


Patient has been hospitalized for reportable illness/condition that this order has been placed for (suspected or diagnosed)

When ordered during ER duration, answer would be N.

Same LOINC as on case report = 
  • 77974-4 Patient was hospitalized because of this condition
  • ACLA agrees with this LOINC
  • Assume Y/N/U see above and apply same value set to all
  • Another way to ask = Patient has been hospitalized for current illness
5Hospitalized at time of order? Y/N/U      DELETE ROW

Hospitalized at time of order can get that in PV1-2

  • Does this refer to if the patient is currently hospitalized or hospitalized within the past # of days/weeks?
    • It is for this condition.
    • CSTE answer Currently hospitalized, perhaps ER at time of order?
    • At time of order.  That may be a problem if they want at time of specimen collection
  • Should this only be answered Y if patient is in the hospital for COVID-19 symptoms? Hospitals may be screening all inpatients, whether they're in for suspected COVID-19 or a cardiac problem.
  • CSTE answer: WA State noted that for when they've used this AOE in the past, they tailored it to "hospitalized for symptoms relevant to the condition." However, it was also noted that since the symptom set for COVID is so diverse and seemingly ever evolving, it could be potentially useful to cast a wider net. ; Also noted that PV1 is not always reliable
  • Which code system/value set?
  • OBR-31 for reason for exam?  Hospitalized due to COVID, mass screening, etc.

ICU due to suspected reportable condition? Y/N/U 

Patient has been admitted/transferred for reportable illness/condition (suspected or diagnosed - at any point up to the ELR report in current encounter)

  • Does this refer to if the patient is currently in the ICU or has been in the ICU within the past # of days/weeks?
    • At time of order.  Similar problem as above.
  • Should this only be answered Y if patient is in the ICU for COVID-19 symptoms?
    • It is for this condition
  • Riki thinks it may be as part of case.  Then need to understand if test is shortly post discharge
  • CSTE answer: Note that at the beginning of the response, both 'Hospitalized' and 'ICU' were used to prioritize case investigations for the sickest individuals. However, now that priority paradigm may be shifting
  • When interested in whether in ICU at time of order, use PV1 location/organization providing care.
  • PROPOSED LOINC: Patient has been admitted to ICU due to suspected reportable condition (or "for current illness" or "due to this condition"?)
  • Assume Y/N/U see above and apply same value set to all
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)

This is at time of exposure where they normally live.


Proposed LOINC: Patient normally resides in a congregate care setting

Assume Y/N/U see above and apply same value set to all

8Pregnant?Current pregancy status of the patient

Which code system/value set? 

Specimen Collection

1Date specimen collected (date format)Required-HHS
ELR allows use of 0000, when date is unknown
2Specimen Source - use appropriate LOINC, SNOMED-CT, or SPM4 codes, or equivalently detailed alternative codesRequired-HHS

OBR-15.1 and OBR-15.4 in V2.3 

SPM-4 - SPM-8 in V2.5.1

3Accession #/Specimen IDRequired-HHS

Accession# = OBR-3 in V2.3 and V2.5.1

Specimen ID = N/A in V2.3, SPM-2 in V2.5.1

Test Result

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

N/a in V2.3, often assumed from MSH-4 in V2.3, because the reporting facilty is assumed to be the performer (but that may not be the case)

OBX-23 in V2.5.1  Strongly suggest to pre-adopt.

2Performing facility zip codeRequired-HHS

N/A in V2.3 - not sure where that would come from

OBX-24 in V2.5.1 Strongly suggest to pre-adopt.

3Device IdentifierRequired-HHS

Intent is to know which test has been performed where (reagents and instrument)

Can be pre-cooridnated as per EUA, or off-label use = indicate each separately

N/A in V2.3, so may need to provide OBX with LOINC and use OBX-4 to link to the OBX it relates to - can we map the UID components to te elements in this panel, so we can decide which one is the DI?

OBX-18 in V2.5.1

Use Device Identifier (Model number) in UDI or Manufacturere name + test kit name (per EUA)

Still TBD:

How do you know when test kit is off-label vs as per EUA?

How to identify the different aspects (Reagent ID, instrument ID, EUA ID?)

4Test result – use appropriate LOINC code, as defined by the Laboratory In Vitro Diagnostics (LIVD) Test Code Mapping for SARS-CoV-2 Tests provided by CDCRequired-HHSThis is referring to the performed test (observation.code in CDA/FHIR)OBX-3
5Test result (value) – use appropriate SNOMED CT code as defined by the Laboratory In Vitro Diagnostics (LIVD) Test Code Mapping for SARS-CoV-2 Tests provided by CDCRequired-HHSThis is referring to the result value (Observation.value in CDA/FHIR)


Some results can be numeric, and require units of measure, but no SCT code

some results could be longer text, specifically interpretations

SCT is required for qualitative result values

6Test Result date (date format)Required-HHS

N/A in V2.3 - suggest to use OBR-22

OBX-19 in V2.5.1

Updates to Implementation Guides

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
    • 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 (AP:  Is the expectation that the performing lab update their descriptions to those in a master list?  (i.e. they say Pregnancy Status and AOE master is Pregnant?) 
  •  LOI
    • None?  CLIA test request requirements listed under Resources below.
  • LRI
    • Add guidance on how to convey device identification information
      • Can be sent in OBX 3 as a result for "reagent identifier" build as a test result in the panel reporting COVID results.
      • Can also be sent in PRT-15 (I think)
      • Can be sent in OBX-18

Implementation Guidance


  • Data Elements
    • Use proper segments per Mapping Spreadsheet below for PID and OBR fields.
      • If the guide indicates they are optional or not supported, consider them RE.
      • If not possible, then use OBX segments using LOINC codes per Mapping Spreadsheet.
    • 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 the following data, use OBX for interpretation of lab result:
      • 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.  (AP:  EHRs are sending some AOE questions and responses in their orders, such as for cultures, but what is the delta from their current implementations to LOI conformance?  HJB: Not sure that matters.  We're defining the goal and indicate that if you can't, then step back)
      • Include Profile TBD, but a new profile in MSH-21 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 PLUS [whatever list Riki is adding if maintained separately for now]
        • eDOS would be electronic version of CLIA Specimen Collection Manual FH: Please clarify this statement  HJB: Ditto.  Does eDOS address everything in CLIA SCM or more?  If the latter, we should not set an expectation that eDOS is limited to CLIA SCM. AP:  Former.  eDOS includes the CLIA Specimen Collection Manual content in electronic format, but the v 2.51 eDOS IG also includes additional items such as Charge/Test Master.  The FHIR Orders Catalog is also aligned with CLIA Specimen Collection Manual requirements too.  Once finalize may wish to have HHS/CAP input to make sure no issues before implementing.  HJB: Given that, I suggest to remove this sub-bullet as it only confuses in this context since we are only pointing to attachment A.  Implementors would get very confused pulling this in and wonder what they are supposed to do with that.  
  • Results - Any ELR to PHA
    • Use LRI R1 STU 3 Section 8.11, 13.3.3, Z for specification on how to add/forward AOEs with the result using OBX segments that are based on HL7 v2.8.2  (AP note:  AOEs become/are results and their values in OBX 3/5 messages sent to providers and PHA via ELR.  HJB: clarified in both Orders and Results.  Thank you!)
    • 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 Attachment A 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.  (AP Note:  LRI is separate form ELR and ELR is required by law, while LRI is not technically required anymore, but was for stage 2 MU of hospital labs only.)

Device Identification

  • It is expected that some test kits/reagent packs/cartridges will not have an official Device Identifier, so any unique device identifier will do.  (AP:  should confirm this statement is what FDA expects as not sure it is.) For purposes of this discussion that is considered a Device Identifier.  Keep in mind for manually performed tests such as rapid kits, point of care testing or non interfaced instruments, these will have UDIs that are manually entered into the LIS.
  • 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. (AP:  What does this mean?  Do you mean as a test result and result value? The assay produces the test results)
    • Issue: is IVD Test Code always related to exactly one test kit?
    • Ed from Abbott is checking on ROMA assay, which utilizes results from two other assays/regent packs to produce the calculated ROMA result
  • 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 has been confirmed many LISs do not have that capability today, so may not immediately have that available. The performing laboratory could build it as a OBX 3 to take advantage of existing LIS functionality. 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
      3. Enter the barcode value into a designated lab result value field in the LIS to be stored for a patient result value or in another field in the LIS for the test build.  When results are reported, the OBX 3 field is populated with the result value of the barcode.  UDI barcodes could be scanned with the implementation of reagents in the test build/set up screens for use for each patient instance.
    • 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.
  • UDI for equipment/instrumentation platform  (In scope as of 16Jun20 call)
  • Out of Scope
    • UDIs for control and QC
    • UDIs for specimen collection devices (i.e. swabs, containers, additives)

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 - these were the current usages I found, so some will need to be adjusted
  • FH: Race and Ethnicity have an extra value not in the 2018 Lab Value spreadsheets:  "PHC1175^Refused to answer^CDCPHINVS", do we need an action item to update the Value Set spreadsheets?  (I was not successful updating the spreadsheet so added question here)  HJB: Agreed.

  • 2020-06-16 FH: SPM-4 in ELR R1, Section 6 Vocabulary Constraints  references Specimen Type Value Set, description is "Specimen Type - Union of HL70487 and SNOMED CT Specimen sub-tree (12303009)." The Mapping Spreadsheet references LIVD with comment: "LIVD provides SCT codes for SPM-4."  For ELR can we use the value set defined in ELR?

  • 2020-06-17 FH: typo in Patient Ethnicity coding system reference,  "U^Unkown^HL70005" should be U^Unkown^HL70189"
  • 2020-06-17 FH: Patient Race includes "U^Unkown^HL70005" but HL70005 User Defined table does not include Unknown (even in V2.8.2)
  • For specimen source/type, should we also reference OBR-15 for really old systems that don't support SPM?

Open Issues

  • 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?
    • 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 reaggents created from scratch.
  • UDI for manual test kits and LDTs (non analyzer performed tests)?
  • Do we need multiple test kits? Ed will check if 1 or 2 UDIs

  • 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.  (AP:  What is meant by certification?  ELR for non hospital labs has not required use of 2015 vendor certification products.  In fact it can still be sent on paper, flat file or via portals.  Also ELR and LRI guides/messages are separate and go to different places.  Some LISs have fields in their database and send ELR messages with fields they don't send back to ordering provider via LRI.)
  • 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!).
  • Options for differentiating OBX for AOE vs OBX for results:  (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?)
    • 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
    • In eDOS, AOE is represented in  XXX  field
    • In LOI, AOE is represented in 
  • 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: Becasue this is for manual data entry
  • What shall we point to for LIVD latest guide? Riki: Unfortunately the IICC link is the only one official, right?

Resources for Background

  • Link to current guidance:
  • Link to FAQ document:
  • Information Blocking Actors:  (Includes labs)
  • Information Blocking Definition:
  • USCDI Data Classes, Elements and Standards:
  • CLIA regulations:
    • 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.

  • No labels