IHE ITI Profile Proposal XCA Query and Retrieve Fraunhofer ISST and Tiani Spirit on behalf of epSOS 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 states own discretion

3 epSOS Original Members Austria Czech Republic Denmark France Germany Greece Italy Slovakia Spain Sweden The Netherlands United Kingdom 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 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 NCPs 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

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 patients 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 patients affiliation MUST verify patients consent and enforce patient privacy policy (if defined)

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

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