SV: Socio-technical challenges when the openEHR approach is put to use in Norwegian hospitals
bert.verhees at rosa.nl
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
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
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
> DIPS ASA
> Mobil +47 93 43 29 10 <tel:+47%2093%2043%2029%2010>
> [mailto:openehr-technical-bounces at lists.openehr.org] *På vegne av*
> Thomas Beale
> *Sendt:* fredag 11. mars 2016 15.16
> *Til:* openehr-clinical at lists.openehr.org; Openehr-Technical
> <openehr-technical at lists.openehr.org>
> *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
> 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
> 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
> 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: http://arketyper.no/ Twitter: @arketyper_no
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> <mailto:openEHR-clinical at lists.openehr.org>
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-technical