# removal of data

**Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156)
**Created:** 2006-04-16 09:13 UTC
**Views:** 6
**Replies:** 46
**URL:** https://discourse.openehr.org/t/removal-of-data/14536

---

## Post #1 by @system

Let me enlighten my question

Bert Verhees schreef:
> Thanks again for the help with the authorization\-question, I was lost in the wrong document of the specs\.
> I must say, reading the specs, really is not something for a rainy afternoon, but it is worth it\.
>
> I have another question, probably it also is in the specs, but I didn't find it\.
> \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
> Is it possible to delete a composition in a way that is not traceable anymore?

What happens on deletion of a composition, will there be created a new version, which indicates the non\-existence, and are old versions kept?
Or is it possible to delete all versions of a compositions\.

I guess, this is not possible, but I am not sure

\(I mean this when using the openehr structure\)

Thanks,
Bert Verhees

---

## Post #2 by @system

There is the situation of an EHR-system and the situation of an EHR-extract.

In an EHR-system physical deletion MUST NOT be possible. Deletion after attestation will be in all situations legally not allowed.
Because of rights citizens have it must be possible to logically delete them.
A new version must be created depicting the new situation.

When information is sent between two EHR-systems the EHR-extract is used.
Here are two situations:
- a handover of a complete patient file because of a change of practitioner.
- a document produced by one practitioner is transported to an other practitioner.

In the first situation the complete record is transported. Including all logically deleted parts.
In the second situation only the 'active' parts are transported. All logically deleted parts are not sent in the EHR-extract.

What is exactly in the *open*EHR specs I don't know.

Gerard

-- <private> --

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 654 792800

---

## Post #3 by @mikael

Gerard Freriks wrote:

> \[\.\.\.\]

> In an EHR\-system physical deletion MUST NOT be possible\.
> Deletion after attestation will be in all situations legally not allowed\.

In fact that isn&#39;t true in Sweden\! There are some very special occasions
when a health record or parts of it should be able to be completely
destroyed as if the information never had been written and signed\. The
situation happens very seldom, but still we need to be able to handle it\.

I have only access to Sweden’s health record law \(SFS 1985:562\) in Swedish
tonight, but for the \(few\) people on the list that understand Swedish is
below the paragraph which states this special occasion cited\.

17 § På ansökan av patienten eller någon annan som omnämns i en
patientjournal får Socialstyrelsen förordna att journalen helt eller delvis
skall förstöras\. Förutsättning för detta är dels att godtagbara skäl anförs
för ansökan, dels att patientjournalen eller den del därav som skall
förstöras uppenbarligen inte behövs för patientens vård och dels att det
från allmän synpunkt uppenbarligen inte finns skäl att bevara journalen\.

Innan ansökan slutligt prövas, skall den som ansvarar för patientjournalen
beredas tillfälle att yttra sig\.

Om Socialstyrelsen har avslagit en ansökan om förstöring av en
patientjournal, får beslutet överklagas hos allmän förvaltningsdomstol\. Om
Socialstyrelsens beslut innebär bifall till en sådan ansökan, får beslutet
inte överklagas\.

Prövningstillstånd krävs vid överklagande till kammarrätten\. Lag \(1995:61\)\.

&nbsp;&nbsp;/Mikael Nyström

---

## Post #4 by @Allen_O_Neill

For the non Swedish speakers \.\. here&#39;s a rough translation \(not exact but to
give the general gist\!\)\.\.\.

&quot;The patient or any other person that is mentioned in the patients file, can
apply or can ask to have the file, or parts of the files destroyed\. \[the
government office\] will decide if the file or part of file will be
destroyed\. For this to happen there has to be good acceptable reasons\.
The reasons would be that the file or the part of the file that are asked to
be destroyed are not obviously needed for the patient care, or from a
general point of view there is no obvious reasons to keep it\. Before the
application to have the \[file / part of\] destroyed, the person who is
responsible for the file has the chance to make comment\. If \[the government
office\] has dismissed a request to destroy the patients file, the decision
can be appealed in a general court of law\. If \[the government office\]
consents with the request \(to destroy the file or part of the file\), the
decision can not be appealed\. \(then something about you can appeal to
another court but you must have a permit\)\.&quot;

Hth,

Allen\.

---

## Post #5 by @Sam

Hi everyone

In fact both situations are available in openEHR. In the general case and without access to the repository it is only possible to create a new version which has no information and mark it as deleted. This is generally true for health information as it is still necessary to reconstruct the record for medico-legal purposes. If a part of the record is to be deleted as described in the Swedish text, then the file would have to be manually altered with someone with administrator access to the EhrRepository. In fact this would not be removed from archives or backups unless these were also managed. This functionality will be controlled by the vendor of the EhrRepository itself.

The former should give the person sufficient privacy in all but the most dire situations - the latter is possible.

Cheers, Sam

Allen O'Neill wrote:

---

## Post #6 by @system

I agree that is very seldom.

For many (technical) reasons it is completely impossible to remove all information as if it was never written.

for example:
- The information is communicated with others before it has to be removed
- the information is part of an archive on CD-ROM
- the information is indexed somewhere

Laws (as far as I know) cannot force healthcare providers to change the history of things.
Each healthcare provider has the obligation to document itself.
The law, my personal opinion, most often is written by legal persons.
Therefor what they prescribe is legally correct but many times impossible to execute.

My solution is to translate the legal terms in a requirement to LOGICALLY remove the information,
It is there.
But it is not used any longer.

Gerard

-- <private> --

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 654 792800

---

## Post #7 by @system

You mean bypassing the API and hacking in the database itself?

Bert

---

## Post #8 by @system

First, I want to thank everyone for their contributions on this discussion, it
helped me a lot\.

