Patient-Centeredness: will "Direct-only" get us there?

I read that the HIT Standards Committee recommended that Direct (SMTP, S/MIME secure email) be the only transport protocol for certification. While on the one hand this sounds like a good step toward parsimony (similar to having only one vocabulary for problems or one Consolidated CDA standard for summary of care records), I think it’s different and has some unintended consequences against the patient-centered view that can be advanced with HIEs.

Those of us who worked on Direct recognized its strength for particular “push” use cases. Many also felt strongly that Direct needed a bridge to the HIE world in terms of protocols (hence the XDR and XDM for Direct Messaging specification). The Direct Project Overview made it very clear that Direct “push” is not intended to solve every use case but to coexist with other forms of exchange including “pull” as well explained in this EHRA whitepaper.

This is easy to understand if we look at how businesses are run, and how people manage their personal data. Email push is highly beneficial and essential in my business and personal life. But it’s not all there is. At work, when people collaborate on projects (as providers ought to  collaborate in patient care), they store information in shared resources. They don’t rely upon the project documents existing in every individual’s email or personal folders! That would lead to waste and confusion. Instead, there are repositories that handle version-controlled documents, source code, etc. Wiki pages rather than emails can be used to record the shared project experience. Emails are great for initial notification, but not for the ongoing management of the information. And even individuals don’t email their photos to everyone in their address book: they share them in a single place (like Facebook) from which trusted friends can pull (view and download) them. Information exchange  via Direct should not “push out of the picture” information sharing that benefits the patient and provider community.

HIT SC’s recommendation of a single protocol for certification is fine as a “minimum requirement.” But I’m very concerned that certifying only Direct, if accepted by ONC, could bias providers toward Direct to the detriment of other types of exchange. CMS’ Incentive Program proposes that meaningful use measures only count transmissions to providers using the standards included in certification (page 13708 of the NPRM). This would have the unintended consequence of discouraging sharing through HIEs (at any level), that use IHE profiles such as XDS, XDR, XCA, etc., as most use these instead of Direct. Those profiles require sufficient metadata to support queries against a patient-centered document registry, so that providers can find what they’re looking for. Direct by itself does not provide or require those metadata, so even if Direct were used to push documents to an HIE, the HIE would be hard pressed to correctly index and file the documents.

I’m not criticizing Direct for what it is. I am saying that it was not designed to handle all exchanges, and that overemphasizing it as the only “meaningful use” method that “counts” will have negative impacts on HIEs that provide a patient-centered aggregate view. Point-to-point transmissions don’t provide such a view since each provider’s view from “push alone” is only a “silo” unless everyone copies everyone else on every document (the dreaded “reply to all” email) – not a good idea! While HIEs aren’t required for MU, they should not be discriminated against either. CMS regulations incenting Direct only (implicitly disincenting HIE) could harm progress toward patient-centricity. That would be like a business rewarding people for sending their documents via email but not rewarding them for sharing controlled versions of those documents in a repository. Between ONC and CMS, I hope this problem can be avoided by focusing on the real objective – providers and patients sharing data electronically, without CMS measures counting only Direct SMTP exchanges as qualifying for meaningful use. “Pull” exchanges from an HIE or “push” exchanges using other protocols (e.g., XDR SOAP) should also count toward MU measures. And I hope that HHS goes beyond “permitting” HIEs for MU, but that they will continue to invest in and work with others (e.g., states) on a national healthcare infrastructure (NwHIN Exchange as it evolves) to enable a patient-centered, cross-provider view of data as a public good.

Unfinished HIT Business

Happy New Year! Typically it’s a time for reflection and looking ahead. But since Keith Boone already blogged about the Top 10 HIT Standards efforts of 2011 and John Halamka predicted the Top 16 HIT Standards Committee Topics for 2012, where does that leave me? I’ll try blending 2011 and 2012, since many things started in 2011 but haven’t yet come to conclusion.

In the hilarious comedy Throw Momma from the Train, Billy Crystal plays a writer who is so obsessed with his ex-wife, that he has serious writer’s block and can’t get past the first sentence of his new novel (“The night was humid…”). He eventually gets his writing groove back (“A writer writes, always”), and doesn’t leave unfinished business. Sometimes I feel like I can’t get a blog started either, so I’m going to just start writing and close out the year!

Here are 11 items of HIT standards unfinished business that I hope reach some closure in ‘12.

