Patient Engagement Needs to be a Two-Way Street

The “patient and family engagement” objectives within the federal Meaningful Use (MU) incentive program Stages 1 and (proposed) Stage 2 have been well-intended steps forward. But they have mostly regarded patients as receivers of information (education materials, clinical summaries after each visit, view/download/transmit their information, receive patient reminders). This is pretty much a “one way street.”  Sure, there is “secure messaging” where a patient can send essentially an email to a provider. But most requirements assume that providers control the keys to information that they (figuratively) “dispense” to the patient.

I recently read a fascinating book called “Cognitive Surplus: Creativity and Generosity in a Connected Age” by Clay Shirky, whose premise is that the digital age offers “thrilling changes” as society is transformed from a passive consumer culture (e.g., watching TV/movies and reading publications, all controlled by large media companies), to a more networked culture where technology enables people to create, publish, share, connect, and collaborate in innovative ways, without dependence on established authorities. While the “free for all” can produce huge volumes of frivolous or low-quality content, it can also engender truly original and breakthrough ideas, which otherwise would not have happened, by relying on the goodwill and “cognitive surplus” (hitherto untapped creative energies) of millions of people. Examples include Wikipedia, kiva (microfinancing to help individuals start small businesses and alleviate poverty) and Grobanites for Charity fans of a singer who banded together to help charitable causes in places such as Africa. Shirky’s cognitive surplus thesis has strong parallels to the Health 2.0 movement and patient engagement. How can patients be full partners and contributors to their health information and their health, rather than merely passive consumers whose information is controlled by providers? Or, to use a music analogy as I like to do, is the patient just listening to solo performances by each provider, or are they playing harmoniously as an ensemble?

Patients are partial contributors already. After all, didn’t lots of the patient’s history and information about symptoms, contraindications, outcomes, and treatment that’s in paper charts or EHRs come from patients and their families, through interviews, assessments, and clipboards? Who knows better than patients what they are really doing (not what someone else thinks they ought to be doing)? So it’s good that there has been recent testimony and requests for public comment from the HIT Policy and Standards Committees about patient-generated health data (PGHD). If you have any interest in this subject (and, as a patient, you should), you can respond too. There’s no stated deadline, though commenting sooner rather than later you’d be more likely to be heard.

Admittedly, it’s easier when discussing EHR certification and MU to discuss outputs from the provider’s EHR to patients, because those are easier to understand, quantify, and control (from a provider’s or EHR vendor’s perspective). When accepting information from patients, things are much more unpredictable. The request for comment asks 10 good questions, such as how “structured” PGHD should be, where are patients “the authoritative source,” and what degree of incorporating PGHD into EHRs should be expected of providers.

I have many thoughts on these questions. More to come next week…

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.

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.

Making HIT MUsic

This post assumes that you have a general understanding of ARRA HITECH legislation and the concepts of Certification and Meaningful Use (MU) of Electronic Health Records (EHRs).

So what would make HIT successful? Let’s keep our eye on the nationally stated goals of quality, safety and efficiency, i.e., better and safer health for consumers at a reasonable cost. As my first blog article compared interoperability specifications to musical scores, I’ll recommend where detailed specifications are necessary, and where they aren’t, so that we end up with a HIT MUsical, not an expensive flop/bomb. (I warned you about my puns in the first article!)

As people wonder what MU should be in the future, some alternative approaches are being considered by groups such as the HIT Policy Committee Meaningful Use Workgroup. One approach is to focus on outcomes achieved more than specific functional requirements. The HIT Policy Committee’s Certification and Adoption Workgroup made recommendations in August, 2009, that “Criteria on functions/features should be high level; however, criteria on interoperability should be more explicit.”

Interoperability: yes, be very specific! As one who has pored over many committee recommendations, interoperability specifications, CCHIT criteria, HHS regulations, NIST test scripts, certification handbooks, and HHS FAQs, I agree that interoperability criteria need to be explicit. I enjoy the opportunity to listen to various performances and recordings of masterpieces such as Beethoven’s Symphony #7. They allow some innovation in tempo, dynamics, and expressivity, but they’re all still the same symphony, because they conform to Beethoven’s musical notation “spec.” I don’t think anyone would suggest that the symphony be performed without all musicians following the same score. Because many players’ efforts need to fit together, it wouldn’t work to let musicians make up their own parts. Interoperability likewise requires many systems to fit together. But let's not skimp on quality: specs need to be implemented successfully in the real world before requiring their use. Also, evaluating return on investment is also key to avoid going overboard: the more frequently information is exchanged, the more people who need the info, and the higher the impact, the more it is worth standardizing. But for something on the other end of the spectrum (infrequent exchange, few people, little impact), is standardization worth the effort and cost?

Functionality: don’t be too prescriptive! In contrast, “functions/features” criteria, excluding interoperability, can be stated at a high (non-prescriptive) level, because they’re within a single system. Other organizations’ systems don’t interact directly with them. There’s the dilemma of wanting to ensure success without “micromanaging” and stifling innovation. Everyone “doing their own thing” re interoperability might be innovative but counterproductive. But when it comes to clinical functionality and workflows, won’t providers have enough information from other providers, market reports, professional associations, user groups, Regional Extension Centers, and test-drive opportunities to figure out what will work for them? Bear in mind that an EHR’s customers already have a starting base, and will lean towards whatever adds value to what they have, rather than something that conforms to generic criteria but doesn’t fit their environment.

We all want a health system that produces the best possible health outcomes for us. I’d rather see our policies, and the efforts of EHR developers, focused on achieving those outcomes, rather than meeting the “letter of the law” of detailed functionality criteria. Such criteria can lead to developers diverting time from features their customers really want, in order to “check the box” and deliver features to meet certification criteria and test scripts that won’t ever be used. So for functionality, excessive specificity of criteria produces distraction and waste! But in contrast, lack of precision and clarity of interoperability specs has produced waste, resulting from people being confused and the same question being asked over and over again.

So I think the original recommendations of the Certification and Adoption Workgroup regarding high-level functionality criteria and explicit interoperability criteria, and the MU Workgroup’s thoughts of more outcome-oriented objectives, are excellent paths to follow as we proceed into MU Stages 2 and beyond.