MARKETPLACES FOR HEALTH APPLICATIONS

Assessment of Requirements in Case of the German Public Health System

Sebastian Dünnebeil

, Jan Marco Leimeister

and Helmut Krcmar

Department of Informatics, Technische Universität München, München, Germany

Department of Economics, Universität Kassel, Kassel, Germany

Keywords: Application store, Healthcare, e-Health, Telemedicine, Public health system, Treatment quality, Treatment

cost, Marketplace, SaaS.

Abstract: Multiple innovations in e-health have the proven potential to improve treatment success, reduce adverse

events and healthcare spending. Despite the promising potential, verified in various studies, the diffusion

speed of healthcare application is very low. A major challenge in healthcare is therefore not only the

research and development for improved treatment, but also the comprehensive and effective diffusion of

selected technologies to caregivers and patients. Hence the paper investigates the theoretical background

influencing the diffusion of innovations. It adopts the concept of application stores, which have shown high

potential as accelerators for extensive distribution of software applications, for the domain of e-health.

Requirements for such a marketplace are derived from the constraints of the public health system. The

involved actors are identified and linked in a high level model.

1 INTRODUCTION

Health systems around the world have seen multiple

innovations in the field of electronic health (e-

health). The benefits of these applications are proven

in many cases; however, the diffusion speed of such

applications is currently very low (European

Comission, 2007). Telemonitoring e.g. has strong

evidence to be beneficial in many aspects of

healthcare. Hospitalization, mortality rate, lack of

work, and the overall treatment costs can be reduced

partially tremendously by telemonitoring, up to 40%

(Helms et al., 2007, Kempf and Schulz, 2008);

however, the software based prevention method is

not commonly used yet. Also medical errors, which

are called adverse event and cause more death than

breast cancer, traffic accidents, and AIDS combined,

can be limited by the usage of e-health application.

Hence utilization of such supporting information

systems (IS) is urgently recommended by the

European Authorities (European Comission, 2007).

Applications managing the accurate discharge of

prescription show significant advantages, compared

to the traditional handling. These are able to

decrease the rate in unadjusted absolute death rate

by 27% for cardio-vascular patients after one year

(Lappé et al., 2004). Considering the fact that wrong

medication in the united States cost $4.4 Billion in

2006 (IOM, 2006) and 37.4% of all adverse events

are caused by wrong medication (Aranaz-Andrés et

al., 2008), the diffusion of such technologies should

be the subject of efforts across the whole society. As

the technology is theoretically available, the benefits

are proven; a method to organize and accelerate the

distribution is an important factor. Therefore the

paper investigates the reasons for slow adoption of

e-health and suggests a model to improve the

situation.

1.1 Diffusion of Innovations

According to Rogers (Rogers, 1995) the diffusion

speed of innovations depends on five factors (figure

1). These factors are assumed to be valid for

healthcare innovations; they are therefore applied to

the area of e-health applications. Goal of this step is

to explain the unsatisfying situation, visible by now.

Relative Advantage: If the new treatment method

can achieve a relative avantage compared to the

current handling, it fosters the underlying

innovation. Main stakeholders involved in the

treatment are caregivers, patients, and the founders

(normally health insurances or tax payers). The

315

Dünnebeil S., Leimeister J. and Krcmar H..

MARKETPLACES FOR HEALTH APPLICATIONS - Assessment of Requirements in Case of the German Public Health System.

DOI: 10.5220/0003171703150322

In Proceedings of the International Conference on Health Informatics (HEALTHINF-2011), pages 315-322

ISBN: 978-989-8425-34-8

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

examples above show that the relative advantage is

obvious, at least in the case of patients and founders,

as treatment success improves and treatment cost

drops. The usage condition must therefore be

changed in a way that caregivers also benefit from

the relative advantage when using e-health

applications. This could be achieved by financial

incentives. Cases where expected efficiency

advantages resulting from the application of health

information technology (IT) are not, at least

partially, distributed to the caregivers are likely to

gain little acceptance within this group. In the case

of the German health card this problem caused a

tremendous cut back in functions offered by the

system, due to the resistance of the caregivers

(Tuffs, 2008). No insentive structures were planned

