IHE ITI Profile Proposal XCA Query and Retrieve

1. IHE ITI Profile ProposalXCA Query and Retrieve Fraunhofer ISST and Tiani Spirit on behalf ofepSOS Consortium and epSOS Industry Team

2. epSOS: Objective • cross-border exchange of health data within Europe • national infrastructures MUST remain as-is • B2B-style cross-gateway data exchange (NCP) • retrieval of ePrescriptions and provisioning of eDispensation data • retrieval of medical summary • Brokered Trust (NI <-> NCP <-> NCP <-> NI) • privacy and data protection • patient MUST give consent to the use of epSOS (patient MAY refine access rules) • data access MUST be within the context of a medical treatment • national security policies MAY apply at a member state‘s own discretion

3. Original Members Austria Czech Republic Denmark France Germany Greece Italy Slovakia Spain Sweden The Netherlands United Kingdom epSOS New Members (2011) • Belgium • Estonia • Finland • Hungary • Malta • Norway • Poland • Portugal • Slovenia • Switzerland • Turkey Industry Team • Accenture • Agfa Healthcare • Cisco • CompuGROUP • GE Healthcare • ICW • Intel • Microsoft • Oracle • Tiani Spirit • T-Systems • 3M • and others...

4. epSOS NCPs

5. epSOS 101 epSOS is founded on a partial brokered trust paradigm: the active actors are not necessarily known or directly trusted each MS only directly trusts its own NCP and own human actors each and every access control decision is always made in country-A ACS: data consumer always country-B, data provider always country-A double-role mapping with foreign IdA and TRC as “Attribute Provider” the NCP’s act in several roles: legal umbrella for each Member State, delimiting its boundaries trust anchors (NI-B ↔ NCP-B (↔ epSOS ↔) NCP-A ↔NI-A) trust terminators at the national interface (NCP-B to NCP-A) as brokered “mutual” authentication providers and trust assurances as “semantic bridges” that perform schema and code translation  NPC = multi-dimension communication facilitator 5

6. Problem Area #1: Access Control • Country of care (country B) MUST proof the authenticity of the HCP • HCP MUST explicitly confirm the existence of a treatment relationship • Country of patient‘s affiliation (country A) MUST either enforce • attribute-based access control on the requested service acc. to its national security policy • permissions granted to NCP in the country of care (needs-to-know principle) • Country of patient‘s affiliation MUST verify patient‘s consent and enforce patient privacy policy (if defined)

7. policy activation Patient Privacy Policy XUA++ resource provider PoC type HCP roles TRC acceptor deny purp. of use attr. value * attribute value * patient ID policy decision WSE andoperation doc. type country of care date of access evaluates represents policy-ID * policy

8. Problem Area #1: Access Control • XGateway-Query( „PID:1234“, „Patient Summary“) -> docID:17 • XGateway-Retrieve( 17 ) -> Patient Summary document • Problem #1.1: How to enforce a policy only with a doc-id? • epSOS XCA implementation detail #1: • all requests are piggybacked with XUA++ and TRC assertion • --> all attributes are at hand for policy decisions • Problem #1.2: How to prevent bypassing access control? • XGateway-Retrieve( 19 ) -> private patient data of another patient • --> NCP cannot verify the authenticity of PID and docType for an XCA XGateway-Retrieve() request

9. Problem Area #2: Deferred Documents • epSOS NCPs provide pivot mapping and encoding of original patient data • NCP requests original data from national infrastructure and creates requested encoding on demand • many countries use databases for storing ePrescriptions: • original data can be handled as described in the Delayed Document Assembly Supplement • epSOS pivot data is a deferred document but unknown to the repository and registry (must solely be handled at the NCP gateway!) • Problem #2.1: How are document IDs handled and kept unique? • Problem #2.2: How do NCP and registry/repository interact?

10. Option #1: XDS Registry as PIP • Processing of XCA XGateway-Query • XDS registers deferred document for the requested document format (original as parent) • Processing of XGateway-Retrieve: • Query the national document registry for the metadata of a document that is identified by its ID • Match patient-ID and resource attributes • Enforce security policies • Perform retrieve() of parent document • create requested format acc. to type as given in metadata • update document and metadata at XDS level • Required Extension: • XDS PIP Interface (metadata query by doc-ID)

11. Option #1: Drawbacks • Approach requires extension to the national registry interface • Approach does not work if a country uses detached pseudonyms as PIDs for its registry • Each metadata is queried twice (once with the XGateway-Query and once during XGateway-Retrieve) • e.g. Spanish ePrescriptions are deferred AND dynamic -> data consistency issues

12. Option #1.2: Query and Retrieve • In order to ensure the authenticity of the patient ID and resource attributes • Perform XGateway-Query and XGateway-Retrieve as a single Operation • Processing of XGateway-QueryAndRetrieve: • Query the national document registry for the metadata and IDs of the requested documents • Assess security policies on attributes • Perform retrieve() in case of policy accept • create deferred documents and perform provideAndRegister • Respond with metadata and documents • Required Extension: • XCA XGateway-Query with returned documents

13. XCA XGateway-Query Extension

14. Option #1.2: Benefits • Approach does work for each registry and repository implementation that works with current XCA • national infrastructure not affected • Deferred document creation is not visible outside the NCP -> common behaviour and low complexity • Discrete data delivery (no intra-epSOS partial failures) • deferred and dynamic documents can be handled • Further Benefits: • Optimization for all scenarios where only a single document is requested (e.g. patient summary) • Optimization for all scenarios where a document selection based on XDS metadata makes no sense (e.g. ePrescription)

15. epSOS Further Processing • Option #1 as a quick solution • for problem #1: PIP interface to XDS • for problem #2: XDS registers all 3 encodings and NCP (ab)uses PIP interface to query for the target format; no write-back of NCP-generated documents to prevent inconsistencies • Industry refuses to implement option #2 unless it is an IHE XCA profile adaption (even though this is a common BPPC performance measure....) • Alternative solution based on OMG RLUS has already been assessed and specified