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

Bert Verhees bert.verhees at
Wed Mar 16 06:10:41 EDT 2016

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

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
> Mobil +47 93 43 29 10 <tel:+47%2093%2043%2029%2010>
> *Fra:*openEHR-technical 
> [mailto:openehr-technical-bounces at] *På vegne av* 
> Thomas Beale
> *Sendt:* fredag 11. mars 2016 15.16
> *Til:* openehr-clinical at; Openehr-Technical 
> <openehr-technical at>
> *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”
>     (
>     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 of which was done before the national governance was
>     established). We’ll probably use the paper as a learning point to
>     improve our national governance model, and I’d like to hear any
>     international (and domestic Norwegian for that matter) takes on
>     the implications of the paper.
>     Kind regards,
>     *Silje Ljosland Bakke*
>     **
>     Information Architect, RN
>     Coordinator, National Editorial Board for Archetypes
>     National ICT Norway
>     Co-lead, Clinical Models Program
>     openEHR Foundation
>     Tel. +47 40203298
>     Web: Twitter: @arketyper_no
>     <>
>     _______________________________________________
>     openEHR-clinical mailing list
>     openEHR-clinical at
>     <mailto:openEHR-clinical at>
> -- 
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openEHR-technical mailing list