Hi, There are several (5) realities: 1- that what is actually happening in the Patient System 2- that what is observed by the HcP/author (observables via senses) 3- subjective evaluation by HcP 4- that what is documented in the EHR patient record (Committed Composition) 5- the EHR Patient Record system
a- Each commit must be logged and never physically removed. Committed Compositions are never physically removed Each is a legal act that needs to be documented and stored. Several other processes are connected such as: billing, (lega) reporting b- The status of Committed Compositions can change (from active to not-active, cq readable to not-readable) In other words the Access Control status is changed. A change in a Care Plan as part of the Patient System is documented via a superseding new Committed Composition indicating the termination of the process that is a a Care Process Plan. It will be a new update, as a new version, of the Committed Composition that is about the Care Process Plan. Nothing can/must be 'logically deleted’, a new status must be documented. c- When patients demand the removal of all data the Patient record is declared in-active or its Access Control List is changed such that only the patient has controlling access rights. d- When specified Committed Compositions are ‘removed’ as requested by the Patient these wil be declared iin-active or its Access Control List is changed such that only the patient has controlling access rights. e- In-active means that the data can NOT be used for the provision of Health Care; it can be used for administrative or legal purposes. Logging is one of the legal/administrative needs. Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 6 Nov 2017, at 15:39, Bert Verhees <bert.verh...@rosa.nl> wrote: > > For the first scenario, changing a care plan, or stopping it, I wouldn't > think of calling it logical deleting it but bring it into another state: > stopped, or something like that. > > The second is in fact physical removing it from the Ehr and then saving it > somewhere in some form. In the openehr standard is, as far as I know not a > facility to do this. In fact the second scenario is, as I see it, from the > openehr point of view the same as the third. > > Bert > > > Op ma 6 nov. 2017 15:11 schreef Thomas Beale <thomas.be...@openehr.org > <mailto:thomas.be...@openehr.org>>: > > > On 04/11/2017 18:38, Bert Verhees wrote: >> But also apart from that. The discussion is if a standard should facilitate >> an inactive patient (logical deleted) to still remain in the active clinical >> information system with a special flag or that he should be transferred to >> an archive system. This is the question which is important to decide if a >> standard should define a "deleted" flag. >> >> I think such a flag is a technical flag to organize some way of archiving >> data. It has no additional semantic meaning and should not belong in a >> standard defining semantic structures. >> > > just to be clear, we are talking about (at least) 3 different things: > logical content deletion, e.g. I want to 'wipe out' my second homeopathic > Care Plan that is no longer relevant because I stopped believing in homeopathy > archival of EHR: I want to move the EHR to an archive system that allows > access, querying (or at least extraction), but separate from operational EHRs > physical deletion of EHR from entire system: nuke this EHR > The delete marker in the current model only applies to the first one. > To support archival, we need to know what we think the archival workflow will > be. Let's say we defined that, then I can imagine adding a new Boolean flag > to EHR_STATUS called e.g. archived or ready_for_archival or similar. THis > flag would prevent the system from 'seeing' the EHR even if it was not yet in > the physical archive, and it would enable an archival admin process to know > that it really can archive this EHR. When you think about it, a flag won't be > enough, it needs to be some sort of signed 'consent for archiving' concept. > For the third scenario, another flag may make sense like > 'ready_for_deletion', but again, we need to study the needed workflow in > detail to really know what changes to the models are needed. > > - thomas > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > <mailto:openEHR-technical@lists.openehr.org> > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>_______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
