e-CareManagement blog

Chronic Disease Management • Technology • Strategy • Issues and Trends

The Third Rail in HITECH Implementation: “Please Don’t Make Us All Speak Latin”

By Vince Kuraitis and Steven Waldren MD, MS.  Dr Waldren is Director of the Center for Health Information Technology at the American Academy of Family Practice (AAFP).

Two issues have rightfully surfaced front and center in the public’s understanding of HITECH Act implementation:

  • ” definition of “Meaningful Use” of EHRs, and
  • ” definition of “certification” process for EHRs

…and we applaud the progress of the workgroups and the HIT Policy Committee in addressing these issues constructively.

However…a THIRD issue lurks – “Data harmonization at the expense of data liquidity“, or put another way – “misplaced pursuit of one (and only one) language at the expense of practical communication.”

On August 20, the HIT Standards Committee approved recommendations to bring forward to the HIT Policy Committee meeting later this September. 

In this post, we will:

  1. Summarize aspects of the HIT Standards Committee’s recommendations that are problematic
  2. Develop an analogy to illustrate how the recommendations will limit innovation and increase barriers to communication.  Our analogy:

The Standards Committee recommendations are like mandating that everyone in the U.S. be required to speak Latin by 2013.

latin

Dr. Blumenthal has wisely anticipated that there could be a situation where in his role as national coordinator that he should not follow a Committee’s advice:

“This committee does provide advice to the national coordinator, but it does not make policy,” Blumenthal said, with a noticeable emphasis on “not.” [iHealth Beat; August 18, 2009]

Dr. Blumenthal, this is exactly the situation you have anticipated.

1) Summarizing the HIT Standards Committee’s Recommendations

On August 20th, the Clinical Operations Workgroup presented a set of standards for meaningful use. These standards cover clinical summary formats, clinical vocabularies, e-prescriptions, labs results, and public health reporting.

In essence, these recommendations promote a single language that is not used today. With the standards selected, that “language” gives advantage to healthcare enterprises that have the financial and technical resources to manage the complexity.

These recommendations are impractical to implement by small and medium sized medical practices, where 80% of the care is delivered today.

The recommendations do not embrace the set of technologies providing interoperability in the Internet/Web era, which would allow simpler, less expensive options for smaller practices.

In addition to the complexity, without simple transport standards and the variability allowed in 2011-2012, the recommendations will not promote wide-scale interoperability.

The standards are broken down into those for years 2011-2012, years 2013-2014, and year 2015.

  • For years 2011-2012, they allow many “alternatives” to the standards for 2013.  However, they require a “wrapper” around this content called CDA (HL7 Clinical Document Architecture).  Use of this wrapper currently is very sparse in the healthcare enterprise (i.e. large hospitals, integrated delivery networks) and its use in the ambulatory arena is almost non-existent.
  • The recommendations also pick NCPDP SCRIPT 10.x for e-prescribing, when the entire market is using NCPDP SCRIPT 8.1 today.
  • The recommendations use HL7 version 2.5.1 messaging, when only a very small fraction is using this version.  Most are using 2.3 or 2.4.
  • Another standard selected for lab results is the Unified Codes of Measure (UCUM). At a testimony in February 2009 at NCVHS, representatives from the clinical laboratory association stated no labs they were aware of were using UCUM

2) An Analogy – The HIT Standards Committee’s Recommendations are Akin to Mandating that Everyone in the U.S. Must Speak Latin by 2013

Standards for health IT have many parallels to “standards” around the use of everyday language.  We believe that the HIT Standards Committee recommendations are akin to legislating that everyone in the U.S. be required to speak Latin by 2013. 

Why?  Several reasons:

  1. While mandating one harmonized language seems intuitively appealing, logic suggests that more than one language is optimal.  Costs and benefits must be weighed. 
  2. Availability of cheap, easy translation limits the value (benefits) of one harmonized language
  3. Health IT is not one nation – different languages are spoken today in “institutional” vs. “ambulatory” HIT.  Harmonizing around institutional languages limits innovation and creates costs for people in ambulatory HIT.
  4. Standards are not created, they are adopted.  Mandating one harmonized language is misplaced when people don’t have incentives to communicate.

