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> 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> 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 > -- Ing. Pablo Pazos Gutiérrez Cel:(00598) 99 043 145 Skype: cabolabs <http://cabolabs.com/> http://www.cabolabs.com pablo.pa...@cabolabs.com Subscribe to our newsletter <http://eepurl.com/b_w_tj>
_______________________________________________ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
