 | |
Trust scenarios | | |
 Role based
access control
 See XACML
» See also: Use-case: medical record access control
Use-case: Simple access
1. Principal requiring access (P) sends request to a resource server (RS)
2. RS fields request and forwards details to access control policy decision server (AC)
3. AC returns decision on access to RS (permit, deny + obligations)
4. RS checks obligations, performs required actions
5. RS acts on original request
6. RS returns response to P
Use-case: Access with privacy policy
1. Principal requiring access (P) sends request to a resource server (RS)
2. RS fields request and forwards details to policy decision server (AC)
3. AC needs additional information from requester: sends request back to RS
4. RS sends request to P, with privacy policy information
5. P consults local policy for release of additional information. Sends in formation to RS.
6. RS provides additional information to AC.
7. AC returns decision on access to RS (permit, deny + obligations)
8. RS checks obligations, performs required actions
9. RS acts on original request
10. RS returns response to P
Use-case: medical record access control
Based on the first use-case from
http://www.oasis-open.org/committees/xacml/repository/draft-xacml-usecase-01a.pdf
. This use-case should be easily modelled
by mapping the XACML structure into RDF (if XACML have done their job OK ;-).
Clinical Record Use Cases
Title: Clinical Record Use Cases
Terse Description: Control of the creation, maintenance, and access of medical records
and messages
coded in XML.
Version: v0.1
Submitted by: Fred Moses
Date: September 4, 2001
Summary
Access to medical records is governed by ethical and legal privacy requirements and the preferences
of the patient. This use case and its variants illustrate related
confidentiality needs.
Scope
Medical record creation, storage, access, and messaging system and its users.
Actors
·
Creators and readers of medical documents such as physicians and other health care givers
·
Patients
·
Those associated with Patients who have access privileges
·
Payers
·
Institutions (HMOs, government bodies) permitted access.
Process Sequence
Primary Process Flow
A physician creates a record with administrative, medical, and privacy content, signs it, and has it
stored (in XML format) in a records system.
September 9, 2001 OASIS XACML Technical Committee v1.0 Use Case
Key Points:
·
Other personnel may collect portions of the record, such as the administrative information.
·
Access policy must have granularity at the level of elements within the document and individuals within
the actor population.
·
Access policy must be included with the document.
·
The document must have a nonreputable signature.
·
Once signed, the document itself may not be modified.
Alpha Process Variant: Record retrieval
A physician or other permitted actor retrieves all or parts of a record for review or transmission to
other parties.
Key Points:
·
The portion of a document that may be retrieved depends upon the requestor and privacy conditions included
in document. For example:
o
Patient restricts access to specific administrative info (address and phone number) to prevent abusive
ex-spouse from finding her.
o
Restrictions extend beyond the originating organization and follow the record or message to another. (This may warrant the encryption of restricted portions.)
o
Differential access restrictions for especially private information such as psych notes. That
is, while most of a record may be made available to a new actor, restrictions may
be applied in the process.
Beta Process Variant: Record transmittal
A permitted actor retrieves all or part of a record for transmission to other parties. They must
be bound by the same restrictions that already apply to the information.
Key Points:
·
Restrictions extend beyond the originating organization. Encryption may be a means of enforcing
this.
·
Necessary agreements between originator and receiver are beyond the scope of this use case.
Gamma Process Variant: Record addendum
A physician or other caregiver creates an addendum to a record with administrative, medical, and/or
privacy content, signs it, and has it stored (in XML format) with the existing
record in the records system.
Key Points:
·
Since signed records or portions of them may not be modified, some form of a attachment or addendum
must be used.
·
Changes in access permissions may affect the previously existing document and any addenda. Both
patient and care giver can add restrictions. Only the patient can cause
restrictions to be removed. (See the cases regarding information withheld from the patient, below.)
·
Any addenda to the access policy must be included with the document.
·
Should a form of version control be applied?
·
The result must have a nonreputable signature.
·
Once signed, the addendum itself may not be modified.
Delta Process Variant: “Breaking the glass”
A patient arrives at the emergency room unconscious. Caregiver(s) need to be able to assume special
privileges in order to gain access to information that was restricted, but
may be critical in the patient’s care.
Key Points:
·
There need to be people, possibly outside the normal flow, who have special privileges.
o
Do they need to possess a special decryption key?
o
Do there need to be multiple decryption keys such that no single person can break glass.
·
When extraordinary measures are invoked, should a standard mechanism attach a note to the record? See
the comment regarding version control, above.
Epsilon Process Variant: Information is withheld from patient
A psychiatrist receives information that s/he believes could be harmful to the patient or others if
disclosed to the patient. In accordance with the law in the patient’s state, the
psychiatrist marks this information as not to be disclosed to patient. The patient requests access
to his/her psychiatric records. Access to the restricted documents is denied.
Key Points:
·
The patient isn’t the legal owner of his/her records. Except in legally identified cases such
as this, however, the patient has the right to see his/her own record. Thus, there is
a policy that circumstances may modify.
Zeta Process Variant: Patient overrides restrictions
The patient in the previous example obtains an override of the restrictions through legal recourse. Access is permitted.
Key Points:
·
Legal maneuvers are outside the scope of this use case.
·
There is a need for attaching new access privileges to an existing document.
Glossary
Caregiver
Physician, nurse, or other person providing health care. The HIPAA rules gives strict definitions
for this and other personages and devices associated with the health care
process. These are outside the scope of this use case. An informal meaning will suffice.
HIPAA
Health Insurance Portability and Accountability Act of 1996 - An act of Congress specifying, among other
things, privacy standards for medical records. This is augmented by
Department of Health and Human Services rules. See the Web site given below.
Nonreputable signature
A signature signed in such a fashion that the signer couldn’t refute it. See, for example, the
XMLD specification for which there is a link below.
» See also: See XACML
| 
