How Will Engaged Patients Get Their Comprehensive Health Information?

As I’ve blogged previously, I believe in the right of patients to access their data. Exercising a right is one thing: deriving benefit is another. The data needs to be usable for the patient or their caregiver/designee. Google Health’s demise, or the fact that patients very rarely ask for an electronic copy of discharge instructions or clinical summary (Stage 1 MU) doesn’t prove that patients don’t want their data: it’s not an “either/or” choice between having convenient functionality vs. having access to the data (see my thoughts here). I’ve made analogies (with caveats) to online banking before. But besides health data being more voluminous and complex than banking data, people usually don’t interact with nearly as many banks as healthcare providers. I as a generally healthy person have visited eight healthcare providers in the last two years, and 12 providers in the last five years. A person with more chronic illnesses would have more providers and far more visits. Will the increasing penetration of EHRs help us as patients? Specifically, how will I get my comprehensive personal health information when it’s scattered in so many different places, electronic or not? Connecting to each one individually doesn’t seem to be the answer.

Here are some ways that might possibly happen (with italicized comments indicating my opinion of feasibility and likelihood):

1. Private or public health information exchanges that connect all my providers (or at least a critical mass), aggregate and perhaps normalize my data, and which have a patient portal with view/download capability for patients.
   A few of these exist, so it may be possible for patients to get somewhat comprehensive information if they stay in the same region or provider network for a while and all those providers share data with the HIE
2. All providers’ EHRs pushing their data to my PHR. This could work with HealthVault, though I don’t know how many other PHRs currently support Direct protocols. The patient can receives separate standardized structured documents (e.g., CCD), but then has the option to merge and reconcile data from those documents into their PHR data fields.
   Unlikely in the near future, though technically possible to the extent that Direct Project becomes adopted and required in Stage 2 MU.
3. All providers’ EHRs making their subset of my data available to me to download, which I then upload into my PHR.
   This is theoretically possible if Stage 2 Meaningful Use continues as proposed by the HIT Policy Committee, but it’s a lot of work for the patient: adds the download + upload steps to the “merge and reconcile” step of #2.
4. Patient Centered Medical Home that aggregates data from multiple providers. Possible in pockets with PCMHs and strong HIE capability
5. All providers having all my data (due to comprehensive information exchange plus EHRs consuming and storing everyone else’s data) so that no matter which one I accessed, I’d have all my personal health info.
   Highly unlikely in the near future, since most EHRs can’t consume and store most of the data. Some EHRs can import some external data, such as medication history.
6. Virtual on-the-fly health record assembled from all sources (similar to the recommendations in the PCAST report).
   Highly unlikely in the near future.

I think #1 and #2 are the most feasible today, though the percent of patients who will actually benefit from them is still low. I’d be interested in your thoughts on what is most likely to gain traction and whether there are other possibilities that are feasible today that I missed.

ONC Care TransITions Convocation – What Happened?

I blogged about the meeting that was to be held on October 14^th. Now that it has occurred, with approximately 160 persons attending in person and 300 via webcast, here are first impressions. Some slides from the meeting are posted, with the main conclusions on 13-17 and 24-26.  

KEY POINTS FROM THE MEETING

