Dear friends, My thoughts on this debate wrt complexity of HL7 and similar such standards as also the slow pace of adoption:
I think it is time we went back to basics (especially when a simple thing like describing Blood pressure (110/70 mmHg) can take more than a Kb of memory) The reason being that our worthy IT compatriots wish to micro-manage and detail each (atomic) component of medical literature. That is not and will never be possible - period. The results of all this - >> huge groups and sub groups to make ever more complex "standards"(V1....2.....2.5....3) millions of bucks to create, sustain and propagate such "standards" >> millions more to train thousands of people to learn this (mostly unwanted 'language'), thousands more to program it >> spawning of hundreds of (unnecessary) support industries to care for this/these "Standard(s)" >> and so on and so forth......... Of course all of this is awfully good for business (mine included), job creation, pay hikes and promotions. BUT...(my conscious bleats)....who finally pays?? we all know that >> ultimately.... the poor patient!! and in countries like the UK..... every citizen! I think it is a case of the cure being worse than the ailment. Remember, doctors have their own standards. I can read a case history written in English, on a plain A4 sheet of paper, by a clinician from any part of the globe (and vice versa) and understand every word (if I am of that specialty). And we have been doing this for more than 200 years. So let us not wrap tons of extraneous information to the already large medical knowledge pool. Informatics is good and does help clinicians (see my company's logo), but in the right doses....a toxic dose (more than LD50) can kill. We have now reached (IMHO) a stage where our 'Help' is actually becoming a big fat obstruction. I say, "KISS" (Keep it simple S****d!). I do believe that a real standard should be one that does the job and is simple enough to self learn in a day or two. Elegance not diarrhoea is the need of the day. Bottom line - we now need to seriously think about going back to basics and simplify - simplify - simplify. I welcome comments from my worthy colleagues . With warm regards, Dr D Lavanian MBBS,MD CEO and MD HCIT Consultant www.hcitconsultant.com Certified HL7 Specialist Member- American Medical Informatics Association Member HIMSS Senior Consultant and Domain Expert - Healthcare Informatics and TeleHealth Former Vice President - Healthcare Products, Bilcare Ltd Former Vice President - Software Division, AxSys Healthtech Ltd Former Co-convener Sub committee on Standards , Governmental Task force for Telemedicine Former Vice President - Telemedicine (Technical), Apollo Hospitals Group Former Deputy Director Medical Services, Indian Air Force Office: +91 20 32345045 Mobile: +91-9970921266 ----- Original Message ----- From: pablo pazos To: openehr technical Sent: Saturday, November 20, 2010 3:01 AM Subject: RE: More on ISO 21090 complexity It's hard get both: standard by consensus and to base standards on good design practices. I think the point of the discussion is: what model (or way of modeling) is good and why? On one hand we have the HL7 way of modeling things, that do not follows the best known practices but is accepted by many parties. (HL7 models are tight coupled with XML Schemas, for exmple, the "choice" construcor in the diagrams is a bad way of modeling things that can be modeled better with subclassing in UML, as every developer that works with HL7 v3 knows, this adds complexity to the development). In the other hand we have some models that follow the best design practices, but are acepted by a group of "friends". The strong point in one is the weak point in the other. So, in reality, we have to live with a god and with many atheists, and believe in both. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos > Subject: Re: More on ISO 21090 complexity > To: openehr-technical at openehr.org > CC: openehr-technical at openehr.org > From: hammo001 at mc.duke.edu > Date: Fri, 19 Nov 2010 14:54:32 -0500 > > Tom, Now I know why HL7 has so much trouble. -- "just basic god practice. > " Shouldn't god be capitalized? I think HL7 needs to pay Tom a consulting > fee - for all the advice. > > W. Ed Hammond, Ph.D. > Director, Duke Center for Health Informatics > > > > Thomas Beale > <thomas.beale at oce > aninformatics.com To > > openehr-technical at openehr.org > Sent by: cc > openehr-technical > -bounces at openehr. Subject > org Re: More on ISO 21090 complexity > > > 11/18/2010 06:38 > AM > > > Please respond to > For openEHR > technical > discussions > <openehr-technica > l at openehr.org> > > > > > > > On 18/11/2010 06:51, Vincent McCauley wrote: > > > >From the point of view of a clinical datatype implementer who has to > write > actual code, the ISO dataypes provide a level of detail > that is both required and sufficient. They are definitely not > "simple" in > their definition but are mostly "simple" > in terms of concept representation. > The atom at one time looked "simple" and remains so in concept, > though in > fact having considerable underlying complexity. > The level of detail required depends on your use case which seems to > be a > major contributor to your divergence of opnion. > > > > I see this as one of the major problems of HL7 actually. It seems to think > that everything should be driven by use cases. This is not the case. The > general drive in all engineering and software development is to have layers > of highly reusable elements that work in all situations. Thus the design > concept of 'Integer' and 'String' in a programming language is not specific > to any particular used. Neither should the concept of 'codedtext', > 'ordinal' or 'physical quantity'. The idea that a set of such data types > should be built not just for messaging, but apparently with features for > other more specific use cases is plain wrong. It is not good modelling. > Contextual (i.e. use-case specific) features should always be added in > specific classes / locations in models dealing with those specific use > cases. > > The openEHR data types are designed like that - it is just basic god > practice. They can be (and are) used in messaging, storage, GUI, business > logic. Context specific features are modelled and coded where they are > relevant, not integrated into what would otherwise be completely generic > data types. > > Not understanding this basic modelling practice has lead HL7 to produce > models that are very far from being easily implementable or reusable - > which is a real pity. > > - thomas > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ------------------------------------------------------------------------------ _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101120/28c396b1/attachment.html>
