Hi, What is needed are several scenario's or use cases.
I think we need those for two situations at least: - within an organisation - between organisations And then we need to take into account variations in possible architectures. ? With or without an Authorisation server ? The situation where information is polled from a system containing all possible information ? The situation where information is published from a system containing all information Without a series of accepted restrictions the problem will be intractable. (N persons, O Roles, P Participations, Q types of information, R exceptions and S Contexts) Gerard On 2003-04-25 21:53, "Thomas Beale" <thomas at deepthought.com.au> wrote: > > 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 >> -- <private> -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
