June, 2010 SOAP / IHE Concrete Implementation

We are a group of organizations who have already implemented IHE profiles We recognized the user stories – IHE already addresses them We could leverage existing products and toolkits – it wasn’t scary We can get this done fast

Optional HISP hops XDR backbone Step up and down to edges UDDI Directory Destination HISP Source HISP Step up to XDR Step up to XDR Step down from XDR Step up to XDR SMTP REST XMPP XDR, XDM SMTP REST XMPP XDR, XDM Source Systems Destination Systems Provide and Register

 EMR to EMR  EMR to  to PHR  Web app to

To: Source: Allscripts Source HISP:MedAllies Destination/ Destination HISP:Epic User stories: 1, 2, 3, 4, 6

To: Source/Source HISP:Epic Destination HISP:MedAllies Destination: client User stories: 1, 2, 3, 4, 6, 7, 8, 9, 10, 11

To: Source: client Source HISP:GE / MedAllies Destination / Destination HISPEpic’s Lucy PHR User stories: 6, 7, 8, 9, 10, 11

To: Source:IBM web app Source HISP:GE / Vangent Destination HISP:MedAllies Destination : client User stories: 1, 2, 3, 4, 6, 7, 8, 9, 10, 11

5: Laboratory sends lab results to ordering provider Laboratory may not have a patient ID. If they do, they would likely use XDR on the sending edge. If not: A: Use order number as pseudo patient identifier B: Relax XDR metadata requirements 12: Primary care provider sends patient immunization data to public health Several initiatives within CMS already use XDR on the receiving edge, so this may just be scenario 1.

Straightforward integration with NHIN Exchange One metadata model supports both minimal and extended metadata Developed, maintained, and enhanced through a formal and open process Can work across the continuum of care settings, from small practices to integrated delivery networks

11 Simplicity and use cases

12 The question of metadata XD* profiles provide a consistent structure for metadata that is independent of content\ When we realize we’re dealing with user stories that require metadata, we’ll have a place to put it We can degrade down to zero patient-specific metadata if that is required by policy - we can bring this to IHE to profile it if we want

Supports point-to-point encryption; doesn’t currently support non-trusted intermediaries Intended recipient metadata integrated into content container metadata ebXML can look daunting SOAP looks hard

Maturity of the approach: small changes to XDR are much preferable to inventing something new This is a profile, not just a protocol Trivial interoperability with NHIN Exchange Why SOAP / IHE