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.

Meaningful Use and Consolidated CDA

I invite anyone who is interested in commenting on the ONC Stage 2 Standards and Certification Rule, and/or the HL7 Consolidated CDA standard, to visit this page within the ONC S&I Framework.

http://wiki.siframework.org/ToC+MU+Analysis

As you know Meaningful Use 2 has specified Consolidated CDA and the data to be exchanged with providers (upon transitions of care) and with patients (view, download, and transmit; clinical summaries after visits). But the mapping of the MU2 data to consolidated CDA has been fuzzy, so the work on that page is an attempt to clarify and help "harmonize" ONC's rule with the standard it references. I have a spreadsheet posted that explains this, and Keith Boone does too (and Keith has written extensively about this on his Healthcare IT Standards blog).

The time is short, as comments to ONC are due by early May. We are conducting this analysis via an open process facilitated by ONC S&I, in cooperation with HL7 Structured Documents workgroup.

David

Meaningful Use Seeking Standards!

Update: 10 minutes after I posted below, the ONC NPRM was issued!
================================================

Hello! I, like many of you, are in the midst of reviewing the Medicare and Medicaid Programs; EHR Incentive Program - Stage 2 Proposed Rule (NPRM) on Meaningful Use Stage 2 (MU2), which was published late yesterday afternoon but was probably not seen by most people until today. The reason I titled this post as I did was because MU2 needs to be “married” to the Standards, but we’re all limited by the fact that the ONC NPRM on Standards and Certification Criteria was not published on the same day as the CMS NPRM. We’re still waiting... So for MU 2, we don’t have the actual standards in our hands yet, which we need in order to understand the criteria and assess their effects on providers, vendors, and others. Since I’ve been following the HIT Standards Committee for months, and there were sneak previews given at HIMSS, I know about many standards that ONC supposedly included such as Consolidated CDA, NwHIN Direct, and SNOMED-CT. But I’d sure like to see the details ASAP.

From CMS’ NPRM, many data elements in the “summary of care record,” “clinical summaries,” and “view and download” overlap but aren’t quite the same. As worded they don’t exactly match terms used in standards. Hopefully someone in ONC did the mapping to translate from the HIT Policy Committee’s and CMS’s phrases into the right “data buckets” in Consolidated CDA, for example. If not, I’m available to help through efforts like ONC’s S&I Framework Transitions of Care workgroups.

Margalit Gur-Arie wrote a helpful MU2 summary that helps distinguish what’s the same, what’s slightly new, what’s really new, etc.

As an interoperability champion, I see that ONC really means it when it talks about a big push for interoperability in MU2. MU2 has no more of those “check the box” tests without real exchange that characterized much of MU1! But stage 1 still has a few more years of life in it, for at least some providers, even if it is just a stage setter, Farzad Mostashari spoke of the “massive river flowing” of advances HIT, and I’ll be glad when real information exchanges flow abundantly among providers and patients, as I wrote about in some of my very first blogs.

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?

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.

Do Patients Need and Want Data, or Convenience Features?

So it seems that most patients were not “engaged” to, and certainly not “married on” independent PHRs such as Google. Many people including myself have learned more from failures than successes. Sometimes it helps to learn not just from my own failures but from the failures of others. So while the recent announcement of Google Health demise was no surprise, it offers an opportunity to learn. What do patients want? What do they need? Are needs and wants the same?

Mr HISTalk wrote about what Google Health should have done, and asked what actual users (not only HIT pundits) think. Missy Krasner, a founder of Google Health, echoes some of the same observations about people wanting convenience functionality, not a medical archive. She also asks the same question (“to tether or not to tether”) and comments on PHRs not being “social enough” – see my posts about Being Engaged to Multiple EHRs and Social Healthcare and Social HIT).

So, answering Mr. HISTalk’s call, here’s my experience. I was/am a user of both Google Health and Microsoft HealthVault, hoping that one or both would get over the hump of updating my record with providers’ data so I wouldn’t have to enter it myself. Technically, both of them were partially over that hump since they could import medications from my Pharmacy Benefits Manager (Medco), and Lab Results from my main lab provider (Quest), except that I had to get a physician authorization for the labs (why this barrier?), which was an example of the authentication hassle that Missy mentioned. Microsoft was more proactive than Google in allowing HealthVault PHR updated with discrete data extracted from a clinical summary (e.g., CCD) sent by an EHR via SMTP (email) protocol, which I’ve done successfully. While Google was nominally a member of Direct Project, Microsoft was much more involved and visible. Will HealthVault actually be updated by many EHRs, and even so will it still meet Google’s fate? I won’t speculate on that, except to say that Microsoft made it farther over the hump than Google did.

