1. Test Management Eric Poiseau Inria, Rennes

2. Purpose  Provide support for the management of the connectathon process from registration to results  Provide support for continuous testing over the internet.

3. Requirements  Target :  IHE  Vendors  Users

4. Where are we at ?  3 CAT  EU2009 (1/2), EU2010, NA2011, EU2011  We have not yet met our target for vendors and users.

5. Test tools Test Management scenario Test Plan description in Gazelle Peer to Peer Peer to Peer test specification Orchestration Operational test Workflow test specification Proxy Validation Services (EVS) Simulators Systems Data Data set Profiles (IHE & epSOS) Actor Profile Description Profile Description Specification Test Plan Test case 5 Test tools Test Management scenario Test Plan description in Gazelle Peer to Peer Peer to Peer test specification Orchestration Operational test Workflow test specification Proxy Validation Services (EVS) Simulators Systems Data Data set Profiles (IHE & epSOS) Actor Profile Description Profile Description Specification Test Plan Test case 5

7. Explanations  Scenario  Business case. For example : provide a Patient Summary for the patient John Kernevel  Test Cases  Various cases included in the business scenario that need to be tested.  Test Plan Description  Translation into test plan within the Gazelle tool of the test cases.  This translates into Peer to Peer and Workflow test specifications, as well as Data Sets.  Corresponding information is input into Gazelle through web forms that includes precise instructions for testers and description of test sequence diagram. 7

8. Explanations Continued  Peer to Peer test specification  Description of the tests for transactions between 2 actors.  Workflow test specifications  Description of the tests that involve transactions between a group of actors participating to a same test case.  Orchestration  Translation of the test specification into scripts that manage the interactions between the test participants (Simulators or Systems Under Test (SUT)).  Operational Test  Instance of a test script using Simulators, SUT, data and a Proxy for test data capture to verify the conformance. 8

9. Explanation Continued  Proxy  Component that captures data exchanged between the participants to a test (SUT and/or Simulators)  Validation Service  Service that validates the conformity of a message (or document) given the context of a test case.  Data set  Data needed during the operational test to exchange information between actors (ex: first name, last name of the patient, codes,…) 9

10. What’s next ?  Improve application performance  Improve memory usage  Ease Test assignement to monitors  RSS feeds for testers and managers  Easier installation, better documentation  Key Performance Indicator (KPI) Reports  Extends test grading by external tools  Hook to GMM for vendor and users use cases

11. Resources  In 2009 : 25 pm  In 2010 : 10 pm  In 2011 : estimation 7 pm

12. Links and URL  Application :  http://gazelle.ihe.net/EU-CAT http://gazelle.ihe.net/EU-CAT  http://gazelle-green.wustl.edu/IHE_North_America http://gazelle-green.wustl.edu/IHE_North_America  Documentation  http://gazelle.ihe.net/content/gazelle- documentation http://gazelle.ihe.net/content/gazelle- documentation  Support – Feature request  http://gazelle.ihe.net/jira/browse/GZL http://gazelle.ihe.net/jira/browse/GZL