• ONC's purpose in convening this meeting. Farzad Mostashari (ONC) and Todd Park (HHS CTO) said ONC's role was to "unite the tribes" and "let others help” solve a major problem in today’s health care system.
• Transition between hospitals and post-hospital (PCP, Long-Term Care, Home) was the focus. The consensus was that the current state of affairs is unacceptable. Much of the time there is zero transfer of information from hospital to other providers, particularly public health clinics.
• Plan of Care. Based on findings from four parallel workgroups, there was much mindshare in support of a shared Plan of Care (PoC). "Shared" doesn’t mean just "exchanged" as in passed along from one provider to another. They meant a collaborative mutually-developed Plan of Care that has input from multiple providers (care team) as well as the patient and his caregivers. This comes with challenges of governance and access control, though I didn’t hear those issues discussed.
• Are transitions of care more like a "relay race" (hand off the baton linearly) or like a "football game" which is much more interactive all along the way? Some felt that the best we could expect was to improve the handoffs in a relay (vs. dropping the baton by not exchanging at all), whereas others wanted to move more toward a collaborative care model like a football team. Harmonious collaboration requires much clearer definition of roles and responsibilities across many organizations.
• Some said that the care plan should be approved by the patient, and co-developed, like two people redlining a contract together, rather than thrown over the wall.
• CDA Consolidation Standard. Doug Fridsma and Jitin Asnaani affirmed ONC's support for the new "single standard" CDA Consolidation. This builds upon but also simplifies the standards that many have worked hard to support, and is convergence rather than divergence. I favor this direction, though the standard is still being balloted, and it will take work to migrate to it.
• Dr. Holly Miller of MedAllies gave a good example of the clinical need for standards and information exchange which could not only help care transitions, but change the course of the patient's health. She used the example of repeat visits to the ER involving patient falls treated in isolation, vs. the alternative where the PCP is notified, detects a pattern and underlying cause, and intervenes to prevent future falling incidents.
• Jitin said that 10 HIT/HIE vendors (not named) have committed thus far to the ONC ToC pilots. He said one or two of them would test Consolidated CDA in conjunction with Direct Project. (My editorial comment: Consolidated CDA in its entirety (over 50 sections) is unlikely to be tested in the pilots, but a constrained subset that still needs to be clearly defined should be tested).
• Jitin also announced the coordination of the S&I Framework, Beacon Communities, EHR/HIE Interoperability Workgroup (the multi-state effort led by New York), and the State HIE Programs. The EHR/HIE workgroup is outside of ONC, but is cooperating with them.
• While the focus of much of the discussion was on needs rather than how to do it technically, there was a strong agreement on the need for tight, specific standards.
• Timeliness and Relevance of Information. The theme of "the right information, when I need it, where I need it" was emphasized often. Not just for providers but for patients. Dr. Scott Young of Kaiser Permanente said that typical Discharge Instructions are not given/explained at the right time and place (which should be where the patient spends most of their time, e.g., at home). Similarly, patient education is often deferred until the end of the hospitalization and are generic, whereas it can and should be started while the patient is in the hospital. Several said that PCP and other providers needed to be notified at the time of admission not just at discharge, because they need to be aware of the situation and given the opportunity to contribute to the care process.
• Taking Follow-Up Actions. Others said that Patients should not just be told to do things like make appointments: the hospital should actually make them (or help the patient make them) while the patient is still there. Similarly, don't just tell the patient to get prescriptions filled or buy medical equipment: send them home with them! The highest risk to a patient occurs within the 1st 72 hours after discharge, when the patient is most vulnerable physically but also is distracted by other things needing social support (childcare, finances, cleaning the house, taking care of the yard, etc.).
• Medication Reconciliation. One suggested that the reconciliation process should start with what the patient is actually taking, and then build from there, rather than other people's lists that the patient is asked to verify (because they will tend to say "yes" when asked "Are you taking ____X?" even if they really aren't taking it.
• Feedback loops were often emphasized. While not defined precisely, I gather that it means feedback to the care team and caregiver about how well the care plan is working, whether desired outcomes/goals are being achieved.
• Disintermediation. Dr. Bo-Linn, a physician who has practiced for 50 years, said that there must be "disintermediation" because the system can't afford to be so hierarchical and provider-dependent, but that patients must be able to do more for themselves to remove cost from the system. He pointed to examples like ATMs (no tellers), pumping and paying for gas. Making travel reservations is another example.
• Spread of existing technology rather than new technology. While new technology was encouraged, most felt that the technology exists to do nearly everything that was discussed, and that successes exist in pockets, but are exceptional and seldom replicated. So one of the challenges is disseminating successes and scaling out the solutions that already exist.
• Getting the Word Out. Health Affairs, one of the leading health policy journals, wants to chronicle innovation as its happening, and encourages submissions. ONC is now funding Health 2.0, an innovative group highly focused on patient engagement. It has sponsored an innovation competition, "Ensuring Safe Transitions from Hospital to Home" which ends on November 16th.

So it was a thought-provoking day that I’m glad I attended. While its intent was to stimulate urgency and innovation, rather than to define standards or regulations, I think it was a preview of priorities that HHS will be focusing on in the future. Speaking of Care Transitions, I’m at the ONC S&I Face-to-Face right now. I plan to blog about the S&I Framework projects that I’m involved in.

Putting the IT in Care TransITions

