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. Op za 4 nov. 2017 21:18 schreef Bert Verhees <[email protected]>: > Gérard, I think you are wrong. A patient in the Netherlands can require > under specified conditions total physical and logical removal of his data > from a health care information system . > > If you want I can represent you a link to the law - text which says so, > but because that is in Dutch, and therefor not readable for others, and > also not interesting for others I rather take that communication to private > level instead of public discussion group level. > > Best regards > Bert Verhees > > Op za 4 nov. 2017 18:48 schreef GF <[email protected]>: > >> Even when the patient wants all data to be removed, this means removeal >> in the context of the provision of helath care. >> For legal and administrative purposes the data can NOT be removed but be >> available for these non-healthcare provision related circumstances. >> One needs a label ‘deactivated’ (for health purposes. >> >> Remember: Even when the patient has left the author (HcP) has >> administrative and legal responsabilities. He is accountable for many years >> because fo actions taken. He needs to be able to defend himself. >> >> GF >> >> >> Gerard Freriks >> +31 620347088 >> [email protected] >> >> Kattensingel 20 >> 2801 CA Gouda >> the Netherlands >> >> On 4 Nov 2017, at 17:20, Bert Verhees <[email protected]> wrote: >> >> 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 >> >> >> _______________________________________________ >> 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
