OO ONC NPRM Response Draft

OO Draft Response

HL7 OO offers the following feedback on ONC's Laboratory RFI in the ONC NPRM [get full names].

• The utility and maturity of existing HL7 v2 and C-CDA standards supporting laboratory interoperability and the impact of moving to FHIR-based laboratory data exchange.
  

HL7 v2, CDA, and FHIR all support laboratory test ordering, resulting, and sharing to a greater or lesser extent with varying areas of focus and levels of maturity adoption.  The following provides a brief overview of the current state of these standards in this context.

HL7 v2 continues to be the primary vehicle to support laboratory testing workflows using various versions and implementation guides.  HL7 v2.3.1 through v2.5.1 are the predominant standards version used, while more current versions are mostly used as a source to pre-adopt specific capabilities otherwise not available.  This typically has occurred through the Laboratory Orders Interface (LOI) and Laboratory Results Interface (LRI) guides that not only cover the full ordering and results workflow, but also specific profiles within them enabling inclusion of those profiles in any existing HL7 v2 standard use of order or result workflow, whether highly localized/customized or not.  These standards versions are primarily used, while adoption of the full LOI and LRI implementation guides are limited, even though various HIT have adopted the LRI guide associated with ONC's 2014 Certification Edition with EHRs being certified by ONC to a particular version referenced in ONC 2014 Certification Program and some laboratories' LIS having validated its ability to support CLIA requirements.  HL7 v2 also includes a EHR functional specification that further defines the ordering provider's HIT responsibilities when receiving the official results report in response to their order, recognizing that others copied or forwarded on that report may not have the same requirements, etc. secondary data reporting.

With the pandemic, guidance was expanded to not only cover general ordering and results reporting plus specific guidance for Ask at Order Entry questions (AOEs), Newborn Dried Blood Spot testing (NDBS), and genomic data, but also additional AOEs to pass critical demographics and Social Determinants of Health (SDOH) data through the laboratory, and include test device data (supporting both test kit/reagents and instrument and model information leading to multiple UDIs often being messaged).  While the implementation guides support these data, actual adoption has been more challenging due to availability of the data and/or sufficient drivers to adopt.

HL7 v2 also includes an Electronic Laboratory Results reporting (ELR) implementation guide that is currently used for certification for reporting to Public Health.  Its most current version is now expressed as a profile within the LRI implementation guide and is suitable for use.  In fact, COVID related additional data requirements are currently fully incorporated in both LRI and its ELR profile within, as well as LOI.

HL7 v2 includes a directory of service (eDOS) where a laboratory can share available tests for ordering with a provider.  Some organizations support an earlier version, but widespread adoption, including using the latest version has not occurred at any scale.

HL7 CDA, through the C-CDA implementation guide and Companion Guide permits sharing of laboratory order and result information, along with other health data, as part of the information in the document types currently required under ONC's Certification Program.  However, implementation of CDA is mainly downstream from the origination of laboratory data in the laboratory information system (LIS), occurring in the EHR, HIE or other downstream HIT or modules.  CDA is utilized for document exchange but is not intended to manage workflow or other individual discrete data exchanges.  There are no plans to expand the use of HL7 v3, CDA, and C-CDA in particular for additional laboratory messaging needs, especially given CDA, and C-CDA are not designed to support laboratory ordering processes.

HL7 FHIR is emerging as the new, broad based data sharing and exchange standard.  Certified EHRs support FHIR based query access to some laboratory data exposing a subset of the lab order and result data, particularly data required by USCDI.  However, currently many LISs lack such FHIR functionality.  While the FHIR Order Catalog IG exists for exchanging and updating laboratory compendium information as the analog to eDOS, FHIR equivalent IGs are lacking for LRI and LOI to support the laboratory order and results reporting workflow between a provider and laboratory in a CLIA compliant manner.  Additionally, efforts are in progress to publish a FHIR based directory of service, as well as a FHIR based Laboratory IVD Test code mapping (LIVD) IG where manufacturers of laboratory tests can provide guidance on the most suitable mapping of IVD test codes (organized by instrument and model) to LOINC codes for results.  The guide is also being expanded to cover IVD test result values mapped to SNOMED and or LOINC answer codes.  We note that while catalog and mapping information needs to be available to all participants in the workflow, this does not mean that all EHRs and LISs need to ingest such data, thus having to support these use cases in full.  The advancement of on-line directories, through web sites or Apps that can be accessed in context, can provide alternate means of enabling those configuring their systems to have the necessary guidance available at their fingertips.  Lastly, there are FHIR based IGs for clinical genomics (recently developed) and electronic pathology and cancer reporting (under development) for results reporting, usability of data within genomics, anatomic pathology and related laboratory areas that historically used non discrete text blob-based reports such as pdf documents. 