Let’s look at each of these separately.

1. While mandating one harmonized language seems intuitively appealing, logic suggests that more than one language is optimal.  Costs and benefits must be weighed.  Would requiring everyone in the world to speak the same language improve communication? No.

Examine the logical fallacy here.  First let’s define the extremes, then the middle ground.

It’s intuitively obvious that people speaking different languages creates communication problems.  At one extreme, if everybody in the world had his or her own unique language, then NOBODY could communicate.

At the other extreme, it’s intuitively appealing to think of everyone speaking one language — we’d all be able to communicate with no need for translation.

HOWEVER, this is where the failure in logic occurs.  Given that the one extreme of everybody speaking different languages doesn’t work, it doesn’t logically follow that the right answer is to have everybody speak ONE language.

There is no “right” number of languages. The optimal number is somewhere between the two extremes and is dependent on the costs and benefits that would be incurred in achieving language (or HIT) harmonization and standardization.

There’s a world of difference between striving toward a long-term goal of one standardized world language vs. requiring this to happen in a three year time frame.

2) Availability of cheap, easy translation limits the value (benefits) of one harmonized language. In the case of health IT, today we have many workable lightweight standards.

Why is it that when you travel to Germany, that many of the people you meet speak English?  We believe it is because of delivery methods that make it easy and cheap to transmit the English “language” across the Globe (e.g., CDs, DVD, e-books, and the Internet).

We think it is also because there is value to them to “translate” between English and German. Such value might be  understanding US movies and music or  learning technical content in e-books or on the Web.  There is also a financial benefit by being more vacation friendly to English speaking foreign travelers.

We need this easy transmission and market value to drive translation (interoperability).  Creating a basic network that does not place a high cost (complex standards, large number of requirements) to participate can go a long way toward interoperability.

Yes, we have multiple languages spoken today in HIT, but we have multiple inexpensive, functional, widespread tools to facilitate translation — HL7 CCD, ASTM CCR, fax, .pdf, even Microsoft Word ….  They’re not perfect, but they work.

3) Health IT is not one nation – different languages are spoken today in “institutional” vs. “ambulatory” HIT.  Harmonizing around institutional languages limits innovation and creates costs for people in ambulatory HIT.

We see at least two different HIT “nations”.

  • One is populated by large institutions that are comfortable speaking Latin (i.e. HL7 CDA, UCUM)
  • One populated by ambulatory tribes — small to medium size physician practices, clinics, patients with PHRs, and innovative early stage companies with limited health IT budgets – that prefer multiple less sophisticated, yet effective dialects.

Let’s consider one example: the differing use of summary care record standards in institutional and ambulatory settings.

The HL7 CCD standard is more likely to be used in institutional settings:

  • By organizations that have already adopted HL7 (e.g., large delivery systems)
  • To support existing business models
  • In non-disruptive applications that achieve costs savings and/or quality improvements by automating EXISTING processes that are INTERNAL TO THE ORGANIZATION (or with existing trading partners), e.g., hospitals sending test result information to doctors.
  • Where implementers have already incurred significant fixed costs to adopt HL7 as a broader enterprise standard

The ASTM CCR standard is more likely to be used in ambulatory settings:

  • By organizations that have not yet adopted any standard (e.g., early stage companies)
  • To support new business models
  • In disruptive applications that achieve costs savings and/or quality improvements by creating NEW PROCESSES, often involving parties that are not currently exchanging information, e.g., improving patient chronic care management with the goal of avoiding ER visits and hospitalizations.
  • Where the implementers are highly sensitive to incremental costs of IT resources and view the CCR as a “better, faster, cheaper” alternative.

Does it make sense to force all HIT nations to speak Latin – the language of large institutions? Doing so will limit innovation and place unnecessary costs on ambulatory HIT tribes.

Consider the costs that would have to be incurred to get everyone speaking Latin by 2013, e.g., throwing out existing books, rewriting books, the training and education that would need to take place.

