Prof. Dr. Asuman Dogac Dept. of Computer Eng. Middle East Technical University Ankara, Turkey

1. CEN/ISSS eBIF Global eBusiness Interoperability Test Bed Methodologies ProjectSome 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 CEN/ISSS eBIF GTIB Workshop, Brussels

2. Interoperability Stack CEN/ISSS eBIF GTIB Workshop, Brussels • 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 Integration Profiles (e.g. IHE, NES UBL) or Technical Specifications (National or Regional Health Networks: e.g. USA NHIN, NICTIZ, Saglik-NET) INTEROPERABILITY STACK Industry Specific XML Schemas: HL7 v3 Messages, HL7 CDA, CEN EHRCom, UBL, OAGIS, ... Non-XML Content: HL7 v2 Messages (EDI), X12, DICOM (Medical Imaging) Document Layer Terminologies/Coding Systems: LOINC, UNSCSP, ISO 3166 ... Business Rules (e.g by using schematrons) Specifications with Diagrams: e.g. IHE(Actor/Transaction Diagrams,Sequence Diagrams) , NES UBL (Activity Diagrams), HL7 (Sequence Diagrams) Business Process Layer Choreography/Business Process Standards: WSCDL, ebBP Quality of Service Protocols: WS-Reliability, WS-Security, WS-Addresing Communication Layer Higher Level Messaging Protocols: SOAP, ebMS, ... Transport Protocols: HTTP, SMTP, MLLP, ...

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 codedbecause 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 CEN/ISSS eBIF GTIB Workshop, Brussels

5. Foreseen requirements… CEN/ISSS eBIF GTIB Workshop, Brussels 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. Foreseen requirements… CEN/ISSS eBIF GTIB Workshop, Brussels • 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. Foreseen requirements… CEN/ISSS eBIF GTIB Workshop, Brussels • 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. Foreseen requirements… CEN/ISSS eBIF GTIB Workshop, Brussels • 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. Foreseen requirements… CEN/ISSS eBIF GTIB Workshop, Brussels • 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. Need for a Test Description Language and Test Expressions CEN/ISSS eBIF GTIB Workshop, Brussels 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. An Example Scenario for Semantic Tests Test Scenario Requirements Are the codes used obtained from the valid code systems? Is it a valid SOAP Message? WS SOAP 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 1box; 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" ...... ...... Does the SOAP header conform to the WS-Security User Name Token Profile? Are the business rules valid? (‘quantity value’ should be numeric and at most two digits) HL7-V3 <patient> <id> </id> <given> </given> <family> </family></patient> Is this a valid HL7 v3 message? (Testing conformance to HL7 v3 XML Scema) Are the specifications given in the scenario validly reflected in the document? 11011010 Internet Examination Service Examination Service Simulator A Semantic Test for the Examination Service Testing Tool 12345 National Health Information System, MoH, Turkey Doe John A Hospital Information System CEN/ISSS eBIF GTIB Workshop, Brussels

13. Thank you for your attention…Questions? CEN/ISSS eBIF GTIB Workshop, Brussels