IHE IT Infrastructure mHealth access to Document Sharing Profile

1. IHE IT InfrastructuremHealth access to Document Sharing Profile John Moehrke June 6, 2012

2. Documents for Mobile Health • Profile that is as simple as possible on the client side, yet supports as much of XDS Document Source and Document Consumer functionality. • Most focused on supporting as small of a foot-print on the client side (representational case of the client is a mobile device such as smartphone or tablet). • Not intended to replace XDS, but augment it • Lead: John Moehrke (GE)

3. XDS Flow and Interactions • XDS Document (Metadata): • Class • Patient Id • Author • Facility • Date of Service • … Registry Consumer 3. Consumers search for documents with specific information 2. Repository registers the documents metadata and pointer with the Registry Source of Documents Repository 4. Consumers retrieve selected documents from Repository (-ies) 1. Sources post document packages to the Repository

4. mHealth As Proxy to XDS Registry Consumer Source of Documents Repository

5. mHealth • Approach • Resource  XDS Document Entry • HTTP RESTful approach to operations acting on Resource • Flat structure of XDS Document Entry encoded in JSON • Technology • HTTP + JSON • Security/Privacy • Mostly out-of-scope as HTTP RESTful security is layered on using TLS/SSL or Kerberos or OpenID or Oauth or etc…

6. mHealth - transactions Document Source Document Consumer Put Document Entry [ITI-AA]   Get Document Entry [ITI-BB]  Find Document Entries [ITI-CC]  Get Document [ITI-DD] Document Recipient Document Responder

7. mHealth grouped with XDS

8. mHealth grouped with XCA

9. Example: JSON encoding of XDS DocumentEntry {patientID: "144ba3c4aad24e9^^^&1.3.6.1.4.1.21367.2005.3.7&ISO" , classCode: {code:" 34133 -9 ",codingScheme:“2.16.840.1.113883.6.1", codeName:“Summary of Episode Note"}, confidentialityCode:{code:”N”,codingScheme:”2.16.840.1.113883.5.25”,codeName:”Normal sensitivity”}, formatCode:{code:”urn:ihe:lab:xd-lab:2008”,codingScheme:” 1.3.6.1.4.1.19376.1.2.3”,codeName:”XD-Lab”}, typeCode:{code:””,codingScheme:””,codeName:””}, Author:{…}, practiceSettingCodes:{code:" 394802001 ",codingScheme:“2.16.840.1.113883.6.96 ", codeName:“General Medicine"} Title:"documenttitle", creationTime:“20061224”, hash:“e543712c0e10501972de13a5bfcbe826c49feb75”, Size:“35”, languageCode:“en-us”, serviceStartTime:“200612230800”, serviceStopTime:“200612230900”, sourcePatientId:“89765a87b^^^&3.4.5&ISO”, mimeType:” text/xml ”, uniqueId:” 1.2009.0827.08.33.5074”, entryUUID:”urn:uuid:14a9fdec-0af4-45bb-adf2-d752b49bcc7d “}

10. Put DocumentEntry 3.AA.4.1.2 Message Semantics The HTTP POST method is used, with HTTP Accept set to application/json. The message is a MIME multi-part which conforms to the following requirements: • The first mime part is the metadata encoded using the JSON encoding of DocumentEntry. • The second mime part is the document. The Source shall generate a unique UUID for the entryUUID using the well-known rules for UUID creation. The Put Document Entry is sent to the URL for this patient and entryUUID, i.e., the intended Document Entry. The format for a Document Entry URL is: http://<location>/<patientID>/DocumentEntry/<entryUUID>/ Where: • Location – a locally defined root part of arbitrary path. • patientID – the CX encoded patient ID (where XDS is used, this is the XDS Affinity Domain Patient ID). This value may need to be transformed for URL encoding. • entryUUID – the UUID value. For example: http://blah.com/blah/144ba3c4aad24e9%5E%5E%5E%261.3.6.1.4.1.21367.2005.3.7%26ISO/DocumentEntry/14a9fdec-0af4-45bb-adf2-d752b49bcc7d/

11. Get DocumentEntry 3.BB.4.1.2 Message Semantics The Document Entry URL includes the patient ID and the entryUUID. The format for the Document Entry URL is: http://<location>/<patientID>/DocumentEntry/<entryUUID>/ Where: • location – a locally defined root part of arbitrary path • patientID – the CX encoded patient ID (where XDS is used, this is the XDS Affinity Domain Patient ID). This value may need to be transformed URL encoding. • entryUUID – the UUID value

12. Get Document 3.DD.4.1.2 Message Semantics The Document Consumer sends a HTTP GET request to the server. The Document Consumer may use content negotiation by providing a HTTP Accept header, according to the semantics of the HTTP protocols (see RFC 2616, section 14.1). The only MIME type assured to be returned is the MIME type indicated in the Document Entry. http://<location>/<patientID>/Document/<entryUUID>/ Where: • location – a locally defined root part of arbitrary path. • patientID – the CX encoded patient ID (where XDS is used, this is the XDS Affinity Domain Patient ID). This value may need to be transformed for URL encoding. • entryUUID – the UUID value.

13. FindDocumentEntries 3.CC.4.1.2 Message Semantics The Find Document Entries message is an HTTP GET request that can be sent to the FindDocuments URL http://<location>/<PatientID>/FindDocumentEntries?<parameters> Where: • location – a locally defined root part of arbitrary path. • patientID – the CX encoded patient ID (where XDS is used, this is the XDS Affinity Domain Patient ID). This value may need to be transformed for URL encoding. • Parameters – key/value pairs in accordance with RFC2616 for encoding GET queries. …. For example: http://blah.com/blah/144ba3c4aad24e9%5E%5E%5E%261.3.6.1.4.1.21367.2005.3.7%26ISO/FindDocumentEntries?classCode=”2345-3%5EGarbage%5EOINK”&serviceStartTimeFrom=”200501020304”

14. Open Issues • Restricted “Create” to ONE document, with derived SubmissionSet • No access to SubmissionSet, Folders, associations • Patient ID is needed as part of URL • Bring in hData as framework • Bring in ATOM in GET path for multiple entries • Allow for conditional get? • Need more on Security, specifically Audit? • JSON use of anonymous objects or not?

15. Opportunity • May provide light weight access to information in Document form (quicker XDS) • Allergies, Medications, Problems • Referrals • Simplified publish of new document to XDS

16. Questions ?