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
http://modularspecs.siframework.org/
• Open process
– Public calls held throughout specification development
– Formed, consulted an Advisor Group
2
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
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. 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. 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. 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. 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. MSPD Future Activities
• Actively looking for pilot participants
– Looking for 3-4 sites interested in HPD Plus
– Contact Farrah.Darbouze@hhs.gov or Matthew.Rahn@hhs.gov
• Considering submission to SDOs
• Continue releasing updates and refinements to RTM, IG, TI over
coming months
9