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'.