Presentation on theme: "June, 2010 SOAP / IHE Concrete Implementation. We are a group of organizations who have already implemented IHE profiles We recognized the user stories."— Presentation transcript:
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 email Email to PHR Web app to email
From:email@example.com To: firstname.lastname@example.org@epic.ehr.nhin.org Source: Allscripts Source HISP:MedAllies Destination/ Destination HISP:Epic User stories: 1, 2, 3, 4, 6
From:email@example.com To: firstname.lastname@example.org@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
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
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
Your consent to our cookies if you continue to use this website.