Forecast Cloudy but Clearing: a Crystal Ball for Meaningful Use

Now that the HIT Standards Committee met on September 28^th to wrap up their “Standards Summer Camp” and are well along in several of the ONC Standards and Interoperability Framework initiatives, how do we stand in getting a clear weather forecast for Meaningful Use Stage 2? Activity was fluid during the hot summer, but by the chill of winter, much will have “frozen” into the form of ONC’s Notice of Proposed Rulemaking (NPRM) for Stage 2 Standards and Certification Criteria.

I was pleased to see an initial draft of certification criteria produced by the Implementation Workgroup. While it’s very preliminary, I understood it to be the first cut at the criteria that ONC will refine over the next few months as they write the NRPM, expected to be released for public comment perhaps in January. Here are a few highlights of what I found new or surprising. While my main focus is generally on information exchange criteria, there is some noteworthy new information on other objectives too. Numbers refer to the rows in the document.

• 10 Clinical Decision Support. There’s more specificity around the ability to configure the CDS rules based on user role, patient setting, and points in workflow; also display of the evidence/source of each notification or care suggestion
• 15 Lab Results. Lots of work has been done in the ONC S&I Framework and HL7 on the new Lab Results Interface (LRI) implementation guide, in an effort to bridge the gap between competing standards. I applaud efforts to work together to reach consensus, even if it means no one gets everything they want, so I hope that this standards effort is leveraged.
• 18 Electronic Notes. They provide clarity that it must not be a scanned document, but that pretty much every other kind of electronic note is OK. While functionally that is achievable, hopefully there will be careful consideration in how to measure this objective to avoid burdening providers with workflow issues.
• 23 Patient View and Download. A definite shift to patient-initiation via electronic access (a secure web portal for example) to more information than was required in Stage 1, rather than have to request a copy through provider personnel. There’s still much debate about alternative ways to satisfy this (e.g., is an export to a patient-controlled PHR acceptable?), so it will be important for guidance to be clear here. 
• 29 Exchange Clinical Information. In this objective, as well as Patient View and Download, clarity is needed on how many types of clinical documents are required (one-size-fits-all vs. multiple different documents?). For example, the ONC S&I Framework Transitions of Care initiative has recommended specific documents -- Discharge Summary and Discharge Instructions from a hospital and Consultation Request and a Consultation Summary from an EP, but the MU objective is written as if it is just a single clinical summary.
• 33 Syndromic Surveillance. As expected, there is a new implementation guide, though it is only applicable to hospitals. But there is still uncertainty over considering submission of Reportable Cancer Conditions by EPs. If that is to be included, what is the recommended standard?
• 52 Amendments to information. This is a requirement that had not been included in previous presentations of Stage 2 MU. Will it be in the NPRM? If so, it would include replacing a data element while preserving a record of the previous value, and appending patient-supplied information as free text or scanned image/document, for patient engagement (e.g., if the patient disputes something in the record). Note, they use the word "user" but are not clear whether they mean "patient" for the requirement to "Make electronically available, upon a user's request, a historical account of amendment(s).”
• 53 Patient Matching. This is also something not mentioned in the Policy Committee's MU objectives. It is fuzzy at this point. If included in certification, it would impose more validation upon some demographic data.

I encourage you to read these thoroughly and work through the channels available to you (e.g., a provider association, a trade association, an industry consortium, or comments to ONC’s blog) to submit suggestions for clarification. The people on policy and standards committees work very hard, but it’s impossible for them to anticipate every case where someone might have trouble interpreting. The implementation workgroup already has flagged areas that they know need more work. If you can give examples of how interpretations may vary, and offer constructive suggestions for how it could be worded unambiguously and made testable, I think it will help ONC to write the clearest possible regulatory language.

How Would EHRs Matter to Patients?

In my previous post, I said I’d talk next about patient engagement functions that need EHR data vs. those that don’t.

No doubt, there are some “data-less” functions that can still be useful – you need little or no clinical data to request an appointment, e-mail your doc, or a refill (other than your Rx number). Here’s a list, undoubtedly incomplete, of some functions that I think are Not EHR-dependent vs. those that need (or greatly benefit from) EHR data. Several of the items below are “gray areas.”  

Not EHR-Dependent

