Nov. 21, 208CEN/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 FrameworksProf. Dr. Asuman Dogac

Dept. of Computer Eng.Middle East Technical University

Ankara, Turkey

Nov. 21, 208CEN/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

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 LayerNon-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)

Integration Profiles(e.g. IHE, NES

UBL)

or

Technical Specificati

ons(National or

Regional Health

Networks: e.g. USA

NHIN, NICTIZ, Saglik-NET)

Integration Profiles(e.g. IHE, NES

UBL)

or

Technical Specificati

ons(National or

Regional Health

Networks: e.g. USA

NHIN, NICTIZ, Saglik-NET)

Interoperability Stack

Nov. 21, 208CEN/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

Nov. 21, 208CEN/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

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

Nov. 21, 208CEN/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)

Nov. 21, 208CEN/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

Nov. 21, 208CEN/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

Nov. 21, 208CEN/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

Nov. 21, 208CEN/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)

National Health Information System,MoH, Turkey

Examination Service

Nov. 21, 208CEN/ISSS eBIF GTIB Workshop,

Brussels 12

An Example Scenario for Semantic Tests

Internet

11011010

A Hospital Information System

HL7-V3 <patient> <id> </id> <given> </given> <family> </family></patient>

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 ScenarioRequirements

Nov. 21, 208CEN/ISSS eBIF GTIB Workshop,

Brussels 13

Thank you for your attention…

Questions?