Re: Versioning implementations

Wed, 23 Aug 2017 13:17:11 -0700

So, what happens is that (for example) one healthcare-enterprise has created a care-plan, which is to use by more care-providers on different computer-systems/network/database (another healthcare-enterprise). When on the same system/network/database there are things like locking to solve this.
The original enterprise sends a message containing the care-plan, and the receiving starts integrating it in their own care-plan. 


This happens a lot. A person was in a hospital, they wrote a care-plan 
for when at home again, to do some things. (take medication, for 
example). The care-provider at home (the GP, or nurse) already has a 
care-plan, and adds the information of the hospital. Everything cool.



Sometime later, the patient has to go back to the hospital, here was an 
unforeseen complication. The GP/nurse from the home situation, sends 
their care-plan to the hospital (in a message), so the specialist can 
see what has been done at home. Everything cool again, no branching 
needed. The message is stored, and some information of the message may 
be added to the care-plan of the hospital where the patient has to stay 
some time.



That is how the things go, in my country. But even there, to handle this 
simple information-transfer is hard enough. Even too hard. Hospitals, 
for example, still do not synchronize medication-information with the 
national health network.



I leave the discussion now. I think, branching and merging might be good 
in a perfect world, but in common practice, even sharing information in 
common messages, and coded with a good terminology is not yet reality. 
In Germany, for example, they do not use SNOMED-CT.


Best regards and thanks for your opinions.
Bert



On 23-08-17 21:41, Thomas Beale wrote:



The branching model in the specs is actually not designed to deal with 
competing editors in the same computing environment (that's taken care 
of by the optmistic locking rule already in openEHR); it's designed to 
allow for the possibility of an original resource such as Care Plan or 
a Medication List originating from some provider enterprise, and being 
copied to another location and modified there, while still being 
modified in the original location. In a perfect world this would not 
happen, because such resources would be true singletons, sitting 
behind a single-point-of-truth service API that all applications 
talked to. Well, since the NHS realised they wanted that 10 years ago, 
they are no closer to it today. I've never seen anything like it in 
the US either; it might exist inside Kaiser somewhat, and maybe Beth 
Israel (due to Halamka) but otherwise, no. But forking and 
modification of resources does happen easily.



All the branching model ensures is that the mods made by people at 
different 'systems' end up on branches specific to those systems, so 
that if the data are ever copied back to an original location, a safe 
machine merge can in fact happen, because the branches won't clash - 
this ensures no data are lost. A true content merge is still 
potentially required, which will most likely be manual.


- thomas


On 23/08/2017 20:27, Bert Verhees wrote:

Hi Eric, good story, but one remark, I understand from your story 
that you favor branching above locking. Because when you do locking 
while a composition is in edit mode, you don´ t need branching, and 
the merging becomes much easier. In fact, there is no merging when 
there is no branching



When you do locking of a composition in edit mode, every one wanting 
to edit a composition always works on the latest version.



Locking of a data-set when taking it into edit mode, is not something 
very exotic to do. In fact, it is common practice all over the world. 
I never heard of an information system supporting branching, and for 
good reason.
Branching is used in source-code files, but even there, it is avoided 
as much as possible. All programmers can imagine the trouble that 
comes to them when at the end of a working day, the version control 
system refuses to store a change in a file because it was edited 
simultaneously by someone else who posted it before.



You say, care providers should solve the branching/merging by calling 
the one who edited a composition simultaneously to find an agree 
about what to do with the merge.



And what if that other care-provider has gone home, maybe for a long 
period, after a week of night shifts, what should one do? Keep the 
composition in edit-mode? And causing more trouble and more branches 
and more merges and more agreements to find, because others need to 
edit the composition too? And what happens with the people wanting to 
read the composition, what do they read, the latest posted version 
(so all the edit-states are not accessible?)



I think this is a undesired solution. I think the locking system, in 
the end, is more safe also for the patient.


Bert




On 23-08-17 10:03, Erik Sundvall wrote:

