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 Dear Bill, dear Sam
Meanwhile, security constraint modelling succeeds. This concerns policy modelling, policy negotiation, privilege management, access control, object security categorisation. Unfortunately, the preparation of EU 6th Framework proposals was so time comsuming that I had no time to continue and to distribute the results. The modelling is also part of the EU modEHRa proposal OIA (Thomas and Sam) will be involved in. Best regards Bernd - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
