1. 1 IHE ITI White Paper on Access Control WP Review Cycle 1 Chapter 4: Actors and Transactions Chapter 6: Implementation Issues Dr. Jörg Caumanns, Raik Kuhlisch, Olaf Rode Berlin, 31.03.09

2. 2 Objective of this TCon -step through chapter 4 and consolidate organization -discuss the recommendations for IHE actions -schedule until May f2f

3. 3 Page Count Access Control in Healthcare 3.0 pages Fundamentals of Access Control10.0 pages (can be reduced by 1-2) Policies and Attributes16.0 pages(can be reduced by 2-3) Actors and Transactions22.0 pages(can be reduced by 2-4) Examples 8.0 pages Implementation Issues 8.0 pages(redundancies with 3 and 4) Annex (glossary, standards,..) 3.0 pages 70.0 pages(could be reduced to 60-65) 123456A

4. 4 Status Chapter 1finalized, minor open issues Chapter 2finalized, minor open issues Chapter 31st draft, open issues from February TCon Chapter 41st draft, core discussed at last TCon Chapter 5subject to next TCon Chapter 61st outline and fragments 123456A

5. 5 State to reach before May f2f Chapter 1: no severe open issues; will be moved forward to the next phase Chapter 2: no severe open issues; will be moved forward to the next phase Chapter 3: no severe open issues; will be moved forward to the next phase Chapter 4: no severe open issues; will be moved forward to the next phase Chapter 5: open issues on examples identified; will be discussed at f2f Chapter 6: open issues on standards/profiles identified; will be discussed at f2f March 31 st : 52/70 pages written April 24 th : 70/70 pages written

6. 6 Chapter 4: Actors and Transactions [~20-24 pages] Intro and Sample Use Case[1.5 pages] Methodology Overview[0.5 pages]-> should be 1.0 Step 1: Policy and Attributes[1.0 pages] Step 2: Attribute-Domain Mapping[2.0 pages] Step 3: Default Flow [5.0 pages] Step 4: Adaptation[5.0 pages] Step 5: Deployment[1.0 pages] Sample Environments[2.5 pages] Actors and Transactions[4.0 pages]

7. 7 Open Issue from last TCon: Diagram Syntax

8. 8 UML Collaboration Diagram

9. 9 UML Sequence Diagram

10. 10 UML Activity Diagram

11. 11 Sample Use Case: 1 Storyboard, multiple environments In a metropolitan area several hospitals set up a network for the exchange of medical patient data. Because of the high density of hospitals, the medical specialization of many of these hospitals, and a high degree of transparency with respect to treatment-specific quality parameters it has been observed that many patients visit different hospitals for different purposes and diseases. During anamnesis physicians often get aware of former treatment at other hospitals and the existence of diagnostic data that might be useful for consideration in order to evaluate the severity of ongoing processes and to verify a suspected diagnosis. To face this situation a dedicated application is designed on top of the hospital network that enables physicians to easily access historical data from other hospitals that might be relevant for recent diagnosis (e. g. lab data, radiologic data). An access to this data is only permitted after the patient has consented: what kind of data might be accessed which organizations might access this data which roles are authorized to access this data for what purpose the data might be accessed

12. 12 Methodology 1.Design a policy profile and identify the attributes needed to instantiate the profile (see section 3 and section 4.3) 2.Identify the attribute sources and domains where these attribute can be made available (see section 4.4) 3.Define the default flow of control among the client-side and resource-side ACS (see section 4.5) 4.Optimize the flow of control with respect to the prioritized requirements (see sections 4.6 and 4.8) 5.Deploy the (logical) domains onto physical nodes (see sections 4.7 and 4.8) 6.Map the ACS building blocks and the messages among them onto actors and transactions (see section 4.9 and 6)

13. 13 Step 1 policy instance role-ID org-ID purpose-ID patient-ID res.type-ID policy decision policy activation lab data physician treatment clinic A patient attribute subject attribute context attribute subject attribute resource attribute resource ID my data resource attribute App-ID context attr. historical DB

14. 14 Context Domain Subject Domain Patient Domain Resource Domain patient privacy policy (consent) org. security policy resource Application Domain application security policy org. security policy STS request initiator Trust Step 2 patient ID organization ID subject ID purpose ID resource ID subject role ID resource type organization ID application id application ID Patient Privacy Policy: org: Clinic A role: physician purpose: treatment kind-of: lab data subject role ID

15. 15 Step 3a Context Domain STS Subject Domain purpose ID context activation Identity Prv. consumer subject role STS subject ID org ID subject role org ID XUA app ID subject ID patient ID organization ID subject ID subject role ID role activation....

16. 16 Step 3b Patient Domain Resource Domain patient privacy policy resource ID policy activation PEP / PDP resource resource type patient ID purpose ID patient ID subject role org ID XUA app ID query for app ID request initiator

17. 17 Context Domain STS Subject Domain purpose ID role activation Identity Prv. consumer subject role STS org ID subject role org ID XUA app ID subject ID patient ID subject ID subject role org ID subject ID STS Patient Domain Resource Domain patient privacy policy resource ID policy activation PEP / PDP resource resource type patient ID app ID XUA purpose ID patient ID app ID Step 3

