Jaa

The Truth About Health IT Standards – There’s No Good Reason to Delay Data Liquidity and Information Sharing

  • Artikkeli

David C. Kibbe and Peter Neupert

Now that the Obama administration and Congress have committed to spending billions of tax payers’ money on health IT as part of the economic stimulus package,  it’s important to be clear about what consumers and patients ought to expect in return—better decision-making by doctors and patients. 

The thing is, nobody can make good decisions without good data. Unfortunately, too many in our industry use data “lock-in” as a tactic to keep their customers captive. Policy makers’ myopic focus on standards and certification does little but provide good air cover for this status quo. Our fundamental first step has to be to ensure data liquidity – making it easy for the data to move around and do some good for us all.

We suggest the following three goals ought to be achieved by end of 2009:

  • Patients’ clinical data (diagnoses, medications, allergies, lab results, immunization history, etc.) are available to doctors in 75% of emergency rooms, clinic offices, and hospitals within their region.
  • Patients’ doctors or medical practices have a “face sheet” that lets any staff member see an all-up view of their relevant health data, including visit status, meds, labs, images, all of which is also viewable to patients via the Web.
  • Every time patients see providers, they are given an electronic after-visit report that includes what was done and what the next steps for care will be according to best practices and evidence-based protocols, whenever these are applicable.

Some who view this seemingly humble list of achievements will say that we can’t do it, because the standards aren’t ready, or the data is too complex. They’ll say that delays are necessary, due to worries about privacy or because too much data is still on paper.

We disagree.  We believe that where there’s a will, there is going to be a way.  And we already know most of what we need to know to achieve these goals.  We know that:

  • huge amounts of digital data exist, already formatted electronically, but scattered across many proprietary systems (meds, labs, images).
  • software and the Internet makes it possible—in a low cost, lightweight way—to get data out of these databases to the point of decision making (to the ER doctor, the patient/consumer, or the  primary care physician).
  • people are hungry for information in whatever form they can get it:
    • Getting it on paper is better than nothing
    • Getting it quickly is better than getting it late
    • Getting it in non-standard digital format is better than paper (software is pretty good at transforming non-standard to standard formats)
    • Getting it in a standard format is better
    • Getting it in a structured, standard format is best
  • An integration “big bang” -- getting everybody all of a sudden onto one, single, structured and standard format—can’t and won’t happen.

We don’t have to wait for new standards to make data accessible—we can do a ton now without standards.  What we need more than anything else is for people to demand that their personal health data are separated from the software applications that are used to collect and store the data.

This idea of separating health data from the applications is very important, and a better way to frame the discussion about how to achieve data liquidity than is the term “interoperability,” which we find cumbersome and opaque. Smart people, armed with software, can do incredible things with data in any format – so long as they can get to it.

Customers of health information systems want to re-use their health data, and in ways they haven’t always thought of or anticipated.    However, many enterprise system vendors make it difficult or expensive to get access to the data—to separate it from the application.  They believe that proprietary “lock-in” allows them some form of strategic advantage.      

We understand that IT vendors are in business, and need to create strategic value for their products.  And we are very much in favor of that—in rules, in workflow, in user experience, price and flexibility, and so on. However, vendors should not be able to “lock” the patient or enterprise data into their applications, and thereby inhibit the ability of customers and partners to build cross-vendor systems that improve care.

It’s possible for vendors to provide value without the need for lock-in.  There are lots of examples of this, for example, the Health Information Exchange in Wisconsin and CVS MinuteClinic.  In the former, value is clearly being added immediately to users in the ED, without requiring all the participating EDs to change their systems or to be standards compliant (or CCHIT certified).  At MinuteClinics, summary after-visit health data are made available to customers online using the Continuity of Care Record standard. This is where the low hanging fruit is.     

There’s already a proven model for extracting and transforming data in many ways – HL7 feeds, non-HL7 feeds, web services, database replication, XML and XSLT, and more – and along the way wecan create value by interpreting the data and adding metadata.  Microsoft is doing it today– both in the enterprise with Amalga and and across enterprises to the consumer with HealthVault.    We hope other vendors follow this lead to drive better outcomes for patients. 

