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
