hi Tom > The only kind of 'profile' I know of elsewhere in other standards is of > the kind 'we only implement x, y but not z'.
which is the kind I'm talking about > The answers Grahame gave me last time I discussed how to profile > 21090 for 13606 use are here, about half-way down. rather incomplete. We really do have to get this done > I happen to know that Sweden, Singapore and the UK have created at least 3 > different 'profiles' of 21090 over time, all to suit their own needs. There > is no guarantee that data or software built on these home-grown profiles > will talk to each other, nor that any of them would talk with software or > data built on the pure 21090 specification. but if they've profiled according to the method above, then they will talk to each to the degree that their requirements match. Solving mismatched requirements is outside the scope of a data types standard. If they've profiled *and mapped*, then it's not so straight forward - depends very much on the quality of the mapping. > This can't be anybody's idea of an easy way to get started with a data types > standard. no, of course, the easy way, is "do it my way", which is a variation of the Not-Invented-Here-Syndrome > There is no escaping from the fact that having a type called 'Any' > representing a concept that should be called something like 'AnyDataValue' > (in openEHR it is DV_ANY) is annoying and has to be dealt with in some way. really? You've not heard of namespacing? It would make that much difference to you to prefix all or some of the types with "DV_" or something? Surely not. Did you read the discussion in ISO 21090 about this point? (It was written specifically for you) (and btw, in my implementation, I did end up prefixing the names, for purely programming reasons) > We had this discussion last week. I made the point that this is > true of IT vertical industry integration standards. I don't believe > Tom offered a counter example to this. > > I have not been tracking other vertical industry ICT standards. But I did > offer a examples of 'stacks' of standards which do not follow the strange > world of HL7 modelling. Everyone else uses normal OO modelling, or else > something accepted like XML schema (admittedly terrible for object models, > but that's another story); but HL7 can't (it instead tries to get OMG to > change UML).? I fail to see why standards in e-health have to be done in > such a bizarre way. There is nothing special about e-health requiring that. you changed the sense. Your original claim was that standards should just pick something that works well enough. My point is that ICT vertical interoperability standards don't work like that, including in health. As Ann pointed out, not everyone uses normal OO modelling, and for a variety of reasons. In fact, big companies are starting to move on - have you seen M (microsoft oslo)? I happen to think that design by constraint - which is the fundamental pattern of both v3 and openEHR - is irretrievably busted, and it's time for us both to move on and find something better. (But perhaps we should spend some time implementing in the real world before we do that...) I'm watching M closely to see if a realistic alternative emerges there. It hasn't yet. And the alternative is to talk to OMG to talk about getting UML changed. But it's odd to have the pot call the kettle black, since ADL is hardly standard UML. Heath: > As an ISO standard, I believe that it should be an intersection of all the > input specifications, rather than a union extension has it's own difficulties, as does union. We were aware of the berlin decision, but ISO 21090 resulted from a deliberate decision to do something different. Was that a right decision? Unfortunately, time won't tell, since the alternatives are purely hypothetical. Grahame
