Hi All, what a discussion :) Just a few points: we have developed an endoscopy reporting application based on a very comprehensive domain model (some of you already know - I am obsessed with this model!) using openEHR specifications. There were many obstacles - including data types (for example a quantity data type with two alternate units of which one was not in the list of selectable units defined in a small terminology) but a solution could always be found. I can say that it has worked for us and in a few weeks time we will release the code as open source. There was a mention of GUI with data types; indeed I must say that they almost always dictate the type of widget on screen - that's our experience. Rest of the GUI definition comes from what we call "GUI Directives" inserted into Templates as annotations. I suggest that we define a specific entry for GUI for each node at template level.
There relevance of this message to this thread is that, I have repeated this argument several times before, I suggest working on some concrete examples when discussing about pros and cons of different standards. So I'd be very interested to see some examples (caution not to use 'use case' here ;) where one standard data type works and the other doesn't and vice versa. Perhaps a wiki page where the ordinary readers like me could understand fully and appreciate the many arguments thrown so far. It's a pity that we are using so little of the available e-collaboration tools effectively while calling ourselves as (health) informaticians ;) I personally think we, health informaticians, make life a lot more complicated than it should be. I am pretty confident that the solution of >90% of problems is a no brainer and that we need more of it for the remaining. My gut feeling is that the chances of getting something working out there are higher if we start with simple and generic data types. Based on the needs during 'real-world' implementations (not well thought use cases) I think they can evolve 'incrementally'. I must admit that I may just be too simplistic here but this is my approach to solve problems. There were also a few mentions about 'maintainability' and 'software quality'. Well I know a little bit about this (indeed my research is all about this topic!). Maintainability, according to the well accepted ISO/IEC 9216 and 25000 series standards quality model, is a quality characteristic - a very important one because it has a dramatic effect on software cost. The rule of thumb is to avoid complexity - in code, design artefacts, process etc. The preliminary results of our research shows that it takes seven times less time to implement changes and the complexity is nine times less in the openEHR based application compared to a 'typical' object-procedural/relational DB application. One next research question now in my mind is to build a third application using HL7 based on exactly the same requirements. I'd be very keen to collaborate if you find the idea interesting and worth investigating. I guess this should then be the "Evidence based health informatics" ?? Cheers, -koray From: openehr-technical-bounces at openehr.org [mailto:[email protected]] On Behalf Of Seref Arikan Sent: Sunday, 21 November 2010 6:50 a.m. To: Dr Lavanian; For openEHR technical discussions Subject: Re: More on ISO 21090 complexity 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<mailto: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<http://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<mailto:[email protected]> To: openehr technical<mailto: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 > Subject: Re: More on ISO 21090 complexity > To: openehr-technical at openehr.org<mailto:openehr-technical at openehr.org> > CC: openehr-technical at openehr.org<mailto:openehr-technical at openehr.org> > From: hammo001 at mc.duke.edu<mailto: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<http://aninformatics.com> To > > openehr-technical at openehr.org<mailto: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<mailto: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<mailto:openEHR-technical at openehr.org> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org<mailto:openEHR-technical at openehr.org> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ________________________________ _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org<mailto:openEHR-technical at openehr.org> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org<mailto: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/20101122/60d0c9b4/attachment.html>
