IHE IT Infrastructure mHealth access to Document Sharing Profile John Moehrke June 6, 2012

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)

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

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

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…

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

mHealth grouped with XDS

mHealth grouped with XCA

Example: JSON encoding of XDS DocumentEntry {patientID: "144ba3c4aad24e9^^^& &ISO", classCode: {code:" ",codingScheme:“ ", codeName:“Summary of Episode Note"}, confidentialityCode:{code:”N”,codingScheme:” ”,codeName:”Normal sensitivity”}, formatCode:{code:”urn:ihe:lab:xd-lab:2008”,codingScheme:” ”,codeName:”XD-Lab”}, typeCode:{code:””,codingScheme:””,codeName:””}, Author:{…}, practiceSettingCodes:{code:" ",codingScheme:“ ", codeName:“General Medicine"} Title:"document title", creationTime:“ ”, hash:“e543712c0e de13a5bfcbe826c49feb75”, Size:“35”, languageCode:“en-us”, serviceStartTime:“ ”, serviceStopTime:“ ”, sourcePatientId:“89765a87b^^^&3.4.5&ISO”, mimeType:” text/xml ”, uniqueId:” ”, entryUUID:”urn:uuid:14a9fdec-0af4-45bb-adf2-d752b49bcc7d “}

Put DocumentEntry 3.AA 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: / /DocumentEntry/ / 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: 6ISO/DocumentEntry/14a9fdec-0af4-45bb-adf2-d752b49bcc7d/

Get DocumentEntry 3.BB Message Semantics The Document Entry URL includes the patient ID and the entryUUID. The format for the Document Entry URL is: / /DocumentEntry/ / 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

Get Document 3.DD 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. / /Document/ / 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.

FindDocumentEntries 3.CC Message Semantics The Find Document Entries message is an HTTP GET request that can be sent to the FindDocuments URL / /FindDocumentEntries? 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: 3%5EGarbage%5EOINK”&serviceStartTimeFrom=” ”

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?

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

Questions ? 16