Now I discovered today, there is a law in the Netherlands which obliges
care\-takers \(GP&#39;s etc\) to remove all records for patients demanding this
\(within 3 months of demand, and after some years of not visiting that GP\)

I guess the best way of doing this is removal of the demographic record, but
maybe we get key\-violations, which then is not such a good idea\.

if I am right in the above \(I am not a lawyer\) there should be an API to do
this\. is there such an API?

Bert

---

## Post #9 by @mikael

I know that it is very hard to completely remove \(parts of\) an electronic
health record, but the law is still the law and we therefore must follow it\.
It happens now and then in Sweden that we must remove \(parts of\) an
electronic health record completely \(and not only logically\)\. The removal is
mainly done manually and to a high cost\. In Sweden we therefore also need to
record where we send electronic health record data and where we back the
data up\.

&nbsp;&nbsp;/Mikael Nyström

---

## Post #10 by @William_E_Hammond

Maybe we Americans are the only ones who screw up, but one of the reasons I
have to remove data from the EHR is when the data manages to get into the
wrong patient&#39;s record\.  Unfortunately for every right way to do something,
there are many wrong ways\.  I have said that if I did not have to design
for human errors, I could do the work 4 times as fast\.

Result, we need to have the ability to remove data physically and
completely from the EHR\.  To leave the data is a breach of privacy\.

Ed Hammond

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Mikael Nyström
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;mikny@imt\.liu\.se&gt;              To:       &lt;openehr\-technical@openehr\.org&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Sent by:                        cc:
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;owner\-openehr\-technical@        Subject:  RE: removal of data
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;openehr\.org
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;04/18/2006 04:53 AM
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Please respond to
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;openehr\-technical
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
I know that it is very hard to completely remove \(parts of\) an electronic
health record, but the law is still the law and we therefore must follow
it\.
It happens now and then in Sweden that we must remove \(parts of\) an
electronic health record completely \(and not only logically\)\. The removal
is
mainly done manually and to a high cost\. In Sweden we therefore also need
to
record where we send electronic health record data and where we back the
data up\.

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/Mikael Nyström

---

## Post #11 by @system

Bert,

Ik heb dat nergens gelezen.

Het verwijderen is altijd onderworpen aan de beslissing van de arts.

De termijn waarna gegevens moeten worden verwijderd is nu 15 jaar.
En dan is het ook nog onderworpen aan beperkende bepalingen.

Universitaire klinieken moeten het 115 jaar bewaren.

Kijk op:
[http://www.zonmw.nl/nl/programmas/programma-informatie/informatie-en-communicatietechnologie-in-de-zorg-icz.html](http://www.zonmw.nl/nl/programmas/programma-informatie/informatie-en-communicatietechnologie-in-de-zorg-icz.html)
voor info van het Juridisch lab.

Gerard

-- <private> --

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 654 792800

---

## Post #12 by @sebastian.garde

Dear Ed,

I don&#39;t believe that this is a case for physically deleting data in the record:
If data was attributed to the wrong patient, for medico\-legal reasons it still must be posssible to recreate the record exactly the way a physician saw it during that period of time\. You however should delete it logically and give a reason for this\.

Sebastian

---

## Post #13 by @Dierckx_Walter

Dear all,

To remove (or even change clinical data without keeping a track of the original registration) is due to the national legislations.

In this respect I think it is advisable to leave this issue “open” – meaning that some kind of parameter setting should be available to manage the clinical data handling. And let’s wait and see what the European directions will include …

Regards,

Walter Dierckx.

---

## Post #14 by @system

For the Dutch readers amongst us, Dutch law very explicitly demands the
possibility for destroying a patients record

See http://www.hulpgids.nl/wetten/wgbo-tekst.htm

---

## Post #15 by @thomas.beale

openEHR supports logical deletion of content in the following way \(see updated Common IM \- change\_control section of  http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/common_im.pdf):

\- a new Version is created
\- VERSION\.data is removed\. The current way of thinking is that there has to be a data item there e\.g\. a Composition, but with its own content removed\. However, I believe we should make VERSION\.data 0\.\.1 to allow complete deletion of the item\. Either way should work, but the first way seems artificial to me\.
\- VERSION\.lifecycle\_state is set to deleted \(there is a term code for this in the openEHR terminology\)
\- commit as usual

The result is that the view of the EHR now doesn&#39;t include the Item corresponding to the deletion just made \(assuming your software correctly looks at the lifecycle state and handles deleted data properly\)\.

Sam mentioned that to satisfy the Swedish requirement, a low level database hack would have to be made\. This is true\. openEHR is designed like Subversion and similar things, as far as versioning is concerned\. As you will see, most designers of such repositories \(us included\) don&#39;t believe in making physical removal a normal option \(see e\.g\. the Suubversion FAQ on this \- http://subversion.tigris.org/faq.html#removal); but nevertheless, it is always possible at some level\. The usual approach is to make it a special administrator task, with no visible API that would allow normal software to do it\. This doesn&#39;t mean however that such a procedure is not defined, just that it is probably implemtation specific due to being low level \(removing stuff from MySQL would be different from doing it in say Oracle\)\.

There is also a kind of deletion allowed for an entire patient record, due to the move scenario that Gerard mentions below\. This is described in detail in the latest Common IM draft\. Note that this is easy to do, because you are not selectively removing something from within an EHR, which is the limit of coherent versioning, you are simply deleting the whole thing\.

\- thomas beale

Gerard Freriks wrote:

---

## Post #16 by @thomas.beale

Mikael Nyström wrote:
> I know that it is very hard to completely remove \(parts of\) an electronic
> health record, but the law is still the law and we therefore must follow it\.
> It happens now and then in Sweden that we must remove \(parts of\) an
> electronic health record completely \(and not only logically\)\. The removal is
> mainly done manually and to a high cost\. In Sweden we therefore also need to
> record where we send electronic health record data and where we back the
> data up\.
>
> &nbsp;&nbsp;/Mikael Nyström
>&nbsp;&nbsp;

even though it can always be done \(as per my last past\), I think it will become a meaningless act, as systems become more distributed, and more caching occurs; more internet backups are done, patients have their own copies etc\. How can anyone be sure the data is ever really deleted?

One thing openEHR does is provides the built in option to have no patient ids whatsoever in the EHR \- to connect a person to an EHR, there would have to be a separate index of person\_id, ehr\_id\. It doesn&#39;t have to be this way \- there are other levels of privacy you can choose\. See the &quot;generic&quot; package section of http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/common_im.pdf for some discussion on this\.

By the way, we use the feedback in these discussions to improve the documents, so you will find a better description of logical deletion in the next draft to go up\.

\- thomas

---

## Post #17 by @thomas.beale

William E Hammond wrote:
> Maybe we Americans are the only ones who screw up, but one of the reasons I
> have to remove data from the EHR is when the data manages to get into the
> wrong patient&#39;s record\.  Unfortunately for every right way to do something,
> there are many wrong ways\.  I have said that if I did not have to design
> for human errors, I could do the work 4 times as fast\.
>
> Result, we need to have the ability to remove data physically and
> completely from the EHR\.  To leave the data is a breach of privacy\.
>&nbsp;&nbsp;

Hi Ed,

I am glad you brought that one up\.\.\.we also thought about this scenario specifically in openEHR, based on evidence e\.g\. in Queensland state health service \- about 4m consumers \- there are from memory 200 merges a week and 3 demerges \- which is the scenario you mention\. So it&#39;s part of life with current systems, human error etc\. The merge situation \(1 patient has 2 records assigned to them, then we find out later it is the same person\) is described in some detail in section 6\.2\.7 of http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/common_im.pdf \. So far we have chosen to use logical deletion to perform the demerge, which satisfies medico\-legal reqirements \(e\.g\. for the physician&#39;s protection, a drug they give might be based on the evidence of a problem or diagnosis wrongly put in the patient&#39;s record; removing that information later leaves the physician with no legal protection\), but might not satisfy privacy requirements, if there is an easy way for someone to see patient B&#39;s information \(which they normaly don&#39;t have access to\) inside patient A&#39;s record \(which they are allowed to see\)\. But most likely the wrongly inserted information will appear to be patient A information \- there won&#39;t be any indication that it was actually about patient B \(assuming it was entered by a physician or nurse wrongly using patient A&#39;s EHR\)\. There might be other ways it could get there, but in openEHR, if the info was put in record A, there is no way to know it was meant for somewhere else\.

\- thomas beale

---

## Post #18 by @Karsten_Hilbert

Well, a common scenario would be a scan of a discharge
letter being attached to the wrong patient\.

Karsten

---

## Post #19 by @system

Dear all,

In the paper world, I know, it is clear.

A document with legal implications can never be destroyed without any trace.
A document with legal implications can be removed from a registry in one place and moved to a special registry, folder, cupboard, etc.

And the same is true for data entered (and attestedand therefor with leagal implications) in the paper file.
What is in it, stays in it.
It is explicitly forbidden to remove, scratch out, made unreadable, etc.
The only way is to annotate incorrect data/information and not use it or send it to others.

In other words, in the paper world in the Netherlands, we only know the logical delete.

What has happened, has happened, we can not falsify history, is the bottom line.

Gerard

-- <private> --

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 654 792800

---

## Post #20 by @thomas.beale

Karsten Hilbert wrote:

---

## Post #21 by @system

Gerard Freriks schreef:
> Dear all,
>
> In the paper world, I know, it is clear\.
>
> A document with legal implications can never be destroyed without any trace\.
> A document with legal implications can be removed from a registry in one place and moved to a special registry, folder, cupboard, etc\.
>
> And the same is true for data entered \(and attestedand therefor with leagal implications\) in the paper file\.
> What is in it, stays in it\.
> It is explicitly forbidden to remove, scratch out, made unreadable, etc\.

Sorry Gerard, in my opinion you are wrong, article 455 of WGBO \(law of protection of personal data\) states very explicitly that a patient can demand destroying of his record\.
I wrote this two days ago\. The holder of this record must obey within 3 months after demanding, and there are some exclusions, but the fact is that there are situations where those exclusions do not apply\.
So permanent deletion of records is a demand of the law\.

Bert

---

## Post #22 by @system

Dear Bert,

Reading again a thick report by our Royal Dutch Medical Association about the interpretation of this pecific Dutch law my opinion is NOT changed.
In a separate e-mail you can read some relevant pages.

In summary. 'Information can be destroyed' is the text.

There are two important conditions when it is not allowed to destroy information:
- because of legal reasons
- because of a substantial interest for others not to destroy it. An example is a legal process, or genetic information.
What is not explicitly discussed in this report is the use case where decisions have been made on the basis of information that the patient wants to remove. In my opinion in this use case the information can never be removed physically or logically in the context of these decisions and the legal implications. But it must be removed logically in the context of information that can be transmitted to others.

Later in the report there is a chapter on the EHR and deletion.
They explicitly mention that deletion in the electronic sense means destruction of the hard disk and CD-rom, etc.
This is not possible. A pragmatic solutions in terms of a well behaved Information system, implicating logical delete plus specific business rules, is the optimal solution.

Gerard

-- <private> --

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 654 792800

---

## Post #23 by @system

Hi Gerard,

There are more emails on this subject, I did not yet read them all, I will within a day or so, at this moment I don&#39;t have the time\.
I saw in a glimpse that there was a possibility to remove data, but maybe I m wrong, it was only a glimpse\. I will come back to this\.
The purpose of this reply is the discussion about interpretation of the Dutch law \(as I saw also the Swedish law, but I am not sure about that\)

Gerard Freriks schreef:
> Dear Bert,
>
> Reading again a thick report by our Royal Dutch Medical Association about the interpretation of this pecific Dutch law my opinion is NOT changed\.
> In a separate e\-mail you can read some relevant pages\.

I did not receive that email, maybe later\.
>
> In summary\. &#39;Information can be destroyed&#39; is the text\.
>
> There are two important conditions when it is not allowed to destroy information:
> \- because of legal reasons
> \- because of a substantial interest for others not to destroy it\. An example is a legal process, or genetic information\.

You are right, these exclusions are mentioned in the law\. But the fact that the law explicitly states that removal must be possible, and mentions some exclusions means that there will be cases in which the patient has the right to remove data\.
> What is not explicitly discussed in this report is the use case where decisions have been made on the basis of information that the patient wants to remove\. In my opinion in this use case the information can never be removed physically or logically in the context of these decisions and the legal implications\. But it must be removed logically in the context of information that can be transmitted to others\.
>
> Later in the report there is a chapter on the EHR and deletion\.
> They explicitly mention that deletion in the electronic sense means destruction of the hard disk and CD\-rom, etc\.

It is always the same old story, people creating laws and not knowing what they are talking about\.
Destruction of a CD ROM sounds reasonable, because you cannot remove information from a CD ROM, destruction of a hard disk is not reasonable, because it is not necessary to destruct a hard disk to remove patients data\.
This is the intention of the law, to give a patient the possibility to remove data \(and \*only\* if necessary, also destruct the carrier\)\.
The law does not say logically or physically, but it is clear that the law means, there may be no way those data can be retrieved again\.

If data are cached, then that is a problem of the health\-data\-keeping organization to remove them, it is not the patients\-problem
> This is not possible\. A pragmatic solutions in terms of a well behaved Information system, implicating logical delete plus specific business rules, is the optimal solution\.

If logically deleted means that there will be no way of retrieving the data, that would be fine, I think\.
In many cases it will be enough to break the connection between a person and that particular data, but one can also imagine cases that it is possible to easily deduction to whom a record belongs\. E\.g\. if you are the only person with no legs in your town, and there is a record which is related to missing both legs in a GP\-office in your town, then it will be very easy to connect that record to a person, even when the connection does not anymore exists in the database\.

Concluding, there may be cases where logically deleting will not be sufficient, so there may be cases that physically removal will be necessary, to be compliant with the law\.

Regards
Bert Verhees

---

## Post #24 by @Karsten_Hilbert

You miss the point: A scan in this scenario is identifiable
to belong to a patient different than the one it&#39;s attached
to hence it&#39;s a breach of privacy\. So it&#39;s not &quot;the same&quot;
since, yes, there IS a &quot;way to know it was meant for
somewhere else&quot;\.

Karsten

---

## Post #25 by @system

Thomas Beale schreef:
> openEHR supports logical deletion of content in the following way \(see updated Common IM \- change\_control section of  http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/common_im.pdf):
>
> \- a new Version is created
> \- VERSION\.data is removed\. The current way of thinking is that there has to be a data item there e\.g\. a Composition, but with its own content removed\. However, I believe we should make VERSION\.data 0\.\.1 to allow complete deletion of the item\. Either way should work, but the first way seems artificial to me\.
> \- VERSION\.lifecycle\_state is set to deleted \(there is a term code for this in the openEHR terminology\)
> \- commit as usual
>
> The result is that the view of the EHR now doesn&#39;t include the Item corresponding to the deletion just made \(assuming your software correctly looks at the lifecycle state and handles deleted data properly\)\.
>&nbsp;&nbsp;
> normal option \(see e\.g\. the Suubversion FAQ on this \- http://subversion.tigris.org/faq.html#removal); but nevertheless, it is always possible at some level\. The usual approach is to make it a special administrator task, with no visible API that would allow normal software to do it\. This doesn&#39;t mean however that such a procedure is not defined, just that it is probably implemtation specific due to being low level \(removing stuff from MySQL would be different from doing it in say Oracle\)\.

It is said in http://www.openehr.org/getting_started/t_openehr_primer.htm that one of the disadvantages of current health\-care information systems is the costs and difficulties to maintain them\.
Having to delete data manually, and thereby having to regard DB\-vendor\-specifics, OpenEhr\-implementor\-specifics and OpenEhr\-version\-specifics makes, in my opinion Openehr, regarding this issue costly and difficult, and even dangerous to maintian\. I think, I would never advise some implementor doing this\.

It is also said on the same webpage that the OpenEhr community is growing, and has members of many countries\. One can conclude from this that OpenEhr has the desire to not be nation\-specific, and should have features which are needed \(f\.e\. for repairing an errorneous post of data\), or even in a minority \(f\.e\. to be local law compliant\) of the community\.

So not having a proper &quot;removal of patients\-data or even a complete patient&quot;\-record API is in my opinion opposite against some of the OpenEhr goals\.

---

## Post #26 by @thomas.beale

Bert Verhees wrote:
> It is said in http://www.openehr.org/getting_started/t_openehr_primer.htm that one of the disadvantages of current health\-care information systems is the costs and difficulties to maintain them\.
> Having to delete data manually, and thereby having to regard DB\-vendor\-specifics, OpenEhr\-implementor\-specifics and OpenEhr\-version\-specifics makes, in my opinion Openehr, regarding this issue costly and difficult, and even dangerous to maintian\. I think, I would never advise some implementor doing this\.

perhaps I am missing something\. openEHR simply provides a logical versioning model that supports many semantics, including logical deletion\. Physical deletion cannot be expressed in that kind of model \- the semantics of physical deletion are by definition at the file system or some similar level\.
>
> It is also said on the same webpage that the OpenEhr community is growing, and has members of many countries\. One can conclude from this that OpenEhr has the desire to not be nation\-specific, and should have features which are needed \(f\.e\. for repairing an errorneous post of data\), or even in a minority \(f\.e\. to be local law compliant\) of the community\.
>
> So not having a proper &quot;removal of patients\-data or even a complete patient&quot;\-record API is in my opinion opposite against some of the OpenEhr goals\.

no, that&#39;s not the intention; in fact we already have in the APIs being used in Australia the possibility to split one EHR into two EHRs due to wrong patient data going into an EHR, and also to merge two EHRs\. openEHR itself doesn&#39;t say anything at all about the semantics of removing an entire patient, since it doesn&#39;t define formally the idea of &quot;collection of EHRs&quot;, only single EHRs\.

\- thomas beale

---

## Post #27 by @system

> Bert Verhees wrote:
> &gt; It is said in
> &gt; http://www.openehr.org/getting_started/t_openehr_primer.htm that one
> &gt; of the disadvantages of current health\-care information systems is the
> &gt; costs and difficulties to maintain them\.
> &gt; Having to delete data manually, and thereby having to regard
> &gt; DB\-vendor\-specifics, OpenEhr\-implementor\-specifics and
> &gt; OpenEhr\-version\-specifics makes, in my opinion Openehr, regarding this
> &gt; issue costly and difficult, and even dangerous to maintian\. I think, I
> &gt; would never advise some implementor doing this\.
>
> perhaps I am missing something\. openEHR simply provides a logical
> versioning model that supports many semantics, including logical
> deletion\. Physical deletion cannot be expressed in that kind of model \-
> the semantics of physical deletion are by definition at the file system
> or some similar level\.

Maybe I am missing something too\. I don&#39;t know if physically deleting has
something to do with the filesystem, in my opinion, one could also regard a
permanent deletion of a record as a physically deleting\.
That depends how data are stored, which is something to be done by a
persistence\-layer, which can be everything, XML, CSV, relational db, post
relational db, even smoke signals to an indian on the other side of the
canyon, which carves the data in a pieces of wood\.
Physically deleting would be in this last case: use the pieces of wood for new
smoke signals\.

Maybe I am completely on the wrong track, I don&#39;t know the complete
documentation, although I am getting further in it everyday, and, as you also
said, it is not always up to date\. So I cannot take everything for granted,
and also I have to consider what people on this mailing list say\.

I understood that physically deleting \(which is, in my view, complete removal
of records \(leaving no trace at all\) is impossible except by bypassing the
kernel and doing it manually\. The reasons why I understood this are
following\.
\- Gerard said it should not be possible to physically delete a record, only
logically may be possible\. Logically removing in my view is adding a new
version which has a deletion mark \(like SVN works\)
\- Sam said that for really \(untraceable\) removal, it would be necessary to
hack in the underlying database manually
\- You said that too, and emphasized it by mentioning that that is not easy
because of different DB\-Vendors\. And also you pointed to Subversion, which at
this moment has no way for permantent deleting a record and removing all
traces to it, all evidence it ever existed\.

> &gt; It is also said on the same webpage that the OpenEhr community is
> &gt; growing, and has members of many countries\. One can conclude from this
> &gt; that OpenEhr has the desire to not be nation\-specific, and should have
> &gt; features which are needed \(f\.e\. for repairing an errorneous post of
> &gt; data\), or even in a minority \(f\.e\. to be local law compliant\) of the
> &gt; community\.
> &gt;
> &gt; So not having a proper &quot;removal of patients\-data or even a complete
> &gt; patient&quot;\-record API is in my opinion opposite against some of the
> &gt; OpenEhr goals\.
>
> no, that&#39;s not the intention; in fact we already have in the APIs being
> used in Australia the possibility to split one EHR into two EHRs due to
> wrong patient data going into an EHR, and also to merge two EHRs\.
> openEHR itself doesn&#39;t say anything at all about the semantics of
> removing an entire patient, since it doesn&#39;t define formally the idea of
> &quot;collection of EHRs&quot;, only single EHRs\.

It would be possibe to gather all records \(this always confuses me: an EHR is
something as one single composition?\) belonging to a patient and remove them,
without leaving evidence it ever existed?

Because, that is what the Dutch law demands to be possible\.

The context of which is thought about OpenEhr is many times, this for use in
regional or even national context\. This is not always necessary to be the
case\.

So let me ask again my question, and first explain a situation:
It could well be that an OpenEhr\-system is used in a private clinic, or a
clinic for mental health\. For example, there is a famous clinic in London
where rich people can get rid of there cocaine and alcohol habits\. They work
quick, and seem succesful\. I can imagine that the really rich people want all
there evidence, having stayed in such a clinic to be removed, and I think,
they have the power to get this done\.
Maybe other mental health clinics need some evidence for taxes and insurance
administration, but when that is done, no evidence of their stay may be left
if the patient demands that\. That is what the Dutch law tells us\.

Is that possible, using an API in OpenEhr?
If yes, than I was on the wrong track because of my misunderstanding the
remarks made by you, Gerard and Sam\.

kind regards
Bert Verhees

---

## Post #28 by @Tim_Churches

Bert Verhees wrote:
> I understood that physically deleting \(which is, in my view, complete removal
> of records \(leaving no trace at all\) is impossible except by bypassing the
> kernel and doing it manually\. The reasons why I understood this are
> following\.
> \- Gerard said it should not be possible to physically delete a record, only
> logically may be possible\. Logically removing in my view is adding a new
> version which has a deletion mark \(like SVN works\)
> \- Sam said that for really \(untraceable\) removal, it would be necessary to
> hack in the underlying database manually
> \- You said that too, and emphasized it by mentioning that that is not easy
> because of different DB\-Vendors\. And also you pointed to Subversion, which at
> this moment has no way for permantent deleting a record and removing all
> traces to it, all evidence it ever existed\.

It seems inevitable that physical deletion of patient records will be
needed in some circumstance, and may be required by law in some
countries\. Of course, as various people have pointed out, if a system
administrator has physical access to the back\-end database or
repository, then physical deletion of particular records is always
possible \(although deletion of that record from all back\-up copies on
tape etc can be very difficult to achieve\)\. The question for openEHR is
whether it should define a function in its storage kernel specifications
to facilitate such physical deletion and ensure that they are done in a
consistent and safe fashion, or whether it should be left up to the
system/database administrator to have to hack away at teh back\-end
storage, bypassing the openEHR storage kernel\. I would suggest that if
one of the aims of openEHR to good integrity of medical records, it
should be doing everything in its power to discourage system/database
administrators from having to bypass the openEHR storage kernel to
effect such deletions, and thus specify functions for the physical as
well as the more usual logical deletion of patient records\.

One of the reasons why people are reluctant to include facilities for
physical deletion seems to be the need for a legal record of the
information which was available to clinicians and others at particular
points in time\. That&#39;s a reasonable concern, but such concerns can only
be addressed if use is made of digital notarisation of records by a
trusted third\-party notary\. Such notarisation needs to be tightly
integrated with the back\-end storage mechanism, to permit digital
counter\-signing of each version of each record, not just the whole database\.

Tim C

---

## Post #29 by @thomas.beale

Tim Churches wrote:
> One of the reasons why people are reluctant to include facilities for
> physical deletion seems to be the need for a legal record of the
> information which was available to clinicians and others at particular
> points in time\. That&#39;s a reasonable concern, but such concerns can only
> be addressed if use is made of digital notarisation of records by a
> trusted third\-party notary\. Such notarisation needs to be tightly
> integrated with the back\-end storage mechanism, to permit digital
> counter\-signing of each version of each record, not just the whole database\.
>&nbsp;&nbsp;

we have actually consciously made the change control model \(section 6 in http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/common_im.pdf) compatible with notarisation by a TTP; in particular, the idea that a digital digest can be generated with each new version of any version container, and the digest sent elsewhere; then when copies of the versions are sent in Extracts to another location, the receiver has a way of verifying the authenticity \(regenerate digest and compare with requested copy from notary service\)\. We have yet gone to the lengths of explicitly modelling more than the digest \(which is described in the forthcoming EHR Extract spec\), but i suspect we might in the future\.

\- thomas

---

## Post #30 by @thomas.beale

Bert,

I think you are making this much more complicated than it needs to be. There is nothing *a priori* to stop physical deletion of parts of a record. However in version controlled systems, something special behind the scenes is usually needed to effect it. How this appears in the API has nothing to do with how it is implemented. All I said is that it would be quite normal that the action of physical deletion (even if available in the API) requires a higher level of access than other operations, i.e. cannot just be done by any normal user - it might require a system administrator with special permissions. This is because physical removal of pieces of an EHR (like pieces of any versioned repository) can easily lead to inconsistencies in the remaining part.

The other scenario you mentioned is physical deletion of a complete EHR. This is obviously easy (technically); most likely the access control requirement is higher here as well.

How you configure the access control is up to the system installers, it is not hardwired into openEHR.

- thomas beale

Bert Verhees wrote:

---

## Post #31 by @Tim_Churches

Thomas Beale wrote:
> Tim Churches wrote:
>> One of the reasons why people are reluctant to include facilities for
>> physical deletion seems to be the need for a legal record of the
>> information which was available to clinicians and others at particular
>> points in time\. That&#39;s a reasonable concern, but such concerns can only
>> be addressed if use is made of digital notarisation of records by a
>> trusted third\-party notary\. Such notarisation needs to be tightly
>> integrated with the back\-end storage mechanism, to permit digital
>> counter\-signing of each version of each record, not just the whole
>> database\.
>>&nbsp;&nbsp;
>
> we have actually consciously made the change control model \(section 6 in
> http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/common_im.pdf)
> compatible with notarisation by a TTP; in particular, the idea that a
> digital digest can be generated with each new version of any version
> container, and the digest sent elsewhere; then when copies of the
> versions are sent in Extracts to another location, the receiver has a
> way of verifying the authenticity \(regenerate digest and compare with
> requested copy from notary service\)\. We have yet gone to the lengths of
> explicitly modelling more than the digest \(which is described in the
> forthcoming EHR Extract spec\), but i suspect we might in the future\.

OK, that sounds good\. An alternative modus operandi for digital
notarisation is for the EHR to generate a self\-signed digest for each
new version of a record, send that digest to a third\-party notary, who
then counter\-signs the digest and sends it back to the EHR, which then
stores the counter\-signed disgest in the repository alongside the record
to which it applies\. That means that the digital notary does not need to
store anything other than their complete history of private signing
key\(s\), and anyone can check the validity of the notary&#39;s
counter\-signature by referencing the public signing key for that notary
for the date on which the record was counter\-signed\. The notary does not
have to be consulted or bothered for that validity check to occur\. If
the counter\-signature is valid, then the stored digest is valid, and if
a new digest calculated from that version of the record matches teh
stored digest, then it provides strong evidence that that version of the
record existed in that state at some time prior to the counter\-signing
date\. Because notaries don&#39;t need to remember anything other than their
signing keys, they can be very cheap to set up and operate, and can be
made very secure eg run a hardened Web server with minimal facilities
and no writable storage\. But there needs to be somewhere in the openEHR
record to store the counter\-signed digest\. Or maybe more than one \- it
is possible that several separate notaries could be used to provide
&quot;triangulation&quot; of their attestation functions\.

Tim C

---

## Post #32 by @thomas.beale

Tim Churches wrote:
>
> OK, that sounds good\. An alternative modus operandi for digital
> notarisation is for the EHR to generate a self\-signed digest for each
> new version of a record, send that digest to a third\-party notary, who
> then counter\-signs the digest and sends it back to the EHR, which then
> stores the counter\-signed disgest in the repository alongside the record
> to which it applies\. That means that the digital notary does not need to
> store anything other than their complete history of private signing
> key\(s\), and anyone can check the validity of the notary&#39;s
> counter\-signature by referencing the public signing key for that notary
> for the date on which the record was counter\-signed\. The notary does not
> have to be consulted or bothered for that validity check to occur\. If
> the counter\-signature is valid, then the stored digest is valid, and if
> a new digest calculated from that version of the record matches teh
> stored digest, then it provides strong evidence that that version of the
> record existed in that state at some time prior to the counter\-signing
> date\. Because notaries don&#39;t need to remember anything other than their
> signing keys, they can be very cheap to set up and operate, and can be
> made very secure eg run a hardened Web server with minimal facilities
> and no writable storage\. But there needs to be somewhere in the openEHR
> record to store the counter\-signed digest\. Or maybe more than one \- it
> is possible that several separate notaries could be used to provide
> &quot;triangulation&quot; of their attestation functions\.
>&nbsp;&nbsp;

Tim,
this is a very nice model \- I have not seen this exact variant before, but as you say, it would be cheap to run and require less in terms of cross\-service requests to work\. At the moment, you won&#39;t see any &quot;digest&quot; attribute in the class ORIGINAL\_VERSION \(which is one place you might expect to see it\), because doing this complicates digest generation\. Usually to generate a digest reliably from a set of objects, you have to convert them to a known serial form \(e\.g\. some XML variant, or we might mandate dADL, which is more object\-oriented, unambiguous, and half the size\), and generate the digest from that\. To do this conveniently, it is better if you can just serialise a network of objects starting from some root object\. Now, if the object we want to logically generate the digest from is the ORIGINAL\_VERSION object \(= the data being stored plus the audit trail, any attestations, the version id, previous version id and Contribution id\) then adding a digest to this same object means that you have to have some way of not including the digest attribute itself in the computation\. While it is not that hard to model or implement, it is in my experience a guaranteed invitation for 50% programmers to get it wrong\.

So we have left open the possibility that digests instead will be generated from the ORIGINAL\_VERSION object, and stored in a table in the VERSIONED\_OBJECT container object; for any given Version you can ask what the digest is\. This digest can then be obtained for inclusion in the EHR Extract for each Version included\. We have not yet put this change into the model, but I think it is probably the right one\.

\- thomas

---

## Post #33 by @Karsten_Hilbert

http://www.gnotary.de

provides just that\. The site is in German\. It offers an
implementation of what Horst Herb originally proposed in the
gnotary concept\. The academic idea transformed into an open
source project \(GNotary\) transformed into a product
\(gnotary\.de website and business\)\.

Contact Sebastian for information in English \(my brother, so
add standard disclaimer here \- oh, and I wrote most of the
original code for the gnotary server, so there\)\.

Karsten

---

## Post #34 by @Tim_Churches

Karsten Hilbert wrote:

---

## Post #35 by @system

Thomas Beale schreef:
>
> Bert,
>
> I think you are making this much more complicated than it needs to be\. There is nothing /a priori/ to stop physical deletion of \_parts\_ of a record\. However in version controlled systems, something special behind the scenes is usually needed to effect it\. How this appears in the API has nothing to do with how it is implemented\. All I said is that it would be quite normal that the action of physical deletion \(even if available in the API\) requires a higher level of access than other operations, i\.e\. cannot just be done by any normal user \- it might require a system administrator with special permissions\. This is because physical removal of pieces of an EHR \(like pieces of any versioned repository\) can easily lead to inconsistencies in the remaining part\.
>
> The other scenario you mentioned is physical deletion of a complete EHR\. This is obviously easy \(technically\); most likely the access control requirement is higher here as well\.
>
> How you configure the access control is up to the system installers, it is not hardwired into openEHR\.

Thanks, I think I understand \(for now\)

Bert

---

## Post #36 by @Karsten_Hilbert

> &gt;  http://www.gnotary.de
> &gt;
> &gt; provides just that\. The site is in German\. It offers an
> &gt; implementation of what Horst Herb originally proposed in the
> &gt; gnotary concept\.

\.\.\.
> &gt; Contact Sebastian for information in English \(my brother, so
> &gt; add standard disclaimer here \- oh, and I wrote most of the
> &gt; original code for the gnotary server, so there\)\.
>
> There is an English version of some documentation for Gnotary by Horst
> Herb at http://www.gnumed.net/gnotary/ However I don&#39;t think the gnotary
> server described on that page is currently functioning\.

Right, it is not\. But the gnotary people from the URL given
above run one which can be tested freely and under certain
circumstances be \*used\* freely \(by FOSS projects, roughly\)\.
The source is FOSS, too, of course\. The API is SMTP\.

Sebastian has the inside scoop\.

Karsten

---

## Post #37 by @system

Thomas Beale schreef:
>
> Bert,
>
> I think you are making this much more complicated than it needs to be\. There is nothing /a priori/ to stop physical deletion of \_parts\_ of a record\. However in version controlled systems, something special behind the scenes is usually needed to effect it\. How this appears in the API has nothing to do with how it is implemented\. All I said is that it would be quite normal that the action of physical deletion \(even if

The content under this subject shifted, it is no problem, but quick, a remark, while the original subject is still a bit warm\.\.\.\.

It is not that important to me, logical or physical deleted, I make money programming, I am not a scientist\.
So I am working with the wonderful OpenEhr specs, suddenly a GP, important for my projects comes:
&quot;Hey, how about article 455 of the WGBO? &quot;
\(which explicitly demands the possibility for deletion of data, and does not mention logically or physically, to be law\-compliant, one must read the law as simple as possible, and try to understand the intention of the law\)
> available in the API\) requires a higher level of access than other operations, i\.e\. cannot just be done by any normal user \- it might require a system administrator with special permissions\. This is because physical removal of pieces of an EHR \(like pieces of any versioned repository\) can easily lead to inconsistencies in the remaining part\.

So I as I read above, it is possible to be law\-compliant in the OpenEhr system, but it is difficult\.
It would be nice if every composition had a method: DestroyAndLeaveNoTrace, but I understand that this not desirable because it must be possible to revert to the state of the record where the information is in tact\. I do not understand why, because when the law in case of art 455 says that it is not allowed \(destruction means no way back\!\!\) to revert back, why should openehr want to revert back?

But as I said, it is not important to me, at the time it occurs I will find my way to comply to the law\.

regards
Bert Verhees

---

## Post #38 by @thomas.beale

Bert Verhees wrote:
>
>> available in the API\) requires a higher level of access than other operations, i\.e\. cannot just be done by any normal user \- it might require a system administrator with special permissions\. This is because physical removal of pieces of an EHR \(like pieces of any versioned repository\) can easily lead to inconsistencies in the remaining part\.
>
> So I as I read above, it is possible to be law\-compliant in the OpenEhr system, but it is difficult\.

it&#39;s nothing to do with openEHR \- it&#39;s mathematically guaranteed that at least in some cases, physical deletion of a subset of the items in a version controlled repository that supports change\-sets and legally defensible history and audit will logically corrupt the repository\. This is because in general more than one thing can be changed in a change\-set \(what we call a Contribution\), not just the thing you want to delete\. Even if the thing you want to remove is the only thing in a Contribution, removing the Contribution still falsifies the previous states of the repository, and could easily leave both doctors and patient without a legally defensible EHR \(e\.g\. if some physician had read the now\-deleted information that said that the patient refuses blood transfusions because of religion, and under the health service rules, obeyed the patient preference; the patient then died as a result, and now the family wants to know what the hell happened\.\.\.\.how does the physician prove what evidence his/her decision was made based on, if it has been rubbed out\)\.

Technically, deletion is easy, but there are consequences for consistency and legal value of the data\. So making it harder to do is sensible\. We have to realise that all such legislation as has been mentioned here is written as if we were in 1850, still writing everything on paper\. Even then it was not watertight \- anyone could make a written copy, and it was not long before photography and typewriters made that job a lot faster\.

In my opinion the best way to satisfy the intention of this kind of legislation is to design EHRs so that the identity of the patient can be kept completely out of the EHR if desired\. openEHR supports 3 levels of this separation:
\- no subject of care Ids at all in the \(have to create a ehr\_id, subject of care id table elsewhere, in a secure space\)
\- subject of care id is mentioned only in the root EHR object of the EHR \(relatively easy to stop most software getting to this particular object\)
\- subject of care id is mentioned in any/all information items about the subject, i\.e\. Entry\.subject in openEHR terms\.
In more open environments within secure boundaries, patient names can even be included in the record if desired\. The level of separation is up to each site or health authority\. The first level means that even if you succeed in stealing and decrypting the whole EHR, you still don&#39;t know whose it is\. I agree that if it happens to contain information correspponding to a small minority \(people with HIV, people with one leg etc\) this protection is reduced\. But this protection is only one of many; once you have a secure environment, biometric or RFID login, data encryption, and other measures, it is going to be a lot of work to steal patient data and then match it to an actual person\. The very people who might have more reason to fear this are likely to have higher protection\.
> It would be nice if every composition had a method: DestroyAndLeaveNoTrace, but I understand that this not desirable because it must be possible to revert to the state of the record where the information is in tact\. I do not understand why, because when the law in case of art 455 says that it is not allowed \(destruction means no way back\!\!\) to revert back, why should openehr want to revert back?

being able to reconstruct previous states of the EHR is the only way to provide medico\-legal support for claims made later about what happened earlier\. Most likely this law is in conflict with other laws that say that physicians \(or someone at least\) have the right to keep such information as is necessary to protect them from later claims in court that they acted negligently; by the same argument, the \_same\_ functionality also protects the patient, especially if they added information to their own EHR and it was ignored\. Physical deletion breaks the integrity of any versioned repository, thus stopping it performing one of its major functions\. openEHR is no different in this regard from Subversion, CVS, BitKeeper, ClearCase, SourceSafe or any other tool you want to mention\.

> But as I said, it is not important to me, at the time it occurs I will find my way to comply to the law\.

consider how the \(world&#39;s most stupid\) law on region encoding of DVDs was complied with: DVD manufacturers brought out all\-region decoders\. Now we can buy a DVD in an airport and know it will play at the other end\.

\- thomas

---

## Post #39 by @system

Friends,

Data, information and knowlegde exists, can be interpreted in a spefic context, only.

Data, information and knowledge without a context can be considered garbage.
It can not be interpreted faithfully.
It is nothing more than a string of codes.

Always data, information, knowledge will be used outside the original context.
It will be very difficult to erase it completely.

The consequence is that when the context is removed from the data it can no longer be interpreted faithfully and therfor be used correctly.
Logical removal is an example of this.

Gerard

-- <private> --

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 654 792800

---

## Post #40 by @system

I understand your arguments and Gerards his  arguments, and I agree with most
of it
\.
But the law is the law, and some patients will want to practice their rights
for deletion\. This law comes from 1995\. A health\-care information application
must be able to obey the law, even if it is a bad law\.

---

## Post #41 by @mikael

Thomas Beale wrote:

> Technically, deletion is easy, but there are consequences for consistency
> and legal value of the data\. So making it harder to do is sensible\. We
> have to realise that all such legislation as has been mentioned here is
> written as if we were in 1850, still writing everything on paper\.

The Swedish Health Record Law is from 1985 and has been revised several
times since then\. The law is written to be media and technique neutral and
describe what the society demand from a health record\. Then is it up to the
suppliers to use their technique so the health records keeps up to the
society’s demands before they sell the health record systems to the health
care providers\. In this case can it be burnable health record papers or
electronic health record systems with good functionality to completely
remove entered data\.

I therefore don’t think that we shall talk about the laws in a fashion of
non modern laws written for a previous media, but instead of how we
technicians can satisfy the society’s demand on health records whatever
technique we use\.

> Even then it was not watertight \- anyone could make a written copy, and
> it was not long before photography and typewriters made that job a lot
> faster\.

Of cause is it possible to copy data from a paper based health record, but
in Sweden we then note where we send the copy\. It is still possible to do
with electronic health records\.

&nbsp;&nbsp;/Mikael Nyström

---

## Post #42 by @Sam

I think this is how it should happen - it should be very rare - but obviously under strict control of the provider and source. It breaks all the openEHR specifications and I think should not be part of the spec. Cheers, Sam

Bert Verhees wrote:

---

## Post #43 by @Sam

Hi Ed
It is possible that someone acted on this information in the meantime and even made a key decision - making it unavailable except in a legal(historical) view of the EHR is easy - built into the spec - it would only be seen with a historical view which can require further security (and even patient consent).
Sam

William E Hammond wrote:

---

## Post #44 by @williamtfgoossen

In een bericht met de datum 4-5-2006 15:30:25 West-Europa (zomertijd), schrijft hammo001@mc.duke.edu:

> Mcuh of an opinion of this topic depends on what your view of an EHR is.
> My view is very specific and focused. The EHR contains the data that is
> important for the present and future care of the patient. It is legal in a
> sense that the data should be correct, complete for its purpose, and
> focused. A clinical warehouse or data repository is where all the data
> goes and stays. A clinical data warehouse would serve the purpose you
> identify. A physician treats the patient. It would be interesting to note
> how such errors are discovered. In my experience, it is frequently the
> patient and secondly the provider seeing the patient who discovers those
> errors.
>
> If the EHR contains anything and everything without structure and purpose,
> it becomes too burdensome to use.
>
> For example, in the clinical laboratory, it is important to note a series
> of times - when the specimen was collected, when it arrived at the lab,
> when it was processed, and when it was reported. The physician taking care
> of the patient is interested only in the time of the specimen and that the
> result is reported.
>
> I recognize that many will disagree with this position
>
> Ed

Ed I have no opinion on your lab example, but in principle I agree that an important feature of an EHR is to delete data that are wrong. However, the procedure for this can be multiple.

-> normally error data are made inactive, but can still be traced for legal reasons. But they do not function anymore in the active record of the patient. It might even need a specific technician inpunt to track it back, but even the fact that data of another patient where entered in the record of the patient under care is an event you might need to verify years later. Of course they should be removed from the active record and have no function anymore in any of the data uses in the EHR. But the fact that this error once existed and was corrected and how and by whom must be trackable I believe.

William Goossen

---

## Post #45 by @system

Funny?

After many years of discussions,
after one definitive ISO TR on the topic of the definition,
I read that Ed Hammond fears that people will disagree with his views.

What you described is :
*4.6.2 Definition* *Integrated Care EHR*
*The Integrated Care EHR (ICEHR) is defined as a repository of information regarding the health status of a*
*subject of care in computer processable form, stored and transmitted securely, and accessible by multiple*
*authorised users.* *It has a standardised or commonly agreed logical information model which is independent*
*of EHR systems.* *Its primary purpose is the support of continuing, efficient and quality integrated health care*
*and it contains information which is retrospective, concurrent, and prospective.*

And something the healthcare provider is using for its own purposes.

This is more close to the definition of the basic-generic definition.

*4.3.1 Definition*
*The basic–generic definition for the EHR is a repository of information regarding the health status of a subject*
*of care, in computer processable form.*

So what can be the problem?

Gerard

-- <private> --

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 653 108732

---

## Post #46 by @William_E_Hammond

On the contrary\.  If I worried about people disagreeing with me, there is a
long list of people I would not talk with\.  I was recognizing that, in this
case, I recognize my views are not the popular view\.  Doesn&#39;t make it right
or wrong, as I am sure you are aware\.

Not only that, I enjoy the conversation\.

However, in terms of your two references, I still think the wording is open
for interpretation of what the EHR contains\.  I wanted\. to be specific\.
That&#39;s what&#39;s wrong\.

Ed

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Gerard Freriks
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;gfrer@luna\.nl&gt;                 To:       openehr\-technical@openehr\.org
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Sent by:                        cc:       owner\-openehr\-technical@openehr\.org
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;owner\-openehr\-technical@        Subject:  Re: removal of data
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;openehr\.org
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;05/04/2006 11:27 AM
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Please respond to
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;openehr\-technical
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Funny?

After many years of discussions,
after one definitive ISO TR on the topic of the definition,
I read that Ed Hammond fears that people will disagree with his views\.

What you described is :
4\.6\.2 Definition  Integrated Care EHR
The Integrated Care EHR \(ICEHR\) is defined as a repository of information
regarding the health status of a
subject of care in computer processable form, stored and transmitted
securely, and accessible by multiple
authorised users\.  It has a standardised or commonly agreed logical
information model which is independent
of EHR systems\.  Its primary purpose is the support of continuing,
efficient and quality integrated health care
and it contains information which is retrospective, concurrent, and
prospective\.

And something the healthcare provider is using for its own purposes\.
This is more close to the definition of the basic\-generic definition\.
4\.3\.1 Definition
The basic–generic definition for the EHR is a repository of information
regarding the health status of a subject
of care, in computer processable form\.

So what can be the problem?

Gerard

\-\-  &lt;private&gt; \-\-
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: \+31 252 544896
M: \+31 653 108732

---

## Post #47 by @system

The EHR contains what needs to be documented, to be said, in view of the fact that it is the life long record about one patient, isn't it?

GF

-- <private> --

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 653 108732

---


**Canonical:** https://discourse.openehr.org/t/removal-of-data/14536
**Original content:** https://discourse.openehr.org/t/removal-of-data/14536