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

Reply via email to