Antw: Re: CEN meeting and data types
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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20070225/1316adda/attachment.html -- next part -- ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
Antw: Re: CEN meeting and data types
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-clinical_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
CEN meeting and data types
hey Sam I'll bite ;-) but the openEHR data types are ready for archetypes and the cluster element (leaf node) architecture. it you want, we can go round and round on semantic issues. Always a pleasure ;-). But is there anything specific that makes you think that it would be inappropriate or unwise to use the iso datatypes in the document with 13606? (so not including general issues) Grahame Sam Heard wrote: Dear All I have been at the CEN working group meetings representing Standards Australia. It is clear to me that CEN needs to take on the openEHR data types in order to progress quickly. The ISO data types are likely to be appropriate for the HL7 environment and will map to openEHR - but the openEHR data types are ready for archetypes and the cluster element (leaf node) architecture. You can have a look at the ISO data type proposal likely to come through HL7 soon at: http://informatics.mayo.edu/wiki/index.php/ISO_Datatypes user name: wiki password: wikiwiki It will be helpful to make your views known on this list. Cheers, Sam -- o ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
CEN meeting and data types
Grahame Grieve wrote: hey Sam I'll bite ;-) but the openEHR data types are ready for archetypes and the cluster element (leaf node) architecture. it you want, we can go round and round on semantic issues. Always a pleasure ;-). But is there anything specific that makes you think that it would be inappropriate or unwise to use the iso datatypes in the document with 13606? (so not including general issues) I guess it depends on what CEN wants to achieve, and also what the implementation state and intention of the ISO types is. Possibilities I see: * Let's say that the ISO types provide a set of types whose purpose is to facilitate data type conversion between HL7 HL7-like (e.g. various flavours of v2, v3 etc), openEHR, others (UN-cefact? ASTM? etc). Then the kind of implementations will be limited to XML conversion. * On the other hand, if they were used as real data types, say in CEN, then there is now the job of implementing them in all the major technologies and testing them. Plus they need to be checked for use with archetypes. * If CEN used the openEHR data types, they get something implemented in Java, C#, Eiffel, XSD (others?), that are heavily debugged and in production use now, and for which the constraint semantics and syntax are already known and tested in ADL. This includes constraint types for String (C_STRING), Integer (C_INTEGER), Date (C_DATE)..plus specialist constrainer types for DV_ORDINAL (C_DV_ORDINAL), DV_QUANITTY (C_DV_QUANTTY) and CODE_PHRASE (C_CODE_PHRASE). These have all been tested and are known to work, and numerous archetypes have used them. Also, the openEHR data types are founded on existing standard data types (ISO11404), and assume the standard semantics for all the usual built-in things (String, Integer, Boolean, Array, List,...) plus the ISO8601 date/time types (Date, Time, etc) 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 ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
CEN meeting and data types
Thomas, I agree with you that in the case CEN (13606) adopts the OpenEHR data types they know that it is proven technology. Just now, when any moment CEN/tc251 EN13606 will get published, we dearly need proven data types to implement it. In the case that CEN will make the choice for OpenEHR, my remaining questions are: What harm is done? How can CEN/tc251 EN13606 be aligned, some years from now, with the forthcoming ISO data type standard? Can it be aligned? Or can't it? 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 22-feb-2007, at 11:27, Thomas Beale wrote: Grahame Grieve wrote: hey Sam I'll bite ;-) but the openEHR data types are ready for archetypes and the cluster element (leaf node) architecture. it you want, we can go round and round on semantic issues. Always a pleasure ;-). But is there anything specific that makes you think that it would be inappropriate or unwise to use the iso datatypes in the document with 13606? (so not including general issues) I guess it depends on what CEN wants to achieve, and also what the implementation state and intention of the ISO types is. Possibilities I see: * Let's say that the ISO types provide a set of types whose purpose is to facilitate data type conversion between HL7 HL7-like (e.g. various flavours of v2, v3 etc), openEHR, others (UN-cefact? ASTM? etc). Then the kind of implementations will be limited to XML conversion. * On the other hand, if they were used as real data types, say in CEN, then there is now the job of implementing them in all the major technologies and testing them. Plus they need to be checked for use with archetypes. * If CEN used the openEHR data types, they get something implemented in Java, C#, Eiffel, XSD (others?), that are heavily debugged and in production use now, and for which the constraint semantics and syntax are already known and tested in ADL. This includes constraint types for String (C_STRING), Integer (C_INTEGER), Date (C_DATE)..plus specialist constrainer types for DV_ORDINAL (C_DV_ORDINAL), DV_QUANITTY (C_DV_QUANTTY) and CODE_PHRASE (C_CODE_PHRASE). These have all been tested and are known to work, and numerous archetypes have used them. Also, the openEHR data types are founded on existing standard data types (ISO11404), and assume the standard semantics for all the usual built-in things (String, Integer, Boolean, Array, List,...) plus the ISO8601 date/time types (Date, Time, etc) 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 ___ 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-clinical_lists.openehr.org/attachments/20070222/34fb2ebf/attachment.html -- next part -- ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
