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" <[email protected]> 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
