IHE ITI Profile Development Health Date Service Access

IHE ITI Profile Development Health Date Service Access (aka XCA Query and Retrieve) Fraunhofer ISST ep. SOS Consortium ep. SOS Industry Team

Background • In the European ep. SOS project it was decided to use IHE XCA for cross-border data sharing • During ep. SOS Service design and implementation several problems were discovered – policy enforcement and consent verification (missing attributes in the retrieve operation) – assessment of audit trails (what documents of patient X were accessed by whom? ) – stateless responding gateway (esp. in case of dynamic/deferred document generation) • Similar problems were discovered during design of the German PHR services and are reported by industry 2

Another Use Case • A vendor of heart pacemakers allows a patient to run a diagnoses of the device. The diagnoses data is transmitted to a central server at the vendor. Authorized physicians may access this data. • The vendor implements a service for physicians to access their patients diagnosis data. The idea is to use XCA/XDS for the implementation of Pacemaker: : Get. Recent. Diagnosis. Data( pid ): – Cross. Gateway. Query( patient-ID, pacemaker-data, CDA) 17 – Cross. Gateway. Retrieve( 17 ) CDA-coded diagnosis data • Problems – how to enforce a patient policy on retrieve( 17 )? – why 2 transactions (incl. transmission, parsing, database access, security and audit overhead)? – when to render CDA from the diagnosis data while keeping the service stateless and IDs consistent? – what if new diagnosis data is written to the database between query and retrieve (implied semantics broken)? 3

Profile Development: Methodology • Assumption is that these observations are just the symptoms for a deeper problem: • Why does XCA fit for sharing data between healthcare enterprises and why does it cause problems in scenarios like ep. SOS? • Methodology: – Assess the “real” problem – Discover typical examples – Analyze the symptoms (is the list complete? ) – Assess whether the solution proposed by ep. SOS covers the problem and “heals” the symptoms 4

Problem Assessment • XCA works fine for HIN connectivity (EHR sharing) – existing data of any kind content agnostic – provider-specific EHR compilation browsing metaphor – unstructured documents need for metadata – participants are trusted perimeter protection – access is semantic-neutral no need to query on data semantics (“most recent” etc. ) • SOA Entity Services (Health Data Services) like in ep. SOS and other HIN-by-Design scenarios – known data types and formats (fixed data model) – bound to business/domain model – structured data (CDA) – trust brokerage; service discovery (health data locator) – fine grained, policy based access control – operations impose semantics (“get. Most. Recent. Care. Plan”) – discrete behavior (transactional semantics) 5

Example 1 XCA ep. SOS e. Prescription Service Content agnostic Consumer can only process CDA coded e. Prescriptions acc. to ep. SOS schema Browsing metaphor Targeted search for e. Prescriptions (there is no assumption of a full EHR) Search by metadata All information needed is implied or within the document (but may be content-specific for some operations and therefore not covered by metadata) Perimeter protection Enforcement of domain security policy and patient privacy policy (XACML/BPPC) Semantic neutral Consumer wants “dispensable prescriptions”; only provider can assess whether a prescription is dispensable (shared semantics) 6

Example 2 XCA Heart Pacemaker Diagnosis Service Content agnostic Consumer expects diagnosis data in an agreed format and encoding Browsing metaphor Targeted search for most recent diagnosis data (again: no EHR, just very specific data) Search by metadata All information needed is implied by the service and the operation Perimeter protection Enforcement of domain security policy and patient privacy policy (XACML/BPPC) Semantic neutral Consumer wants “most recent data”; can be assessed at both sides if list of matching data objects is known (fits with XCA) 7

Conclusion 1 • XCA is mainly addressing cross-community scenarios for sharing data between independent patient record managing entities. • XCA characteristics do not match scenarios well where partners have agreed on the types, formats, business object models and semantics of specific data sharing services (SOA “entity services” acc. to IHE SOA White Paper; Health Data Services in common (European) terminology). 8

