hi Tom I'm not going to get into a long debate here about modeling philosophy. I'll respond with brief points to each of yours, and then I'll shut up. Other people can take it further if they want.
> they might well be; my original question was: is this the only possible > reaction (these data types are complex, untested and risky); is there no > standard that could have been written to get a better reaction? > I contend that there is. * perhaps, but not a political reality > a few people realise this, but not many. Most think that the title "Health > Informatics ? Harmonized data types for information interchange" implies > interchange between any two layers of software, systems or whatever, and the > first thing they do is try to implement these types in their system and you can. but I wouldn't and don't use them *as is* for persistence. Nor would I use the OpenEHR data types, and for the same reasons. If I normalised them, would I use them? Yes, I would and do. I do agree that users need training to understand how not to use them. Perhaps, one day, I shall write a book about that. But this is also true for openEHR, though perhaps less true. > a set of clean, clear core data types - no context information like > 'updateMode' or null flavour etc. and mostly the first thing people do is profile this right out. Which NCI have done, btw. > The context specific stuff is specific to HL7 only. It just doesn't apply > elsewhere. not at all. And I'm surprised you still think this. HXIT is to do with capturing and managing foreign data. As is some of the II stuff. It doesn't and won't arise in an EHR system for internal data, but it will for imported data. So where it does arise is not HL7 specific. Flavors are a ISO 21090 thing. And optional - they aren't in the schema, for instance. Update mode is transactional. Almost everybody will profile it out. > The model is defined such that all data types inherit from HXIT and > then ANY, which contain 7 attributes specific to HL7v3 messages. no., specific to messy data and/or transactions. Putting them there certainly has problems, but it has benefits too. > There is not a close correspondence between the 21090 idea of > ?ANY? and the typical Any/Object or other root class of most > object-oriented type systems ? this name clash would have to be resolved in > some way; It appears I will have to keep repeating this until I am blue in the face. It is not a name clash, nor does it (or should it) correspond to a root class in any other system - it is it's own class. The fact you think this indicates that you are totally confused as to what ISO 21090 is. (Hint: look at how you modeled your own data types...) > HL7v3 specific attributes in its base classes complicates the use of more > orthodox modeling for such purposes; absolutely. If you modeled handling those things elsewise, it complicates matters. > alternatively to produce a version of 21090 for use outside of HL7v3, a > ?profile? of some kind has to be developed by ISO and/or CEN. it's not hard to do, it's anticipated, it's widely done. And we should do it for CEN. I was going to collaborate with Dipak to do exactly that, but we haven't got around to it. > It includes ?types? for name and address that are really compositional > structures, and would normally be considered to be archetypable so, archetype them. We expect it to be done. I fail to see your issue here. > It uses a modelling notion called ?flavours? defined via ?common constraint > patterns on existing datatypes?, which is not supported in any standard > industry UML or related tools (e.g. Eclipse Modelling Framework); no. It's just design by contract. When they give us real design by contract tools, then we'll be able to leverage that. In the mean time, it's a way to give the designers a fantasy that they are making meaningful statements that will be ignored in real life. Of course you don't like that (can you guess that I don't either?). > there is no match for the logical type ?Duration? or ?Time?. PQ.Time, or PQ with a unit of time > The type TEL (telecommunications address) includes the attribute > ?useablePeriod?, intended to indicate when the address is useable. I agree. it would be better elsewhere. But it's not a big deal is it? > The type II (instance identifier) includes the coded attribute ?reliability? > which indicates whether the identifier was ?issued by the system?, > ?verified by system? or ?unverified by system?. yes, which turns out to be useful and important (even for openEHR, outside identifiers managed by openEHR. I guess it will come up eventually). You could put it somewhere else, but it's going to have to go somewhere. > The modelling style seems to follow the strange HL7 obsession > with non-object orientation, popularised in the RIM. which indicates that you don't understand the RIM or the data types, and how they differ. Grahame
