Ihe iti profile proposal xca query and retrieve
1 / 15

IHE ITI Profile Proposal XCA Query and Retrieve - PowerPoint PPT Presentation

  • Uploaded on

IHE ITI Profile Proposal XCA Query and Retrieve. Fraunhofer ISST and Tiani Spirit on behalf of epSOS Consortium and epSOS Industry Team. epSOS: Objective. cross-border exchange of health data within Europe national infrastructures MUST remain as-is B2B-style cross-gateway data exchange (NCP)

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'IHE ITI Profile Proposal XCA Query and Retrieve' - rossa

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Ihe iti profile proposal xca query and retrieve

IHE ITI Profile ProposalXCA Query and Retrieve

Fraunhofer ISST and Tiani Spirit on behalf ofepSOS Consortium and epSOS Industry Team

Epsos objective
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


Original Members


Czech Republic









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

Epsos 101
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


Problem area 1 access control
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)

Patient privacy policy

policy activation

Patient Privacy Policy


resource provider

PoC type

HCP roles


acceptor deny

purp. of use

attr. value *

attribute value *

patient ID

policy decision

WSE andoperation

doc. type

country of care

date of access



policy-ID *


Problem area 1 access control1
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

Problem area 2 deferred documents
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?

Option 1 xds registry as pip
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)

Option 1 drawbacks
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

Option 1 2 query and retrieve
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

Option 1 2 benefits
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)

Epsos further processing
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