On verticals and whether "everybody does" UML: The ISO 10303 STEP engineering-domain standard family includes a modelling framework (called EXPRESS) which could, in some not-too-unlikely alternate world, have been adopted by HL7 for development of v3 (the timing was about right). STEP is pretty mature and widely used in its sector, and is, in my opinion and others', technically superior to UML for modelling structural and dymanic aspects of information shared between complex enterprises that deal with conceptually complex information. I guess it wasn't a candidate for HL7v3 simply because HL7 folks (long before I was involved) didn't happen to know about STEP and what it can do... and that was simply because they were working in the health sector & not involved in sectors such as petrochemicals where STEP was in use.
...and BTW I'm not recommending JIC harmonization with STEP ;-) Ann W. Ann M Wrightson Pensaer TG | Technical Architect Gwasanaeth Gwybodeg GIG Cymru | NHS Wales Informatics Service Symudol/Mobile: 07535 481797 Llanelwy | St Asaph: WHTN: 1815 8232 Ff?n/Tel : 01745 448232 Pencoed: WHTN: 1808 8930 Ff?n/Tel: 01656 778940 ________________________________ From: openehr-technical-bounces at openehr.org [mailto:[email protected]] On Behalf Of Thomas Beale Sent: 08 November 2010 21:19 To: openehr-technical at openehr.org Subject: Re: ISO 21090 data types too complex? 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 Cymraeg:- Mae'r neges hon yn gyfrinachol nad chi yw'r derbynnydd y bwriedid y neges ar ei gyfer, byddwch mor garedig ? rhoi gwybod i'r anfonydd yn ddi-oed. Dylid ystyried un rhywd datganiadau neu sylwadau a wneir uchod yn rhai personol,ac nid o angen rhaid yn rhai o eiddo Bwrdd Iechyd Prifysgol GIG Abertawe Bro Morgannwg, nac unrhyw ran gyfansoddol ohoni na chorff cysylltiedig. Cofiwch fod yn ymwybodol ei bod yn bosibl y bydd disgwyl i Bwrdd Iechyd Prifysgol GIG Abertawe Bro Morgannwg roi cyhoeddusrwydd i gynnwys unrhyw ebost neu ohebiaeth a dderbynnir, yn unol ag amodau'r Ddeddf Rhyddid Gwybodaeth 2000. I gael mwy o wybodaeth am Ryddid Gwybodaeth, cofiwch gyfeirio at wefan Bwrdd Iechyd Prifysgol GIG Abertawe Bro Morgannwg ar www.abm.wales.nhs.uk English:- This message is confidential. If you are not the intended recipient of the message then please notify the sender immediately. Any of the statements or comments made above should be regarded as personal and not necessarily those of Abertawe Bro Morgannwg University Health Board any constituent part or connected body. Please be aware that, under the terms of the Freedom of Information Act 2000, Abertawe Bro Morgannwg University Health Board may be required to make public the content of any emails or correspondence received. For further information on Freedom of Information, please refer to the Abertawe Bro Morgannwg University Health Board website at www.abm.university-trust.wales.nhs.uk. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/b6c481e3/attachment.html>
