1. 1 IHE ITI White Paper on Authorization Rapid Walk-Through Jörg Caumanns, Raik Kuhlisch, Oliver Pfaff, Olaf Rode, Christof Strack, Heiko Lemke Chicago, 26.01.09

2. 2 Editing Team Authors:Raik Kuhlisch, Jörg Caumanns // Fraunhofer ISST Oliver Pfaff, Markus Franke // Siemens IT Solutions // and Services Christof Strack, Heiko Lemke// SUN Microsystems Supervisior:Rob Horn// Agfa Healthcare Editorial Team:John Moehrke// GE Healthcare Lynn Felhofer // MIR Manuel Metz// GIP-DMP

3. 3 Storyline of the White Paper There is no “one-fits-all” solution for authorization access control requirements and paradigms vary policies, verifiable attributes, and attribute sources vary granularity of protected items varies deployment varies Therefore this white paper does not provide a single deployment of ACS and its building blocks among static domains. It rather provides healthcare system architects with a model and a corresponding methodology: The model describes how the building blocks of a distributed access control solution can be described in a manner that is both deployment and implementation independent. The methodology defines how system architects can use the model to reason about different realization opportunities in order to discover the most appropriate deployment and flow of control with respect to the given application architectures requirements. Deployment and implementation issues are handled in a generic way. The application of concrete standards will be subject to future profiles.

4. 4 Outline of the White Paper[59.5 pages] 1.Access Control in Healthcare (Motivation/Outline)[ 2.5 pages] 2.State-of-the-Art [ 8.5 pages] 3.Policies and Attributes [ 7.0 pages] 4.Common Access Control Model [ 8.5 pages] 5.Sample Adaptations of the Common Model [10.0 pages] 6.Methodology for Using the Common Model [12.0 pages] 7.Deployment and Implementation Issues [ 8.0 pages] 8.Appendix: Glossary of Terms [ 1.5 pages] 9.Appendix: Vocabularies for Attribute Names and Values[ 1.5 pages]

5. 5 Chapter 1: Access Control in Healthcare [2.50 pages] Motivation [0.75 page] Typical Access Control Scenarios in Healthcare[1.00 page] Objective and Outline [0.75 page]

6. 6 Chapter 2: State-of-the-Art[8.5 pages] State of the Art Principles of Secure Design [1.00 pages] Paradigms: DAC, MAC, RBAC,... [1.50 pages] Policy Based Access Control (PEP, PDP,...) [1.00 pages] SOA Security Decouple Authorization and Authentication [0.50 pages] Decouple Security Object Lookup and Use [0.50 pages] Access Control System Conceptual Model vs. Deployment vs. Implementation[1.00 pages] Context Domain, Subject Domain, Resource Domain [1.00 pages] Management of Attributes and Policies [0.50 pages] Trust Relationships[0.50 pages] Federated Healthcare Environments [1.00 pages] Federation of the Resource Domain (XCA) Federated Identities within the Subject Domain (XUA) Distributed Patient Attributes (PIX, XCPI)

7. 7 XSPA SAML Profile / HITSP TP20 High-Level Interactions trust relationship [SOA-style security!]

8. 8 Core Model (XSPA + externalized IdP) ACS STS Context Domain ACS Subject Domain ACS STS Resource Domain Identity Prv. request initiator resource circle of trust enter context PEP / PDP STS Attribute Svc Policy Authority PEP / PDP Attribute SvcPolicy Authority

9. 9 Core Model (XSPA + externalized IdP) ACS STS Context Domain ACS Subject Domain ACS STS Resource Domain Identity Prv. request initiator resource circle of trust enter context PEP / PDP STS Attribute Svc Policy Authority PEP / PDP Attribute SvcPolicy Authority XUA XDS XUA XCA PIX/PDQ PWP XDS, PHR,...