You Don’t Want Only Data, but You DO Need Data!

Nearly everyone intones that a PHR is not useful if it’s just a passive data “filing cabinet.” They say Google Health just didn’t “DO” enough to capture the minds and time of patients, although both HealthVault and Google Health had “ecosystems” of applications that would work with them. A few years ago, I thought “patient engagement” largely meant PHR (including their ecosystems) + patient portals. But I now realize that patient engagement goes way beyond PHR – I’ve got a large and growing list of what it encompasses. Still, just because functionality and convenience are what “sell,” that does not mean that data is unimportant! A physician or hospital won’t want to buy an EHR just for a raw database if the EHR lacks functionality and usability. But an EHR without a solid data foundation probably won’t be very functional or usable either!

Not all patient engagement is data-dependent. For example, I could schedule an appointment without having any of my electronic health information. In my next blog post, I’ll discuss which patient engagement functions clearly need EHR data, which ones don’t, and which ones are in a gray area.

Happy Independence Day!

"Social Healthcare" and "Social HIT"

I considered a title of “Socialized Healthcare” as a play on words, just to get some attention. But I’m not talking about socialized medicine and government takeover of healthcare (I won’t touch politics with a 10 foot pole in this blog). Rather, I’m thinking about the implications of social networking and interactive communities. This is a big theme of the Health 2.0 community, of which I’ve attended an innovative and fascinating conference. “Patient engagement” – a key priority in the incentives for Meaningful Use (MU) – isn’t just about patients accessing their electronic health records, but also about interaction among a community of patients, caregivers, care providers, and others. People already “socialize” (talk about) their health quite a lot already, in some cases using IT (e.g., the Internet)!

A little-known fact about the Direct Project is that there was a “bake-off” among four exchange protocols: SMTP (e-mail transport***) chosen by consensus as the primary protocol, SOAP (web services as used by IHE) chosen as an option to bridge to many existing EHRs, REST (web services based on Internet HTTP protocol), and XMPP (the protocol used in Facebook). While XMPP wasn’t chosen, its consideration was intriguing. The state of existing technology adoption in healthcare IT, and the fitness to purpose were factors in reaching the decision, but there was recognition that new technologies could play a significant role in the future. So as healthcare itself becomes more interactive and collaborative, new enabling technologies will become more applicable.

***Caveat – I realize that Direct Project is not just “plain old e-mail” like most people are using, but e-mail is the easiest analogy to explain the Direct push pattern of information exchange.

The key question isn’t about protocols, but how persons and systems interact with each other. Generally speaking:

1. System-system interactions are called interoperability
2. Person-system interactions are called user interface
3. Person-person interactions (facilitated by IT) are sometimes called social networking

The first two have received much attention in discussions about MU. The last has not. Even though there are proposed Stage 2 or 3 Meaningful Use requirements such as uploading patient-sourced data, that’s one-way, not really interactive. Secure patient-provider messaging may be the closest MU requirement in the Person-person category.

While e-mail-style of interaction can appear semi-interactive (i.e., long threads), it’s less interactive than chat/instant messaging or Facebook. It matches those use cases that drove it (e.g., pushing referrals, discharge summaries, results, and immunization updates among known recipients). Facebook, in contrast, has push, pull, and publish/subscribe patterns all rolled together. I haven’t seen many use cases that imply more interactivity (though a few were mentioned in the XMPP link above), so I’d be interested if anyone could point out some.

I haven’t researched or pondered this subject enough to write in depth about it it yet, but foresee huge and possibly transformative potential there. My company’s CEO, John Glaser, said as much at the HIMSS HIT X.0 mini-conference. I look forward to learning more about the opportunities (use cases), technologies, and innovations in “Social Healthcare.”

Certification Retrospective Part 4 – Lessons Learned

Note: this blog post concludes my discussion of experiences in CCHIT. The opinions are mine, and do not necessarily reflect the views of CCHIT or Siemens.

In life in general, and in development of software, standards, and certification criteria, we learn and grow more by trial and error than we do when everything goes smoothly. Frederic Brooks’ classic software engineering book The Mythical Man-Month said “Plan to throw one away; you will anyhow.“ Hence we need prototyping and iterative refinement. The CDA Consolidation Project is fresh on my mind. I voted negative in its HL7 ballot, but that doesn’t mean it won’t succeed, only that it has issues to fix. It would have been a miracle to get that complex task right the first time.