Therefore, most uses of FHIR involving laboratory data involve exposing a subset of the lab order and result data, at least data required by USCDI although could be more depending on the system, that is made available through FHIR based APIs for query in some implementations."  Other implementations may "transform" HL7 v2 laboratory message data into FHIR in a downstream system.

In summary: 

• • • HL7 v2 LOI and LRI are sufficiently mature to support the respective workflows and CLIA compliant implementations for order and result sharing.
    • While HL7 v2 eDOS is available and provides guidance on AOEs and information on laboratory ordering, it is not widely implemented.
    • HL7 CDA, C-CDA, and Companion Guide are sufficiently mature to support sharing information about orders and results without workflow management; and
    • Although FHIR profiles are available for basic display and sharing of laboratory data, these profiles and implementation guides are generally insufficient for laboratory orders and reporting in a clinical context. FHIR elements, profiles, implementation guides, like US Core, and others needs further development and testing in order to be sufficiently mature.

As a general note, as data requirements for SDOH and SOGI change (where SDOH data for public health reporting in particular and some SOGI data as well should be more an area of focus for case reporting, thus reducing the load on the laboratory workflow having to share data not relevant to the performance of the laboratory), all the above guides are subject to enhancements which are currently in flight for SOGI data in particular.  We note that for most reportable laboratory tests a case report would be required as well thus aligning case reporting is reasonable.  However, for some laboratory tests there is no corresponding case report requirement so we need to understand better how data flows can be made less cumbersome.

• Which implementation guides or other standards should ONC adopt in certification criteria for health IT supporting transmittal and receipt of laboratory orders, laboratory results and directory of services?

When considering use of either of these guides for certification it is not only a matter of maturity, but also adoption, effort, and incentives.   We note that the ONC Certification Program, while positioned as an HIT certification program, is primarily focused and used by EHRs.  HIT developers and providers using them are incented to adopt certain implementation guides.  Eligible Providers and Eligible Hospitals were incented to adopt certified HIT.  Consequently Health IT developers, mostly EHR developers and various LIS developers supporting Eligible Hospitals reporting to public health, were incented to participate in ONC's certification program to adopt certain implementation guides.  However, clinical, commercial, and public health laboratories and their LIS developers were not similarly incented to adopt those same implementation guides, although some do support the LRI and ELR guides.  As a result, there is clear adoption of the HL7 CDA C-CDA and Companion Guides for document based laboratory results sharing, HL7 FHIR US Core based RESTful API access to laboratory results, and HL7 v2 ELR for electronic laboratory reporting to public health agencies.  However, adoption of the HL7 v2 LRI guide for electronic laboratory results reporting supporting formal results reporting under CLIA has been limited.  The cost of adopting certified LRI capabilities by providers was not offset by the cost, even as capabilities were available, as the incremental benefits were minimum.  

Reporting electronic laboratory results supporting CLIA requirements has been based on multiple versions of HL7 v2 messages well before ONC started its certification program.  Some of these versions do not support complete specimen information needed by public health, cancer registries, and genomics.  Without additional resources, most laboratories have been unable to voluntarily adopt additional IGs or standards.

Other than for new interfaces, including the HL7 v2 LOI and LRI (including the latest guidance for ELR reporting to Public Health) in ONC's Certification would not yield the advancements expected.  The benefits of replacing existing interfaces in full do not outweigh the cost of such an upgrade, even though the guides provide a fully aligned set of implementation guides addressing CLIA requirements and establish consistent use of HL7 v2 for various complex interoperability use cases.  For existing interfaces, a more targeted approach, which the guides also support, introducing individual profiles that can be used with any existing HL7 v2 laboratory order or result message can advance data quality and consistency at a lower cost by focusing on use of the aligned value sets. Focusing on more consistent adoption of standard vocabularies (in particular LOINC, SNOMED, UCUM) would likely have more benefit than promoting the adoption of up to date LOI/LRI versions when other HL7 v2 interfaces have been widely adopted. 

