Every day I experience life in the world of healthcare IT, supporting 3000 doctors, 18000 faculty, and 3 million patients. In this blog I record my experiences with infrastructure, applications, policies, management, and governance as well as muse on such topics such as reducing our carbon footprint, standardizing data in healthcare, and living life to its fullest.

Tuesday, November 10, 2009

The Genius of the AND

Recently in Washington, an important political figure asked me why I had the reputation of resisting change.

Since I've spent my life catalyzing change and embracing the latest technology, I found this a very strange statement.

I have no idea how history will record my life and work, but I think the answer is - it depends who you ask.

Wes Rishel wrote a great blog today that reduces the debate about standards and interoperability into two points of view - “the healthcare informatics crowd" and "the Internet crowd".

I've spent the past 4 years facilitating standards harmonization in HITSP, bringing together 800 organizations to discuss the parsimonious number of standards needed to facilitate the data exchanges which will support meaningful use.

From the point of view of the healthcare informatics crowd, the harmonization of disparate approaches into CDA/CCD with XDS.b, XDR, XCA and XDM represents significant simplification and convergence of the major stakeholders in healthcare IT.

From the point of view of the Internet crowd, it represents a set of complex content and security constructs that puts the SDOs in the HTTP business.

The work I've done for the past 4 years aimed at unifying the industry on a web services approach, embracing web-centric standards such as SOAP, XML, and HTTPS. In 2006-2007, this was considered very forward looking. In 2009, RESTful data exchange of simple payloads with TLS and application level security is considered cutting edge.

Thus, my challenge as a leader is to bring together both the healthcare informatics crowd and the internet crowd, without having to take sides and choose either/or.

The answer to me is that we need to embrace both approaches - the right tool for the right job depending on what you want to achieve.

For provider to provider communication which requires the exchange of documents with non-repudiation as the medico-legal record for direct clinical care, the CDA/CCD has great metadata and the ability to support structured data as well as free text discharge summaries/operative notes/history&physicals.

For a summary record that represents a snapshot in time of problems, medications, and labs for transmission between EHRs and PHRs, the CCR and other formats such as Google's CCRg or PDF can do the job.

On the FACA blog today, Marc Overhage wrote about good enough standards for a particular purpose.

This blog posting is likely to generate debates from both the healthcare informatics crowd and the Internet crowd.

Certainly, I believe that a single standard with templates or subsets for a particular purpose would reduce costs and ease the vendor burden of having to support multiple standards, but the trick to accomplishing this is to ensure that the standard be simple enough to be easily implementable for "the little guy", the iPhone, and the use cases of EHR to PHR exchange where the goal is to provide basic summaries to patients. As I said in my blog last week, I'm convinced that the SDOs will continue to refine their content standards such as CDA and CCD to clean up the XML (get rid of moodCode) and provide templates to support a range of applications, both complex and simple (hide the OIDs so that most implementers do not need to deal with them).

Until then, we need a glide path that embraces the healthcare informatics crowd and the internet crowd, respecting the hard work and best thinking of both.

For provider to provider communication which requires the exchange of documents with non-repudiation as the medico-legal record for direct clinical care, we use the CDA/CCD.

For a summary record that represents a snapshot in time of problems, medications, and labs for transmission between EHRs and PHRs such as would be used by Microsoft, Google or Keas, the CCR or PDF is good enough.

We separate content and transport, recognizing that some organizations will use XDS.b and XDR for SOAP-based transport, while others will use RESTful approaches, enforcing privacy policy with security features at the application level.

As standards evolve we can revisit this with the aim of convergence as long as further parsimony does not impede innovation.

It is my hope, that by embracing the right tool for the right purpose, we can balance standardization, ease of implementation, and innovation.

The genius of the AND - I hope that both the healthcare informatics crowd and the Internet crowd can embrace this path forward.

9 comments:

I've been following your committee involvement and read your blog religiously. If your actions are leaving the perception of one that resists change than we truly are at the mercy of the "beholder". If anything, from my viewpoint, I felt that you were pushing the envelope beyond what most entities could hope to attain but that's your right to do so. If you disclose the name of this important political figure I'll remember not to vote for him/her.

