# Scenarios for change type "deleted" **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2017-10-15 14:49 UTC **Views:** 7 **Replies:** 46 **URL:** https://discourse.openehr.org/t/scenarios-for-change-type-deleted/15494 --- ## Post #1 by @system Hi I'm trying to define a set of rules for a logical delete commit and have some gray areas that I'm not sure of. **1. commit after delete flow** [creation v1] => [modification v2] => [deleted v3] => ? Can a modification/amendment v4 happen after a delete? This is one of those cases that forks in the version tree can happen, since v2 is deleted by v3, but v1 can be forked and a commit of modification or amendment can happen on that branch. I'm considering the delete only affects a VERSION, not the whole VERSIONED_OBJECT. Can a delete logically delete the whole VERSIONED_OBJECT? On a lineal versioning scheme, I'm not sure if an amendment can happen after the delete. because the semantics of lineal versioning is I'm versioning v3 not v1 if I do a commit after v3. I think if a delete happens, that is like killing that branch, so no new versions can be added. Is that correct? What do others think? **2. delete on persistent compos** Looking at the specs, it is not clear to me how a delete would affect a persistent composition. This is an open question. This is also related with the previous case, since if a version is deleted on a persistent composition, there will be more commits for it after the delete, because it is persistent. **3. delete a non-trunk version** [creation v1] => [modification v2] => [amendment v3] => ... Let's say there are many modifications/amendments for a compo, can be persistent or event. What happens if a version in the middle of the version tree/line is deleted? Can that even happen? What happens with the created versions after that? In my head those versions created on the branch of a deleted version should also be deleted if deletes are accepted in the middle of the tree. The other rule can be only accept deletes on the latest versions. What do you think? --- ## Post #2 by @system Until we have a clear criteria for commits after delete, I'll use this: 1. lineal versioning (no branching) 2. "deleted" compositions can be "undeleted" using "modification" change type, since we don't have an "undelete" change type 3. if current latest version is "deleted" the composition won't appear on query results --- ## Post #3 by @system You would be able to import this structure into our implementation and it would work the same way\. Pieter --- ## Post #4 by @system Hi Pieter, What structure? --- ## Post #5 by @system well, a deletion is a deletion, logically. In a non-versioned system, the data object would literally disappear. In a versioned system, such as we have, the top version records the fact of deletion, which logically applies to the whole versioned object. it could, if in system A (say in hospital A), the Composition is logically deleted but in system B (clinic B) a copy of that Composition (say medications list) is modified with a new version; then if this modified Versioned object is copied back to system A, system A will see a branched tree, which communicates the fact that hospital A thinks the information is no longer there, but clinic B does have a version of this information. THis can only be resolved at the organisational level - i.e. by agreeing what is really going on with the medication list (or whatever the info object is) between the two HCFs. But - is there any real scenario where this could actually happen? I can't imagine System A really wanting to delete the medication list Composition. that's what it logically means doing. well as you point out, things might be ambiguous if two systems modify copies of the same versioned composition, and one of them does a logical deletion. We probably need to think about this more carefully and update the documentation. I at least would need to get a better understanding of the problem first i.e. real use cases. Well, deletion should really make the persistent composition act as if it wasn't there, except for queries in earlier time windows. So I would say a priori that further commits should be prevented, but - maybe someone is going to say: what if the deletion was an accident? Maybe there needs to be a lifecycle operation 'undelete' (or 'undo delete'). that can't happen - a deletion can only happen as the top version. If we were talking about Git or some other typical system, deletion makes it look like a file is actually gone, and subsequent commits will create a new file of the same name, but whose version lineage is disconnected from the previous one. We could add something to the spec to force something like that behaviour. - thomas --- ## Post #6 by @system I meant data using the criteria you outlined\. Regards, Pieter Bos --- ## Post #7 by @system 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 --- ## Post #8 by @system I shouldn't write in the middle of the night, while travelling. Of course the deleted status is in the version, not in the composition. Sorry for confusing reply. Have a nice day Bert --- ## Post #9 by @system 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 --- ## Post #10 by @system > about a 'deleted' marker on the VERSIONED_OBJECT type itself. That seems a clever idea. Because the whole version history would become out of sight. That is how it is used anyway. It is also like that in Github. If a file (object) is deleted from the repository it seems like completely vanished. Also all previous versions of the object. Of course going back in time makes it again visible and also the previous versions. --- ## Post #11 by @system 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 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #12 by @system 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](http://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 --- ## Post #13 by @system 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 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #14 by @system 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 --- ## Post #15 by @system 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. --- ## Post #16 by @system I do NOT dispute what patients can demand. Under all circumstances it is the author that is accountable for his actions. Even under Dutch Business law one needs to keep files for the Revenue Tax) offices. What is meant by the Privacy Law is that all data must be logically be ‘removed’. All health data must NOT show up. All business transactions need to be preserved. All accountable actions can be questioned in Public and Criminal law. Meaning, in my view, that the patient record is there but unavailable for the provision of health care. Meaning that either that record is tagged as ;inactive’ or the that the reading and writing rights are for the patient only. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #17 by @system (Health) Data never must be physically deleted. Facts happen and are recorded. But not always readable. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #18 by @system > > Hi I'm trying to define a set of rules for a logical delete commit and > have some gray areas that I'm not sure of\. > > \*1\. commit after delete flow\* > > \[creation v1\] => \[modification v2\] => \[deleted v3\] => ? > > Can a modification/amendment v4 happen after a delete? > > well, a deletion is a deletion, logically\. In a non\-versioned system, the > data object would literally disappear\. > Logical deletions don't make data disappear, even if it's not under a versioned system\. > In a versioned system, such as we have, the top version records the fact > of deletion, which logically applies to the whole versioned object\. > That sort of works on a lineal versioned system, the specs are not clear in terms of how to handle a deletion in a distributed versioned system\. I agree delete should be considered to affect the status of the whole versioned object, but on a branching scenario this is not so well defined or maybe can't be implemented at all \(see below \*\*\*\)\. The issue I see with versioning for deletion is that amendments, modifications, etc\. are defined at the same level of the deletions, and the other modification types apply to the latest version, not to the whole composition\. Considering this: shouldn't delete be specified on it's own, separated from other change types? I always had doubts about using a commit to delete something, and now I'm starting to understand why :\) > This is one of those cases that forks in the version tree can happen, > since v2 is deleted by v3, but v1 can be forked and a commit of > modification or amendment can happen on that branch\. > > it could, if in system A \(say in hospital A\), the Composition is logically > deleted but in system B \(clinic B\) a copy of that Composition \(say > medications list\) is modified with a new version; then if this modified > Versioned object is copied back to system A, system A will see a branched > tree, which communicates the fact that hospital A thinks the information is > no longer there, but clinic B does have a version of this information\. > \*\*\* That kind of contradicts the "deletion logically applies to the whole versioned object", since the versioned object is unique, independently of which system has a copy of a version from that versioned object\. On a branching case, the delete seems to only affect a branch\. > THis can only be resolved at the organisational level \- i\.e\. by agreeing > what is really going on with the medication list \(or whatever the info > object is\) between the two HCFs\. > Besides the delete case, that is the issue of merging branches, IMO is always an organizational issue\. We had another thread were we talked about lineal vs\. distributed/branching versioning\. > But \- is there any real scenario where this could actually happen? I can't > imagine System A really wanting to delete the medication list Composition\. > Change medication list for X and I think we will have cases\. If we don't have cases, why do we included this on the specs? A related issue, is if a delete happens by mistake, how can someone "undelete" if no more commits are accepted on that branch after the delete? I think it would be useful to accept commits, like amendment, because maybe the data is not incorrect, but the previous delete commit was incorrect\. In that sense, when a logical delete happens on a system, a good feature is to have a view of the deleted elements and allow users to undelete them, like a trash bin\. IMO if delete can be executed by a user, undelete should also be executed by a user, not by the organization\. > I'm considering the delete only affects a VERSION, not the whole > VERSIONED\_OBJECT\. > > Can a delete logically delete the whole VERSIONED\_OBJECT? > > that's what it logically means doing\. > > On a lineal versioning scheme, I'm not sure if an amendment can happen > after the delete\. because the semantics of lineal versioning is I'm > versioning v3 not v1 if I do a commit after v3\. > > I think if a delete happens, that is like killing that branch, so no new > versions can be added\. > > Is that correct? What do others think? > > well as you point out, things might be ambiguous if two systems modify > copies of the same versioned composition, and one of them does a logical > deletion\. We probably need to think about this more carefully and update > the documentation\. I at least would need to get a better understanding of > the problem first i\.e\. real use cases\. > Rethinking that, I'm not sure if killing a branch is correct, since I see the undelete case \(mentioned above\) happen if delete is allowed\. In terms of the spec, I'm worried about what the spec allows and try to fill the blanks the spec doesn't provide\. I'm not sure why allowing something in the spec if we don't have use cases to support that\. Maybe the easiest would be to remove the delete cases from the spec and delegate that to each implementation\. Some may support it, some may support undelete, some may apply the delete to the latest version, some may apply it to the whole versioned object, others will support logical and physical deletes, etc\. There are too many cases to define all of them in an unambiguous way\. > \*2\. delete on persistent compos\* > > Looking at the specs, it is not clear to me how a delete would affect a > persistent composition\. > > This is an open question\. > > This is also related with the previous case, since if a version is deleted > on a persistent composition, there will be more commits for it after the > delete, because it is persistent\. > > Well, deletion should really make the persistent composition act as if it > wasn't there, except for queries in earlier time windows\. So I would say a > priori that further commits should be prevented, but \- maybe someone is > going to say: what if the deletion was an accident? Maybe there needs to be > a lifecycle operation 'undelete' \(or 'undo delete'\)\. > That is exactly what I was thinking of while writing :\) But\! as I said, I'm not sure if delete/undelete should be handled at the change type level, it seems to be a concept on a different level than create/modification/amendment\. > \*3\. delete a non\-trunk version\* > > \[creation v1\] => \[modification v2\] => \[amendment v3\] => \.\.\. > > Let's say there are many modifications/amendments for a compo, can be > persistent or event\. > > What happens if a version in the middle of the version tree/line is > deleted? > > that can't happen \- a deletion can only happen as the top version\. > is that specified? > If we were talking about Git or some other typical system, deletion makes > it look like a file is actually gone, and subsequent commits will create a > new file of the same name, but whose version lineage is disconnected from > the previous one\. We could add something to the spec to force something > like that behaviour\. > In Git, If I checkout v2 on a new branch, and there are v3, v4, \.\.\., in the master branch\. If a file is deleted on the new branch, and I commit the branch, the file won't be there for that branch, and master \(v3, v4, \.\.\.\) won't notice about that\. All issues will happen when I try to merge my branch with master, there I need to decide if I keep or not the file that is a difference between the two branches\. The real issue here is now to merge, not the delete itself\. But, the semantics of a delete happening on a branch should be specified\. I think most implementation won't implement merging, so this case might not happen\. But if the specs support branching, the merging process and handling deletions on branches while merging should be specified\. --- ## Post #19 by @system Here is the a description by royal organization of medical institutions of the Dutch law for saving medical data. [https://www.knmg.nl/advies-richtlijnen/artseninfolijn/praktijkdilemmas-1/praktijkdilemma/hoe-lang-moet-ik-medische-dossiers-van-patienten-bewaren.htm](https://www.knmg.nl/advies-richtlijnen/artseninfolijn/praktijkdilemmas-1/praktijkdilemma/hoe-lang-moet-ik-medische-dossiers-van-patienten-bewaren.htm) It was years ago 10 years. It is now 15 years. Dutch law is always harmonised with European or UN law if there is such law on that level. There are two considerations. 1) The medical institutions want an end point for their responsibilities to keep data access able. 2) Patients have the right to clean up their history. The medical institution is not required to remove the data after 15 years but it has the right to do that. 10 years ago I wrote software to facilitate that for the largest GP software user group of the Netherlands. After those 15 years a patient can demand totally removal of every trace at a medical institution. So. This to close that part of the discussion. I did not read yet Pablo 's long reply. I will certainly do that maybe later today. I am again travelling. Best regards Bert --- ## Post #20 by @system Hi All Ideas from a clinical perspective: --- ## Post #21 by @system In the Netherlands as in many countries, if you change GP a patient is able to lose his medical history if he wants that. It is up to the patient to hand it over to the new GP. And after 15 years he can demand his previous GP to remove his records. From that point on all his medical history has gone. Is this different in the UK, where there is only one governmental health care provider? And how about Australia? --- ## Post #22 by @system Sorry for the sloppy text. It is typed on a phone with bad sight because of the small screen and also the sun glittering on it. But reading back I see that it is easy to understand it well. ;-) --- ## Post #23 by @Karsten_Hilbert The deadlines are different, and they are different for different "types" of medical data, and also for different age groups of the patient, but essentially this is what it's like in Germany as well\. Even more so, once a deadline has passed, providers would actually be obliged to pro\-actively delete old data \(likely even from records of active patients\) unless they deem it necessary for either legal self\-protection or for continued care\. No need for the patient to demand deletion\. However, nearly no one does that \(pro\-active deletion\)\. Karsten --- ## Post #24 by @system In the Netherlands the deadlines are more complicated also. I presented a simplified version of the regulations, for the discussion sake this is not important. In fact it is so the the health care provider loses the responsibility to maintain the data after 15 years of inactivity, and the patient can already demand for removal after 5 years. But it is different when the patient is under 18, and it is also different if the health care provider is in employer relation to the patient. I don't know what is meant there, but that is what the regulations say. However, both can agree that the data will be maintained for longer time, for example in case of hereditary diseases. --- ## Post #25 by @system Hi there, just a short remark: we were involved in a regional EHR (in the sense of a health information exchange network) project in the state of Lower-Saxony, Germany. While this might be a different use case, we clearly had to be able to physically delete patient data from all IHE XDS repos and registries in the case of a patient's withdrawal. So when we use openEHR for such a use-case, we still have the same requirement. Cheers, Birger --- ## Post #26 by @Karsten_Hilbert a\) The repositories were likely not the primary repositories    intended for immediate clinical care ?   in which case the deadlines don't apply b\) had you suspected that a withdrawing patient intends to sue    the health information exchange network you would likely have    had the right to retain data regardless But, yeah, physical deletion certainly seems necessary even if only, say, 50 years post mortem \.\.\. Karsten --- ## Post #27 by @system Hi Karsten, a) these repos are not the primary sources of the data. Hence, the deadlines do not apply! b) Implementing such a process was demanded by the state data protection commissioner. I'm not sure how realistic this would be, but such a network heavily relies on patients' trust. If there is doubt, you lose. Besides: we implement openEHR in a distributed data warehouse scenario. Most data will be integrated locally from application systems. To be able to share data with other sites, we need to consider patients' consent. If a patient withdraws, we don't have any purpose to keep this 'secondary use data' within the data warehouse/openEHR system. Besides the legal questions, being able to physically delete data from such a database is also necessary for practical development and maintenance reasons. For operative systems, this is a whole different story. I recently was told that physically deleting records should not be possible when you want your software to be certified as a medical product according to German law. Birger --- ## Post #28 by @Karsten_Hilbert Hi Birger, as a GP in Germany I know what you are talking about :\) > b\) Implementing such a process was demanded by the state data protection > commissioner\. I'm not sure how realistic this would be, but such a network > heavily relies on patients' trust\. If there is doubt, you lose\. Assuming a patient intends to sue the network it would have had the right to retain any patient data it needed for legal proceedings, regardless of whether the patient requested deletion\. Say, to prove a given document arrived in the repository at a given time or was passed on at another given time or some such\. > If a patient > withdraws, we don't have any purpose to keep this 'secondary use data' within > the data warehouse/openEHR system\. Except for: see above\. > For operative systems, this is a whole different story\. I recently was told > that physically deleting records should not be possible when you want your > software to be certified as a medical product according to German law\. I know :\-\) and that is quite contrary to what the BDSG demands, so German law contradicts German law\. However, the no\-deletion policy is pretty much a scare tactics \(by over\-interpretation\) used by German EHR/document archive vendors desiring to sell their "solutions" to German doctors\.\.\. Karsten --- ## Post #29 by @system Dear all, It is time to reflect on the status of any data in any EHR, local or shared. 1- Documenting any fact in a data collection is an event with legal consequences. There always is the obligation to document what one has done: adding, reading, deleting, changing the status, etc. A log-file documents this. 2- Physical deletion is NOT possible. During the life cycle of data data collections are backed-up. This can be in write once, read many times, media. Sometimes complete databases are replicated as back-up. 3- Only logical deletion is possible by changing the status: tagging data or by changing the ACL of that data item. Observe that changing the status is a legal act that needs to be documented. 4- All data items that are entered in to a EHR data collection have a lifecycle: new inactive data, evaluation, active health relevant data, evaluation, plans, actions or new inactive data, evaluation, active administrative relevant data, evaluation, plans, actions. 5- Health and Administration relevant data can be declared by the HcP entering the data: de novo or re-used. 6- Next to life cycles of data items, there are life cycles of data item collections. 7- During the life cycle of any data item or data item collection new data items and/or data item collections are generated as re-used data. This implies that data is copied and can be sent and stored else where. 8- When patients request the removal of data-items or data collections all legal events are and have to stay documented. They no longer can be read for the provision of healthcare either by changing the Access Control List or are tagged to be in-active. All health and administrative related data and all data that is backed-up, and all data sent to others stay in their data collections. 9- Because of legal reasons or because of regulations any 'logically removed' data could be read. 10- Finally the Ross Anderson/BMA Security Policy Principles Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #30 by @Karsten_Hilbert > 2\- Physical deletion is NOT \.\.\. \.\.\. easy and often practically next to impossible\. > possible\. During the life cycle > of data data collections are backed\-up\. This can be in write > once, read many times, media\. Sometimes complete databases > are replicated as back\-up\. While true it draws blank stares from legal or political\. So we need to declare "deleted" to mean "deleted\-as\-much\-as\-possible"\. Karsten --- ## Post #31 by @system Small example. As GP I had scanned early 1990’s to CD’s all ‘Green cards’, meaning patient records. I can not remove these files on write-only media. But logically they were removed because they were all archived and stored in a vault. My EHR-system had no access to these scans. All this might give frowns by the legal profession. Logical deletion is possible at best. Logical deletion means that that data no longer is actively used in health care provision processes. Absolute and full Physical deletion many times is impossible, or not practical. Gerard Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #32 by @system Gerard, I think there is not much disagreement here\. In our project, we had to physicially delete from our XDS repos and the registry\. However, we would keep the ATNA logging files and the database backup\. This might sound a bit inconsistent but that has been the reality in our state\. While I agree with your statements regarding physical deletes, I still consider the delete in our use\-case not as "logical" because the data objects were really to be deleted from the databases of the operational systems\. The vendor from Austria had to change their IHE solution to physically delete the data instead of just flagging it\. What else is to say? There cleraly are use\-cases for openEHR that go beyond the classic EHR scenarios\. Therefore, there need to be ways described by the spec to support physical deletes \(in the sense of the example given above\) as well as logical deletes\. Best, Birger There should still be a way to differen \) but you are certainly right that --- ## Post #33 by @Karsten_Hilbert > Small example\. > > As GP I had scanned early 1990’s to CD’s all ‘Green cards’, meaning patient records\. > I can not remove these files on write\-only media\. Oh, you can, but it is not feasible: Re\-read all CDs, delete from recovered data any data that needs to be deleted, destroy old CDs, burn new CDs\. > Logical deletion is possible at best\. > Logical deletion means that that data no longer is actively used in health care provision processes\. > Absolute and full Physical deletion many times is impossible, or not practical\. Exactly, the latter\. An example for \*you\* are unable \(as opposed to \*it\* is not possible\):   Your CDs were handed over to a data keeping company to   which you don't have access \(say, it went bankrupt\)\. Under German law you might well be responsible for a\) having made sure that company complies with German law, and b\) you may \*still\* potentially be liable today\. Case in point: under German law when a doctor's children inherit \(\!\) patient charts hey automatically become the legally responsible custodians of the records and become, among other obligations, liable to litigations for privacy breaches both by the parent they inherited from and also themselves \! Yes, \*non\-doctors\* may fall under doctor\-patient privacy laws just because they become heirs to a former GP office's patient charts\.\.\. I doubt any such crazy thing is possible anywhere else\. Karsten --- ## Post #34 by @system the deleted marker is for other (more boring) scenarios entirely - it's just about content, not about moving / removing EHRs, which we also have to be able to do, but which is another question... specification of an EHR archive does not yet exist in openEHR, and you are right, that's the place for this kind of thing. But, we wouldn't want to solve everything on day 1... - thomas --- ## Post #35 by @system > 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\. EHR\_STATUS has 2 Boolean flags \- is\_modifiable and is\_queryable, which can be both turned off for these kinds of EHRs\. If people think we need more flags, they can be proposed to be added to this structure\. > 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\. exactly right\. This is one of the drivers for the openEHR versioning system in fact\.\.\. \- thomas --- ## Post #36 by @system just to be clear, we are talking about (at least) 3 different things: --- ## Post #37 by @system 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 --- ## Post #38 by @system The question is in how far should openehr define a system. Should also describe an archival system? Should it describe also how to handle physical deletion? And why should it describe that? It can become harder for system-builders to reach OpenEHR conformance. I think this is a wrong direction. OpenEHR defines a logical semantic flexible datastructure. And a query language. It does not even define on which way to achieve that. The technical details are implementers business. I think OpenEHR does not need a deletion flag, as I wrote before, that is describing a technical solution for archiving. I must excuse myself,I am not able to participate more in this discussion this week because I am onholiday Best regards. Bert --- ## Post #39 by @system 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 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #40 by @Karsten_Hilbert Given the fact that ACLs are ephemereal in many sorts of ways I can easily understand the desire for physical deletion \(but I agree with you that it is next to impossible under many circumstances\)\. Best, Karsten --- ## Post #41 by @system Restricting the reading, and processing, for use outside the provision of healthcare or labelling it as restricted NOT for use in healthcare are two alternatives for ‘Logical Deleting’. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #42 by @Karsten_Hilbert > Restricting the reading, and processing, for use outside the provision of healthcare or labelling > it as restricted NOT for use in healthcare are two alternatives for ‘Logical Deleting’\. Sure\. But\. What isn't there can't be breached\. What is, will be\. Karsten --- ## Post #43 by @system I just received ab email about this. In Dutch from the Dutch Authority Privacy (Autoriteit Persoonsgegevens ) The DPIA mentions very explicitly right on correction and right on removal. Else the system owner will be fined. It is European law. No room for discussions or ethical considerations. Just law. The KNMG, Royal Dutch Society for Medical Affairs states the same. They do not say logical or physical removal, they just say removal. If I was responsible. I would know how to be sure to do the right thing. I guess everybody else also knows what to do. --- ## Post #44 by @system Always it is possible to cheat whatever. But it nneds a criminal mindset to do just that. what one is not supposed to do. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #45 by @system If someone wants to read that email. I can forward it, it is in Dutch that is why I don't post it here. Next may, 2018, the new European privacy regulations will become effective. --- ## Post #46 by @system How is ‘ removal’ defined? In my thinking, it means the right to have data labelled such that is NOT used in the provision of healthcare. Copies made in the past, can not easily be removed, all the times. Data shared with third parties can not easily be removed. Data that is acted upon, can not easily be removed. Data that is re-used for administrative purposes or legal reporting can not easily be removed. Think of use of data in legal proceedings, used for administrative purposes, data logged in the log-file. The law and its regulations (based on EU law) can write what they like. Reality, technology, choices made in the past, will never change in the sense that all data can physically be removed. At best it is removed logically and locally, meaning it is not allowed to play a role in the provision of healthcare in the future. That is and stays my opinion. GF Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #47 by @system @all I'll try to summarize all your comments into a requirements document on the wiki, besides opinions and interpretations, openEHR has to satisfy these use cases. @Thomas please check my answer from Nov 4th, a. we might need to add more change types, b. maybe separate strict change types from delete cases, c. define the semantics of delete/undelete in the specs, d. clarify how a delete works in a branched versioning environment, also on the specs. What do you think? Best, PP. --- **Canonical:** https://discourse.openehr.org/t/scenarios-for-change-type-deleted/15494 **Original content:** https://discourse.openehr.org/t/scenarios-for-change-type-deleted/15494