More on ISO 21090 complexity

Technical (archive)
21

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.

22 
Tom,  As you have often pointed out, we do disagree but we are friends.  In
aqny case, I enjoy the banter.  At a minimum, it teaches me reserve.
Unfortunately, the issues go beyond technical and even philosophy.  The
problem is when you put 500 people to writing standards

Ed, I think you just identified the problem…

23

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

24

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

25

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

26

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

27

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 :wink: 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 :wink:

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

28

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@aucklan
             d.ac.nz> To
             Sent by: For openEHR technical discussions
             openehr-technical <openehr-technical@openehr.org>
             -bounces@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@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 :wink: 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 :wink:

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

29 
To all,
...  Even with
CDA, to send a single data value takes a lot of characters

openEHR would be the same in that respect. But the criteria we judge on now include things like computability, re-usability (of information) and so on, not just number of bytes and time to display.

I think we should be able to define structures independent of the
transmission of the data.  How do we work together to move ahead?

I have been arguing with HL7 folk for years on this point. But HL7 appears locked into defining the content within a message based model, full of message-related attributes and design features. This makes it very hard to re-use an HL7 content definition, even assuming it was agreed to be done as an HL7 template (unfortunately, this is in XSD, a disasterous modelling technology) or an RMIM.

One of the things we tried to do from the outset with archetypes was to get away from this. Yes, openEHR archetypes implicate the openEHR reference model, but only about 30% of it - the semantics that matter to clinical modellers. And from openEHR templated archetypes, we can generate diverse downstream artefacts for use by normal programmers. The message XSD is a end-of-the-line downstream product, not a starting point in openEHR.

  • thomas
30

Well said! Here is my take on the problem.

Imagine having N barrels, and a number of pipes, connecting these barrels. Barrels are filled with water, and pipes carry water from barrel A to barrel A.
At an abstract level, both barrels and pipes contain water, but they are supposed to allow different uses of water, and this is reflected to their design.

A pipe mostly has a smaller diameter compared to a barrel, since it is supposed to go through walls, and it is usually made from a different material, considering problems like freezing. So you insert two ends up a pipe into two barrels, and it would help you carry water from one barrel to another.

The barrel on the other hand, is designed to hold water, and it has a large cover, matching its wider diameter. You can get a water pot, sink it into the barrel, and fill it with water. This would be your local use of water.

By design, pipes provide barrel to barrel connectivity, and people in front of the barrels get their water from the barrel.

Now, both in theory and in practice, you can use pipes to store water. Imagine how you’d do it: you get 40-50 pipes, close one end, then bind them all together and put them on the ground , making them stand on their closed end. Then you need to either connect 50 pipes to your 50 vertical pipes, or try to fill them with a water pot, making sure that you don’t spill water into the space between them.
When it is time to use this set of pipes to fill water into water pot, you can’t sink the water pot into the pipe’s opening, so you’d have to lean the pipes to fill water to water pot, of course, since all pipes have an open top, you’d have to have to deal with water being wasted.

Likewise, you can remove the tops and bottoms of barrels, join them, and try to use them as pipes. This time, you’d be wasting an awful amount of space, since only a certain amount of water is supposed to flow from one point to another and also, you’d find out that 30 cm thick walls can’t really contain barrels with 60 cm diameters.

Trying to use HL7 to build the whole information system is like trying to use the pipes to store water. It somehow happens, but both the people building the storage (information system) and the people trying to feel the water pot (end users) have problems.

If you try to use comprehensive models you’ve designed to run a clinical information system for messaging, you’re trying to put barrels into walls.

I think you can see what is wrong here, but life is funny when it comes to software; if it more or less works, then it is simply called “working”. I for one, will not be storing water in pipes…

Best Regards
Seref

31

In a message dated 21-11-2010 14:50:15 W. Europe Standard Time, hammo001@mc.duke.edu writes:

I think we should be able to define structures independent of the
transmission of the data. How do we work together to move ahead?

Hi Ed,

