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-implemente rs_lists.openehr.org
_______________________________________________ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
