IHE ITI Profile Development Health 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 XCAepSOS ePrescription Service Content agnosticConsumer can only process CDA coded ePrescriptions acc. to epSOS schema Browsing metaphorTargeted search for ePrescriptions (there is no assumption of a full EHR) Search by metadataAll information needed is implied or within the document (but may be content-specific for some operations and therefore not covered by metadata) Perimeter protectionEnforcement of domain security policy and patient privacy policy (XACML/BPPC) Semantic neutralConsumer wants “dispensable prescriptions”; only provider can assess whether a prescription is dispensable (shared semantics)

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

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 is “urn:ihe:iti:2010:CrossGatewayQueryRetrieve” –Inside 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 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 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 Metadata (ebRIM names)Health Data Service usage convention statusimplied mimeTypeimplied NameNo processable, otherwise implied. creationTimeEncoded within the document hashCan usually be omitted (integrity protection during transmission) languageCodeEncoded within the document repositoryUniqueIdNot needed in Health Data Provider scnearios serviceStartTime, serviceEndTime Encoded within the document sizeImplied (document is available) sourcePatientIdEncoded within the document sourcePatientInfoEncoded within the document classCodeImplied eventCodeListRelevant information is within the document authorEncoded within the document confidentialityCodeNot needed if policy is enforced at the provider formatCodeImplied or encoded within the document healthcareFacilityTypeCodeUsually not needed (it’s just a service...) otherwise within the document practiceSettingCodeUsually not needed (it’s just a service...) otherwise within the document XDSDocumentEntry.uniqueIdNot needed XDSDocumentEntry.PatientIdEncoded within the document

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)