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 <tel:+47%2093%2043%2029%2010>
*Fra:*openEHR-technical
[mailto:[email protected]] *På vegne av*
Thomas Beale
*Sendt:* fredag 11. mars 2016 15.16
*Til:* [email protected]; Openehr-Technical
<[email protected]>
*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
<http://www.openehr.org/releases/AM/latest/docs/Overview/Overview.html#_business_purpose_of_archetypes>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 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
<https://twitter.com/arketyper_no>
_______________________________________________
openEHR-clinical mailing list
[email protected]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
--
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
