Modular Specifications Project

1. Modular Specifications Project Phase 1: SOAP Based Secure Transport Module

2. Modular Specifications Project Overview The Modular Specifications and Testing Project is a sponsored by ONC intended to generate platform independent modules or building blocks for Nationwide Health Information Network functions. The building blocks produced by the pilot include: requirements driven, implementable and adoptable specifications, test implementations that fully implement each specification, and test suites for each specification. The Modular Specifications Project is a highly collaborative process which leverages the collective knowledge of the project team, subject matter experts, and the standards, implementation, testing and user community through high intensity development sprints and iterative public review. To date, the Modular Specifications Project has created modules for SOAP Based Transport and Direct Transport. The project team is currently in the process developing artifacts for Certificate Discovery for Direct Transport.

3. Modular Specifications Project Interoperability Specification Development Organizations Production Development Cycles • Artifacts Produced: • Modular and Implementable Specification • Test Implementation Code • Vendor Neutral Test Cases • Recommendations to Community Public Feedback SME Input Presentation of Recommendations to Community Development Sprints Internal Feedback Modular Specifications Testing

4. Phase 1 Scope • SOAP Based Secure Transport Module • Specifications used: Exchange Authorization Framework and Messaging Platform – transport and security infrastructure, no content • Transport method: SOAP over HTTP • There was a formal review period after the conclusion of this phase. • The Phase 1 artifacts have been presented to the HIT Standards Committee and Exchange Coordinating Committee for review

5. Specifications Team • Developed a Requirements Traceability Matrix (RTM) in Excel • Reformatted conversational text of the source production specifications into singular requirement statements • Non-requirement text (examples, implementation guidance, etc) were moved to appendices • Included optionality for each requirement • Provided traceability to underlying specifications for each requirement statement (HL7, OASIS, etc.) • Provided traceability to associated Test Implementation and Test artifacts for each requirement • Developed Visual Basic code to convert the RTM into a HTML document. • Allows for easy navigation, hyperlinks from each requirement to applicable appendices and underlying specifications • Allows for easy publication and maintenance

6. Refactored Specifications Internal hyperlinks ease navigation within document Requirements reformatted to be singular, testable statements Links to underlying specifications provided where appropriate

7. Test Implementation Team Request / Response Handlers HIO Adapters Inbound Orchestrators Outbound Orchestrators WS JMS Filters Transformers SMTP REST Transport Core SOAP Processor WS-A Handler Cert Validator Security Interface State Handler Session Handler Policy Verifier WS-RM (Optional) RI Core Auditing Logging Exception Handling DAO Configuration Utilities UDDI • Architecture – Transport

8. Test Implementation Team HIO Adapters WS JMS Security Core SAMLValidation Handler WSSecurity Handler SMTP REST Request / Response Handlers SAMLAssertion Handler Authorization Handler RI Core Auditing Logging Exception Handling DAO Configuration Utilities UDDI • Architecture – Security

9. Test Implementation Team Nationwide Health Information Network Exchange

10. Test Implementation Team • Unit Testing • Transport & Security Test Cases • Test Approach • Test Harness • Installation Instructions • Entrust Installation Instructions

11. Testing Team • Developed a written test package useful to a wide range of audiences: • A tester or test team intending to perform an IV&V task, • A product vendor or developer to pull into their internal testing process, or • A pilot system going through pre-validation, validation, or self-attestation model when going live. • The package includes: • Test cases describing both basic and alternative (negative and behavior) message flows, • Checklists to utilize against resultant logs/messages to review field-by-field conformance, and • Test data or templates to create data. • The package traces back to both the RTM and the original specifications.

12. Testing Team Test cases are derived from requirements both top-down and bottom-up. We start with an enumerated requirement… Test cases … This testing domain is message-centric, so we design top-down test cases for basic end-to-end message flows: initiator success, responder success, and responder error. Test cases are traceable from the requirements… and to the requirements Then we design bottom-up test cases using specific message variants to test specific requirements. x

