Sunday, April 15, 2007

The Mysteries of HL7 and Object Oriented Modeling, from Gerard Freriks

(Posted with permission.)

I noticed the following exchange:

Rene: using this argument, all kinds of commonly used payload participations and associations would end up at the entry Act of the static model (whatever that entry Act would be, given that the Wrappers R2 project may introduce a Conversation/Contractual Act as the static entry point). Whilst introducing a common XPATH expression to access the recordTarget, (a) for other things one would still have to go to the payload model, (b) it increases reliance on sender/receiver understanding the inheritance and propagation mechanism thereof in the models - the understanding of which is currently probably limited to a dozen people worldwide. From an implementation standpoint this is not desirable.

Lloyd: Receivers must understand propagation between the wrappers period. That is not optional. Placing patient in a consistent place for all models actually makes implementation easier, not harder. This isn't about "common usage", but rather about data that has specific uses other than merely pertaining to the payload.
If I'm interpreting correctly, one expert (Rene) is of the opinion that the inheritance and propagation mechanism in the HL7v3 models is understood by no more than a dozen people worldwide. This means that only a few persons know how HL7 is deploying Object Oriented Modeling. I don't think that I'm wrong in thinking that millions of people know the Object Oriented Modeling techniques made popular by OMG and UML. Why, then, is HL7 using an abnormal, rather than a standard, way to deal with classes and propagation of attributes? Do they do this in order to ensure that only a handful of people will understand it properly?

Reading Lloyd's reaction, it is clear that he expects all implementers to know what only a handful know.
Poor implementers of HL7v3 artefacts.
My conclusion: A handful of experts has created a very nice niche for themselves to provide valued and needed expertise.

No comments: