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

NOTE: This meeting is being recorded and will be posted on the Wiki page after the meeting

From S&I Framework to Participants:Hi everyone: remember to keep your phone on mute

RESTful Health Exchange (RHEx)

WebEx #7

September 20, 2012

Powering Secure, Web-Based Health Data Exchangewiki.siframework.org/RHEx

DRAFT—for discussion purposes only

Interoperability Test Framework Overview

Overview

• RHEx Overview and Refresher– RHEx Architecture

• The RHEx Test Framework– Specification Validation & Decomposition– Configuration and test profiles– Demonstration

• Summary• Questions & Wrap-up

3

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 1

Phase 2

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 OpenID Connect

Phased testing withRHEx Test Framework

Test Framework

7

Specification Validation

Security SpecificationsOpenID Connect

OAuth 2.0

JSON Web Token

8

Phase 1

Phase 2

Testing in 3 steps

1. 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

2. Test the test assertions using a developed automated Testing Framework

3. Document results

9

Specification Decomposition

6.5.4 DELETEThis operation MAY be implemented. If a DELETE is sent to the document URL, the document is completely deleted. If DELETE is implemented, special precautions should be taken to assure against accidental or malicious deletion. Future requests to the section URL MAY return a status code of 410, unless the record is restored.Status Code: 204, 410

The decomposition and resulting test assertions for this requirement would be defined as follows: 

1. If DELETE operation is not implemented, the server MUST respond with a status code of 405 (section 6.1.2).

2. If DELETE is successful the server must respond with 204 status code (implied requirement).

3. If DELETE operation is successful, then future requests to the document URL MAY return status code 410 unless the record is restored.

4. If target of deletion does not exist then server should respond with 404 not found HTTP status code (implied requirement).

OMG RESTful Transport Specification: Section 6.5.4

10

Test Assertion status codes

PASSED Test passed and was successful. PASSED with

WARNINGS Test passed and was successful with some warnings.

SKIPPED (or missing input)

Test was skipped and not executed because either its inputs were missing (i.e., the input required to process the test assertion was missing) or one of its prerequisite tests was not found or not loaded.

PREREQ_FAILED The test assertion was not processed because a pre-requisite (dependent) test assertion failed.

FAILED RECOMMENDATION

Test fails to meet a recommended or optional (e.g., SHOULD, RECOMMENDED, etc.) element of the specification. This is treated as a warning such that a test assertion failed, but the type attribute for the test assertion indicated that it was “recommended,” not “required.” This type of failure will not affect the overall conformance result.

FAILED Test failed to meet a mandatory (MUST, SHALL, etc.) element of the specification. This designation indicates the target system fails to conform.

The final status of each test assertion is assigned a designation as follows:

11

Sample Test Report

Here’s sample report running against the RHEx Patient Data ServerTest Id Section Description OperationContext Initial

6.2.5.0 6.2.5 baseURL (OPTIONS)6.2.5.1 6.2.5 OPTIONS on HDR baseURL MUST return 200 status

code (implied contentType = text/xml??)OPTIONS HDR baseURL

W

6.2.5.2 6.2.5 X-hdata-security HTTP header MUST be included in response

OPTIONS HDR baseURLP

6.2.5.3 6.2.5 Response SHOULD NOT include an HTTP body (RECOMMENDED)

OPTIONS HDR baseURLF

6.2.5.4 6.2.5 Implied: if baseURL not defined (HDR not found) should return 404 status. (RECOMMENDED)

F

6.3.0 6.3.0 baseURL/root.xml (GET)6.3.1.1 6.3.1 baseURL/root.xml GET [MUST] returns XML object

with 200 status code as defined by the HRF specification (implied contentType = text/xml; namespace = HRF: WARN if not met)

GET baseURL/root.xml

W

6.3.1.2 6.3.1 Implied: if baseURL not defined (HDR not found) should return 404 status. (RECOMMENDED)

GET baseURL/root.xmlP

6.3.2 6.3.2 baseURL/root.xml (non-GET)6.3.2.1 6.3.2 baseURL/root.xml POST operation MUST NOT be

implemented. Returns 405 statusPOST baseURL/root.xml

F

6.3.2.2 6.3.2 baseURL/root.xml PUT operation MUST NOT be implemented. Returns 405 status

PUT baseURL/root.xmlF

12

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.

13

Overview

• RHEx Overview and Refresher– RHEx Architecture

• The RHEx Test Framework– Specification Validation & Decomposition– Configuration and test profiles– Demonstration

• Summary• Questions & Wrap-up

14

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

15

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 RHEx SimpleWeb 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" /> <testAssertion class="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>

16

17

DemoTest against the RHEx

Simple Web App

<?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>

rhexOidcConfig.xml

18

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>

19

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

• RootXmlAtomCheck id=6.2.1.6, req=6.2.1.4, 6.3.1.1– Check consistency between root.xml and atom feed

20

21

BaseUrlRootXml[6.3.1.1]

BaseSectionFromRootXml

[6.4.1.1]

DocumentTest

[6.5.1.2]

DocumentCreate

[6.4.2.2]

DocumentCreateCheck

[6.4.2.3]

DocumentDelete

[6.5.4.1]

DocumentFutureDelete

[6.5.4.3]

RootXmlAtomCheck

[6.2.1.6]

BaseUrlGetTest[6.2.1.4]

Chaining Tests

root.xml

atom feed

22

DemoTest against the RHEx

Patient Data Server

Overview

• RHEx Overview and Refresher– RHEx Architecture

• The RHEx Test Framework– Specification Validation & Decomposition– Configuration and test profiles– Demonstration

• Summary• Questions & Wrap-up

23

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 profile can be executed in different configuration contexts

25

Helping the ONC/RHEx Certification 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

• Suggest making the Test Framework Tool part of the ONC certification testing toolkit

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

26

Powering Secure, Web-Based Health Data Exchange

http://wiki.siframework.org/RHEx

27