1. Meaningful Use Stage 2. More than a hope, it’s a safe bet that this will reach closure in 2012. I predict that items #3, 5, 6, and #8 below will be partially resolved by MU2, but most won’t because they’re complex and/or outside the scope of MU2.
2. Sustainability of federal standards initiatives. HITSP was the previous ONC’s sanctioned standards harmonization effort, but it is gone. Some wheels were reinvented. Now the ONC S&I Framework is here, but an election year and budget cuts loom. What are the chances for national continuity of direction beyond 2012?
3. Sensible certification rules. The HIT SC’s Implementation Workgroup made recommendations based on testimony from the difficult Stage 1 experiences. What practical improvements will be made to certification? 
4. CDA. Just when we thought there was convergence on Consolidated CDA and achievement of a critical mass of CDA-capable products (driven largely by Stage 1 certification), significant CDA changes are being discussed: Detailed Clinical Models (CIMI) and Green CDA standards. What is the path forward that achieves simplification and yet doesn’t send everyone back to the drawing board?
5. Transitions of care. ONC put a lot of effort into the ToC initiative, and some fine clinical recommendations were issued, but they haven’t been fully connected to the Consolidated CDA work yet. How will the MU standards be adjusted so that they truly help clinicians in care coordination?
6. Vocabularies. What appear to be strong recommendations for singular standard vocabularies were made, but seemingly watered down by statements that they are “for quality measures only.” Will converged vocabularies be a reality for interoperability as well as quality measures?
7. Patient-sourced information. Let’s face it, much data in EHRs comes straight from the patient already, yet patient-sourced information seems to be controversial. What HIT standards, will enable patient information (from devices, interviews, messages, PHRs) to have their proper place?
8. Lab reporting and ordering. I hope that the ONC Laboratory Reporting Initiative has achieved widespread consensus.  Will these standards finally result in standardized interfaces in the real world, vs. just on paper?
9. Holistic view of exchange patterns. ONC has focused heavily on the specifications that it commissioned. But will ONC recognize the role of community-based HIEs using standards such as IHE XDS, and not leave a “hole in the middle” by considering only Direct and cross-community NwHIN Exchange?
10. Certificate and/or Provider Directory. Much effort has been poured into supporting only the Direct Project. Will the limited use case of certificate discovery given a Direct address be enough to push Direct into mainstream use? Will there be robust universal certificate directories and provider directories?
11. Query Health. This is not likely to be in MU2, and with so many other priorities, there may not be many organizations geared up to be query responders. What critical mass of industry adoption is necessary in order for population health queries to be statistically significant?

Certification Retrospective Part 3 – Controversies Along the Way

Note: this blog post continues my discussion of experiences in CCHIT. The opinions are mine only and do not necessarily reflect the views of CCHIT or Siemens. Please bear this in mind especially considering that the topic is “Controversies”

From my last Certification Retrospective post, I promised to share lessons learned and some “agonizing controversies” we faced in the CCHIT Interoperability workgroup (IOWG). I thought I could do both in one post, but now realize that I’ll need a “Fourth Movement” after this. Each controversy could easily take up a post of its own, but I’ll try to squeeze them into this post, deferring Lessons Learned to Part 4.