10. 10 Chapter 3: Policies and Attributes [7.00 pages] Granularities and Flavours of protected Resources[2.00 pages] Application, Session, Service, Data,... Nesting and Sequencing of Policies Access Policies vs. Behaviour Policies Instantiation of access rights for organizations The Role of the Patient [1.50 pages] Consents and Policies client-side vs. resource-side enforcement patient-bound tokens (e. g. EHCs) Resource Security through Role Based Access Control [2.00 pages] Needs-to-Know Principle Structural vs. Functional Roles (HL7 role engineering) Policy Conflicts Policy and Attribute Sources [1.50 pages] Policy Authorities Attribute Value Authorities Binding of policies and attributes

11. 11 Applications as Legal Frameworks XDS: Shared Medical Data Privacy Policy Security Policy Purpose of Use EHR, PHR, eCR,... App. Policy activates

12. 12 Resource Access Policy: Who is allowed to access my EHR for the given purpose/context? Resource Behaviour Policy: How may authorized subjects work with my EHR? EHR Definition Privacy Consent National Law Agreement Configuration AuthorizationScope, Procedure,... Regulations Access Policies vs. Behaviour Policies

13. 13 Needs-to-Know Principle (e. g. Treatment Contract) The objective of access control is to provide all physicians the information they need to know in order to treat the patient the best way - while respecting the patient’s right towards self-determination - while protecting the confidentiality and integrity of medical data

14. 14 HL7 Role Engineering

15. 15 Authorization vs. Organization of Labor “Patient has specified constraints that would limit of all oncologists, access to the radiology portion of the patient record.„ (taken from Proposed Use Cases for XSPA TC) „Patient has specified constraints that would exclude the head of the radiologic dept. access to the radiology portion of the patient record.„ (opt-out scenario) These consents must not be enforced by technical access control means because they violate the underlying organization of labor! e. g. oncologists „must know“ radiology data in order to decide on a surgery e. g. head of dept. „must know“ the work results of his staff in order to control quality Bold statement is too rigid. The problem must be discussed in more depth in the WP.

16. 16 policy subject-ID role-ID (adm) policy activation context-ID purpose-ID role-ID (func) patient-ID resource-ID activity-ID policy consumer represents policy-ID * attribute value * policy decision resource provider attribute value * policy-ID * evaluates accept or deny... res.type-ID Attributes and Policies

17. 17 Chapter 4: Common Healthcare ACS Model [8.5 pages] Introduction of the model[2.0 pages] Identification and Authentication [1.5 pages] Subject Authentication (XUA) Role Attributes and Role Activation Patient Identification Privacy Policy Activation and Session Control [2.5 pages] Context Activation Application Policy Activation Privacy Policy Activation Separation of DAC- and RBAC-style rules Policy Decision and Enforcement Resource Control [2.5 pages] Resource Policy Selection Resource Attribute Retrieval Policy Decision and Enforcement

18. 18 4-Domain Model ACS STS Context Domain ACS STS Subject Domain ACS STS Patient Domain ACS STS Resource Domain patient privacy policy (consent) context attributes subject attributes resource attributes role activation consent activation Identity Prv. PEP / PDP org. security policy request initiator resource Attribute Svc. PEP / PDP org. security policy

19. 19 5-Domain Model ACS STS Context Domain ACS STS Subject Domain ACS STS Patient Domain ACS STS Resource Domain patient privacy policy (consent) context attributes subject attributes resource attributes role activation consent activation Identity Prv. PEP / PDP org. security policy request initiator resource Attribute Svc. PEP / PDP Application Domain ACS STS application attributes PEP / PDP app. security policy org. security policy

20. 20 Role Activation and Permission Assignment (XSPA) role activation permission catalogue

21. 21 Policy Activation (Example: Consent) - XSPA POU and User Based Access (UBA) Control Resource Object Masking (MA)

22. 22 Attribute Usage policy subject-ID role-ID (struct) policy-ID context-ID purpose-ID role-ID (func) patient-ID resource-attr activity-ID policy decision policy enforcement role activation context activation Enter Context policy activation org.-ID

23. 23 Conclusion Using the same set of building blocks (actors) and messages (transactions) very different flows of control can be realized in order to match the non-functional requirements of the application scenario. Different domains use building blocks with identical functionality and semantics. Therefore these blocks are generic in away that they are independent from their environment. There are different opportunities to implement the actors and transactions that make up the common building blocks. But: To allow for a multi-vendor strategy and for cross-enterprise communication these implementations must be interoperable. There is a need for interoperability profiles (comparable to XUA) for policy activation, attribute retrieval, and attribute/policy integration into transactions.

