InTech uses cookies to offer you the best online experience. By continuing to use our site, you agree to our Privacy Policy.

Medicine » Telemedicine » "Telemedicine Techniques and Applications", book edited by Georgi Graschew and Stefan Rakowsky, ISBN 978-953-307-354-5, Published: June 20, 2011 under CC BY-NC-SA 3.0 license. © The Author(s).

Chapter 4

Design Criteria for Large eHealth Infrastructure System

By Thomas Grechenig, Barbara Avana, René Baranyi, Wolfgang Schramm and Anna Wujcow
DOI: 10.5772/19091

Article top


Triangle of potentials of eHealth and health telematic systems (Larsen E., 2003)
Figure 1. Triangle of potentials of eHealth and health telematic systems (Larsen E., 2003)
Different roles and sights
Figure 2. Different roles and sights
Iterative design process for a large scale health network
Figure 3. Iterative design process for a large scale health network
Natural Order of Criteria Levels
Figure 4. Natural Order of Criteria Levels

Design Criteria for Large eHealth Infrastructure Systems

Thomas Grechenig1, Barbara Avana1, René Baranyi1, Wolfgang Schramm 1 and Anna Wujciow1

1. Introduction

We live in a time where ubiquitous access to information is part of our daily lives. Most of us use the Internet for sending or receiving information every day. We store data about our daily lives and thanks to social networks, we are able to stay in contact with other people even easier than before. Interestingly one of the most important aspects in our private lives has not yet made the jump into the digital world: our health. While every doctor’s office, hospital and insurer keeps a specific set of information about the progress of their patients’ health, the patient itself rarely has the possibility to either read or contribute this set of information. In addition these piles of health information are completely disjoint. This means, that whenever a patient visits a physician, this patient him- or herself has to update the doctor about all the medical events that have happened since the last visit. For the patient, this is not necessarily an easy task. Not only is it very difficult for the average the patient to remember what happened when, but it is also very difficult for a layman to articulate these facts correctly.

This is where eHealth comes into play. EHealth infrastructures, when done properly, can help to aggregate data, provide the right information to the right people and most importantly give control about health related information back to the patient. EHealth itself is not a technology per se, but a collection of tools and technologies, which combine healthcare topics with computer technologies. These tools include telemedicine, electronic health records, electronic medical records, computer aided diagnosis, hospital information systems and many more. When talking about large health infrastructures, usually regional, national or international eHealth networks and systems are meant (Eysenbach, 2001).

The most common goals of large eHealth projects include a personal health record (PHR), confirmation of a patient’s insurance status and electronic medication. Electronic medication in particular has the potential to positively affect daily health care. Not only does eMedication reduce paper work for health care providers (HCP), pharmacies and insurers, but also allows a streamlined process for preventing accidental prescription of medications with a negative cross interaction.

Planning eHealth strategies for healthcare providers or a nationwide healthcare system is one of the most critical aspects when starting programs or initiatives for eHealth and telemedicine implementation. The planning aspect involves building a strategic vision to align the goals of politic representatives or senior management with the needs of the e-Health marketplace. Technology management and system implementation relate to managing the diffusion of eHealth innovations, redesigning work practices so that both workers and users can work virtually (e-work), and addressing issues of user acceptance or failure arising from the implementation and evaluation of an eHealth system (Tan, 2005).

Before approaching such a project, the vision on the strategic or political level must be carried to the institutions, which would be responsible for the eHealth or telemedicine project development. On the operational level of the institutions concrete measures are analyzed and planned. The technicians on the technical level are responsible for the implementation of the strategic infrastructure programs or application design.

Any sufficiently large IT infrastructure project on a regional, national or international level can be cognitively described along four major abstraction levels:

  1. Political/Public Level – Political/Public Criteria (PC)

  2. Institutional Level – Institutional Criteria (IC)

  3. Operative Level – Operational Criteria (OC)

  4. Technical Level – Technical Criteria (TC)

Engineering practices target only the technical level, while making quaint references to the existence of an operational level that might influence purely technical issues and decisions. The existence and the importance of the institutional level and the political level are usual ignored, if not outright denied in technical textbooks and university curricula. This is in strong contrast to the fact, that projects hardly ever fail on the technical level, and if so, only as a result of failures on the other levels.

This chapter presents an insight into the most important design criteria with their associated requirements and pitfalls on the four levels.

2. Political level

Every large-scale eHealth project begins on a political level. Politics in this context denotes not only a governmental body, but can also be a collection of persons inside a company or organisation. A functioning political level is essential for a successful eHealth project. Issues on the political level always have direct impact on the underlying levels, most critical on the technical.

First and foremost the ultimate goals of the project have to be defined. A system with aim to reduce healthcare costs will have other requirements than a project which is simply used to check the insurance status of a patient or a project with the aim to create a nation-wide personal health record. The important questions to ask are:

  • What do we want to achieve with the new eHealth infrastructure?

  • Who are the end-users?

  • Will this project involve the creation of the specification and the implementation, or only the specification?

  • How will the industry be included?

  • Depending on the project goal: Who will be the stakeholder groups?

Only when these questions are answered discussions on a broader level can happen. Every decision that is made on this level determines the possible implementation, rollout and risk mitigation strategies, which are needed for a successful completion.

Most infrastructure projects are riddled with multiple conflicting goals, less than perfect responsibility delineations, infighting amongst participants and stakeholders and unclear budgetary and timing constraints. There will usually be an overwhelming number of documents claiming the contrary and brand name consulting companies involved to maintain the facade of orderly project management. This big mess during every project stage is not necessary. With clear communications, removal of typical “ego” personas, the early inclusion of patient and physician representatives and a complete project transparency, many of the problems arising from this pile of stakeholder can be prevented or at least diminished.

