I notice the versioning discussion. Is see three different topics; (non-)Persistent, versioning and synchronisation/consolidation. I see no use of non-persistant flags. I see two reasons for versioning. Synchronisation,consolidation is too complex for now.
ERS systems document events. Each documented event is equally important to document. What is important now is not later. And vice versa. Always a subjective opinion is documented by the author. Persistent Depending on circumstances an event is important or not. In this context I fail to grasp the need to label certain events as persistent and others not. All documented events need to persist in EHR-systems. Lists re-used data. Some events warrant to be re-used in context dependent lists: Active medication, Problem list, Previous diagnosis, etc. Each context, HcProvider will need different lists for different purposes. These lists are the result of documented events and persist. Creating lists is an example of re-using data, because list content is derived from pre-existing events/data. These lists are either changing are not-changing over time. Versioning Lists Lists can be updated as the result of new events in the patient system and therefor need to be versioned. These are non-technical new versions. They are the result because of changes in the patient system Versioning events While documenting events and committing them to the data base sometimes event data needs to be changed, updated, corrected. The same event gets a new technical version, because nothing in the patient system changed but the documentingHcProvider initiated the change. Synchronisation, merging, syncing This is a complex topic. Is there an extensive list of examples and requirements? Gerard Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 18 Aug 2017, at 13:49, Pablo Pazos <pablo.pa...@cabolabs.com> wrote: > > From Thomas comments, it is clear that we have such last two use cases, > internal versioning and cross-system versioning / sync / consolidation. > > Consider people here is talking about their own experience with the specs > under the use case they implemented. We can argue that internal versioning is > needed in 100% of the implementations while cross-system is a much less > implemented case. This doesn't mean that the current specs are not usable and > useful in abstract, but we should contextualize the discussion by use case > and by the frequency each is implemented. > > For internal versioning it is clear that distributed versioning spec > generate some friction at implementation time. IMO we need to address both > use cases trying to minimize friction for new developers. That can improve > the quality of the specs without print anything out. > > Also, I would like to hear more about implementations of both use cases and > the challenges implementers had to really validate the idea of addressing > both use cases explicitly in the specs. > > Cheers, > Pablo. >
_______________________________________________ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org