Thomas Clark wrote: > Hi Bill, > > Suggested roles: > > FAMILY > Class #1: > -immediate > Class #2: > -legal next of kin > Class #3: > -parents > -siblings > > EMERGENCY: > -first responders > -transport > -emergency room > -life support > > NON-MEDICAL CAREGIVERS: > -Patient identified > outpatient services > > LEGAL > -Patient attorney > -health services > -social services > -police services > -fire services > -public health services > > MEDICAL > -family physician > -substitute family physician > -family medical designee > -nursing services > > The Patient can supply specific persons and organizations. However, some > should be identified and granted access based upon their function, e.g., > health and social services. > > -Thomas Clark > > ----- Original Message ----- > From: "Bill Walton" <bill.walton at jstats.com> > To: <openehr-technical at openehr.org> > Sent: Monday, April 28, 2003 12:15 PM > Subject: normalizing access vs. normalizing denial (was openEHR security) > > > >>This is a multi-part message in MIME format. >> >>------=_NextPart_000_0183_01C30D90.8FC88240 >>Xontent-Type: text/plain; >>charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >>HI Sam, >>=20 >> >>>>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. >>=20 >> >>>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 >>=20 >> >> >>------=_NextPart_000_0183_01C30D90.8FC88240 >>Xontent-Type: text/html; >>charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> >><HTML><HEAD> >><META content=3D"text/html; charset=3Diso-8859-1" = >>http-equiv=3DContent-Type> >><META content=3D"MSHTML 5.00.3315.2869" name=3DGENERATOR> >><STYLE></STYLE> >></HEAD> >><BODY bgColor=3D#ffffff> >><DIV><FONT face=3DArial><FONT color=3D#0000ff>HI = >>Sam,</FONT></FONT></DIV> >><DIV><FONT face=3DArial> <BR>> > BW: Related to = >>all of the=20 >>above, it seems like there are probably a number of circumstances that = >>would=20 >>require that the control of the Access Control list itself be capable of = >>being=20 >>over-ridden or delegated. It looks to me like, as currently = >>defined, the=20 >>only roles that could grant access would be the patient and Next of Kin=20 >>roles. But assume, for example, that a patient is hospitalized, = >>needs a=20 >>test performed that can't be performed in the facility, and has = >>designated a=20 >>Next of Kin that's not present. Perhaps it's just a difference = >>between our=20 >>systems, but in the U.S. I can imagine a need to delegate the right to = >>change=20 >>the Access Control list without delegating some of the other decisions = >>(e.g.,=20 >>"pull the plug") that are associated with Next of Kin here. Again, = >>as long=20 >>as the Audit Trails are in place it seems that fears of inappropriate = >>access=20 >>might be effectively balanced against the needs of providers re: access = >>to the=20 >>records for the purpose of delivering the appropriate care. Or = >>perhaps I'm=20 >>misunderstanding the Next of Kin role.<BR> <BR>> SH: The whole = >>approach=20 >>is to normalise access rather than normalise denial - so a transfer of a = >>record=20 >>(or part there-of) would almost always mean that the person giving = >>permission=20 >>for the transfer was happy with the hospital policy - as advertised = >>under these=20 >>6 roles. The access control list would have to be changed by an = >>authorative=20 >>person when parts of the record required for ongoing care had been = >>limited a=20 >>clinician who had left. Logging these things is far more important than = >>being=20 >>highly restrictive - the latter being possible if the patient wants=20 >>this.<BR></FONT></DIV> >><DIV><FONT color=3D#0000ff face=3DArial>It looks to me like maybe there = >>needs to be=20 >>rights to change the Access Control List associated with each of the = >>roles=20 >>currently defined. Or maybe there already are and I've just=20 >>misunderstood. I completely agree that logging is far more = >>important than=20 >>being restrictive. We certainly can't hamper the timely provision = >>of=20 >>care.</FONT></DIV> >><DIV> </DIV> >><DIV><FONT color=3D#0000ff face=3DArial>Thanks,</FONT></DIV> >><DIV><FONT color=3D#0000ff face=3DArial>Bill</FONT></DIV> >><DIV><FONT face=3DArial> </FONT><FONT=20 >>face=3DArial><BR></DIV></FONT></BODY></HTML> >> >>------=_NextPart_000_0183_01C30D90.8FC88240-- >> >>- >>If you have any questions about using this list, >>please send a message to d.lloyd at openehr.org > > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > > Hi friends,
This is an interesting discussion. In that context I like to mention that 10 years ago a paradigm considering structural roles on the one hand and functional roles on the other hand has been successfully introduced and also implemented in several standards. This approach complies also with the newer developments of the more generic HL7 RIM due to the relations between structral roles and RIM Role as well as functional roles and RIM Participation. The old role paradigm fits also into the OMG's view including its expression using UML, etc. It is basis of CEN and ISO standards. Regards Bernd - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
