1 ihe iti white paper on authorization rough cut implementation opportunities for bppc dr. jörg...

1

IHE ITI White Paper on Authorization

Rough Cut

Implementation Opportunities for BPPC

Dr. Jörg Caumanns, Raik Kuhlisch, Olaf Rode

Berlin, 13.01.09

2

BPPC Access Control Scenario: Sample MAC Use Case

• Within an affinity domain physicians use an EHR based on IHE XDS to exchange medical data

• The EHR (Affinity Domain) Policy defines 3 Privacy Consent Policies for administrative data access, general medical data access, and sensitive medical data access.

• Data access is explicitly authorized by each patient by signing one of the Privacy Consent Policies (e. g. Patient A allows that his administrative and general medical data may be accessed using the EHR).

• All document entries within the XDS registry are marked according to their confidentiality (administrative data, general medical data, sensitive medical data)

• During the medical workflow each subject (user) is always assigned to a functional role: administrative staff, general care provider, or direct care provider.

• As no billing information is exchanged, the interplay of roles, policies, and confidentiality codes follow the MAC paradigm (i. e. each policy subsumes all less restrictive policies).

• BPPC is used to ensure that each data access is in line with the patient’s consent and that each subject (user) can only access medical information that is dedicated for his role.

3

BPPC Access Control Scenario: Access Control Matrix

Administrative Data

General Medical Data

Sensitive Data

Administrative Staff X

General Care Provider X X

Direct Care Provider X X X

4

BPPC Access Control Scenario: Flow of Control (1/2)

• Prior to accessing any data the subject is authenticated and assigned with a functional role which reflects a mapping of an administrative role into the current treatment context (functional role assignment).

• Based on the current role, it can be decided which policies are useable for the subject (subject policy activation)

• Using an XDS stored query the subject retrieves the metadata of the signed policy document from the XDS document registry (patient policy activation). If no consent is available, a default policy (as defined with the Affinity Domain Policy) is used.

• The policy that is active for the current scenario is the intersection (minimum) of the subject’s activated policy and the activated patient policy (access policy activation)

5

BPPC Access Control Scenario: Policy Activation (MAC)

Administrative Data

General Medical Data

Sensitive Data

Administrative Staff X

General Care Provider X X

Direct Care Provider X X X

active role

of the subject

acce

ss perm

itted

by a

ctivate

dsu

bje

ct policy

acce

ss perm

itted

by a

ctivate

dpatie

nt p

olicy

activatedconfidentiality

6

BPPC Access Control Scenario: Flow of Control (2/2)

• When querying the XDS registry for medical data of the patient, the subject (user) includes the confidentiality codes corresponding to the activated access policy with the request message.

• The XDS registry returns the OIDs and metadata of all documents that match the query and at least one of the provided confidentiality codes [ITI TF-2.3.18.4.1.3.5].

• Using the provided OIDs the subject (user) can now access the documents needed from the XDS document repository.

7

BPPC Access Control Scenario (MAC Example)

context node resource node

Subject Node

authenticate Identity Prv.

Attribute SvcXUA + administrative roles

functional roleassignment

enter context

subject policyactivation

Affinity DomainPolicy

Privacy PolicyConsents

patient policyactivation

XDS Doc. Registryaccess policy

activation

XDS Document Consumer

XDS Doc. Repository

XUA + activated policy

ACS

ACS

PEP PDP

document query

document

retrieval

8


context node

resource node

Subject Domainauthenticate Identity Prv.



enter context





XDS Doc. Registry

access policyactivation


XDS Doc. Repository

XUA + activated policy

ACS

PEP PDPdocumentquery

documentretrieval

Application Domain

Registry

RepositoryPatient Domain

Resource Domain

9


context node

Subject Domainauthenticate Identity Prv.



enter context





Registry


XDS Doc. Repository

XUA + subject policy

ACS


documentretrieval

Application Domain

Registry

RepositoryPatient Domain

Resource Domain


10

BPPC Access Control Deployment (MAC Example)

context node

Subject Nodeauthenticate Identity Prv.



enter context





XDS Registry


XDS Doc. Repository

XUA + subject policy

ACS


documentretrieval

Resource Node


ACS

11

Additional Access Control Scenarios

eCR

epSOS

12

eCR Access Control Pattern

context node

Subject Domain

authenticateIdentity Prv. Attribute Svc

XUA + administrative roles

enter contextPolicy Vocabulary Rolicy Templates


eCR Record Reg.

eCR Data Services

Token Mgmt.

PEP PDP

Application Domain

Registry

Repository

Patient Domain

Resource Domain

Role Policies (RBAC)

STS

STS

admission policyactivation

STS

ACL (DAC)

Patient Consents

PEP PDP

eCR locator

eCR consumer1

3

Policy-ID

4

Policy Cache5

Policy

2

13

epSOS Patient Summary Access Control (just an option..)

Subject Domain

authenticateIdentity Prv. Attribute Svc

XUA + administrative roles

enter context

Pivot Vocabulary Mapping tables

access policy

activation PS Data ServicesPEP PDP

Application Domain

Repository

Patient Domain

Patient Consents

STS

PS consumer

1

National SecurityPolicy (RBAC)

2

3

Resource Domain

Patient Home Country

Physician Home Country

NCP-Network

1 ihe iti white paper on authorization rough cut implementation opportunities for bppc dr. jörg...

Documents