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:
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:
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.
Have fun pushing a wet noodle.
Good article from Peter Neupert of Microsoft   who testified in front of the Senate last week and
"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.
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.
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.
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.
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.
Peter, I concur with your posted blog on IT Standards. To be sure, this is not as much a technology or standards problem as it is a sociology issue. The first step is for the Industry is to acknowledge IT for what it is, a medical tool or device.
There is little debate that knowledge and information have always been among a physician’s best clinical tools. Consistent with this fact,IT should be viewed by the healthcare industry as a medical device. With the advent of evidence based medicine coupled with advances of IT, we are in many ways on the brink of a golden age of medicine.
We can all agree comprehensive personal clinical information has not digitally made its way into the consumer’s hands. To some degree it is not readily recommended or available, yet.
Consumers have great interest in the subject of healthcare, yet the long predicted wave of consumer empowerment in healthcare has yet to arrive.
Consumers, as well as the business community, are generally unaware of the healthcare cost and quality issues and interoperability issues. Nor do they recognize that they have a new, long anticipated, role as purchasers seeking value in the healthcare delivery system.
Today, the consumer is unable to identify value without information on cost and quality. Quality cannot be identified without measurement and it cannot be compared without standardization.
How does a consumer get educated about their new role in their own health and their interaction with the healthcare delivery system? Who do they trust to guide them?
Consumers trust their physicians far more than any other group in the Healthcare system. They certainly value their doctor’s advice, even if they don’t follow it all of the time.
Today, the consumer is effectively, unwittingly waiting on their physicians to recommend this new medical device for their health. Therefore, engagement of the physician is the key to fostering consumer empowerment.
Admittedly, IT is in many ways a crude medical device, but that is today. Many of the now traditional medical devices that were introduced into the healthcare market throughout history started off as crude devices; think about surgical tools.
Like other medical devices, this device is certain to evolve with use, experience, and continued development and innovation. Many predict that the use of this IT device by healthcare professionals will become the standard of practice, like scrubbing in before surgery. The legitimate debate generally centers on how and when.
As with other changes in medicine, the adoption of this new tool will be an evolution. It will not happen by just flipping a switch at the end of any given year, it will evolve. Consumers and their physicians must participate in this evolution for it to ultimately be successful. The consumer’s best platform to effectively and economically engage with the industry is a standardized personal heath record (PHR).
I contend that a PHR is Durable Medical Equipment (DME) and that the Payers should pay for it:
There is no single authority, such as a federal agency that confers the official status of DME on any device or product. A fairly comprehensive definition of Durable Medical Equipment as contained in a Texas Group Policy is as follows:
Durable Medical Equipment is defined as being equipment that:
- can withstand repeated use; and
- is primarily and customarily used to serve a medical purpose; and
- is generally not useful to a person who is not sick or injured, or used by other family members; and
- is appropriate for home use; and
- improves bodily function caused by sickness or injury, or further prevents deterioration of the medical condition; and
- is prescribed by a physician.
A consumer’s PHR fits the definition as follows:
Durable Medical Equipment means
equipment : Noun. An instrumentality needed for an undertaking or to perform a service.
- can withstand repeated use. a PHR easily withstands repeated use.
- is primarily and customarily used to serve a medical purpose. a PHR contains a consumer’s relevant medical information so many medical decisions can be made based on the contents of the record.
- is generally not useful to a person who is not sick or injured, or used by other family members; a PHR is not useful to anyone in the consumer’s family but the consumer and only the consumer can use it to track and support her health or coordinate her care when she is ill
- is appropriate for home use; a PHR is appropriate for home use or anyplace a consumer has a connection to the Internet.
- improves bodily function caused by sickness or injury, or further prevents deterioration of the medical condition. According to the trade association that represent insurance plans and the executives of most plans, there is consensus among stakeholders that the widespread adoption of health information technology will lead to safer, more effective health care. Experts believe adoption of technology will reduce preventable errors, such as medication errors, increase compliance with recommended treatments, improve treatment for people with chronic disease, and contribute to lower health care costs.
and is prescribed by a Physician; Can physicians professionally make this recommendation to their patients? It depends on whether they can professionally agree with the statement that “a PHR is a medical tool that in certain cases can benefit their patient’s ongoing health or illness.”
If physicians prescribe a PHR for each of their patients, and the Payers collectively agree to pay the costs, (that I believe they are already contractually responsible for anyway under the terms of their issued policies), the standard of practice in a community can change. Physicians can create a new business model in order to pay for their EMR system, and the power of a new medical device can be leveraged for the benefit of the consumer.
It is only when the Physicians are engaged that the consumers will follow, and the market will rapidly evolve. Then the standards will be market driven, because there will actually be real demand fueled by Doctors and their power to prescribe. So the key will be, how do you really engage the physicians?
Standards will not engage them, but more time, more money, and clinical benefit will. That does not sound like a standards or technology problem to me.
We've spent a lot of time over the last couple of weeks talking about moving data around - making it