IHE ITI Profile Development Cross-Community Simple Query

1. IHE ITI Profile DevelopmentCross-Community Simple Query Fraunhofer ISST TIANI Spirit

2. Current Status • IHE ITI recommendation (F2F Toronto) • objective is simplicity; therefore we should keep the transaction as simple as possible • Proposal: • simple SOAP message • query against known XML schema (requestor and responder share data of an agreed schema)

3. Simple Query documentrequestor documentprovider XCSQ Request XCSQ Response 3

4. XCSQ grouped with XDS documentrequestor documentprovider DocumentConsumer Document Registry XCSQ Request Document Repository documents XCSQ Response

5. Option 1: AttrbuteMatch request := [typeID] [templateID] attrExpr+ [sortExpr] typeID := HL7 Instance Identifier templateID := HL7 Instance Identifier attrExpr := attrName op attrValue attrName := string attrValue := string op := XPath valueComp operator sortExpr := attrName [order] [count] [index] order := ascending | descending count, index := integer

6. Example Request Message <soapenv:Body> <ihesq:SimpleQueryRequest> <hl7v3:typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/> <ihesq:FilterByAttribute> <ihesq:AttrExpr attrName=“patientID” op=“eq”> 423998274</ihesq:AttrExpr> <ihesq:AttrExpr attrName=“classCode” op=“eq”> 57829-4 </ihesq:AttrExpr> <ihesq:AttrExpr attrName=“formatCode” op=“eq”> urn:epSOS:ps:2010 </ihesq:AttrExpr> </ihesq:FilterByAttribute> <ihesq:resultSet maxResults = “1” order=“descending” attrName=“creationTime” /> </ihesq:SimpleQueryRequest> </soapenv:Body>

7. Option 1: Pros and Cons • Pros • easy to implement • can be mapped onto metadata and documents (no assumptions made) • Cons • requires a fixed set of attribute names (that should be a subset of XDS metadata)

8. Option 2: XPath Query request := typeID [templateID] xpathLogicalExpr [sortExpr] typeID := HL7 Instance Identifier templateID := HL7 Instance Identifier xpathLogicalExpr := see XPath 2.0 syntax sortExpr := xpathPathExpr [order] [count] [index] xpathPathExpr := see XPath 2.0 syntax order := ascending | descending count, index := integer

9. Example Request (epSOS) <soapenv:Body> <ihesq:XmlQueryRequest> <hl7v3:typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/> <ihesq:FilterByXPath> (//ClinicalDocument[@classCode=‘57829-4’ and @formatCode=‘urn:epSOS:ps:2010’ and recordTarget/patientRole/ patient/@id=‘123223432424’]) </ihesq:FilterByXPath> <ihesq:ResultSet maxResults = “1”> <ihesq:Sort order=“descending”> //ClinicalDocument/effectiveTime </ihesq:Sort> <ihesq:ResultSet /> </ihesq:XmlQueryRequest> </soapenv:Body> 9

10. Example Request (Patient Device) <soapenv:Body> <ihesq:XmlQueryRequest> <hl7v3:typeId root=“...." extension=“GLUCOMETER"/> <!-- read all low glucose values of a given patient --> <ihesq:FilterByXPath> //Set[@pid=“12342”]/Entry[@value<‘50’ and @date>”20110110”] </ihesq:FilterByXPath> <ihesq:ResultSet> <ihesq:Sort order=“descending”> //Set/Entry/@date </ihesq:Sort> <ihesq:ResultSet /> </ihesq:XmlQueryRequest> </soapenv:Body> 10

11. Example Request (ebRIM/XDS) <soapenv:Body> <ihesq:XmlQueryRequest> <hl7v3:typeId root=“..." extension=“EBRIM"/> <ihesq:FilterByXPath> (//rimext:ExtrinsicObject[@mimeType=‘text/xml’ and rim:Classification[@classificationScheme=‘...’ and @nodeRepresentation="34133-9„] and rim:Classification[@classificationScheme=‘...’ and @nodeRepresentation=„12345„] ]) </ihesq:FilterByXPath> <ihesq:ResultSet> <ihesq:Sort order=“descending” startIndex=“10” maxResults=“10”> //ExtrinsicObject/Slot[@name=“creationTime”]/ValueList/Value </ihesq:Sort> <ihesq:ResultSet /> </ihesq:XmlQueryRequest> </soapenv:Body> 11

12. Option 2: Pros and Cons • Pros • easy to implement (XPath processor) • very flexible • usable to filter data from (patient) devices: • “all glucose values < 50 for the last 4 weeks” • Cons • can only be implemented on top of (unencrypted) documents • performance may be a problem

13. Option 3: Simplified XPath Syntax • Simplification of Option 2: • within logical expressions only XPath PathExpressions and constant values are allowed • 1:1 mapping to metadata attributes can be done • no restriction on attributes • example • //ClinicalDocument/recordTarget/patientRole/patient/id  $XDSDocumentEntryPatientID • //ClinicalDocument/@formatCode  $XDSDocumentEntryFormatCode

14. Option 3: Pros and Cons • Pros • easy to implement • can be mapped onto metadata and documents (no assumptions made) • very flexible • allows for performance optimization • Cons • ??

15. Example Response Message <soapenv:Body> <ihesq:SimpleQueryResponse> <ihesq:ResultDocument> <hl7v3:ClinicalDocument> ... </hl7v3:ClinicalDocument> </ihesq:ResultDocument> <ihesq:ResultDocument> ... </ihesq:ResultDocument> <ihesq:Status code=“0” msg=“Success” matchingDocuments=“24” returnedDocuments=“2” /> </ihesq:SimpleQueryResponse> </soapenv:Body>

16. Example Response Message (MTOM/XOP) <soapenv:Body> <ihesq:SimpleQueryResponse> <ihesq:ResultDocument> <xop:Include href="urn:uuid:F862...03956117@apache.org" xmlns:xop="http://www.w3.org/2004/08/xop/include"/> </ihesq:ResultDocument> <ihesq:Status code=“0” msg=“Success” matchingDocuments=“24” returnedDocuments=“1” /> </ihesq:SimpleQueryResponse> </soapenv:Body> Document content as base64 coded SOAP attachment

18. Example Request (CDA) <soapenv:Body> <ihesq:XmlQueryRequest> <hl7v3:typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/> <ihesq:FilterByXPath> (//ClinicalDocument[@classCode=‘57829-4’ and @formatCode=‘urn:epSOS:ps:2010’]/recordTarget/patientRole/ patient[@id=‘123223432424’]/../../..) </ihesq:FilterByXPath> <ihesq:ResultSet maxResults = “1”> <ihesq:Sort order=“descending”> //ClinicalDocument/effectiveTime </ihesq:Sort> <ihesq:ResultSet /> </ihesq:XmlQueryRequest> </soapenv:Body>