Many have criticized HealthVault regarding privacy and security concerns, or perceived limitations of HV as a personal health record (PHR). I suspect that HV is challenged more by the market's perception of Microsoft's long running security issues than with any actual shortcomings of that type in HV. And since HV is not a PHR, but rather a "platform," criticisms about any lack of PHR features is not relevant.
One topic I've not seen addressed is the safety and effectiveness of the data within HV - and I don't mean "safety" as in the data is secure from unauthorized access or misuse. I mean "safety" as in the utilization of data stored in HV by other applications won't result in an unsatisfactory patient outcome, you know, like death or injury.
Certainly at first blush HV does not fall under the FDA's purview, but things could end up that way. (More on this later.) A key tool mandated by the FDA's Quality System regulation (QSR) to ensure quality and safety is the risk analysis. Any kind of connectivity needs to be thought of with risk analysis in mind - what can go wrong and how can those risks be mitigated?
If HV is more than just an interface engine, pushing data from one application to another, the risks are narrow. Sample risks include: data corruption during transfer into or out of HV, and data corruption during conversion of the data from one standard format into another. Mitigating these risks is straight forward; common data communications techniques to ensure data quality, and design and testing of the HV platform itself to verify data conversions are done accurately and reliably.
What if HV is more than a translator, but a repository of patient data? Most applications have a database that is written, updated and controlled by that application. It is the application that ensures that the data in the database is correct and valid. It is the application that provides the workflow to safely and reliably validate, edit and update data.
How is data quality ensured when various applications can read and write that resides on HV? Let's say data is edited or a calculated value is generated and then rewritten to HV. Does it overwrite the existing data? If there are multiple sets of the same data, how do you know which set is the best and most accurate data? Do you assume that the most current values are correct? What if they're not? What if that "better" data is not rewritten to HV but remains in the clinical information system in which it was generated - and another application comes along and uses the "wrong" data?
HV does track the properties, history and sharing of patient data. It also logs the time received and the source of the data. (You can see more detail in this page from the HV Developer Center.) Is this sufficient? Perhaps. What seems to be missing is the logic that controls the workflow between various applications, both what they do to the data and how they use it. Also needed is a formal verification process to ensure that any logic concerning HV data is implemented properly between applications, which is not mentioned on the HV Going Live! page.
The first red flag for the FDA regarding HV is the Connection Center (CC). Here data is acquired from medical devices, and if that data is to be used in rendering a diagnosis or guiding therapy (clearly the case with hypertension, diabetes and other chronic diseases) then CC meets the legal definition of a medical device. Presently, the FDA does not actively regulate products like CC, although there are examples of standalone connectivity products and features similar to CC that are built into broader based products that have received the FDA's premarket approvals. The regulatory risk for Microsoft is that the FDA could change its position and recall the product until it receives premarket approval. This change could result from political pressure (Congress or advocacy groups), adverse publicity from reports of patient injuries or deaths, or if Microsoft markets HV (or HV CC) in a way that gets the FDA's attention.
Regardless of the FDA's potential interest, the real issue is provider confidence. If Microsoft cannot demonstrate its ability to ensure the safe and effective use of data on the HV platform, then HV will never see much adoption. Such uncertainties could also dissuade vendors from incorporating HV if they feel that providers won't adopt.
There are many important contributions that HV can make to health care, and Microsoft is off to a good start. As a beta product there are still a few gaps to fill.
See previous Microsoft HealthVault posts here and here. Pictured right is the futuristic HealthVault logo.
Recent Comments