Ihe iti profile proposal xca query and retrieve
This presentation is the property of its rightful owner.
Sponsored Links
1 / 15

IHE ITI Profile Proposal XCA Query and Retrieve PowerPoint PPT Presentation


  • 45 Views
  • Uploaded on
  • Presentation posted in: General

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)

Download Presentation

IHE ITI Profile Proposal XCA Query and Retrieve

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


Epsos

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


Epsos ncps

epSOS NCPs


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

5


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

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


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


Xca xgateway query extension

XCA XGateway-Query Extension


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


  • Login