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

-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..

Certiﬁcation 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

 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

-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

-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

-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

-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

-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

-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

degree

interoperability

(IO)

best

reachable

event

changes

needs

informa on

exchange

(new

requirement)

fin

she d

measure

Improve

interoperability

(reac on

event)

degree

interoperability

with

worse

degree

expandability

good

expandability

worse

expandability

degree

interoperability

with

good

degree

expandability

good

expandability

good

expandability

reac on

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

-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

-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

-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

-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

-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

-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

-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

-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