The level of the political criteria (PC) is sometimes under-estimated and sometimes over-estimated. Overestimation often occurs at that group of people whose daily business is in the public sphere, media and political space. Just as useful it is for a large eHealth infrastructure system that the locally political representatives engage themselves in the relevant ministries or trade spokesmen try to deal seriously with the topic, as inappropriate is often a direct public debate between different political representatives on the subject area of the eHealth system.

A general large eHealth system therefore needs across a common will of all parties to build such an infrastructure. If it is not possible to establish such consensus, the establishment as such must be called into question.

Underestimation of the criteria on political aspects is done regularly by technical specialists in the medical field or information technicians who are involved with building the infrastructure. As positive the value of the overall system of the level of medical or information technology may be, no system can be implemented against the public, the policy or against established cultural practices. In smaller IT environments it may be possible to set up systems against the established processes and users may adapt to the systems - this is a tradition in the 40 years of information technology. But in a system that affects nearly every citizen of a country and a very large protected practitioners group, the use case against the known tasks in everyday life results to a failure of the system.

In the triangle Nation / Health Sector / Citizen or Patient the right relationship of all parties has to be identified for each question or problem, then the potential of the use of eHealth, electronic health record or nationwide health telematic systems can be discussed (see fig. 1).

Promotion and ownership of the system are necessary for the public political discourse and a professional decision-making process.

The following criteria can be identified on the political level:

  • Consideration of cultural aspects and historical development in healthcare

  • Appropriate and necessary innovation to implement the main systems for eHealth

  • Healthy Growing: Creating a healthy eHealth Infrastructure Step-by-Step

  • Appropriate design of the media presentation, dealing with fears and enhance Acceptance

  • Appropriate allocation at the general governmental level

  • Representation in parliament and other representative organisations for citizens

  • Appropriate legislative measures to accompany the implementation process and operation of the system


Figure 1.

Triangle of potentials of eHealth and health telematic systems (Larsen E., 2003)

2.1. Consideration of cultural aspects and historical development in healthcare

Of course there are always exciting innovations and of course innovative work flows can be introduced as part of new technology, but the basis of trust is gained with the possibility to use that which has been always used or to handle situation how they were previously feasible to handle.

Mapping the history means that the understanding, translation and analysis of it is a necessary prerequisite for a valid construction of the new system. It will not be made obsolete entirely, but re-implemented.

On the opposite the “electronification” of healthcare brings options and opportunities that appear for the patient as a pleasant relief. If a process previously was extremely difficult, such as the collection of a lesion, and which can be done in future by electronic delivery and saves a long way, certainly from the point of acceptance of the system is a hit.

2.2. Appropriate and necessary innovation to implement the main systems for eHealth

Until now different application modules for systems in eHealth have been identified by previous research and development as important to be implemented in a future-proof eHealth infrastructure. The most important of them are Electronic Health Records (EHR), eMedication systems and emergency data sets.

2.2.1. Electronic health records

One of many problems for a physician when diagnosing and treating a patient is to perform an accurate anamnesis. Many patients are not able to properly communicate a medical or medication history. This of course can lead to treatment mistakes, which in the worst case may end with the death of the patient. Therefore many large-scale eHealth projects also include an electronic health record platform. An electronic health record is the systematic collection of electronic health information about individual patients or populations (Gunter & Terry, 2005). This means, that every citizen is associated with a data set consisting of her or his medical history. Depending on the reason behind the electronic health record implementation, this may include diagnoses, hospital stays, medication history, etc. Ultimately a thoroughly implemented electronic health record can provide a safer and more effective healthcare for the patient by providing the physicians with the necessary information in every step of the treatment process. For this to work the support of the physicians is absolutely necessary.

When implementing an electronic health record, the project has to deal with two main user groups: patients and health care professionals. Both groups usually have strong opinions about this topic, which in turn will cause heated debates during the project phase. In sections 2.4 and 3 the fears and agendas of patients and health care professional are discussed in greater detail.

2.2.2. Emergency information

If a significant political resistance against a large scale electronic health record system is foreseeable, it is often advisable to start with an electronic health record with limited functionality. Such a minimal electronic health record could for example only include a patient’s emergency information (e.g. allergies, contact person). The advantage with this approach is the possibility to start the rollout with a relatively low risk application, and then add additional functionality when the running system has a high stable performance (technical and political wise). In many cases this approach helps to avoid costly discussions and public debates.

2.2.3. Medication interaction

One of the most useful applications an eHealth system can include is the interaction check between multiple prescribed medications. Since a patient’s complete treatment process usually involves multiple doctors, prescription with medications with adverse effects, can form. This can easily be avoided with an electronic medication system, which checks every prescription for potential hazards. Since a potential off-label use of medication lies at the discretion of the physician, such checks should ideally also be performed at the time of prescription in the doctor’s office, not only at the time of dispensation at the pharmacy.

2.3. Healthy growing: Creating a healthy eHealth infrastructure step-by-step

In theory there are two main possibilities for creating a large eHealth infrastructure.

First: Include all conceivable state-of-the-art features into the project. This will create, at least on paper, a fully featured system that can be used to do everything even remotely eHealth related.

Second: After defining the immediate goals of the project, the next step is to evaluate possible implementation approaches and to test the waters for eventual resistance from potential stakeholder groups. The art when using this approach is to align the project goals with technical and political possibilities while maintaining the essential functionality required for a meaningful system.