Hi!


Shared care-plans, medication lists and allergy lists often need to 
be updated by several care providers that have different EHR-systms 
separated by both legal and practical/technical barirers; for 
example regional vs municipal care in Sweden or private vs public 
care providers.


Today in (usually non-openEHR contexts) that is often done by either:

1. using a separate shared system just for shared care plans etc 
(which means a degree of double data entry and manual 
transfer/reentry of things from/to different EHR systems that the 
patient has records in at different care providers)

or

2. forcing everybody to use the EHR system of the "biggest" care 
provider in the (or that systems shared care planning module). 
Pretty convenient for the big actor but a mess for the other smaller 
ones, especially those that have a patient mix from several 
different "big" providers using the "use my system" attitude...



So yes the multi-provider shared records with branch/merge 
capabilities are certainly needed if we want to avoid #1 and #2 above.



And yes merge will be a headache for users when it occurs, but 
likely less of a headache in total than #1 and #2 above. I believe 
enough of the subgroup of clinicians dealing often with shared care 
will become proficient enough to handle merging.



The "lock" approach (only allowing one party to change at a time) 
would only work if things were entered and synced fast and at once 
after the care event had happened. In reality a doctor may read 
version 12 of the medication list when seeing the patient on Friday 
and audio-record an update (that should become version 13), that 
gets transcribed and recorded in the EHR after the weekend.  During 
the weekend the patient needs to go to another care provider (e.g. 
emergency) that also looks at version 12 (since that is the latest 
recorded one) and immediately after the consultation records a 
version 13. See the merge conflict? In this case it might need to be 
resolved by the care takers contacting each other to agree on 
possibly conflicting persciptions. What happens today without 
openEHRs ability to at least detect a merge conflict is not always 
good for patient safety.



Many openEHR implementations today are single-care provider systems 
and then you don't handle/detect the conflicts using the system, but 
hopefully some other way.



I agree that a distributed versioning could be specified as optional 
in some openEHR conformance profile for single-care provider 
systems, but it should certainly not be taken away from the openEHR 
specifications! This also means that the version identifiers used in 
the specs (e.g. 
8849182c-82ad-4088-a07f-48ead4180515::ehr.examplecareprovider 
.org::12) should still contain the system id (e.g. 
ehr.examplecareprovider .org) even in single-care provider systems 
so that they can later be upgraded (or their possibly signed data 
can be moved) to a system capable of full distributed versioning.


