Grahame,
On 06/11/2010 21:17, Grahame Grieve wrote:
> hi Tom
>
> David's points are right on the money. The heart of the matter
> is "not invented here".
they might well be; my original question was: is this the only possible
reaction (these data types are complex, untested and risky); is there no
standard that could have been written to get a better reaction? I
contend that there is.
> A related issue is the fact that the
> ISO 21090 data types are optimised for exchange, not storage
> (explicitly a statement in their scope), but the NCI scope includes
> storage - which raises hard questions about normalization
a few people realise this, but not many. Most think that the title
"Health Informatics ? Harmonized data types for information interchange"
implies interchange between any two layers of software, systems or
whatever, and the first thing they do is try to implement these types in
their system. I guarantee it is the first thing they do... we have seen
the same thing with 13606 and CDA - both designed for exchange, and the
first thing people do is to implement them in their systems, where they
don't work properly.
One of my big problems with 21090 is in fact that since it is natural
for people to only want to do things once, what should have been
specified as an ISO health informatics DT standard should have been:
* a set of clean, clear core data types - no context information
like 'updateMode' or null flavour etc.
* a set of wrapper types designed to use the core types, optimised
for messaging
* other sets of wrapper types as needed, optimised for other
specific purposes, e.g. storage or whatever
This would really have helped. But instead we have almost the exact
opposite: a single spec with everything bound in, requiring reverse
engineering for use in non-HL7v3 circumstances.
Note that the core types would satisfy the 'data types for interchange'
need in most cases (e.g. in EN13606). The context specific stuff is
specific to HL7 only. It just doesn't apply elsewhere.
> The implicit message you have is that "therefore openEHR data types are
> better", whereas the openEHR data types share pretty much the same
> basic shape as the ISO data types in regards to the issues above (in
> fact, the overall differences are minor, mainly related to philosophical
> issues about modeling philosophy, and a few small ones about requirements)
I wasn't trying to say anything about the openEHR DTs actually, and you
are right, they don't really do anything much different from the 21090
ones. If I was to say something, I would say that they are a lot easier
to understand and implement directly into software, because their design
is a) context-free and b) more object-oriented.
But I really have no problem with an international standard for
shareable data types in e-health that is different from openEHR, or
anyone else's favourite / private model. I just think that 21090 is not it.
> I use ISO 21090 in my commercial products. My take is somewhat
> different than this : it works fine for it's purpose - of course, how
> could it be otherwise? It certainly carries complexity, but this is
> inherent in the problem space. I do have a personal list of snits
> about what I failed to achieve with ISO 21090, which manifest in
> practical issues when implementing. But perfection is to be found
> in the next life.
some of which I am aware of, and I am in no way criticising your work on
this. But let's face it, all this ANY and HXIT and AD/ADXP/EN/ENXP are
pure HL7 stuff. They are not needed in a core international data types
standard. Perfection is not some unattainable thing in the infinite
future; most of what counts as imperfect in most standards is the result
of rational arguments lost in committees full of people with little
competence to understand what is being engineered, or the downstream
consequences. Indeed, if we removed that mechanism from standards
development alone, the quality of all e-health standards would probably
double. Nearly all so-called imperfections are simply own goals and
self-injury, and I for one don't see that as an acceptable state of affairs.
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101106/7ec012eb/attachment.html>
