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.

Intermezzo: ONC Standards and Interoperability Framework Initiatives

Before the 3rd movement of my blog series -- on information liquidity, the trickle becoming a flood, and final post yet to be named -- I was busy just before Christmas writing responses to a call for comments on the ONC Standards and Interoperability Framework initiatives. I posted my responses on the ONC FACA blog (I had multiple responses, all on December 22nd around 2pm).

I'm also working with others on responses to the recent 108-page PCAST report on "realizing the full potential of health information technology to improve healthcare for Americans." More on that later...

So now, back to the post-holiday catchup and to the 3rd movement!

David

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.

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.

Harmonious What?

Hi, I'm David Tao. This initiates my new blog. I'm not going to dive into anything deep, heavy, political, or technical today. But I'll briefly introduce myself and my blog's purpose. I expect that anyone who takes the time to read this is interested in healthcare, information technology (that's what "IT" is), or else is my mom or wife.

I'm married, a father of four, and a grandfather of two. My family is blessed with good health and has generally avoided serious illnesses. But if there's one thing I know for sure, there are no sure things as far as health, so I want the health care system to work as well as it possibly can when we inevitably need it.

I've been employed since 1977 by Siemens Healthcare (and Shared Medical Systems, which Siemens acquired). Siemens is a large global company with major presence in many technology/engineering fields. Its products are everywhere, some visible to the eye (like windmills, high-speed railroads, solar panels, light bulbs, and MRI machines) and some behind the scenes (like electrical power distribution, broadband networks, and the software that runs healthcare organizations). I'm a "senior key expert" in the Solutions Development organization of a business unit known as Siemens Health Services, located near Philadelphia, PA, which provides Healthcare Information Technology ("HIT") software and services for healthcare organizations like hospitals and physicians. My specific focus is on interoperability (which means exchange of information). Patients receive health care in many physician offices, hospitals, clinics, labs, pharmacies, long term care, and their own homes, so their information should be exchanged with everyone who needs it, including the patients themselves and their families.

Why did I name my blog "Harmonious Health IT?" It's really a play on words expressing my professional desire for HIT systems to share information and work together "harmoniously" for the good of patients, and my personal love for music (and harmony in particular). I enjoy singing in a cappella vocal groups, church choirs, and harmony-driven pop like Beach Boys/Eagles/Beatles. I also love playing classical piano (one of the few instruments that can create its own harmony as well as melody and rhythm).

There are lots of parallels between music and interoperability. Consider an orchestra where all the parts need to fit together. Similar to the specifications for HIT interoperability, orchestral scores are both a "standard and implementation guide" to the musicians. Individual musicians have some flexibility in how they perform their parts, but they're guided by well-defined specs for what instruments like the cello, french horn, timpani, and clarinet should play. If everyone made up their own part, there wouldn't be harmony, but rather disharmony or even cacophony. Unfortunately, HIT hasn't always been harmonious over the years if systems made up their own parts. But with billions of taxpayer dollars stimulating increased use of HIT, it better become harmonious quickly!

Never mind my age, but when I quote the song "I'd like to teach the world to sing in perfect harmony..." that may give you a clue as to my generation. Many of you won't know what I'm talking about (but for those who do, yes I prefer Coke over Pepsi). If I were to call that a "HIT song" that would also tell you about my unfortunate propensity for puns (from which you can only hope I spare you in upcoming blog posts).

In the coming weeks, I'll share my thoughts on what's happening or on the horizon in HIT, and my suggestions for how all of us (who share a common bond as consumers and patients of the healthcare system) can help ourselves move forward to more harmony in health and ultimately to more harmony in our lives.

Thanks for joining me.

David