While in theory the first approach could yield a fairly complete system, in reality it will be almost impossible to fully implement it. Every health topic causes debates on a political level, the more people involved or affected, the more intense these debates will be. The political and public resistance in such a project can easily reach critical levels up to the point where the project would be required to stop, or to be heavily reengineered. In practice, the second approach has a greater chance of actual finishing close to the planned duration. An early alignment between project goals and the opinion of involved stakeholders helps to alleviate public and political resistance. When taking this step, people should still be educated about the future possibilities while assuring that these future steps will only be performed if feasible and meaningful.

2.4. Appropriate design of the media presentation, dealing with fears and enhance acceptance

Health topics invoke strong emotions in everybody affected. There will be heated public debates from the first project presentation until after the project launch. There can be no general rule on how to prevent these discussions, since the political and public environment is different for each project. Typical attack points include project costs, technical safety of the final solution, changes in clinical workflows, and the general usefulness of the project. Certain parties will not hesitate to play with end-users’ fears to motivate a movement against the project. Public disputes do not necessarily need to have a negative impact, in the contrary: Public disputes also provide the possibility for the project team to present their views and therefore the possibility to turn the public opinion into a favourable one. For this strategy to work the project needs to provide complete transparency about the intended project goals, the architecture, the implemented security measures and the level of involvement of political and industrial parties. Appropriate media presentation, the right information at the right time is needed.

Health in general and eHealth in particular are topics, which invoke emotional debates on the political and on the public level. Therefore it is essential that from early project stages on, the project goals, purpose and technologies are open and transparent. The end-user needs to know what individual information is stored in which way, who will be able to access it, and how the individual can control his or her information.

A typical fear of physicians includes the fear of increased control from payer organisations. A complete digitalisation of the treatment process and the traceable association between a treatment task introduces a transparency into a doctor’s daily work, which is completely new to this field. Currently doctors are also required to meticulously document every step of a patient’s treatment, but there are very few possibilities for outside institutions to actual verify that these steps really have been performed as stated. The only way to deal with this fear is to turn it into an advantage for the doctor. An accurate documentation provides assurance about previous treatments and illnesses and therefore increases the physician’s treatment confidence.

Patients’ fears are fundamental similar to the fears of the physicians. The fear to be a complete transparent patient for everyone to see is more than justified and must be taken seriously. The newspapers are full of reports about compromised IT systems. While these incidents are isolated events, they create an atmosphere of uncertainty. There are few technological possibilities to absolutely secure an IT system on a physical and application level, but these measures have to be open for discussion from early project stages on. Only a complete transparent and open specification of these security measures, where experts are allowed to freely comment can the project reassure concerned users. If does not take these security concerns seriously, it will have to deal with fearful patients and an increasingly worse public opinion.

2.5. Appropriate allocation at the general governmental level

A large eHealth Infrastructure system is as far as possible recognized as an “all-party” system because it makes little sense for investment with more than 10 or 15 years effect, is again and again re-questioned if a government or management changes. It is the duty of engineers to take precautions to ensure that certain political streams can be completely changed in the course of establishing and to anticipate that these streams can be integrated either easily or have no effect on the system at all.

2.6. Representation in parliament and other representative organisations for citizens

Main principles of the new system are established in a time period in which the parliamentary political discourse doesn’t care much about it. But since a negative reaction of the competent parliamentarians, regardless of their fraction, at a time, where the technology can only be slightly changed, the involvement of specialists in the respective groups in the parliament at a reasonably early stage is certainly important.

Depending on the type of construction and the procurement of technology in the process of tendering and contract awards there are extensive public debates over task and award decision. In many countries this is controlled and steered of the respective industrial players, therefore the parliamentary needs to be informed properly.

Therefore it is necessary to have a general political statement, owner or writer of it. This must be done with professional modesty and neutrality. Political processes and large eHealth infrastructure systems are long-term projects, and therefore a only short-term successful fractionation is not advised for receiving overall success.

2.7. Appropriate legislative measures to accompany the implementation process and operation of the system

Appropriate legislation must be provided to grant a stable basis for the large scale/nationwide implementation and to minimize risks in the setup through policy enforcement. The best condition for the functioning of such an eHealth system and also the most important initial planning action is and remains the provision of a proper legal basis for the system establishment. Without such a legal basis any perfectly established system can be swept away after two or three years of construction by a political storm.

3. Institutional level

A large-scale eHealth project consists of several involved institutions. Every institution included in such a project has its own agenda and goal. This goal is not necessarily equivalent with the success of implementing a large-scale eHealth project in time and in budget. Long established institutions tend to fear that they risk losing influence and power if they are not able to increase and state their importance and needs in a large project. EHealth projects in particular contain a lot of institutions with longstanding traditions (e.g. general practitioners or hospitals) and every one of them wants their fair share of influence. So the final goal (from the political level) should be that every institution in the project feels an immediate benefit from such a system and suffers no visible loss in reputation or influence. Even though this is hard to achieve – it might be advisable to give the institutions the impression, that their goals and requirements are the most important ones. The final system needs to combine requirements from all participating institutions (these requirements need to be discussed and adapted for the final system - see Fig. 2). To make that happen, the project initiators need to know which institutions are involved and what their respective agenda is. You should bring their goals to the table and start a solution finding when it is defined which institutions will participate. The results of this process should give the political level the opportunity to compare the benefits and costs of the various options resulting from the institutions’ requirements/wishes/necessities. It is important to remember, that the duration of the solution finding process increases with the amount of involved institutions and the nature of their respective goals. It might be a good starting point to initially align goals between the institutions. Another issue might be the public perception on this process. Some institutions might misuse the general opinion of citizens for their agendas. e.g. a institution may spread fears among people by releasing only parts of the results of the discussion process. These may be avoided by providing transparency throughout every institution and the general population (see also chapter 2.4).