for this group, the reduction of overall treatment

spendings, resulting from better health care, raised

the fear of lower income for phyiscians without

adequate compensation (Bernnat, 2006).

Figure 1: Diffusion speed of innovations.

Complexity: Innovations must be easy to handle for

the involved actors. Considering the fact that a an

average physician-patient contact only lasts about

seven minutes (Kurt, 2001), complex applications

are difficult to handle for either side. Handling for

the patients must be especially easy, as they have

high variation in cognitive reaction and technical

background. Caregivers genarally do see themselves,

at least partially, responsible for the education and

support of their patients, when they use e-health

services. (Dünnebeil et al., 2010b) This raises a high

scepticism concerning the extra effort caused by the

support of patients and requires a comprehensive

program in order to distribute the education work to

various institutions.

Compatibility: Applications must be integrated into

the application landscape of the software that is

already deployed in the health institutions. The

exchange of data with existing applications is

essential in many cases. Missing data exchange

leads to the usage of multible software systems

during the treatment of one patient. In case of

multimorbidity several treatment processes have to

be combined. Hence software integration should

result in one interface instead of multible. In extreme

cases the divertion into seperated systems can even

cause patient’s death, caused by cognitive overload

of caregivers (Zuehlke et al., 2010). Compatibility

can be partially ensured by interoperability of

distinct IS. Several approaches exist to ensure

syntactic and semantic interoperability (Pedersen

and Hasselbring, 2004). However, the compatibility

is not fully insured for combinations of various

software modules yet.

Triability: Potential users must be able to try e-

health applications before their adoption decision.

The case of the German health card system, which

tried to establish mandatory software usage for e.g.

prescribing, has shown that voluntary usage has

advantages. Several systems should compete in

terms of user friendliness. The chance to try

different applications for the same purpose gives the

possibility to adopt the system which matches the

users’ individual requirements best.

Observability: Little of the advantages of e.g.

telemonitoring or prescription applications are

known to the public by now. If patients can observe

that other patients, who do use e-health applications

personally or who’s caregivers are supported by

such software, receive a better treatment, they will

likely request the services during medical treatment,

too. Same counts for caregivers who can observe

advantages in terms of earnings or quality achieved

by colleagues using e-health applications.

2 APPLICATION STORES

Marketplaces for applications have the potential to

deliver software from various developers distributed

all over the world to users. While mobile phones had

few applications installed in the past, by today a

mobile phone can host any combination of up to

225,000 applications (Holzer and Ondrus, 2009).

The revenue created with the App Store of apple

currently exceeds $ 1 Billion; more than 5 Billon

applications were downloaded and deployed on the

devices of the company so far. Considering the total

sales of the iPhone and the iPod Touch, which

reached 34 Million units by 2009, an average

Diffusion

Speed

Triability

Relative

Advantage

Complexity

Observability Compatibility

HEALTHINF 2011 - International Conference on Health Informatics

316

deployment of about 50 applications on one device

can be derived for the year 2009 (AppleInsider,

2010). This turns a modern Smartphone into a highly

customizable device, which can be adapted to fulfil

the user’s individual requirements. The criteria for

diffusion of innovations, which were discussed

earlier, can be easily observed in the case of the

iPhone and the App Store. The relative advantage

for customers is the availability of a huge number of

functionalities, offered for their device. It can

therewith be customized to a degree far beyond a

standardized product, as the development of

functionalities does not originate in a single

development entity. Also a mass customization, as in

case of the car industry, cannot reach such a

diversification as a huge distributed community of

developers. Financial advantages are possible for

both, developers, who can reach a broad audience

with their software, and for the distributing

company, which can earn a share of the revenue and

sells the pool of functionalities available for their

devices as a competitive advantage. The complexity

was also reduced, as a single installation method

allows the utilization of specialized applications. A

modern Smartphone is no longer a device for a small

group of people with high technical expertise; rather

it is usable for a broad spec of users. Compatibility

with e.g. common mail accounts, wireless access

points and the synchronization with home computers

allow the usage of personal data on various devices

and in several applications. The triability has

increased as the technology is nearly ubiquitously

offered; users can download free evaluation versions

