1. 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. 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. 3 BPPC Access Control Scenario: Access Control Matrix Administrative Data General Medical Data Sensitive Data Administrative Staff X General Care Provider XX Direct Care Provider XXX

4. 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. 5 BPPC Access Control Scenario: Policy Activation (MAC) Administrative Data General Medical Data Sensitive Data Administrative Staff X General Care Provider XX Direct Care Provider XXX active role of the subject access permitted by activated subject policy access permitted by activated patient policy activated confidentiality

6. 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. 7 BPPC Access Control Scenario (MAC Example) context node resource node Subject Node authenticate Identity Prv. Attribute Svc XUA + administrative roles functional role assignment enter context subject policy activation Affinity Domain Policy Privacy Policy Consents patient policy activation XDS Doc. Registry access policy activation XDS Document Consumer XDS Doc. Repository XUA + activated policy ACS PEP PDP document query document retrieval

8. 8 BPPC Access Control Scenario (MAC Example) context node resource node Subject Domain authenticate Identity Prv. Attribute Svc XUA + administrative roles functional role assignment enter context subject policy activation Affinity Domain Policy Privacy Policy Consents patient policy activation XDS Doc. Registry access policy activation XDS Document Consumer XDS Doc. Repository XUA + activated policy ACS PEP PDP document query document retrieval Application Domain Registry Repository Patient Domain Resource Domain

9. 9 BPPC Access Control Scenario (MAC Example) context node Subject Domain authenticate Identity Prv. Attribute Svc XUA + administrative roles functional role assignment enter context subject policy activation Affinity Domain Policy Privacy Policy Consents patient policy activation Registry XDS Document Consumer XDS Doc. Repository XUA + subject policy ACS PEP PDP document query document retrieval Application Domain Registry Repository Patient Domain Resource Domain access policy activation

10. 10 BPPC Access Control Deployment (MAC Example) context node Subject Node authenticate Identity Prv. Attribute Svc XUA + administrative roles functional role assignment enter context subject policy activation Affinity Domain Policy Privacy Policy Consents patient policy activation XDS Registry XDS Document Consumer XDS Doc. Repository XUA + subject policy ACS PEP PDP document query document retrieval Resource Node access policy activation ACS

11. 11 Additional Access Control Scenarios eCR epSOS

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

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