• Personal Health Record (PHR) – untethered, if patient is willing to enter the data or settle for existing PHR data feeds (e.g., PBM med history)
• Patient self-service functions (e.g., schedule appointment, request drug refill, view clinical data, pay bill)
• Patient-provider communication and collaboration
• Tools for providers to improve the patient experience
• Technologies to make healthcare more accessible for patients, e.g., telemedicine, virtual visits
• Wellness/lifestyle aids (not just "medical", e.g., diet, exercise, recreation)
• “Find a doctor”
• Search for alternatives to provide services (e.g., price comparisons for services not covered by insurance)
• Patient satisfaction surveys
• Bedside communication with family & friends (e.g., Skype video chat, web access)
• Notification/invitation to events (free screenings, symposiums, etc.)

EHR-Dependent (some may also be provided by Health Information Exchanges)

• Patient access to EHR information (e.g., download)
• Personal Health Record (PHR) – tethered; or untethered PHR with data feeds from EHR (to greatly increase usability)
• Patient Portal
• Patient annotations/amendments to their health information
• Patient provision of information to providers (e.g., home device measurements)
• Providers pushing information to patients via patient preference
• Reminder “app” for taking meds, vaccinations, physical exam, etc.
• Other apps or notifications that help patients follow through with what was prescribed/planned
• Tools for patients to act upon their data (trackers, analytics, access to knowledge)

So patients can accomplish quite a bit without EHRs. But you have questions about your lab or imaging tests and their significance, or your many medications, it sure would help to have the actual data and not rely on memory. I doubt that you’d get full benefit from your med list unless you also knew about your problems/conditions and diagnostic results. I, for one, wouldn’t want to take subsets of my data and redundantly enter it into a dozen separate websites.

If I’m a patient who wants a comprehensive and integrated view of my data, how might I get that? More on that next time…

Certification Retrospective Part 3 – Controversies Along the Way

Note: this blog post continues my discussion of experiences in CCHIT. The opinions are mine only and do not necessarily reflect the views of CCHIT or Siemens. Please bear this in mind especially considering that the topic is “Controversies”

From my last Certification Retrospective post, I promised to share lessons learned and some “agonizing controversies” we faced in the CCHIT Interoperability workgroup (IOWG). I thought I could do both in one post, but now realize that I’ll need a “Fourth Movement” after this. Each controversy could easily take up a post of its own, but I’ll try to squeeze them into this post, deferring Lessons Learned to Part 4.

