Hi All Ideas from a clinical perspective:
1. A patient or clinician may want to delete a composition from one instance of a health record. For example, a correspondence about a surgical operation (which is considered sensitive by a patient) might come to a mental health service and be added to their record at that site. The patient may ask for it to be removed as it is not relevant at that location. 2. A patient may want something deleted from their ‘virtual EHR’ or single logical record. This will be more difficult and should be deemed to be an error of some sort, or have expired from a medicolegal point of view. A label like ‘ personality disorder’ entered by an inexperienced nurse at an emergency clinic might be an example. Clearly propagating the update of the entire EHR will depend on the governance of each instance. We will have to have very clear rules for this to be automated and safe. It will, however, always be possible to return the record to the state it was at any given interaction. 3. A patient may want to delete (or recall) all propagated copies of a composition. This would appear to be reasonable, especially in an “opt out” situation like we have in Australia. This does not have the medicolegal issue that item 2 has as the record will be held in the ecosystem in which it was created. However, a trust system will still be required or very strong governance of who can propagate such a deletion. Cheers, Sam Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 ________________________________ From: openEHR-technical <[email protected]> on behalf of Bert Verhees <[email protected]> Sent: Sunday, November 5, 2017 3:15:09 PM To: For openEHR technical discussions Subject: Re: Scenarios for change type "deleted" 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 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 Op zo 5 nov. 2017 00:26 schreef Pablo Pazos <[email protected]<mailto:[email protected]>>: On Thu, Nov 2, 2017 at 3:01 PM, Thomas Beale <[email protected]<mailto:[email protected]>> wrote: On 15/10/2017 12:49, Pablo Pazos wrote: 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. - thomas _______________________________________________ openEHR-technical mailing list [email protected]<mailto:[email protected]> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Ing. Pablo Pazos Gutiérrez e: [email protected]<mailto:[email protected]> p: +598 99 043 145 skype: cabolabs [https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ] <http://cabolabs.com/> http://www.cabolabs.com<http://www.cabolabs.com/> https://cloudehrserver.com<https://cloudehrserver.com/> Subscribe to our newsletter<http://eepurl.com/b_w_tj> _______________________________________________ openEHR-technical mailing list [email protected]<mailto:[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