of applications and evaluated them prior to the

adoption decision. Acquaintances and retailers offer

potential adopters the chance to get an inside, before

the individual decision whether to adopt the

technology or not is taken. The advantages of

applications distributed in this way are also

observable for the public by now. Many people use

the applications and advertisement tries to transport

the advantages to a broad target audience.

As e-health innovations can achieve advantages

for patients and reduce the public healthcare

expenses for chronic diseases, health authorities

should be keen pushing the deployment of these

technologies. If the potentials of application stores

for mobile phones can be transferred to the

healthcare sector, a broader distribution might be a

possible result. The paper will therefore investigate

if the concept of marketplaces for applications, as

described for mobile communication, can be

transferred to the healthcare sector. The concept

turns requirements and constraints into a high level

model, which can be implemented afterwards.

3 REQUIREMENTS

IN HEALTHCARE

Medical IS are currently mostly available in fixed

versions with few optional extension modules. Some

Personal Health Records (PHR), as HealthVault of

Microsoft, offer a data pool for patients, which can

be extended and used by additional applications as

heart rate watches or blood pressure monitors

(Microsoft, 2007). The security issues, HealthVault

is not conform to the Health Insurance Portability

and Accountability Act (HIPAA) and the German

privacy protection commissioner discourage patients

from usage (Sunyaev et al., 2010), turn the usage of

patient centred commercial health records into an

unlikely approach to overcome the described

diffusion problem. Especially since caregivers

harshly reject private companies to act as health

application providers and PHR operators (Dünnebeil

et al., 2010b), other methods must be evaluated to

encourage the distribution of e-health innovations.

The healthcare sector is not considered a normal

market. Only less than one third of all services

provided in healthcare are paid by the consumer of

these services directly. Most expenses are covered

by health insurances or authorities, financed by tax

money. Those must not take adoption decisions

based on subjective opinion; they must rather

establish a traceable method to decide whether an

application should be financed. A patient cantered

approach is therefore not sufficient. A method to bill

services to health insurances must be included.

Accordingly the approach used in the mobile phone

market is adopted and extended for healthcare in the

following section. When designing a marketplace for

e-health applications, several conditions have to be

fulfilled. The paper constructs a marketplace for

healthcare applications, considering the

requirements and constraints set in the German

public health system. The model is developed step-

by-step, starting with the software deployment

model, which is currently used for software

distribution in the German public health system to a

model, which includes all necessary aspects covered

in this work. Goal of software development on the

platform is to allow developers of medical software

and telemedicine applications to reach as many users

as possible. The best innovations ought to be used

MARKETPLACES FOR HEALTH APPLICATIONS - Assessment of Requirements in Case of the German Public Health

System

317

widely in healthcare, as they have positive medical

impact.

As an example for an e-health application we

look at an application for monitoring cardiac

insufficiency. A software developer has an

innovative concept for telemonitoring, which he

wants to sell to caregivers in ambulatory care. The

company is currently too small to approach a bigger

number of caregivers directly. Additionally the

caregivers show little interest, since they cannot bill

the telemonitoring to the health insurance. Patients

with a valid diagnosis for this chronic disease are

able record their blood pressure and weight once a

day with the system. The data from the blood

pressure meter and the scale is transferred and

recorded on the server of the software provider. The

data transfer from the devices to the server can be

automated or uploaded manually. Once the

parameters run out of normal range, the physician

receives a notification. The doctor’s medical IS

sends a request the service to see whether some of

the patients he monitors have vital parameters

showing impairment as indication for an infarct.

Action can be taken before the patient calls in

because of the symptoms. This normally saves

valuable time. According to the study the saving for

one patient can be expected to be as high as 6000

Euros in one year (Helms et al., 2007). A part of the

savings should go to the application provider and the

caregiver who performs additional extra work when

using the telemonitoring application. A further share

of the savings can be granted to patients with good

compliance.

3.1 Direct Distribution Model

Traditionally software is developed as a

personalized solution for one customer or released as

a product, which can be sold to multiple users

afterwards. Developers of the software can be either

internal IT departments or self-contained software

companies. The distribution channel mainly leads

