1. Nov. 21, 208 CEN/ISSS eBIF GTIB Workshop, Brussels 1 CEN/ISSS eBIF Global eBusiness Interoperability Test Bed Methodologies Project Some Thoughts on the Requirements for the Global Conformance and Interoperability Test Frameworks Prof. Dr. Asuman Dogac Dept. of Computer Eng. Middle East Technical University Ankara, Turkey

2. Nov. 21, 208 CEN/ISSS eBIF GTIB Workshop, Brussels 2 Interoperability Stack Testing Interoperability involves not a single standard but a collection of standards addressing different layers in the interoperability stack There are several alternative standards to be chosen from for each layer Profiling avoids this problem by fixing the combination of the standards and even further restricting the interfaces to provide interoperability Integrated Healtcare Enterprises (IHE) HITSP in USA for NHIN Ministry of Health, Turkey for NHIS However, there are standards which allow greater flexibility by specifying a range of standards for a specific layer  E.g., HL7 v3 provides a number of normative specifications for the transport layer such as ebMS or Web services

3. INTEROPERABILITY STACK Communication Layer Transport Protocols: HTTP, SMTP, MLLP,... Higher Level Messaging Protocols: SOAP, ebMS,... Quality of Service Protocols: WS-Reliability, WS-Security, WS-Addresing Business Process Layer Choreography/Business Process Standards: WSCDL, ebBP Specifications with Diagrams: e.g. IHE(Actor/Transaction Diagrams,Sequence Diagrams), NES UBL (Activity Diagrams), HL7 (Sequence Diagrams) Document Layer Non-XML Content: HL7 v2 Messages (EDI), X12, DICOM (Medical Imaging) Industry Specific XML Schemas: HL7 v3 Messages, HL7 CDA, CEN EHRCom, UBL, OAGIS,... Terminologies/Coding Systems: LOINC, UNSCSP, ISO 3166... Business Rules (e.g by using schematrons) Integrati on Profiles (e.g. IHE, NES UBL) or Technica l Specifica tions (National or Regional Health Networks: e.g. USA NHIN, NICTIZ, Saglik-NET) Integrati on Profiles (e.g. IHE, NES UBL) or Technica l Specifica tions (National or Regional Health Networks: e.g. USA NHIN, NICTIZ, Saglik-NET) Interoperability Stack

4. Nov. 21, 208 CEN/ISSS eBIF GTIB Workshop, Brussels 4 Foreseen requirements… A Test Execution Model  Which is capable of testing different scenarios using different standards at each layer Scenario based testing capability Allowing “pluggable adaptors”, i.e., nothing should be hard coded because different communities may use different standards for a specific layer High level test constructs that can simulate the missing actors in the scenario Capability to dynamically set up test scenarios, e.g., changing test data at run time

5. Nov. 21, 208 CEN/ISSS eBIF GTIB Workshop, Brussels 5 Foreseen requirements… Ability to test over the Web anytime, anywhere and with any party Ability to handle different electronic document standards (XML, EDI, DICOM, UBL, OAGIS 9.1, GS1 XML,…) Ability to model for user interactions, reporting and execution monitoring Ability to handle control flow Ability to model all test constructs/commands

6. Foreseen requirements… Adequate communication capabilities, such as  Sending and receiving messages to/from SUTs  Ability to process the message according to the specified protocol to be able to use them in test script executions, e.g., parsing a SOAP message into SOAP Header, SOAP Body and the Attachment  Ability to intercept the messages among the SUTs in interoperability tests

7. Nov. 21, 208 CEN/ISSS eBIF GTIB Workshop, Brussels 7 Foreseen requirements… Validation Techniques  A modular validation interface where different validation tools (XSD Validators, Schematrons, XPATH, Rule Engines, etc) can easily be integrated into framework and used for syntactic and semantic tests  Should enable integration of specialized validation components (e.g. a LOINC code list/code validator)  Should provide an interface to enable third party validations in test executions (e.g., a Web service interface)  Validations with user interaction (e.g., a user can be prompted by questions or information requests where the responses are used in validations)

8. Nov. 21, 208 CEN/ISSS eBIF GTIB Workshop, Brussels 8 Foreseen requirements… Test Result Reporting  Ability to generate a report for each step  Ability to generate detailed reporting (e.g. reason or location of failure)  The informational logs for other steps (message steps, user interactions) should also be included in the report  The report should be presented in a common format although validation tools may have their own format

9. Nov. 21, 208 CEN/ISSS eBIF GTIB Workshop, Brussels 9 Foreseen requirements… Further automation (preliminary steps)  Automation of configuration management  Presenting the scenario to SUT admins (information entities in the scenario) “A patient whose name is John Doe visits doctor Mary in 2008-10-13. The main diagnosis identified after the examination is Bronchitis…”  For easy maintenance and dynamicity of a test scenario, the information given in the scenario should be bound to the test scripts  Automation of these steps also enables run-time customization of the scenario templates by means of user interaction capabilities Test designer can delegate the responsibility of specifying the value of an information entity to the user of a SUT  May also support the integration of random value providers for these information entities

10. Nov. 21, 208 CEN/ISSS eBIF GTIB Workshop, Brussels 10 Foreseen requirements… Test Execution Monitoring  Real time monitoring of test execution where status and report for each step are presented to users during execution Complementary Tools  Test frameworks should aim “low cost of entry” and hence provide a graphical environment where a test designer can assemble the reusable test constructs for conformance and interoperability tests  In this way, the specialist on standards can easily design test scenarios with elementary knowledge on test description language

11. Nov. 21, 208 CEN/ISSS eBIF GTIB Workshop, Brussels 11 Need for a Test Description Language and Test Expressions A computer interpretable test description language is required for test frameworks to allow dynamic set up of test cases Should also be human readable (so XML based language will be suitable) Should be simple and unambiguous (only representation of operational semantics of test scenarios which has the same interpretation for users, test designers and the test engine) Should have strong and adaptable expression language for data processing (e.g. support XPath, XQuery, XSLT for XML) Utilization of function calls (small data processing scripts)

12. National Health Information System, MoH, Turkey Examination Service Nov. 21, 208 CEN/ISSS eBIF GTIB Workshop, Brussels 12 An Example Scenario for Semantic Tests Internet 11011010 A Hospital Information System HL7-V3 Testing Tool WS SOAP Is it a valid SOAP Message? Does the SOAP header conform to the WS-Security User Name Token Profile? Examination Service Simulator A Semantic Test for the Examination Service Is this a valid HL7 v3 message? (Testing conformance to HL7 v3 XML Scema) 12345 Doe John Are the codes used obtained from the valid code systems? Are the business rules valid? (‘quantity value’ should be numeric and at most two digits) Are the specifications given in the scenario validly reflected in the document? Dear SUT Administrator, You need to follow the requirements given below in this test scenario....... The prescription given to the patient should contain the following data: The medication should be ‘ASPIRIN FORT TABLET 20 TB’ from the "Medications" list code of the "Medications" list being ‘8699504020007’. The quantity should be 1 box; the "period value" should be 1 (meaning in a day); the "doseQuantity" should be 3 and the "routeCode" should be 3 (meaning that the medication should be taken orally"...... Test Scenario Requirements

13. Nov. 21, 208 CEN/ISSS eBIF GTIB Workshop, Brussels13 Thank you for your attention… Questions?