24. 24 To be done: Definition of re-usable building blocks Identity Provider Actor: XUA + Attributes (extension to XUA?) Attribute Service Actor: encapsulates LDAP services; provides attribute values (if bound to requestor domain, PWP will do for now) Role Activation Actor: receives XUA+ and provides functional role (no interop problem except agreement on codes; not conceptually mature) Policy Activation Actor: 1. receives XUA+, attributes and provides policy or policy ID 2. receives policy-ID and provides policy PEP/PDP Actor: receives XUA+, attributes and (opt.) policy; consumes policy (opt); consumes attributes (opt.), provides policy decision, consumes audit trail

25. 25 To be done: Using IHE Profiles as a Base for the BB Policy activation using XDS Dealing with BPPC (rough cut; details in the samples chapter) Using PWP for subject attribute retrieval Using XUA for Identity Provisioning

26. 26 Chapter 6: Methodology Policy Determination Session Control vs. Resource Control Policy Authorities Paradigms for Patient Privacy Policy, App Policy, Resource Policy Policy Assignment (Indexing for Retrieval) Attribute Identification Identification of Attribute Stubs Domain Assignment Policy Assignment Specification of Attribute Value Sources Policy Management Policy Encoding Policy Deployment

27. 27 Chapter 6: Methodology Access Control Systems within the Domains PEP/PDP Placement Policy Retrieval (Pull/Push) Attribute Retrieval (Pull/Push) Authorization Request Interface Integration of the ACSs into the Application Control Flow Session Management (if required) Mapping of Resource Requests onto Authorization Requests Security Token Control Flow Policy Lifecycle Management

28. 28 TP20: Development of Security and Privacy Protections

29. 29 Use-Cases: Exemplary Consent CIS Clinic B CIS Clinic A Consent exchange I hereby authorise Clinic A to share all my diabetes-related medical data with diabetologists at Clinic B in case that I require a treatment while I am at Clinic B.

30. 30 governs Use-Cases: Definition of (umbrella) Policies Consent I hereby authorise Clinic A to share all my diabetes-related medical data with the diabetologists of Clinic B in case that I require a treatment while I am at Clinic B. Patient Privacy Policy : Clinic A as source diabetologist working in Clinic B currently treating me diabetic-related data enables / legitimates forms CIS Clinic B CIS Clinic A XDS XCA

31. 31 Use-Cases: Alignment to Domain Model ACS STS Context Domain ACS STS Subject Domain ACS STS Patient Domain ACS STS Resource Domain patient privacy policy (consent) context attributes subject attributes resource attributes role activation consent activation Identity Prv. PEP / PDP org. security policy request initiator resource Attribute Svc. PEP / PDP involved in treatment role diabetologist repres. of Clinic A diabetic related data Patient Privacy Policy : Clinic A as source diabetologist working in Clinic B currently treating me diabetic-related data

32. 32 Core Methodology Multistep process that distinguishes between: - Tooltime and - Runtime activities No Defaults: Authorization Model (DAC, MAC, RBAC,...), Attribute Types and Sources Defaults: Syntax of policies

33. 33 Core Methodology (Tooltime) 1. Define Attributes (Desired Values) Configuration Attribute Stubs Attribute Value Source Subject ¬ Subject (Resource,App) e.g. Org. Type ID Datatype Internal (Aut/SSO) External (Classes)

34. 34 Attribute Stub Definition (Example) I hereby authorise Clinic A to share all my diabetes-related medical data with Diabetologists at Clinic B in case that I require a treatment at Clinic B. Patient Privacy Consent Model policy role-ID org-ID purpose-ID patient-ID res.type-ID policy decision policy activation diabetes related Diabetologist treatment clinic A resource ID my medical data

