IHE ITI White Paper on Access Control

1. IHE ITI White Paper on Access Control WP Review Cycle 1 Chapter 4: Actors and Transactions Chapter 5: Examples Chapter 6: Implementation Issues Jörg Caumanns, Raik Kuhlisch, Olaf Rode, Sören BittinsBerlin, 28.04.09

2. Objective of this TCon • step through the examples within chapter 4 and 5 • step through the technical chapter 6 • objectives for the May f2f • planning the presentations for the May f2f

3. Page Count • Access Control in Healthcare 3.0 pages • Fundamentals of Access Control 10.0 pages • Policies and Attributes 16.0 pages • Actors and Transactions 26.0 pages • Examples 12.0 pages • Implementation Issues 5.0 pages • Annex (glossary, standards, ..) 3.0 pages • 75.0 pages 1 2 3 4 5 6 A

4. Status • Chapter 1 finalized, minor open issues • Chapter 2 finalized, minor open issues • Chapter 3 1st draft, open issues from February TCon • Chapter 4 1st draft, open issues from March TCon • Chapter 5 1 of 2 examples; subject to this TCon • Chapter 6 1st draft, subject to this TCon 1 2 3 4 5 6 A

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 31st: 52/70 pages written • April 28th : 68/75 pages written

6. Chapter 4: Actors and Transactions Sample Environments

7. 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

8. Default Flow of Control org ID subject ID STS Identity Prv. subject role subject ID XUA patient ID org ID Subject Domain subject role Context Domain role activation app ID STS purpose ID subject ID consumer org ID XUA subject role purpose ID patient ID Resource Domain Patient Domain app ID patient ID STS resource ID app ID policy activation patient privacy policy resource type PEP / PDP resource

9. Sample Environment: Thin Client • Environment and Requirements: • Only web browsers are to be used as clients. • Possible Solution: • The context domain and its ACS are deployed as a web application that is accessible through a web portal. HCPs use a single sign-on with a second web portal. Whenever the application portal is called without a valid XUA, the portal redirects the user to the log-in portal. The log-in portal verifies the user’s credentials and upon success redirects the user back to the application portal. This interplay of the two portals is invisible to the user and can be automatted by using standard protocols (e. g. SAML HTTP POST Binding).

10. Sample Environment: Thin Client

11. Sample Environment: Affinity Domain • Environment and Requirements: • The hospital network is set up as a XDS affinity domain with a central registry and distributed repositories within the participating 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.

12. Sample Environment: Affinity Domain • Possible Solution: • The registry and all repositories are modeled as resource domains. Each resource domain contains its own ACS which enforces the patient’s privacy consent. In contrast to the previous example a policy push pattern is recommended because otherwise the policy would have to be discovered and fetched for each repository access. • It has to be noted that the policy has to be evaluated and enforced for each query and retrieve transaction. Assuming that the registry is only queried once this results in n+1 evaluations of the same set of rules against the same set of attributes for the retrieval of n documents.

13. Sample Environment: Document Prefetch • Environment and Requirements: • When a patient registers for an examination at a physician the respective organization may want to fetch that patient’s historical data in advance. This results in two copies of the data that must both be protected from inlegitimate disclosure with respect to the access rights granted by the patient.

14. Document Prefetch Step 1: Prefetching Documents

15. Document Prefetch Step 2: Accessing Documents

16. Sample Environment: Cross-Domain • Environment and Requirements: • The existing hospital network is joint with two other adjacent regional networks, whith each of the three networks being set up as an independent affinity domain. Patients can give consent that upon their will each physician connected to this extended circle of trust may access historical data even cross-domain. This consent is given with each affinity domain where historical data of that patient is gathered.

17. Sample Environment: Cross-Domain • In this scenario each registry and repository within any of the affinity domains represents a resource domain on its own. Cross-domain messaging and routing is implemented using the IHE XCA profile and therefore the document consumer does not have to be aware of the distributed nature of the historical data application. Policies have to be enforced within each resource domain (Due to the dedicated consents these domains each carry responsibilities for the legitimacy of data processing). Policies can only be pulled because they are distributed among the affinity domains and therefore only a node within a domain can “know” where the respective policy is made accessible. • For this scenario to work all affected affinity domains have to agree upon the semantics of the attributes that are used to express roles and other subject properties. Otherwise a resource-side PEP/PDP will not be able to use these attributes for the retrieval and/or evaluation of the patient’s privacy policy which will then result in an access denial (following the principle of fail-safe defaults).

18. Chapter 5.2: BPPC Example Core BPPC Resource-Side Role Activation Resource Security Policy Opt-Out

19. Storyboard • In a metropolitan area, a regional healthcare network is set up as an IHE XDS affinity domain. • Patients may consent that part of their medical data is registered with a central XDS registry in order to make it available for all physicians within the network. • For reasons of simplicity it is decided to use IHE BPPC for consent management and enforcement.

20. Core BPPC

21. Predefined Consents

