modular specifications project

Modular Specifications Project

Phase 1: SOAP Based Secure Transport Module

1

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.

2


• Modular Specifications Testing 3

Development Sprints

Public FeedbackSME

Input

Internal Feedback

Interoperability Specification Development Organizations

Presentation of Recommendations

to Community

Production Development Cycles

Artifacts Produced:•Modular and Implementable Specification•Test Implementation Code•Vendor Neutral Test Cases•Recommendations to Community

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

4

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

5

Refactored Specifications

6

Requirements reformatted to be singular, testable statements

Internal hyperlinks ease navigation within document

Links to underlying specifications provided where appropriate

Test Implementation Team

7

• Architecture – Transport

HIO Adapters

WS JMS

RESTSMTP

Request / Response HandlersInbound

Orchestrators

FiltersTransformer

s

Outbound Orchestrator

s

Transport CoreSOAP Processor

WS-RM (Optional)

State Handler

Cert Validator

WS-A Handler

Session Handler

Policy Verifier

Security Interface

RI CoreAuditing Logging Exception

Handling DAO UtilitiesConfiguration UDDI


• Architecture – Security

8

HIO Adapters

WS JMS

RESTSMTP

Request / Response Handlers

Security CoreSAMLValidation Handler

Authorization Handler

SAMLAssertion Handler

WSSecurity Handler

RI CoreAuditing Logging Exception

Handling DAO Configuration Utilities UDDI


9

Nationwide Health

Information Network

Exchange


• Unit Testing

• Transport & Security Test Cases

• Test Approach

o Test Harness

o Installation Instructions

o Entrust Installation Instructions10

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.

11

Testing Team

• x

12

Then we design bottom-up test cases using specific message variants to test specific requirements.

…

Test cases are derived from requirements both top-down and bottom-up. We start with an enumerated requirement…

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

Test cases

Testing Team

13

• 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

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

Testing Team

14

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

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

15

http://modularspecs.siframework.org/

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.

16

http://www.gpo.gov/fdsys/pkg/FR-2012-03-07/pdf/2012-4430.pdf

Walkthrough

17


Phase 2: Direct Transport Module

18





19



Development Sprints

Public FeedbackSME

Input

Internal Feedback



to Community


Artifacts Produced:•Modular and Implementable Specifications•Test Implementation Code•Vendor Neutral Test Cases•Recommendations to Community

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

21

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

22


23





• Architecture – eMail Client using native S/MIME

24

Test Implementation

• Design

25

Test Implementation

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

26

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-


– 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


original specifications. 27

Testing Team

28

Then we design bottom-up test cases using specific message variants to test specific requirements.

…

Test cases are derived from requirements both top-down and bottom-up. We start with an enumerated requirement…

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

Test cases

Testing Team

29

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

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

Testing Team

30

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

Testing Team

31

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

Public Review



• 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

32


Walkthrough

33


Phase 3: Certificate Discovery for Direct Module

34





35



Development Sprints

Public FeedbackSME

Input

Internal Feedback



to Community


Artifacts Produced:•Modular and Implementable Specification•Test Implementation Code•Vendor Neutral Test Cases•Recommendations to Community

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

37

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

38


39




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)

40

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

41

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

42

Certificate Discovery Hybrid Model

43

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

44

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-


– Test cases describing both basic and alternative (negative and behavior) message flows, and


original specifications.

45

Testing Team

46

Direct Certificate Discovery is very behavior-centric, rather than message-centric. So starting with a single requirement…

We generate multiple test cases to cover the various success and error paths through the algorithm.

Test cases traceable to requirements (from requirements under construction)

Test cases

Testing Team

47

• Test data 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.

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

48

Public Review



• 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

49


Walkthrough

50

Phase 3 – Public Call

• Next Public Call– May 2, 2012

51

modular specifications project

Documents

underlying specifications

specifications teamdeveloped

adoptable specifications

direct transport

test artifacts

project team

testing project

implementation guidance