Friday, October 02, 2009

Can Microsoft Healthvault Do a Better Job than HL7?

Part II of the Wolandscat series on "The Crisis in E-Health Standards" continues the argument of Part I, discussed already here, to the effect that software engineers should be the ones engaged in building e-Health standards -- and not (for example) quasi-governmental committees involving members with 'limited engineering skills' and utilizing a methodology based on democratic votes. The task, as should by now be clear, is orders of magnitude too complex to be left to committees and to committee votes.

But there is a worry which arises in connection with this general strategy, which is that software engineers -- even when given all the resources they need, and even when walled off from committee interference and popularity contests -- often seem to produce work that is affected by the very same confusions about which Wolandscat himself is complaining. Consider, for instance, the Microsoft Healthvault list of Health Item Types, which informs us that:

Allergic Episode is an occurrence of an allergy which is defined by the Allergy type.symptoms

At the same time we are told that Allergic Episode inherits Health Record Item, where the latter is defined as:

A single piece of data in a health record that is accessible through the HealthVault service.

Is 'Allergic Episode' so defined really a good name for something that is (a) a single piece of data, that is (b) in a health record that is (c) accessible through Microsoft Healthvault?

Further examples of Health Record Items provided by Microsoft include: a blood pressure measurement, an exercise session, or an insurance claim. But is a blood pressure measurement or an insurance claim or an exercise session truly a good example of a 'single piece of data'? Are any of these things data at all?

A potentially even more serious problem for Microsoft turns on the fact that the definitions offered on this page by its engineers are static programming class definitions -- suggesting that their authors think that they can create a representation of the medical domain by means of a monotonically growing set of classes deployed in software. But medicine is constantly changing in polydirectional ways, and software conceived along the given lines will be so sensitive to such changes that it will require constant maintenance, re-testing and re-deployment.

If, therefore, much HL7 standards-building offers evidence of a lack of overarching software infrastructure that could make the standard work in any kind of serious deployment, so the Microsoft material on the Healthvault pages is evidence of an equal and opposite lack of understanding of the domains within which such deployment would need to take place (vast and changing content; complex semantics).

As I am sure Wolandscat would agree, the real need, if we are to get all the separate pieces of this gigantic puzzle to work together, has to be an organisation that is something like a mini-university, or a cross between a university and a company (to avoid becoming detached from reality) involving at least: ontologists, software engineers, medical domain experts, and persons with experience of and a track-record of success in implementing and brutally testing healthcare IT systems in real-world environments. The organisation should have cross-disciplinary mechanisms that force each kind of person involved to understand the outputs and meaning of the others' work. And this work should be implemented in tools -- not just in its vision -- and subject to rigorous real-world testing in advance of any eventual release in the form of 'standards'.


XML4Pharma said...

Dear Barry,

Although I am not an ontologist, I also have doubts on HL7-v3. Mine are more related to their use of XML technology.
I do not know whether you have ever had a look at OpenEHR, which uses archetypes.
If you have, do you think they are doing a better job seen from the ontology side?

Barry Smith said...

Reponding to XML4Pharma:
I have a generally positive opinion of OpenEHR. They have not, as yet, made significant progress towards ontological coherence. Unlike what still seems to be the case in the HL7 community, however, they have recognized the need for improvements in this regard.

Phil said...

Seems like lots of wheel-reinventing going on in Microsoft.

What's wrong with using the SNOMED CT ontology?

Spero melior said...


The problem with SNOMED CT is that it makes some of the same fundamental mistakes / confusions as Microsoft.

For example, SNOMED CT says that a disease is a finding. Well, diseases exist whether anyone finds them or not.

For example, if archaeologists find that an ancient pharaoh had osteoarthritis, then it is not the case that the osteoarthritis came into existence when the archaeologist found it. In other words, the disease is a different thing than a finding of the disease. For one, they happened thousands of years apart.

So, SNOMED CT is confused when it says Disease isa Clinical finding.

Tim Miltz said...

Late to the HealthVault / HL7 talk here but might as well chime in with my insights.

I think Microsoft HealthVault offers at the moment less inter-officer/facility B2B, B2C communication, however there is great potential for C2C - patient to patient communication proxy of HealthVault.

I have for some time been interested in seeing an opt in program by patients that can have their symptoms, medications, treatments shared and matched with other patients, I think that kind of automated cross correlation of data can help remedy some diagnosis - or mis-diagnosis.

I have faith in MSHV, the quest is, does MS have faith. HL7 has SO much momentum behind it, decades, and hundreds of thousands of developers over the years. Microsoft is more of a centralized hub here and will have to strive hard to entice HL7 operations to move over.

One thing many HL7 developers do is migrate one HL7 system to another, so if Microsoft could up their game on automating import of HL7, they might have a better chance.

I really think MSHV, on a global scale can change the health of everyone on the planet for the better.

Tim Miltz