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 

RE: Adressing of i.e. discharge summaries

[Heath Frankel]

Hi Bjorn,
Yes we have used these archetypes for representing the service request at both 
the instruction and composition level. Our instruction starts in a care plan so 
we have to represent the referred to provide in the instruction participations. 
Then when we send the referral we copy it to the receiving provider 
participation in the eReferral composition.

Since a discharge summary is a kind of transfer of care then I would expect it 
to have a similar participation when it is being directed to a primary care 
provider although this doesn't need to be populated when it is being uploaded 
to a national repository for example.

Regards

Heath

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bjørn Næss
Sent: Wednesday, 16 March 2016 4:42 PM
To: openehr-technical@lists.openehr.org
Subject: Adressing of i.e. discharge summaries

There is a lot of compositions that is created for the purpose of sending the 
content to another healthcare provider. Discharge summaries is one example.
For instruction health care service request there is some elements and slots 
added to the protocol part. Here you can add both the requestor and the 
identifier.

In the Nehta CKM there is a composition archetype for referral. This archetype 
has some structure under context to add participation and identification of the 
requestor. I think this pattern would be the right way to do this.

Anyone with experiences or suggestions on how to do this?



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

Mobil +47 93 43 29 10


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6189 / Virus Database: 4540/11798 - Release Date: 03/11/16
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Adressing of i.e. discharge summaries

[Bjørn Næss]

There is a lot of compositions that is created for the purpose of sending the 
content to another healthcare provider. Discharge summaries is one example.
For instruction health care service request there is some elements and slots 
added to the protocol part. Here you can add both the requestor and the 
identifier.

In the Nehta CKM there is a composition archetype for referral. This archetype 
has some structure under context to add participation and identification of the 
requestor. I think this pattern would be the right way to do this.

Anyone with experiences or suggestions on how to do this?



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

Mobil +47 93 43 29 10

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org