1. When should HITSP specs be incorporated into certification? Once HITSP was formed, it (not CCHIT) was designated to select standards. CCHIT, however, could decide when/if those standards would be certified, striking a difficult balance between supporting the federal strategy (HITSP was HHS-funded, CCHIT was partially HHS-funded) and yet being pragmatic. It would have been difficult to require EHRs to develop too much at once when certification was “all or nothing” and not modular. From working in both CCHIT and HITSP, CCHIT tended to give more weight to considerations such as market adoption and lead times, not just whether a suitable standard existed. I along with Jamie Ferguson were appointed to co -chair the 10-member HITSP-CCHIT joint working group, whose goal was to coordinate the work of HITSP and CCHIT and address how/when to include HITSP specs in certification. But some HITSP-selected standards were still in “trial implementation” with little adoption, and the approval of a standard (HL7, HITSP, or any other) didn’t mean it should be mandatory within a specific timeframe. And there were just so many of them to digest, let alone certify! Some people weren’t pleased, thinking that CCHIT should be a more aggressive “enforcement arm” of HITSP. In the end, we included more of HITSP in 2008 and 2009 certification criteria than ONC did in its 2011 certification criteria, most notably the HL7 2.5.1 Laboratory results with LOINC vocabulary starting in 2007, C32 CCD starting in 2008 (adding RxNorm, UNII, SNOMED CT vocabularies in 2009) and HITSP TP13 (IHE XDS.b – see point #2 below). But we also roadmapped (2-3 years out) most other HITSP specs when we published our 2009 criteria. I believe this was a sensible middle of the road approach. IMHO, if we had mandated many more HITSP specs in certification, there would be few or zero certified products today!
2. Should certification require transport standards? Fourth & Ten – we’d better punt! Seriously, we debated this during 2008 and 2009. We recognized this as a glaring gap in interoperability, and wanted to make headway, realizing that lack of secure transport standards would hinder interoperability even if content were standardized. The Direct Project didn’t exist back then. We were aware of diverse ways that HL7 messages were transported, that IHE had defined SOAP-based web services for document transport, and that HITSP had selected many IHE specifications. Many vendors had already tested IHE Cross-Enterprise Document Sharing (XDS.b) at Connectathon. So the IOWG approved XDS.b as 2009 certification criteria (along with PIX/PDQ to support it). But the Board of Commissioners decided to designate these as optional interoperability criteria, not required for certification, because despite the IOWG’s recommendation and strong EHRA support, some commented against it. This was the one case I can recall where my workgroup’s recommendation was overridden by the Board, which I know was a tough decision since the Board usually didn’t do that. This was also a case where we were less aggressive in CCHIT than the EHR Association had proposed. EHRA had sometimes criticized CCHIT for not providing enough lead time, but in this case they were very disappointed that CCHIT had not required this in certification. This one still bothers me as a missed opportunity.
3. Should we require discrete data import, and who owns that decision anyway? We felt that the main point of requiring standardized content formats and vocabularies, not just human readability/liquidity, was for the discrete data to be consumable. Following our “methodical march” mentioned in part 2, we thought in 2008 that the time had come to propose discrete data import (e.g., update your medication, allergy, or problem lists using data from other providers). But now we were into a “boundary condition.” Where did interoperability’s “turf” end and functionality begin? We had a series of “discrete data import” meetings between the IOWG and the Ambulatory and Inpatient Functionality workgroups. We recognized that data must not only be exchanged, it needs to be reconciled (medication reconciliation being an example), and that you can’t just “slam in” all meds, allergies, problems from many external sources to automatically update the active med/allergy/problem list. The functionality workgroups didn’t think the time was right to require such capability in certification for 2009 or 2010. But how were we going to keep making progress toward semantic interoperability? In the end, we proposed criteria to import very specific discrete data elements for medications, allergies, demographics, and immunizations (with problems to come later), as described in my last post. But we didn’t define the functionality, as long as the discrete data were stored somewhere. And in any case, reconciliation criteria would belong to the functionality workgroups, not the IOWG. I think this would have been a reasonable “baby step” but because of the change in certification that started in 2009, those roadmap criteria never had the chance to be certified. I hope that similar careful thought will go into decisions in ONC certification, whenever it gets to that point. End-to-end interoperability involves content creation, secure standardized transport, and content consumption, all of which should be considered holistically.
4. Should we push the industry toward a single standard for clinical problems? This was really part of the broader topic of converging on a singular standard vocabulary for each type of data, but SNOMED CT for problems was the lightning rod topic for several reasons: a) the difficulties of getting physicians to create medical problem lists at all; b) ICD-9 diagnosis codes were already required for reimbursement and some physicians systems were built around ICD-9; c) ICD-10 was already complicating things by looming on the horizon; d) anything that imposed more work on physicians could hinder usability and adoption. So though SNOMED CT seemed a clear winner for an interoperable clinical vocabulary and was HITSP-endorsed, we received considerable pushback from some members of the other workgroups as to how fast SNOMED CT could be required. I was pleased that many in the IOWG stepped up to provide statistics and research facts such as analysis of mapping of ICD-9 to SNOMED CT and clarification that standard codes don’t have to be visible in the clinician’s UI. We knew this was a contentious issue, but staked out our positions in the 2009 roadmap and a Q&A document.

The above four were prototypical of the controversies we faced in content, vocabulary, and transport. I could go on with more examples. That’s part of the challenge of interoperability work, as evidenced by the fact that ONC and the HIT Standards Committee still have all of the above issues to ponder for Stages 2 and beyond. I should mention that one more big controversy arose in the very first year, when CCHIT was newly formed and struggling to figure out how to set the interoperability bar. Eyes were upon those first members to resolve the CDA vs. CCR debate. Unlike the four issues above, where we took a stand, we weren’t ready to force a decision in 2006, and then HITSP was formed by ONC to deal with such “standards harmonization” issues. So at least our punt had a receiver (and football wasn’t locked out)!

I promise that Part 4 will really conclude this series with my thoughts on Lessons Learned, proudest accomplishments, regrets, and hopes for the future, stemming from my CCHIT experience. Thanks for listening to my sharing from “inside the trenches” of discussions of which the public was not aware.