from the developer to the user directly, reflects

therefore a 1:1 relation (figure 2). Mostly a sales

force is needed to distribute software this way.

Especially for non consumer products, as health IS

or e-health applications, traditional retailers are not

suitable.

Figure 2: Traditional Software development and

distribution model.

Development of customized software for normal

sized medical institutions is often not possible due to

the size. The average institution in German

ambulatory care counts about 2.1 physicians, with

86 patients visiting the practise per day (Dünnebeil

et al., 2010a). With 289k Euro average annual

revenue (Kassenärztliche Bundesvereinigung, 2008)

the development of a customized solution is hardly

affordable and not cost-effective. Most physicians in

ambulatory care are therefore using standardized

stand alone systems for their treatment support. The

market of German health IS for ambulatory care is

highly fragmented. In 2009 116.895 medical IS were

installed in physicians’ practices. In total more than

200 different systems are deployed in primary care

(KVB, 2009). For these solutions the availability of

functions or modules depends on the developments

of the product owner. The utilization of services is

obviously also coupled with the product life cycle,

as updates delivers new functions. For smaller

companies this approach raises the barrier for market

entry. They depend on the owners of the medical IS

to include and sell the application bundled with their

software. An individual market entry with stand-

alone solutions is difficult, taking into account that

nearly 170,000 physicians are practicing in German

ambulatory care. Small companies can neither

provide a sales force to approach a big number of

physicians, nor can they provide the overall

functionality of a self contained-system.

3.2 Application Platforms for Many

Developers

An alternative to the one-to-one distribution of

software is a marketplace for applications, accessible

to many developers as a service (figure 3). This

approach became hugely famous when Apple

released its application marketplace called “App

Store” for their devices. Apple did not intend to

develop the whole software set deployable on their

embedded devices any longer within their own

company. The devices were opened for developers

around the world to sell or donate their applications

via the application store. The operating system

running on such devices is usually not an open

platform. Installation of additional software is only

possible via the provider’s proprietary internet

platform. All applications are checked on conformity

with the company’s guidelines pervious to their

release, especially concerning compatibility and

content. The services provided by the platform are

financed by a certain share of the retail price, which

is retained by the store provider. The financial

User Developer

HEALTHINF 2011 - International Conference on Health Informatics

318

transactions are, at least in the case of the App Store,

carried out by the provider of the store.

Figure 3: SW-Distribution model via a centralized

provider.

The resulting model is a 1-to-n distribution

model, as all the devices running the applications are

of one kind. This approach can be adopted and

applied for the owners of the medical IS. They can

offer developer platforms to enrich their software

with external content. This concept, similar to the

one provided by apple, is hardly feasible,

considering that 200 different providers offer

platforms in ambulatory care. If a developer wants to

reach all patients, theoretically 200 different

versions have to be provided, which requires a high

administrative and technical effort. The providers of

medical IS would have to agree on a common

extension model, ensuring universal compatibility.

3.3 Application Platforms for Various

User Groups

In case of the German health system a high

fragmentation of target platforms is one constraint

that has to be taken into account as there is currently

no overall extension model. Most health IS in

hospital or practices are deployed on open platforms

as a personal computer (PC) or an application server.

Software which is offered by the provider can be

deployed directly to the target platforms. However

the compatibility with the main medical IS has to be

ensured.

Figure 4: Distribution model with multiple developers and

multiple user groups.

Hence it is important to enable the compatibility

with each platform the application is supposed to run

on. For the resulting n-to-n approach (figure 4) this

can be implemented when a) the application is

adapted to every single target platform b) uses an

adequate virtual machine model, which is available

for each target platform, or c) standards are

employed, which can be used by every target

platform.

Case A will deliver native applications to all

registered user platforms and systems. This will

require the applications to be compiled and adopted

to every target platform supported by the provider.

Similar deployment models can be seen for software

as e.g. browsers, which are available for a whole set

of operating systems (Mozilla, 2010). This is

primarily the operating system. Possibly the

caregivers’ IS must also be considered if the

application needs to be integrated with the main

system on the end user. Without common

communication interfaces, every version has to be

adjusted manually. This model is known for mobile

devices as well. Native software is adapted to each

