Following this debate is for me more interesting than a tennis match, and, in my opinion, it is advantage-Beale.
Randy Neall On Fri, Nov 19, 2010 at 5:44 AM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > On 19/11/2010 05:49, Williamtfgoossen at cs.com wrote: > > Hi all, > > Given this discussion on ISO 21090 I would like to bring forward the > following: > > 1. Every international standard is and has to be based on political > decisions: all member countries have to be accepting it and hence will want > to get something specific out of it, or block too difficult parts. > That is the way of standards making, in contrary to what a group of friends > like in OpenEHR foundation can do. This has nothing to do with committees > working in the implementation space or sitting at a table. It is how formal > democratic voting goes. Not a perfect system we know, but apparently chosen > above totalitarian approaches. > > > I do hate to bring this up, but in the entire rest of existence, all > engineering (i.e. all creation of technical artefacts) is done by > 'totalitarian' approaches. If you know the person who would travel on a > plane built by 'democracy' rather than engineering, please introduce us... > > This democratic development (inclusive of all parties concerned, and voting > by members) has been and is still the case for ISO 21090. > The same democratic and transparant voting procedure by members is used in > HL7 international (of course the membership is organised different from > ISO). > > 2. The use cases for ISO 21090 do come from different sources: an older > basic data type standard from ISO, clinical use cases, CEN standards, in > particular the one on archetypes (13606-2), AND HL7 among others. The > resulting set is accepted by the ISO membership, and indeed the HL7 > membership, referring to it as datatypes R2 (and facing an enourmous piece > of effort and work to redo a lot of the models and messages due to the > harmonisation). And under the JIC, also the CDISC organisation deals with > this since ISO 21090 is part of the joint harmonisation work. I think the > willingness of the different JIC partners to step beyond their traditional > route and harmonise this formidable and fundamental work is the most > important achievement in the last 25 years of international standards work. > I would like to compliment Grahame in particular that he managed to get a > useful, albeit say 96% "perfect" standard out of this. > > > I don't have a problem with the fact that use cases have been researched, > indeed that is an excellent achievement. I have a problem with the way the > standard has been created on that basis; it tries to do way to much, > incorporating all kinds of special cases that should not be included in the > core generic data types standard. Such use cases can be accommodated in one > or more separate 'packages' that show how to use the core classes for the > specific purpose, and what extra classes are needed to formalise other data > specific to the use case. > > > > 3. No standard or specification can be perfect. In particular, Tom's work > might be closer to perfection than the ISO 21090, but that is hypothetically > a matter of a percentage between 96% and 97.5% on a VAS of 0 - 100%. I > personally are pragmatic, I need in Detailed Clinical Models and in HL7 v3 > Care Provision message implementations about 20 - 30% of the ISO 21090, so > do not bother about the rare use cases addressed. > > > no, no, no... wrong argument William! It is not about being on a sliding > scale of good / better / perfect! This standard is in a different place > altogether, 'designed' according to different permises, specifically that it > should try and cover all known use cases in one standard. It is trying to do > way too much, has numerous formal attributes and natural language guidelines > not applicable to most use cases. It is built according to the wrong-headed > HL7 notion of modelling which is: put everything in at the top/centre and > profile it out later. Firstly this breaks basic rules of maintainability, > encapsulation, etc, secondly, it is going to really damage the uptake and > usefulness of this standard! Just like software and models based on the > HL7v3 RIM, where NO TWO IMPLEMENTATIONS CAN COMMUNICATE, this will be the > same. > > > > 4. Core principle behind the standard is that you create a profile around > it that allows you to implement it in your system, or your message, or your > datawarehouse or whatever. There is usually no way to have it 100% ready for > use. The example from the blog that Tom talks about, where ISO 21090 is > mapped into their own CDISC models is almost perfect. That is the way to go. > Yes it will include mappings from ISO time format to XML time format. But if > that works well on implementation, at the exchange level you are compliant. > > > mappings are unavoidable with standards. But having to do this 'profiling' > with every HL7 standard is nonsense - having to decide which attributes I > don't need, which ones I can set to 0 or Nil, or False, or some other > special value.... just think about the combinatorial complexity of all those > decisions over an object with 10 data fields! ANd then multiply that by the > number of organisations having to make those decisions. > > > > 5. If you adhere to ISO 21090 / conform to it / there is always the option > to limit your implementation set. E.g. refer to particular chapters or codes > in ISO 21090. > > > particular chapters, particular classes, particular attributes, but only in > specific circumstances.... the 'profiling' work has to be done all over the > place, so even when the standard is fully accepted, noone except HL7v3 > message people can directly use it! It doesn't even make sense in its > current form for CDA! (And I forgot to mention it is full of CDA specific > stuff which also makes no sense being in a supposedly generic standard). > > > > 6. It looks from Tom's objections that OpenEHR cannot adhere to data type > standard ISO 21090. Is that a problem in the OpenEHR specifications, or is > that a problem on political level: we do want to invent our own because it > is closer to perfection? What I mean here is: if I create archetypes in > OpenEHR spaces (there are about 25 in Dutch available pending other issues > to be solved before releasing). And from this system I need to exchange HL7 > v3 messages in the Dutch national switshboard space, will I be in trouble > because the OpenEHR archetypes cannot handle even the basic ISO 21090 > datatypes? > > > openEHR can handle all of the data types conceptually, that isn't the > problem. The mapping, just like for everyone else with a normal kind of > object model, will be painful because of the irrelevant stuff in ISO 21090, > and annoyances like TS.DATE, and numerous other details. But, *much more > importantly*, which profile should openEHR map to? Some core profile? A > 13606 profile? A CDA profile? A v2 profile? an NHS profile? The Sweden > profile? How many mappings will we need? Remember, archetype designers don't > care about which specific way the archetypes might be deployed - in > messages, on a screen etc, so any attributes specific to those uses won't > make sense. Do we need an 'archetype' profile of 21090? > > Please have a look at this specification: openEHR Support Information > Model > <http://www.openehr.org/releases/1.0.2/architecture/rm/support_im.pdf>- > the section on 'Assumed types' shows how little openEHR assumes about > underlying basic types. On top of that, it builds a core set of data types > that have no attributes relating to messaging, null flavours, or obscure use > cases. All of that latter is handled in contextually sensible places. Normal > object models created according to normal design principles always end up > like this. ISO 21090 doesn't, because it follows the HL7 > include-everything-then-profile approach. > > - thomas* > * > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101119/2b8aad22/attachment.html>