An Aid to Survey the River of Clinical Information

Recently, I’ve had discussions with many people in the HIT industry about the future direction for Meaningful Use (MU), especially about exchanging clinical information. It’s clear that Stage 1 is only the start of a journey, and that increasingly robust sets of clinical information will need to be exchanged. However, such exchanges need to be helpful rather than burdensome, and much work needs to occur to figure out how to display what’s significant, accurate, reconciled, and usable for clinicians and patients (see my recent blog series Part 1, Part 2, Finale).

I’m sharing a spreadsheet (a work in progress) showing a library of standardized reusable data sections and comparing many types of electronic clinical documents/records, including the two most “famous” that are required in Meaningful Use Stage 1, CCD and CCR. This spreadsheet may eventually be published in a more final form from an organization, but even now it may be useful to you if you have any of these questions:

• What must be shared in Stage 1 as a clinical summary with providers and/or patients? (See spreadsheet columns B and D green cells)
• Are certification and MU clinical summaries the same? There are some interesting differences that can be found between the standards for certification and the language for meaningful use (See column A and the CMS FR – Clinical Summary tab).
• What’s the difference between a full C32 and what’s required in Stage 1 certification? Quite a bit, actually! (See column D, white check marks)
• What data are not included in CCR and CCD but might be desirable to share in the future? (See all rows and columns). Stage 1 requires only the most commonly requested clinical summary data (meds, allergies, problems, results, etc.).
• How much reusability exists among today’s electronic clinical documents? (See column Q, which also indicates which sections are most often used). There are worthy efforts afoot to improve commonality and reduce divergence, such as the ONC sponsored CDA Consolidation Project. 

Here’s my compulsory “liquid” or “music” analogy of the day. A mighty rushing river is growing, of clinical information and the standards thereof. I hope my high-level spreadsheet serves as an aid, a “Bridge Over Troubled Water” where you can safely survey the river before you plunge in. Although I created this spreadsheet, with plenty of review from Health Story and EHRA members, I’m far from being the authority on clinical documents. Robin Raiford did wonderful work on a similar spreadsheet in 2009, which was actually more detailed, but was limited to HITSP CDA documents and preceded the ONC Final Rules. I recommend that you read the original specs, and follow Keith Boone’s blog and his upcoming CDA book.

Finale: Drinking Safely and Healthily from Liquid Information

Happy New Year! If you must drink, do it responsibly and safely. Which brings us to the subject of this Finale to a blog series that started here. How can Health IT systems help clinicians to consume/drink the liquid information that will increasingly flow to them? How can these systems help users protect both patient safety and clinician productivity?

The faucet has been opened. It’s fairly easy to tell developers to send clinical information to others. It’s harder to know what to tell providers to do with what they receive. The trickle of information exchange hasn’t become a flood yet, but let’s be prepared! Clinicians want the information to be usable, not a hindrance. They want to do the right thing, but they can’t afford to reduce their capacity to see patients, and they don’t want to be liable for negligence if they can’t read every word of every available electronic record for the patient. Policies and guidelines for realistic expectations and duties of clinicians to retrieve and read electronic information would be very helpful coming from medical, legal, and health information management professional associations.

Patient safety is impacted both if there’s inadequate information flow but also if there’s too much. We’ve heard of “alert fatigue” in clinical systems, and could face “information overload fatigue” too, where important information is obscured by “noise” that could lead to errors or duplication as occur in the absence of information flow. While the PCAST report on health information technology proposes applying search technology (good idea), that may be helpful but insufficient. I can “Google” anything, but how often do you or I look beyond the first page of results, even when there are thousands of hits? I implicitly rely upon the search engine to display the most relevant links first, since my time is limited. While a patient’s medical records are much less voluminous than data in web searches, even dealing with only 24 clinical documents per my personal health example requires indicators of relevance to aid decision making. If I don’t look at Google search results page 2, it’s probably not a big deal, but the stakes are much higher for patient care: who can decide what’s most important to show for a clinical encounter, especially since that varies depending on the encounter’s purpose?

Thankfully, healthcare and academic organizations realize the need to tackle this challenge. I was fascinated by the findings from this medication reconciliation project at Partners Healthcare: “design of a novel application and the associated services that aggregate medication data from EMR and CPOE systems so that clinicians can efficiently generate an accurate pre-admission medication list.” It was pioneering work at the time, and was a springboard for further research, such as refined aggregation algorithms based on more standardized data, and clinician-vetted UI techniques to reduce cognitive burden and add value.