this is the 6 year ongoing work on detailed clinical models, no more no less.
comment on the UML is irrelevant on this, since we also have XML, ADL and R-MIMs created from the data elements base.

However, one thing on data elements is very important: relationships between some data elements need to be expressed, e.g. for total scores, derivations.

Met vriendelijke groet,

Results 4 Care b.v.

dr. William TF Goossen
directeur

De Stinse 15
3823 VM Amersfoort
email: wgoossen@results4care.nl
telefoon +31 (0)654614458

fax +31 (0)33 2570169
Kamer van Koophandel nummer: 32133713

32

Hi Koray,

As an example of a “real-world implementation”, we have build an EHR for trauma care. Our project was developed in one year and four months.
The core of the development is an openEHR-based framework, wich takes archetypes and our own templates (with GUI directives), and generate GUI, data binding with RM structures, validation of data against archetypes contraints, and persistence of the RM structures. BTW, this framework has been open sourced: http://code.google.com/p/open-ehr-gen-framework/ (sorry docs in spanish only).

I’ve estimated that this particular project without the “openEHR overhead” could be finished in 6 months.
But if I have other project like this today (same size, same complexity, etc), I think we can finish the development en 3 months, using our openEHR-based framework.

So, if we have 10 projects this are the numbers:

  • Without openEHR tools: total of 160 months (13.3 years)
  • With openEHR tools: total of 56 months (16 months for the first development, 4 months for the rest 9 projects, that’s 4,7 years!!!)

If we can improve the tools, these times could be improved, and the final solutions have the advantage of separating the knowledge from the software, and we can share and reuse archetypes between diferent projects, that’s just great! :smiley:

Hope this experience can help you.

33

hi Tom

I can only presume this email actually predated our other discussion

a) a response to some (undoubtedly real) needs by the hL7v3 design group,
and are modelled according to the hL7v3 architecture, not some other
architecture.

which architecture is, everything completely denormalised. And
so they're not suitable for an environment where you want
to normalise. y.

I am not even sure the spec is clear itself on what originalText really is:

Original text can be used in a structured user interface to capture what the
user saw as a representation of the code on the data input screen, or in a
situation where the user dictates or directly enters text, it is the text
entered or uttered by the user

So is it a representation of the code on the data input screen (i.e. the
term for the code) ? Or is it some other freely entered text to which a code
(and term) is being attached? Why is originalText 'semantic' and
'displayName' not - when it is in fact the proper linguistic rendering of
the code, and therefore surely 'semantic'?

OriginalText is a problem. The definition was agonised over a great deal.
It's the text that's the basis one which the code was assigned - if there
is any.

displayName is an algorithmic conversion from the code to it's designated
display.

Generally, the two are logically exclusive - it doesn't make sense
to have one and not the other. But sometimes it does. grrr.

a true synonym (different linguistic rendering of the same concept), AND
a mapping - usually done for classification purposes, e.g. association of a
broad ICD or DRG code to some specific disease or condition text.

maybe. The definition doesn't seem crisp to me. How precise does the
different linguistic rendering have to be before it's a true synonym?
If it's not a synonym, it's a mapping. Or the other way around?

Grahame

34

I'd say so, Grahame, because the date on Thomas's email was 18th
November, and I recall reading its content already, many days ago.

- Peter

35

yeah, Peter, thanks. You'd think that when I write that, I'd have
the wit to actually check the date huh?

Grahame

36

Hi Pablo,

Your project is very interesting and I think needs more discussion,
outside the context of this thread on the ISO datatypes. Perhaps you
should re-post it on a new thread or on the 'openEHR adoption' thread,
as it might give some useful pointers as to how we can best share from
and support open source projects like yours and Koray's. There are
also some interesting discussion to be had about how to share the
archetype you have developed, or at least feed your ideas into broader
developments.

Would you mind re-posting in a different/new thread?

Ian

Dr Ian McNicoll
office / fax +44(0)1536 414994
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical analyst, Ocean Informatics
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care SG Group www.phcsg.org