Architecture

1. Architecture Sören Bittins // FhG FOKUS WP-L 3.4 and WP-L 3.A, epSOS-I SEG-L

2. Agenda • Introducing the epSOS architecture • Principles • Scope • Layering • Core processes • National Contact Point (NCP) as a multi-dimension communication facilitator • epSOS services and profiling • Overview of epSOS Services • Profiling of epSOS services • Usage of IHE Profiles in epSOS • Closing • Flowing Back to the Community • Open Issues

3. PrinciplesofepSOSarchitecture • Non-Intrusive concerning existing national e-Health infrastructures (overlay messaging + integrative security) • Decoupling of Business and Security Architecture: • Strong separation through layering of architecture concerns • Brokered trust paradigm, strong security demands by countries • Service Orientation and alignment to IHE Profiles: • Architecture abstraction through layering, profile focus • High flexibility concerning component orchestration: • Self-sustained, interchangeable components • Interceptor model for introduction of extended components

4. ScopeofepSOSarchitecture

5. LayeringofepSOSarchitecture Medical Treatment and Administration (Business Processes) Document Sharing (Business to Business Architecture) Security and Privacy (Security Architecture and Support Services) Connectivity (epSOS Messaging Architecture)

6. National Contact Point (NCP) as a multi-dimension communication facilitator epSOS is founded on a partial brokered trust paradigm: each MS only directly trusts its own NCP and own human actors each disclosure/access control decision is always made in country-A double-role mapping with foreign IdA and TRC as “Attribute Provider” the NCP’s act in several roles: injection point of a harmonising layer of commonality legal umbrella for each Member State, delimiting its boundaries trust anchors and terminators: as brokered “mutual” AuthN providers, trust assurances, and audit trail technical “glue” for common/national interfaces, protocols, and formats as “semantic bridges” that perform schema and code translation 6

7. Overview of epSOS Services • epSOS Patient Summary: • communication of a CDA-coded PS with original rendering (PDF) • two-step implied pivot transcoding/translation for coded part • one document principle in a query+retrieve communication fashion • epSOS ePrescription: • communication of an atomic ePrescription with original rendering • same translation/transcoding principle applies • epSOS eDispensation: • communication of dispensed medication, voluntary processing • epSOS Consent Service: • communication of a patient consent as processing authorisation • template-based exchange, CoA activation  epSOS Consent WF

8. Core processes of epSOS COUNTRY B COUNTRY A Local IT at a Hospital, Pharmacy, etc. National Healthcare Infrastructure Gateway B GatewayA HCP authentication Patient identification Consent & HCP authorization Service entry point discovery Policy enforcement Policy enforcement Medical data query and retrieval Policy enforcement Policy enforcement Medical data update notification

9. Profiling of epSOS services • Common services within epSOS were profiled for: • interoperability assurances across systems and countries • „testability“, substitutes, and certification streamlining • exploiting already existing InterOp test-beds and activities • benefitting from off-the-shelf plug-in components • Candidates for immediate application within epSOS: • XCPD, XDR, ATNA, BPPC, CDA, XACML, XSPA, TSL, etc. • reality check for approaches: NSL/TSL, template consent • Candidates with adaption needs: • XCA, XUA, BPPC, community agreements, trust elevation • epSOS tried hard to reuse, not to replace or deprecate • however, epSOS was facing challenges (RLUS, Security) • motivating adaptions by innovation, and new profiles

10. Usageof IHE Profiles in epSOS

11. Flowing Back to the Community • Despite attempting to reuse, certain significant aspects were not always addressed by existing profiles and provisions • IHE Cross Community Fetch (XCF): • stateless transaction allowing for immediate document return • stateless and fully aware of in-band data manipulation (transcode) • simpler to implement while covering „constrained“ use cases • extremely performing when number/extend of returns are known • enables zero-disclosure NCP‘s with no data protection implications • Strict Communities and Domain Principle: • not applicable in x-border transfer of medical data as in x-enterprise • introduction of flexible and individual community agreements

12. Open Issues • Profile Maintenance and Composition Deprecation: • mandatory Updates of Profile, Technical Framework, etc. • implicit disqualification by deprecation (SHA-1, TLS 1.0, XACMLv3) • backwards compatibility with a potential for technology lock-in • in process: “pre-selection” of profiles for common tasks as way out • Scope, Audience, Positioning (Market), Coordination: • mismatch between extension, adaption, and scoping of such • questionable positioning constraints with implications (EU Extension) • missing steering entities „in between“ for realigning diverging tracks • challenging consolidation of especially legal & regulatory issues: • balancing: interface vs. functional spec. for compliance (DPA, PatSafety, etc.) • incoherent assumptions “single harmonised application domain”

13. Thank You! Stay tuned for a detailed analysis of the epSOS profiling and standards exploitation

14. Flowing Back: Profiling Details Massimiliano Masi // Tiani ``Spirit‘‘ GmbH epSOS SEG-I, WP3.7

15. Agenda • Key Insights • Profiles and Standards: ATNA • Profiles and Standards: XUA • About Patient Consent • Profiles and Standards: XCF • Profiles and Standards: Emergency Access

