On February 15, 2016 I’m testifying to the NCVHS Subcommittee on Standards on behalf of LOINC. This hearing is the latest in a long line of discussion about the attachment standards. In fact, LOINC’s role in the claims attachments standards was cooking before I came to Regenstrief. Fortunately, use of LOINC in this context has never really been controversial.

NCVHS asked panelists to provide comments on many questions. Here are the highlights from my point of view.

Paperclip

photo via chrisdlugosz

A brief history of a long journey

LOINC’s use as a proposed attachment standard has a long history. All of the earliest drafts of the HL7 attachment specifcations (circa 1999) through today have used and recommended LOINC codes for specifying the clinical content being requested and returned. The claims attachment notice of proposed rulemaking (NPRM) published on September 23, 2005 proposed the adoption of LOINC for these purposes. NCVHS held hearings in November 2011 where there was support for the HL7 CDA (with LOINC inside) approach, as summarized in the March 2012 letter from NCVHS. In February 2013, NCVHS held a second hearing on attachments where I also gave testimony. The summary recommendations from that hearing recommended LOINC as the attachment type code set.

Currently proposed standards

In the June 2013 letter, NCVHS recommended the following standards:

Message Content/Format

  • HL7 Implementation Guide for CDA Release 2: IHE Health Story Consolidation, DSTU Release 1.1 (US Realm) Draft Standard for Trial Use, July 2012
  • HL7 Attachment Specification: Supplement to Consolidated CDA Templated Guide, Release 1, May, 2013

Attachment Type Value Set

  • Logical Observation Identifier Names and Codes (LOINC) developed and maintained by the Regenstrief Institute, Inc., LOINC® c/o Center for Biomedical Informatics.

Routing/Envelope

  • X12 275 Additional Information to Support Health Care Claim
  • X12 275 Additional Information to Support Health Care Service Review

Request for Attachments

  • X12 277 Health Care Claim Request for Additional Information (for all claim-related attachment requests)
  • X12 278 Health Care Service Review – Request (for non-claim-related attachment requests)

Acknowledgment

  • X12 TA1 and 999

Development of the proposed standards

LOINC was created at Regenstrief in 1994. LOINC’s purpose is to provide universal codes and names that serve as the global lingua franca for identifying tests and observations. To promote widespread adoption, LOINC is distributed at no cost worldwide under a user-friendly license.

With 42,000+ users from 172 countries, it has become ubiquitous in healthcare. LOINC is an official national standard in about 30 countries, including the U.S. where it has been adopted in many federal efforts, including the meaningful use program. There are tens of millions of patients around the world today with billions of discrete electronic health data elements coded with LOINC.

Regenstrief curates LOINC, but it’s development is spurred by large global community. New LOINC terms are added by the requests of end users. In the last four years, we have processed submissions from more than 195 different organizations from 19 countries. The current version of LOINC contains 78,959 terms. We are currently adding about 1,800 new terms in each twice yearly release (June and December).

Regenstrief works collaboratively on standards development with many other SDOs, including the IHTSDO, RSNA, IEEE, and HL7. I specifically want to highlight our close, long-standing collaboration with HL7. It was by design that LOINC codes fit perfectly as the vocabulary standard for observation identifiers in HL7 messages and FHIR resources, and as document type codes in HL7 CDA documents.

Thus, in our view, the proposed use of HL7 standards and LOINC as the standard code set in claims attachments is a natural and logical approach.

Relationship to standards in other programs (i.e. Meaningful Use)

The 2015 Edition meaningful use criterion require C-CDA Release 2.1 (which specifies using LOINC codes for identifying document types). The 2014 Edition adopted C-CDA Release 1.1.

Many other federal programs use CDA-based implementation guides with document level LOINC codes. A few examples include: CMS for exchange of electronic clinical quality measure data, CDC’s National Healthcare Safety Network for Healthcare Associated Infection Reporting, and CDC for Public Health Case Reports.

Support for other transactions

LOINC codes can be used in any healthcare transaction or exchange that needs a universal code to identify a test, measurement, observation, or collection thereof (including documents, panels, forms, data sets, etc.). LOINC already has a robust set of codes (including many kinds of clinical documents) and an open submissions policy for adding new content where needed.

Support for the intended business function/use

The current proposal recommends C-CDA release 1.1 and the HL7 Attachment Specification Supplement Release 1, May, 2013. Since those recommendations in 2013, HL7 has published two updates to C-CDA (release 2.0 and release 2.1) and an update to the Attachment Supplement is forthcoming.

I ultimately believe that C-CDA Release 2.0 is a better long-term standard than C-CDA Release 2.1. Why?

