Re: Scenarios for change type "deleted"

2017-11-06 Thread Bert Verhees 
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

Op ma 6 nov. 2017 15:40 schreef Bert Verhees :

> 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
>
> Op ma 6 nov. 2017 15:11 schreef Thomas Beale :
>
>>
>>
>> On 04/11/2017 18:38, Bert Verhees wrote:
>>
>> 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.
>>
>>
>> just to be clear, we are talking about (at least) 3 different things:
>>
>>- *logical content deletion*, e.g. I want to 'wipe out' my second
>>homeopathic Care Plan that is no longer relevant because I stopped
>>believing in homeopathy
>>- *archival of EHR*: I want to move the EHR to an archive system that
>>allows access, querying (or at least extraction), but separate from
>>operational EHRs
>>- *physical deletion of EHR from entire system*: nuke this EHR
>>
>> The delete marker in the current model only applies to the first one.
>>
>> To support archival, we need to know what we think the archival workflow
>> will be. Let's say we defined that, then I can imagine adding a new Boolean
>> flag to EHR_STATUS called e.g. archived or ready_for_archival or similar.
>> THis flag would prevent the system from 'seeing' the EHR even if it was not
>> yet in the physical archive, and it would enable an archival admin process
>> to know that it really can archive this EHR. When you think about it, a
>> flag won't be enough, it needs to be some sort of signed 'consent for
>> archiving' concept.
>>
>> For the third scenario, another flag may make sense like
>> 'ready_for_deletion', but again, we need to study the needed workflow in
>> detail to really know what changes to the models are needed.
>>
>> - thomas
>> ___
>> 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

Re: Scenarios for change type "deleted"

2017-11-06 Thread Bert Verhees 
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

Op ma 6 nov. 2017 15:11 schreef Thomas Beale :

>
>
> On 04/11/2017 18:38, Bert Verhees wrote:
>
> 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.
>
>
> just to be clear, we are talking about (at least) 3 different things:
>
>- *logical content deletion*, e.g. I want to 'wipe out' my second
>homeopathic Care Plan that is no longer relevant because I stopped
>believing in homeopathy
>- *archival of EHR*: I want to move the EHR to an archive system that
>allows access, querying (or at least extraction), but separate from
>operational EHRs
>- *physical deletion of EHR from entire system*: nuke this EHR
>
> The delete marker in the current model only applies to the first one.
>
> To support archival, we need to know what we think the archival workflow
> will be. Let's say we defined that, then I can imagine adding a new Boolean
> flag to EHR_STATUS called e.g. archived or ready_for_archival or similar.
> THis flag would prevent the system from 'seeing' the EHR even if it was not
> yet in the physical archive, and it would enable an archival admin process
> to know that it really can archive this EHR. When you think about it, a
> flag won't be enough, it needs to be some sort of signed 'consent for
> archiving' concept.
>
> For the third scenario, another flag may make sense like
> 'ready_for_deletion', but again, we need to study the needed workflow in
> detail to really know what changes to the models are needed.
>
> - thomas
> ___
> 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

Re: Scenarios for change type "deleted"

2017-11-06 Thread Thomas Beale 



On 04/11/2017 18:38, Bert Verhees wrote:


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.




just to be clear, we are talking about (at least) 3 different things:

 * *logical content deletion*, e.g. I want to 'wipe out' my second
   homeopathic Care Plan that is no longer relevant because I stopped
   believing in homeopathy
 * *archival of EHR*: I want to move the EHR to an archive system that
   allows access, querying (or at least extraction), but separate from
   operational EHRs
 * *physical deletion of EHR from entire system*: nuke this EHR

The delete marker in the current model only applies to the first one.

To support archival, we need to know what we think the archival workflow 
will be. Let's say we defined that, then I can imagine adding a new 
Boolean flag to EHR_STATUS called e.g. archived or ready_for_archival or 
similar. THis flag would prevent the system from 'seeing' the EHR even 
if it was not yet in the physical archive, and it would enable an 
archival admin process to know that it really can archive this EHR. When 
you think about it, a flag won't be enough, it needs to be some sort of 
signed 'consent for archiving' concept.


For the third scenario, another flag may make sense like 
'ready_for_deletion', but again, we need to study the needed workflow in 
detail to really know what changes to the models are needed.


- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Scenarios for change type "deleted"

2017-11-06 Thread Thomas Beale 



On 04/11/2017 15:47, GF wrote:
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


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Scenarios for change type "deleted"

2017-11-06 Thread Thomas Beale 



On 04/11/2017 14:20, Bert Verhees 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..




the deleted marker is for other (more boring) scenarios entirely - it's 
just about /logically removing /content, not about moving / removing 
EHRs, which we also have to be able to do, but which is another question...


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.



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
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Scenarios for change type "deleted"

2017-11-06 Thread Karsten Hilbert 
On Mon, Nov 06, 2017 at 11:57:28AM +0100, GF wrote:

> 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
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Scenarios for change type "deleted"

2017-11-06 Thread Birger Haarbrandt 

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

Am 06.11.2017 um 11:57 schrieb GF:

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
gf...@luna.nl 

Kattensingel  20
2801 CA Gouda
the Netherlands

On 6 Nov 2017, at 11:43, Karsten Hilbert > wrote:


On Mon, Nov 06, 2017 at 11:38:23AM +0100, GF wrote:


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
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net 


E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

___
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



--
*Birger Haarbrandt, M.Sc.*

Peter L. Reichertz Institut für Medizinische Informatik
Technische Universität Braunschweig und
Medizinische Hochschule Hannover
Carl-Neuberg-Str. 1
30625 Hannover

T +49 (0)531 391-2129
F +49 (0)531 391-9502
birger.haarbra...@plri.de
http://www.plri.de

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Scenarios for change type "deleted"

2017-11-06 Thread GF 
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
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 6 Nov 2017, at 11:43, Karsten Hilbert  wrote:
> 
> On Mon, Nov 06, 2017 at 11:38:23AM +0100, GF wrote:
> 
>> 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
> -- 
> GPG key ID E4071346 @ eu.pool.sks-keyservers.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> ___
> 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

Re: Scenarios for change type "deleted"

2017-11-06 Thread Karsten Hilbert 
On Mon, Nov 06, 2017 at 11:38:23AM +0100, GF wrote:

> 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
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org