18. 18 Context Domain consumer STS Patient Domain Resource Domain patient privacy policy policy activation PEP / PDP resource Context Domain consumer STS Patient Domain Resource Domain patient privacy policy policy activation PEP / PDP resource STS Context Domain consumer STS Patient Domain Resource Domain patient privacy policy policy activation PEP / PDP resource STS policy ID STS policy repository policy Policy Pull Policy Push Policy Cache

19. 19 Sample Environments (1/2) Thin Client Only web browsers are to be used as clients. Access control is implemented by the web portal that schedules queries and other requests to the respective databases at the participating hospitals. Affinity Domain The hospital network is set up as a XDS affinity domain with a central registry and distributed repositories within the hospitals. Queries for patient historical data are based on the IHE ITI-016 Query Registry transaction. The registry’s response only contains references to documents that match the patient’s privacy consent. Data itself is retrieved using the IHE ITI-017 Retrieve Document transaction. Again the restrictions of the patient’s consent have to be considered. For reasons of efficiency the policy should not be evaluated twice (once for each transaction) for retrieving a single document.

20. 20 Sample Environments (2/2) Integration of an existing repository The hospital network is set up as sketched in 4.8.2. One of the participating hospitals uses an XDS repository implementation where the vendor is unable to integrate an ACS. Application Service Integration The historical database application is implemented as a web service that encapsulates the XDS affinity domain of the hospital network. Multiple Affinity Domains The hospital network is set up from multiple affinity domains which each consisting of a registry and a repository.

21. 21 STS X-Service User and ST provider actors are abstract superactors from which other actors can be derived that require a trusted encoding of their issued claims (comparable to the publisher and subscriber actors). Other Actor X-Service User ST Provider get X-Assertion STS Wrapper ST Verifier safeguard claim verify claim Trust X-Service Provider verify claim provide X-Assertion

22. 22 STS Recommendation: IHE should define a framework for the definition of interoperable “get X-Assertion” and “provide X-assertion” transactions. This framework should consider two different levels of trust: direct trust (X-Service User consumes X-Assertion) and brokered trust (X-Service User as intermediary between X-Service Provider and ST Provider). Other Actor X-Service User ST Provider get X-Assertion STS Wrapper ST Verifier safeguard claim verify claim Trust X-Service Provider verify claim provide X-Assertion

23. 23 Attribute Provider Recommendation: IHE should define a PIP as an instance of the STS-framework (see 4.9.1) for querying for attributes about an otherwise authenticated subject. The respective actors and transactions are needed for infrastructures where subject authentication is performed within a domain that does not maintain role and organization membership information about the authenticated subject. E. g. if a health professional card is used, authentication is performed within a central subject domain (e. g. a nationwide PKI) while most of the subject’s attributes are managed with the enterprises subject domain (e. g. enterprise HR services).

24. 24 Policy Activation subject purpose of use activated roles... policy patient assignment claim (scenario-policy) policy-ID The assignment of a policy to an access request must be verifiable for the PDP. The assignment is as trustworthy as the service that claims to have done this assignment by activating the referenced policy. Two transactions are required to implement all three policy activation patterns: 1. activation/retrieval of a policy for a certain scenario - response includes just the policy (policy pull pattern) - response includes just the assignment claim (policy cache pattern) - response includes assignment claim and policy (policy push pattern) 2. retrieval of a policy for a given policy-ID (policy cache pattern)

25. 25 Policy Activation As assignment claims must be authentic the issuing actor should be derived from the previously defined “ST provider” actor. Depending on the activation pattern the policy enforcing PDP and the ACS of the context side business service consumer take different roles: PatternPolicy ActivatorPolicy enforcing PDPContext domain ACS Policy pullST ProviderX-Service User as X-Assertion Consumer (not involved) Policy pushST ProviderX-Service ProviderX-Service User as X-Assertion Broker (claim) Policy cacheST ProviderX-Service Provider (claim) and X-Service User (policy) as X- Assertion Consumer X-Service User as X-Assertion Broker (claim) Recommendation: IHE should provide a profile consisting of an policy activator actor (derived from the ST Provider superactor, focused on brokered trust scenarios) and a policy registry (derived from the ST Provider superactor, focused on direct trust scenarios) with transactions for policy activation (claim retrieval) and policy retrieval.

26. 26 PEP/PDP ensemble There is no need for a dedicated profile, because all transactions are already covered by the other recommended profiles. The only exception is PEP-PDP communication (XACML within SAML authorization decision stmt), which is an interoperability issue if PEP and PDP are distributed among different domains. Recommendation: PEP/PDP should not be a profile in the 2009/2010 cycle. Instead the WP should be adapted to the other transactions recommended for profiling work in this paper after they passed their first connect-a-thon.

27. 27 Identified minor Issues Wording: “consumer”, “initiator”, “client”,... Wording: “enforcing policy decision” instead of “enforcing policy” Wording: “pattern” vs. “variants” in section 4.6ff

28. 28 Schedule (April 2009) MondayTuesdayWednesdayThursdayFridaySaturdaySunday 303112345 6789101112 131415 epSOS 16 epSOS 17 epSOS 1819 2021 epSOS 22 epSOS 23 epSOS 242526 27282930123 Chapter 5 (Examples) Chapter 3-6 (Open Issues)