IHE ITI Profile Development Health Date Service Access (aka XCA Query and Retrieve)

1. IHE ITI Profile DevelopmentHealth Date Service Access(aka XCA Query and Retrieve) Fraunhofer ISST epSOS Consortium epSOS Industry Team

2. Background • In the European epSOS project it was decided to use IHE XCA for cross-border data sharing • During epSOS 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

3. 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::GetRecentDiagnosisData( pid ): • CrossGatewayQuery( patient-ID, pacemaker-data, CDA)  17 • CrossGatewayRetrieve( 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)?

4. 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 epSOS? • Methodology: • Assess the “real” problem • Discover typical examples • Analyze the symptoms (is the list complete?) • Assess whether the solution proposed by epSOS covers the problem and “heals” the symptoms

5. 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 epSOS 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 (“getMostRecentCarePlan”) • discrete behavior (transactional semantics)

6. Example 1

7. Example 2

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

9. 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, content-agnostic 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 eHealth solutions (SOA, CDA, ...) often follow the Health Data Service paradigm by focusing on specific data and building upon a shared domain/information model

10. Actors and Transactions • 2 Actors • Health Data Service Consumer • Health Data Service Provider • 1 Transaction • listData( patientID, infoModelReference, specificQueryParams ) • 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

11. Standards Options • ebRS, ebRIM (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/HL7 RLUS (+ HL7 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 epSOS for both standards

12. XCA XGateway-Query Extension

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

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

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

16. Open Issues • including a reference to the business (domain/information) model with the query • may be expressed through the class code (or combination of classCode and typeCode) • content-model specific query arguments • exisiting slots should correspond to CDA header schema • syntactically it is easy to add 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

17. Metadata in result set

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