13. Testing Team Checklists XPath or other search criteria for the field you are verifying Verify presence: required, optional, conditional Any other verifications, along with descriptions and examples Other (non-RTM) requirements that pertain to this field • We also develop test checklists, which are used to verify conformance of messages or files. Each Checklist Item is written to: • Make it relatively easy for a verifier (or tool) to determine conformance and answer questions about a specific field • Consolidate all checks about that field in one place, using unambiguous language (e.g. MUST) • Track all spec references pertaining to that field, using references as detailed as possible

14. Testing Team Together with Test Cases, Checklist Items provide full verification coverage for all testable requirements.

15. Public Review The deliverables have been available throughout the Project lifecycle at http://modularspecs.siframework.org/ Public calls have been held throughout the process to gather input from the stakeholder community There was a formal review period after the conclusion of the phase. The Mod Spec Pilot was also presented to the HIT Standards Committee and Exchange Coordinating Committee for review

16. Reference in MU Stage 2 NPRM The Phase 1 artifacts are currently referenced in the Meaningful Use of Health IT Stage 2 Notice for Proposed Rulemaking posted at http://www.gpo.gov/fdsys/pkg/FR-2012-03-07/pdf/2012-4430.pdf The specific reference is: We believe the use of these standards is a critical first step in achieving a common means of transporting health information to support MU and future exchange needs. For this certification criterion, we also propose to adopt as an optional standard at § 170.202(a)(3) the SOAP–Based Secure Transport RTM version 1.0 32 which was developed under the nationwide health information network Exchange Initiative and to which we believe EHR technology should be able to be certified. 32http://modularspecs.siframework.org/NwHIN+SOAP+Based+Secure+Transport+Artifacts.

17. Walkthrough

18. Modular Specifications Project Phase 2: Direct Transport Module

19. Modular Specifications Project Overview The Modular Specifications and Testing Project is a sponsored by ONC intended to generate platform independent modules or building blocks for Nationwide Health Information Network functions. The building blocks produced by the pilot include: requirements driven, implementable and adoptable specifications, test implementations that fully implement each specification, and test suites for each specification. The Modular Specifications Project is a highly collaborative process which leverages the collective knowledge of the project team, subject matter experts, and the standards, implementation, testing and user community through high intensity development sprints and iterative public review. To date, the Modular Specifications Project has created modules for SOAP Based Transport and Direct Transport. The project team is currently in the process developing artifacts for Certificate Discovery for Direct Transport.

20. Modular Specifications Project Interoperability Specification Development Organizations Production Development Cycles • Artifacts Produced: • Modular and Implementable Specifications • Test Implementation Code • Vendor Neutral Test Cases • Recommendations to Community Public Feedback SME Input Presentation of Recommendations to Community Development Sprints Internal Feedback Modular Specifications Testing

21. Phase 2 Scope • Direct Transport Specifications • Specifications used: Direct Applicability Statement for Secure Health Transport and XDR and XDM for Direct Messaging Specifications • Transport method: SMTP and S/MIME with XDR and XDM conversions • There was a formal review period after the conclusion of this phase. • The Phase 2 artifacts have also been presented to the HIT Standards Committee for review • The Phase 2 recommendations have been presented to the Direct Community for review, currently awaiting response

22. Specifications Team • Developed a Requirements Traceability Matrix (RTM) in Excel • Reformatted conversational text of the source production specifications into singular requirement statements • Non-requirement text (examples, implementation guidance, etc) were moved to appendices • Included optionality for each requirement • Provided traceability to underlying specifications for each requirement statement (HL7, OASIS, etc.) • Provided traceability to associated Test Implementation and Test artifacts for each requirement • Developed Visual Basic code to convert the RTM into a HTML document. • Allows for easy navigation, hyperlinks from each requirement to applicable appendices and underlying specifications • Allows for easy publication and maintenance

23. Refactored Specifications Internal hyperlinks ease navigation within document Requirements reformatted to be singular, testable statements Links to underlying specifications provided where appropriate

