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

Bert Verhees bert.verhees at rosa.nl
Sat Mar 12 04:34:28 EST 2016


Just a thought on the reading of the article

Good article, until I found this sentence: "domain models are now 
separate from the software (but not the product), and they can be built 
by non-IT personnel, assuming a tool with a reasonable user interface."

Making user-interfaces is a profession, not something you learn on a 
rainy sunday afternoon.

When I read that users should be able to build systems when having the 
tooling, it gives me doubts about its efficiency.
When I write that users are King, I do not mean that Users must do the 
work.
Kings don't work, maybe they have a hobby, but mainly, they drink the 
wine, they don produce it.

I have spent many hours with non-technical medical doctors who learned 
programming BASIC and assembler as a hobby in the eighties, they should 
not interfere, they should not try to understand what Codd has to do 
with database-systems. We, technicians don't try to understand diseases, 
we accept a fairy tale about little monsters inside our body. No 
problem. We understand that we don't need to understand. We want to be 
cured, we trust medical doctors that they do what good is for us.

There are so many ways for non-technical end users to explain what they 
want to technical staff. It is the result that counts, isn't it?
And the price is very high, and of course the tax payer is happy to pay. 
I think that is one of the problems, in normal commercial markets, 
companies are much more efficient.

We have the situation in the Netherlands that we spent 500 million Euro 
for a information-exchange-environment for medical data. Not only 500 
million, but also we waited 15 years.

Now we have it.
But it does not have, even the most basic, authorization, everyone who 
has legal access to the system can look at every patients-record.
Not only that, it has no logging accessible for patients, a patient 
cannot see who looked at his medical records.
The use of the system is against every privacy law in the Netherlands, 
so there was a court needed to use it, and the court gave its blessing 
because patients are voluntary in the system (opt-in)

If you would have designed the system from requirements, and gave it to 
a technical company, together with domain-experts to define a message 
standard, I think the system would have been ready ten years earlier, 
for 20% of the costs, and no court needed to approve its use.

I think in medical ICT, the best role of the user in ICT is widely 
misunderstood. We, technical experts and domain experts should inform 
users that democracy does not mean that people need to understand how to 
run a country or build an ICT system.

On 11-03-16 15:15, Thomas Beale wrote:
>
> 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/>http://arketyper.no/ Twitter: 
>> @arketyper_no <https://twitter.com/arketyper_no>
>>
>>
>>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
> -- 
>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20160312/d96d5c94/attachment-0002.html>


More information about the openEHR-technical mailing list