Thom, and Tom, It would be nice when CEN could agree with you about the data types needed for EN13606. But twe can't forget the GPICS and the refferal message standard.
Gerard -- <private> -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On Apr 28, 2005, at 10:15 AM, Thomas Beale wrote: > Bert Verhees wrote: > > >> Interesting subject in this email. But it came through >> >> Issue 1: >> >> ----------------------- >> The use of in many programming languages reserved words in the HL7 >> datatypes. >> I am talking about the datatypes: Set, Array. >> ----------------------- >> >> > Hi Bert, > > almost all the issues you mention in this thread are actually due > to the HL7 data types, which CEN unfortunately decided to adopt/ > adapt a long time ago. Tom Marley and others have struggled to find > an version of them which a) remains faithful to the idea of HL7 bu > b) fixes some problems, like strange inheritance. Personally, I am > much more straighforward;-) I don't find the HL7 data types a good > design at all, generally, and have made available the reasons in > various standards discussions, along with many others who have > pointed out the same problems (such as you are now doing). The > result of this recently has been: > > - an new ISO work item called "data types for clinical > informatics" (or something very close to that), whcih will > recognise 3 layers: inbuilt types (like in ISO 11404), general > purpose clinical types (specified from requirements), and a 3rd > layer for bindings to particular model systems, such as HL7. THis > work would avoid name clashes and other problems prevalent in the > HL7 data types. The part 3 should be part of the HL7 ISO standard, > not the ISO data types standard (for reasons of sensible managing > dependency, and just out of relevance), but HL7 of course wanted to > put its specifications in the main new standard. > > - CEN is now in a position of having to determine what the data > types should look like for EN13606. In theory, they should be part > 2 of the standard-to-be I mention above. > > In practice, the data types required for EN13606 is not a hard > problem. The total list for all structural attributes is as follows: > > - string (= ISO11404 CharacterString) > - date_time (in ISO11404) > - object_identifier (in ISO11404) > - boolean (in ISO11404) > - a multimedia type (probably = an Array<Octet> in 11404) > - coded_text (not in 11404) > > No substitutability is needed as far as I remember. So this list is > very short, simple, and available in any object-oriented language. > (Personally my recommendation to CEN is to define a set like this > as the structural datatypes right now, taking them from layer 1 of > the new ISO standard, which is more or less ISO11404. only the > CodedText type needs to be added. This could be done easily, and > while avoiding the problems of the HL7 CD etc types, such as > qualifiers.) > > The next set of data types that is required is those which inherit > from DATA_VALUE, which is the type of ELEMENT.value. This list is a > lot longer, and has substitutability rules: > > - Date, Time, Duration, Date_time > - Partial dates and times > - Text (with language) > - Coded Text > - Quantity, Quantity Ratio, Quantity Range, Count > - Identifiers of real world entities > - Boolean/Bistate > - State > - Ordinal > - Time specification > - Uri > - Encapsulated Multimedia > - Parsable > > This is the list of types I would see being developed as part 2 of > the new work item in ISO. For the moment, openEHR has a pretty > reasonable list of types which correspond to these, which could be > used, although that would be up to CEN to decide. > > >> It is in some popular languages not possible to use some words to >> define your own datatypes, or parts of the datatypes. >> This makes it impossible to use the standard in that language as >> it is. >> >> A standard should be platform-independent (OS, programming- >> language), that is why I think it is an important issue >> >> I worked around the issue by naming those types: HL7Set, HL7Array, >> and for consistency, I named the other Collection-types also >> HL7... (HL7Bag and HL7List). >> >> > That is about what you have to do for the moment, in in fact, in > part 3 of the new ISO standard, where there will be an HL7 binding, > such names will have to be used. > > - thomas beale > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050528/b5de9fcc/attachment.html>