C-CDA Release 1.1 had some serious problems with its use of standard vocabularies. It used unconventional entry templates approaches with SNOMED CT observable codes when all of the other national initiatives (HITSC, CMS quality measures, Federal Health Architecture, etc.) adopted LOINC codes. So, providers were using LOINC for calculating quality measures, but for sending that result in C-CDA they had to convert it to something else.

It was a mistake that never should have happened.

Many of these issues were corrected in C-CDA 2.0. Yet, the “lack of backwards compatibility” (i.e. correcting the error) between 2.0 and 1.1 led to the creation of C-CDA 2.1, where the approach was have implementers send both codes for places where Release 2.0 had a LOINC code and Release 1.1 inadvertently had a SNOMED CT code.

The approach in C-CDA 2.1 is a little kludgy and in some cases non-trivial. For some templates, implementers have to do the mapping between LOINC and SNOMED themselves because the templates were not specific enough to allow a 1:1 correspondence. It seems that this approach would be even more problematic and challenging than just making a one time switch to the more widely adopted (and consistent with federal advisory guidance) codes from LOINC.

But, alas, the ONC has adopted C-CDA Release 2.1 in the 2015 Edition meaningful use criterion. At the level of the Document type codes, which is the main focus of the attachment standards, these code system problems do not exist. (All the document type codes come from LOINC).

Therefore, despite some reservation, I think that use of the C-CDA Release 2.1 standard for attachments is probably still the best course because it leverages the same underlying clinical document standards required in meaningful use. However, it is not as straightforward a path to success as it could have been.

The HL7 Attachments Supplement IG is also being updated to reference C-CDA Release 2.1.

With these updates (C-CDA Release 2.1 and the Attachments Supplement), the proposed standards do support the intended business function/use. The standards provide the ability to send both structured and unstructured clinical data. They also have the flexibility to evolve to accommodate new attachment types. Over time new LOINC codes and flagged as “unstructured” when approved, which allows them to be used in exchange without changing anything about the syntax/structure.

Potential impact to various health care entities

Overall, the impact of the proposed standards and code sets will have the effect of massively improving the efficiencies of claims processing. It will eliminate the manual, labor-intensive and paper-centric processing that is the norm today. To the extent that attachments are sent as structured data, it will enable more automated processing.

There is, of course, an up-front cost to the downstream efficiencies.

Payers

Payers will have to build the technical infrastructure to support this exchange. For many, the C-CDA and LOINC standards will be new. (Although we know many payers are familiar with LOINC for aggregating lab data, the document level codes are likely unfamiliar). Receiving structured, standardized electronic data will facilitate automatically adjudicating the claim because payers will have the data necessary in a computer-understandable format. Automatic adjudication will greatly reduce the administrative overhead necessary to process their transactions (i.e. claims, prior authorizations, etc).

Providers

The vendors of provider EHR systems may have to integrate with practice management system functions in order to package the clinical payload with the X12 message.

Providers will rejoice at opportunity for a more efficient solution than the manual, paper driven process that exists today. If these data can be gathered and submitted electronically, senders will no longer have to retrieve and copy records and prepare paper (sometimes many pages of paper) attachments for the receiver. By adopting standards used in other contexts (e.g. CDA and LOINC), providers will be able to leverage to the infrastructure investments they’ve already made. Greater automation means greater predictability. They will be better equipped to provide the information supporting a healthcare transaction. Automated adjudication will also improve turnaround time.

Strategies to measure the impact of adopting standards

Regenstrief has not developed a strategy for measuring the impact of adopting LOINC in this context, but are open to working collaboratively with others on this. We know that ONC is interested in partnering with SDOs in this regard, as reflected in the cooperative agreement announced in 2015. These topics have been discussed among members of the SCO as well. Given the funding model for LOINC, Regenstrief would need additional resources to pursue such an effort.

Suggested implementation plan

We suggest that three years are allowed from the date of final rule is published until implementation is required. Within this timeframe, some time is needed to develop the software capabilities, and additional time needed for actual implementation. This might work out to be something like Year 1 for product development (vendors) to support the transactions. Implementation will also require analysis and redesign of business workflows. Starting to implement the exchange with the attachment standards could begin in Year 2. Once implemented, these standards could meet industry needs for 7-10 years, dependent on several factors.

Why should NCVHS recommend the adoption of the standards and code sets?

NCVHS should recommend standards and code sets for attachments because it is the right thing to do. The X12+C-CDA+Attachment Supplement+LOINC combination is the best solution available. There is evidence from early adopters that it can have real benefits. Adopting a uniform set of standards across the industry will have a significant impact on the efficiency of processing attachments. Limiting the initial implementation to health care claims attachments for which the C-CDA has defined a template (e.g., hospital discharge summary, operative notes) is a reasonable, incremental path that builds on the existing infrastructure being created to support a truly learning healthcare system.