Bill First, and perhaps you consider this a seperate issue that's out of scope for Access Control, but what about Audit Trails?
SH: openEHR has full version control of all components so we have this thoroughly covered. If you are talking about auditing what is viewed, our research in the early 90s suggested that clinicians were totally against this - and it is very difficult to be sure what is seen unless refresh times, screen size and scrolling are all monitored - the idea is terrifying! 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?" SH: We do believe that it is essential to log access - but not to what unless there is an over-ride on the constraints set by the patient. This could result in an automatic email to the patient in the future. But not policing what the clinician who has access looks at. 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, SH: In openEHR this is versioned like anything else... and 2) a history of accesses to the EHR itself. SH: I agree as long as we are talking access - that is logged - and over-rides and who authorised them and for what reason ( perhaps unconscious in Emergency is appropriate. Patients could set the over-ride capability to be turned off. 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. SH: True - it will only be able to be stored as an HTML rendition unless there is an extract in openEHR - but you are right - this could be saved - this is difficult to police. 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). SH: The fact is, unlike usual systems, there will be more restraints on reads than writes. Research access will be via the kernel with an approved program unless it is one-to-one reading of records when the patient's consent is required anyway. 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. SH: As above 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. SH: The whole approach is to normalise access rather than normalise denial - so a transfer of a record (or part there-of) would almost always mean that the person giving permission for the transfer was happy with the hospital policy - as advertised under these 6 roles. The access control list would have to be changed by an authorative person when parts of the record required for ongoing care had been limited a clinician who had left. Logging these things is far more important than being highly restrictive - the latter being possible if the patient wants this. 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. SH: Again, we have had a lot to say about this over the years. In openEHR - it is the EHR - so the boundary is the model itself. There is a real problem in the federated approach with addressing this - but I think openEHR gives a clean approach. 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. I agree - it is fascinating. Can I point you to our (original work on this - quite philosophical) which I wrote with Len Doyal - a professor of medical ethics in London. http://www.chime.ucl.ac.uk/work-areas/ehrs/GEHR/Deliverables.htm#D8 Keep up the good work! Sam ____________________________________________ Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20030426/8be5b494/attachment.html>
