Meeting Etiquette

1. Meeting Etiquette • Please announce your name each time prior to making comments or suggestions during the call • Remember: If you are not speaking keep your phone on mute • Do not put your phone on hold – if you need to take a call, hang up and dial in again when finished with your other call • Hold = Elevator Music = very frustrated speakers and participants • This meeting, like all of our meetings, is being recorded • Another reason to keep your phone on mute when not speaking! • Feel free to use the “Chat” or “Q&A” feature for questions or comments, especially if you have a bad phone connection or background noise in your environment From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute  NOTE: This meeting is being recorded and will be posted on the Wiki page after the meeting

2. RESTful Health Exchange (RHEx)WebEx #7September 20, 2012 Interoperability Test Framework Overview wiki.siframework.org/RHEx Powering Secure, Web-Based Health Data Exchange DRAFT—for discussion purposes only

3. Overview • RHEx Overview and Refresher • RHEx Architecture • The RHEx Test Framework • Specification Validation & Decomposition • Configuration and test profiles • Demonstration • Summary • Questions & Wrap-up

4. What is RHEx (Refresher from WebEx 1) • An open source, exploratory project to apply proven web technologies to demonstrate a simple, secure, and standards-based health information exchange • Sponsored by the Federal Health Architecture (FHA) program • Called RESTful Health Exchange (RHEx) • Intended to inform a path forward on a RESTful health exchange • A Fiscal Year 2012 project being demonstrated in 2 phases • Phase I: Security approach for a RESTful health information exchange (April-July 2012) • Phase II: Content approach for a RESTful health information exchange (July-September 2012) Download the recording or briefing from the 1st WebEx here: http://wiki.siframework.org/RHEx+Materials

5. RHEx Architecture Stack Phase 1 Phase 2 Phase 1 Key

6. Overview – the RHEx Test Framework • Built to validate conformance testing initially against the RHEx profiles and associated specifications • Runs against a set of URLs defined on a configuration file, so can be run against any server that implements RHEx service interfaces • Results of such conformance testing may become input to certification testing, particularly for those components affecting security through OpenIDConnect

7. Phased testing withRHEx Test Framework Test Framework

8. Specification Validation Phase 2 Phase 1 Security Specifications OpenID Connect OAuth 2.0 JSON Web Token

9. Testing in 3 steps • Decompose and derive valid test assertions requirements from identified, technical specifications • Each test assertion will map to a particular SHALL, MUST, or SHOULD statement in a relevant specification • Test the test assertions using a developed automated Testing Framework • Document results

10. Specification Decomposition OMG RESTful Transport Specification: Section 6.5.4 • The decomposition and resulting test assertions for this requirement would be defined as follows: • If DELETE operation is not implemented, the server MUST respond with a status code of 405 (section 6.1.2). • If DELETE is successful the server must respond with 204 status code (implied requirement). • If DELETE operation is successful, then future requests to the document URL MAY return status code 410 unless the record is restored. • If target of deletion does not exist then server should respond with 404 not found HTTP status code (implied requirement).

11. Test Assertion status codes The final status of each test assertion is assigned a designation as follows:

12. Sample Test Report Here’s sample report running against the RHEx Patient Data Server

13. Testing FrameworkFunctional Components • Validation Process Control • This function controls all processing within the testing tool. • Set-up Context • Manages the configuration properties for the test client with implementation-specific details such as the base URL and supported XML files to publish as documents. • Optionally initializes the context to any implementation-specific details such as security and authentication with hooks in place to perform pre- and post-actions on each HTTP request. • Test Assertion Executor • Builds a test plan to execute test assertions in a valid order • Execute the test assertion components handling any exceptions. • Test assertion components validate particular requirements is implemented correctly • Build Conformance Report • Output from the analyzer tool is a conformance report. • As the test assertions are processed, the conformance report is built based on output from the validation functions.

14. Overview • RHEx Overview and Refresher • RHEx Architecture • The RHEx Test Framework • Specification Validation & Decomposition • Configuration and test profiles • Demonstration • Summary • Questions & Wrap-up

15. simpleConfig.xml <?xml version="1.0" encoding="UTF-8" ?> <configuration> <loginURL> http://rhex-simple:3000 </loginURL> <defaultUser> <email>test@test.com</email> <password>password</password> </defaultUser> <user2> <email>user2@test.com</email> <password>password</password> </user2> …. <noaccessUser> <email>noaccess@test.com</email> <password>password</password> </noaccessUser> <HttpRequestChecker> org.mitre.rhex.security.RhexOpenIdConnectSecurityChecker </HttpRequestChecker> <baseURL> http://rhex-simple:3000/patients/1 </baseURL> <invalidBaseURL>http://rhex-simple/patients/NotValid</invalidBaseURL> <document> <url> http://rhex-simple:3000/uploads/document/attachment/1/vitalSign.xml</url> <!-- include content (e.g. id) from test document to verify document was loaded correctly --> <content><![CDATA[ <id>8f37e9a12a10020004000080</id> ]]></content> </document> <profileDocumentFile> profiles/simpleProfile.xml </profileDocumentFile> </configuration> This slide shows configuration customized to an instance of the RHEx Simple Web App