35. 35 Attribute Stub Definition (Example) I hereby authorise Clinic A to share all my diabetes-related medical data with Diabetologists at Clinic B in case that I require a treatment at Clinic B. Patient Privacy Consent Model policy role-ID org-ID purpose-ID patient-ID res.type-ID policy decision policy activation diabetes related Diabetologist treatment clinic A context attribute subject attribute context attribute subject attribute resource attribute resource ID my medical data resource attribute

36. 36 Use-Case: Attributes Context Domain STS Subject Domain ACS Resource Domain purpose ID resource ID role activation Identity Prv. PEP / PDP request initiator resource subject role patient ID org ID resource type STS subject ID org ID

37. 37 Core Methodology (Tooltime) 2. Policy Building by Given Syntax Configuration Attribute Stubs Attribute Value Source Subject ¬ Subject (Resource,App) e.g. Org. Type ID Datatype Internal (Aut/SSO) External (Classes) Policy

38. 38 Core Methodology (Tooltime) 3. Policy Deployment Configuration Attribute Stubs Attribute Value Source Subject ¬ Subject (Resource,App) e.g. Org. Type ID Datatype Internal (Aut/SSO) External (Classes) Policy Policy Service Management

39. 39 Use-Case: Policy Context Domain STS Subject Domain STS Patient Domain ACS Resource Domain patient privacy policy purpose ID resource ID role activation policy activation Identity Prv. PEP / PDP request initiator resource subject role patient ID org ID resource type STS subject ID org ID

40. 40 Core Methodology (Runtime) 1.Service Request 2.Authorization Request Generation Business Service Configuration Requestor 1 2 Access Control System

41. 41 Use-Case: Initial Flow of Control Context Domain STS Subject Domain STS Patient Domain Resource Domain patient privacy policy purpose ID resource ID role activation policy activation Identity Prv. PEP / PDP request initiator resource subject role patient ID org ID resource type STS subject ID org ID

42. 42 Core Methodology (Runtime) 2. Authorization Request Processing (Policy Discovery and Evaluation) Application Resource PDP PEP Policy Finder Configuration Policy Policy Service Management ACS

43. 43 Use-Case: Policy Retrieval Context Domain STS Subject Domain STS Patient Domain Resource Domain patient privacy policy purpose ID resource ID role activation policy activation Identity Prv. PEP / PDP request initiator resource subject role patient ID org ID resource type STS 1 2 3 4 subject ID org ID

44. 44 Use-Case: Attribute Flow Context Domain STS Subject Domain STS Patient Domain Resource Domain patient privacy policy purpose ID resource ID role activation policy activation Identity Prv. PEP / PDP request initiator resource subject role patient ID org ID resource type STS patient ID purpose ID patient ID subject ID org ID subject role org ID XUA

45. 45 Use-Case: Attribute Flow [Patient Safety Mode] Context Domain STS Subject Domain STS Patient Domain Resource Domain default policy purpose ID resource ID role activation policy activation Identity Prv. PEP / PDP request initiator resource subject role patient ID org ID resource type STS purpose ID patient ID subject ID org ID XUA

46. 46 Use-Case: Single Sign-On Context Domain STS Subject Domain STS Patient Domain Resource Domain patient privacy policy purpose ID resource ID role activation policy activation Identity Prv. PEP / PDP request initiator resource subject role patient ID org ID resource type STS patient ID purpose ID subject role patient ID org ID subject ID subject role org ID XUA

47. 47 Configuration Opportunities may as well be pushed with request may be pushed with request as security token caller-side vs. resource-side enforcement

48. 48 Policy Pull vs. Policy Push

49. 49 Use-Case: Policy Push Context Domain STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID role activation policy activation Identity Prv. PEP / PDP request initiator resource subject role resource type STS patient ID purpose ID patient ID subject ID policy 2 3 4 org ID 1 patient ID org ID subject roleXUA subject role org ID XUA Resource does not have to know where policies are kept. Client may cache policies. Processing on server can start immediately. Appropriate for highly distributed and dynamic environments.

