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'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. - thomas beale Gerard Freriks wrote: > 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 > > > > On 16-apr-2006, at 11:13, Bert Verhees wrote: > >> 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 >> > -- ___________________________________________________________________________________ CTO Ocean Informatics (http://www.OceanInformatics.biz) Research Fellow, University College London (http://www.chime.ucl.ac.uk) Chair Architectural Review Board, openEHR (http://www.openEHR.org)
