Certification of Service-oriented eHealth Platforms
Derivation of Structured Criteria for Interoperability and Expandability
Martin Benedict, Martin Burwitz and Hannes Schlieter
Chair of Wirtschaftsinformatik, esp. Systems Development, Dresden University of Technology, Dresden, Germany
Keywords: Certification, eHealth, Service-oriented Platforms, Interoperability, Expandability, Extensibility.
Abstract: Certification of interoperability is an important quality measure, which can foster the success of eHealth
projects. Often these projects test and certify interoperability for specific purposes. The achievement of
long-term interoperability is often not in the scope of these projects. In this paper we describe the im-
portance of expandability for the long-term interoperability. Further we show, how a structured criteria cata-
logue for the certification process can be derived for these two quality factors.
1 INTRODUCTION
1.1 Certification of eHealth Solutions
in Integrated Care Regions
More and more complex and expensive therapies as
well as quality issues of localized care due to a
shortage of healthcare professionals are typical is-
sues the healthcare is faced with. Furthermore, the
need for cost efficiency is a challenge that has to be
mastered by the healthcare systems in Europe. One
important influencing factor for this development is
the demographic change, which leads to more mor-
bidity (Gröne and Garcia-Barbero, 2001). In Germa-
ny for example, in the rural areas the average age of
the population is rising while the availability of
primary and secondary care decreases (Greß and
Stegmüller, 2011, pp. 11, 14, 20). To face these
problems an often-discussed approach is the estab-
lishment of integrated care. The goal is to enhance
the quality and efficiency of patient treatment and
the patients quality of life, in particular for patients
having complex and long-term health problems,
which are treated by multiple healthcare providers.
The result of the integration of multiple healthcare
providers is called “integrated care” (Kodner and
Spreeuwenberg, 2002). Several players must work
together in different subjects. Gröne and Garcia-
Barbero notice that this integration of players is
significantly driven by telemedical technologies on
different layers of granularity (citizen, professional
teams, health care systems) (Gröne and Garcia-
Barbero, 2001). Telemedical projects aim to im-
prove the communication between actors in the
healthcare. Several regional telemedical projects in
Germany have been initiated in the last years (e.g.
see (Plischke et al., 2014), (Audebert et al., 2004)).
When implementing telemedical platforms
communication standards can foster interoperability
by defining a language that can be interpreted by
different information systems. However, eHealth-
platforms usually aim to implement a specific subset
of a communication standard, e.g. to share patients
demographics data. Later in the lifetime of such
platforms new data exchange needs may become
important and new implementers want to implement
services based on platforms. Thus, an interoperable
eHealth-platform with many participators has to be
flexible concerning new requirements and technolo-
gies – it must be sustainable. In particular, if it is
designed as a basic infrastructure, which allows
implementing services by 3
rd
-party developers, re-
quirements exist, which have not been recognized
yet. These aspects are addressed by the term ex-
pandability. Risks that affect expandability may
arise from complex extensibility mechanisms, pro-
prietary interfaces, expensive business models and
lock-in effects (Hilley, 2009). To counter these risks
conformity assessment through a neutral party can
be an appropriate method (Sunyaev and Schneider,
2013). The attestation from the third-party assess-
ment is called certification (DIN Deutsches Institut
für Normung e.V., 2005, p. 17).
To sum up, risks affecting the interoperability
and expandability of an eHealth-platform can be
countered by methods of certification. When de-
114
Benedict M., Burwitz M. and Schlieter H..
Certification of Service-oriented eHealth Platforms - Derivation of Structured Criteria for Interoperability and Expandability.
DOI: 10.5220/0005221401140122
In Proceedings of the International Conference on Health Informatics (HEALTHINF-2015), pages 114-122
ISBN: 978-989-758-068-0
Copyright
c
2015 SCITEPRESS (Science and Technology Publications, Lda.)
scribing a certification method as an artifact, one
part will be a structured catalogue of criteria. It ena-
bles a measurable and objective determination of
properties that has to be fulfilled by a certification
subject to achieve a high degree of the quality fac-
tors. However, when we started to design the arti-
fact, it was not clear how to achieve criteria that
indicate the factor achievement. In this paper, we
focus on the question how criteria that measure the
degree of interoperability and expandability of
eHealth solutions can be determined. Therefore the
following subquestions are formulated:
(I) What is the role of interoperability and ex-
pandability for an eHealth-platform?
(II) How can criteria be determined, that allows
an evaluation of these quality factors?
We aim to design a framework, which defines
layers of interoperability that are connected with
quality factors. First we describe how interoperabil-
ity and expandability are interrelated and that ex-
pandability is a necessity for interoperability in a
long-term view. We discuss actual interoperability
models of European studies concerning interopera-
bility certification. Third we propose a framework,
which allows a structured derivation of conformity
criteria based on interoperability models. We con-
tribute to the evaluation of platform expandability,
by showing that these interoperability layers can also
be useful to structure conformity criteria. Finally, for
demonstration purposes, we present a resulting crite-
ria catalogue, which was defined in a specific pro-
ject.
1.2 Demonstration
In an EU-funded project a regional healthcare plat-
form for Eastern Saxony is developed. The main
objective of this project is to improve the care of
patients in rural and structurally weak areas. One
important objective to the platform is, that it must be
open and allows 3
rd
-party providers to implement
projects based on the platform or to connect their
own software with the central platform.
The original vision according to this objective is
to provide an infrastructure for future healthcare
projects in saxony. The platform hides the technical
eHealth-infrastructure and allows project initiators to
focus more on issues of intersectoral care and less on
technical issues. Health solution implementers can
use it as a framework for the development of innova-
tive eHealth solutions. Obstacles in project initia-
tions should be reduced by the platform.
Additional, three sample projects are developed
initially for the platform (see figure 1). These sample
applications and the platform are certification ob-
jects. In this paper, we refer to the platform to
demonstrate the defined certification scheme and to
describe the principles of the proposed criteria mod-
el. The certification of the platform should verify,
whether the vision is achieved by the implementa-
tion of the platform. The certification of applications
determines whether the applications are using the
components of the platform as intended. This is
intended to steer the growth of the ecosystem around
the basic platform.
2 RELATED WORK
Existing works in the field of eHealth-certification
addresses mainly the requirements of the users con-
cerning electronic health records rather than to ad-
dress the openness as a factor for 3rd-party develop-
ers as an enhancer of functionality and quality of;
Figure 1: Scheme of the platform infrastructure and the description of the three sample applications.
CertificationofService-orientedeHealthPlatforms-DerivationofStructuredCriteriaforInteroperabilityand
Expandability
115
service (De Moor et al., 2008; Hörbst et al., 2009;
Hörbst and Ammenwerth, 2010a). Furthermore
existing approaches focus primarily on the interop-
erability between eHealth-systems (Hörbst and
Ammenwerth, 2010b; Toroi et al., 2007). Evaluation
of interoperability in the context of eHealth is well
operationalized by testing systems and procedures,
e.g. the IHE Connectathon (IHE Europe, 2014) or
the ONC HIT Certification Program (Office of the
National Coordinator for Health Information Tech-
nology, 2012) are based on computerized testing
routines. There exists also a set of studies concern-
ing eHealth interoperability and testing of interoper-
ability in Europe (HITCH - Healthcare Interopera-
bility Testing and Conformance Harmonization,
Antilope - Advancing eHealth Interoperability,
EHR-Q, etc.), which face the problem of how a
certification of eHealth services can be disseminated
in a harmonized European way. However, it is hard-
er to find some work that explicitly faces expanda-
bility (or its synonym extensibility) of eHealth sys-
tems (no results for “allintitle: ehealth expandabil-
ity” or “extensibility” at Google Scholar). One ex-
planation for this gap could be that eHealth-systems
are interpreted as monolithic systems by the certifi-
cation approaches.
Independent from the eHealth-domain, there are
some approaches that define a component based
view of software (Alvaro et al., 2005). These certifi-
cation approaches focus on the reuse of individually
certified software components. 3
rd
-party providers
primary play the role of component deliverers. Alva-
ro differentiates between two ages of certification:
the age of mathematical and test-based models and
the age of techniques and models that predicts quali-
ty requirements (Alvaro et al., 2005). The evaluation
methods in current eHealth certification programs
can be assigned to the first age.
3 METHODS
3.1 Interoperability and Expandability
and Their Impact to eHealth-
Platforms
Existing quality factor models systematize different
aspects of software quality to dedicated quality fac-
tors. These factors represent a specific set of attrib-
utes that a software product has to fulfill (e.g. main-
tainability, usability, etc.). An often-cited model is
the factor model of McCall, which contains eleven
quality factors. This model contains an interoperabil-
ity quality factor and a flexibility factor. A specific
attribute, which is assigned to the flexibility factor,
is expandability (McCall et al., 1977). The factor
model from Deutsch and Willis describes expanda-
bility as a dedicated factor (Galin, 2004, p. 45).
However, interoperability and expandability are
defined as follows:
IEEE defines interoperability as “the ability of
two or more systems or components to ex-
change information and to use the information
that has been exchanged” (IEEE, 1990, p. 42).
Expandability is the ability to adapt to future
requirements resulting from enhancements in
functionality, broadening of service to new
target groups and improvements in service and
usability (Galin, 2004, p. 45).
Expandability and interoperability are interrelated.
Expandability is a necessary prerequisite for in-
teroperability. Interoperability can be given for a
specific snapshot of a system. This system, for ex-
ample, might be able to communicate with an unre-
stricted set of systems for a specific purpose (e.g.
sharing lab results). Hörbst and Ammenwerth identi-
fied that this purpose-specific view when defining
interoperability requirements could be found often in
literature (Hörbst and Ammenwerth, 2010a, p. 329).
According to the same system, in a long term view,
the interoperability maybe worse, if new needs for
information exchange emerge and the system can’t
be extended to fulfill these needs. This dependency
is depicted in figure 2.
The degree of interoperability is defined by the
quotient of the number of electronic implemented
information exchanges and the number of require-
ments that specify the need for electronic infor-
mation exchange. If a system has a worse expanda-
bility the reaction time span between a new require-
ment regarding information exchange and its fin-
ished implementation is very long. Meanwhile other
new requirements can come up and reduce the de-
gree of interoperability more and more. An expand-
able system can react to new requirements very
quickly. The time span between event and measure
is much smaller, when the expandability is good.
It may be argued that interoperability is given, if
the system considers all future information exchange
needs by implementing all known interoperability
standards. Apart from the impracticability of this
approach even in this case, interoperability is only
given for a specific set of information exchange
needs that is considered by the implemented interop-
erability standards at a specific point in time. If there
are new communication partners (e.g. a new authori-
HEALTHINF2015-InternationalConferenceonHealthInformatics
116
Figure 2: Dependency between the degree of interoperability and the degree of expandability accumulated over time.
ty was implemented) or new communication needs
(e.g. new measure methods that lead to new data
structures) which aren’t considered in existing
standards, the interoperability is reduced to the in-
teractions defined by the existing standards. Fur-
thermore, it is difficult to predict which of the im-
plemented interoperability functions are really need-
ed. This could lead to excessive efforts with small
solution-relevant outcome.
In the opposite direction expandability can be
improved by a good interoperability. If an eHealth
platform has well-organized interoperability mecha-
nisms, for example established and well documented
data models taken from interoperability standards,
the implementation of platform extension is facili-
tated. 3
rd
-party implementers for example can reuse
already implemented interfaces to connect to exist-
ing platform components.
3.2 Structuring with Interoperability
Layers
An often-used approach to structure the view on
interoperability between two or more systems, is to
describe a layered model defining layers of interop-
erability. There are existing interoperability frame-
works, which are dedicated to the structuring of
eHealth interoperability. One is the eHealth Europe-
an Interoperability Framework (eEIF). It defines
four layers of interoperability: legal, organizational,
semantic and technical interoperability (European
Commission and Deloitte & Touche, 2013, p. 14).
Another three-layer model containing an Applica-
tion, Logical and Technical Layer (ALT-Model) is
defined by the HITCH-project. Additionally an or-
ganizational layer is mentioned, but not considered
in the model (Coorevits et al., 2011, p. 12). The
Antilope project synthesizes different interoperabil-
ity models, inter alia the eEIF interoperability mod-
el. It defines the following layers of interoperability:
Legal and Regulatory, Policy, Care Process, Infor-
mation, Applications, IT Infrastructure (van Pelt and
Sprenger, 2013, p. 11). The Antilope model is the
newest of the three described models. For a detailed
explanation of the several models we refer to the
mentioned references. We selected the ALT-model
as basis of our framework. In the following, the
layers are defined in the context of conformity as-
sessment and it is shown, how they can be matched
to the Antilope interoperability model. Even if the
organizational layer is not in the scope of the ALT-
model, the framework considers it.
Organizational Layer: A conformity assessment
on the organizational layer has to ensure, that the
platform provider and the 3
rd
-party implementer
conforms to a legal and organizational context,
which allows an information exchange or a compre-
hensive use of provided functionality. Compared to
HITCH’s organizational layer, which focuses on
quality of care, in this paper the organizational Layer
focuses on measures between the platform provider
and the 3
rd
-party implementer. Indirectly this also
aims at quality of care, because those measures en-
sure a seamless handling of care aspects. In the An-
tilope interoperability model this layer is referenced
by “Legal and Regulatory” and “Policy”.
Application Layer: On this layer, it must be en-
sured that platform provider and 3
rd
-party imple-
menters are able to support integrated care process-
es. HITCH addresses presentation and functionality
at this layer. This must support the care process. In a
conformity assessment, it must be assured, that the
functionality for the interaction between platform
and third party products is given. In the Antilope
me
degree
of
interoperability
(IO)
best
reachable
IO
event
changes
needs
of
informa on
exchange
(new
requirement)
fin
i
she d
measure
to
Improve
interoperability
(reac on
to
event)
degree
of
interoperability
with
worse
degree
of
expandability
no
IO
good
expandability
worse
expandability
degree
of
interoperability
with
good
degree
of
expandability
good
expandability
good
expandability
#1
#2
#3
#1
#2
#1
#3
reac on
me
span
CertificationofService-orientedeHealthPlatforms-DerivationofStructuredCriteriaforInteroperabilityand
Expandability
117
interoperability model this layer conforms to “Care
Process”, but with the view to a concrete system as a
certification subject, which has to support this pro-
cess.
Logical Layer: This layer aims at concepts and
principles that have to be understood by 3
rd
-party
implementers and the platform providers. This layer
can be associated with the ANTILOPE-layers “In-
formation” and “Application”. On this layer it must
be evaluated, whether concepts specified by a stand-
ard, technical rules or by the platform are imple-
mented in a transparent way and whether they are
interpretable by the both stakeholders. On this layer
also the design decisions of the platform and imple-
mentation of those decisions has to be evaluated.
Technical Layer: On this layer, it must be evalu-
ated that the both sides abide technical framework
conditions. This focuses on technical specifications
and on the transparency and right use of implemen-
tation mechanisms. This layer is associated with the
Antilope interoperability layers “Application” and
“IT Infrastructure”.
3.3 Framework to Structure the Crite-
ria Catalogue
Existing certification approaches describe criteria for
existing interoperability functions but not for the
extension of interoperability. Our proposed frame-
work addresses this methodological gap. Figure 3
illustrates our framework.
A bilateral view is the foundation of the frame-
work. On the one hand, there is the platform, which
provides interoperability and expandability mecha-
nisms and on the other hand there is a 3
rd
-party im-
plementer, which wants to add new components to
the platform or to interconnect his own product with
the platforms interoperability mechanisms. The two
quality factors are interconnected with the layers of
the ALT-model from HITCH. Even if the ALT-
model doesn’t specify the organizational layer in
detail (Coorevits et al., 2011, p. 13), we use this
layer in the model to describe organizational aspects
concerning the conformity assessment. For example
the contracting is an organizational aspect. The se-
lection of the layer models is driven by the following
factors that refer to resulting criteria catalogues:
expected volume of the resulting catalogue
expected complexity and practicability of the
use of the criteria in an evaluation processes
expected ability of formalization of the result-
ing criteria
expected precision of the resulting criteria
The intersection of a quality factor and an in-
teroperability layer describes an aspect that has to be
evaluated in an assessment process. The question
marks identify that these points have to be specified
in detail. One important use of these intersections is
to categorize the different certification criteria. A
criterion defines a requirement that a system has to
fulfill in a verifiable way. Other instances of this
interconnection-model can help to describe the sub-
jects of certification and the certification methods. In
HITCH the least is already done for the interopera-
bility quality factor.
Figure 3: Scheme for the assignment of criteria to the quality factors of expandability and interoperability.
HEALTHINF2015-InternationalConferenceonHealthInformatics
118
The bilateralism is depicted by the “matching”-
arrows. The certification of the platform expandabil-
ity is the opponent of the certification of implemen-
tation conformance of a 3
rd
-party implementer.
These two pillars address the risks mentioned in the
introduction of this paper. The implementer of the
platform is evaluated concerning the expandability
of the platform and the 3
rd
-party implementer is
assessed concerning its valid use of the extension
mechanisms. This matching can be called asymmet-
ric, because there is a provide-use-relationship be-
tween the certified actors. For the quality factor
interoperability the two actors are evaluated regard-
ing a valid implementation of an interoperability
mechanism, for example an interface. These mecha-
nisms are specified in an, ideally standardized but
also proprietary specification. Both, the platform and
the implemented component of the 3
rd
-party imple-
menter must be conforming to this specification.
This matching can be called symmetric.
3.4 Semiformal Model for the Scheme
The derivation of criteria is a central step when de-
scribing a specific certification process. Hence, in
the following we describe a structure, in which the
criterion is embedded. This structure forms the basis
for a derivation method and shows how the scheme
shown in section 3.3 is considered in a formalized
model. Figure 4 shows the concepts that are associ-
ated with the criteria. A criterion results from reali-
zation scenarios, which are formulating solution
approaches for a specific use case. Realization sce-
narios can be referenced to standards like IHE-
profiles (Integrating the Healthcare Enterprise). This
scenario oriented methodology is taken from the
Antilope project (van Pelt and Sprenger, 2013, p. 6
f.).
The quality factors interoperability and expanda-
bility are indirectly referenced with the criterions by
quality objectives. These quality objectives are spe-
cific subordinated goals that have to be achieved for
a good quality factor fulfillment. The criterion is
associated with a specific requirement from the
requirements specification. The standards, refer-
enced in the realization scenarios must also be refer-
enced by specific criteria that are derived from the
scenarios. A criterion could have subordinated crite-
ria. The subordinated criteria specify conditions that
are necessary for the fulfillment of the parent criteri-
on. A subordinated criterion must be on the same or
a lower layer of the specified certification scheme.
In the provided scheme the layers are represent-
ed by the enumeration and associated to the criterion
with an attribute. The layers are ordinal:
Organizational > Application > Technical > Logical
Criteria can also reference other criteria, to show
dependencies. These dependencies specify no sub-
ordination or precondition. They are informative.
The definition of criteria associated with the quality
factor interoperability is depending on a specific
domain. In section 3.1 we stated, that the degree of
interoperability could only be determined for specif-
ic purposes. Insofar the definition of use cases for
interoperability is always driven by a domain con-
text.
Figure 4: Criteria-model for the certification framework.
CertificationofService-orientedeHealthPlatforms-DerivationofStructuredCriteriaforInteroperabilityand
Expandability
119
4 RESULTS
In the following we demonstrate the use of our
framework with a small set of criteria. In the context
of our project, described in section 1.2, we defined a
set of subordinated quality objectives, which support
the achievement of expandability and interoperabil-
ity (see table 1).
Table 1: Quality objectives derived for the demonstration
platform.
Expandability Interoperability
Performance Performance
Transparency Transparency
Reusability Usability
Conformity to Standards Conformity to Standards
Security Reactivity
Market accessibility Consistency
Framework behavior Legal compliance
Legal compliance
Another concept, we specified, are realization sce-
narios, which are derived from a use case. The sce-
narios profile the prospective expandability aspects
to specific expandability cases. In the following a
simple scenario is shown:
A 3
rd
-party implementer wants to transmit pa-
tient data from a patient registry to the platform.
For this purpose an HL7v2 (Health Level Seven
Version 2) message (ADT A01) should be used. An
adapter for receiving these message types isn’t im-
plemented yet. He implements a component, which is
able to receive messages from this type and to modi-
fy the internal data.
Table 2: Example criteria for expandability.
Criterion Layer Quality
Objective
API and interface-specification
must be available to a 3rd-party
implementer without specific
constraints.
Organi-
zational
Trans-
parency
The data hold in the platform
must be accessible for read and
write to new components.
Appli-
cation
Reusability
The extension-mechanism of
the interface layer for import-
interfaces uses the following
patterns: Bridge, Decorator,
Adapter, Template Method
Logical Framework
behavior
A mapping-language allows the
configuration of interfaces.
Tech-
nical
Reusability
All SOAP-service-interfaces
are specified with WSDL.
Tech-
nical
Framework
behavior
Considering of the quality goals for the platform,
now criteria can be derived and assigned to each
layer. For example the criteria in Table 2 have been
derived based on the described scenario. All criteria
in the following table address expandability aspects.
For expandability, the layers of the framework
are instantiated as follows: The criteria on the organ-
izational layer ensure, that the context of the tech-
nical platform is designed in a way, that the 3
rd
-party
implementer is not hampered. Criteria on the appli-
cation layer describe basic principles that are ex-
pected when extending the technical platform. It
addresses the general application behavior towards
expandability. This is similar to functional require-
ments. Criteria on the logical layer address architec-
tural principles. In the example specific design pat-
terns that target on the problem fields reusability,
flexibility and abstraction from implementation are
referenced (Gamma, 1995). Criteria on the technical
layer define expected technology aspects.
Table 3 shows an exemplary set of criteria,
which describe the requirements for the implementa-
tion conformance of third party applications. These
criteria ensure that the ecosystem of the platform is
designed in a homogenous structure. To foster the
use of established standards, the second criterion
defines that the use of established standards is oblig-
atory. This criterion should prevent the ecosystem
from being overwhelmed with new proprietary inter-
faces.
Table 3: Example criteria for implementation conformance
of 3
rd
-party application.
Criterion Layer Quality
Objective
It must be documented, which
services of the base platform
are used.
Organi-
zational
Trans-
parency
Implementation of new external
interfaces considers interna-
tional and national standards.
Appli-
cation
Conform.
Standards
Services of the platform had to
be referenced always via a
central naming service.
Logical Framework
behavior
Interoperability criteria can be derived as shown
in (Coorevits et al., 2011, p. 14 ff). The use cases
and realization scenarios are derived as shown in
(van Pelt and Sprenger, 2013). In table 4 we show a
small subset of the derived interoperability criteria.
Our domain context for which criteria was derived
was the generic inter-institutional sharing of docu-
ments. As basic use case and scenarios we reused
the Antilope-defined use case and scenarios from
use case 4b (van Pelt and Sprenger, 2013, p. 32 ff.).
HEALTHINF2015-InternationalConferenceonHealthInformatics
120
Table 4: Example criteria for interoperability.
The derived criteria are also formulated in the
context of our defined quality objectives. The exam-
ple also shows criteria that are in a hierarchic rela-
tionship. For example, the second criterion is the
parent criterion for the fourth criterion, which in turn
is the parent for the fifth. The fifth is the parent of
the sixt.
5 DISCUSSION
We demonstrated how established interoperability
layer models can structure conformity criteria and
that these models can also be applied for expandabil-
ity. The other newer interoperability models weren’t
used for the structuring for the following reasons.
We haven’t selected the eEIF model, because its
views are too organization-oriented. There are two
layers representing legal and organizational interop-
erability and only two layers (semantic and tech-
nical) that represent information system aspects. The
differentiation between logical and technical aspects
would have become difficult. The model from An-
tilope was not selected because through its six layers
a criteria catalogue had lead to many nearly equal
criteria that overlap in their definition space. For
example the first criterion in t ^ able 3 can
be assigned to “Legal & Regulatory” and also to
“Policy”. The resulting catalogue would have be-
come too voluminous due to redundant criteria. If
necessary, the layers of Antilope can be adapted. To
ensure the adaptability of the Antilope interoperabil-
ity model, the mappings are defined in this paper. In
the following definition of the framework layers, a
reference to the Antilope layers is also given.
It was necessary to redefine the layer of the or-
ganizational view in the context of expandability. In
the ALT-model the organizational layer is only out-
lined with the terms “continuity and quality”
(Coorevits et al., 2011, p. 14). It aims at the care
process. Our definition of the organizational layer
more focuses on the organization between the stake-
holders of an eHealth-project. Nevertheless the qual-
ity of care results is affected by the properties of this
layer, e.g. if the stakeholders of the project define
the need for a privacy agreement that enables the
data exchange of patient relevant data in a legally
conformant way.
A resulting question from our work is which
evaluation methods are adequate to use with the
gathered criteria. The evaluation methods build
another part of the artifact certification. The three
studies described in section 2 define assessment
processes for interoperability and functionality of
eHealth software products. It can be found, that the
layers are not recognized in the specified assessment
processes. Only HITCH provides how the testing
can be structured by the ALT-model (Coorevits et
al., 2011, p. 14). If only interoperability for specific
information exchanges should be tested, this may be
sufficient. In this case the criteria derived with our
framework can be used as acceptance criteria in a
test plan (Bruun-Rasmussen and Johansen, 2013, p.
16 f.). If interoperability in the long-term view
should be certified, there is one problem: Because of
the future aspects of this view, there are no specific
components that can be tested. Even other expanda-
bility aspects (extension of other non-interface-
related platform components) are not testable. In
such a cases other evaluation methods, like inspec-
tions have to be done. There are different scenario
based inspection methods for such problems that
seem appropriate, e.g. ATAM (Kazman et al., 2000)
or QADA (Henttonen et al., 2007). In the next steps
we plan to analyze different methods for architecture
evaluation.
As part of a larger design artifact, we evaluated
the framework only in an artificial evaluation with
the shown demonstration (Alturki et al., 2011). We
demonstrated that the framework aligns with the
eHealth-context. Further research has to be done
answering the question, whether the framework also
is applicable for non-eHealth-Solutions.
ACKNOWLEDGEMENTS
This work is part of the EFRE-fostered project
Criterion Layer Quality
Objective
1. A template for an interoperabil-
ity agreement must exist, in which
the stakeholders are obliged to
implement interoperability stand-
ards.
Organi-
zational
Legal
comp-
liance
2. The system must be able to
receive and store documents from
other systems
Appli-
cation
Reactivity
3. The system must be able to
send stored documents to other
systems.
Appli-
cation
Reactivity
4. The system must be able to act
as IHE actor “Document Reposi-
tory”.
Logical Conform.
Standards
5. The system must support the
IHE transaction ITI-41.
Logical Conform.
Standards
6. The system implements registry
response defined in ebRS.
Tech-
nical
Conform.
Standards
CertificationofService-orientedeHealthPlatforms-DerivationofStructuredCriteriaforInteroperabilityand
Expandability
121
“Telehealth Ostsachsen” supported by the European
Union and the Free State of Saxony.
REFERENCES
Alturki, A., Gable, G., Bandara, W., 2011. A Design
Science Research Roadmap, in: Jain, H., Sinha, A.,
Vitharana, P. (Eds.), Service-Oriented Perspectives in
Design Science Research, Lecture Notes in Computer
Science. Springer Berlin Heidelberg, pp. 107–123.
Alvaro, A., de Almeida, E.S., de Lemos Meira, S.R., 2005.
Software component certification: a survey. Softw.
Eng. Adv. Appl. 2005 31st EUROMICRO Conf. On
106–113. doi:10.1109/EUROMICRO.2005.52.
Audebert, H.J., Wimmer, M.L.J., Schenkel, J., Ulm, K.,
Kolominsky-Rabas, P.L., Bogdahn, U., Horn, M.,
Haberl, R.L., 2004. Telemedizinisch vernetzte Schlag-
anfallstationen. Nervenarzt 75, 161–165. doi:10.1007/
s00115-003-1659-2.
Bruun-Rasmussen, M., Johansen, I., 2013. D2.2: Interop-
erability Testing Processes (Deliverable No. D2.2),
ANTILOPE - Adaption ad take up of standards and
profiles for eHealth Interoperability.
Coorevits, P., De Moor, G., Devlies, J., Bourquard, K.,
Heidenreich, G., Sauermann, S., Loef, C., 2011. D4.2
Processing interoperability testing, semantic and func-
tional criteria (Deliverable No. D4.2), HITCH -
Healthcare Interoperability Testing and Conformance
Harmonisation.
De Moor, G., Kalra, D., Devlies, J., 2008. Certification of
Electronic Health Record systems and the Importance
of the Validation of Clinical Archetypes. Stud. Health
Technol. Inform. 82–91. doi:10.3233/978-1-58603-
922-6-82.
DIN Deutsches Institut für Normung e.V., 2005. Kon-
formitätsbewertung – Begriffe und allgemeine
Grundlagen (ISO/IEC 17000:2004); Dreisprachige
Fassung EN ISO/IEC 17000:2004.
European Commission, Deloitte & Touche, 2013. eHealth
EIF - eHealth European Interoperability Framework -
Vision on eHealth EIF.
Galin, D., 2004. Software quality assurance. Pearson
Education Limited, Harlow, England; New York.
Gamma, E. (Ed.), 1995. Design patterns: elements of
reusable object-oriented software, Addison-Wesley
professional computing series. Addison-Wesley,
Reading, Mass.
Greß, S., Stegmüller, K., 2011. Gesundheitliche Ver-
sorgung in Stadt und Land - ein Zukunftskonzept: Ex-
pertise für die Friedrich-Ebert-Stiftung. Friedrich-
Ebert-Stiftung, Wiesbaden.
Gröne, O., Garcia-Barbero, M., 2001. Integrated care - A
position paper of the WHO European office for inte-
grated health care services. Int. J. Integr. Care 1.
Henttonen, K., Matinlassi, M., Niemela, E., Kanstren, T.,
2007. Integrability and Extensibility Evaluation from
Software Architectural Models- A Case Study. Open
Softw. Eng. J. 1, 1–20.
Hilley, D., 2009. Cloud computing: A taxonomy of plat-
form and infrastructure-level offerings. Ga. Inst.
Technol. Tech Rep GIT-CERCS-09-13.
Hörbst, A., Ammenwerth, E., 2010a. Electronic Health
Records: A Systematic Review on Quality Require-
ments. Methods Inf. Med. 49, 320–336.
doi:10.3414/ME10-01-0038.
Hörbst, A., Ammenwerth, E., 2010b. Quality and Certifi-
cation of Electronic Health Records. An overview of
current approaches from the US and Europe. Appl.
Clin. Inform. 1, 149–164. doi:10.4338/ACI-2010-02-
R-0009.
Hörbst, A., Schabetsberger, T., Hackl, W., Ammenwerth,
E., 2009. Requirements regarding quality certification
of Electronic Health Records, in: Adlassnig, K.P.
(Ed.), Medical Informatics in a United and Healthy
Europe: Proceedings of MIE 2009, the XXII Interna-
tional Congress of the European Federation for Medi-
cal Informatics. IOS Press, p. 384.
IEEE, 1990. IEEE Standard Glossary of Software Engi-
neering Terminology. IEEE Std 61012-1990 1–84.
doi:10.1109/IEEESTD.1990.101064.
IHE Europe, 2014. Whitepaper on Connecathon.
Kazman, R., Klein, M., Clements, P., 2000. ATAM:
Method for architecture evaluation (Technical Reoirt
No. CMU/SEI-2000-TR-004). Software Engineering
Institute, Carnegie Mellon University, Pittsburgh.
Kodner, D.L., Spreeuwenberg, C., 2002. Integrated care:
meaning, logic, applications, and implications–a dis-
cussion paper. Int. J. Integr. Care 2.
McCall, J.A., Richards, P.K., Walters, G.F., 1977. Factors
in software quality. General Electric, National Tech-
nical Information Service.
Office of the National Coordinator for Health Information
Technology, 2012. ONC HIT Certification 2014 Edi-
tion - Test Procedure Overview.
Plischke, M., Wagner, M., Haarbrandt, B., Rochon, M.,
Schwartze, J., Tute, E., Bartkiewicz, T., Kleinschmidt,
T., Seidel, C., Schüttig, H., Haux, R., 2014. The Low-
er Saxony Bank of Health: Rationale, Principles, Ser-
vices, Organization and Architectural Framework.
Methods Inf. Med. 53, 73–81. doi:10.3414/ME13-02-
0003.
Sunyaev, A., Schneider, S., 2013. Cloud services certifica-
tion. Commun. ACM 56, 33. doi:10.1145/2408776.
2408789.
Toroi, T., Eerola, A., Mykkänen, J., 2007. Conformance
testing of interoperability in health information sys-
tems in Finland. Stud. Health Technol. Inform. 129,
127.
Van Pelt, V., Sprenger, M., 2013. D1.1: Refinement Defi-
nition document (Deliverable No. D1.1), ANTILOPE -
Adaption ad take up of standards and profiles for
eHealth Interoperability.
HEALTHINF2015-InternationalConferenceonHealthInformatics
122