• What barriers would additional health IT certification criteria for laboratory interoperability create for developers and other interested parties, and how might this affect adoption and use of such technology?

As indicated in the prior question, key barriers include having aligned incentives for all stakeholders (in particular EHR developers, LIS developers, providers, laboratories, and public health) to adopt the same versions of the standards and implementation guides.  Having the EHR developers and providers aligned on HL7 CDA C-CDA plus Companion Guide and FHIR US Core is sufficient for other HIT to consistently be able to receive and share general laboratory results data.  For workflow management focused the same incentive program alignment should occur while the respective HIT vendors should focus on adoption of key profiles in LOI and LRI to begin alignment.  ONC's Certification Program should align with CLIA and laboratory regulatory requirements to minimize overhead to all stakeholders and enable adoption of those IGs and profiles for laboratory data.  We note that LISs have long life cycles during which interfaces rarely change as a whole.  ONC should explore opportunities for new interfaces and providing laboratories funding to implement to take advantage of adopting the newest versions in total, but must recognize that this is a longer term challenge to balance cost and benefit.

The more critical barrier to focus upon is the accurate adoption and consistent use of appropriate vocabulary standards, particularly LOINC, UCUM, and SNOMED.  Fidelity of these mappings should be preserved in downstream systems when orders and results are shared to prevent loss of test meaning and computerizability. Having improved directories of services with the correct encoding, encouraging the use of IVD LIVD coding maps, as well as encoding the results correctly as close to the source is essential.  Additionally, where relevant adding device/instrument data, and aligning public health laboratory reporting with case reporting can further optimize and increase data quality.  For example, the more laboratories adopt LOINC encoding for their test orders and results (where available), the more these "trigger codes" are available downstream to help meet electronic case reporting (eCR) reporting requirements.

• Would developers of laboratory information systems or in vitro diagnostics systems that have not traditionally submitted products for certification under the Program seek out and benefit from certification to criteria relevant to such developers’ products?

LIS developers have not been subject to ONC Certification Program style certification, while laboratories using their systems have been subject to CLIA requirements such as the laboratory obtaining a CLIA certificate. The CLIA program primarily focuses on laboratory quality requirements such as data content (presence of critical data in the report), but not how these are met.  CLIA originally involved paper based processes, which some laboratories still utilize for their ordering and reporting.  However, as HIT was implemented, the requirements still must be met, but now IGs, profiles and other standards utilized in meeting them, must permit users to implement HIT in a CLIA compliant manner, no matter the version of HL7 (v2, FHIR, etc.) including IGs, profiles, etc. utilized.  From an interoperability perspective, alignment on a common version of a standard, including a specific implementation guide version, including use of common vocabularies and value sets, reduces friction when implementing those interoperability capabilities.  Unlike the rollout of C-CDA and FHIR US Core where certification drove adoption, HL7 v2 messages have been in wide and varied use well before ONC started its certification program.  Upgrading laboratories and their LISs, all EHR vendors, public health LIMS and information systems all at once will be a significant and challenging lift with incremental benefit.  Consequently, while there are clear benefits to having both EHRs and LIS certified to the same standards and implementation guide versions, without the necessary incentives for providers and laboratories to implement the upgrades, and considering the cost of adopting the latest standards and implementation guide versions, not many LIS developers seek out certification or laboratories voluntarily adopting these latest standard versions as seen during the Meaningful Use era.   

Addressing the alignment of incentives and creating a progression of steps towards adoption of a common standard and implementation guide, focusing on key profiles defined in the LOI and LRI guides that can be pre-adopted into existing interfaces., can substantially address these challenges and ease the adoption challenges of the most desired capabilities to foster interoperability.  For LIS developers and laboratories as well as for EHR developers and providers, a focus on the accurate and consistent use of vocabulary and value sets (LOINC, UCUM, and SNOMED in particular) would be most important.  A focus on introducing new data requirements consistently across the board, e.g., Newborn Dried Blood Spot (NDBS), pandemic data, device information, and genomics data would yield substantial benefits at a more affordable cost.

