Dr D Lavanian, Just so I understand what you are saying. Are you promoting what is in this email as a solution or the stuff from your website?
"Put simply, we are a One-Stop Shop for all of your needs in the Healthcare technology Domain. Be it strategy, software design, ergonomy validation, software, hardware, medical equipment, project management, clinical content management, field trials/testing, marketing or bundled turnkey services - we do it all. Our services are listed on the pane to your right." Maybe you just have a guilty conscious for taking Australian's money? I dunno...I can't figure it out. Cheers, Tim On Sat, 2010-11-20 at 19:38 +0530, Dr Lavanian 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 > 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 > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- *************************************************************** Timothy Cook, MSc Project Lead - Multi-Level Healthcare Information Modeling http://www.mlhim.org LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook Academic.Edu Profile: http://uff.academia.edu/TimothyCook You may get my Public GPG key from popular keyservers or from this link http://timothywayne.cook.googlepages.com/home -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101120/fe3ef4ac/attachment.asc>
