To all,
I think these conversations are becoming interesting. Systems are complex
because designers either do not take the time to build them correctly or
are not smart enough to make them simple. Of course, simplicity is a
matter of preference. A story about Mark Twain. He wrote a long letter
and appoligized that he did not have time to write a shorter one. In my on
work, It takes me much longer to write a short paper than a longer one - I
have to think about content. Most designers like to show you what they
know, and modelers never finish modeling.
I think there are some smart people on this list. I also think we spend
too much time criticizing what is; and I think we have focused too much on
components. I designed my first "compound data elements" in 1972. In a
metadictionary, I defined the components - whose order defined the
structure; included the prompts for data collection; and stored with
delimiters separating the components. Heart murmur is an example, and we
could query for any heart murmur - or define the degree of specifity. The
overhead of XML tags and including the data structure is huge. Even with
CDA, to send a single data value takes a lot of characters.
I think we should be able to define structures independent of the
transmission of the data. How do we work together to move ahead?
Koray, I like your thoughts.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Koray Atalag
<k.atalag at aucklan
d.ac.nz> To
Sent by: For openEHR technical discussions
openehr-technical <openehr-technical at openehr.org>
-bounces at openehr. cc
org
Subject
RE: More on ISO 21090 complexity
11/21/2010 06:37
AM
Please respond to
For openEHR
technical
discussions
<openehr-technica
l at openehr.org>
Hi All, what a discussion J
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: [email protected]
[mailto:openehr-technical-bounces at openehr.org] 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> 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
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