So it is with certification. The CCHIT Interoperability Workgroup (IOWG) experienced growing pains in its early years. 2006 produced only a roadmap, 2007 produced the first (modest) interoperability criteria. 2008 had stronger criteria and roadmap, and 2009 was poised to make big strides toward semantic interoperability. What were my main lessons learned through these years?

What We Got Right (IMHO):

• The “methodical march” sequence of building blocks. Putting the horse before the cart sure helps! As described in Method to our Madness?, we proposed a logical sequence for interoperability:

1. Data Capture
2. Liquidity
3. Standardized Content
4. Data Consumption

Our views crystallized especially in 2008-2009. CCHIT’s criteria included many of the standards that were eventually endorsed by ONC. For example, Lab Results, CCD, e-prescribing, vocabularies (LOINC, RxNorm, SNOMED CT), and leveraging HITSP.

• The Roadmap (“Glide Path”) Concept. I love maps (online, GPS, paper) and want to know ahead of time where I’m going and the milestones along the way. CCHIT published roadmaps for the next two years beyond each certification year. Roadmaps aimed to provide adequate lead time and to encourage developers to plan and head in the right direction. While the HIT Standards Committee did a great job proposing a “Glide Path” to more robust standards in their proposals in late 2009 (see Jamie Ferguson’s August 20th 2009 Clinical Operations Workgroup presentation), that concept was mostly lost when the ONC regulations were published (see comments on John Halamka’s Feb. 10, 2010 blog). For interoperability, developers need to know the target standards, more than a high-level meaningful use matrix, to move forward.
• Staying a Course. Once we defined the roadmap, we might adjust timing and provide more detailed criteria in our next development cycle, but overall there was continuity and stability with a minimum of “surprises.”
• Transparency. CCHIT posted responses to every public comment on its website. Of course not everyone would agree, but we thought everyone deserved to know their comments were considered and our rationale for decisions.
• Teamwork. The IOWG built relationships and trust among multiple stakeholders within CCHIT, as mentioned in Part 1. That enabled us to work through differences and get things done, despite conflicting opinions. In contrast, it’s harder to capture the “team” element in groups where 50-100 people are nominally on a project but attendance is sporadic, yet I understand the need for openness and transparency. Ultimately, a small group forms a cohesive team within the larger group. For example, the Documentation and Testing workgroup within the Direct Project gradually developed a “team” spirit similar to what the IOWG had.

Regrets:

• Lack of Opportunity to Finish What We Started. Last week I used football, now here’s my first baseball analogy. CCHIT, as the “starting pitcher” for EHR certification was relieved by ONC in the 6^th inning – enough to get a quality start, but not enough to win the game. Our methodical march didn’t reach its goal, but I hope that ONC will be a good “closer” to save the win for interoperable EHRs, coordination of care, and the good of the patient.
• Lack of End-to-End Coverage. Interoperability involves senders, receivers/requesters, and perhaps intermediaries. To succeed, it must encompass all participants (e.g., EHRs, HIEs, PHRs, labs, pharmacies, public agencies), because so much exchange goes beyond EHRs. We didn’t achieve this in CCHIT, but not for lack of trying! We envisioned covering some end-to-end interoperability through certification programs for HIEs and PHRs in addition to EHRs. Excellent people were in the HIE and PHR workgroups, and the IOWG had good dialogues with both. The HIE program was launched with poor uptake followed by suspension in light of impending ONC program changes. The PHR program was not launched.
• All-or-Nothing Approach. CCHIT pondered a modular certification approach early on, especially for inpatient EHRs, but didn’t implement it until ONC mandated it in the Certification Final Rule. In hindsight, I wish we had done that sooner. I don’t think we needed an “all or nothing” approach. Truth in labeling would have disclosed each product’s gaps, to help people make informed decisions. Vendors with complete EHR functionality could still differentiate themselves as a “one-stop shop” but others (“little guys”) would not be excluded from certification just because they didn’t provide 100% of all capabilities.
• A year in limbo. From mid-2009 through mid-2010, the industry was paralyzed by uncertainty and lost momentum on interoperability. It was clear that CCHIT criteria wouldn’t be adopted as is by ONC, but no one knew what would replace them. There was no assurance of staying a course or a clear glide path, and people who had done their best to follow the CCHIT roadmap were concerned and confused. Interoperability features (such as standardized coding and discrete data consumption) that the IOWG expected to be in products in 2010 have been delayed, possibly to MU Stages 2 or 3.

Whether right or regret, there are lessons learned that can be applied going forward.

• Follow the methodical march – a logical sequence of capture, liquidity, standardization, and consumption.
• Define a roadmap (glide path) with ample lead time.
• Stay the course.
• Take an end-to-end perspective.
• Be transparent.
• Be flexible, not “all or nothing.”

