Lab directory interoperability

[nhoffman]

https://www.openinfobutton.org/hl7-infobutton-standard

The HL7 Context-Aware Knowledge Retrieval Standard provides a standard mechanism for EHR systems and knowledge resources to communicate, implementing infobutton capabilities. The Infobutton Standard consists of the following specifications (links to download the specifications at the HL7 Web site are provided below)

Brought to mind by a comment from Brian Jackson on the mailing list in the context of a conversation about online test directories:

At the top of my own wish list: Easy integration into EHR ordering applications. When a clinician searches for a test to order in the EHR, they should be searching in the lab’s online directory, not the clunky search that’s currently embedded in EHRs. And once they find a test to order, actually ordering it needs to be a click away.

[nhoffman]

Also, from Alex Mays:

Hello all,

One project that’s relevant to this discussion is the HL7 FHIR Order Catalog Implementation Guide. It’s particularly relevant to the EHR integration/unified LIS solution comments of the last couple emails.

https://build.fhir.org/ig/HL7/fhir-order-catalog/uclabservices.html

The idea is that a laboratory could provide its test catalog via a FHIR API, whether that be to an ordering system, a web-based viewer, or what have you. It would also allow for catalog administration via a FHIR API if desired. This solves none of the organization/people problems with catalog maintenance, but at least it would provide structured laboratory information in an API with an industry-standard format. Those of you who have been pushing your vendors to adopt similar functionality may want to point them to this effort.

Please note the IG isn’t published yet, although I expect that it will be sometime this year.

-Alex

[apitkus]

Hello,

You may want to have separate threads, but a bit of history. There are HL7 V2 Implementation Guides (IG) for electronic Directory of Service (eDOS) for lab compendiums from the lab and receipt of lab results in the EHR. There is also the Lab Orders Initiative (LOI) IG for sending orders from the EHR to the LIS, Laboratory Results Reporting Initiative (LRI) IG for sending results from the performing lab to the EHR, Electronic Lab Reporting (ELR) IG for reporting to Public Health, and EHR-S functionality IG for receipt of lab results into the EHR. eDOS, LRI, LOI were part of the Stage 3 Meaningful Use proposed rule, but removed from the final rule so adoption has been voluntarily/variable.

NIST has test tools, scenarios/test cases for both LIS (as sender or receiver) and EHR as (receiver or sender) that are pretty good testing across different laboratory and result patterns. Although more complex cases such as pathology and genomics, reflexive testing are still needed. What's nice is

Regarding eDOS, here's an example of a 24 hr Urine protein. (Click on the left menu choices to expand the EHR or LIS Test Plan eDOS 1 (for initial compendium load) to eDOS 2 for updates for adds, deactivate, etc. functions).

There are a few other aspects in implementing too.

1. Keep in mind the average EHR/practice is interfaced to 1-5 laboratories, depending on insurance, the same desired "test" may need to be ordered from one or the other laboratory. Interfaces are also utilized when the EHR and LIS are not the same vendor/shared database (more on that in a minute).

With the interfaced systems, if the tests are the same (method, specimen, as reflected by same LOINC, etc.) a single test may be built in the EHR (one for orders, one for results or one for both depending on EHR/LIS build functionality, etc.). Orders, results can be comingled, etc. Most times, the LIS naming convention is not used in the EHR in favor of provider preferred naming conventions or generic terms in EHR builds. Thus, EHR functionality for ~10 of the major EHR vendors I've seen involves mapping the preferred EHR term to the order or result number for the performing lab test, so the performing lab knows which order the MD desires.

So in essence, this contributes to lab Inoperability as each EHR may use different naming conventions for say the same test from LabCorp, ARUP, Mayo, Quest or your academic hospital lab. So you cannot tell the full meaning of a test by it's name alone. Hence the value of encoding with LOINC that captures much of the info (but not all, in all cases).

2. A significant issue that is not fully realized by many yet, is when there are differences in "tests" many clinicians, clinical informatics build teams, etc. don't understand which are clinically significant and thus separate test builds are needed for each.
   Consider the following examples: LDH with a pyruvate to lactate reaction (https://loinc.org/14805-6) is 3xs higher than an LDH with a lactate to pyruvate reaction; AST or ALT with p5'P is clinically significantly different that without. These should not be comingled. Yet often there is a single EHR build term (and in some LISs), which does not reflect the methodology. Best case scenario, each performing lab maps to the method specific LOINC so downstream users can distinguish result values from each method to keep them distinctly separate in calculations, clinical decision support, RWE, and other decision making to avoid introducing biases.
   Worst case scenario are the EHR builds where there is a single AST, ALT, LDH (note the methodless naming convention), where different results and values are sent/received from the EHR-mapped to this single term and because most EHRs can only support a single LOINC map, the term is mapped to the methodless LOINC, thus losing method information there too. Clinically significant values are comingled, and shared, perpetuating the issue and potentially causing patient harm. It's like having a term Temperature and comingle values from degrees F and Celsius together in displays, calculations, decision making without distinguishing which scale of units is utilized. 32 in each has vastly different meaning!

3. Ideally distinct "tests" should be built, and flow from compendium to order to result, and sharing to PH, research, HIE or other EHRs. However, clinicians will complain about the burden of scrolling through 2-4xs as many orders (depending on how many variances of a test). Secondly, with the functionality above with the different naming conventions and maps to the test order or result number, when interfaced results are received in the EHR, the HL7 message is received at the doorstep to meet CLIA/CAP interfacing requirements, then remapped to the EHR's internal database terms and the original message is destroyed. Essentially any data may be preserved or remapped, usually to the EHR preferred terms.

4. In cases, where the same vendor is used for the EHR and LIS, a single term may be built and used internally as orders and results are not interfaced, but flow between "modules" and to the public health reporting module and then interfaces/messaged out. Usually the EHR is adopted/implemented first and then the lab module added on, so these terms are usually determined by the EHR build teams and challenging to change later without impacting all providers/patients.

5. I do agree that each performing lab's compendium info/terms should be searchable in CPOE workflows. Ask at Order Entry (AOE) questions should be presented to the provider at order entry (i.e. CLIA required LMP for Paps) and/or later in the workflow such as specimen collection (i.e. Hours of collection for 24 hr/timed urine, challenge doses, # hrs fasting). Their responses/info should be included with the order. Some EHR vendors have clunky functionality, hardcoding the questions to order terms. The burden to maintain with test changes takes time and effort as a result. One EHR also let's providers choose their preferred term from a list that is separate from the lab compendiums. Thus providers will order tests not even on the lab's menu and it gets rejected. Existing standards adoption and getting folks off of paper and faxed based orders is needed too. Nationally all EHRs/LISs and order functionality should be at the same level/bar of standards adoption. Then we can work to refine issues to improve the quality even more to get closer to the ideal wishlist/vision.
   -andrea