On 08/11/2010 18:51, Grahame Grieve wrote: > hi All > > A roll up of comments: > > 1. ISO 21090 is often (always?) profiled > > It seems remarkable to me that people think it's a problem that ISO 21090 > needs to be profiled. Who would've guessed that a full standard that meets > many requirements is simpler to implement if you profile out the features > that reflect requirements you don't have? I'm pretty sure that this is true > of every other standard as well. It's certainly true of all my implementations > of W3C, IETF, and OMG standards.
I know that in HL7 this profiling is normal. The only kind of 'profile' I know of elsewhere in other standards is of the kind 'we only implement x, y but not z'. In other words, choosing a subset of classes or features to implement. As soon as one has to actually chop up the classes in a model however, we are on different ground. The answers Grahame gave me last time I discussed how to profile 21090 for 13606 use are here <http://www.openehr.org/wiki/display/stds/openEHR+to+ISO+13606-1%2C+ISO+21090+mapping>, about half-way down. As you can see, it was not 100% clear on a cursory inspection what exactly the profile version would look like. As Grahame has said, this is still to be done properly with Dipak. This means that official users of 13606, e.g. Sweden, can't actually use the standard out of the box, and do not have any official version to use until that work is 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. So in fact, we have N pseudo-standards, and no real standard. This can't be anybody's idea of an easy way to get started with a data types standard. > 2. Some people have responded vehemently to Tom's initial comments > > I suppose I'm a little guilty. I don't mind people criticising ISO 21090. > Other's people's list of criticisms will never be as a long as mine. But > it's frustrating to respond to the same wrong comments repeatedly, > especially when the come from people who are widely and rightfully > regarded as genuine experts Note that I am not particularly making criticisms as if it were me personally trying to address the problems; I am mainly reflecting common responses from others, e.g. in government departments, universities and so on. 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. > 3. In health informatics, standards are done differently. > > 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. > 4. The ISO process is flawed > > Yes. As is every other process, each in it's own way. well yes and no... there are different categories of flawedness.... in e-health, the paper standards bodies a) 'design' technical artefacts by (randomly self-selected) committees, b) take many years to ratify them, c) don't validate them properly and d) don't maintain them in any meaningful time period. Engineering processes (i.e. requirements capture, analysis, design, implement, test, deploy, maintain - all with feedback loops - by technically competent people) are also flawed, but usually only in minor ways. We still feel safe getting into an aircraft designed by an engineering process. Hardly any modern aircraft fall out of the sky due to engineering faults (the current problem with the Rolls Royce Trent 900 engines shows just how far you have to push the boundaries before any kind of serious problem occurs).* I still contend that we can do much, much better. * - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/600e36af/attachment.html>