operating system as the iPhone OS, Android of

Symbian.

Case B will require a virtual machine to run the

source code on the target device. Such software

implementations of computers are available for

multiple platforms and can execute applications

virtually. The Java Virtual Machine (JVM) is widely

known and used. A similar model is feasible for

medical IS when virtual machines are running on all

target platforms. The interface problems can

normally not be overcome, as only standard system

interfaces are implemented in the virtual machine.

Case C: The Provider offers the developers

applications via the standardized access, which is

nearly universally executable by computers. The

TCP/IP Stack can today be used with various

application stacks, as the HTTP or SOAP protocol

stack, on which distributed applications can be built.

Therewith the applications are nearly universally

accessible as internet browsers are broadly

distributed, on personal computers (PC), smart

phones and tablet devices. Software as a Service

(SaaS) is the corresponding software delivery model,

which provides access to business functionalities

remotely (usually over the internet) as a service

(Knorr, 2007). This approach can be integrated with

existing legacy systems (Sun et al., 2007) as medical

IS.

3.4 Application Platforms for Different

Groups of Patients

We suggested some rough methods to approach the

challenge of multiple target platforms and IS. A

User Provider

Developer1

Developern

…

Usergroup n

Provider

Usergroup 1

…

Developer 1

Developern

…

MARKETPLACES FOR HEALTH APPLICATIONS - Assessment of Requirements in Case of the German Public Health

System

319

provider of an e-health marketplace can offer

software with a certain standard or for a virtual

machine to manage the fragmentation issue. The

majority of healthcare spending is public funds.

Those are credited to the caregiver after the

treatment, mostly according to a fixed allowance

catalogue. If the user of e-health applications is a

caregiver, whose treatment is founded by his or her

patient’s health insurance, the software must be able

to deal with the billing modalities of several user

groups. Most insurance differ in terms of benefits

and administration. In Germany each citizen has

mandatory public health insurance. Currently 163

public health insurances are available (GKV, 2010),

which leads to at least 163 different groups of clients

to be handled.

Figure 5: Application Platform with certification entity.

Clients insured by private institutions have

different treatment conditions than clients who are

insured by a public health insurance company. This

can increase the diversity further. Considering the

telemonitoring example for patients with cardiac

insufficiency, the payment to patients, caregivers,

and patients has to be included into the application.

Each health insurance might pay different

allowances to caregivers and patients according to

their regulations. The provider of the application

platform could offer the service of financial

transactions as an additional feature if there is a link

to the health insurance and a payment standard

(figure 5).

3.5 Application Platforms with

Certification Entity

Taking into account that health information contains

very sensitive patient data, a single provider might

not be suitable to control and host the applications in

a self-contained way. The privacy concerns rose for

HealthVault are likely to come up for other

commercial providers that offer e-health

applications, too. Compliance with legal

requirements raises the necessity for a controlling

entity, which is independent from the provider and

separates commercial interests from those of the

public health authorities and the patients.

Applications might collect and interpret personalized

medical data in an illegitimate way. The certification

of a third party can eliminate such threats and

increase the trust in e-health applications, especially

if commercial interests of the controller can be

disqualified (figure 6).

Figure 6: Application Platform with certification entity.

The controlling entity is also suitable to set up

regulations that any medical application has to obey.

A reference model could be the HIPAA guideline or

the German book of social law (Bundesrepublik

Deutschland, 1988), which guarantees that e.g. every

medical data item needs to be authorized by the

owner, before it can be processes by a caregiver.

Also the usage of encryption and digital signature

are regulated in this legal framework.

3.6 Multi User Application Platforms

Customers buying e-health applications have to be

distributed into at least two different groups. The

telemonitoring example indicated that both,

caregivers and patients, need software tools to

ensure a proper monitoring of the patients’ vital

parameters. One group collects the data; the other

group is responsible for the analysis. The application

platform must therefore ensure access for patients

and various groups of caregivers. The resulting

model (figure 7) indicates that the provider has to

offer to at least two access channels.

Figure 7: Multi User-Application Platform Service.

The resulting model presents a comprehensive

approach. It addresses all actors and requirements

