1. June, 2010 SOAP / IHE Concrete Implementation

2. 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

3. 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

4.  EMR to EMR  EMR to email  Email to PHR  Web app to email

5. From:harry.winston@goodhealthclinic.org To: edward.stukel@epic.ehr.nhin.orgedward.stukel@epic.ehr.nhin.org Source: Allscripts Source HISP:MedAllies Destination/ Destination HISP:Epic User stories: 1, 2, 3, 4, 6

6. From:harry.winston@goodhealthclinic.org To: john.smith@happyvalleyclinic.nhindirect.orgjohn.smith@happyvalleyclinic.nhindirect.org Source/Source HISP:Epic Destination HISP:MedAllies Destination:email client User stories: 1, 2, 3, 4, 6, 7, 8, 9, 10, 11

7. From:harry.winston@goodhealthclinic.org To: marlowephillips@lucy.phr.nhin.orgmarlowephillips@lucy.phr.nhin.org Source:email client Source HISP:GE / MedAllies Destination / Destination HISPEpic’s Lucy PHR User stories: 6, 7, 8, 9, 10, 11

8. From:harry.winston@goodhealthclinic.org To: john.smith@happyvalleyclinic.nhindirect.orgjohn.smith@happyvalleyclinic.nhindirect.org Source:IBM web app Source HISP:GE / Vangent Destination HISP:MedAllies Destination :email client User stories: 1, 2, 3, 4, 6, 7, 8, 9, 10, 11

9. 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.

10. 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. 11 Simplicity and use cases

12. 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

13. 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

14. 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