IHE IT InfrastructuremHealth 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)

ConsumerRegistry

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):

ClassPatient IdAuthorFacilityDate of Service…

Source of Documents

XDS Flow and Interactions

3

ConsumerRegistry

RepositorySource 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 Responder Document Recipient

Document Consumer

Find Document Entries [ITI-CC]

Get Document [ITI-DD]

mHealth grouped with XDS

mHealth grouped with XCA

XCA Initiating Gateway

XDS Document Registry

XDS Document Repository

MHD Document Responder

MHD Document Consumer

XCA Responding

GatewayXDS Affinity DomainInfrastructure

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:"document title",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 “}

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/

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

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.

FindDocumentEntries

3.CC.4.1.2 Message SemanticsThe Find Document Entries message is an HTTP GET request that can be sent to the FindDocuments URLhttp://<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”

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