16. profiles/simpleProfile.xml <?xml version="1.0" encoding="UTF-8"?> <assertionProfile> <description> This document contains the test assertions for the Simple Profile definition for the RHExSimpleWeb Application. These test assertions are used by the testing tool to determine if server implementing the RHEx data interface is conformant to the Simple Profile. </description> <testAssertion class="org.mitre.rhex.BaseUrlNotFoundTest" id="6.2.1.1"/> <testAssertion class="org.mitre.rhex.BaseUrlGetHtmlAcceptTest" id="6.2.1.5" /> <testAssertionclass="org.mitre.rhex.BaseUrlRootXmlNotFound" id="6.3.1.2"/> <testAssertion class="org.mitre.rhex.SectionNotFound" id="6.4.1.2"/> <testAssertion class="org.mitre.rhex.openid.UserDocumentGetTest" id="C.2.1" /> <testAssertion class="org.mitre.rhex.openid.UserAccessTest" id="C.2.2" prereq="C.2.1" /> <testAssertion class="org.mitre.rhex.openid.MultiUserSessionTest" id="C.3.0" /> </assertionProfile>

17. Demo Test against the RHEx Simple Web App

18. rhexOidcConfig.xml <?xml version="1.0" encoding="UTF-8" ?> <configuration> <loginURL> http://rhex:3000/</loginURL> <defaultUser> <email>test@test.com</email> <password>password</password> </defaultUser> <HttpRequestChecker> org.mitre.hdata.test.RhexOpenIdConnectSecurityChecker </HttpRequestChecker> <baseURL> http://rhex:3000/records/3 </baseURL> <invalidBaseURL> http://rhex:3000/records/NotValid </invalidBaseURL> <updateDocumentUrl> http://rhex:3000/records/2/conditions/4f985c3ad7d76a6d830000d6 </updateDocumentUrl> <documentSection> vital_signs </documentSection> <updateDocumentFile> data/vitalSign.xml </updateDocumentFile> … <profileDocumentFile> profiles/basicProfile.xml </profileDocumentFile> </configuration>

19. profiles/basicProfile.xml <?xml version="1.0" encoding="UTF-8"?> <assertionProfile> <description> This document contains the test assertions for the Basic Profile definition. These test assertions are used by the testing tool to determine if server implementing the RHEx interface is conformant to the Basic Profile. </description> <testAssertion class="org.mitre.rhex.BaseUrlGetTest" id="6.2.1.4" /> <testAssertion class="org.mitre.rhex.BaseUrlOptions" id="6.2.5.1" /> <testAssertion class="org.mitre.rhex.BaseUrlRootXml" id="6.3.1.1" /> <testAssertion class="org.mitre.rhex.BaseSectionFromRootXml" id="6.4.1.1“ prereq="6.3.1.1" /> <testAssertion class="org.mitre.rhex.RootXmlAtomCheck” id=“6.2.1.6” prereq=“6.2.1.4, 6.3.1.1” /> <testAssertion class="org.mitre.rhex.SectionPut" id="6.4.3" prereq="6.4.1.1" /> <testAssertion class="org.mitre.rhex.BaseUrlRootXmlPut" id="6.3.2.2"/> <testAssertion class="org.mitre.rhex.DocumentNotFound" id="6.5.1.2" prereq="6.4.1.1" /> <testAssertion class="org.mitre.rhex.DocumentUpdate" id="6.5.2.1" /> </assertionProfile>

20. Test Unit Dependencies • BaseUrlGetTest id=6.2.1.4 • 6.2.1 GET Operation on the Base URL Server MUST offer an Atom 1.0 compliant feed of all child sections specified in HRF specification, as identified in corresponding sections node in the root document • BaseUrlRootXml id=6.3.1.1 • 6.3.1 GET baseURL/root.xml GET operation MUST return an XML representation of the current root document, as defined by the HRF specification • RootXmlAtomCheckid=6.2.1.6, req=6.2.1.4, 6.3.1.1 • Check consistency between root.xml and atom feed

21. Chaining Tests root.xml atom feed

22. Demo Test against the RHExPatient Data Server

23. Overview • RHEx Overview and Refresher • RHEx Architecture • The RHEx Test Framework • Specification Validation & Decomposition • Configuration and test profiles • Demonstration • Summary • Questions & Wrap-up

24. Key Features of the RHEx Test Framework • Test Framework is a generic testing framework • Framework not tied to any specific health or security standard • Underlying API to create new tests and extend to new specifications • Schedules tests based on dependencies • Executes tests and generates report with status and errors/warnings logged • Abstracts test implementation from configuration and most server implementation details • Most inputs consist of a URL that can be configured to one of many implementations (see simpleConfig.xml as example) • Chaining tests allows tests to be as fine grain as possible and focus on a discrete test assertion • Keeps tests simple!!! • Tests can use any of the requests, responses, and inputs for other tests so don’t need to duplicate requests • Abstracts set of tests to run from configuration • Configuration file selects Test Profile to execute (see basicProfile.xml) • Test profilecan be executed in different configuration contexts

25. Helping the ONC/RHExCertification Process • RHEx Test Framework runs against a set of URLs defined in the configuration file • Can be configured and run against any server that implements RHEx service interfaces • Test framework software can be downloaded by partners using public website github.com • Results of such conformance testing can become input to possible future certification testing • Certification will require that relevant standards are correctly implemented; the test framework can demonstrate this • This is particularly useful to verify those components affecting security through OpenID Connect • Suggestmaking the Test Framework Tool part of the ONC certification testing toolkit

26. Questions & Wrap-up • Questions? • This FY12 project seeks community engagement: • Visit the RHEx wiki for more information • Join the community discussion on Google Groups • Participate in the RHEx WebEx meetings (see S&I calendar) • Only one left – September 27, Thursday, 11 am – 12 pm EDT • Let us know if you would like additional information

27. Powering Secure, Web-Based Health Data Exchange http://wiki.siframework.org/RHEx