IHE ITI White Paper on Authorization

1. IHE ITI White Paper on Authorization Rough Cut Implementation Opportunities for BPPC Dr. Jörg Caumanns, Raik Kuhlisch, Olaf RodeBerlin, 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

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) access permittedby activatedpatient policy access permitted by activatedsubject policy activatedconfidentiality active role of the subject

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) authenticate Identity Prv. XUA + administrative roles Attribute Svc enter context Subject Node ACS Privacy PolicyConsents Affinity DomainPolicy subject policyactivation functional roleassignment patient policyactivation XDS Doc. Registry access policyactivation PDP PEP ACS document query XUA + activated policy XDS Doc. Repository document retrieval XDS Document Consumer context node resource node

8. access policyactivation BPPC Access Control Scenario (MAC Example) Subject Domain authenticate Identity Prv. XUA + administrative roles Attribute Svc enter context Privacy PolicyConsents Affinity DomainPolicy subject policyactivation functional roleassignment Application Domain Registry patient policyactivation Repository ACS Patient Domain Resource Domain XDS Doc. Registry XUA + activated policy resource node documentquery PDP PEP XDS Document Consumer XDS Doc. Repository documentretrieval context node

9. BPPC Access Control Scenario (MAC Example) Subject Domain authenticate Identity Prv. XUA + administrative roles Attribute Svc enter context Privacy PolicyConsents Affinity DomainPolicy subject policyactivation functional roleassignment Application Domain ACS Registry patient policyactivation Repository Patient Domain Resource Domain Registry XUA + subject policy access policyactivation documentquery PDP PEP XDS Document Consumer XDS Doc. Repository documentretrieval context node

10. patient policyactivation access policyactivation BPPC Access Control Deployment (MAC Example) Subject Node authenticate Identity Prv. XUA + administrative roles Attribute Svc enter context ACS Privacy PolicyConsents Affinity DomainPolicy subject policyactivation functional roleassignment ACS XDS Registry XUA + subject policy documentquery PDP PEP XDS Document Consumer XDS Doc. Repository documentretrieval context node Resource Node

11. Additional Access Control Scenarios eCR epSOS

12. 2 3 4 1 5 authenticate Attribute Svc Identity Prv. XUA + administrative roles Subject Domain enter context Rolicy Templates Policy Vocabulary context node Application Domain eCR locator eCR consumer Resource Domain Policy eCR Record Reg. Token Mgmt. Policy-ID PDP Patient Domain admission policyactivation ACL (DAC) eCR Data Services PEP PEP STS STS STS Patient Consents access policyactivation Registry PDP Repository Policy Cache Role Policies (RBAC) eCR Access Control Pattern

13. 3 2 1 PEP STS epSOS Patient Summary Access Control (just an option..) authenticate Attribute Svc Identity Prv. XUA + administrative roles Subject Domain enter context PS consumer Physician Home Country NCP-Network Mapping tables Pivot Vocabulary Application Domain Patient Home Country Resource Domain Patient Domain access policyactivation PS Data Services National SecurityPolicy (RBAC) Repository PDP Patient Consents