Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Direct20: Modular Specifications - Provider Directories

  • Login to see the comments

  • Be the first to like this

Direct20: Modular Specifications - Provider Directories

  1. 1. Modular Specifications Provider Directories
  2. 2. Modular Specifications Overview • The Mod Specs process is not the same as the S&I Framework Process • Mod Specs efforts are aimed at identifying existing specification for a particular area of interest and improving/documenting/testing/promoting that specification • Mod Specs Provider Directories (MSPD) is the fourth Mod Specs Project – This effort is centered around Provider Directories • All Mod Specs projects and associated artifacts are available at • Open process – Public calls held throughout specification development – Formed, consulted an Advisor Group 2
  3. 3. MSPD Project Tasks • Develop Implementable, Testable, Certifiable Specifications – Requirements Traceability Matrix (RTM) – Implementation Guide (IG) • Create a Test Implementation (TI) based on the specifications – Available for download • Create quality test cases – Will be available for download (SoapUI) • Optionally: a tool that can test conformance to the specifications 3
  4. 4. 4 Approach Diagram RTM Organizations provide spec, IG, data model, tech arch documentations for assessment Test Cases TI Develop Artifacts Mod Spec Process Recommend Organization Others SDO 1 SDO 2 Our team leverages artifacts provided by recommended organization
  5. 5. MSPD Approach • MSPD Specifications based on IHE HPD Plus Specifications • Extended HPD Plus in two key aspects: – Error Handling – Federation Facilitation • These extensions manifested in several ways: – New WSDL • Distinguishes between single and federated data sources • Extensible • Can still encode DSML errors – New Error Model • Can distinguish DSML and Web service errors • Gives more information for trouble shooting • Made some straightforward additions to IWG 1.1 LDAP Mappings 5
  6. 6. IWG 1.1 and MSPD - WSDL Category IWG v1.1 MSPD RTM v1.0 WSDL DSML-based WSDL No explicit way to handle either single data source versus federated source. Already handles DSML batch requests and responses Limited flexibility, extensibility. WSDL to facilitate management of transactions in a federated environment. Clear distinction between single data sources and federated results. Simple to process/interpret. Separation of concerns (DSML for data source and HPDrequest, HPDresponse and HPDerror related to web service) DSML batch requests and responses are applicable. A wrapper is added for better separation of concerns Backwards compatible with ‘wrapping’. Extensible. Enables future capabilities and features to be added.
  7. 7. IWG 1.1 and MSPD – Error Handling Category IWG v1.1 MSPD RTM v1.0 Error Handling Constrained by DSML standard. No specified way to handle errors/responses from multiple sources/federated directories. Limited error types. Allows for DSML errors and Web service errors. Can determine error source (LDAP vs. DSML). More robust error handling since more error information is available for trouble-shooting. Added specification for errors that will be handled by the WSDL. These include: notAttempted,couldNotConnect ,connectionClose, malformedRequest, gatewayInternalError, authenticationFailed, unresolvableURI, federationLoop, business rule violation
  8. 8. IWG 1.1 and MSPD – LDAP Mappings Category IWG v1.1 MSPD RTM v1.0 LDAP Mappings Same data model as IWG v1.1 (Limited and straightforward additions necessary to support MSPD error model and federation capabilities.)
  9. 9. MSPD Future Activities • Actively looking for pilot participants – Looking for 3-4 sites interested in HPD Plus – Contact or • Considering submission to SDOs • Continue releasing updates and refinements to RTM, IG, TI over coming months 9