The above stated aspects can be summarized into the following important points of the institutional level:

  • Identify Institutions: Which institutions are involved and what agenda or goal do they have?

  • Describing benefit: What is the benefit for the system for the institutions?

  • Solution process: The goals of every institution should be discussed with them. The requirements of the solution finding process should be taken into consideration by the political level.

  • System acceptance: among the institutions there are different stages of acceptance. Some of them will like the system and some will not like it at all. You have to determine why acceptance among some groups is low and try to increase it.

Usually a large-scale eHealth project consists of many stakeholders/roles from various institutions with different sights. Because of the uniqueness of every large scale eHealth project the institutions and the involved roles will not always be the same but a few of these institutions will be part of nearly every large-scale eHealth project:

  • Primary and secondary healthcare centres: These healthcare centres represent institutions, which are responsible for delivering the initial care in most countries. They might be users or promoters of a large-scale eHealth system. The centres are essential for promoting and increasing acceptance among citizens, because they are the first or even the single point of contact in terms of healthcare.

  • Health Insurances: depending on the national healthcare funding, public or private health insurances play major roles in budgeting and funding of healthcare services.

  • Hospitals: hospitals consist of multiple user groups which potentially will access the final system.

  • Pharmacies: a pharmacy is a user of a eHealth system or a promoter for it.

  • Nursing and Nursing homes: After-hospital-care is often offered by nursing services or nursing homes. Even if immediate patient referral is usual, data of patients are seldom taken from one institution to the other. Integrated care will have to be considered on supporting IT systems.

  • Patients: the patient delivers data to an eHealth system or uses it. Patients are very heterogeneously distributed and therefore it is difficult to find the appropriate solution to the requirements raised by them especially if there is no representative (which is normally the case) present.

See Fig.2 for the different roles and sights of a large-scale eHealth project.


Figure 2.

Different roles and sights

Acceptance among institutions might be the most important part in the design of an eHealth system – what is the best (in terms of technical planned and designed) system worth if nobody is using it?

But the acceptance has to be widespread among every involved institution (or even further, to institutions who are not directly involved) and not focused on one group. Normally there are institutions, which have a high acceptance towards a new eHealth Systems and institutions which have lower acceptance. First it should be determined why the acceptance might be low (e.g. their goals might not be met) and then try to increase it by actively including them in further requirements engineering phases.

An approach to satisfy all stakeholders, is to integrate them in the design process very early and iteratively. Fig.. 3 shows this iterative process for the design of a large scale health IT network.

3.1. System acceptance for primary and secondary healthcare centers

As initial point of contact in most of the care cases, the primary and secondary healthcare centers play a major role in opinion formation. Doctors and their institutional representatives tend usually to have a rather critical role for larger eHealth-Systems connecting different institutions. They fear the worsening of their situation, more control over their working procedures and their charging/accounting.


Figure 3.

Iterative design process for a large scale health network

But eHealth-Systems with telemedical use cases such as second-opinion-possibilities, specialisation and remote working can bring many advantages to primary healthcare providers. A new interaction room and a joint task force for care for patients can be created. Many healthcare professionals also are very innovative and interested in new technologies. It is in the hand of the system operators/owners to win these professions for the new eHealth systems, even if often the system owners as budget-holders are natural opponents to them.

3.2. System acceptance for health insurances

The system of mutual insurance against common risks of illness (modern social security) was built as a process of industrialization at the end of the nineteenth century, first at factory level, and has then developed into a general public system. In almost every nation with social security system, there exist the obligatory social and health insurances and beyond them the private insurances.

Health insurance companies can benefit from eHealth systems by making efforts to compete with other health insurers in offering faster, modern and appropriate services to the citizens. eHealth systems integrating insurances usually are planned for the billing process connecting directly to the healthcare providers. The requirement of neutral bodies, which provide individual citizens with reliable information on the quality of certain medical services would be a natural task for them. As budget holder and the payer they could be a trust worthy informant for the individual citizen.

3.3. System acceptance for hospitals

Hospitals belong to the so-called acute-care institutions that are required to provide 24x7 emergency operation. The funding and management of such institutions is subject to its own laws, interventions from outside without understanding these structures are generally not appropriate. Individual hospitals are often focused on the latest practices in specific disease areas (cancer clinic, heart clinic, cosmetic surgery, etc.). These two special features give some hospitals - either for geographical or medical reasons - a kind of unique position in the medical supply area and the position to be able to build and operate their own eHealth systems autonomously. The role of hospitals in a nationwide eHealth system therefore has to be clearly defined; interfaces and interoperability of the hospital legacy system to the new eHealth systems play a major role in the overall acceptance, as hospitals also are usually holding most of the patients’ data.

3.4. System acceptance for pharmacies

Interestingly pharmacists are experienced and good traders and find usually common ways to pursue new tasks in interoperable and entity-connecting eHealth infrastructure systems. Easy to imagine, for example, it would be the pharmacist, who could serve as regional patient data lawyer, because he himself is not treating actively and still has a certain sound medical understanding and is trusted over any doctors for the patient as a neutral instance. Next to the normal business case of selling medicines new business cases such as the mentioned data lawyer or medical consultant can be supported by eHealth systems.

3.5. System acceptance for nursing and nursing homes