In 2008 when I helped interoperability and ambulatory workgroups (including physicians, nurses, pharmacists, engineers, and others) write the CCHIT certification criteria and roadmap through 2011, we proposed 2009 as a first step in consumption of discrete data such as medications and allergies from C32 CCDs, but concluded that we shouldn’t be prescriptive about EHR functionality or workflow to handle such data.

Medications are just one example of data that needs to be reconciled after being exchanged. A new clinical data Reconciliation project at IHE offers promise to advance the cause of clinical decision support for reconciling problems, allergies, medications, and more. It’s humbling to acknowledge that HIT isn’t so sophisticated or trusted to make clinical decisions, any more than web search can buy your next car automatically. Instead, we should share the results of research to inform and stimulate innovations that are then tested in multiple care settings, before even thinking about regulating and standardizing functionality. But I’m all for specifying how standardized information exchanges can be inputs to these innovative algorithms and UIs.

To return to my musical analogy, music isn’t just playing the notes in a score: but rather how the score is brought to life to touch the heart through the genius of great performers. We shouldn’t try to turn musicians into robots where every nuance is pre-programmed. Similarly, in HIT MUsic, there’s room for the art as well as the science!

If anyone reading this can point to interesting research and experiences regarding consuming health information that’s exchanged, I’d love to hear about them. The results would benefit providers and developers EHRs and HIEs as well.

Opening the "Information Liquidity" Faucet

This starts a mini-series blog, a “Symphony in Two or Three movements.” Movement 1 will discuss what is happening as the information starts to flow “liquidly” as it should, among providers and patients and public health in the healthcare system. Movement 2 will discuss what I think providers will need to avoid drowning when the liquid turns into a flood.

There are now government incentives to exchange information, due to the ARRA HITECH legislation as well as the emergence of accountable care organizations (ACOs). Some advocate high degrees of structured data and vocabularies from the outset. Others say that the most important thing is first to achieve “health information liquidity” – simply get the information to flow freely without much standardization of content – and later to evolve towards higher degrees of interoperability and structure. Right now as I type these words, ONC Chief Technology Officer Todd Park is espousing health data liquidity on ONC’s webcast! CMS will open the incentive money faucet, as providers open their EHRs’ faucets to exchange information.

Up till now, providers receive some health information through manual methods such as patients carrying their paper records or images on CD, or referring providers sending paper mail or FAX. But most of it isn’t in electronic format that they can use in their EHR. And most providers have little or no opportunity to “find” information on their patients if it’s not delivered to them. The bad news is that they’re missing a holistic view of the patient and may waste time searching or repeating questions or tests. The “good news” (not really good) is that they probably aren’t overwhelmed by, nor obligated to discover, all the patient’s previous records.

But now the faucet is opening and the “liquid” is starting to flow. In order for the data to be understood at both ends of an exchange, standards are needed. Many have already been defined and just need to be adopted. ONC has recognized standards in data format (e.g., CCD or CCR format for patient summaries, and HL7 2.5.1 lab result messages for public health) and clinical vocabularies. Partners Healthcare has done encouraging work testing the adequacy of standards (e.g., CCD, RxNorm) to communicate structured codified medication lists among different systems. ONC didn’t select standards for physical transport of the data, but has now recognized the need there, so they’re sponsoring the Direct Project for simple push of data among known recipients (e.g., referrals and discharges) using a secure e-mail protocol (SMTP with S/MIME). Its goal is to be simple, ubiquitous, and accepted as e-mail is today, and a step above current manual methods. But the Direct Project Overview explains how Direct doesn’t to handle every scenario, such as “pulling” data for an emergency visit. There are already standard specifications for patient lookup and record locator services (e.g., IHE PIX and XDS) when querying a Health Information Exchange registry and repository. The ONC-sponsored Nationwide Health Information Network Exchange and Connect projects also leverage IHE. While the Direct Project and IHE both use established standards, there’s still much room to grow in their adoption in the healthcare domain.

Let’s assume that over the next two years that Direct and IHE both thrive: then what will people do with the information that flows to them? As I speak with clinicians, very few care about the formats and transport protocols, but they want the right information at the right time to help them make better decisions to help their patients. They have to use, to consume (or “drink” to preserve the liquid analogy) what they receive. But as the saying goes, “be careful what you wish for.” Who wants to drink from a fire hose? What happens when the electronic information arriving at the clinician’s fingertips, or available through an HIE, is no longer a trickle but becomes a flood? Ah, rather than ending up with a “drinking problem” I prefer to see it as an opportunity for innovation.  More about that in Movement 2 of this blog post.