22. Access Rules (Affinity Domain Policy)

23. Context-Side Enforcement

24. Resource-Side Enforcement

25. Deployment and Implementation • For the given scenarios and environment the context domain and the subject domain will be deployed within the healthcare professional organization that utilizes the patient’s data. Following the default deployment of BPPC the resource domain and the patient domain are integrated. Signed consent documents and their respective metadata (containing the consent ID) can be managed within the same registry and repositories as the patients’ medical data. • Both context-side and resource-side enforcement can be implemented using the existing BPPC transactions. The only difference is the deployment of the application logic for consent verification and policy enforcement (document consumer vs. document provider).

26. Extension: Resource-Side Role Activation • As one can see from the two previous figures, BPPC requires strict environmental security at the client because the attribute that is used for policy decision (roles which determine the OIDs of the acceptable consents) is provided by the user himself. If IHE ATNA (node authentication) is used as the only trust establishing means, the trust relationship among the resource and the client domain is rather weak because ATNA can neither safeguard an business layer application nor a human user. • Therefore from the perspective of the resource provider it would be desirable not to be provided a list of applicable consents but rather get authentic attributes on the subject’s role and the consents given by the patient. This information is suitable to decide on the affinity domain policy without relying on the user to claim for himself which consents he might utilize.

27. Resource-Side Role Activation

28. Deployment and Implementation • For the given scenario and environment the context domain and the subject domain will be deployed within the healthcare professional organization that utilizes the patient’s data. If a direct trust relationship among the subject domain and the resource domain can be established, common local role assignment mechanisms can be used. Otherwise the role identifier must be safeguarded by an XUA in order to ensure its authenticity. • Following the default deployment of BPPC the resource domain and the consent domain are integrated. Signed consent documents and their respective metadata (containing the consent ID) can be managed within the same registry and repositories as the patients’ medical data. • If the document consumer handles over role identifiers instead of the XUA this scenario can be implemented using the existing BPPC transaction. The only semantic extension is that the resource provider must be able to map roles onto usable consents.

29. Extension: Resource Security Policy • As the regional healthcare data exchange is well accepted by patients and physicians, further business scenarios are set up on top of the existing network. Among these is an application to support data exchange within the context of integrated care contracts. This application introduces health insurance companies as actors, which are – by contract – authorized to access certain forms of their insured patients for the purpose of quality assurance. • Additional Policy: A security policy is defined which states that employees of insurance companies can only access documents with certain HL7 class codes. Further more it must be ensured that the patient has signed an integrated care contract and has a contract with the insurance company. An additional consent is defined that expresses the patient’s will to allow this restricted data access for his health insurer.

30. Resource Security Policy: Attributes

32. Deployment and Implementation • The attribute service for requesting additional patient data (health insurer and signed IC contracts) is deployed as a dedicated central service within the XDS affinity domain. This functionality can e. g. be added to the existing PDQ implementation. • As the document consumer handles over XUAs instead of role identifiers this scenario cannot be implemented using existing implementations of the BPPC safeguarded registry transactions. Nevertheless, if XDS.b is used, the only required extension is to place the XUA into the message’s security header (see section 6.x).

33. Extension: Opt-Out • The recent policy enables each member of the network to access the patients administrative and (non-sensitive) medical data. Even more as access rights to sensitive data are granted by giving consent to organizations all staff members of these organizations can access the patient’s sensitive data. In order to empower the patient it is decided that patients should be enable to set up “black lists” of organizations and individuals they explicitly don’t want to get insight into their data.

35. Chapter 6: Implementation Issues Overview of Security Standards Composition Security Token Encoding and Exchange Policy Encoding

36. Security Standards Composition • Not mandatory but well-established standards:

37. Security Token Encoding and Exchange • Combination of WS Trust and SAML assertions provides „Proof-of-Possession“ mechanism -> out of the box feature of various implementations • Assertion Issuing via WS Trust protocol • Recommendation: Transfer Assertion to Relying party in SOAP Security Header • Subject authentication and subject attribute exchange based on XUA •  chapter describes mapping to XUA • Policy may be also encoded and communicated by the means of SAML

38. Security Token Chaining • Two opportunities (assumption: use of SAML Assertions as tokens) • XUA assertion might be bound to another (policy) assertion that holds an access policy.  SAML Assertion provides referencing or embedding other assertions by using the elements “Advice” or “Evidence”. • Create hash including subject and attributes (contents) and add it as an attribute to XUA. Policy assertion applies the same hash and adds it, too.  Compare both hash values in order to verify the correct chain.

39. Policy Encoding • Requirement for interoperability: In distributed access control systems, a standardized request/response language and encoding of the policies itself must be present. • Possible encoding languages: SAML, XACML, XrML • OPEN ISSUE POLICY RETRIEVAL: • Definition of BPPC as Policy Markup & Localization • Description of XDS.b as Policy Store

40. Open Issues for the May f2F Objective of the Meeting Objectives of the two Presentations Further Processing