Standards are necessary but not sufficient. I have often felt like "Horton Hears a Who" asking where is the "person/consumer/patient" in the data? How can we expect to get patient centered care if we don't start our design process around their needs - not simply giving them a snapshot after their care is over but active participation in the co-creation of their care? Data is a reflection of a live "conversation" that starts and ends between providers, patients, people, support systems and not just "data". (as an aside we don't really need more data but a system that transforms it into information and knowledge with the goal behavior change).

So few people in the national conversation have ever seen an EMR, let alone trained providers to use one and I irritate most of my health 2.0 friends when I ask them so are you using a PHR? (its a little like trying to use Quicken before your bank is online).

In accounting they have both balance sheets (snapshot), income statements and cash flow. But people aren't just numbers and hopefully in healthcare we will move towards a dynamic living co-created "shared care plan" vs an EMR/PHR model

This isnt' just theory. Group Health Co-op which has a robust health IT system for its 580,000 members also has the highest penetration in the use of its patient portal at over 50% that moves beyond the artificial bifurcation of an EMR/PHR.

We were told it was impossible to do but patents were given write access (via email) before their providers could, they get labs (both normal and abnormal within 24 hours) and information therapy that is targeted to their problem lists as well as an after-visit summary for each encounter. Halfo f all primary care encounters are now happening via email or telephone encounters. As of last month they can now also make (not just request) their own appts and the entire primary care system is moving to the medical home model and doctors are able to focus on people with chronic conditions.

It wasn't the technology (Epic) but a core commitment at the design stage to build the system around the patients needs. That combined with a business model (salary vs piecemeal) and workflow redesign is what was trans-formative.. (pay docs to answer email to see adoption increase)

So much of the intellectual bandwidth of the industry has been focused on the critically important issue of standards (the industry itself failed to resolve this over the past 20 years hence the need for outside encouragment) but we all need to remember that the goal is high quality, effective efficient patient centered care.

What are their needs? What does "meaningful use" look like to them? What "standards" will make their lives easier? Perhaps if we stop thinking of them as a recipient of the data and as the key stakeholder and payer of the entire system we would start with them (us) and build out from there.

Thanks for your blog. I appreciate your effort to be open and inclusive. Most of the time I agree with your main points, but respectfully differ with the conclusions you came to here.

Collins spoke of seemingly contradictory goals like quality and cost in healthcare, but I don’t think the argument translates well into standards selection. The "genius of the AND" sounds enticing at first, but much less so when re-expressed as "multiple standards for the same purpose." The most inclusive "AND" would be to let everyone do whatever they want, but that contradicts what HITSP has been doing to harmonize and seek "parsimony" of standards. The "AND" would allow CCR, CCD, and many customized and/or old versions of HL7 formats. Re: terminologies, “AND” would avoid migrating to SNOMED-CT, RxNorm, LOINC, etc. Yet you’ve spoken positively (and I agree) about the need for standard terminologies. Laxness in HIT standards got us to the current state: lack of interoperability, with much wasted time and cost for custom interfaces.

The "AND" approach seems at first easier for the data producers (it actually isn’t), but is harder for everybody downstream. This is primarily more expensive because there are many recipients for every producer of data. For the "AND" to work, producers must either produce BOTH formats and recipients must do extra work to import discrete data from BOTH formats (diverting attention other areas of need); or else rely on two-way mappings (which may not be accurate and are also extra work).

However, the “AND” principle fits with the concept of a “glide path.” I commend the HIT Standards Committee for providing glide paths to allow time to reach standards targets. In this context, producing a CCR can be a step toward producing a CCD or other structured CDA documents. But as a glide path, there should be no requirement on recipients of a CCR that they be able to do more than interpret the CCR as human readable text. Ideally, the use of CCR in a glide path should treat it using HITSP CAP120 to wrap the document in a CDA header so that at least the data identifying document and patient can be standardized.