Conclusion 2 • XCA can as well be used to implement health data services, but – makes security very complex – imposes overhead and complexity on the business level (browsing metaphor) – imposes restrictions on the agreed semantics as metadata is fixed and content agnostic; does not allow to search within structured documents of known format • From a technical perspective the content-aware data access to health data services is much simpler than a very flexible, contentagnostic data sharing setting: – the requirements have an overlap with QED, but this has other problems (see XCA supplement) – many of the XCA features are just overhead and cause complexity benefit of standard solution may get lost! • newly designed e. Health solutions (SOA, CDA, . . . ) often follow the Health Data Service paradigm by focusing on specific data and building upon a shared domain/information model 9

Actors and Transactions • 2 Actors – Health Data Service Consumer – Health Data Service Provider • 1 Transaction – list. Data( patient. ID, info. Model. Reference, specific. Query. Params ) • Features – perfectly matches SOA principles and entity service requirements – single transaction simplifies security and handling of dynamic/deferred documents in SOA – content-awareness allows for binding the service to a business/domain/information model 10

Standards Options • eb. RS, eb. RIM (as in XCA/XDR/XDM/XDS) – Advantages • very low implementation effort for vendors who already support XCA • XDR comes for free as a provide-operation – Disadvantages • content agnostic (content awareness must be added) • OMG/HL 7 RLUS (+ HL 7 CDA query profile) – Advantages • perfectly matches all requirements through the notion of semantic signifiers – Disadvantages • new standard not in use for IHE profiles (high effort) • conflicts with existing profiles (XCA, XDR) • Draft Specs are available from ep. SOS for both standards 11

XCA XGateway-Query Extension 12

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: Cross. Gateway. Query. Retrieve” – Inside the @Adhoc. Query. Request/Response. Option, the return. Type “Leaf. Class. With. Repository. Item” MUST be used. This value, specified by eb. RS version 3. 0, indicates that both the full metadata plus the document contents are to be returned. 13

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

Benefits • Approach does work for each registry and repository implementation that works with current XCA – existing infrastructure not affected • Simplification of security means – policy is enforced only once – all attributes for policy decision are available – only one audit trail entry with all information 15

Open Issues • including a reference to the business (domain/information) model with the query – may be expressed through the class code (or combination of class. Code and type. Code) • content-model specific query arguments – exisiting slots should correspond to CDA header schema – syntactically it is easy to additional <rim: slot> entries – specific slot names and parameter types could be defined together with the respective CDA implementation guideline or domain/information model – vendors MAY query into documents or extract metadata for querying --> implementation dependend and invisible to the consumer • minimization of metadata overhead – refer to Minimum Metadata Profile or make fully optional 16

Health Data Service usage convention Metadata in result set implied Metadata (eb. RIM names) status mime. Type implied Name No processable, otherwise implied. creation. Time Encoded within the document hash Can usually be omitted (integrity protection during transmission) language. Code Encoded within the document repository. Unique. Id Not needed in Health Data Provider scnearios service. Start. Time, service. End. Time Encoded within the document size Implied (document is available) source. Patient. Id Encoded within the document source. Patient. Info Encoded within the document class. Code Implied event. Code. List Relevant information is within the document author Encoded within the document confidentiality. Code Not needed if policy is enforced at the provider format. Code Implied or encoded within the document healthcare. Facility. Type. Code Usually not needed (it’s just a service. . . ) otherwise within the document practice. Setting. Code Usually not needed (it’s just a service. . . ) otherwise within the document XDSDocument. Entry. unique. Id Not needed XDSDocument. Entry. Patient. Id Encoded within the document 17

Next Steps • Agreement on a storyline for Part 1 and use cases (next TCon on Jan. 31 st) • Agreement on the standard (next TCon) • Draft of Part 1 and 2 for the f 2 f in Toronto • Discussion on open issues (Toronto) 18