Dear Ed,
Thanks for your clear and frank contribution to this discussion. Although I don't always agree with the boldness of Tom's remarks and I'm one of those people with 'little competence' (although I tent to think that I understand what is being engineered), I can understand his frustration as well. It's difficult if you try to reach something that you feel is being blocked just because people don't see what you're doing and as a result they choose somethings that looks sufficient today..... Looking through this frustration, wouldn't you agree that an ideal international standard on datatypes should be about a set of clean, clear core data types 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 If no, how would your ideal standard look like? If yes, how could we go about to establish this is the near future? Cheers, Stef Op 7 nov 2010, om 01:33 heeft William E Hammond het volgende geschreven: > Interesting comments. It is interesting that the ISO standard was approved > by HL7, CEN and ISO. > As to why we fix the problems of ISO 21090 on HL7, someone else will have > to address. As far as I know, HL7 actually does not even vote on ISO > standards. I must admit that I hoped at times the differences could be > resolved. I guess the differences are so fundamental that we can't find a > path to harmonization. Maybe some other group with the biases that we have > can help resolve the situatiuon. I am interested in seeing things brought > together. I think if we don't, neither of us will enjoy success at a level > we would like to see. More importantly, I think we won't meet the > requirements of the global HIT community without trying to find a solution > to the differences. I think, and I know you don't agree, that some of the > differences are matters of opi ion - a different way of doing things., I > am using data types for ISO 21090 without any problems. I may be to dumb > to appreciate the difficulties. I do admit that I am not using every data > type. > > In any case, the best to you. I thnk openEHR has made major progress and > is becoming an influential organization. I do enjoy some of the > discussions on this list server. I am, believe it or not, learning some > new things. Thanks to these discussions. > > Best. Looking forward to seeing you all in January. > > > > W. Ed Hammond, Ph.D. > Director, Duke Center for Health Informatics > > > > Thomas Beale > <thomas.beale at oce > aninformatics.com To >> openehr-technical at openehr.org > Sent by: cc > openehr-technical > -bounces at openehr. Subject > org Re: ISO 21090 data types too > complex? > > 11/06/2010 05:36 > PM > > > Please respond to > For openEHR > technical > discussions > <openehr-technica > l at openehr.org> > > > > > > > > Hi Ed, > > well since you asked ... my list of problems, from a cursory examination: > The model is defined such that all data types inherit from HXIT and > then ANY, which contain 7 attributes specific to HL7v3 messages. This > means that any other types, such as BL (Boolean) inherits these > attributes. This is a basic modelling error, since the normal > approach is to separate context-specific attributes (e.g. specific to > the use of data values in messages, but not other uses) into > ?wrapper? classes. The practical effects of this modelling are > twofold: > There is not a close correspondence between the 21090 idea of > ?ANY? and the typical Any/Object or other root class of most > object-oriented type systems ? this name clash would have to be > resolved in some way; > an implementation of the 21090 data types is forced to have > HL7v3 specific attributes in its base classes, and it also > complicates the use of more orthodox modelling for such > purposes; > alternatively to produce a version of 21090 for use outside of > HL7v3, a ?profile? of some kind has to be developed by ISO > and/or CEN. > It includes ?types? for name and address that are really > compositional structures, and would normally be considered to be > archetypable or otherwise configurable structures consisting of > lists, trees etc of primitive types (String, Integer etc); (this > problem has been around forever in HL7. I was in CEN meetings in 2002 > or 2003 when people were complaining about this. It might make sense > for HL7, but it doesn't in more generic modelling frameworks) > It uses a modelling notion called ?flavours? defined via ?common > constraint patterns on existing datatypes?, whereby e.g. the > timestamp type TS can be constrained to TS.CA.BIRTH, i.e. a variant > used in Canada for recording birth dates. The problems with this > approach include: > is that it is not supported in any standard industry UML or > related tools (e.g. Eclipse Modelling Framework); (It is sort > of doable in OO languages, but it breaks the normal spirit of > OO modelling, and is not conducive to maintainability) > class-names containing the ?.? character are not legal in most > type systems; > it is not generally known or understood by IT practitioners; > it is not clear how such ?constrained types? should be > implemented in normal object-oriented development technologies; > it mixes the concept of localised constraint that would > normally be defined outside of the software, with ?hard? data > types that would normally be implemented in the software (e.g. > TS would normally be implemented in software, but implementing > ?Canadian birthdate? is likely to make software brittle). > Due to the above problem, date/time types typically needed in > clinical data, and archetypes, are defined using types: TS.DATE, > TS.DATETIME, although there is no match for the logical type > ?Duration? or ?Time?. > The error of including context-specific attributes within base types > occurs elsewhere in the specification. To give two examples: > The type TEL (telecommunications address) includes the > attribute ?useablePeriod?, intended to indicate when the > address is useable. Normally such a context attribute would be > found within a context specific information structure > representing ?Contact? or some other typical demographic > concept in which not only the date range, but also type / > purpose (e.g. ?business?, ?home?) might be recorded. 21090 > forces it to be in every instance, although it presumably can > be empty (as is likely in most instances). > The type II (instance identifier) includes the coded attribute > ?reliability? which indicates whether the identifier was > ?issued by the system?, ?verified by system? or ?unverified by > system?. > The modelling style seems to follow the strange HL7 obsession with > non-object orientation, popularised in the RIM. In summary, I don't see > 21090 as being at all appropriate for the title of the standard, which is > "Health Informatics ? Harmonized data types for information interchange". > Instead, it should just have been called "Data types for HL7-based > messaging". It doesn't make sense as an ISO standard; it is really an HL7 > standard. > > - thomas > > On 06/11/2010 18:39, William E Hammond wrote: > I agree with Dqavid's points. > > The world, unfortunately, is not perfect. Understanding how the ISO > data > types standard came into being might be useful in understanding why > it is > as it is. After more than 5 years in trying to get a g;obal standard > for > data type, a group, lead by Graham Grieve, was able to put together a > combination of documents from ISO, CEN, and HL7. The result was an > overwhelming and certainly more than we need or will probably ever > use data > types. > > I would be interested in knowing why this standard is considered to > be > complex. Is it a result on the large number of data types? Is is a > result > of the complexety of some of the data types? > > I would be interested in knowing how anyone would change the simplier > data > types. It seems to me that most of these "primitive" data types are > exactly wahat we have been using for a long time. > > I would suggest that NCI - and others - simply identify what subset > of the > datatypes they propose to use and move ahead. On the o0ther hand, > that > migtht happen naturally out of the full set. If its\'s too complex > or not > useful, it will not be used. > > I agree that everyone haveing their own set does not solve the > problem. If > any set meets my needs, I don't care what else is in the package. > > > W. Ed Hammond, Ph.D. > Director, Duke Center for Health Informatics > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > _______________________________________________ > 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/20101107/c27437cd/attachment.html>