That’s it! This has been a long blog series, and if you made it to the end, thanks!

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.

Andante: What Happens When the Trickle Becomes a Flood?

This is the second part of a “Symphony in Three Movements” blog. The second movement of a symphony is often the slow movement: Andante literally means “a moderately slow tempo (a walking pace).” The first movement (information liquidity) is Allegro (fast, lively) because there’s a national momentum around Meaningful Use (MU). But using/consuming/”drinking” the information has moved slowly for reasons that I’ll discuss now.

All of us have experienced information overload (too much paper mail, e-mail, so many web sites and so little time). Many messages compete for our attention and go unread. So when we advocate health information liquidity, and it comes, we need to be careful what we wish for!

As a patient, father and grandfather, I want clinicians to be helped, not burdened, by availability of my family’s information. So I’d like to know: what do they consider helpful? To starting think through this question, let’s consider a real world scenario rather than abstractions: myself as a patient (I consent to this disclosure of my health information).

Over the past year, as a relatively healthy person who took four sick days from work, I had the following medical encounters:

• one ER visit followed by an additional day of hospital care for a “transient global amnesia” attack, which hopefully won’t recur
• Two PCP visits: one routine annual physical, plus one following up the hospitalization
• One Neurologist office visit following up the hospitalization
• Two dermatology visits with minor procedures performed
• One GI visit, related to a procedure performed in 2008
• I also had dental and chiropractic visits

That’s 7 medical visits. The hospital has an EHR, and my PCP is starting to use one, but I don’t know about the others. Let’s hypothesize that they all are meaningful users of EHRs. Then they would have produced at least 16 electronic clinical documents: 7 clinical summaries and one discharge summary for the next provider, 7 electronic copies of health information and one discharge instructions document for me. I’m not counting other MU information exchanges such as e-prescriptions, immunization registry updates (one flu shot), nor reportable labs or surveillance. Here I’ll just focus on the clinical documents, realizing that much more information can also be exchanged (results for lab, EEG, EKG, CT, Echo; consult notes, etc.). If 2011 and 2012 are like 2010, then by 2013 I’d have 24 or more electronic clinical documents available to other providers. People with serious or chronic illnesses could have far more. So what should my providers in 2013 look at? All 24 documents? How would they decide what’s important and relevant? Most of these documents will be partly duplicative but may not list exactly the same problems, procedures, allergies, etc. To what extent does this additional information (and the effort to digest it) save time or work elsewhere? As far as I know, these aren’t simple questions with simple answers, but I’d be interested in your thoughts.

At a minimum in 2013 I’d expect the hospital to send (push) electronically a discharge summary and/or a CCD to my PCP and the Neurologist, who will then read them. The Direct Project has received a lot of attention because it has clear applicability to common scenarios like discharges, referrals, and consults. But that’s a drop in the bucket compared to all patient’s electronic health information, so there remains a big challenge about what to do with the rest of it.

As reported in the recent PCAST report, p.15, lack of liquidity and interoperability produces this problem: “In effect, the patient has fragmented into disconnected facts and clusters of symptoms. To prevent the most basic medical errors, some facts are elicited over and over again, to the frustration of patients and healthcare providers alike: ‘Do you have any drug allergies? Have you had any surgeries? Are you taking aspirin or blood thinners?’ This frustrating repetition works, albeit inefficiently, if the patient is cognitively intact and well informed, but not all patients fit that description, especially in the event of a serious or acute illness. Health providers need views of the patient that are less fragmented than at present.” And so along comes information liquidity to remedy the fragmentation – or does it? PCAST report p. 23 says: "A first point to convey is that in virtually all of our use cases, the “user” of the data does not need to be, and indeed should not be, scanning through the entire health record. Instead, the user needs to be looking at an application layer that accesses and presents a limited amount of information from a given health record or set of records."

That “application layer” has slowly been emerging in pockets of HIT, perhaps because the information exchange is still a trickle, not a flood yet. Do clinicians trust a layer to limit the information they see? What’s the right balance between too much and too little? Though I’m a standards advocate, I’m not sure we’re ready for standards in this area, but we do need research, innovation, real-world implementation testing, evidence of what works and what doesn’t, sharing of experiences, policies, and guidance. In my third and final movement of this series, I’ll talk about some promising research and projects underway to improve the usability and benefits of the information that flows. Despite what I said about the challenges, I’m optimistic that we (collectively) will figure this out.

In the meantime, while you await the finale of this symphony, Happy Holidays and Merry Christmas to you!

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.