Hi Bill, good questions....
Security has been thought about, and is still being thought about! Essentially there are a number of aspects: A - what is the model of access control - the main problem here is different definitions of roles in different "bricks-and-mortar" institutions at which the one patient might appear (I shouldn't really say bricks-and-mortar, since we include emergency health workers, social workers, mobile nurses etc) B - what is needed in the EHR architecture (i.e. what we call the "openEHR reference models") to support security/privacy requirements? What is the granularity of privacy control required C - how is information to be protected when it moves? D - the related issues of encryption, notarising (for legal protection or investigation of previous clinical acts) E - who sets the privacy settings which control how secure access occurs at runtime? We have not yet written a comprehensive document on this. However, we think we know a fair few things, mainly based on the ideas of other people. Work has been done at the DSTC in Australia on many aspects of security, including a national PKI proposal. Bernd Blobel has probably described security and health information in the most detail that I know of, in his various papers and recent book. The US GCPR project probably made more progress on security in the CPR than it did elsewhere. So. What do we know? - role-based access control is required. To make it work properly in a shared care community context (e.g. a hospital, 50 GPs, aged care homes, nursing care, social workers etc etc) then the roles need to be defined congruently. I seem to remember some Canadian project coming to the conclusion that really the roles need to be defined the same across the entire (national) health care system. I think this is both correct and a the same time unrealistic. I think we will be able to find ways of having diversely defined roles without every health care facility having incompatible definitions of "consultant", "treating physician" etc. Bernd's work on this area is pretty detailed. - the EHR architecture does not need too much complexity added to support consent-based secure access. We currently think it needs to have the ability to store something like 'sensitivity' and access control group id(s) at each 'significant' (i.e. not the smallest) node, the lowest being the openEHR Entry. The access control groups will themselves be defined in their own service. - when the decision is being made at runtime to grant or deny access to a certain part of the EHR to a certain user, the user role (already authenticated etc etc) and access group ids in the piece of EHR requested are compared to the access group definitions. Further, some way of establishing _relevance_ of this user accessing that bit of the EHR is required - i.e. the link between the patient and the user who is a treating physician, or on a team providing care. Other users who are not providing care would probably be treated differently. Certificates would be created if access is granted; these might be time-limited (again I think Bernd has experience in time-limited access); they might be more like keys if we are talking about sending the data outside the secure environment in the form of an encrypted extract. - the patient or competent guardian must be the setter of consent, but most likely with the professional advice of the physician. - the problem of what categories or ways a patient could set consent is hard to define - I don't think anyone has worked it out. If a patient wants to say "exclude family from access to my mental health EHR items" - which items are "mental health"? Some obviously are, but if other mundane items are useful to mental health clinical professionals, do we exclude them or not? Or.... do we allow the patient to set consent just on individual items? THis will not be realistic for most patients - they would have to trawl the record after every addition setting consent all over the place. Could it be set on the basis of problem? How does "exclude all users except treating physicians from accessing HIV/ADIS information". WHat information is HIV/AIDS related? Certain drug prescriptions clearly are, but so are certain patterns of common infections; a medically competent user could identify a person suffering AIDS even if the obvious items were blocked. Philippe Ameline, the producer of the Odyssee product has some really interesting ideas in this area - patients set traffic light colours in a dartboard representing access control to each unit of the record. - I think notarising is relatively easy to solve technically - just a case of working out a scheme whcih works in a distributed environment. Hashes need to be generated for each item and sent to a trusted third party notary service. Audit trails are taken care of inside the architecture - have a look at the definition of the classes Transaction (EHR RM), Entry (EHR RM), and the change control classes (COmmon RM). All relevant party ids, dates, times and locations are recorded (or so we believe!). - thomas beale Bill Walton wrote: > Sam, > > Thanks much for sending that along. I haven't made my way through all > the examples yet, but I like where you're going. A few questions / > comments if you don't mind. > > First, and perhaps you consider this a seperate issue that's out of > scope for Access Control, but what about Audit Trails? In addition to > the choices / decisions you summarize on Page 3, I believe there's a > key question the system needs to be able to answer: "Who has had what > access to my records?" To answer this question it looks to me like > the system needs to maintain two types of information: 1) a history of > the changes to the Access Control List, and 2) a history of accesses > to the EHR itself. Further, it looks like the EHR access history > should include reads as well as writes. That way, the trail would > lead to the providers that have, with permission, made copies of the > EHR within their own systems. > > This is tied to the first question I think, but how does the system > deal with the needs of Consulting Physicians and Researchers who are > not going to provide care, but may need read access to the full > record? If I read this correctly, the mechanism controls what > information can be accessed, but not the type of access permitted > (i.e., read vs. write). > > How do Emergency medicine providers get access to the records? It > looks like there needs to be an override to allow the timely delivery > of service in Emergency situations. It would seem to me that the > existence of the Audit Trails above might calm fears of inappropriate > access. > > Related to all of the above, it seems like there are probably a number > of circumstances that would require that the control of the Access > Control list itself be capable of being over-ridden or delegated. It > looks to me like, as currently defined, the only roles that could > grant access would be the patient and Next of Kin roles. But assume, > for example, that a patient is hospitalized, needs a test performed > that can't be performed in the facility, and has designated a Next of > Kin that's not present. Perhaps it's just a difference between our > systems, but in the U.S. I can imagine a need to delegate the right to > change the Access Control list without delegating some of the other > decisions (e.g., "pull the plug") that are associated with Next of Kin > here. Again, as long as the Audit Trails are in place it seems that > fears of inappropriate access might be effectively balanced against > the needs of providers re: access to the records for the purpose of > delivering the appropriate care. Or perhaps I'm misunderstanding the > Next of Kin role. > > What's an EPR, what's in it, and what, if any, information overlap > does it have with an associated EHR? You introduce EPR in the first > example, but there's no definition provided and no reference to an > external source. > > This is a really interesting problem space to me. I've been studying > HIPAA (the Health care Information Portability and Accountability Act) > and have become fascinated with the discussion over how best to > balance the needs of the various parties involved in the provision and > payment of healthcare services so as to improve the quality and > decrease the cost of health care here in the U.S.. Talk about a > non-trivial problem! Interestingly, it looks to me like all > the nonsense can be traced back to the health record and some > fundamental questions about who owns it, who controls access to it, > etc. Thanks again for sharing. Hope to hear from you soon. > > Best regards, > Bill > > > ----- Original Message ----- > From: Sam Heard <mailto:sam.heard at bigpond.com> > To: Bill Walton <mailto:bill.walton at jstats.com> ; > openehr-technical at openehr.org <mailto:openehr-technical at openehr.org> > Sent: Wednesday, April 23, 2003 6:10 PM > Subject: RE: openEHR security > > Bill > > Security and the EHR - ah theres a question! At least having a > reference model of the EHR makes this something that might be > tackled effectively. The current openEHR model has and access > control feature on ARCHETYPED in the Common Reference Model. The > idea being that anything that can be archetyped - that is, it is a > coherent clinical composition or concept - can have its access > controlled. > > It is envisaged that the EHR will have an access control list > which can be transfered to other centres as part of an extract if > required. This requires standardisation of access control groups. > We have done some work in Australia to get a set of access groups > that could be standardised across health care and I enclose a copy > of this document for your consideration. > > Hope this is a start - very interested to work with you on this! > > Cheers, Sam > > -----Original Message----- > From: owner-openehr-technical at openehr.org > [mailto:owner-openehr-technical at openehr.org]On Behalf Of Bill > Walton > Sent: Thursday, 24 April 2003 7:36 AM > To: openehr-technical at openehr.org > Subject: openEHR security > > I apologize for not having had the time to dig in and find > this out for myself yet, but I'd really appreciate it if > someone could tell me if security has been addressed in the > openEHR architecture and, if so, point me to the > documentation. I'm trying to understand the system's > capabilities to limit access not only to authorized > individuals, but also to limit the access of authorized > individuals to specific subsets of an individual's record. > Thanks in advance for showing me where to dig. > > Best regards > Bill > -- .............................................................. Deep Thought Informatics Pty Ltd mailto:thomasXXX at YYYdeepthoughtZZZ.WWWcom.AAAau (remove all caps) openEHR - http://www.openEHR.org Archetypes - http://www.deepthought.com.au/it/archetypes.html Community Informatics - http://www.deepthought.com.au/ci/rii/Output/mainTOC.html .............................................................. - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
