Re: SV: Socio-technical challenges when the openEHR approach is put to use in Norwegian hospitals

[Bert Verhees]

On 16-03-16 00:36, Bjørn Næss wrote:


Yes – there must be some kind of misunderstanding. The intention have 
never been that end-user should do the important and challenging work 
on developing clinicial information models (archetypes). The idea have 
been that this gives the clinical community an opportunity to influent 
and co-operate in this work.




The great advantage of OpenEHR, and possible other 2 level modeling 
software is not that it is easy for non technical people to use or 
develop with.
Users should never develop systems. And for using, it does not matter 
which storage is behind a system.


I sometime notice that it is hard to find good reasons why an 
organization like an hospital should switch to OpenEHR, and sometimes 
you see solutions to not really existing problems mentioned as an advantage.


For me the most important advantage of OpenEHR is its flexibility and 
that it can change information-schemes without having a lot of heritage 
to carry.


I explained it before, I don't remember if it was on this list, but if 
so, excuse me.


What I have seen are medical information-systems which keep on growing 
in complexity and that during 20 years.
A hospital information system I know has grown to 7000 tables in 20 
years (350 new tables every year, two new tables every working day, no 
kidding)
A GP information system has grown to 1000 tables in 10 years (100 new 
tables every year).
There will always be changes, new medical cures, organizational changes, 
other medical professionals doing something,  etc.
All the time when new functionality is needed new tables are created, 
old tables are never removed or changed, no-one dares to touch them, and 
every year less programmers understand the semantics. Documentation does 
not help much, because the documentation also often refers to situations 
from the past.
One natural thing of documentation is that it diverge from reality, this 
happens so often that famous developer-guru's say that it is better not 
to document a system. A system which needs documentation is not a good 
system.
Code to the tables becomes spaghetti, people come and go, and 
test-frameworks keep the thing running, but not many people really 
understand what the system does. I have seen such systems quite a few 
times, not only in healthcare


Just for fun:
http://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered

This one is famous:

|// // Dear maintainer: // // Once you are done trying to 'optimize' this 
routine, // and have realized what a terrible mistake that was, // 
please increment the following counter as a warning // to the next guy: 
// // total_hours_wasted_here = 42 // ||//When I wrote this, only God and I understood what I was doing //Now, 
God only knows|




The burden of maintaining or expanding or changing such a system gets 
higher every year , until the point is reached where the price of 
maintaining is higher then the price of a big reset
A new system will be bought, a team of experts will need a year or so to 
determine which data still have understandable semantics, and of course, 
the important data, like birthday, insurance and name of patients mostly 
will survive the transitions. And after some years, the new system will 
develop the exact same flaws as the previous system.


Many people do not realize the cost of the data-tangles which exist, or 
they think that professional system-maintenance can avoid this, and 
thus, it will not happen to them. But it will, I have seen very 
professional environments, academical hospitals, a team of highly 
qualified technicians working full days, maintaining the system (how 
much does that cost?) which have fallen into this trap.


Complexity is the enemy.

In a OpenEHR system you never create new tables, you always store in the 
same tables, because the semantics are not in the storage, but in the 
archetypes, which only need a limited structure to store and never 
changes. This can be an Object Oriented storage solution, or XML, or 
relational, that is not important for this point. So, the system has 
limited complexity, and the complexity will remain limited.


Companies, also hospitals, try new things, a new product-line, a new 
medical cure-project, create archetypes for that, run it a time, adjust 
it a few times.
But the system will not become more complex. The semantics of the 
storage are in the archetypes, not in the storage itself.
Archetypes are easier to understand because they are not a web of tables 
related to each other, and related to tables outside the project, they 
are self explaining and have quite simple structure.





I think all agree that the development and deployment of ICT solutions 
for healthcare is a large socio-organizational-technical challenge. 
 The work done by domain experts is only a (important and essential) 
part of that problem domain.


Best regards
Bjørn Næss
Product owner
DIPS ASA

Mobil +47 93 43 29 10 

SV: Socio-technical challenges when the openEHR approach is put to use in Norwegian hospitals

