Dear all, We need to be careful.
Wiki defines: Built-in abstract data types Because some ADTs are so common and useful in computer programs, some programming languages build implementations of ADTs into the language as native types or add them into their standard libraries. For instance, Perl arrays can be thought of as an implementation of the List or Deque ADTs and Perl hashes can be thought of in terms of Map or Table ADTs. The C++ Standard Library and Java libraries provide classes that implement the List, Stack, Queue, Map, Priority Queue, and String ADTs. The rest are other things, other 'types of data types' at best. Artefacts that need a proper definition and scope before we use them in an argument. What CEN, HL7, OpenEHR and ISO need is an agreement about the ADT's they basically need. Plus the next level (layer) of other artefacts they need in the models that are deployed using the set of agreed ADT's. CEN is using the term 'CEN Data Types' for these. It is a mixture of CEN specific definitions and ADT's. HL7 is using the term 'Abstract Data Types' for their CEN-like collection of artefacts. Even Addresses and Telephone numbers are part of there scope. Here I sense (one of several) confusions created by terms used in the HL7 community and products. On top of all this there are artefacts (Archetypes/Templates) that are the leaf-nodes in that context and we must never use the term data type for those. Data types 'live', are defined, have a scope, in the ICT world of programming languages and databases. The leaf nodes in archetypes and templates are defined at the healthcare level. In no way they can be considered 'data types' and must classified as such. The way archetypes and templates are expressed in ADL contain real data types' since this is the ICT-world. It is for these reasons that the contribution by William confuses me. Things are getting mixed up. Creating problems. With regards, Gerard -- <private> -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On 25-feb-2007, at 9:41, Williamtfgoossen at cs.com wrote: > In een bericht met de datum 22-2-2007 11:36:46 West-Europa > (standaardtijd), schrijft Thomas.Beale at OceanInformatics.biz: > > >> Now, since CEN is an archetype-enabled standard, it might make >> sense to >> use data types that are known to work in software and known to >> work for >> archetypes. >> >> So one question is: what is the intended use of the new ISO date >> types >> (conversion, or to be the 'real thing')? Secondly, how will CEN >> EN13606 >> be validated with a new set of data types? >> >> - thomas beale > > > Good points / questions, > > my 2 cents on this: > > I would like to distinghuis between the few datatypes that are > basic and work in software, in archetypes, in HL7 v2 and in HL7 > v3, not much but there will be several, and the ones that are > technical implementation specific. From clinicians point of view > then most day to day data will be represented and they will not > have to worry about unimportant technical details (unimportant > because smart technicians have found conversion methods to deal > with it). > > imho the ISO standard should define the generic real thing. Integer > is real, string is real, OpenEHRstring is one technical artifact > derived from real thing to work in some software. Next, it should > facilitate in preventing battles to make conversions possible. > > This can only be solved if we step back from the technical data > specification and use the clinical data specification as point of > reference, map from there to CEN, Open EHR, ISO, HL7 v2 and v3. It > is like the standards, no explosions wanted. > > Hope this helps, > > William > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://www.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/20070225/9c078b48/attachment.html> -------------- next part -------------- _______________________________________________ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
