Download Document

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
Nov. 21, 208
CEN/ISSS eBIF GTIB Workshop, Brussels
1
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
Nov. 21, 208
CEN/ISSS eBIF GTIB Workshop, Brussels
2
Interoperability Stack
INTEROPERABILITY STACK
Integrati
on
Profiles
Document Layer
Business Process
Layer
Communication
Layer
Industry Specific XML Schemas: HL7 v3 Messages, HL7 CDA, CEN
EHRCom, UBL, OAGIS, ...
Non-XML Content: HL7 v2 Messages (EDI), X12, DICOM (Medical
Imaging)
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)
Choreography/Business Process Standards: WSCDL, ebBP
Quality of Service Protocols: WS-Reliability, WS-Security, WS-Addresing
Higher Level Messaging Protocols: SOAP, ebMS, ...
Transport Protocols: HTTP, SMTP, MLLP, ...
(e.g. IHE,
NES UBL)
or
Technica
l
Specifica
tions
(National or
Regional
Health
Networks:
e.g. USA
NHIN,
NICTIZ,
Saglik-NET)
Foreseen requirements…

A Test Execution Model

Which is capable of testing different scenarios
using different standards at each layer




Nov. 21, 208
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
CEN/ISSS eBIF GTIB Workshop, Brussels
4
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
Nov. 21, 208
CEN/ISSS eBIF GTIB Workshop, Brussels
5
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
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, 208
CEN/ISSS eBIF GTIB Workshop, Brussels
7
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, 208
CEN/ISSS eBIF GTIB Workshop, Brussels
8
Foreseen requirements…

Further automation (preliminary steps)


Automation of configuration management
Presenting the scenario to SUT admins (information entities in the
scenario)



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


“A patient whose name is John Doe visits doctor Mary in 2008-10-13. The
main diagnosis identified after the examination is Bronchitis…”
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, 208
CEN/ISSS eBIF GTIB Workshop, Brussels
9
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, 208
CEN/ISSS eBIF GTIB Workshop, Brussels
10
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)
Nov. 21, 208
CEN/ISSS eBIF GTIB Workshop, Brussels
11
An Example Scenario for Semantic Tests
Test
Scenario
Are the codes
used
obtained from
Requirements
the valid code
systems?
WS SOAP
Dear SUT Administrator,
Does the SOAP header conform to
the WS-Security User Name Token
Profile?
<given>
this test scenario.
Is this a valid HL7 v3 message?
(Testing conformance to HL7 v3
XML Scema)
Are the business rules
valid?
HL7-V3
(‘quantity
value’
should
<patient>
You
need
to followbe
thenumeric
and at most
two<id>
digits)
</id>
requirements
given
below in
</given>
<family> given
</family>
specifications
in the
</patient>
Are the
scenario......
validly reflected in the
......
document?
12345
John
Is it a valid SOAP Message?
The prescription given to the
patient should contain the following
data: The medication should be
11011010
‘ASPIRIN FORT TABLET 20 TB’
from the "Medications" list code of
the "Medications" list being
Internet
‘8699504020007’. The quantity
should be 1 box; the "period
value" should be 1 (meaning in a
day); the "doseQuantity" should
Doe
be 3 and the "routeCode" should
be 3 (meaning that the medication
should be taken orally"
Examination
Examination
A Semantic
Service
Service
Test for the
Simulator NationalExamination
Health
Service
Information
System,
Testing
Tool
MoH, Turkey
A Hospital
......
......
Information
System
Nov. 21, 208
CEN/ISSS eBIF GTIB Workshop, Brussels
12
Thank you for your attention…
Questions?
Nov. 21, 208
CEN/ISSS eBIF GTIB Workshop, Brussels
13