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. Challenge: Access Control • The patient‘s privacy policy MUST be enforced twice (query / retrieve) • retrieve only takes a doc-ID as an argument. How to securely obtain the patient ID for retrieving the privacy policy?

7. Challenge: Simplicity • epSOS Patient Service: Obtain a patient‘s PatientSummary (only one instance available) • XCA query provides the PS ID and then XCA retrieves the document. This could be one transaction. • epSOS ePrescription Service: Obtain a patient‘s pending ePrescriptions. • Always all ePs are retrieved because there is no useful selection criterion for eP in XDS metadata. Again: One transaction would do well....

8. Challenge: epSOS SOA • epSOS defines logical services (Patient Service, eP service, etc.) • the operations of these services are mapped onto IHE transactions • use of XCA for data access: • one logical operation must be mapped onto 2 transactions (no user interaction in between) • No discrete behaviour (partial failures etc.) • processing logic on the client side that could as well be on the server

9. XCA XGateway-Query Extension

10. XCA Extension • The query request message XML is syntactically identical to that of IHE Cross Community Query request with two extensions:. • The <ws:Action/> is “urn:ihe:iti:2010:CrossGatewayQueryRetrieve” • Inside the @AdhocQueryRequest/ResponseOption, the returnType “LeafClassWithRepositoryItem” MUST be used. This value, specified by ebRS version 3.0, indicates that both the full metadata plus the document contents are to be returned.

11. XCA Extension • The query response includes metadata and documents <rim:ExtrinsicObject> <!-- lots of stuff missing here --> <xdsext:Document> ... <!-- base64 coded document --> </xdsext:Document> </rim:ExtrinsicObject>.... - wire-format as for retrieve response message (MTOM/XOP)

12. Benefits • Approach does work for each registry and repository implementation that works with current XCA • national infrastructure not affected • Simplification of policy enforcement • policy is enforced only once • all attributes for policy decision are available • 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) • Further Benefits (for epSOS): • Deferred document creation is not visible outside the NCP -> common behaviour and low complexity • Discrete data delivery (no intra-epSOS partial failures)

13. Status and Effort • Effort is very low because the respective spec has already been written in the epSOS project • IHE was heavily involved (Karen, Bill, Charles) • Work to do is the editorial interation with the existing XCA profile