With the increased life expectancy in developed countries, the home care and nursing market will develop further and eHealth systems can offer a technological basis for this, supporting patients needs and rights. From the perspective of medical documentation is to be noted that a large-scale eHealth system in principle should offer the possibility to document the treatment and disease progression in non-clinical care area in a compact way to serve the spirit of integrated care and to achieve complete supplementary documentation for care during a full care process of a patient. Transparency of medication for different institutions, referral from hospital care to home care with all necessary patient data improve the treatment result of nursing professionals with decreasing the error rates due to lack of information.

3.6. System acceptance for patients

As already mentioned in chapter 2.4 the acceptance among patients is an important aspect for a successful launch of any eHealth project. The remarkable and paradoxical fact is, that the main and relevant “Institution Patient” for the development of a large-scale eHealth system has no clearly established interest group to defend their requirements and goals individually. Healthcare institutions have emerged from issues as financing, profession and qualification, access, community care and abuse prevention. The resulting institutions are now mandated to take over these roles for patients.

The topics here are patients' rights, protection of privacy, access to authentic medical information, data sovereignty of the patient, availability of information to qualified hospital staff in an emergency, etc. (Batami, 2001). All these are issues that require special and clear accentuation obtained from the patient's perspective.

A starting point for further studies can be found in (Hackl, 2009) where the acceptance and fears towards an EHR of patients is reviewed and in (Hoerbst, 2010) where this is discussed from the point of view from physicians.

4. Operational level

The operational level is where the actual administration and management of an eHealth system occurs. The eHealth system maintains sensitive data; therefore everything should be tracked, measured, analyzed and planned accordingly. The operational level has to fulfil the needs raised by the technical level and the political level – so the operational level may start with acquiring the requirements from the technical and political level.

In the operational level a few important aspects need to be answered and discussed:

  • Adaptability and framework quality: can your system be adapted when new requirements arise?

  • Locality of medical or e-Health services: from where and by whom can the service be accessed?

  • Accessibility and Ownership of patient or treatment data: who is the owner of the data and how can it be accessed?

  • Maintainability of systems and networks: The developed standards need to be maintainable with respect to future organizational changes and/or technological advancement within the given environment of human or infrastructural resources.

  • Integratability and interoperability of heterogeneous systems: how can new systems or services be integrated into the eHealth infrastructure? The technical design and standards must ensure ongoing information flow between all nodes of the network and system, considering heterogeneous existing IT infrastructures.

  • Transparency of data transmission and audits: data transmissions should be traceable by the users.

These aspects are described in more detail in the next sections.

4.1. Adaptability and framework quality

A large-scale eHealth project will not be static - it will continuously grow in size (in terms of users or user groups and requirements). So these requirements or users should be able to be easily integrated into the system. The choosing of a flexible and adaptable framework is necessary to allow the ease of adaptation. This is not reduced to only technical changes but also to organizational ones. If there is an organizational change, which might be happen throughout a long large scale eHealth project, the operational level has to continue the work. This might be achieved by a flexible and easy adaptable framework.

4.2. Locality of medical or e-health services

It should be determined what the purpose of a service or system is and who the users are. Where are access points for the end-users and should it be accessible from everywhere with no restrictions (e.g. a PHR which is accessible from every web browser) or should this be restricted (e.g. a HIS can only be accessed from within a hospital)? Depending on this purpose adequate security measures (e.g. VLAN or VPN on network level) should be taken into consideration. A system or service, which is available from everywhere, is potentially more susceptible to unauthorized access and fraud, e.g. when someone has stored his medical data in a PHR and his login and password is stolen by malicious software the thief can easily access the data from everywhere. As opposed to this it would be more difficult if the thief has to be in the same LAN or can only access a system or service from a specific terminal.

4.3. Accessibility and ownership of patient or treatment data

The ownership of patients’ data is in most cases determined by juridical restrictions, which are different in every country (e.g. who is the owner of the data in a national EHR). If the eHealth project is set in more than one country, juridical advice might be necessary from all participating states. Even if this is not the case the chance for patients to have control over their own data might be a great benefit of the system/service.

To access the data it is necessary, that the system or service is available when the end-user needs to access it. See chapter 5.4 for further information about reliability and availability.

4.4. Maintainability of systems and networks

Highly available, fault-tolerant large-scale systems and networks tend to be hard to configure and maintain. Simplicity of maintenance has to be guaranteed on any level of network design to make integration processes for further components as easy as possible. Defining a update-cycle may positively influence the maintainability. When it comes to maintenance a definition of service level agreements or operational level agreements are necessary to deliver a highly available system - which is needed in an eHealth project with sensitive data involved. The end user also might want to know when maintenance is happening. When it comes to problems while using the system, a single point of contact for the end user is useful, where he can ask questions or address new problems.

4.5. Integratability and interoperability of heterogeneous systems

This design criteria is strongly related but not limited to future developments (i.e. applications, services or new infrastructure components). Often large eHealth projects need to include interfaces to clinical and billing systems - so the integratability and interoperability has to be available from the beginning and not exist only in some future implementation. This is important especially when integrating new services or connecting heterogeneous systems. To ensure this, without too much additional implementation effort, standards should be used where possible. There are multiple available standards to choose from e.g. IHE or HL7. An evaluation of available standards to fit the systems is required to find the right standard.

4.6. Transparency of data transmission and audits

EHealth systems contain sensitive data (e.g. health status of a patient). If this data is stolen there will be a huge reputation loss for the system, especially if this was not the fault of the patient himself (e.g. application bugs). There also might be scenarios, where a health care professional is looking at medical metadata without a reason and the patient wants to know about this. Everything, which is stored, changed or read, should be documented and logged - this includes who has taken an action and when it happened. Audits allow the complete tracking of who accessed what and when, without knowing the content of the accessed data. This can only be achieved by encrypting the sensitive data and therefore this has to be integrated into the design process on the operational level.

