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-technical_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