I’m curious why you said that CCR (or PDF) are good enough for EHR-PHR exchange, while endorsing CCD for EHR-EHR. CCD was approved by HITSP/HHS nearly three years ago for "consumer empowerment" and "consumer access to clinical data" both of which are EHR-PHR exchanges. HITSP proceeded, to its credit, to select additional CDA-based documents (such as C48 Referral and Discharge Summaries and C84 History and Physical and Consultation Notes) that reuse HITSP CCD templates for EHR-EHR exchanges, recognizing that CCD lacked some data for those scenarios.

I appreciate the need to help the "little guys" but CCR/CCD is not a strong example to make the case. There are already open source tools available to assist with CDA. Instead, the sheer number of standards and specs to read would be more much likely (than CDA) to overwhelm a "little guy," so why not help them by focusing on fewer fronts and simplifying documentation?

John, thanks for your continuing efforts to keep things transparent and realistic. Your intent is good, but I believe that endorsing overlapping standards introduces unnecessary waste and is too reminiscent of the pre-HITSP status quo which meant minimal or costly interoperability.

I agree with David’s comments on John’s post. I was pleased that John came down strongly in favor of CCD for clinician-to-clinician exchange but puzzled and in disagreement with the proposition that CCR (or even PDF) is “good enough” for EHR to PHR exchange or why we need to settle for “good enough”. Although John’s focus on synthesis and meeting competing needs is almost always a very positive contribution, in this instance, I think it is not the way to go on this issue.

Certainly, from the vendor side, there will already be the capability to send CCDs given ARRA certification requirements. Moreover it is certainly possible to tailor CCD data output to the needs of a PHR where those needs are more limited than those of a clinician. Finally, the problems with vendors needing to support multiple clinical summary exchange standards are significant (see http://healthit.hhs.gov/blog/faca/index.php/2009/10/29/hit-standards-committee-pulling-forward-the-benefits-of-healthcare-it/comment-page-5/#comment-106.)

From the PHR standpoint, there should be no issue with the ability of major players to accept a CCD nor with the time to get ready on a reasonable glide-path, given that EHR to PHR data population is not slated as an ARRA meaningful use requirement until 2013. My understanding is that Microsoft HealthVault already will accept CCD along with CCR.

Moreover, the distinction between EHR data and PHR data may not be so clear-cut given the interest of some in having PHRs contribute to EHR content and play an important role in continuity of care. In addition, there has been recent discussion of making the NHIN more patient centric, so some traditional distinctions between EHR and PHR data may be fading in the context of health information exchange (http://chilmarkresearch.com/2009/10/01/nhin-the-new-health-internet). Those who truly see PHR data as a robust basis for clinical decision making may not be well served by a model of light data content and data exchange as John outlines in this post and an earlier one (http://geekdoctor.blogspot.com/2009/11/standards-lessons-from-web.html).

I am afraid the power of the AND turns into barriers for the consumer when the spheres where each standard is applicable have a large overlap. As a consumer and patient, I would be very concerned that my health data in my PHR does not contain the same richness than what is exchanged between my care providers and their EHRs. Just like I expect this content transparency, I expect continuity of exchange through a consistent set of standards for the middle layer (between transport and content that supports a variety of standardized exchange sequences). I want to have my health data flow through media interchange (XDM), where I can take the data where either to my PHR or to any provider EHR, simple point to point push (XDR) between these, shared among my PHR and among my community of providers (XDS), and even moving through the NHIN (XCA), if I chose to. It seems that it would reduce my empowerment as a consumer to have these boundaries pre-set by the standards.

I've been engaged in a number of blog posts and discussions with others recently about trust, including a physicians ability to trust information recieved by a patient. If providers need additional technology or different standards to access personal health record information, it creates an artificial boundary between that content and what providers share about a patient. If we want to live in an evironment where providers can trust patients (and vice versa), we need to not put such artificial barriers between them.

There is a well developed and published standard that is overlooked in the US arena. (But not in Europe)This simple standard (5 parts 6Mb zipped) is the CEN/ISO EN13606 EHRcom standard.It is a basis (part 1) implemented in software. And Archetypes and Templates produced by tools based on part 2.All the variability in healthcare can be expressed as archetypes/templates and implemented immediately.

Why is there a strong tendency in the USA not to look at CEN and ISO standards solutions?