It is true that care-plans for a single patient for a single case can be written by more care-takers simultaneously, but one could argue if they, in that case, belong in the same composition?
Wouldn't it be better to have more care-takers for one patient on a single case have their own compositions, and are grouped by folders outside the compositions?
Bert
well how a care plan is designed is up to clinical designers. The usual idea is to have an updatable, evolving plan (potentially for each major problem), shared across care providers.
- thomas
On second thoughts, I agree that to facilitate a care-plan is a good reason to have persistent compositions.
In case if more than one care-taker is able to edit a single care-plan in a single composition simultaneously, then branching/merging will become necessary.
However, in that case, I think it is better in that case to lock that particular composition for updates and have it refreshed on the screen like should always be done on database-based applications after locking.
In that case, only versioning without merging would be necessary.
But like you mentioned before, merging (without branching) can become necessary on importing data from another OpenEHR-based EHR, in that case, persistent compositions can have reasons to be merged.
Thanks very much for the explanation. I understand that this is a delicate subject which complexity is easily underestimated.
Bert
Hi Bert, excellent questions!
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?
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
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.
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:
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.
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
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.
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