HI Sam, > > BW: 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.
It looks to me like maybe there needs to be rights to change the Access Control List associated with each of the roles currently defined. Or maybe there already are and I've just misunderstood. I completely agree that logging is far more important than being restrictive. We certainly can't hamper the timely provision of care. Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20030428/0d226f47/attachment.html>
