Showing posts with label HIE. Show all posts
Showing posts with label HIE. Show all posts

Tuesday, April 24, 2012

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.

Wednesday, December 28, 2011

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?

Monday, November 7, 2011

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.

Wednesday, October 12, 2011

Putting the IT in Care TransITions

On Friday, October 14th, 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 14th 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 14th 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.

Thursday, February 17, 2011

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

Tuesday, December 28, 2010

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.