necessary to enable software-based cooperation

between patients and caregivers. Legal compliance

and an adequate security standard can be ensured by

a controller entity. Developers of different nature

User Provider

Developer1

Developern

…

Client1

Clientn

…

User Provider

Developer1

Developern

…

Controller

Client 1

Client n

…

UserGroup1

(Patient)

Provider

Developer1

Developern

…

Controller

Client1

(Patient)

Clientn

(Patient)

…

UserGroup2

(Caregiver)

…

UserGroupn

HEALTHINF 2011 - International Conference on Health Informatics

320

can use the provider to offer their services to the

users. Health insurances should be linked to the

provider with a unified billing model. A payment for

every transaction is more likely than a licence model

that requires investment prior to the actual usage of

the service. Each arrow in the model connects actors

involved in the marketplace. All actors but the

provider and the controller are currently very

heterogeneous. A standardization of these links must

therefore be pushed forward to avoid numerous

adoptions to individual characteristics.

4 CONCLUSIONS

Construction of application stores for the healthcare

domain is more complicated than for the mobile

phone market. While mobile phone manufactures

can rely on a unified target platform, the market for

health IS is highly fragmented. Not only the

diversity of end-user systems has to be targeted in an

appropriate manner, but also security standards, the

challenge of interoperability and the ability to bill

services to multiple health insurances or authorities

that operate with different treatment standards. A set

of standards is essential to unify the system and

organization landscape. Otherwise it is unlikely to

achieve a workable platform, allowing more players

to build up the market and pushing medical

innovations into practise. International marketplaces

are difficult to implement, as the health systems

differ enormously around the globe. Already the

number of requirements in the German public health

system is huge. Theoretically 200 primary care

systems are deployed; these have to interact with

value added applications. Each application must be

able to determine the treatment standard for at least

163 health insurances, which can result in very high

complexity. Frequent changes in the legal

regulations raise further barriers for a stable and

sustainable operation of an ecosystem for e-health

applications.

A marketplace for healthcare applications is

certainly desirable. A standardized platform would

ease the market access for more players and

accelerate the diffusion of the innovations seen in

the domain of e-health. Self-contained development

of e-health is very difficult by today, as many

requirements have to be converged to be fully

compliant with national security and administrative

standards. Authorities must set up adequate

standards to enable software development for the

healthcare market that is detached from the

regulations and focuses on the medical and technical

innovations, which are the core competence of the

developers. Chapter 3.3 has indicated how the

problems of platform diversity can be overcome in

software deployment. Health insurances will have to

develop similar methods to determine how e-health

applications can be included into the regular billing

model for healthcare services. A financial model

focused only on the direct payment of patients is

unlikely to be successful. Effectiveness of an

application can often not be judged by the patients,

an inclusion of caregivers seems therefore

inevitable. Hence a proper incentive structure for

this group is important. Health authorities can use

the results of the studies to judge the effectiveness of

e-health applications and include them as allowable

services within a regular time cycle if they perform

well. The paper worked out the actors involved in a

potential marketplace and described important

connections between them. The resulting model is a

high level framework of a comprehensive platform

for application distribution. A more detailed analysis

of the technical and organizational requirements

should be subject of further research.

REFERENCES

Appleinsider (2010) Apple Says App Store Has Made

Developers Over $1 Billion.

Aranaz-Andrés, J. M., Aibar-Remón, C. & Vitaller-

Murillo, J. (2008) Incidence Of Adverse Events

Related To Health Care In Spain: Results Of The

Spanish National Study Of Adverse Events. Journal

Of Epidemiology And Community Health, 62:, 1022-

1029.

Bernnat, R. (2006) Kosten-Nutzen-Analyse Der

Einrichtung Einer Telematik-Infrastruktur Im

Deutschen Gesundheitswesen. Booz Allen Hamilton

Gmbh.

Bundesrepublik Deutschland (1988) Sozialgesetzbuch

(Sgb) Fünftes Buch, Gesetzliche

Krankenversicherung.

Dünnebeil, S., Sunyaev, A., Blohm, I., Leimeister, J. &

Krcmar, H. (2010a) Do German Physicians Want

Electronic Health Services? A Characterization Of