16. Key Insights • epSOS selected and influenced international standards (from IHE, OASIS, and HL7) • With the successful IHE connect-a-thons in Bratislava and Pisa, epSOS proved being implementable and is now operational for general public • We are working together with a new born OASIS TC in order to find feasible, real-world, and secure solutions to the 112 use case • We provided the e-Health international community with a new profile, the Cross Community Fetch (XCF) • We are reality-checking several European engagements for the fitness of use in the e-Health “wild”: NSL/TSL, eSignature, x-border recognition • Results are already being reused and epSOS is extensively extended by national engagements: portals, system integration, security extension

17. Profiles and Standards: ATNA • ATNA is the core of the IHE security model: • PKI has to be in place: each node owns a X.509 Certificate • NCP2NCP communications are mutually authenticated TLS-based transactions • Rfc-3881 compliant audit trails for each transaction including handling medical data / configuration change / security alerts • ATNA is adjusted by epSOS: • ATNA + VPN provide the epSOS channel authentication & encryption • Provided integrity for audit trails (long term XML Digital Signature) • Additional audit trails for security conditions (e.g., treatment relationship)

18. Profiles and Standards: XUA • Cross Enterprise User Assertion (XUA): • Provides a mechanism to transfer principal authentication by means of WS-Security • A SAMLv2.0 authentication assertion to represent principal identity • Specific value for principal’s identity in audit trail • A new IHE profile is being evaluated (XUA++) • XUA++ development was influenced by epSOS-CCD experience: • Identity attributes with OASIS XSPA (subject-id, role, permissions) • PurposeOfUse of the assertion • XUA++ was adjusted by epSOS: • Added additional attributes (healthcare facility type code, clinical specialty)

19. About Patient Consent • The workflow Patient Consent has a drawback • What will happen if a country needs to enforce a document retrieve? Registry • Enforcement made on XDS metadata • Repository has no metadata, only content • For each document, the PDP (acting as a PIP) needs to perform an additional XDS AdHocQuery to Registry PDP Repository

20. Profiles and Standards: XCF • This is a key concept for Cross Community Fetch: • XCF (Bittins, Masi, 2011), a new IHE standard driven by epSOS experience • Better implementation of access control • Avoids unnecessary XCA messages (the resources are known in advance) • Bindings for XDS Consumers, XDS Sources, XCA Initiating Gateways, XCA Responding Gateways, XDS Registries, and XDS Repositories Responding Gateway Initiating Gateway Cross Gateway Fetch [ITI-63]

21. Profiles and Standards: Emergency Access • In 2011, OASIS started the Trust Elevation TC: • TC’s goal is to define a set of methods or standardized protocols that service providers may use to elevate the trust in an electronic identity presented to them for authentication purposes • Based on the usual categories: Who you are, What you Know, What you have, the TC recognized a fourth category, the context • We identified the context as the actual healthcare treatment • Within the scope of SAML assertions, elevate trust means to increase the Level of Assurance (LoA) with an identity • the epSOS CCD partner responsible for Implementation, epSOS backbone, and Integration (Tiani) is actively and directly involved in this TC for consolidating the regulatory complex use case for epSOS

22. Thank You!

23. Annex

24. End-2-End & Brokered Security

25. Profiles and Standards / XUA • We use two SAML assertions: • Identity Assertion (IdA), which proves the identity of the HCP • Treatment Relationship Confirmation (TRC), which proves the relationship with the patient • Subject confirmation method: sender-vouches • Renders the brokered trust • Deviates from XUA (which uses the Bearer)

26. epSOS Identity Provider NCP-B NCP-A epSOS Backbone IdA PEP WS-Security Token NI Local Authentication HIS TRC STS IdA+ATNA Attribute Service

27. Patient Consent • Informed consent: two use cases: • Consent given in Country A, discriminate access from all Countries B • Newly consent given in Country B, discriminate access to country A • The implementation uses IHE BPPC: • When submitting from B to A, IHE XDR is used • Two policies: Opt-In, Opt-Out • BPPC CDA document contains a reference to the given consent • the communicated consent is a template that enables the CoA to act according to their own legislation without introducing regulatory mismatch • The consent is rendered using a XACMLv2 policy: • Obtains attributes from the SAML IdA, TRC • Contains Rules for each epSOS-defined role, purpose of use, action, permission • Can be stored in a XACML Policy Repository using OASIS WS-Trust / SAMLv2 Profile for XACMLv2

28. Consent Enforcement NCP-B NCP-A 5. Create XACML Request with attributes from IdA and TRC STS IdA 4. Validate assertions 1. Authenticate 3. epSOS transaction with IdA and TRC 3: documents PEP TRC PDP 2. Obtain TRC 7. Obtain Policy 8. For each documentenforce the policy Policy / XDS Repository 6. Obtain decision

29. Emergency Access • We submitted the epSOS 112 use case to the TC: • The contribution is accepted in D1.0 draft-1 • The key concept is: • 112 access is represented as the PurposeOfUse attribute in the IdA (LoA-1, or LoA-2) and TRC (TREATMENT or EMERGENCY). • In order to change the purpose of use of the assertion, HCPs must elevate the trust, i.e., the reliability that the IDP-B has with the identity of the HCP (LoA-3 or LoA-4, as per NIST semantics) • The newly issued IdA and TRC will travel to NCP-A • At NCP-A, a special EMERGENCY XACML policy (defined by national means) is activated, due to the elevated LoA • Access is either granted or denied • Experience comes from the works and discussions within the WP3.7 • Each PN is able to enforce the local regulations for 112 access