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* * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101119/f62a82ba/attachment.html>
