Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Although ELR has been required of all laboratories performing testing for reportable conditions, only Eligible Hospital labs have been required [Andrea: this is inaccurate. EHs are NOT required to use that format. Inclusion as a Certification Criterion did not make it required. CMS MU/PI could have made it required, but did not either. It is one of the CHOICES they have. So, a number of EHRs did certify against it, even a number of LIS systems effectively did (as they are always responsible to send an ELR), but many providers did not make the choice to do so. ] (Hans, which part do you think is inaccurate and can you provide the required format you believe has been in effect? I'm interested in seeing what you are seeing.   ELR has been part of MU for EHs since Stage 1 MU.  Certification criteria for vendors has been based upon the HL7 v2.51 IG referenced in the federal rules as certification has been handled nationally (in other words, health it vendors have not been certified by each jurisdiction).   NIST has ELR certification test tools vendors are tested upon when they get certified.  See https://www.cdc.gov/ehrmeaningfuluse/elr.html and https://www.cdc.gov/elr/technicalstandards.html  and https://hl7v2-elr-testing.nist.gov/mu-elr/

Furthermore if you search the ONC CHPL website of Certified Health IT Products ( https://chpl.healthit.gov/#/search )and filter for those certified against the criterion for transmission of reportable lab tests and results, you'll see the 108 vendors who have met the certification requirements.  Most are LISs, but some are interface engines or other modules/products.

Each jurisdiction indicates their onboarding criteria for ELR, which may be exactly the same as the IG or they may include additional fields or make some optional.  It's up to the sender to comply with each jurisdiction's requirements as part of their onboarding process. using a certified vendor system. What drives vendors crazy is there are slight differences for a state and sometimes they need to modify their interfaces to meet some of these criteria.  They wish requirements were exactly the same nationally.  These requirements (using a certified vendor system, HL7 2.51 messages, LOINC encoded results, SCT encoded qualitative result values.  Here's information from NCDPH's ELR page on their requirements:  https://epi.dph.ncdhhs.gov/cd/meaningful_use/elr.html You'll note near the bottom of the page they indicate their criteria is "more extensive" than ONC's requirements.   Here's Florida Health's criteria for ELR for MU:  http://www.floridahealth.gov/diseases-and-conditions/disease-reporting-and-management/florida-meaningful-use.html  and http://www.floridahealth.gov/diseases-and-conditions/disease-reporting-and-management/_documents/elr-implementation-guide.pdf  They also list how they wish pregnancy status and other info typically collected as AOEs to be sent.

That all said, for non hospital labs, they don't need to meet MU criteria (such as using a certified vendor system) as they have been ineligible for incentives.  They do however, need to meet each jurisdiction's criteria still.  Often the jurisdiction will require LOINC and SNOMED CT, but may allow either HL7 v2.31 or v2.51 messaging to be sent by the performing lab.  Als

Laboratories are the entities that report reportable conditions using ELR.  Reportable conditions are reported by providers using electronic Case Reporting (eCR) or other surveillance functionality.

When I was at CAP, I was part of the CDC & ONC funded Laboratory Interoperability Cooperative (LIC) team, which was tasked to assist 500 hospital labs including 100 CAH labs with their ELR for MU.  We worked with about half of the public health jurisdictions across the country.  About the same time, Riki was on a sister grant assisting public health laboratories with their ELR criteria.  I believe they worked with about 11 public health jurisdictions.  Riki please correct me if I've recalled incorrectly.)

 to send HL7 v 2.51 messages with LOINC and SNOMED CT codes conforming to each PHA jurisdiction's requirements for the past decade using a vendor system certified to provide functionality according to the HL7 ELR Guide in Meaningful Use regulations.  For the remainder of laboratories (i.e. blood banks, reference labs, government/DOD labs, independent labs), they need to meet each jurisdictions ELR requirements based upon the HL7 2.51 ELR IG [Andrea: since when do they meet that guide?when do they meet that guide? (See above references.  Is your point about the version of the guide?  The version cited in federal rules is not the most recent ELR guide so I'd agree with you there.)  We are aware of many variations where the intent is to have used the guide perhaps as a starting point; Riki: yes using the ELR R1 guide as a starting point], but may send messages in HL7 2.3.1 format, which 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. 

...

  • 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. - QUESTION: it does not have a slot for it (I thought that's what the Equipment (to be renamed to Product) UID is for) - or that information is not currently provided in that slot?  HJB: Still TBD in R2 to finalize location, either ObservationDefinition or DeviceDefinition. Riki: I was just talking about the current published spreadsheet version
  • 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. Riki: but it coudl be - the lan is to do STU update, so we could add these additonal AOEs as STU comments and include, so that part can be remedied as fast as Frieda can edit (wink) (AP:  eDOS supports any AOE as each laboratory may have different AOE needs for their CLIA Specimen Collection Manual/order catalog/lab compendium/eDOS content.  Each lab also determines their own phrasing for their AOEs.  Some refer to culture sources as site or specimen source.)
    • 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.

...

  • 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?
  • 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 PFT 15 (I think)
      • Can be sent in SPM (field?)

...

  • 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 R1 STU 3 Section 1.4.10X, 6.15, Z 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?)
      • 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
      • Use Mapping Spreadsheet below for PID and OBR fields that are RE if not R.
    • 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 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.)

...