As ONC's Certification Program is voluntary, adoption is primarily driven by other programs, such as CMS' payment programs.  Currently, legislation such as the Protecting Access to Medicare Act (PAMA), with its reduced reimbursement and cuts to laboratories, has negatively impacted funds available to laboratories, including for adoption and upgrades to HIT and standards.  Reversing said impacts, which have been on hold during the pandemic, and adding additional funding for laboratories could incent laboratories to adopt most current HL7 v2 standards and implementation guides.  Incentives to additional laboratory data stakeholders could help spur FHIR US Core based APIs for laboratory data access.  Appropriate incentives must be in place for both providers and laboratories to subsequently drive demand for use of EHR and LIS certified products, to incent developers to participate in the relevant certification programs. and without increasing vendor related costs to laboratories and providers.

• Are there any other steps that ONC and HHS should consider taking to advance laboratory interoperability?

We suggest that:

• • • ONC work closely with the FDA and SHIELD to advance the adoption and consistent use of critical vocabulary and focus on adoption of key functionality to advance the consistent exchange of NDBS, device, pandemic, AOEs, and genomic data using HL7 v2 messages for systems needing to share that.
    • further alignment and optimization of ELR and eCR data flows should be considered to reduce impact on ELR reporting, where data that is not necessary for the the performance of the lab tests, needs to be communicated by the ordering provider to the lab solely for inclusion in the ELR transaction to public health.  
    • To advance laboratory interoperability especially with public health reporting (i.e. ELR and cancer), we recommend laboratory order messages contain adequate discretely encoded specimen information (e.g. collection procedure, specimen type, specimen source) at a minimum as needed for these laboratory and public health reporting needs. Find ways to ensure providers are using the existing capability in EHR-s to record those elements.
    • ONC focuses on more consistent adoption of standard vocabularies, better defining the use of SNOMED for specimen attributes as an additional profile in V2, CDA and FHIR IGs as that would greatly improve quality of this vital clinical context to the lab result.

OO Discussion Notes