On Friday, October 14^th, I look forward to attending a meeting in Washington DC called Putting the ‘IT’ in Care Transitions. That will be followed closely by the ONC S&I Framework Face-to-Face meeting in DC on October 18-19, which will also feature a track on Transitions of Care. Meanwhile, Meaningful Use Stage 2 standards definition marches on, as I wrote in my last blog. Many initiatives are converging (I hope).

The October 14^th meeting will consider three specific patient scenarios: an elderly isolated widow with many chronic conditions; a young child with serious asthma and exacerbating home environment; a homeless man with diabetes and schizophrenia. The premise is: “if the system is designed to assist the most complex patients, then the system will function effectively for all.” I agree with the premise as far as capabilities (more complex scenarios often require more robust capabilities), but I don’t think it’s always true from an adoption and usability perspective. How often have you and I felt that a process or a gadget or a computer UI was “over-engineered” because it was designed for a complex but rare scenario, but was cumbersome for the most common scenarios?

The October 14^th meeting also has a premise that “even the most advanced provider and community organizations acknowledge that new innovation is needed to improve the efficiency and effectiveness of delivering transitional care interventions to large numbers of patients, particularly in an environment in which technology adoption is rapidly growing and the state of technology is changing.” Right on, and so I suggest that these are some key areas for “much new innovation:”

1. Innovative and Usable Presentation of a "just right" level of information to clinicians that avoids the extremes of "information overload fatigue" vs. overly aggressive filtering of information, especially when much information exchange occurs. Can HIT be smart enough to anticipate what a clinician needs? Or must HIT be passive and "do no harm" by leaving all decisions up to the clinician?
2. Policies and guidelines for which electronic information a clinician must read, vs. what they do not need to read. While this is often viewed as a bigger problem for HIE/"Pull" models, it’s a concern even for "push" exchanges, especially if a sender sends information to one provider and copies many others on the "care team." 
3. Reconciliation principles for many types of data, not just medications. E.g., lists of problems/diagnoses, allergies, procedures, and immunizations. The risks vs. rewards of merging, aggregation, deduplication, normalizing across multiple information sources whose vocabularies are not fully standardized. Should HIT strive for “a single source of truth” or just accept that “here is what other sources have said?”
4. Who or what makes a care team? The term is used a lot, but is it clear what makes one? Just knowing who other providers are, and even having access to their records, doesn’t necessarily create a team or a care plan. My hometown football team, the Philadelphia Eagles, has so much talent that some dubbed them a “Dream Team” and surely they know each other’s names and roles, but they aren’t an effective team at the moment. And to play off the meeting title, how will putting the T (Technology) into Team result in better patient Care?

I look forward to blogging about the outcome of these next two meetings.

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.

Would You Like to be Engaged to Multiple EHRs?

There’s strong agreement that for meaningful use of Healthcare IT, patients and families need to be “engaged.” The question is, how? In Stage One, patients are to be given an electronic or paper copy of clinical summary information from office visits and hospitalizations, as well as discharge instructions from hospitals. This is good and a step beyond mere paper. But that raises the question of how this information can be used by the patient, other than viewed as if it were paper. What’s the “Quicken” equivalent of a “killer app” for patients to manage their health? (Oops, maybe “killer” app is not so good for healthcare…). The Stage 2 Meaningful Use Request for Comment proposes that patients be able to view and download their information from a “web based portal” that is a module of an EHR (considering that the incentive program is about “certified EHR technology”).

The best tool for any given patient depends on the individual, so speaking in statistical terms may gloss over some things. But let’s suppose that all EHRs were to offer such a portal. How many of them would a patient need to access? For myself last year, that would have been five (four EP and one hospital). According to an article by Peter Bach of Memorial Sloan Kettering Cancer Center, the typical Medicare patient sees seven doctors in four practices in one year, and those with multiple chronic conditions saw 11 docs in seven practices in one year. If you then throw in a hospital, that means eight healthcare organizations possibly with eight EHRs for one patient in a year. If you’re a family member caring for your children or aging relatives, multiply all that. You might have to interact with more than 20 web portal accounts, ending up with over 40 separate downloaded files (you’d probably need more than one per organization per year). Even if they’re in a standardized format, who or what will reconcile or pull them together? Will you be the one, using copy & paste with a spreadsheet or word processor? I don’t think so… If you use a web-based tool specifically designed to deal with those files, well then you’re probably using a Personal Health Record (PHR).