50. 50 Use-Case: Policy on my Memory-Stick Context Domain STS Subject Domain Patient Domain (USB) Resource Domain purpose ID resource ID role activation Identity Prv. PEP / PDP request initiator resource subject role resource type STS purpose ID patient ID subject ID policy 3 4 org ID 1 patient ID org ID subject roleXUA subject role org ID XUA Bio STS sign policy Requires patient to be in place when his data is accessed.

51. 51 Attribute Pull (PIP) vs. Attribute Push PDP Requestor Resource PEP PIP PDP Requestor Resource PEP PIP Service Request without Attributes (PULL) Service Request with Attributes (PUSH)

52. 52 Use-Case: Attribute Pull, Policy Push Context Domain STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID policy activation Attribute Svc PEP / PDP request initiator resource subject role patient ID org ID resource type patient ID purpose ID patient ID policy 1 2 3 4 XUA subject ID Requires a central Attribute Service. Low functional requirements at the client.

53. 53 Use-Case: Attribute Pull, Policy Pull Context Domain STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID policy activation Attribute Svc PEP / PDP request initiator resource subject role patient ID resource type patient ID purpose ID patient ID 1 2 3 4 org ID XUA subject ID Ideal for thin clients with low bandwith (e. g. mobile phones). TelKo may act as subject domain. Server does not have to trust client.

54. 54 Use-Case: Attribute Pull, Policy Cache Context Domain STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID policy activation Attribute Svc PEP / PDP request initiator resource subject role patient ID resource type policy ID purpose ID patient ID 1 2 3 5 org ID XUA subject ID patient ID policy ID 4 Low bandwidth requirements. Matches BPPC where policy is at the resource node but client initiates policy selection.

55. 55 Use-Case: Split PEP/PDP Context Domain STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID policy activation Attribute Svc PDP request initiator resource subject role patient ID resource type patient ID subject ID 1 2 4 5 org ID PEP resource ID policy decision STS 3 Low bandwidth requirements. Server-side processing with no security overhead. Resource does not have to know attribute/policy sources. But: Fat client. Resource must trust client. One additional message

56. 56 Use-Case: Client-side PEP/PDP Context Domain STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID policy activation Attribute Svc PEP / PDP request initiator resource subject role patient ID resource type patient ID subject ID 2 1 3 org ID patient ID subject ID Resource can be based on XDS/XCA without any security extensions. But: Fat client. Resource must trust client. Additional message (metadata request).

57. 57 Use-Case: Client-side PEP/PDP with SSO STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID policy activation Attribute Svc PEP / PDP request initiator resource subject role resource type patient ID 1 2 3 org ID patient ID subject ID patient ID org ID XUAsubject role Context Domain

58. 58 Deployment and Evaluation Deployment of the single domains (and their respective building block) onto nodes subject domain in usually closely related to the context domain. But: providing it close to the resource makes attribute pull easier deployment of the patient domain depends on the use of pull/push and on implementation issues (e. g. if XDS is used for policy management) Evaluation of the various deployment opportunities with respect to principles of secure design management authorities and policies security consideration (what assumptions can be made about the nodes’ security contexts)...

59. 59 Chapter 5: Sample Adaptations of the Generic Model Regional Healthcare Network Based on IHE XDS/XUA MAC style Application Policy + DAC style consent + RBAC resource policy on client side Cross Domain Data Exchange using XCA gateways and policy push BPPC

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

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

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

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

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

65. 65 4-Domain Model (XSPA control flow) ACS STS Context Domain ACS STS Subject Domain ACS STS Patient Domain ACS STS Resource Domain patient privacy policy (consent) context attributes subject attributes resource attributes role activation consent activation Identity Prv. PEP / PDP org. security policy request initiator resource Attribute Svc. PEP / PDP 2 1 3 4 5 6 7 8 9 10 11

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

67. 67 Chapter 7: Deployment and Implementation Issues Layering Opportunities (Message Header, SOAP Header, SOAP Body) Security Token Encoding and Exchange PEP/PDP Integration Example: Safeguarding XDS transactions (incl. discussion on XCA)

