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.