24. Test Implementation Team • Architecture – eMail Client using native S/MIME

25. Test Implementation Design

26. Test Implementation Implementation Guide Interaction with Direct Community Validated existing Direct code Unit Test Cases Run Test Cases Develop and Tested Implementation Guide

27. Testing Team • Developed a written test package useful to a wide range of audiences: • A tester or test team intending to perform an IV&V task, • A product vendor or developer to pull into their internal testing process, or • A pilot system going through pre-validation, validation, or self-attestation model when going live. • The package includes: • Test cases describing both basic and alternative (negative and behavior) message flows, • Checklists to utilize against resultant logs/messages to review field-by-field conformance, and • Test data or templates to create data. • The package traces back to both the RTM and the original specifications.

28. Testing Team Test cases are derived from requirements both top-down and bottom-up. We start with an enumerated requirement… Test cases … This testing domain is message-centric, so we design top-down test cases for basic end-to-end message flows: initiator success, receiver success, and receiver error. Test cases are traceable from the requirements… and to the requirements Then we design bottom-up test cases using specific message variants to test specific requirements.

29. Testing Team • We also develop test checklists, which are used to verify conformance of messages or files. Each Checklist Item is written to: • Make it relatively easy for a verifier (or tool) to determine conformance and answer questions about a specific field • Consolidate all checks about that field in one place, using unambiguous language (e.g. MUST) • Track all spec references pertaining to that field, using references as detailed as possible Checklists Any other verifications, along with descriptions and examples XPath or other search criteria for the field you are verifying Verify presence: required, optional, conditional Other (non-RTM) requirements that pertain to this field

30. Testing Team Together with Test Cases, Checklist Items provide full verification coverage for all testable requirements.

31. Testing Team Unique challenges this phase: • Support more complex deployment models than simple messaging: • Abstracted actors into sender, converter, receiver • Large-scale reuse of checklists from other testing contexts • XD* conversion tests needed similar checklists to NwHIN Document Submission, Query for Documents, etc. • RTM utilized new IHE Metadata-Limited supplement • Refactored to make checklists modular and context-aware

32. Public Review The deliverables have been available throughout the Project lifecycle at http://modularspecs.siframework.org/ Public calls have been held throughout the process to gather input from the stakeholder community There was a formal review period after the conclusion of the phase. The Mod Spec artifacts have also been presented to the HIT Standards Committee and Direct Community for review

33. Walkthrough

34. Modular Specifications Project Phase 3: Certificate Discovery for Direct Module

35. Modular Specifications Project Overview The Modular Specifications and Testing Project is a sponsored by ONC intended to generate platform independent modules or building blocks for Nationwide Health Information Network functions. The building blocks produced by the pilot include: requirements driven, implementable and adoptable specifications, test implementations that fully implement each specification, and test suites for each specification. The Modular Specifications Project is a highly collaborative process which leverages the collective knowledge of the project team, subject matter experts, and the standards, implementation, testing and user community through high intensity development sprints and iterative public review. To date, the Modular Specifications Project has created modules for SOAP Based Transport and Direct Transport. The project team is currently in the process developing artifacts for Certificate Discovery for Direct Transport.

36. Modular Specifications Project Interoperability Specification Development Organizations Production Development Cycles • Artifacts Produced: • Modular and Implementable Specification • Test Implementation Code • Vendor Neutral Test Cases • Recommendations to Community Public Feedback SME Input Presentation of Recommendations to Community Development Sprints Internal Feedback Modular Specifications Testing

37. Phase 3 Scope • Phase 3: Certificate Discovery for Direct • Specifications used: Direct Applicability Statement for Secure Health Transport (digital certificate sections) and the S&I Framework’s Certificate Discovery for Direct Project Implementation Guide • Discovery method: DNS and LDAP hybrid • Phase 3 is currently under development. • There will be a formal review period after the conclusion of this phase. • The Phase 3 artifacts will also be presented to the HIT Standards Committee and Direct Community for review