The problem with the current MU proposal for downloading from individual EHRs is that it implicitly endorses a “tethered PHR” model – a PHR extension of an EHR. But that PHR is not really patient-centric, because it contains the patient’s data from the organization using the EHR. Over time, the data will broaden as EHRs import and reconcile data from other sources such as EHRs or Healthcare Information Exchanges, but most EHRs aren’t there yet. And “tethered” is only one of several approaches to patient-centric health records. Other flavors include independent personally-controlled PHRs such as Microsoft’s and Google’s; health record banks; payer-based PHRs such as Blue Cross; employer-based PHRs such as Walmart’s using Dossia. They all have their strengths and weaknesses, but the personally controlled PHR has recently made some significant headway, associated in part with the Direct Project announcement re Dr. Paolo Andre’s EHR and Beth Israel’s Direct Push to Healthvault. If independent PHRs can be updated through a standard transport protocol (Direct secure SMTP), that securely pushes standardized content (e.g., CCD or CCR) into the PHR in a way that is structured and codified, as already required in Stage 1 MU, then the potential for a comprehensive, patient-centered record (not tied to any one provider) has increased. Now this isn’t magic – the patient or family member still needs to decide which data from the CCD are relevant and should be added to their master problem list, medication list, etc., as I’ve done with my own PHR. An ecosystem of innovative products (trackers, monitors) can then flourish around the PHR, given the influx of more robust data to operate on.

In preparing comments to the HIT Policy Committee’s Meaningful Use workgroup, I’ve recommended that MU should focus on the goal: getting the information to the patient or caregiver’s hands in a way that they can use, not on inadvertently favoring an EHR-centric “tethered PHR” flavor. Let the EHRs do the behind the scenes work of transmitting the patient’s info into PHRs of the patient’s choice (which might be any of the flavors I mentioned), enabling patients to interact productively with a tool they like, rather than making them “polygamously engaged” to multiple EHRs/portals and encumbered with lots of files to manually import into PHRs. For patients who don’t want to use a PHR, they can still get their electronic copies (as in MU Stage 1). But for those who want the opportunity to have their electronic information together in one place, there’s a great opportunity for MU, defined in a way that allows flexibility and innovation, to leverage the Direct Project and the existing and emerging clinical content standards like harmonized (I like that word) CDA Consolidation Project templates building upon CCD/C32.  

So, patient and family engagement: yes! Let this relationship between patients and HIT be productive, patient-centered, simple-to-use and... engaging, please!

“Quickening” the Flow of Health Information – Part Two

Sometimes you just have to be quick. And I wasn’t, so Part Two is later than I planned. Here are some more analogies between Quicken (which I use for my “Electronic Financial Record”) and an Electronic Health Record inasmuch as both require information exchange. Of course, “money” and a relatively small data set are exchanged in financial transactions, rather than the vast array of health information. So with that caveat, here I go.

• Making payments is analogous to Direct Project “push” messages. I enter payments that are pushed to payees in a format that they can accept (some electronic, some paper checks). I can enter these payees’ addresses or have Quicken look some up in a directory. My interaction is simple, but Quicken and the financial network (like a healthcare HISP) securely route the transaction behind the scenes.
• Quicken updates my register pulling relevant data from my bank. To me, the bank is analogous to a Healthcare Information Exchange in that it received and aggregated transactions from many payees, so I don’t have to connect to all the payees. I can download from the bank as needed. Of course, the bank has security and privacy protections for my data, similar to how health data must be protected.
• Balancing my register, which occurs automatically, is comparable to data reconciliation in an EHR (though it is much much simpler for money than for health data!)
• I can set up automatic actions such as reminders and payments, which is analogous to workflow automation features in healthcare, where events (like signing a letter or discharging a patient) can trigger data to be transmitted to others.
• Quicken interfaces to tax preparation software such as Turbo Tax, which then files taxes with the IRS and state. This is analogous to healthcare transmissions to public health and quality reporting agencies.