Unlike the physical world where there is a need for dejure standards—think railroad tracks—in the software world, there is much more flexibility and the standards that work are the ones that evolve from USAGE and market acceptance.    The certification and standards road equals conferences, press releases, “connectathons”, caregivers-turned-bureaucrats.  The outcomes road equals immediate benefits to actual caregivers AND learning we can apply to the next round, and the next, and the next.
 
We have given the industry decades to make this happen --- and just in the last 1-2 years have people finally gotten fed up and just started moving.  Our great risk here is that the people lobbying for dollars and certification today are the people who are invested in the old road.  With the amount of money we are talking about, we run the risk of just giving them another decade to delay and plan.   Instead, let’s put the dollars into rewarding behavior and outcomes, and let the people who live with the problems every day figure out how to solve them.
 
When we set out to go to the moon in the 1960’s we didn’t say “let’s build a great rocket.”   So, too, in this case we shouldn’t say “let’s buy a great IT system.”   Our measurements should be tied to what we want – better care, informed by the data that is just out there waiting for us to use it.

David C Kibbe MD MBA is a Family Physician and Senior Adviser to the American Academy of Family Physicians who consults on health care professional and consumer technologies.  Peter Neupert is Health Solutions Group Corporate Vice President at Microsoft.

Comments

  • Anonymous
    January 01, 2003
    We've spent a lot of time over the last couple of weeks talking about moving data around - making it

  • Anonymous
    January 01, 2003
    Good article from Peter Neupert of Microsoft   who testified in front of the Senate last week and

  • Anonymous
    January 23, 2009
    Have fun pushing a wet noodle.

  • Anonymous
    January 26, 2009
    "Unlike the physical world where there is a need for dejure standards—think railroad tracks—in the software world, there is much more flexibility and the standards that work are the ones that evolve from USAGE and market acceptance." David, Peter - great commentary. Agree. I like to call this "interoperabiity by design" and not by "standards" (constraint). Sending around the link to to your post.

  • Anonymous
    January 26, 2009
    Peter, you and David note that “(w)hat we need more than anything else is for people to demand that their personal health data are separated from the software applications that are used to collect and store the data.”  Microsoft’s answer to driving that consumer demand seems to be HealthVault. HealthVault is ineffective in driving demand from the consumer side, and indirect in its impact in doing so.  When I visit HealthVault, I have two choices for sharing information.  I can personally input my health care information and send a blind invitation to a provider to share the information I have input (an invitation hardly being a demand), and with no assurance that the provider will do the same; or I can see all applications that work with HealthVault and will populate my HealthVault account with its information related to me (none of these applications look to be directly connected to traditional providers).  So while I can type by hand or scan into HealthVault the paper documents given to me by my provider, how do I obtain, digitize and upload the images, tests and practitioner notes that were taken?  And while I can upload the results from my medical devices and other applications, what assurance do I have that it will be read, digested, and used to make my next office visit with my provider more efficient and result in a better outcome?  The answer to both questions is for HealthVault to connect those practitioners who are passionate about using technology to drive efficiency and improved outcomes with similarly-minded patients, not to send out blind requests to providers, or to try to turn consumers into thousands of Microsoft HealthVault sales reps calling on one physician at a time.   Forcing the consumer to input and upload the data to HealthVault doesn’t do much to expose consumer demand, nor does providing an invitation system that encourages blind communication with a provider that may or may not have even heard of HealthVault.  Neither does empowering the user to download heart rate or blood sugar information from portable devices (laudable as a proactive, preventative activity, but not as a driver of portability and control of medical information).  If you are truly interested in people demanding that their personal health data are separated from the software applications that are used to collect and store the data, then provide a searchable database in HealthVault that provides by name, specialty, practice, location, insurer, etc. those providers that actively support HealthVault, encourage their patients to use HealthVault, and will post patient medical records (including images, tests, practitioner notes, etc.) in their patient’s HealthVault account upon patient request.  Such practitioners would be rewarded by greater patient volume among the most desired patients - those who are already committed to more efficient practices and better outcomes themselves.  Connecting these consumers with medical practitioners who are committed to HealthVault would create a virtuous cycle that would eventually expand to reach the practitioners and patients initially hesitant to embrace the portability of medical information. While this functionality may have already been evaluated and declined by the HealthVault team or may be targeted for a future release, if you are genuinely concerned about generating a consumer-driven demand for medical record portability and control, you must update HealthVault now to contain this information.

  • Anonymous
    January 27, 2009
    David and Peter - spot on, in many ways. Most welcome is your viewpoint on "lock-in" as a significant obstacle to the patient-centric world of data and improved healthcare ecosystem at scalable and sustainable economics. I have found that many hospitals under 200 beds (accounts for nearly 40% of the US health system) lack resources to unlock data themselves and cannot employ technology that "extract and transform data in many ways" particularly due to the enormous  (read as $20,000+ per data feed) toll to "unlock" the data ... charged to build an interface. This said, I am aware of hundreds of hospitals who are going it alone, not waiting for interoperability standards, because they see the immense value of unlocking the data and working with a holistic patient view of data. So movement is afoot. Hopefully Peter's testimony to Senator Kennedy et al resonated and has begun to move this mountain. Thanks for speaking out.

  • Anonymous
    January 27, 2009
    I'm not sure anyone is seriously suggesting that you can't integrate without standards.  The point is that standards generally* make life easier.  Easier usually improves cost effectiveness (and/or development speed if that is what you're working to).  As a technologist, I'd love to go for integration across the board (in fact, I'm a huge SOA advocate), but most businesses need to factor cost effectiveness into their decision to invest. Of course, the "customer pull" which you describe will help with the benefits side of the case. *in healthcare we're way off a diminishing return on standards whereby they become a constraint... in fact the standards will mature into being more flexible for a good while yet.

  • Anonymous
    January 30, 2009
    Shawn --- You've nailed the reason that traditional "PHR" applications have failed to gain the traction or realize the benefits they promise. Folks have voted with their feet for years --- if the experience isn't connected to docs --- both from a workflow and data perspective --- uptake is going to remain limited and, in your words, ineffective. Trying to solve this is fundamentally the reason HealthVault exists in the form that it does. The problem is, capturing that data and intersecting those workflows is tough --- health information is mostly on paper today, and when it is digital, it's scattered between systems in lots of proprietary repositories. Workflows are not standardized and are a key cost driver - for example, asking a doc to take time out of his seven allotted minutes for a visit to do template-based documentation --- hard sell. The end result being, there is no easy answer to getting data automatically into an aggregated form that makes it useful. That said --- virtually all of the work we are doing right now is targeted at making that happen: our data model is designed to support information in whatever form it exists (structured to unstructured); we are involved in connectivity projects with most major hospitals in the US; we are engaged with every significant EMR and HIT vendor in the industry; we have a growing set of third-party consultants who are expert in connecting provider systems to HealthVault; our device story enables capture of new information in the home; unique services like UNIVAL take paper records and turn them into structured digital data; and yes we support manual entry and faxes/scanning as well. This is the brass ring --- and we are "all in" to get it done. In fact, this is really a key point behind Peter and David's post ... that the reality today is that information is in all kinds of formats, and at all levels of structure, and hidden behind all kinds of gates. By focusing exclusively on mandating "standards" that by definition can only capture a tiny fraction of the real world data, policy makers run the risk of making it way more difficult to pull this stuff together --- because there are tons of reasons that data exists in the forms it actually does. The real problem we need to fix is the mentality that access to data is a competitive advantage for vendors --- because THAT is where the system falls down delivering the kind of data exchange you're looking for. For our industry colleagues --- how many products do you know that implement "standard" HL7 feeds --- but the data in those feeds is a subset of all the relevant data they have in their proprietary databases? This is how it goes down --- vendors can say they're "standards compliant" but use data lock-in to try to hold tight to customers. This has to change. The fact is we are just getting started with HealthVault --- there is lots to do. Thanks for engaging in the dialog --- I hope you continue to stick with us. If you want to learn more about how we're trying to kickstart connectivity, visit my blog at http://blogs.msdn.com/familyhealthguy or check out or development documentation at http://msdn.com/healthvault.

  • Anonymous
    February 01, 2009
    The comment has been removed