Archetypes
Bert Verhees wrote: Hi, I was looking for archetypes, and I found this link: http://oceaninformatics.biz/archetypes/ on the openehr website these links have been fixed just now as it happens. - thomas beale
Archetypes
Je suis absente du bureau jusqu'au jeudi 26 avril 2006. Sandrine Villaeys
removal of data
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 removal of patients-data or even a complete patient-record API is in my opinion opposite against some of the OpenEhr goals. no, that'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't say anything at all about the semantics of removing an entire patient, since it doesn't define formally the idea of collection of EHRs, only single EHRs. - thomas beale
Archetypes
Bert, the link you need is: http://oceaninformatics.biz/archetypes/MindMap/ArchetypeMap.html regards George Hayworth Quoting Bert Verhees bert.verhees at rosa.nl: Hi, I was looking for archetypes, and I found this link: http://oceaninformatics.biz/archetypes/ on the openehr website I found descriptions, but no archetypes: Not Found The requested URL /ADL/evaluation/openEHR-EHR-EVALUATION.directive-medication.v1.adl was not found on this server. Apache/2.0.50 (Fedora) Server at oceaninformatics.biz Port 80 Can someone tell me where I can find those? Thanks in advance Bert Verhees This message was sent using IMP, the Internet Messaging Program.
removal of data
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'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
removal of data
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'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. 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
Archetypes
george.hayworth at oceaninformatics.biz schreef: Bert, the link you need is: http://oceaninformatics.biz/archetypes/MindMap/ArchetypeMap.html This is very interesting link, I never saw it before. But the other which my question was originally about works fine now. (http://oceaninformatics.biz/archetypes/) Thanks Bert Verhees
removal of data
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060424/0fc599d8/attachment.html
removal of data
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'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'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 triangulation of their attestation functions. 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't see any digest 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
notarization, was: Re: removal of data
On Mon, Apr 24, 2006 at 07:10:08PM +1000, 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'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'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 triangulation of their attestation functions. 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 -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
removal of data
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
notarization, was: Re: removal of data
On Mon, Apr 24, 2006 at 08:43:35PM +1000, Tim Churches wrote: 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. ... 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). There is an English version of some documentation for Gnotary by Horst Herb at http://www.gnumed.net/gnotary/ However I don'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 -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
removal of data
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: Hey, how about article 455 of the WGBO? (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
removal of data
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's nothing to do with openEHR - it'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 happenedhow 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'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'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
removal of data
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 On 24-apr-2006, at 9:23, Bert Verhees wrote: 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. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060424/9c99493e/attachment.html
