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> wrote: > Hi Bert, excellent questions! > > > On Aug 21, 2017 5:55 AM, "Thomas Beale" <thomas.be...@openehr.org> wrote: > > > On 21/08/2017 09:09, Bert Verhees wrote: > >> On 21-08-17 02: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 > > 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
