This is a very useful post - I have thrown in some comments below - mainly as a means of stimulating further discussions, not providing answers. I hope that the security experts amongst us will be motivated to think seriously about solutions for openEHR.
Thomas Clark wrote: >With an interest in Patient Centered Healthcare that includes security I >believe that a Secure Data Store in conjunction with Patient unique >applications can provide secure Patient -controlled, secure Healthcare >records. Selection of and control over the Secure Data Store is exercised by >the Patient with the market providing a selection of services. > By "secure data store" - I think you mean security mechanisms in the persistence infrastructure - i.e. database level encryption, database-level user authentication (i.e. distinct from application or network secure login) etc. At one level, it seems to me that these things are organisational security issues in the sense that they are the same for all enterprise information reseources - and we don't need to say anything special in the EHR specifications. On the other hand, we are talking about distributed patient-centred health information here, not employee emails. Do we need a formal model of the virtual EHR (i.e. distributed pieces of EHR) in which security facilities are defined (at least abstractly) for persistence and exchange? I think we do. Everyone has a lot of ideas about this, but I don't think we have seriously thought about defining a distributed EHR model on which we can hang security definitions - we only (so far) try to define security "in-the-small". >Organizations and Practitioners would be able to choose a security system >that suits their purpose and is able to communicate with other over a set of >standardized, secure data transmission systems using perhaps different >send/receive filters, e.g., versioning, paths. At all points NEED TO KNOW >governs access and data records are composed of multiple physical records >with secured components, each component potentially unique. > >My preference is for appropriately encapsulated, time-and access-limited, >secure objects, each entity (e.g., Patient, Hospital, Clinic, Practitioner) >generating their own. This overall mechanism could include OpenEHR records >accessible via standardized applications. It could include others as well. > at this level do you see the physical EHR fragments (i.e. piece of EHR at each physical location) as being the "object" at which these systemic security features should be defined? >COMMENT: >There is significant potential for misuse between two or more users of >OpenEHR records. These records must have their own security mechanisms. They >should be affected to some extent by other security systems that transmit >them, e.g., security trailer tracing handling back to sources. Security >monitors should be able to review and audit the trailers. Security >verification should then close loopholes. Security consistency checks can >verify multiple local and remote copies. > I think we need to separate out the security needs which are specific to EHRs from those which would apply to any enterprise information. One principle that we think needs to be observed is that clearly secure access to peoples EHRs will be violated, however infrequently; therefore access audit trails do need to exist so that the a) the EHR subject can be notified that there was a breach; b) the means of violation can be identified and fixed and c) hopefully the violator can be identified and appropriate action taken. We at least need to guarantee that a) occurs - this requires that all violations are knowable and known. >UPDATES >Updates to OpenEHR records looks like a problem. If several organizations, >Practitioners and the Patients start communicating and updating OpenEHR >records it can result in a significant update problem, e.g., delayed >reports, as well as a major security problem. One might consider the >assignment of an ADMINISTRATOR OF UPDATES to sort this stuff out, which also >could result in use of Secure Data Stores to handle temporary files and >other information. > I don't believe there will be any problem with update within any given health care facility - it will work in a very similar way to a configuration management (CM) system, in which (in general) there are multiple, competing, simultaneous modifiers. These systems work like clockwork already in many enterprises. The difference in health is - of course - security - in a normal CM system, there are not differential security settings on the controlled items. I would not claim to have worked out all the details, but I suggest that the basic idea is that the "checkout" operation of a piece of EHR by any user be where the security be applied - the user role be compared to the access group definitions & sensitivy markers on the relevant EHR data and Access Control service setting; the checkout (like a pure read) either proceeds or not. The biggest issue in my mind is the secure control of the information _during the checkout period_, and also post check-out. In a CM system, there is the concept of a "user workspace" which is where information is checked out into. In EHR-land, this needs to be a _secure workspace_ - one which is a totally controlled part of the system. The challenge is what to do with EHR information which needs to be checked out for a long time (longer than a session), made persistent in the workspace, etc etc. I don't think this is insurmountable, but it does need to be part of the design. >SECURITY REVIEWS >This is a big one. In a potentially global system security can't be >standardized. The systems and networks are usually different as is the user >community. In this regard, security must be adaptable and reviews tailored >to the local environment. > so what is the abstract model for this - is one possible - and what do local implementors have to do? >ACCESS >Role-based access is central. However, it must be limited, e.g., by the >Patient. There should be other models as well. For instance, prior to >surgery I would like to DEDICATE ACCESS to a practitioner who in turn >IDENTIFIES members of a TEAM and ASSOCIATES (including organizations) >involved in a current procedure. It would a time- and function-limited >dedication. > intersting idea - this is essentially identifying a 'consent proxy', same as e.g. an intellectually impaired person would have to do - only for most people it would presumably be time-limited. But a proxy does pose new challenges as well - who is legally responsible for access violations by people the proxy allowed (incorrectly to access the patient data? Does the proxy have the right to dynamically change the settings at any time? Is an appropriate legal metaphor the "power of attorney"? >Nationwide role-based access may be good for Public Health personnel but > and anyway, that kind of access would probably be to de-identified/anonymised data - so it will be through a different mechanism. >role-based access for all Physicians in Canada is NOT a great idea, e.g., >there probably would not be interest and dissemination of or wide access to >secure, private information violates many security requirements. > Sure - but is there any need for any standardisation of role definitions across a health system - i.e. that the meaning of "registrar" be the same everywhere? I would have thought it very desirable since EHR information can easily be shared over a wide area due to patients moving, specialist care/testing etc etc. >Emergency-based access is crucial. In a variety of situations one would not >necessarily be in a position to grant access. A nationwide emergency access >mechanism is definitely a good idea. > >CONCLUSION >OpenEHR security should: >1)address record-based security issues >2)produce a structure that would support information transfer with other >security systems >3)integrate access control from identified, global primaries >4)support security applications to monitor, review, audit and control >individual and groups of records >5)support reporting and review to primaries > > we have work to do! - thomas beale > > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
