Greetings, I'd say that simplification is a must in medical informatics, but I would not attempt to bring that simplification to the standards or the scope of medical informatics. The level of detail and complexity we introduce into our solutions is there because most of the time, even with the best practices history has thought us, there is a certain amount of complexity we can not avoid.
As long as the requirements are in the lines of "connect every hospital, every information system, every mobile device to healthcare data.." there will be these endless versions Where we need simplification is the front end of the technologies we are developing. That is tooling and clinical systems and other outputs, pretty much anything that relies on standards and software development. the real challenge in medical informatics IMHO is to give a doctor something that feels at least as convenient as the A4 sheet of paper and does at least a little bit better. I personally do not think that this is necessarily a challenge completely linked to the underlying complexity of the standards or information systems. There is certainly a connection, but complex specifications on their own are not reason for still not having the solutions we have been dreaming about. If you try to reflect the requirement of a layer onto others, you'll almost always end up losing capability. In fact, the price of power and simplicity is most of the time increased complexity at the background. For example, any expensive car with an F1 style gear shifting gives you a much simpler way of managing the gear. One button up, other button down. Now think about the complexity of the system that is giving you that gear shifting. It is much more complex than the usual gear box you'd have in a 1997 Ford Escord (my old car, which needed an exorcist at the back seat to stop it from killing me with its weird problems..) Iphone? Same thing. What a simple UI! Just put your finger on it. The technology backing it up? Definitely more complex than your first cell phone, which could easily replace a brick in your garden wall.. Let's try to simplify the right things, and we'll get there. Best Regards Seref On Sat, Nov 20, 2010 at 2:08 PM, Dr Lavanian <lavanian at vsnl.net> wrote: > 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 <pazospablo at hotmail.com> > *To:* openehr technical <openehr-technical at openehr.org> > *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 <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 > > > _______________________________________________ > 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/c1db8be5/attachment.html>
