A CONFORMANCE AND INTEROPERABILITY TEST SUITE FOR TURKEY’S NHIS AND AN INTERACTIVE TEST CONTROL AND MONITORING ENVIRONMENT A THESIS SUBMITTED TO THE GRADUATE SCHOOL OF NATURAL AND APPLIED SCIENCES OF MIDDLE EAST TECHNICAL UNIVERSITY BY AL ˙ I ANIL SINACI IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE IN COMPUTER ENGINEERING JUNE 2009
135
Embed
A CONFORMANCE AND INTEROPERABILITY TEST SUITE FOR …etd.lib.metu.edu.tr/upload/12610677/index.pdf · A CONFORMANCE AND INTEROPERABILITY TEST SUITE FOR TURKEY’S NHIS AND AN INTERACTIVE
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
A CONFORMANCE AND INTEROPERABILITY TEST SUITE FOR TURKEY’SNHISAND AN INTERACTIVE TEST CONTROL AND MONITORING ENVIRONMENT
A THESIS SUBMITTED TOTHE GRADUATE SCHOOL OF NATURAL AND APPLIED SCIENCES
OFMIDDLE EAST TECHNICAL UNIVERSITY
BY
AL I ANIL SINACI
IN PARTIAL FULFILLMENT OF THE REQUIREMENTSFOR
THE DEGREE OF MASTER OF SCIENCEIN
COMPUTER ENGINEERING
JUNE 2009
Approval of the thesis:
A CONFORMANCE AND INTEROPERABILITY TEST SUITE FOR TURKEY’S NHIS
AND AN INTERACTIVE TEST CONTROL AND MONITORING ENVIRONMENT
submitted byAL I ANIL SINACI in partial fulfillment of the requirements for the degree ofMaster of Science in Computer Engineering , Middle East Technical University by,
Prof. Dr. CananOzgenDean,Graduate School of Natural and Applied Sciences
Prof. Dr. Muslim BozyigitHead of Department,Computer Engineering
Prof. Dr. Asuman DogacSupervisor,Department of Computer Engineering, METU
Assoc. Prof. Dr. Ahmet CosarCo-supervisor,Department of Computer Engineering, METU
Examining Committee Members:
Prof. Dr. Ismail Hakkı TorosluDepartment of Computer Engineering, METU
Prof. Dr. Asuman DogacDepartment of Computer Engineering, METU
Prof. Dr. Ozgur UlusoyDepartment of Computer Engineering, Bilkent University
Assoc. Prof. Dr. Ahmet CosarDepartment of Computer Engineering, METU
Yıldıray KabakSRDC Ltd.
Date:
I hereby declare that all information in this document has been obtained and presentedin accordance with academic rules and ethical conduct. I also declare that, as requiredby these rules and conduct, I have fully cited and referencedall material and results thatare not original to this work.
Name, Last Name: ALI ANIL SINACI
Signature :
iii
ABSTRACT
A CONFORMANCE AND INTEROPERABILITY TEST SUITE FOR TURKEY’SNHISAND AN INTERACTIVE TEST CONTROL AND MONITORING ENVIRONMENT
Sınacı, Ali Anıl
M.S., Department of Computer Engineering
Supervisor : Prof. Dr. Asuman Dogac
Co-Supervisor : Assoc. Prof. Dr. Ahmet Cosar
June 2009, 118 pages
Conformance to standards and interoperability is a major challenge of today’s applications
in all domains. Several standards have been developed and some are still under development
to address the various layers in the interoperability stack. Conformance and interoperability
testing involves checking whether the applications conform to the standards so that they can
interoperate with other conformant systems. Only through testing, correct information ex-
change among applications can be guaranteed. National Health Information System (NHIS)
of Turkey aims to provide a nation-wide infrastructure for sharing Electronic Health Records
(EHRs). In order to guarantee the interoperability, the Ministry of Health (MoH), Turkey, de-
veloped an Implementation/Integration/Interoperability Profile based on HL7 standards. Test-
BATN - Testing Business Process, Application, Transport and Network Layers - is a domain
and standards independent set of tools which can be used to test all of the layers of the in-
teroperability stack, namely, the Communication Layer, Document Content Layer and the
Business Process Layer.
In this thesis, the requirements for conformance and interoperability testing of the NHIS are
iv
analyzed, a testing approach is designated, test cases for several NHIS services are developed
and deployed, and a test execution control and monitoring environment within TestBATN is
designed and implemented through the identified testing requirements. The work presented
in this thesis is part of the TestBATN system supported by theTUBITAK TEYDEB Project
No: 7070191 in addition by the Ministry of Health, Turkey.
Keywords: conformance testing, interoperability testing, National Health Information System
of Turkey, test suites, automated human-driven testing
v
OZ
TURKIYE ULUSAL SAGLIK B ILGI SISTEMI’N IN UYGUNLUK VE B IRLIKTEISLERLIK TESTLERI VE INTERAKTIF TEST KONTROL VEIZLEME ORTAMI
Sınacı, Ali Anıl
Yuksek Lisans, Bilgisayar Muhendisligi Bolumu
Tez Yoneticisi : Prof. Dr. Asuman Dogac
Ortak Tez Yoneticisi : Doc. Dr. Ahmet Cosar
Haziran 2009, 118 sayfa
Standartlara uygunluk ve birlikte islerlik, gunumuz uygulamaları icin buyuk onem tasımakta-
dır. Birlikte islerlik katmanlarının farklı bolumleriicin gelistirilen bircok standart bulunur.
Uygunluk ve birlikte islerlik testleri, standartlara uygunlugun ve standartlara uygun uygula-
maların birlikte calısıp calısamadıklarının testlerini icerir. Uygulamalar arasındaki iletisimin
dogrulugu ancak test vasıtasıyla garanti edilebilir. T¨urkiye’nin Ulusal Saglık Bilgi Sistemi
(USBS), Elektronik Saglık Kayıtları’nın ulusal olcekte paylasılmasını amaclayan bir altyapı
sunar. Bu altyapı cercevesinde gelistirilmekte olan uygulamaların birlikte islerligini saglamak
amacıyla, T.C. Saglık Bakanlıgı HL7 standartlarına dayalı bir gelistirme/entegrasyon/birlikte
islerlik profili olusturmustur. TestBATN, uygulamaların tanım kumelerinden ve kullanılan
standartlardan bagımsız olarak calısan, birlikte islerlik katmanlarının tumunu - Haberlesme
Katmanı, DokumanIcerik Katmanı veIs Sureci Katmanı - test etme yetisine sahip bir sistem-
ler butunudur.
Bu tez calısmasında, USBS kapsamındaki uygulamaların uygunluk ve birlikte islerlik testleri
icin gereksinim analizi yapılarak bir test metodolojisi gelistirilmistir. Belirlenen metodoloji
vi
uzerinden bircok USBS servisi icin test senaryoları gelistirilmis ve TestBATN dahilinde bir
test kontrol ve izleme ortamı tasarlanmıs ve hayata gecirilmistir. Sunulan altyapı ve gelistirilen
test senaryoları, USBS’deki uygulamaların uygunluk ve birlikte islerlik testlerinde kullanılmıs
ve ulusal captaki entegrasyona buyuk katkı saglamıstır. Bu calısma TUBITAK - TEYDEB,
1507 kapsamındaki B.02.1.TBT.0.06.02.162.01 Sayılı ve “Birlikte Islerlik StandartlarınınIn-
ternet Tabanlı Test Altyapısı-7070191” baslıklı proje dahilinde gelistirilen TestBATN siste-
minin parcasıdır.
Anahtar Kelimeler: uygunluk testleri, birlikte islerliktestleri, Turkiye Ulusal Saglık Bilgi
Sistemi, Saglık-Net, etkilesimli test kumeleri
vii
To my family
viii
ACKNOWLEDGMENTS
I would like to express my sincere gratitude and appreciation to my supervisor, Prof. Dr.
Asuman Dogac for her encouragement, guidance and supportthroughout this study.
I would also like to express gratitude to my co-supervisor, Assoc. Prof. Dr. Ahmet Cosar for
his guidance and support during my study.
I am deeply grateful to my family for their love and support. Without them, this work could
not have been completed.
I am deeply grateful to Tuncay Namlı without whose invaluable guidance and contribution,
this work could not have been accomplished. I am also deeply thankful to Gunes Aluc for his
suggestions and continuous support in the development of the testcases. I am highly indebted
to my friends, Gokce Banu Laleci Erturkmen, Mustafa Yuksel, Yigit Boyar, Atasay Gokkaya
and all the other colleagues at the Software Research and Development Center, whose help,
stimulating suggestions and encouragement helped me at alltimes in this research.
I would like to thank the Scientific and Technological Research Council of Turkey (TUBITAK)
for providing the financial means throughout this study.
Finally, my special thanks go to my friends Andac, Birkal, Ferhat, Goncagul, Hasan Sevki,
Ozgehan, Serife and Zulfukar for their help, support andcheerful presence through the course
of this study. Thanks for giving me a shoulder to lean on whenever I need.
ETSI European Telecommunications Standards Institute
eTSL OASIS Event Driven Test Scripting Language
FMIS Family Medicine Information System
HCRS Health Coding Reference Server
HIS Hospital Information System
HL7 Health Level Seven
MERNIS Central Demographics Management System of Turkey
MHDS Minimum Health Data Set
MoH Ministry of Health, Turkey
NHDD National Health Data Dictionary
NHIS National Health Information System of Turkey
OID Object Identifier
RIA Rich Internet Application
RIM Reference Information Model
SSL Secure Sockets Layer
SUT System Under Test
TDL Test Description Language
xvi
TestBATN Testing Business Process, Application, Transport and Network Layers
TTCN Testing and Test Control Notation
XML eXtensible Markup Language
XPATH XML Path Language
XSD XML Schema Definition
xvii
CHAPTER 1
INTRODUCTION
Today, eBusiness applications are widely adopted by the actors of several industry domains,
governments and the public sector. These intensive relationships between the different appli-
cations belonging to a wide range of domains require standardization in the Communication
Layer, Document Content Layer and the Business Process Layers, which together form the
so-called interoperability stack. In the context of the different implementations of the interop-
erability stack by several different applications, it is still cumbersome to reach interoperability
of the solutions and to achieve conformance to standards addressing the different layers of the
stack. Therefore, the need for advanced testing methodologies and practices which cover
relevant set of standards and specifications is increasing continuously.
Standardized protocols and services, and the applicationsdeveloped through the protocols can
be formally tested in two related but different ways. One way goes through the conformance
testing. Conformance testing depicts whether an application correctly implements a particular
standardized protocol or not. In other words, the testing ofthe conformance shows whether
or not a single implementation of the protocol meets the conformance requirements specified
for that protocol.
When a software instance includes an implementation of a universally standardized protocol,
it becomes possible to specify the test criteria and procedures with a quality comparable to
that of the protocol standards themselves. The protocols may set some rules on several layers
of the interoperability stack and these rules are formally defined through some formal doc-
umentation. XML Schemas may restrict the structure of the content, business profiles may
specify the choreography of the exchanged messages among the parties etc. Therefore, these
formal restrictions form a basis for the testing applicability on that of the softwares which
1
implemented the protocols.
Interoperability is the ability of two or more systems or components to exchange information
and to use the information that has been exchanged [1]. More specifically, interoperability is
said to exist between two applications when one applicationcan accept data (including data
in the form of a service request) from the other and perform the task in an appropriate and
satisfactory manner (as judged by the user of the receiving system) without the need for extra
operator intervention [2].
The purpose of the interoperability testing is to prove thatend-to-end functionality between, at
least, two communicating systems is as by required by the standard or a number of standards
on which those systems are based. However, one should keep inmind that interoperability
tests are applied at the end-points and on the functional interfaces of the applications, that is,
interoperability testing can only specify functional behavior. [3].
In the scope of this thesis, we analyzed the conformance and interoperability testing require-
ments of National Health Information System (NHIS) [4] through the Implementation/Integra-
tion/Interoperability Profile [5] which is published by Ministryof Health (MoH), Turkey.
NHIS provides 25 HL7 [6] based Web services for the use of Family Medicine Information
Systems (FMISs) and Hospital Information Systems (HISs). Throughout the thesis, a compre-
hensive testing methodology is designated and several testsuites and testcases are developed
through the methodology and registered to the TestBATN framework to enable the confor-
mance and interoperability testing of NHIS. Furthermore, to realize the testing process, the
TestBATN Control and Monitoring Environment is designed and implemented.
Health Level Seven (HL7) [6] is a not-for-profit ANSI [7] accredited Standards Developing
Organization. The main purpose of HL7 is to provide standards for the exchange of clinical
and administrative data between healthcare systems. HL7 provides standards for interoper-
ability that improve care delivery, optimize workflow, reduce ambiguity and enhance knowl-
edge transfer among all stakeholders, including healthcare providers, government agencies,
the vendor community, fellow SDOs and patients.
HL7 Clinical Document Architecture (CDA) [8], previously called Patient Record Architec-
ture (PRA), is a document markup standard that specifies the structure and semantics of a
clinical document (such as a discharge summary or progress note) for the purpose of ex-
2
change. A clinical document includes clinical observations and services about care events. A
valid CDA document is encoded in Extensible Markup Language(XML) [9] and conforms to
the CDA Schema which is derived from the CDA Hierarchical Description based on the XML
Implementable Technology Specification.
Saglık-NET is an integrated, secure, fast and extensible information and communication plat-
form that aims to increase the efficiency and quality of the health services in Turkey by col-
lecting the health care related information from the healthcare institutes through the defined
standards and specifications.
National Health Information System of Turkey (NHIS) [4], which is developed under Saglık-
NET, is based on sharing a functional database which is accessible by authorized people and
institutions with defined access rights that covers all the citizens’ health records from the
birth and throughout his/her life on a spine of communication network with high bandwidth
throughout the entire country and using the technologies reaching telemedicine applications
in professional practice [10].
All of the software systems running in the medical institutes in Turkey, the FMISs and HISs,
are obliged to have the ability to transfer EHRs, called “Transmission Schema” instances to
the NHIS servers at the Ministry of Health (MoH) premises. Inorder to guarantee the in-
teroperability, the MoH, published an Implementation/Integration/Interoperability Profile [5]
for FMIS and HIS vendors. The Integration Profile and its reference specifications present all
the restrictions and requirements for vendors to update or develop the necessary components
within their FMISs and HISs for a successful integration. However, without an extensive and
effective testing process this is a difficult job for those vendors. Furthermore, only through
testing, correct information exchange among these eHealthapplications can be guaranteed
and the products can be certified.
Conformance and interoperability testing are both important and useful to the testing of the
applications within NHIS. Conformance testing of the FMISsand HISs can show that those
implementations comply with the requirements of the protocols and specifications asserted in
the Integration Profile of MoH.
In the scope of this thesis, a testing methodology is devisedwhich adopts a “step-by-step”
approach from the basic and simple testcases to the complex ones. Basic testcases include
3
test steps which require the minimum level of assertions according to the Integration Profile.
That is, the FMISs and HISs can apply the basic conformance testcases successfully if they
meet the minimum set of functionalities dictated by the related service’s specifications.
TestBATN Infrastructure
TestBATN
Database
TestBATN
Web Services
TestBATN
Server
NHIS Clients
Detailed
Test
Reports
Test Execution
Platform – Web
based Graphical
User Interface /
TLS
User Account Services
View Old Reports
Test Scenario Selection
NHIS Client
System Administrator
Running Test
Scenario Instances
Fire
wall
TestBATN
Communication Ports
Test ScenarIos
<XML>
Load()
Messaging
Standards
A õz Di Sa!lõ!õ T.S.
Bebek Çocuk "zlem T.S.
Muayene T.S.
Systems Under Test
NHIS Web Services
NHIS Client
TestBATN Kullanıcı Web ArayüzüTestBATN Kullanıcı Web ArayüzüTestBATN Kullanıcı Web ArayüzüTestBATN Kullanıcı Web ArayüzüTest BATN Graphical User InterfaceTest BATN Graphical User Interface
Figure 1.1: TestBATN Architecture within the scope of NHIS
As presented in Figure 1.1, several testcases are developedthrough the designated testing
methodology and registered to the TestBATN framework. The developed testcases are pub-
lished to the FMIS and HIS vendors to enable the online testing of their products. Testcases
are developed in the scripting language, Test Description Language (TDL), of TestBATN and
published to the online use of the clients through the TestBATN Control and Monitoring En-
vironment, which is also a part of this thesis.
TestBATN is a software framework which proposes a design andan execution environment
and applies a specific testing approach for dynamic, configurable and automated execution of
4
conformance and interoperability testing against B2B standards, profiles or specifications.
TestBATN is a comprehensive and integrated system consisting of several components. The
TestBATN Engine is the system which interprets and executesthe testcase definitions, which
are scripted in the Test Description Language (TDL), and manages the whole process. The
TestBATN Control and Monitoring Environment is the interface between the engine and the
Human Test Driver to provide real time monitoring on the testexecution, some control on the
scenario and reporting of the test results. The Human Test Driver, while monitoring the test
execution with TestBATN Control and Monitoring Environment, manages the SUT according
to the instructions shown on the Graphical User Interfaces (GUIs).
TestBATN Control and Monitoring Environment is designed and implemented as Adobe Flex
based Rich Internet Application (RIA) through the scope of this thesis to enable the online and
high speed testing capabilities within the testing of NHIS.The environment also implements
a Test Driving Protocol on the TCP [11] level to interact withthe TestBATN Engine enabling
the high speed, instant communication.
Since June, 2008, the developed testcases are in the online use of the FMIS and HIS vendors,
up to 70 companies with nearly 340 users, on “http://www.srdc.com.tr/testbatn”. Since then,
nearly 20.000 testcase executions are recorded. Apart fromthe online use of the developed
testcases through TestBATN; MoH, Turkey organized two well-attended integration work-
shops. First one of the workshops is organized in Cesme,Izmir during June, 29 - July, 5 2008.
Nearly 130 FMIS/HIS developers from 50 vendor companies attended to Cesmeworkshop
and tested their client applications successfully with thedeveloped testcases registered to the
TestBATN framework.
The testcases within the TestBATN framework are also used inthe second integration work-
shop, which is held in Ankara during December 19 - 21, 2008. 133 attendees from 64 vendor
companies were there to test their FMIS/HIS implementations.
The work presented in this thesis is supported by the TUBITAK TEYDEB Project No: 7070191
in addition by the Ministry of Health, Turkey.
In the rest of the thesis, Chapter 2 gives detailed information about the background technolo-
gies, standards and specifications. Particular segments ofNHIS and TestBATN framework,
the development strategies and enabling technologies are presented in Chapter 2. Chapter 3
5
discusses the testing methodology adopted in the testing ofNHIS. Developed testcases and
example scenarios with the detailed explanations are provided also in Chapter 3. Chapter 4
elaborates the design and implementation issues of TestBATN Control and Monitoring Envi-
ronment. The chapter also gives detailed description of theTest Driving Protocol constructs.
Chapter 5 presents the related work in the testing context. Finally, Chapter 6 concludes the
thesis and discusses the ideas about the future work.
6
CHAPTER 2
BACKGROUND ON ENABLING TECHNOLOGIES AND
STANDARDS
2.1 Materials Used In Testing
Testing process that is being introduced in this thesis derives benefit from several XML [9]
based materials/technologies. Since National Health Information System ofTurkey adopts
XML based standards and TestBATN also uses XML based technologies and languages, the
testing approach of this thesis also follows the means of XMLbased technologies.
XML Schema Definition - XSD
An XML schema is a description of a type of XML documents, typically expressed in terms
of constraints on the structure and content of documents of that type, above and beyond the
basic syntax constraints imposed by XML itself. There are a number of different languages
available for specifying an XML schema. XML Schema Definition [13] is one of those XML
schema languages which provides a means for defining the structure, content and semantics
of XML documents. An XSD schema dictates a set of rules to describe the structure of the
XML documents. An XML document is said to be ‘valid’ according to the XSD schema,
when the XML document conforms the rules dictated by that XSDschema. Those valid
XML documents are called as instances of the schema.
XSD schemas include a set of components, namely the definitions of elements and attributes
of the elements. The elements can be nested and ordered within each other. XSD schema
allows definition of restrictions on the child elements of each element and their attributes.
The data types for elements and attributes are also set through the XSD schemas. More-
7
over, default and fixed values of the elements and attributescan be defined through schema
definitions.
XSD version 1.1 is currently under development by the XML Schema Working Group under
the World Wide Web Consortium (W3C) [14].
XML Path Language - XPATH
XML Path Language, XPath, [15] is a query language for selecting parts of an XML docu-
ment. The primary purpose of XPath is to address the nodes inside an XML document. In
addition to its primary purpose, it also provides basic facilities for manipulation of primitive
data types such as strings, numbers and booleans. XPath usesa compact, non-XML syntax to
facilitate use of XPath within URIs and XML attribute values.
The query methodology adopted by XPath, relies on the tree structure of the XML documents
as well as atomic values such as integers, strings, and booleans, and sequences that may
contain both references to nodes in an XML document and atomic values. That is, XPath
operates on the abstract, logical structure of an XML document, rather than its surface syntax.
In this way, the XML document is processed as a tree of nodes. There are different types of
nodes such as, element nodes, attribute nodes and text nodes. XPath accesses these nodes
with the result of its evaluation.
XPath is based on expressions which can be constructed from keywords, symbols and operands.
XPath enables the nested definition of expressions. The result of an XPath expression consists
of a selection of nodes from the input XML documents without the duplicates and additional
evaluation specific parameters.
There exist two versions of XPath, XPath 1.0 and XPath 2.0. Both of them are Recom-
mendation by W3C. XPath 2.0 provides more powerful constructs than XPath 1.0, however,
currently; XPath 1.0 is more widely accepted in the community.
The Schematron
The Schematron [16] [17] is an XML Schema language which defines the structure, content
and semantics of XML documents by making well-defined assertions about patterns found
in XML documents. The main difference of Schematron from the other schema definition
languages is its basis on the tree patterns residing in the XML document model instead of
8
the grammars. From another perspective, Schematron is a rule based validation language
over the XML documents. Namely, a Schematron file includes a set of XPath-based rules,
which correspond to the assertions, to test the presence and/or absence of patterns in XML
tree models.
The Schematron is comparatively stronger in the structuralvalidation of the instance docu-
ments because of its rule-based system. It checks the patterns existing in the XML documents’
tree models against the rules asserted through the Schematron language. This process includes
XSL Transformations [18] one after another. Schematron also enable the error messages ex-
pressed in natural language which will come up during the validation phase. This makes error
detection much easier than the cryptic error codes. On the other hand, Schematron has weak-
nesses against the other schema definition languages. Due toits rule-based nature, it can be
very complex to specify the basic structure and content definition with a set of rules. There-
fore, combining the use of the Schematron with another schema definition language, such as
XSD, induces a good solution.
The Schematron is an ISO (the International Organization for Standardization) [19] standard.
It has been standardized to become part of ISO/IEC ISO/IEC 19757 - Document Schema
Definition Languages (DSDL) - Part 3: Rule-based validation- Schematron.
2.2 Enabling Technologies
Testing process requires use of specific software to test theoperations of the client programs
and utilities automatically. TestBATN constitutes a testing system behaving as an application
server. NHIS clients need to communicate with TestBATN engine for the testing of their
application programs. Enabling this through the Internet,based on Rich Internet Application
technologies, is the main purpose of the testing approach ofthis thesis.
Rich Internet Applications (RIAs)
Rich Internet Applications (RIAs) are web applications, accessible through web browsers,
which are carrying characteristics of the regular desktop applications. To describe the benefits
of Rich Internet Applications, understanding the early internet applications plays an important
role. As the computers started to be interconnected, World Wide Web came up and static
9
web pages evolved within the well-known client-server architectures. In these very early
systems, the clients interact with the server through HTTP [20] and HTML [21]. The primary
technology in creating Internet applications is HTTP, which is simple, ubiquitous, requires no
special tools. The clients send HTTP requests to the application servers and the servers return
static HTML pages to the clients in this model. This early static model is mostly concerned
with the presentation. Since there is no dynamism and interactivity, the only process is the
rendering of the HTML data and to present it to the user looking at the browser.
Dynamic web pages showed up since the static client-server model did not satisfy the chang-
ing user and system requirements. Several server side scripting languages and web frame-
works evolved and enabled the dynamic creation of web pages.The examples of server-side
scripting languages are PHP [22], ASP.NET [23], JSP [24], ColdFusion [25] and other lan-
guages. The dynamism of this model is also based on the HTTP and HTML technologies
with synchronous communication over TCP [11]. The application server creates dynamic
HTML pages upon the request coming from the clients. Dynamiccreation of the web pages
has brought interactivity in the interaction with the end-users. On the other hand, client-side
scripting has also evolved to enhance the interactivity at the presentation level on the user
web browsers. Client-side scripting languages like JavaScript [26] or ActionScript [27] are
frequently used to orchestrate media types (sound, animations, changing text, etc.) of the
presentation.
The Internet age evolves very fast and this evolution pushesthe Internet users to demand more
sophisticated and increasingly interactive web sites. Synchronous client-server model within
an “ask-response” manner, relies on the server for processing, requires refreshment of content
pages and communication through HTTP - HTML bundle at each user request. This, results
in a lot of redundant data being transferred, increasing wait times for clients, and giving a
start and stop feel within the web pages due to their multi-page interfaces. With the very
successful increases in the speed of modern computers and increasing accessibility to broad-
band internet services, users are demanding more from web-based applications. Therefore, to
meet the today’s Internet users’ requirements, there is a need for more efficient and effective
communication methodologies between the user browsers andapplication servers. Further-
more, friendlier and more esthetic graphical interfaces are needed to satisfy the users than the
HTML whose main purpose is just the presentation of data rather than the development of
and “RemoveRunningTestCaseInstance” messages) the RIA when any change oc-
curs about the running instances of the testcase which is requested lastly by the
RIA.
Repeatability:
Yes; it can be sent to the TestBATN server at each user request.
Figure 4.11: Model of RequestRunningTestCaseInstances
Interaction: AddRunningTestCaseInstance
80
Description:
This message construct is used after the RIA sends “RequestRunningTestCaseIn-
stances” message to the TestBATN server. The server sends “AddRunningTetCase-
Instance” message to the RIA if any instance of the testcase indicated by the lastly
sent “RequestRunningTestCaseInstance” message is created by any other SUT ad-
ministrator online in the TestBATN framework.
Sender Responsibilities:
TestBATN server prepares the content of the message, which is the information
about the running instance of the testcase, and sends to the RIA client.
Receiver Responsibilities:
The RIA, that is the GUI running in the browser of the SUT administrator, updates
the presentation of the related parts when any “AddRunningTestCaseInstance” mes-
sage arrives.
Repeatability:
Yes. This message can be sent from the TestBATN server to the RIA when any
testcase instance is started execution.
Figure 4.12: Model of AddRunningTestCaseInstance
Interaction: UpdateRunningTestCaseInstance
Description:
81
After the realization of the interaction, “RequestRunningTestCaseInstances”, the
TestBATN server sends this message to the RIA when any changeoccurs on the
testcase execution instace which was previously sent to theRIA client by the “Ad-
dRunningTestCaseInstance” message. For example, if a new SUT attends to a run-
ning testcase instance by occupying a testcase party, this change is sent to the RIA
clients who previously sent “RequestRunningTestCaseInstances” to the TestBATN
Server about the testcase in question.
Sender Responsibilities:
TestBATN server sends this message to the corresponding RIAclients when any
change occurs on the executing testcase instances.
Receiver Responsibilities:
The RIA updates the corresponding GUI part when receives this message.
Repeatability:
Yes; the server sends this message for each change on the executing testcase in-
stance.
Figure 4.13: Model of UpdateRunningTestCaseInstance
Interaction: RemoveRunningTestCaseInstance
Description:
82
This message is sent from the TestBATN server to the RIA clients when any test-
case execution terminates. The server sends the message to the RIA clients who
previously sent “RequestRunningTetCaseInstances” for a testcase definition.
Sender Responsibilities:
When a testcase ends up, the server sends this message to the RIA clients who
previously sent “RequestRunningTestCaseInstances” message for that testcase.
Receiver Responsibilities:
The RIA updates the necessary parts of the GUI upon receptionof this message.
Repeatability:
Yes; when any running testcase instance terminates, the message is sent to the cor-
responding RIA clients. Creation of this message is agnostic to the reason behind
the termination of the testcase.
Figure 4.14: Model of RemoveRunningTestCaseInstance
Interaction: TerminateSession
Description:
This message is sent from the RIA client to the TestBATN server when the SUT
administrator wants to logout. It can be seen as the oppositeof the “InitiateSession”
message for dropping the handshake between the both sides.
Sender Responsibilities:
Test Control and Monitoring Environment must send the message through the RIA
client to the TestBATN server for each logout process.
Receiver Responsibilities:
The server clears the session information from the internalsystem and handles the
configuration parameters of the user and the testcases executed by that user.
83
Repeatability:
No.
Figure 4.15: Model of TerminateSession
4.2.2 Test Execution
SUT administrator selects the testcase party to actor through the testcase after selecting the
testcase from the “Filtered Testcases” section as shown in Figure 4.16. Afterwards, the user
clicks on the “Execute” button to proceed to start the testcase execution.
Figure 4.16: Testcase Selection and Execution
According to the underlying Test Driving Protocol, when theuser clicks on the “Execute” but-
ton, the RIA sends “LoadTestCase” interaction message to the TestBATN server. Figure 4.17
presents the messaging choreography between the TestBATN Control and Monitoring Envi-
ronment RIA and the TestBATN server starting from loading a testcase and ending with the
start of the execution of the testcase. In the following sections, the steps of this chorepgrahy
are described and the intermediate interactions are explained in detail.
Interaction: LoadTestCase
Description:
84
Figure 4.17: Execution of a Testcase
This message is sent from the RIA to the TestBATN server to load a testcase to be
executed.
Sender Responsibilities:
RIA sends this message to the server when the SUT administrator selects the test-
case and presses the “Execute” button from the GUI.
Receiver Responsibilities:
TestBATN server loads the specified testcase to the memory and sends the descrip-
tion of the testcase and the configuration information to theRIA.
Repeatability:
No. It cannot be repeated until the RIA sends the “ReleaseTestCasePorts” message.
Upon receiving a “LoadTestCase” message, the server sends the description of the loaded
testcase, “TestCaseDescription”, to the RIA client. The RIA pops up a new window and
shows the description of the testcase to the SUT administrator. This description includes the
testing steps of the loaded testcase and their brief explanations.
85
Figure 4.18: Model of LoadTestCase
Interaction: TestCaseDescription
Description:
TestBATN server sends the description of the testcase to be executed to the RIA.
Figure 4.19: Model of TestCaseDescription
Sender Responsibilities:
TestBATN server should prepare the testcase for the execution, assign a unique
identifier to the execution instance and send this information to the RIA.
Receiver Responsibilities:
86
RIA should present the description to the SUT administrator. The SUT adminis-
trators not only see the steps of the testcase but also learn the details and rules that
they must apply into their messages. This process increasesthe awareness of the
FMIS/HIS developers about the standards and specifications dictated through the
Integration Profile.
Repeatability:
No.
Right after sending the “TestCaseDescription”, the serversends “HandleConfiguration” to the
RIA to configure the network related details between the parties of the testcase.
Figure 4.20: Handling Configuration
TestBATN Control and Monitoring Environment RIA lists the “HandleConfiguration” infor-
mation defined inside the testcase. RIA presents this information in a user-friendly GUI
window to the SUT administrator as shown in Figure 4.20. For each communication that
87
will occur through the testcase execution, there must be a configuration handling part defined
inside the testcase definition. This configuration includesthe management of the IP (Internet
Protocol) addresses and the port numbers of the parties taking role through the testcase. That
is, in Figure 4.20, the SUT administrator only enters its IP address information as the Initiat-
ing Party because, for that case, the SUT administrator plays the “USBSIstemci” role which
is the NHIS client. The Responding Party is the NHIS simulation, which is the TestBATN
server. The port number of the TestBATN is important since the SUT administrator must con-
figure its software to send the “Transmission Schema” instance to the specified port number
on the IP address of the TestBATN server, the Responding Party.
Interaction: HandleConfiguration
Description:
For all communication lines defined in the testcase, there must be corresponding
configuration information. TestBATN server asks this configuration information
from the SUT administrator by means of this interaction.
Figure 4.21: Model of HandleConfiguration
Sender Responsibilities:
88
TestBATN server should manage the configuration data for each testcase party sep-
arately and ask the required data from the SUT administrators through TestBATN
Control and Monitoring RIA.
Receiver Responsibilities:
RIA should present this information to the SUT administrator and ask for the related
data fields conveniently. Upon user’s answers, RIA should prepare the “HandleCon-
figurationResponse” message to be sent to the TestBATN server.
Repeatability:
No.
SUT administrator fills in all the configuration related information and clicks on the “Send”
button. RIA prepares and sends a “HandleConfigurationResponse” message to the TestBATN
server.
Interaction: HandleConfigurationResponse
Description:
This is the response of “HandleConfiguration” message including the filled in data
by the SUT administrator.
Figure 4.22: Model of HandleConfigurationResponse
89
Sender Responsibilities:
RIA must fill the corresponding fields of the message with the gathered information
from the SUT administrator.
Receiver Responsibilities:
TestBATN server finalizes the configuration of the testcase after receiving this mes-
sage from all participating parties of the testcase.
Repeatability:
No.
TestBATN server executes the testcase one step forward after collecting all configuration in-
formation from the related parties of the testcase. This step is the handling of the preliminary
data if defined inside the testcase. If there is no defined preliminary data, the server sends the
“SendTestSteps” message directly and the RIA behaves accordingly.
As shown in Figure 4.23, RIA maintains a list of the preliminary data sent within the “Han-
dlePreliminaryTestData” interaction.
Figure 4.23: Handling Preliminary Data
Through the GUI, the user enters or views the preliminary test data information settled in
the testcase definition. After the SUT administrator fills inthe requested information through
“HandlePreliminaryTestData” interaction, RIA sends thisinformation to the TestBATN server
with the “FilledInPreliminaryData” interaction.
Interaction: HandlePreliminaryTestData
90
Description:
This interaction exists to enable the semantic and functional testcases describe in
Chapter 3.
Sender Responsibilities:
TestBATN server processes the preliminary data fields defined inside the testcase
and creates the necessary structures.
Receiver Responsibilities:
RIA lists the preliminary data fields to the user and enables afriendly GUI to make
the SUT administrator correctly fill the requested information. As a response to this
message, RIA should prepare the corresponding “FilledInPreliminaryData” mes-
sage and send to the server.
Repeatability:
No.
Figure 4.24: Model of HandlePreliminaryTestData
Interaction: FilledInPreliminaryData
Description:
This is the response of the “HandlePreliminaryTestData” interaction.
91
Sender Responsibilities:
RIA must correctly prepare and set the corresponding data fields inside message
upon the SUT administrator inputs.
Receiver Responsibilities:
TestBATN server maintains a pool for the preliminary information collected from
the parties of the testcase. If any “UpdatePreliminaryTestData” interaction is re-
quired to notify a user, the server should prepare the message and send it to the
corresponding party/parties.
Repeatability:
No.
Figure 4.25: Model of FilledInPreliminaryData
In some testcase definitions, the test designer may create a test scenario in which the parties
exchange information at the preliminary test data phase. For example, a one party may need
information throughout the testcase execution which will be asked from another party. When
the responder sends the information with “FilledInPreliminaryData” to the TestBATN server,
the server checks whether any party is waiting for the retrieved preliminary data or not. If there
exist a party, “UpdatePreliminaryTestData” interaction is used to notify the SUT administrator
92
for the updated value of the preliminary data field.
Interaction: UpdatePreliminaryTestData
Description:
Testcases defined among multiple parties may need exchange of preliminary infor-
mation between the parties. When a party sends “FilledInPreliminaryData” to the
server, it is sent to the waiting party, if exist, with this message.
Sender Responsibilities:
TestBATN server must wait for the completion of all “FilledInPreliminaryData”
interaction and assignments of all the preliminary data variables.
Receiver Responsibilities:
RIA must present the user any update on the preliminary information upon the
reception of this message.
Repeatability:
No.
Figure 4.26: Model of UpdatePreliminaryTestData
As presented in Figure 4.17, after receiving all “FilledInPreliminaryData” interaction mes-
93
sages from the attending parties of the testcase, TestBATN server sends “UpdatePreliminary-
TestData” to the parties, if there is any party waiting for. Afterwards, the server sends the
details of the test steps of the testcase to the attending parties.
Figure 4.27 shows the snapshot of the GUI at after the “SendTestSteps” interaction is com-
pleted from the server to the RIA. SUT administrator can see the details of each test step,
the test assertions which will be processed throughout the testcase execution and other details
about the testcase.
Figure 4.27: Test Steps View
Interaction: SendTestSteps
Description:
After the completion of the configuration management prior to the testcase execu-
tion, TestBATN server becomes ready to execute the scenarioand sends this mes-
sage to the RIA client to inform the SUT administrators aboutthe details of the test
steps.
Sender Responsibilities:
TestBATN server constructs the test steps through a convenient structure to be pre-
sented to the SUT administrator by the TestBATN Control and Monitoring RIA.
94
Receiver Responsibilities:
TestBATN Control and Monitoring RIA processes the receivedtest steps and
presents to the user as shown in Figure 4.27.
Repeatability:
No. For each testcase execution, this message is sent to eachRIA client only once.
Figure 4.28: Model of SendTestSteps
TestBATN server sends the test steps to all parties of the testcase. Now, everthing is ready
to start the execution of the testcase. To start this process, the parties of the testcase must all
agree on the “StartTest” interaction. That is, all parties must send the “StartTest” message to
the TestBATN server.
Interaction: StartTest
Description:
SUT administrator clicks on the “Start Test” button as shownin Figure 4.27. Test-
BATN Control and Monitoring RIA prepares and sends this message to the Test-
BATN server.
95
Sender Responsibilities:
RIA must send the message to the server upon user request by clicking on “Start
Test” button.
Receiver Responsibilities:
TestBATN server waits for the “StartTest” message from all the parties of the test-
case to start the execution of the testcase.
Repeatability:
No. A testcase can only be started once.
Figure 4.29: Model of StartTest
TestBATN server starts processing on the teststeps of the testcase one by one because all
parties of the testcase agreed on the “StartTest”. Figure 4.30 shows the message choreog-
raphy between the TestBATN server and TestBATN Control and Monitoring RIA just after
the “StartTest” interaction until the testcase terminatestotally with “ReleaseTestCasePorts”
interaction.
When the server completes the execution of a teststep, it sends the result and the report of
that teststep to the SUT administrators through TestBATN Control and Monitoring RIA. This
notification is done through “UpdateTestStatus” interaction. RIA presents the changes on the
status and results of the teststeps to the SUT administrator. Figure 4.31 shows the snapshot
of the environment at the time of testcase execution. The server processes each teststep and
sends the result to the RIA client immediately. Since the underlying Test Driving Protocol
functions in high speed, SUT administrator sees the changesinstantly on the GUI.
“UpdateTestStatus” interaction not only carries the result and status information about the
96
Figure 4.30: At the time of test execution
teststep, but informs the SUT administrator about the report of the execution of that teststep.
As presented in Figure 4.32, TestBATN Control and Monitoring RIA presents the test step
reports to the SUT administrator when clicked on the corresponding button appearing on the
teststep status view section. For example, the report in thefigure says that execution of the
corresponding teststep has ended up with “FAIL” result. Thevalidation adaptor which has
created the report is the “xpathadaptor” adaptor. The reported error is about the Username -
Token profile usage inside the SOAP header. The password fieldof the token does not match
with the previously provided value through preliminary data handling.
Interaction: UpdateTestStatus
Description:
After the execution of each teststep, TestBATN server sendsthis message to the
RIA clients to update the status, result and report of the corresponding teststep on
the GUI of SUT administrators.
Sender Responsibilities:
97
Figure 4.31: Teststep Status Changes
TestBATN server must monitor the execution of the teststepsand send this message
to all attending testcase parties when the processing of each teststep ends.
Receiver Responsibilities:
TestBATN Control and Monitoring RIA is responsible for updating the correspond-
ing view components to notify the SUT administrator about the changes.
Repeatability:
Yes. For each update on each teststep, this message is created and sent to the RIA
clients.
Semantic and functional testing capabilities of TestBATN include a mechanism to ask some
questions to the SUT administrator at the time of execution of the testcase. These questions
are asked through the “AskTestData” interaction and the answers of the SUT administrator
are carried back to the server through “AskTestDataResponse” interaction.
Interaction: AskTestData
Description:
98
Figure 4.32: Teststep Report
Figure 4.33: Model of UpdateTestStatus - I
99
Figure 4.34: Model of UpdateTestStatus - II
If defined in the testcase, this message is created and sent from the TestBATN server
to the RIA to ask the questions indicated in the testcase to the SUT administrator.
Sender Responsibilities:
TestBATN server must create and send this message to the corresponding user’s
RIA when encounters an “AskTestData” construct of Test Description Language.
Receiver Responsibilities:
TestBATN Control and Monitoring RIA pops up a window to ask the questions and
gather the responses from the SUT administrator.
Repeatability:
Yes. Throughout the testcase definition, for each “AskTestData” construct of TDL,
this message is sent to the corresponding RIA client.
Interaction: AskTestDataResponse
Description:
This is the reponse of “AskTestData” returned from the RIA tothe TestBATN server.
Sender Responsibilities:
TestBATN Control and Monitoring RIA should correctly set the fields inside the
message according to the SUT administrator’s answers.
100
Figure 4.35: Model of AskTestData
Receiver Responsibilities:
TestBATN server runs the asserted operations on the responses of the SUT admin-
istrator as settled through the testcase definition.
Repeatability:
No. This message can only be sent as a response of “AskTestData” interaction.
If “AskTestData” repeats, “AskTestDataResponse” messagealso repeats as a re-
sponse.
Figure 4.36: Model of AskTestDataResponse
101
SUT administrator has a chance to stop the execution of the testcase and quit to the main page
of the TestBATN Control and Monitoring GUI at any time. This operation is handled through
the “FinishTest” interaction which is sent from the RIA to the TestBATN server when the
SUT administrator clicks on the “Terminate Test” button.
Interaction: FinishTest
Description:
This message indicates that SUT administrator wants to quitthe execution of the
testcase.
Sender Responsibilities:
RIA must send this message to the TestBATN server when the SUTadministrator
clicks on “Terminate Test” or “Log out” button.
Receiver Responsibilities:
TestBATN server processes this message and informs the other parties of the test-
case about the termination of the execution through the “TestCaseProcessingFin-
ished” interaction. If any of the parties of the testcase terminates the testcase, it
terminates for all of the parties.
Repeatability:
No.
Figure 4.37: Model of FinishTest
Interaction: TestCaseProcessingFinished
Description:
102
This message is sent from the TestBATN server to the RIA clients who are executing
the testcase in question at that time to to inform them about the termination of the
testcase.
Sender Responsibilities:
TestBATN server sends this message to the testcase parties when the tetscase fin-
ishes normally by executing all teststeps or one of the parties terminates the execu-
tion of the testcase in the interoperability tests.
Receiver Responsibilities:
RIA notifies the user by popping up an information window about the termination
and the final report of the testcase.
Repeatability:
No. This message is sent only once to the RIA client to indicate the termination of
the execution.
Figure 4.38: Model of TestCaseProcessingFinished
After the execution of a testcase terminates, the SUT administrators are informed with this
event and the TestBATN Control and Monitoring RIA behaves accordingly by updating the
views of the user as seen in Figure 4.39. When the user clicks on the “Restart” button, RIA
sends the “RestartTestCase” message to the TestBATN serverto restart the execution of the
testcase with the already configured parameters. The GUI returns to the preliminary data
handling state to enable the SUT administrator to change theentered values. If the SUT ad-
ministrator wants to go back to main page to select another testcase or do any other operation,
“Go Back” button is clicked. With this user event, RIA sends the “ReleaseTestCasePorts”
message to the TestBATN server.
Interaction: RestartTestCase
Description:
103
Figure 4.39: Restart of a Testcase
With this message, RIA realizes the re-execution of the lastly executed testcase with
the same configuration parameters.
Sender Responsibilities:
TestBATN Control and Monitoring RIA must give the choice of restarting the test-
case to the SUT administrator as shown in 4.39.
Receiver Responsibilities:
TestBATN server must keep the configuration information of the testcase even if it
is terminated until the “ReleaseTestCasePorts” message isreceived from the RIA.
Repeatability:
Yes. A testcase execution can be repeated with the same configuration parameters
as much as requested by the SUT administrator.
Figure 4.40: Model of RestartTestCase
Interaction: ReleaseTestCasePorts
Description:
104
When the SUT administrator does not want to re-execute the testcase, he/she clicks
on “Go Back” button as shown in Figure 4.39. This message, then, is sent to the
TestBATN server to reset the configuration parameters of thelastly executed test-
case by the user to free the occupied ports and other intermediates.
Sender Responsibilities:
TestBATN Control and Monitoring RIA must provide the choiceof going back to
the main page of the environment to the SUT administrator.
Receiver Responsibilities:
TestBATN server deletes the configuration information of the testcase and releases
the occupied ports.
Repeatability:
No.
Figure 4.41: Model of ReleaseTestCasePorts
During the interaction between TestBATN server and TestBATN Control and Monitoring En-
vironment, if any internal error occurs in the TestBATN server it is reported to the RIA clients
through the “GUIInteractionError” interaction.
Interaction: GUIInteractionError
Description:
This message is sent from the TestBATN server to RIA clients of all parties of the
testcase in case of an internal error.
Sender Responsibilities:
Errors occurred inside the TestBATN server are caught and sent to the RIA clients
with convenient reports.
Receiver Responsibilities:
105
Figure 4.42: Model of GUIInteractionError
TestBATN Control and Monitoring RIA is responsible to handle the presentation
issues when this message is received. The error report is shown to the user and the
state of the view is arranged according to the termination issues.
Repeatability:
Yes. At each time any error occurs, this message is sent from the server to the
clients.
106
CHAPTER 5
RELATED WORK
While e-business scenarios are widely adopted by the users in industry, governments and the
public sector, it is still cumbersome for them to reach interoperability of eBusiness solutions
and to achieve conformance with standards specifications. Therefore, the need for advanced
testing methodologies and practices which cover relevant set of standards is increasing con-
tinuously.
There are a number of research, development and even standardization efforts on testing
methodologies, test tools, languages and frameworks.
Testing and Test Control Notation (TTCN) [72] is one of the first and most successful work
on test automation published by the European Telecommunications Standards Institute (ETSI)
[78]. The latest version, TTCN-3 is a computationally complete and internationally standard-
ized programming language for expressing test cases for conformance and interoperability
testing in the telecommunication domain.
Telecommunication networks use many heterogenic protocols between multiple system nodes,
with dedicated configuration and application data. Ensuring the interoperability of the com-
ponents within such systems, across different vendor platforms and countries require testing
the network components accurately. For this purpose, ETSI has developed methodologies for:
• conformance testing for checking the compliance of isolated components of the telecom-
munication networks, to the protocol standards
• interoperability testing to verify the ability of network components from different ven-
dors to operate in real conditions
107
ETSI provides a number of publicly available TTCN-3 test suites such as Digital Mobile
Radio (DMR), digital Public Mobile Radio (dDMR), Dynamic Host Configuration Protocol
(DHCPv6), IPv6, IP Multimedia Subsystem (IMS), Voice Over IP with the Session Initiation
Protocol (SIP), and the upcoming WiMax test suite.
Since the telecommunications domain is concerned with the low level issues by nature, TTCN
test suites and testing methodologies also focuses on the low level details of the communica-
tion. As a result, it does not fully represent the business processes that mostly the concern of
the high level standards such as the ones used in NHIS. Furthermore, TTCN does not provide
any interactive, human-driven test framework. The test suites are static and for each test sce-
nario and for each client to be tested, specialized code fragments are needed to be developed
prior to the test scenario executions.
OASIS IIC ebXML Test Framework [79] is a test framework enabling conformance and inter-
operability testing for ebXML specifications. The framework includes an architecture design
based on components that can be combined and distributed in different ways, to accommodate
different test harnesses. It also includes an extensible test scripting language for coding test
suites in an executable way. In other words, it describes a test bed architecture and its software
components as well as how these can be combined to create a test harness for various types
of testing [69].
OASIS IIC ebXML Test Framework is totally based on ebXML messaging; therefore, it fo-
cuses on its Message Service Handler (MSH) implementationsinstead of application testing.
Although the specification says that the framework has support for external plug-ins, it would
not be possible to test NHIS services through this frameworknot only due to the need of
those external plugins which enable the processing of HL7 based messages through the Web
services profile but also the lack of an interactive, human-driven test control and monitoring
environment.
OASIS Event Driven Test Scripting Language (eTSL) [80], which is currently a work in
progress, improves OASIS IIC ebXML Test Framework by addressing the different layers
of the interoperability stack, namely, the messaging infrastructure, the messaging choreogra-
phies and the business document standards. eTSL is a model and language for eBusiness/
eGovernment test suites, with a particular focus on communication events, versatile usage
for the Quality Assurance testing phase as well as the monitoring of deployed systems, and
108
extensible design to leverage specialized validation processors as well as XML tools such as
XPath [15], XSLT [18] and XQuery [81].
NIST B2B Testbed [82] project includes a sample implementation of OASIS IIC ebXML Test
Framework v1.1. NIST B2B Testbed is initiated by the National Institute of Standards and
Technology [83] to develop software tools which can be used to test current B2B standards or
technologies and enhance the capabilities for on-demand demonstration of conformance and
interoperability [84].
TestBATN is a superior testing framework than the OASIS and ETSI frameworks with the
added value of the TestBATN Control and Monitoring Environment, presented in Chapter
4, which enables the human-driven test cases. Indeed, in theTestBATN framework an ex-
tended version of the event notion of eTSL is provided which helps capture the requirements
of the test scenarios encountered in the testing of NHIS. These requirements include inter-
action with the users of a System Under Test (SUT), using external evaluation services, and
allowing human validation during test execution. Furthermore, preliminary test steps such
as configuration management and test data initialization have been included in the test execu-
tion of TestBATN. This functionality is critical in the sense that it allows the test framework to
adapt itself to the requirements of the applications under test, rather than the opposite. Finally,
the TestBATN framework provides an extensible and layered platform for design, execution
and life cycle management of the test scenarios to handle thedynamically evolving testing
requirements through the TestBATN Control and Monitoring Environment.
There are also some eHealth specific tools for the conformance testing. HL7 Message Maker
[85] is an initiative administered by HL7 together with NIST[83] to automatically and dy-
namically generate test messages for eHealth applications. The data used to populate the mes-
sages is drawn from a number of sources including the NIST developed database of HL7 data
items, HL7 tables, user tables, and external tables. This initiative focuses on the document
content layer within the interoperability stack. Testing of NHIS requires the test assertions
through the whole layers of the interoperability stack since the Integration Profile includes
several standards and specifications targeting to the different layers of the stack.
IHE provides a detailed implementation and testing processto promote the adoption of stand-
ards-based interoperability by vendors and users of healthcare information systems. The
process is named as Connect-a-thon, a weeklong interoperability-testing event. Managing
109
a Connect-a-thon is a human labor intensive task. Most of themessaging is conducted by
the humans such as checking message contents or applicationbehaviours. Connect-a-thons
require the physical aggregation of the software components and the administrators of those
softwares for a week through a set of workshops. However, theTestBATN framework pro-
vides the TestBATN Control and Monitoring Environment for the automated execution of the
test cases. Therefore, testing of NHIS would be a very complex operation through several
Connect-a-thon organizations.
110
CHAPTER 6
CONCLUSION AND FUTURE WORK
The final outcome of this thesis enabled the conformance and interoperability testing of the
applications developed within the National Health Information System (NHIS) of Turkey.
Nearly all of the Family Medicine Information System (FMIS)and Hospital Information
System (HIS) vendors somehow tested their implementationsthrough TestBATN with the
testcases developed in the scope of this thesis.
Specifications, standards and the Implementation/Integration/Interoperability Profile of the
Ministry of Health (MoH), Turkey, are analyzed and the requirements to enable the testing
of the system are put on the map. According to the identified testing requirements, a test-
ing methodology is designated which follows a test procedure ranging from the basic con-
formance tests to the complex semantic and functional tests. In respect to the designated
testing methodology, several testcases; such as basic conformance testcases, customized con-
formance testcases, interoperability testcases, and testcases for the query, update and delete
methods of the NHIS services and a number of semantic testcases for the NHIS services in
question are developed and registered to the TestBATN framework.
Considering the testing requirements of NHIS, TestBATN Control and Monitoring Environ-
ment is designed and implemented within the scope of this thesis. The environment realized
a human-driven testing infrastructure. Developing a Rich Internet Application as the Graphi-
cal User Interface to the FMIS/HIS administrators and implementing a Test Driving Protocol
provided a comprehensive, user-friendly, simple and high speed control and monitoring envi-
ronment for the TestBATN users.
As mentioned earlier, NHIS servers located at the MoH premises has been accepting “Trans-
mission Schema” instances since November, 2008. As of January 15, 2009, all healthcare
111
institutes have to send the actual, real patient EHR data to NHIS servers with the announce-
ment of governmental regulations.
Currently, nearly all of the state hospitals of Turkey are able to successfully send the daily
EHR messages, which are the “Transmission Schema” instances to the NHIS servers. Uni-
versity hospitals and primary care institutions are continuously boosting up their integration
capabilities with Saglık-Net.
Up to 70 companies with nearly 340 users have been testing their systems through the devel-
oped testcases through “http://www.srdc.com.tr/testbatn” since June, 2008 as mentioned ear-
lier in the thesis. Since then, approximately 20.000 testcase executions are recorded. Not only
the developed testcases through TestBATN was availbale online, but also two well-attended
integration workshops were organized in Turkey. The first one was in Cesme,Izmir during
June, 29 and July, 5, 2008. This workshop has provided various opportunities to nearly 130
FMIS/HIS developers from 50 vendor companies about testing theirapplications successfully
with the developed testcases. The second workshop was held in Ankara during December 19
- 21, 2008. 133 attendees from 64 vendor companies were thereto test their implementations.
Together with the continuous online use of the developed testcases through TestBATN and
the integration workshops organized by the MoH, in which thedeveloped testcases through
TestBATN were also used, increased the integration capabilities of the FMISs and HISs de-
veloped for NHIS. The feedbacks coming from the vendor companies, the statistics of the
ongoing integration and the representatives of the Ministry of Health confirm the contribution
of the TestBATN framework and the comprehensive testcases to the integration skills of the
client applications. Furthermore, the testcases and the user-friendly, high speed TestBATN
Control and Monitoring Environment increased the awareness of the software companies, es-
pecially in the health sector of Turkey, in the international standards, their use in real life
etc. This process has also revealed the importance of the adoption of international standards
within such integration efforts, like NHIS.
The work presented in this thesis is supported by the TUBITAK TEYDEB Project No: 7070191
in addition by the Ministry of Health, Turkey.
NHIS is collecting the Electronic Health Records (EHR) to the central servers located at the
MoH premises, currently. The use of this data is for statistical purposes for now. However,
112
the ongoing process is going towards the integration of the hospitals within each other. That
is, in the near future, the goal is to enable the sharing of theEHRs among the hospitals
instead of only collecting to the center. This process requires further profiles and business
models and more intensive interoperability capabilities.TestBATN can easily be used in the
testing of these interoperability capabilities of the FMISs and HISs. New testcases for the
interoperability scenarios can be developed and online useof the TestBATN framework can
enable the joint test executions without requiring the software applications’ coming together
“physically”.
Furthermore, TestBATN can be used to certify the client applications within NHIS to assure
their conformance and interoperability skills and enable amore intact and accurate integra-
tion.
113
REFERENCES
[1] IEEE Dictionary, Institute of Electrical and Electronics Engineers. IEEE Standard Com-puter Dictionary: A Compilation of IEEE Standard Computer Glossaries, New York,1990.
[2] Brown and Reynolds, “Strategy for production and maintenance of standards for in-teroperability within and between service departments andother healthcare domains”,CEN/TC 251 Health Informatics, CEN/TC 251/N00-047.
[3] ETSI EG 202 237, Methods For Testing and Specification. http://portal.etsi.org/mbs/-Referenced%20Documents/eg 202 237.pdf, last visited on June 2009.
[4] e-Transformation in Health. Department of InformationProcessing, Min-istry of Health, Turkey. http://www.saglik.gov.tr/EN/Tempdosyalar/533 e-transformationinhealth07.pdf, last visited on June 2009.
[5] Ulusal Saglık Bilgi Sistemi/Saglık-NET Entegrasyonu ileIlgili Genelge 2008/18. http://-www.saglik.gov.tr/TR/MevzuatGoster.aspx?F6E10F889 2433CFF1A9547B61DAFFE-2A56515916B329A1F1, last visited on June 2009.
[6] Health Level 7. http://www.hl7.org/, last visited on June 2009.
[7] American National Standards Institute (ANSI). http://www.ansi.org/, last visited on June2009.
[8] Clinical Document Architecture (CDA), Release 2. http://www.hl7.org/v3ballot/html/-infrastructure/cda/cda.htm, last visited on June 2009.
[9] Extensible Markup Language (XML). http://www.w3.org/XML /, last visited on June2009.
[10] Mustafa Yuksel, Sharing Electronic Healthcare Records Across Country Borders, Mas-ter’s thesis, Middle East Technical University, Department of Computer Engineering,Ankara, Turkey, 2008.
[11] Transmission Control Protocol (TCP). http://www.faqs.org/rfcs/rfc793.html, last visitedon June 2009.
[12] Namli T., Aluc G., Sinaci A., Kose I., Akpinar N., Gurel M., Arslan Y., Ozer H., YurtN., Kirici S., Sabur E., Ozcam A., Dogac A. Testing the Conformance and Interoperabil-ity of NHIS to Turkey’s HL7 Profile 9th International HL7 Interoperability Conference(IHIC) 2008, Crete, Greece, October, 2008, pp. 63-68.
[13] XML Schema Definition (XSD). http://www.w3.org/XML /Schema, last visited on June2009.
[14] World Wide Web Consortium. http://www.w3.org/, last visited on June 2009.
114
[15] XML Path Language (XPath). http://www.w3.org/TR/xpath, last visited on June 2009.
[16] The Schematron. http://xml.ascc.net/resource/schematron/, last visited on June 2009.
[17] The Schematron. http://www.schematron.com, last visited on June 2009.
[18] XSL Transformations (XSLT). http://www.w3.org/TR/xslt, last visited on June 2009.
[19] International Organization for Standardization. http://www.iso.org, last visited on June2009.
[20] HyperText Transfer Protocol (HTTP). http://www.w3.org/Protocols/, last visited on June2009.
[21] HyperText Markup Language (HTML). http://www.w3.org/TR/REC-html40/, last vis-ited on June 2009.
[22] PHP. http://www.php.net/, last visited on June 2009.
[23] ASP.NET White Papers. http://www.asp.net/Learn/whitepapers/, last visited on June2009.
[24] Java Server Pages Technology - White Paper. http://java.sun.com/products/jsp/-whitepaper.html, last visited on June 2009.
[25] ColdFusion Datasheets and White Papers. http://www.adobe.com/products/coldfusion/-whitepapers/, last visited on June 2009.
[26] JavaScript on Wikipedia. http://en.wikipedia.org/wiki /JavaScript, last visited on June2009.
[27] ActionScript on Wikipedia. http://en.wikipedia.org/wiki /ActionScript, last visited onJune 2009.
[28] Farrell, Jason. “Rich Internet Applications: The NextStage of ApplicationDevelopment”. Online. Available: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&-arnumber=4283806&isnumber=4283720
[29] Adobe Flex. http://www.adobe.com/devnet/flex/, last visited on June 2009.
[30] Adobe Flash. http://www.adobe.com/products/flash/, last visited on June 2009.
[31] Java Web Start. http://java.sun.com/javase/technologies/desktop/javawebstart/index.jsp,last visited on June 2009.
[32] Java Network Launch Protocol (JNLP). http://jcp.org/en/jsr/detail?id=056, last visitedon June 2009.
[33] JavaFX. http://javafx.com/, last visited on June 2009.
[34] Ajax. http://www.ajax.org/, last visited on June 2009.
[35] Cascading Style Sheets (CSS). http://www.w3.org/Style/CSS/, last visited on June 2009.
[36] Document Object Model (DOM). http://www.w3.org/DOM/, last visited on June 2009.
115
[37] XML User Interface Language (XUL). http://www.mozilla.org/projects/xul/, last visitedon June 2009.
[38] Adobe Flash Player. http://www.adobe.com/products/flashplayer/, last visited on June2009.
[39] SWF. http://www.adobe.com/devnet/swf/, last visited on June 2009.
[40] ECMAScript. http://www.ecma-international.org/publications/standards/Ecma-357.htm, last visited on June 2009.
[42] Cairngorm White Paper. http://www.adobe.com/devnet/flex/articles/-introducingcairngorm/introducing cairngorm.pdf, last visited on June 2009.
[43] Cairngorm Micro-architecture Diagram. http://www.cairngormdocs.org/-cairngormDiagram/cairngorm2rpc.swf, last visited on June 2009.
[44] H. Zimmermann. OSI Reference Model - The ISO Model of Architecture for OpenSystems Interconnection. IEEE Transactions on Communications. COM-28: 425-432,1980.
[45] HL7 Message Development Framework, Version 3.3, December 1999. http://-www.hl7.org/Library/MDF99/MDF99doc.zip, last visited on June 2009.
[46] HL7 Reference Information Model. http://www.hl7.org/v3ballot/html/infrastructure/-rim/rim.htm, last visited on June 2009.
[47] The National Health Data Dictionary (NHDD) of Turkey. http://-www.sagliknet.saglik.gov.tr/portal pages/notlogin/bilisimciler/docs/-usvssozluk 1.1.rar, last visited on June 2009.
[48] HL7 Hierarchical Message Description (HMD). http://www.hl7.org/v3ballot/html/help/-v3guide/v3guide.htm#v3ghmd, last visited on June 2009.
[49] HL7 Vocabulary. http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/-vocabulary.htm, last visited on June 2009.
[50] HL7 Data Types - Abstract Specification. http://www.hl7.org/v3ballot/html/-infrastructure/datatypes/datatypes.htm, last visited on June 2009.
[51] HL7 Refinement, Constraint and Localization, Release 2. http://www.hl7.org/v3ballot/-html/infrastructure/conformance/conformance.htm, last visited on June 2009.
[52] HL7 Version 3 Standard: Transport Specifications Overview. http://www.hl7.org/-v3ballot2008may/html/infrastructure/transport/transport-intro.htm, last visited on June2009.
[53] HL7 Version 3 Standard: Transport Specification - ebXML, Release 2. http://-www.hl7.org/v3ballot/html/infrastructure/transport/transport-ebxml.htm, last visited onJune 2009.
116
[54] HL7 Version 3 Standard: Transport Specification - Web Services Profile, Release 2.http://www.hl7.org/v3ballot/html/infrastructure/transport/transport-wsprofiles.htm, lastvisited on June 2009.
[55] Transport Specification: Minimal Lower Layer Message Transport Protocol(MLLP), Release 2. http://www.hl7.org/v3ballot/html/infrastructure/transport/transport-mllp.htm, last visited on June 2009.
[56] Web Services Description Language (WSDL). http://www.w3.org/TR/wsdl, last visitedon June 2009.
[57] List of Web service specifications on Wikipedia. http://en.wikipedia.org/wiki /-List of Web servicespecifications, last visited on June 2009.
[58] Kabak Y., Dogac A., Kose I., Akpinar N., Gurel M., ArslanY., Ozer H., Yurt N., OzcamA., Kirici S., Yuksel M., Sabur E. The Use of HL7 CDA in the National Health In-formation System (NHIS) of Turkey. 9th International HL7 Interoperability Conference(IHIC) 2008, Crete, Greece, October 2008.
[59] Kose I., Akpinar N., Gurel M., Arslan Y., Ozer H., Yurt N., Kabak Y., Yuksel M., Do-gac A. Turkey’s National Health Information System (NHIS).In the Proceedings of theeChallanges Conference, Stockholm, October 2008.
[60] The Health Coding Reference Server 2. http://sbu.saglik.gov.tr/SKRS2%5FListesi/, lastvisited on June 2009.
[61] International Statistical Classification of Diseasesand Related Health Problems, 10thRevision (ICD-10), Second Edition. Technical Report, World Health Organization,Geneva, Switzerland. http://www.who.int/whosis/icd10/, last visited on June 2009.
[62] Information technology – Metadata registries (MDR) – Part 4: Formulation of data def-initions, (ISO/IEC 11179-4).
[63] Doctor Data Bank. http://sbu.saglik.gov.tr/drBank/, last visited on June 2009.
[64] Web Services Security: SOAP Message Security 1.1 (WS-Security 2004). OASISStandard Specification. http://www.oasis-open.org/committees/download.php/16790/-wss-v1.1-spec-os-SOAPMessageSecurity.pdf, last visited on June 2009.
[65] Generation and registration of Universally Unique Identifiers (UUIDs) and theiruse as ASN.1 Object Identifier components. Open Systems Interconnection, Inter-national Telecommunication Union. http://www.itu.int/ITU-T/studygroups/com17/oid/-X.667-E.pdf, last visited on June 2009.
[66] MERNIS, Central Demographics Management System. http://www.nvi.gov.tr/-Hakkimizda/Projeler,MernisGenel.html?pageindex=4, last visited on June 2009.
[67] Saglik-Net Business Rules. Ministry of Health. http://www.sagliknet.saglik.gov.tr/-portal pages/notlogin/bilisimciler/docs/SaglikNET is Kurallari BRMS.pdf, last visitedon June 2009.
[68] Scientific and Technological Research Council of Turkey (TUBITAK), TEYDEBProject No: 7070191.
117
[69] Namli T., Aluc G., Dogac A. An Interoperability Test Framework for HL7 based Sys-tems IEEE Transactions on Information Technology in Biomedicine Vol.13, No.3, May2009, pp. 389-399.
[70] ETSI Plugtests. http://www.etsi.org/WebSite/OurServices/plugtests/home.aspx, last vis-ited on June 2009.
[71] Connectathon Fact Sheet. http://www.ihe.net/Connectathon/upload/-NA 2008 ConnectathonFactSheet1.pdf, last visited on June 2009.
[72] ETSI TTCN-3. http://www.ttcn-3.org/StandardSuite.htm, last visited on June 2009.
[73] Simple Mail Transfer Protocol (SMTP). http://www.ietf.org/rfc/rfc0821.txt, last visitedon June 2009.
[74] OASIS ebXML Message Service Specification (ebMS). http://www.oasis-open.org/-committees/ebxml-msg/documents/ebMS v2 0.pdf, last visited on June 2009.
[75] Minimum Health Data Sets (MHDS). http://www.sagliknet.saglik.gov.tr/portal pages/-notlogin/bilisimciler/docs/msvs semalari.rar, last visited on June 2009.
[76] The ebXML Test Framework and the Challenges of B2B Testing. http://-ebxmltesting.nist.gov/xmleurope/xmleurope.html, last visited on June 2009.
[77] Integrating the Healthcare Enterprise (IHE). http://www.ihe.net/, last visited on June2009.
[78] Europen Telecommunications Standard Institute (ETSI). http://www.etsi.net/WebSite/-homepage.aspx, last visited on June 2009.
[79] OASIS ebXML Test Framework v1.0. http://www.oasis-open.org/committees/-download.php/10896/IIC ebXMLTestFrameworkv1.1 10 11 04 final draft.zip, lastvisited on June 2009.
[80] Event-driven Test Scripting Language (eTSL), OASIS ebXML Implementation Interop-erability and Conformance (IIC) TC, Working Draft 0.85. http://www.oasis-open.org/-committees/download.php/26036/eTSL-draft-085.pdf, last visited on June 2009.
[81] XML Query Language (XQuery). http://www.w3.org/TR/xquery/, last visited on June2009.
[82] NIST Manufacturing Business to Business (B2B) Interoperability Testbed. http://-www.mel.nist.gov/msid/b2btestbed/, last visited on June 2009.
[83] National Institute of Standards and Technology (NIST). http://www.nist.gov/, last vis-ited on June 2009.
[84] B. Kulvatunyou, N. Ivezic, M. Martin, A. T. Jones, A BusinesstoBusiness Interoperabil-ity Testbed: An Overview, ACM International Conference Proceeding Series; Vol. 50,Proceedings of the 5th international conference on Electronic commerce, 2003.
[85] HL7 Message Maker. http://www.itl.nist.gov/div897/ctg/messagemaker/, last visited onJune 2009.