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. ;-)
Op zo 5 nov. 2017 16:12 schreef Bert Verhees <bert.verh...@rosa.nl>: > 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? > > Op zo 5 nov. 2017 07:06 schreef Sam Heard <sam.he...@oceaninformatics.com > >: > >> 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 <openehr-technical-boun...@lists.openehr.org> >> on behalf of Bert Verhees <bert.verh...@rosa.nl> >> *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 <pablo.pa...@cabolabs.com>: >> >>> On Thu, Nov 2, 2017 at 3:01 PM, Thomas Beale <thomas.be...@openehr.org> >>> 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 >>>> openEHR-technical@lists.openehr.org >>>> >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>> >>> >>> -- >>> Ing. Pablo Pazos Gutiérrez >>> e: pablo.pa...@cabolabs.com >>> 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 >>> openEHR-technical@lists.openehr.org >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical@lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