5. Technical level

The technical level is where the actual implementation occurs. Mistakes on this level, for example insufficient security measures may lead to catastrophic consequences in the future. A large eHealth project can only work if the other levels support and not hinder the technical progress of the project. Issues on a political level nearly always have a direct impact on the technical implementation and therefore on the whole project. These issues often lead to missed deadlines, increasing financial requirements and possibly to loss of support in the public.

The main design criteria on the technical level can be classified into the following categories:

  • Security: Measures to guarantee a secure system on a physical level and on the application level.

  • Usability Engineering: Criteria for a successful usability engineering process.

  • Scalability: Aspects of extending the project on a technical level.

  • Infrastructure Reliability: Aspects of maintaining sufficient system availability.

5.1. Security and privacy implementation

Security is by far the most important aspect in the implementation of any health related system. Insufficient security measures may lead to major problems on a personal and political level. Health care information about a person is not only important to the individual but may also be valuable to other parties (e.g. employer, insurer). Therefore it is essential, that the access to this information is sufficiently and future proof secured (Dantu, 2007). An official compromised system will also have major implication on a political level. In the worst case it will require a complete suspension of either the on-going project (e.g. if a pilot system has been compromised) or the running system. A suspension of such a system has not just negative image implications for all participating parties, but will also require a high amount of financial resources to fix it on a technical level. Many modern large-scale IT projects utilize the Common Criteria for Information Technology Security Evaluation (CC) standard (ISO/IEC 15408) for defining and assessing their security requirements. This approach has the advantage, that because of CC’s generic nature, it can be customized to the project’s individual needs.

There are three main categories of security concepts, which have to be observed when designing an eHealth infrastructure:

  • On-site security: Securing the physical components of the eHealth infrastructure.

  • Communication security: Securing the communication between the separate components.

  • Application security: Securing the application components.

5.1.1. On-site security

On-site security deals with all aspects of securing the physical components, which are either used to store, or access confidential information. These components may include the server infrastructure of a centralized electronic health record storage, computer systems in a medical practice or smartcard readers that are used to control the health care professionals or patients access to the health infrastructure. Depending on the political environment, the requirements for on-site security may differ from the security requirements of the general population (e.g. allowing lawful inspection on one hand and technically eliminating unwanted inspections on the other hand). On-site security is usually implemented by organizational measures (e.g. limit physical access to core components).

5.1.2. Communication security

Communication security can be split into two parts:

  • Securing the physical connection.

  • Securing the transmission channel.

While establishing onsite-security is achieved by restricting access to network centres, this cannot be achieved organizationally for the actual physical link (i.e. fibre channels connecting the sites). As there is no practical defence against eavesdropping on network traffic on the wire The network traffic can be disclosed by touching (fast prism-splice devices generating a non disruptive Y-connection for the eavesdropper) or even non-touching methods (e.g. appraising Rayleigh-scattering) all inter-site connections have to be considered as insecure. While eavesdropping on the fibre links could be protected against by hardware encryption modules, this would not protect against eavesdropping at the core routers themselves or at the handover points to client locations or the central application servers.

Hence all confidential traffic within the network cannot be secured by the network itself but rather needs to be secured by point-to-point encryption (typically achieved by asymmetric or hybrid cryptosystems) between client and services endpoints. Therefore securing the actual transmission need to be handled on an application level.

5.1.3. Application security

Application security measures deal with all aspects of securing the actual application components. This not only includes the infrastructural backend components but also all interfaces that are used to connect to the system. As mentioned previous in the previous section, a secure transmission cannot be guaranteed on the physical level. Depending on various environmental factors (e.g. laws, regulations) various cryptographic methods may be utilized. An important aspect is that the cryptographic technology can be upgraded without losing previous data.

If external components are going to be allowed to access the system, security specification must be in place in time. Further, organisations have to be nominated or created to perform a security validation against the individual components. In addition the system as a whole has to undergo regular security audits.

5.2. Usability engineering and user tests

The general aim of large-scale eHealth projects is to give the target population access to medical information in a way that is not possible at the time of the project inception. Depending on the ultimate project goal, various usability aspects have to be taken into account. Especially in regional, national or international projects a diverse population is present. These projects deal with a young population, handicapped people, elderly people and people with a diverse educational background. If the end-user is required to participate in the resulting eHealth system (e.g. a nationwide health insurance card) the system has to be designed in a way that no one is excluded. The unique character also prohibits the unreflected exclusive use of usability engineering best practices. If an insufficient amount of effort is applied in this project phase, the project will provide additional points to attack the project by its opponents. The nature of such a large project also requires, that usability tests are continuously performed and that the end-user interfaces are engineered around these usability test results. The main challenge in usability engineering of health related IT projects, is aligning usability requirements with security requirements. If for example the access to the eHealth system requires a smartcard with a not individual selectable six digit PIN, it will result in a low acceptance with the potential security risk of everybody writing the PIN directly on the card.

5.3. Scalability for change process implications

Scalability in large IT systems refers to all aspects of extending the projects either vertical or horizontal. While the concrete project extensions are defined and decided on a political level, it is advisable, that the technical level includes potential scalability aspects already in the core architecture. A typical problem when extending a running system is a closed core architecture. If a system is designed and implemented only for the specification of the initial project, without including the possibilities to extend the system, any extension will require a significant higher amount of financial resources and will cause an increased project duration.

Typical extension scenarios include:

  • Including additional regions.

  • Including additional user groups.

  • Adding electronic health record related topics.

  • Adding electronic prescription.