Potential Adopters And Rejectors In German

Ambulatory Care. Third International Conference On

Health Informatics (Healthinf 2010). Valencia.

Dünnebeil, S., Sunyaev, A., Leimeister, J. M. & Krcmar,

H. (2010b) Strategies For Development And Adoption

Of Ehr In German Ambulatory Care. 4th International

Conference On Pervasive Computing Technologies

For Healthcare (Pervasivehealth). Munich, Ieee.

European Comission (2007) Europäischeunion (2007) -

Ehealth For Safety Report. In Communities, O. F. O.

P. O. T. E. (Ed.). Luxembourg.

MARKETPLACES FOR HEALTH APPLICATIONS - Assessment of Requirements in Case of the German Public Health

System

321

Gkv (2010) Alle Gesetzlichen Krankenkassen. In National

Association Of Statutory Health Insurance Physicians

(Ed.).

Helms, T., Pelleter, J. & Ronneberger, D. (2007)

Telemedizinische Betreuung Chronisch

Herzinsuffizienter Patienten Am Beispiel Des

Telemedizinischen Patientenbetreuungs- Und -

Schulungsprogramms „Telemedizin Fürs Herz“. Herz,

32, 623-629.

Holzer, A. & Ondrus, J. (2009) Trends In Mobile

Application Development. Mobile Wireless

Middleware, Operating Systems, And Applications -

Workshops.

Iom (2006) Identifying And Preventing Medication Errors

- Institute Of Medicine,. In Institute Of Medicine Of

The National Academies (Ed.). Washington D.C., The

National Academic Press.

Kassenärztliche Bundesvereinigung (2008) Grunddaten

Zur Vertragsärztlichen Versorgung In Deutschland.

Berlin.

Kempf, K. & Schulz, C. (2008) Telemedizin Bei Diabetes:

Höhere Therapiezufriedenheit, Verbesserte

Stoffwechselparameter. Diabetivar Studie Monika

Dienstle, Wdgz.

Knorr, E. (2007) Software As A Service: The Next Big

Thing.

Kurt, T. (2001) Großbritannien: Ärzte Enttäuscht Und

Desillusioniert. Deutsches Ärzteblatt, 98.

Kvb (2009) Installationsstatistik - Systeme. In

Bundesvereinigung, K. (Ed.). Berlin.

Lappé, J. M., Muhlestein, J. B. & Lappé, D. L. (2004)

Improvements In 1-Year Cardiovascular Clinical

Outcomes Associated With A Hospital-Based

Discharge Medication Program. Annals Of Internal

Medicine, 141, 446-453.

Microsoft (2007) Microsoft Healthvault - Archtiecture

Overview. Microsoft Corporation.

Mozilla (2010) Download A Firefox Version That Speaks

Your Language., The Mozilla Project.

Pedersen, S. & Hasselbring, W. (2004) Interoperabilität

Für Informationssysteme Im Gesundheitswesen Auf

Basis Medizinischer Standards. Informatik -

Forschung Und Entwicklung, 18, 174-188.

Rogers, E. M. (1995) Diffusion Of Innovations, New

York, Ny [U. A.], Free Press.

Sun, W., Zhang, W., Chen, S., Zhang, X. & Liang, H.

(2007) Software As A Service: An Integration

Perspective. In 4749, L. (Ed.) Icsoc 2007. Berlin

Heidelberg, Springer-Verlag 2007.

Sunyaev, A., Chornyi, D., Mauro, C. & Krcmar, H. (2010)

Evaluation Framework For Personal Health Records:

Microsoft Healthvault Vs. Google Health.

Proceedings Of The Hawaii International Conference

On System Sciences (Hicss 43). Kauai, Hawaii.

Tuffs, A. (2008) Germany Plans To Introduce Electronic

Health Card Bmj.Com Medical Publication Of The

Year.

Zuehlke, D., Meixner, G. & Klein, U. (2010) Smart

Medical Software Systems For Dummies? The Case

For A User-Centered Systems Design. Third

International Conference On Health Informatics

(Healthinf 2010). Valencia.

HEALTHINF 2011 - International Conference on Health Informatics

322