The bottom line is that I use Quicken because it saves time and money and helps me do things that would be hard to do on my own. Just avoiding the late fee on one credit card bill pays for the software investment. I’ll surmise that healthcare providers would insist on those kinds of benefits and more. If a provider can have an EHR that can do more than just the electronic equivalent of FAX -- like quickly match and autofile incoming messages to the right patient, help reconcile the data, notify the user that new information is available, provide clinical decision support, improve efficiency  – that EHR would ultimately pay for itself with or without incentives. All of us who work on EHRs need to keep that in mind: if my professional livelihood depended on using this EHR, would I use it? Personal Health Records (PHRs) are an even closer analogy to Quicken, and I believe that they too need interoperability and Quicken-like value to deliver on their potential (rather than being something that most consumers don’t have time for).

Interestingly, Dr. Clem McDonald (an HIT pioneer) recently  wrote a similar analogy, that ideally healthcare data import ought to be as easy as importing bank statements to Quicken, in his commentary Clinical Decision Support and Rich Clinical Repositories in the Archives of Internal Medicine (sorry, the link used to be public but now requires membership).

To wrap up… securely pushing information, as simply as e-mail, is good progress. Liquidity of information, whether health or financial, enables value to be realized when software acts upon it. Financial software has progressed far beyond just moving information. Healthcare isn’t nearly as far, but it’s advancing and more options are becoming available. Not all EHRs are right for everyone, but I believe that they’re on the road to being as if they were “healthcare Quickens.”

"Quickening" the Flow of Health Information -- Part 1

Yesterday was a big day for The Direct Project, which I’ve been pleased to be able to participate in. Kudos to those who have started demonstrating successful “pushing” of communication of clinical information across providers! As pointed out by many speakers, it’s great to see collaboration for the common good among many organizations that are competitors in the marketplace. There’s a quickening momentum as the trickle of information exchange grows to become a flood.

As ONC's Dr. Blumenthal aptly said, The Direct Project is “a lane in the information highway.” What he didn’t say was “but it’s not the cars, passengers, or cargo being transported down the highway.” That’s an important distinction that not everyone may realize, since the pilots really showcase much work that is outside the scope of Direct, such as “integrating patient data across provider settings and during transitions of care” as one pilot announcement said. Direct was used to transmit the data, but didn’t integrate it, because it’s the highway, not the cars or the place that the car is going to. It’s secure transport, not data content nor use of the content.

One beauty of Direct is that it is unbiased, neutral, toward the content it is transporting. It uses established standards to securely deliver any content to the right place so that only the intended recipient can read it (it’s an honest mailman who doesn’t read your mail). But the content had to exist in electronic form before Direct can encrypt and send it. The data could have come from EHR, or a scanner, or a person typing an e-mail message, but someone or something created it first, and someone else (not Direct itself) does something useful with it on the receiving end.

To the extent that something wonderful is done with the data that’s being sent securely through Direct, that’s done by innovative and usable applications of one sort or another, and while Direct didn’t make those applications, it sends them something to work with. Applications analogous to Quicken. Why do I say that? Well, I’ve often heard the healthcare industry unfavorably compared to other industries like banking, where everyone lauds the benefits of their interoperability through ATMs and the ability of banks to download data into personal financial software like Intuit's Quicken (which I’ve used for years). I'm sometimes skeptical of such comparisons because health data is so different than money. Nevertheless, there are some very useful parallels.

If my connection to the bank securely delivered images of paper bank statements as PDF files, and images of checks, it would have some value by saving postage, trees, drawer space, and a little time. But no one would be satisfied with only those benefits today. My account data is not just delivered as images of checks or my old monthly paper statements; it’s delivered in a discrete “consumable” form that I can use to write checks, transfer money, set up automatic payments, manage a budget, analyze my expenses, search, import into tax software – all while my ledger is automatically kept up to date and saves me from having to do the dreaded “reconcile the checkbook” chore that I thankfully abandoned long ago. The semantic standards are pretty basic compared to healthcare – we agree on dollars and cents and dates and times, not so much on the payees (I realize I’m oversimplifying).

So my message to end today’s post, which I’ll follow up with part 2 in another day or so, is that the flow of health information is quickening, and I’m happy that the Direct Project is playing an important role in doing that. But it’s health IT's Quicken counterpart at the other end that makes it really useful. I believe that to get the most value out of secure health transport, we need to increasingly send content that is human-readable but also appropriately structured and consumable at the receiving end. Deciding what that content should be is work for other projects ahead. Whatever it turns out to be, the Direct Project will help push it quickly where it needs to go.

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.