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

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

55

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

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

doc. type

policy activation

patient ID

purp. of use

PoC type

representspolicy-ID *

attribute value *

policy decision

resource provider

attr. value *

evaluates

acceptor deny

country of care

HCP roles

Patient Privacy Policy

date of access

XUA++

TRC

WSE andoperation

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