How has Microsoft HealthVault handled the issue of different languages spoken in institutional and ambulatory HIT? Microsoft HealthVault accepts data transmitted in languages that are comfortable to BOTH nations – and it recognizes the need to provide translation between institutional and ambulatory nations.  That’s the right approach.

4) Standards are not created, they are adopted.  Mandating one harmonized language is misplaced when people don’t have incentives to communicate.

If two individuals do not wish to speak to each other, forcing them to speak Latin will not increase the communication between them.

The better approach is to provide incentives to enhance communication.

To-date, incentives to communicate are not significant and are not consistently deployed.  If barriers of high cost and complexity are erected — i.e. forcing Latin — it will have a chilling effect on our current progress on achieving data liquidity.

The U.S. is making progress on aligning the financial incentives in health care to reward communication (e.g. health information exchange).  The HIT Policy Committee’s recommended definitions of  “meaningful use” and “certification” are great examples of creating incentives and lowering barriers toward achieving enhanced communication among healthcare stakeholders. 

To the Office of the National Coordinator of Health IT: “Please don’t make us all speak Latin.”  Reject the recommendations of the Standards Committee at your upcoming meeting on September 18.  Ask them to try again.

Harmonization of languages (standards) should not come at the cost of limiting data liquidity, practical communication, and innovation.

Thanks to Dr. Don Storey for his review and very helpful comments on a draft of this essay.

Tags: , , , , , , , , , , , , , ,
 

Discussion

What do you think? Leave a comment. Alternatively, write a post on your own weblog; this blog accepts trackbacks. Your "first time" comment will not appear until approved by the moderator. Comments are closed after a post is 90 days old.

Subscribe without commenting

Comments

1.
On January 18th, 2010 at 12:52 am, Heather Leslie said:

Many thanks for this thoughtful post. I absolutely agree that we need to share data in different ways and for different purposes, and technology should facilitate this, not make it harder or more complicated.

It is interesting that the Booze reference on issues around data liquidity assume that the EHR is an application, and that data is something separate. In view of my involvement with openEHR (the basis for the ISO 13606 standard for EHR extracts) I take a slightly different view – that the EHR is actually the health data itself, not an application. This enables us to view the problems slightly differently.

One of the main reason why there is so much chaos at the moment is that we all use different ways of defining the same clinical content, so trying to align all of these is very difficult, maybe near impossible. We are turning ourselves inside out trying to devise sustainable ways of connecting ‘apples with pears’, not only now, but as a vehicle to take us into the future.

However if we adopt an approach in which we mandate a consistency of data definitions then exchange of data becomes simpler by orders of magnitude. These standardised content definitions become a foundation for eHealth, a logical record architecture. It is an approach that is gathering momentum in Europe. In openEHR these content specifications are known as archetypes. Archetyped data can be aggregated and combined to build and generate the documents, messages and shared applications that we need, whether CCR, CCD, software applications, integrated research databases, clinical decision support systems etc – a lingua franca of healthIT. The data will stand a better chance of becoming ‘liquid’ and ‘flowing’ if we have a very tight understanding of what each piece of data means and use it consistently.

The concept of archetypes or archetype-like standardised definitions seems to be largely missing in the eHealth discussion emanating from the US at present. Trying to achieve a single common language at the messaging or document level without common data definitions/specifications is fraught with problems as you so rightly point out in your post.

Mentions on other sites...

  1. HealthIT Policy on September 15th, 2009 at 6:25 pm
  2. Vince Kuraitis on October 1st, 2009 at 9:53 am
  3. HealthIT Policy on October 1st, 2009 at 6:58 pm
  4. govwiki on October 1st, 2009 at 7:00 pm
  5. Gov 2.0 on October 1st, 2009 at 7:00 pm
  6. Nahum Gershon on October 1st, 2009 at 7:57 pm
  7. Vince Kuraitis on November 11th, 2009 at 4:56 pm
  8. Vince Kuraitis on January 15th, 2010 at 11:46 am
  9. Alan C. Viars on January 17th, 2010 at 6:56 pm
  10. HealthIT Policy on January 17th, 2010 at 11:10 pm
  11. Vince Kuraitis on February 18th, 2010 at 2:18 pm