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]>: > On Thu, Nov 2, 2017 at 3:01 PM, Thomas Beale <[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] >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> > > -- > Ing. Pablo Pazos Gutiérrez > e: [email protected] > p: +598 99 043 145 > skype: cabolabs > <http://cabolabs.com/> > http://www.cabolabs.com > https://cloudehrserver.com > Subscribe to our newsletter <http://eepurl.com/b_w_tj> > _______________________________________________ > 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