Every additional functionality will also involve a certain degree of horizontal extension; therefore both aspects will have to be evaluated before approaching any extension project.

5.3.1. Horizontal extension

A horizontal extension of an eHealth system is the inclusion of a larger target audience. This usually means the inclusion of a new region, different health care professional (HCP) specialities or a patient population. There are various political and technical reasons behind such a horizontal extension. Many national eHealth infrastructure projects tend to start with only a few regions for the pilot testing and then include new regions after the successful pilot completion. Another possible scenario is that legal requirements prohibit a certain target population from participating in an eHealth infrastructure project in the implementation phase, but, since such a project usually takes several years, may be allowed to participate at a later stage.

On the technology level a horizontal extension requires measures to increase networking and backend infrastructure. When attaching new regions to the existing network, it is necessary to evaluate the current state of broadband availability. While urban and suburban regions usually have a good availability of current broadband technologies like DSL, Cable, UMTS, etc., this cannot necessarily be said for rural regions. When planning a large eHealth infrastructure project it is therefore essential to define strategies on a technological level on how to cope with differences in networking infrastructure. For example: If the new system requires an always-on connection from the HCP, it will create problems when attaching an HCP in a region without broadband Internet access.

5.3.2. Vertical extension

A vertical extension in comparison describes the addition of new features in the eHealth infrastructure. An example for this is the addition of a nationwide electronic health record to a system where only a limited emergency dataset exist. As described in section 2.2 there could be multiple reasons for adding functionality to an eHealth infrastructure. While a horizontal scalability mostly requires measures for increasing performance when adding more users to the system, a vertical extension requires sufficient extensibility on an application and backend level. In modern software development process, these extensibility mechanisms are not new, but they have to be careful planned. Extending a system, which was not built for extensibility, requires higher financial resources and a longer duration to finish.

5.4. Reliability to support eHealth systems availability

Availability is the probability that the system is operating properly when it is requested for use. A system, which is used 24/7 to access critical data, which is the case for most eHealth systems, requires an availability of almost 100%. A high and reliable system availability from a political point of view is especial important in the months following the project launch. Every significant offline time, even below an hour, will create negative press and will lower the acceptance rate. To avoid this unnecessary project risk, it is important to introduce modern redundancy and general availability technologies and methodologies in the infrastructure and application architecture. By now, there are more than sufficient technical possibilities to facilitate the necessary availability.

Several categories of events can lead to unavailability of the system:

  • Failure of the underlying hardware (e.g. switches, servers, data storage components)

  • Failure of the housing infrastructure (flooding, power, air condition etc.).

  • Broken physical connections (e.g. cabling)

  • Very high latency (i.e. longer than network timeouts) due to excessive arbitrary usage of the network by other users

To avoid unavailability due to component failures a concept of redundant everything is required. In theory “everything” means really everything: not only switches, cables, power supplies, buildings, air condition units, power lines, but also operating systems and maintenance staff. In extreme cases, redundant switches would have to be from different vendors utilizing different operating systems to protect against systemic failures in operating systems. This also means that the maintenance staff is required to have different training and different operating procedures to protect against systemic procedure errors that could lead to downtime. High latency can be avoided by implementing sufficient Quality of Service (QoS) methods. The concrete QoS settings will have to be established during the first pilot and test phases. Ensuring availability is one of the major functions of every infrastructure operations centre. Permanent monitoring and automatic alerting in case of system failures (or system fail-over) guarantees short response times and normal system operations.

6. Natural order of criteria levels

Institutional criteria (IC) map the needs of the different stakeholders within their historically grown environments of the health system: e.g. patients have to learn about the idea and the use of a large scale health IT system; doctors need to be taught about their role, pharmacies hold a special role with e-prescriptions and can e.g. become independent “personal health data lawyers” for patients; hospitals can and will provide professional EHR services and have to define their role within the health telematics system; insurances play a crucial role in building up the infrastructure and have to redefine their organizational role within the opportunities of the new infrastructure.

Political criteria (PC) manage the mindsets and common national notion of the health telematics. Such a project will fail if public trust in the system vanishes. Trust will vanish e.g. if growth is not done step by step on the basis of serious field tests. Public acceptance must not be lost in any phase of construction. Another important political criteria is a countries’ own health system history: any reasonable system has to build on that history and migrate step by step. Cultural aspects will be highly important in actual use and acceptance. We will not highlight this issue here in further detail as these reflections lead beyond the scope of the focus at hand.

We need to emphasize though that according to our experiences in several projects any nation-wide public health IT project has to obey a hidden rule of criteria priority:

PC > IC > OC > TC.


Figure 4.

Natural Order of Criteria Levels

The view of the public and the attitude of the people are most critical for the success of a nation wide health IT system. Some examples: even a perfect understanding and coordination between doctors, insurances and ministries will be a weak instrument against a publicly discussed case for e.g. patients’ health data misuse by employers or by credit banks (PC > IC).

If one of the stakeholders (e.g. insurances) is hurt in its basic interests they will (openly or secretly) foul the process of construction large scale or national health telematics. No matter how complete your project organization is, you cannot build the system against a stake-holder (IC > OC).

Your technical components and architecture can be highly elaborated and sophisticated and all-problem-solving, but your system will be a fail, if e.g. your roll out scenarios and project integration concepts are not realistic, competitive or do not match with the given industrial and administrative facts (OC > TC).