1. When should HITSP specs be incorporated into certification? Once HITSP was formed, it (not CCHIT) was designated to select standards. CCHIT, however, could decide when/if those standards would be certified, striking a difficult balance between supporting the federal strategy (HITSP was HHS-funded, CCHIT was partially HHS-funded) and yet being pragmatic. It would have been difficult to require EHRs to develop too much at once when certification was “all or nothing” and not modular. From working in both CCHIT and HITSP, CCHIT tended to give more weight to considerations such as market adoption and lead times, not just whether a suitable standard existed. I along with Jamie Ferguson were appointed to co -chair the 10-member HITSP-CCHIT joint working group, whose goal was to coordinate the work of HITSP and CCHIT and address how/when to include HITSP specs in certification. But some HITSP-selected standards were still in “trial implementation” with little adoption, and the approval of a standard (HL7, HITSP, or any other) didn’t mean it should be mandatory within a specific timeframe. And there were just so many of them to digest, let alone certify! Some people weren’t pleased, thinking that CCHIT should be a more aggressive “enforcement arm” of HITSP. In the end, we included more of HITSP in 2008 and 2009 certification criteria than ONC did in its 2011 certification criteria, most notably the HL7 2.5.1 Laboratory results with LOINC vocabulary starting in 2007, C32 CCD starting in 2008 (adding RxNorm, UNII, SNOMED CT vocabularies in 2009) and HITSP TP13 (IHE XDS.b – see point #2 below). But we also roadmapped (2-3 years out) most other HITSP specs when we published our 2009 criteria. I believe this was a sensible middle of the road approach. IMHO, if we had mandated many more HITSP specs in certification, there would be few or zero certified products today!
2. Should certification require transport standards? Fourth & Ten – we’d better punt! Seriously, we debated this during 2008 and 2009. We recognized this as a glaring gap in interoperability, and wanted to make headway, realizing that lack of secure transport standards would hinder interoperability even if content were standardized. The Direct Project didn’t exist back then. We were aware of diverse ways that HL7 messages were transported, that IHE had defined SOAP-based web services for document transport, and that HITSP had selected many IHE specifications. Many vendors had already tested IHE Cross-Enterprise Document Sharing (XDS.b) at Connectathon. So the IOWG approved XDS.b as 2009 certification criteria (along with PIX/PDQ to support it). But the Board of Commissioners decided to designate these as optional interoperability criteria, not required for certification, because despite the IOWG’s recommendation and strong EHRA support, some commented against it. This was the one case I can recall where my workgroup’s recommendation was overridden by the Board, which I know was a tough decision since the Board usually didn’t do that. This was also a case where we were less aggressive in CCHIT than the EHR Association had proposed. EHRA had sometimes criticized CCHIT for not providing enough lead time, but in this case they were very disappointed that CCHIT had not required this in certification. This one still bothers me as a missed opportunity.
3. Should we require discrete data import, and who owns that decision anyway? We felt that the main point of requiring standardized content formats and vocabularies, not just human readability/liquidity, was for the discrete data to be consumable. Following our “methodical march” mentioned in part 2, we thought in 2008 that the time had come to propose discrete data import (e.g., update your medication, allergy, or problem lists using data from other providers). But now we were into a “boundary condition.” Where did interoperability’s “turf” end and functionality begin? We had a series of “discrete data import” meetings between the IOWG and the Ambulatory and Inpatient Functionality workgroups. We recognized that data must not only be exchanged, it needs to be reconciled (medication reconciliation being an example), and that you can’t just “slam in” all meds, allergies, problems from many external sources to automatically update the active med/allergy/problem list. The functionality workgroups didn’t think the time was right to require such capability in certification for 2009 or 2010. But how were we going to keep making progress toward semantic interoperability? In the end, we proposed criteria to import very specific discrete data elements for medications, allergies, demographics, and immunizations (with problems to come later), as described in my last post. But we didn’t define the functionality, as long as the discrete data were stored somewhere. And in any case, reconciliation criteria would belong to the functionality workgroups, not the IOWG. I think this would have been a reasonable “baby step” but because of the change in certification that started in 2009, those roadmap criteria never had the chance to be certified. I hope that similar careful thought will go into decisions in ONC certification, whenever it gets to that point. End-to-end interoperability involves content creation, secure standardized transport, and content consumption, all of which should be considered holistically.
4. Should we push the industry toward a single standard for clinical problems? This was really part of the broader topic of converging on a singular standard vocabulary for each type of data, but SNOMED CT for problems was the lightning rod topic for several reasons: a) the difficulties of getting physicians to create medical problem lists at all; b) ICD-9 diagnosis codes were already required for reimbursement and some physicians systems were built around ICD-9; c) ICD-10 was already complicating things by looming on the horizon; d) anything that imposed more work on physicians could hinder usability and adoption. So though SNOMED CT seemed a clear winner for an interoperable clinical vocabulary and was HITSP-endorsed, we received considerable pushback from some members of the other workgroups as to how fast SNOMED CT could be required. I was pleased that many in the IOWG stepped up to provide statistics and research facts such as analysis of mapping of ICD-9 to SNOMED CT and clarification that standard codes don’t have to be visible in the clinician’s UI. We knew this was a contentious issue, but staked out our positions in the 2009 roadmap and a Q&A document.

The above four were prototypical of the controversies we faced in content, vocabulary, and transport. I could go on with more examples. That’s part of the challenge of interoperability work, as evidenced by the fact that ONC and the HIT Standards Committee still have all of the above issues to ponder for Stages 2 and beyond. I should mention that one more big controversy arose in the very first year, when CCHIT was newly formed and struggling to figure out how to set the interoperability bar. Eyes were upon those first members to resolve the CDA vs. CCR debate. Unlike the four issues above, where we took a stand, we weren’t ready to force a decision in 2006, and then HITSP was formed by ONC to deal with such “standards harmonization” issues. So at least our punt had a receiver (and football wasn’t locked out)!

I promise that Part 4 will really conclude this series with my thoughts on Lessons Learned, proudest accomplishments, regrets, and hopes for the future, stemming from my CCHIT experience. Thanks for listening to my sharing from “inside the trenches” of discussions of which the public was not aware.

“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.”

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.