[Bjørn Næss]

Yes - there must be some kind of misunderstanding. The intention have never 
been that end-user should do the important and challenging work on developing 
clinicial information models (archetypes). The idea have been that this gives 
the clinical community an opportunity to influent and co-operate in this work.

I think all agree that the development and deployment of ICT solutions for 
healthcare is a large socio-organizational-technical challenge.  The work done 
by domain experts is only a (important and essential) part of that problem 
domain.



Best regards
Bjørn Næss
Product owner
DIPS ASA

Mobil +47 93 43 29 10

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Thomas Beale
Sendt: fredag 11. mars 2016 15.16
Til: openehr-clini...@lists.openehr.org; Openehr-Technical 

Emne: Re: Socio-technical challenges when the openEHR approach is put to use in 
Norwegian hospitals


I can only see the abstract for now, but I think the authors seem to have 
developed the misconception that end-users would somehow be designing 
applications. openEHR doesn't try to do that, and it's the first time I've 
heard anyone suggest it. openEHR just enables domain experts (generally = a 
small proportion of healthcare professionals, who might also be some kind of 
system user in some part of the world) to more directly define the information 
content of the system, in such a way that it can be processed and queried on a 
semantic level.

The Business Purpose of Archetypes section in the Archetype Technology Overview 

 may help to show why this is useful and necessary (it's short!).

There are still many other problems to solve such as clinical workflows and 
user interaction / UX.

I am currently at Intermountain Health in Salt Lake City working with the 
Activity Based Design (ABD) group that has developed a new architecture that I 
think has a realistic chance of addressing a) workflow (e.g. typical nursing 
tasks like cannulation; more complex cooperative workflows that involve shared 
care) and b) some aspects of UI interaction within workflows. They are just at 
an early prototype stage, and it has taken nearly 2 years to get to the current 
architecture (naturally taking into account many previous attempts and 
experience).

This effort is the first I have seen that has what I think may be the needed 
theoretical understanding and technical architecture to starting to solve 
clinical process and (some of) UI/UX. And what does it rely on? Formal clinical 
models, and it assumes that those models are created by clinical experts. Not 
only that, it explicitly assumes a 'template' concept of the same kind as 
openEHR's, in order to construct useful data sets.

It considers these 'templates' as the basis of an 'Activity' description, which 
then adds new abilities to blend in some presentation directives, pre- and 
post-conditions, some workflow elements, cost-related items (e.g. ICD coding) 
and so on. The innovation here is to consider an Activity a unit of clinical 
work and to attach these process-related semantics into that level of artefact.

So let's just reflect on the fact that this research is only now emerging from 
one of the leading institutions in the world that has historically specialised 
in workflow and decision support.

openEHR as it is today is just a semantic content + querying platform, and I 
think we can reasonably say that we have some handle on generating 
developer-usable artefacts, i.e. things like TDS, TDO etc, but they are all 
content related. These are starting to be standardised now.

The openEHR of today needs to leverage new work such as ABD (or something like 
it) to achieve many of the things that the Norwegian paper talks about. The 
paper seems to be critiquing a somewhat unrealistic set of expectations re: 
openEHR, although I am sure it has useful lessons.

I'll provide a proper description of ABD ASAP, which I think will provide our 
community (particularly those working on clinical workflow, process etc) new 
ideas on 'the next layer' for openEHR.

- thomas
On 09/03/2016 23:58, Bakke, Silje Ljosland wrote:
Hi everyone!

As some of you may have noticed, a paper called "Evaluating Model-Driven 
Development for large-scale EHRs through the openEHR approach" 
(http://www.sciencedirect.com/science/article/pii/S1386505616300247) was 
recently published by a PhD student at the University of Tromsø. The paper has 
some pretty direct criticism of the ideal of wide clinical engagement in widely 
reusable information models, as well as the clear division between the clinical 
and the technical domain inherent in the openEHR model. I think a lot of the 
observations detailed in the paper are probably correct, for its limited scope 
(one Norwegian region and 4 years of observation, half