Managing the whole process of establishing a state-wide health IT infrastructure affords a thorough reflection of the above priority levels as a constant attitude from the drivers of the project. If obstacles arrive in the process of establishment the team in charge has to identify the cause and its criteria level. Removing the obstacle and finding the solution will usually be done within the according level of the nuisance. Solving IC problems by e.g. TC means will always fail. Yet, to our experience this type of level mismatch phenomenon does appear frequently within such large public IT projects. This phenomenon then becomes the cause of unstructured decision making: e.g. institutional top-management (who is in charge of the global vision and general goals of the system) will discuss small technical details. – The operative team in charge of such a project needs to maintain a sane process of decision making respecting the cited levels of construction criteria.

7. Conclusion

The introduction of large eHealth systems cannot be done in a day. Before approaching such a project, the participating parties need to define common goals and draft an approach of how they are going to achieve these goals. When this is done the planning and implementation of the project can begin. During this phase many discussions with representatives from the affected population will happen. Each of these groups will have certain reasons either for or against this project and won’t hesitate to mobilize a public movement to support their claim. Therefore it is essential that these discussions are handled correctly.

Every new large eHealth project has unique problems and goals which need to be included in the design process throughout the whole process from the project start to the project end.

Table 1 summarizes the aforementioned design criteria, which can be used to reduce risks, increase acceptance and give guidance from the political to the technical level of a large-scale eHealth project. Naturally the mentioned design criteria can be enhanced with project specific design criteria, e.g. on the operational level rollout mechanisms, program or project management, maintenance and operation aspects and can be seen as flexible starting point to categorize typical large scale eHealth infrastructure projects.

The authors have been in charge for consultancy and engineering tasks in many eHealth projects: from the technical implementation of ePrescription or modules for electronic health record systems (technical level), over the management, operations and maintenance of existing systems (operational level), to the consultancy of e.g. hospital IT managers (institutional level) and up to the consultancy of Health Ministries of different countries (political level). In the respective levels the identified criteria have been applied, though not in an explicit way, but in as analysis, precondition and alignment of the relevant tasks. This chapter therefore summarizes the experiences to a catalogue which can be applied, checked and amended in future tasks in the health systems area.

Building a modern large or nation-wide health infrastructure provides several promising options in administrative as well as medical progress. In its mature stage, nations will coordinate their health professionals and health budgets in a more effective way not only on the domestic level. They will cooperate and share resources in integrated environments on an international level. The technical-organizational way to arrive at this advanced stage is still very long to go. Brute-force top-down approaches will fail dramatically. The great objective “Unity in Diversity” in health IT connecting all people and institutions into one system needs an organic bottom-up approach. E.g. WHO top-down approaches can support and guard that but are unfit to be the main drivers of that process. Drivers and promoters are regional and national. Integration and connection in health IT must succeed on the national level first. – Overall the whole process requires a permanent attitude of unity from all stake-holders. May it last more than a decade: IT today provides the means of merging doctors, clinics, hospitals, nursing homes, pharmacies, ministries, and insurances into one coordinated health service provider for the benefit of all of us.

8. Acknowledgements

The authors want to thank all colleagues at INSO and RISE, who support the research in Medical Informatics and successfully work in the implementation of smaller and larger eHealth projects. Their vast experience has supported the content and categorization for this chapter.

LevelsDesign criteriaChapter
Political Level = Political Criteria (PC)Consideration of cultural aspects and historical development in healthcare
Appropriate and necessary innovation
Healthy Growing: Creating a healthy eHealth Infrastructure Step-by-Step
Appropriate design of media presentation, dealing with fears and enhancing Acceptance
Appropriate allocation at the general governmental level
Representation in parliament and other representative organisations for citizens
Appropriate legislative measures to accompany the implementation process and operation of the system
See Chapter 2
Institutional Level = Institutional Criteria (IC)System Acceptance for Primary and secondary healthcare centers
System Acceptance for Health Insurances
System Acceptance for Hospitals
System Acceptance for Pharmacies
System Acceptance for Nursing and Nursing homes
System Acceptance for Patients
See Chapter 3
Operational Level = Operational Criteria (OC)Adaptability and framework quality
Locality of medical or e-Health services
Accessibility and Ownership of patient or treatment data
Integratability and interoperability of heterogeneous systems:
Transparency of data transmission and audits
See Chapter 4
Technical Level = Technical Criteria (TC)Security
Usability Engineering
See Chapter 5

Table 1.

Design criteria


1 - S. Batami, 2001 Patient data confidentiality and patient rights, in International Journal of Medical Informatics, 62 1 41 49 .
2 - R. Dantu, H. Osterwijk, P. Kolan, H. Husna, 2007 Securing medical networks, in Network Security, Volume June 2007, 6 13 16 .
3 - Eysenbach 2001 2001, What is e-health? In Journal of Medical Internet Research. (online journal)
4 - Gunter T.D.and Terry N.P. 2005 The Emergence of National Electronic Health Record Architectures in the United States and Australia: Models, Costs, and Questions in J Med Internet Res 7(1.)
5 - W. Hackl, A. Hoerbst, Ammenwerth, 2009 2009. The Electronic Health Record in Austria: Physicians’ Acceptance is Influenced by Negative Emotions, in Studies in Health Technology and Informatics, 150 140 144 .
6 - A. Hoerbst, C. Kohl, P. Knaup, Ammenwerth, 2010 2010. Attitudes and behaviors related to the introduction of electronic health records among Austrian and German citizens, in International Journal of Medical Informatics, 79 81 89 .
7 - E. Larsen, 2003 Standards Insight: An Analysis of Health Information, 2003 Annual HIMSS Conference
8 - J. Tan,, 2005 e-Health Care Information Systems, Jossey-Bass.