38. Specifications Team • Developed a Requirements Traceability Matrix (RTM) in Excel • Reformatted conversational text of the source production specifications into singular requirement statements • Non-requirement text (examples, implementation guidance, etc) were moved to appendices • Included optionality for each requirement • Provided traceability to underlying specifications for each requirement statement (HL7, OASIS, etc.) • Provided traceability to associated Test Implementation and Test artifacts for each requirement • Developed Visual Basic code to convert the RTM into a HTML document. • Allows for easy navigation, hyperlinks from each requirement to applicable appendices and underlying specifications • Allows for easy publication and maintenance

39. Refactored Specifications Internal hyperlinks ease navigation within document Requirements reformatted to be singular, testable statements Links to underlying specifications provided where appropriate

40. Test Implementation (TI) Mission Develop a Direct-based test implementation to demonstrate certificate discovery using the DNS/LDAP hybrid approach. TI Roadmap • Research and deploy existing Direct infrastructure • Setup infrastructure for certificate discovery using Direct • Implement phase 3 requirements • Coordinate with test team to verify compliance with specifications TI Artifacts • Technical Architecture Document (posted on public wiki) • Test Implementation Guide (work in progress)

41. TI Progress Activities • Identified and communicated gaps in current specifications • Reached out to members of Direct community for guidance • Reviewed existing Direct documentation for certificate discovery • Developed Technical Architecture Document • Certificate Discovery system architecture using DNS/LDAP hybrid approach • Certificate Discovery technical workflow and process • Setup Test Implementation infrastructure • Initial configuration for testing DNS/LDAP queries without Security/Trust Agent (STA) • Utilize Direct STA for querying DNS/LDAP

42. TI Technical Notes Technical Notes • Reuse existing Direct implementation functionality to query/discover certificates • Reuse existing Direct configuration web services to manage user and organization level certificates and SRV records • Use of Apache DS as a test LDAP implementation • Initial test configuration specifics • Use of soapUI to query Direct configuration web services to retrieve certificates or LDAP location • Adaptation of existing Direct Java utility to query LDAP and obtain certificate • Can be distributed as a self-contained archive for Windows and Linux

43. Certificate Discovery Hybrid Model

44. TI Next Steps • Research, deploy and configure Direct Security/Trust Agent (STA) for querying DNS/LDAP for digital certificate • Publish updated test implementation guide • Coordinate with test team to verify compliance with specifications

45. Testing Team • Developed a written test package useful to a wide range of audiences: • A tester or test team intending to perform an IV&V task, • A product vendor or developer to pull into their internal testing process, or • A pilot system going through pre-validation, validation, or self-attestation model when going live. • The package includes: • Test cases describing both basic and alternative (negative and behavior) message flows, and • Test data or templates to create data. • The package traces back to both the RTM and the original specifications.

46. Testing Team Direct Certificate Discovery is very behavior-centric, rather than message-centric. So starting with a single requirement… Test cases Test cases traceable to requirements (from requirements under construction) We generate multiple test cases to cover the various success and error paths through the algorithm.

47. Testing Team • Test data (i.e. test certificates and DNS/LDAP entries) are staged for each test case to force a certain path through the discovery algorithm. • If the System Under Test sends the Direct message using the correct certificate, it passes the test. • Reduces need to capture and inspect DNS or LDAP message traffic. Test data

48. Testing Team Unique challenges this phase: • Behavior-centric requirements rather than message-centric • Addressed in part through test data staging • Addition of DNS and LDAP Server actors • May be part of either the Test Environment or the System Under Test

49. Public Review The deliverables have been available throughout the Project lifecycle at http://modularspecs.siframework.org/ Public calls have been held throughout the process to gather input from the stakeholder community There will be a formal review period for after the conclusion of this phase. The Mod Spec artifacts will also be presented to the HIT Standards Committee and Direct Community for review

50. Walkthrough