Gérard has some points. A patient, in the Netherlands, has under conditions the right to require the physical removal of all data. In that case no "deleted" marker is necessary.
Then there is the case of inactive patients. In case of a GP the law requires he must.be able to produce the patients data until ten years after last visit. Often patients just disappear without formally ending the relationship with the GP or they never had a formal relationship. Tourists for example. A GP is not interested in seeing persons in a listing which are not his active patients. I once, some years ago, helped facilitating archiving those patients data, so they could be they physically removed from the GP information system. Also here was no "deleted" marker necessary. The only situation I can think of that requires a "deleted" marker is when a information system is used for historical data research together with active clinical use.. Maybe a standard should not facilitate such combination of use cases in a single data storage information system. When historical research is needed one should query the archive system. Bert Op za 4 nov. 2017 13:16 schreef GF <[email protected]>: > My two cents. > > Two data collections are involved: Patient registry, Patient Health Record. > I focus on the Patient Health Record. > > 0- Committed data is never physically deleted. > > 1- Inactive. 'Copy of data'. > EHR with patient records. > The patient moves to an other place and chances Healthcare Provider. > A copy of the EHR is sent to that HcP. > The original becomes inactive and can be consulted for legal, > administrative purposes, only. > The Patient record is labelled: inactive, read only for legal and > administrative reasons > > 2- Inactive. ‘Removal of data’ > The patient demands by force of law that all personal and health data is > removed. > The EHR becomes inactive and can only be consulted for legal, > administrative reasons > The Patient record is labelled: inactive, read only for legal and > administrative reasons > > 3- Active: Updating of data by third party (patient) > The patient demands a change in the data recorded. > Data recorded after one or more events are changed. > The original Compositions stay un altered. > A new version of the Composition (with the patient as author) is created. > > 4- Active, Update by original author > New facts indicate that previously entered data about an event was > incorrect. The mistake needs to be corrected. > A new version of the Composition is created. > Old data can be acted upon. The application needs to redress this fact. > > 5- Update before a Commit. > During data entry but before the Commit data can be changed always. > Versioning is NOT necessary. > > Gerard Freriks > +31 620347088 > [email protected] > > Kattensingel 20 > 2801 CA Gouda > the Netherlands > > On 3 Nov 2017, at 13:49, Thomas Beale <[email protected]> wrote: > > It's potentially not a completely wrong idea: it might be worth thinking > about a 'deleted' marker on the VERSIONED_OBJECT<T> type itself. As i noted > before though, i'd like to get a better idea of real scenarios where the > current model of deletion doesn't work properly before doing anything. > > - thomas > > > On 03/11/2017 02:36, Bert Verhees wrote: > > > In a versioned system there is no status for "deleted" necessary *inside* > a composition. The system itself marks the composition deleted. With this > in mind it seems to me the semantical meaning of the inside "deleted" > status is meant for something else. > > Bert > > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
