Hi, There is another issue with digital signatures in the context of EHRs: Their value decreases over time and with them the value of digitally signed documents as legal evidence. In other words: securely signed documents don't necessarily provide a secure basis for verifying authenticity for the required time-span of EHRs (30 and more years).
This is due to the following reasons: - the employed cryptographic algorithms and the keys lose their security qualification in the course of time. (algorithm may found to be insecure, key length may be too short for increased computer power,..) - It cannot be guaranteed that the directories and documents needed for the verification of the underlying certificates are available for 30 years or more. In addition, the use of digital signing procedures is often insecure and information for the subsequent evaluation of the actual security is missing. To achieve high conclusiveness of digitally signed documents and to realize their integration into practical use, the documents complete life cycle ranging from generation of the document, generation of the signature, presentation, communication to (long-time-)archiving and later use have to be taken into account in a comprehensive way. For a truly long-term-solution for EHRs, a solution must be provided for this problem. If you are interested in details, see http://www.archisig.de/english Further, signed data may - of course - not be changed in order to keep electronic signatures valid. But when data has to be exchanged across networks, or in context of systems migration, such changes are inevitably occuring. Trying to avoid this with the help of new standardized and stable data formats contradicts experiences (although openEHR itself might be a solution for this problem). So, procedures are necessary to convert signed documents and preserve their evidence value (legally secure transformation). See http://www.transidok.de/index-en.html for details. Regards, Sebastian Dr Sebastian Garde Faculty of Informatics and Communication Central Queensland University Rockhampton Qld 4702, Australia s.garde at cqu.edu.au Ph +61 (0)7 4930 6542 Fax +61 (0)7 4930 9729 http://infocom.cqu.edu.au/hi -----Original Message----- From: owner-openehr-techni...@openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of lakewood at copper.net Sent: Monday, 7 March 2005 5:20 AM To: openehr-technical at openehr.org Subject: Re: Authenticity Issues [was: Re: Demographics service] Hi Bish, Periodic and immediate 'Bio' identification would satisfy certain security requirements re authenticity, e.g., official documents (e.g., post surgical release). Your comment re 'thumb imprint', or scan, provides a more secure means of authentication that may be required. Requiring that a 'digital signature' be incorporated within a EHR is a step forward but if all that is required is the presence of a digital signature one can be obtained from multiple sources. As you indicated 'verification of authenticity' is required. Verification, however, can be 'fooled' as well, e.g., where digital signatures are collected in advance into a set of 'secure signatures' the presence of one or more of these signatures within an EHR indicates just that and no more. How is this solved in other fields? 'Bio ID' is one approach, e.g., 'finger and thumb imprint', a digital photo and a voice track, in addition to other digital signatures puts up a much higher wall. I am intrigued by the combination of voice tracks with background syn, e.g., Practitioner and Practitioner + Patient.. An example would be a Hospital Delivery Room (multiple persons) and an automatically generated voice track Properly encrypted the track would be hard to break and/or deny. In other areas similar approaches are available, e.g., encrypted time/date/voice tracks can be integrated into Medical devices and then into EHRs. Side benefits include integration of the time/date into the EHR. A major problem with the photo approach is that some persons become unrecognizable after a 12 hour shift. A problem with ordinary 'digital signatures' is that they can be hacked, patched and the wrong ones, e.g., a reserved place in an EHR for a fixed-length digital signature is bad since one might be able to place another there. Regards! -Thomas Clark USM Bish wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Sat, Mar 05, 2005 at 07:34:47PM +0100, Karsten Hilbert wrote: > > >>>The main issue here is varification of authenticity of digital data >>>entry. There must be some mechanism to ensure that every entry >>>placed in the EHR must be authenticated by the signitory, even if the >>>entry is made by a secretary, DEO or transcription- ist. >>> >>> >>A first-step solution might be this: >> >>- writes are tracked (author, timestamp) >>- regular clear-text database dumps are taken (say, twice daily) >> this includes the tracked writes (eg audit logs) >>- dumps are signed to be authentic by a, say, CMO >>- dump hashes are timestamp-signed by non-affiliated third >> parties (say, digital notary servers provided by medical >> faculties, etc.) >> >> >> > >This is a logical process to start with. The issue here is >acceptance and institution of the 'notary servers' ... these need to >find a place within the system universally. > > > >[some snipped] > > >>>Audit trails of visits are only to ensure read access by >>>authorised agencies. >>> >>> >>Even that does not really add any value. IF access occurred it must >>have occurred with proper credentials (barring bugs in the software). >> >> > >Yup, as far as the technical side is concerned, this should be the end >point that we need to go for presently ... > > > >>The question is whether those credentials were abused by >>someone who wasn't supposed to know them or by someone in the know >>but who wasn't supposed to access that part of the data. One study >>showed a decrease in the latter when "tracking reads" was announced to >>the regular users. >> >> > >These are human shortfalls. The fact is, if a sysadmin is happy to >broadcast access passwords to all-and-sundry, ultimately, >he/ she is to be held responsible. It is possible to >incorporate much more stringent access methods by thumb imprint or >pupil signature varification (and methods yet to come). However, >such mathods may not be easily deployable or cost effective. > >Just my 2p > >Bish > > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.3 (GNU/Linux) > >iD8DBQFCKrmHr5z5toona28RAkTiAJ4hy3mVByXwyOIhPnzFQhoxQ+3powCfbiMq >Chr+CL6Y/Z6uAj+fvXReau4= >=4UHc >-----END PGP SIGNATURE----- >- >If you have any questions about using this list, >please send a message to d.lloyd at openehr.org > > > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
