Desktop+to+Desktop+Implementation+-+Specification,+Standards+and+Testing

To: The S&I Framework Community (SIFC) From: Dr. Stephen Beller (CEO) & Sabatini Monatesti (COO) NHDS, Inc. Re: Specifications, Standards, Testing and Novel Implementations = = Note: For a PDF version of this wiki page, go to [|http://www.nhds.com/dp/specifications_standards_testing_and_novel implementations.pdf] = Background and Concerns = = = = Testing Issues =
 * The November 30, 2011 Direct Project Modular Specification conference call focused on traceability, gap analysis, and testing capability. The test tools are still in development and there are issues about acceptance testing, compliance and certification.
 * On the December 1, 2011 Query Health WG meeting, the discussion centered on decisions made during an F2F meeting a few days ago regarding specifications, standards and reference implementation issues.
 * Based on these recent events, we are concerned that the currently defined testing process, specs, etc. may not be applicable to all demonstrable implementations. For example, we are currently the only company offering a desktop-to-desktop (node-to-node, app-to-app) implementation; it leverages Direct Project specifications[1], provides email transport, and ensures that all information is AES-256 encrypted end-to-end and at rest. Novel approaches such as this requires a testing tool[2] that ensures a test driver traverses all paths through the software starting at the application layer. This would enable it to evaluate the requisite functionality of any viable implementation.

Questions about the Testing Process
Following are questions about the intent of the testing process
 * Is it the intent of the SIFC to specify a traceability function that mimics a user at each end of a transaction?[3]
 * Is it the intent of the SIFC to specify a traceability function that traverses each path through the software, links path name to specification index, and forces and end-to-end successful transmission of an email message, including attached content?
 * Is it the intent of the SIFC to specify a traceability function that demonstrates end-to-end performance (application capacity in terms of end user transactions per second)?

Suggested Testing Approach
We believe our implementation (called RAHN™) requires changes to the specification and standards to incorporate a desktop-to-desktop implementation. This requires construction of a test tool that has knowledge of all software paths, and that links each path to a specification paragraph number. Hence, any failures, errors, omissions, or deviations from specification could be traced back to all SIFC documentation, vendor documentation, and both documentation version control and software release levels along with error history could be coordinated (i.e., given that the test tool could test all paths per swim diagrams). For example:
 * Assume four documents exist and that each is under version control: System Specification (A1), Test Cases (B1), Problem History (Moves, Adds & Changes (C1), and Operations Guide (D1).
 * Assume that three incidence of execution exist in three separate environments: Development (A1-N), Test (A1-M) and Production (A1-P), and that each have different release levels depending on current problem history, i.e., Production environment release level lagging Development environment with Test environment somewhere in between.

Test Requirements

 * Require that all code insert a branch point, with a flag, at each procedure, with hyperlink and error detection, that when traversed and flag is set a hyperlink is executed that provides a date and time stamp as well as a header message to indicate that a particular documentation reference (paragraph number) was implemented or failure has occurred at this point.
 * All documentation would be indexed and linked in this way and thus we would be able to keep the application and the documentation evergreen thus ensuring an audit trail, tracking all release levels and versions across all environments.

Anticipated Outcomes

 * Promotes a mechanism to ensure conformance to functionality specifications regardless of the specific implementation methods used
 * Ensures that applications are acceptable to the end user with a degree of confidence and that the application meets Project Direct Performance and supportability metrics

= RAHN-Related Standards and Specifications =

Standards
Our technology complies with conventional standards including:
 * AES 256 – encryption standard
 * Zip – compression standard
 * SMTP – mail transport standard
 * XML – import and export functionality supported
 * TCP/IP ISO – seven layer stack (Application, Presentation, Security, Transport, Network, Data Link, Physical)
 * SQL – query language standard
 * Spreadsheet, Formulas, Functions and Macro Code – data manipulation standards
 * File Naming, Format and Storage – data management standards
 * LOINC/ICD/SNOMED/etc. – data terminology standards

Reference Implementation
Below are SWIM diagrams that outline high-level specifications related to our implementation’s functionality. The diagrams are based on the OSI model.

Note that we will release additional SWIM diagrams to show our implementation’s level of compatibility with the current SOAP XDR specs based on the Dec. 12, 2011 documents at http://modularspecs.siframework.org/Phase+2+-+Artifacts+for+Review Footnotes: [1] MODULAR ARCHITECTURE DIRECT SECURE TRANSPORT MODULE, Version .4, October 5, 2011 [2] Modular Specification DIRECT Secured Transport, Test Approach, Version 1.0, November 18, 2011 [3] Direct Test Guide, Version 1.3, November 18, 2011

OSI Model Related to RAHN


The following SWIM diagrams are based on the OSI model. The first set of diagrams (Specified Functions 1-5) refers to specified functions of a currently demonstrable application. This application (called the RAHN™ Referral Manager) creates, transmits, stores and renders referral forms and CCDs. The application includes an optional clinical messages/notes module.

Specified Function 6 indicates ways we can handle the HISP process of obtaining authorized provider IDs and other information.

Specified Function 7 indicates an expansion of the Query Health proof of concept (at this link), which includes a process for obtaining schema information and a direct transport method for sending and receiving query parameters and payloads.