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
Dan Rutz - Epic, IHE ???
Kathy Walsh - LabCorp
Michael Waters - FDA
- AOE - Ask at Order Entry
- eCR - Electronic Case Report
- eDOS -
- ELR - Electronic Lab Reporting
- LOI - Laboratory Order Interface
- PHA - Public Health Authority
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:
- Deployed lab order standards do not have the ability to convey all the relevant ask-at-order-entry questions and answers.
- 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 in active use
- Upgrading to the latest LOI guide is a major lift for everybody, so although desired, is not a good short-term recommendation
Just copied across, not in the right place:
- Is the following accurate interpretation of intent as we know it so far:
- Enhance electronic order flow as much as possible that:
- Ordering systems are capable of asking for and including all applicable AOEs with the order to the lab, particularly where that lab runs on a different system and even more so if that lab is external to the provider’s organization.
- Users are strongly encouraged to include all known information at the time of ordering, recognizing that in a number of situations that information would not be available at time of order.
- The ask is NOT to send an order for test related to a reportable condition to a PHA directly.
- Enhanced ELR content to include all relevant demographic data received from the ordering provider AND all AOEs in the ELR transmission, whether done by the performing lab or perhaps the ordering provider as well based on local requirements.
- If accurate, then the ways to achieve this are:
- AOE Encoding
- The AOE should be encoded according to the latest eDOS IG plus any additional LOINC coding for questions that are not yet in that IG.
- Note that 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
- Order Flow
- Ideally we would like adoption of the latest LOI IG and ensure that where a test goes through multiple hops effectively all data is included for the performing lab (e.g., ordering provider to internal lab that may not need all that information with the order as they can get to it other ways, and then on to a reference lab that does not have that ability to find out otherwise since they are not integrated with the ordering system – the internal lab needs to ensure everything is included)
- That is not likely to happen in this time window, so best is to provide reference to the specific AOE sections in the LOI IG that one is to include that for the AOEs into whatever the current order message is when using HL7 v2. We have provided that approach effectively in a similar situation.
- It is unclear how to get the data from the ordering provider to the performing lab (excluding paper) so the Lab can include it in the ELR. There does not seem to be a viable alternative using .csv files to properly sync.
- Maybe the ELR alternative flatfile format could be used for data collection around the order, too?
- ELR Flow
- Ideally we would like adoption of the latest LRI IG that includes ELR capabilities
- That is not likely to happen, so similar as above, pre-adoption of the relevant sections in the LRI IG that is then included in the existing ELR transactions
- 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.
- If neither of the above can be put in place, then the submitter is to send a .csv file according to a defined template preferable to a Direct Address (most stakeholders support that and has higher opportunity of automation in batches) or a portal for manual submission.
- 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)
HHS element mapping
Use this spreadsheet to collect options and comments around the proposed mapping of the HHS elements to various places in Order and result messages.
Straight from today's LIVD call, needs to be cleaned-up and merged with above where appropriate
- ELR Lab Reporting
- For the "device used to perform the test" the ideal goal is to get UDI Carrier with the test result for the test kit(s) used, not the equipment/instrumentation platform. The initial target of most importance is the Device Identifier as defined by UDI.
- It is expected that some test kits will not have an official Device Identifier, so any unique device identifier will do.
- 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.
- 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. 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.
- Open question whether we need to support multiple test kits/components for one test. There are examples, but seems to be an edge case.
- QUESTION: Couldn't the device ID be included in the LIVD document - and provide guidance around what to use for the assigning authority??
- LIVD DeviceDefinition
- On the DeviceDefinition we need to ensure the Device Identifier is valued to ensure that the actual test data can be used to compare with the LIVD data to assess consistency with proposed LOINC encoding for the test kit used. Already, using Palantir, many thousands of discrepancies have been identified.
- 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.
- UDI - not discussed beyond above to determine whether it means that we use the DeviceDefinition for the kit or the ObservationDefinition as it is 1:1 linked to the IVD test code.
- Need a product reference uid to identify the ObservationDefinition
- Need to re-include ObservationDefinition.identifier 0..*
- identifier.type = "product-reference-identifier"
- identifier.system = TBD (for uid)
- Profile Updates - Not discussed
- Applied the ObservationDefinition update. Need to sync with the gitHub version.
- Clarified that Composition.type.version etc. is NOT the version of LOINC used in the mapping (ConceptMap). Rather that it is the LOINC version according to which the LIVD Catalog LOINC Code has been defined.
- We already may have the LOINC version of the LOINC code being mapped to in the right spot. We will check that next week.
We agreed, and Michael agreed, that he be added to the e-mail list. We also agreed to set up a separate Confluence Page to start to pull everything together: flow, guidance, issues, resource references to start.
From the chat to be included in subsequent documentation.
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
Data Flow and Guidance
Test Configuration - LIVD
Lab Orders - LOI
Electronic Lab Reporting - ELR
Resources for Background
- Link to current guidance/FAQ document