• Reviewed the specific questions and started collecting suggestions for responses.
  1. Which implementation guides or other standards should ONC adopt in certification criteria for health IT supporting transmittal and receipt of laboratory orders, laboratory results and directory of services?
     1. Results - LRI R4
        1. back as not much advances made in consistent coverage and plug/play
        2. maybe R5 once available for SOGI and NBS.
        3. LRI includes ELR = PH_Component; so improved alignment with public health
        4. includes profiles for specific lab use cases – like clinical genomics and newborn screening, which
           1. would benefit from consistent reporting and become mainstay
           2. can be pre-adopted into older result messages
        5. Addressed COVID/Emergency Preparedness data. HOWEVER, not convinced that LRI (thus LOI) is appropriate for all added data important for PH, but not for Lab operations and that eCR would provide a better path for those.
        6. Consider the EHR-S to clarify what the receiver's responsibilities would be for the receiving ordering provider in particular.
     2. Consider ELR to go to LRI +PH_Component through SVAP if feasible. Would create a common base for others to move to LRI.
     3. Orders - LOI R4 would enable consistent order content.
     4. Test Catalog - overall this is a harder one to fit into the configuration workflow 
        1. options are eDOS (v2)- not proposed
        2. FHIR catalog - could consider FHIR Catalog, but
           1. not yet mature to adopt with clear benefits. Perhaps as price transparency becomes more mainstream it starts to have more value.
        3. inability to define/map the devices used that further enable inclusion of test kit UDI at this point.  
     5. Note that while LRI supports UDIs on Test Kit, the LIS would not necessarily be in a place to provide that consistently, and adoption is not sufficiently mature to understand that it covers all use cases fully, e.g., multi-UDI (device, re-agent, etc.) for EUAs and other permitted instrument platform configurations.
  2. The utility and maturity of existing HL7 v2 and C-CDA standards supporting laboratory interoperability and the impact of moving to FHIR-based laboratory data exchange.
     1. For provider-laboratory interactions HL7 v2 is the workhorse to communicate orders and results managing workflow, BUT
        1. not as consistent and interchangeable, but established, so need ROI for upgrades
        2. maybe when new data elements / use case needs force updates
     2. For provider-provider/payer/research the HL7 C-CDA is well established, although HL7 v2 is widely used when sharing involves HIEs.
     3. While FHIR has promise, replacement of the main workflows between providers and laboratories in terms of volume would not yield sufficient benefits to shift.
        1. The focus need to be on green-field topics:
           1. genomic data sharing along with the order or the result
           2. DME orders requiring more data for prior authorization
           3. walk-in laboratories managing orders. i.e. ability to support “lab shopping” where one receives a QR code and can select the laboratory of choice which in turn requests an order to be forwarded.  That forward may be an HL7 v2 message, while a FHIR based approach becomes viable.  Can we define what is meat by walk-in as this use of walk-in seems different from the below use of walk-in?  
           4. Results of the more complex / complicated use cases like genomics and anatomic pathology, where v2 interfaces do not currently yield good structured data
           5. storing results in FHIR resources for access by secondary data users like PH or research
        2. We note though, that the FHIR guides are in progress, e.g., DME/PAO, but not for the wide range of order/result flows. 
     4. As C-CDA documents move to FHIR Documents and Collections the opportunity to migrate is more imminent.
     5. As the FHIR knowledge base and capabilities expand that make easy migration from HL7 v2 realistic and/or v2 expertise starts to run out, such conversions will accelerate. We do note that where additional data is needed, it still may be most efficient and fastest by adding data to HL7 v2 than switching to FHIR.
  3. What barriers would additional health IT certification criteria for laboratory interoperability create for developers and other interested parties, and how might this affect adoption and use of such technology?
     1. LOI/LRI use of AOE data that is not relevant to lab testing would perpetuate data sharing using inappropriate data flows.  AOEs are meant to support lab testing, not as pass throughs that are better served by, e.g.,  eCR reporting.  Would require some guidance updates to LOI and LRI to reduce use of pass-through AOEs.
     2. Where labs do serve as the walk-in with effectively an “EHR” to support that, it would be reasonable that they support eCR for such additional data they capture directly as well. Requires that eCR and Lab triggers ensure that every reportable lab always yields an eCR.  Ulrike Merrick checking if that is the case.  Are we saying that everything that must be reported as part of Electronic Laboratory Reporting (ELR) is also reported as part of eCR and vice versa?  What is meant by walk-in as the above use of walk-in seems different from this use of walk-in?  
     3. Currently system certification provides a higher level of assurance of consistency
        1. ideally both systems in a data exchange should be certified, but if that is not possible, or feasible at least the source system should be certified, which means considering expanding certification to LIS and IVDs.  Laboratories already get certified by CLIA and CAP and I do not think another certification is needed.  
     4. Might want to separate certification of semantic from syntax to support certification of systems using older syntax, but still could send better semantic quality data
     5. Differentiate between providing certification requirements and tooling for it from enforcing / incentivizing users to actually do this.
     6. Focus on certification of options = profiles rather than full guides. LOI/LRI support that.
  4. Would developers of laboratory information systems or in vitro diagnostics systems that have not traditionally submitted products for certification under the Program seek out and benefit from certification to criteria relevant to such developers’ products?
     • LISs have not traditionally subject to certification, is there value having consistency across LISs? 
       • Laboratories are Certified by CLIA and CAP including the order and results reporting processes, etc. content and process, but there is difference of opinion whether the ONC focused certification on interoperability transactions is necessary/beneficial to LIS as it is for EHR, while others suggest that consistency of a common certification process for the various HIT in the same workflow would be helpful and if only done for one is not really helpful.
       • Y/N LIS (should this include LIMs, PoC testing, Apps, middleware within lab)
       • Y/N IVD Systems
     • The original source of the lab result 
       • V2 resulting should be done consistently
       • e.g., vocabulary, profiles, etc.
     • What are the incentives?
       • Labs need support/resources for interoperable systems
       • HL7 v2.5.1 should be the foundation across laboratories
         • EHRs didn't upgrade which meant that labs couldn't
         • Due to the large installed base Laboratories Results being sent to EHRs, requiring upgrade to HL7 2.5.1 would be cost and time prohibitive.
       • More than certification needs to happen to improve adoption
       • Should LOI/LRI be required for certification? LRI was in Stage 2 but dropped in Stage 3 - i.e., why did it not get adopted.
       • Providers only required to enter orders into their systems for compliance, while EHRs were not certified to send orders to Laboratories (although many supported that, just not against a common version such as LOI), since ONC did not adopt LOI and LRI in the 2015 Edition Final Rule.
  5. Are there any other steps that ONC and HHS should consider taking to advance laboratory interoperability?
     1. SHIELD Semantic work
     2. LIVD mapping