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.
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 openEHR specs I don’t know.
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'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).
For the non Swedish speakers .. here's a rough translation (not exact but to
give the general gist!)...
"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)."
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.
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.
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'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?
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.
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'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
Mikael Nyström
<mikny@imt.liu.se> To: <openehr-technical@openehr.org>
Sent by: cc:
owner-openehr-technical@ Subject: RE: removal of data
openehr.org
04/18/2006 04:53 AM
Please respond to
openehr-technical
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.
I don'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.
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 …
- 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'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'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'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.
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.
/Mikael Nyström
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't have to be this way - there are other levels of privacy you can choose. See the "generic" 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.
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'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.
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'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's protection, a drug they give might be based on the evidence of a problem or diagnosis wrongly put in the patient'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's information (which they normaly don't have access to) inside patient A's record (which they are allowed to see). But most likely the wrongly inserted information will appear to be patient A information - there won't be any indication that it was actually about patient B (assuming it was entered by a physician or nurse wrongly using patient A'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.
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.