Best regards,
Erik Sundvall

Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 
55 (or 010-1036252 in Sweden)
Region Östergötland: erik.sundv...@regionostergotland.se 
<mailto:erik.sundv...@regionostergotland.se> (previously lio.se 
<http://lio.se>) http://www.regionostergotland.se/cmit/
Linköping University:erik.sundv...@liu.se 
<mailto:erik.sundv...@liu.se>, http://www.imt.liu.se/~erisu/ 
<http://www.imt.liu.se/%7Eerisu/>



On Mon, Aug 21, 2017 at 10:58 PM, Pablo Pazos 
<pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>> wrote:


    I agree. The singleton is not one persistent compo, but the
    instance associated with an OPT of a persistent compo. When
    talking about singleton instances we should define what is
    considered the "class" :) My mistake.

    In the case of care plans, different care plans will be defined
    by different OPTs, same for medication lists if needed and
    modeled that way (some systems might only need one medication
    list, one problem list, etc. by EHR).

    But again, these are all clinical modeling decisions. A bad
    model might represent different care plans with the same OPT,
    and of course this breaks the singleton concept, but we are
    talking about subjectiveness here, so there are no hard rules
    (call it probabilistic singleton).


    Best,
    Pablo.


    On Mon, Aug 21, 2017 at 5:40 PM, Bert Verhees
    <bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>> wrote:

        Pablo, one small remark, a persistent composition is not
        really a singleton. Not conceptually. A patient can have
        more care - plans, for example, at different care -
        institutions or multiple care - takers at a single
        institution, or have multiple medication-lists.

        Bert


        On ma 21 aug. 2017 19:24 Pablo Pazos
        <pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>>
        wrote:

            Hi Bert, excellent questions!


            On Aug 21, 2017 5:55 AM, "Thomas Beale"
            <thomas.be...@openehr.org
            <mailto:thomas.be...@openehr.org>> wrote:


                On 21/08/2017 09:09, Bert Verhees wrote:

                    On 21-08-17 02 <tel:21-08-17%2002>:51, Pablo
                    Pazos wrote:

                        @Bert Persistent records are a well know
                        pattern in ehrs and it's usefulness should
                        not be under question. Of course systems
                        that focus on primary care might not
                        implement them. But for hospital or even
                        regional / national records need a wider
                        view of the patient, persistent shows their
                        value.

                    Hi Pablo, two questions

                    Which problem do you solve with persistent
                    records which cannot be solved in another way?
                    Do you agree that persistent records are the
                    only reason to have branching/merging necessary?


                well they are likely to be the most common element
                of an EHR to which branches and merging would be
                applied. However they are ubiquitous and are also
                likely to be extended to things like care plans and
                so on. But in principle, branch and merge could
                happen to anything in the record, e.g. for reasons
                like adding competing translations of clinical notes
                etc.

                - thomas





            Adding to Thomas, we can view this from three points of
            view: technical implementation, clinical modeling, and
            spec. My previous comments about persistent records are
            spec related. As Thomas said, _how_ things are done
            using the spec will depend on modelers, and also
            implementers.

            From the spec, I see persistent records as a framework
            to record everything that is conceptually a Singleton
            (one instance across the whole patient EHR). Then if
            that can or can't be modeled as an event record, is a
            discussion for clinical modelers, but I think that
            doesn't diminish the need of such a concept on the specs.

            Versioning and branching is an ortogonal concept to
            event/persistent records and can be used in any case.
            The _how_ versioning/branching is used has a lot to do
            with implementers and that is related to my initial
            question, and the hunch that maybe other devs like me
            found branching/merging an friction point (related to
            complexity) for the most frequent & simple
            implementations of openEHR, but knowing there are less
            frequent implementations that make extensive use of
            branching and merging.

            From the current answers to this thread, I see the need
            of a simplified or relaxed versioning model, that maybe
            is just a constraint over the current version control,
            allowing only certain versioning patterns, like lineal
            versioning, and some control mechanisms like versioning
            lock/release, access to read-only records, etc. These
            are not changes to the current spec, but additions as
            specs or as guidelines.

            What do others think?




                _______________________________________________
                openEHR-implementers mailing list
                openEHR-implementers@lists.openehr.org
                <mailto:openEHR-implementers@lists.openehr.org>
                
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
                
<http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org>


            _______________________________________________
            openEHR-implementers mailing list
            openEHR-implementers@lists.openehr.org
            <mailto:openEHR-implementers@lists.openehr.org>
            
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
            
<http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org>


        _______________________________________________
        openEHR-implementers mailing list
        openEHR-implementers@lists.openehr.org
        <mailto:openEHR-implementers@lists.openehr.org>
        
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
        
<http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org>





    -- 
    Ing. Pablo Pazos Gutiérrez

    Cel:(00598) 99 043 145 <tel:+598%2099%20043%20145>
    Skype: cabolabs
        <http://cabolabs.com/>
    http://www.cabolabs.com <http://www.cabolabs.com/>
    pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>
    Subscribe to our newsletter <http://eepurl.com/b_w_tj>


    _______________________________________________
    openEHR-implementers mailing list
    openEHR-implementers@lists.openehr.org
    <mailto:openEHR-implementers@lists.openehr.org>
    
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
    
<http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org>




_______________________________________________
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org





_______________________________________________
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org


--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>

Consultant, ABD Team, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/>



_______________________________________________
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org




_______________________________________________
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org






















					Reply via email to