On 21-08-17 12:18, Thomas Beale wrote:
On 21/08/2017 10:45, Bert Verhees wrote:
On 21-08-17 10:54, Thomas Beale wrote:
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.
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?
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.
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
_______________________________________________
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