68. 68 Authorization Subsystem - How to Employ? HTTP header SOAP header SOAP body WS application WS-stack e.g. JAX-WS RI/ WSIT HTTP-stack e.g. Tomcat servlet container PEP  PEPs residing in HTTP-stacks: Decoupled from application sources or binaries  Limited to coarse-grained request authorization (may subject X access the service application?)  Limited to HTTP authentication protocols  Hard to hand-over properties to application PEP  PEPs residing in WS-stacks: Decoupled from application sources or binaries  Allows fine-grained request authorization as far as authorization-relevant information is available in request Supports WS authentication protocols  Relies on WS-stack to hand-over properties to application PEP  PEPs residing in WS applications: Allows arbitrarily fine-grained request authorization (may subject X call method Y upon resource Z?)  Needs to consume authentication state from WS-stack

69. 69 Security Token Chaining (eCR Example)

70. 70 PEP/PDP Deployment (eCR Example)

71. 71 Deployment Examples: Client-Side ACS

72. 72 Implementation Example: ACS bound to Clinical IS

73. 73 Technologies for Communication Security in Web Services XML Signature Provides msg authentication W3C standard XML Encryption Provides msg encryption W3C standard SAML assertion Is a kind of OASIS standard (SAML TC) Security token Provides user authentication WSFED Is an extension to OASIS work- in-progress SOAP Message Security OASIS standard (WSS TC) Allows profiling of WS-SecurityPolicy OASIS standard (WS-SX TC) WS-Trust Defines WSs for managing OASIS standard (WS-SX TC) Defines security for STSs WS-Policy Allows publishing of W3C work- in-progress

74. 74 Appendix A: Glossary of Terms ResourceSomething of value in a network infrastructure to which rules or policy criteria are first applied before access is granted [RFC 2753] SubjectIdentified and authenticated entity (e. g. a human actor) who wants to access a resource PolicySet of rules to administer, manage, and control access to [network] resources [RFC 3060] ConditionRepresentation of the necessary state and/or prerequi- sites that define whether a policy rule’s actions should be performed [RFC 3198]

75. 75 Appendix B: Standards and Vocabularies for Attribute Names and Values XSPA Conformance Attributes ASTM E1986-98(2005): Standard Guide for Information Access Privileges to Health Information. HITSP/TP20: HITSP Access Control Transaction Package HL7: RBAC Consent related vocabulary including Confidentiality Codes. HL7: (RBAC) Healthcare Permission Catalog. RFC 2798 (as used by IHE PWP)

76. 76 Sorted out

77. 77 Medical Data Access within Organizations (2 PEPs!) Deployment of PEP/PDPs depends on the level of Trust! (provider must in any case verify, that the consuming organization is authorized. But does he even have to verify that the role of the accessory matches the patient’s consent or an appropriate organization of work?)

78. 78 Generic Model (XSPA + externalized IdP) ACS STS Context Domain ACS STS Subject Domain ACS STS Resource Domain context attributes subject attributes resource attributes role activation Identity Prv. PEP / PDP org. security policy request initiator resource Attribute Svc. PEP / PDP policy activation security policy privacy policy policy activation circle of trust patient attributes enter context consent

79. 79 Generic Model (XSPA + externalized IdP) ACS STS Context Domain ACS STS Subject Domain ACS STS Resource Domain context attributes subject attributes resource attributes role activation Identity Prv. PEP / PDP org. security policy request initiator resource Attribute Svc. PEP / PDP policy activation security policy privacy policy policy activation circle of trust patient attributes enter context XUA XDS XUA XCA PIX/PDQ consent PIX/PDQ PWP

80. 80 Use-Cases: Implementation by (specific) Policies CIS Clinic B IT Clinic A Patient Privacy Policy : Clinic A as source diabetologist working in Clinic B currently treating me diabetic-related data XDS XCA Resource Security Policy : representative of Clinic A diabetic-related data Resource Security Policy: role diabetologist working in Clinic A involved in treatment functional/organisational division pre- negotiated trust

81. 81 Use-Cases: Alignment to Domain Model Resource Security Policy : representative of Clinic A diabetic-related data Resource Security Policy: role diabetologist involved in treatment CIS Clinic A IT Dr. Smith pre- negotiated trust Consent patient domain context domain resource domain application domain subject domain