Download - ESO eHealth-INTEROP FinalReport v1000...eHealth-INTEROP Report Page vii Foreword to the eHealth-INTEROP Report I got involved in standards back in 1987, working for a small software

eeHHeeaalltthh--IINNTTEERROOPP RReeppoorrtt

iinn rreessppoonnssee ttoo eeHHeeaalltthh IInntteerrooppeerraabbiilliittyy SSttaannddaarrddss

MMaannddaattee ((SSAA//CCEENN//EENNTTRR//000000//22000077--2200 eeHHeeaalltthh MMaannddaattee MM//440033 –– PPhhaassee 11))

hhttttpp::////wwwwww..eehheeaalltthh--iinntteerroopp..eeuu

httttp::////www..ehealltth--iintterrop..eu

eHealth-INTEROP Report

Page ii


Page iii

Document Information: SA/CEN/ENTR/000/2007-20 eHealth Mandate M/403 – Phase 1 Report

Warning

This Report was produced under a contract from the European Commission, managed by NEN. 5

The views expressed may not in any circumstances be regarded as stating an official position.

Neither the European Commission, nor NEN, nor any person acting on behalf of either, is responsible for the opinions expressed or the use that might be made of the material included.

10

Document Location: http://www.ehealth-interop.eu Validity: From date of publication until approval by ESOs, EC and EFTA. File name: ESO_eHealth-INTEROP_FinalReport_v1000-plain-cover.doc

Change History Summary:

Date Version (n.Nnn)

Changes file name format: ESO_eHealth-

INTEROP_v0Nnn_CCYYMMDD.doc

2008-04-01 < 2008-05-19 0.001 – 0.024 Internal PT drafts.

2008-05-19 0.025 Interim draft as background information to Wider Co-ordination Group meeting on 2008-05-28.

2008-06-06 < 2008-06-24 0.100 – 0.117 Responses to Gothenburg consultation included – much re-organised and new content added.

2008-06-24 0.200 Second draft to Wider Co-ordination Group meeting and for general comment.

2008-07-15 0.300 Third draft as pdf file to website for general comment.

2008-08-25 0.400 For i2010 and WCG review.

2008-09-19 0.500 v0454 saved as v0500 and converted to pdf for public comment.

2008-11-26 < 2008-12-18 0.600 – 0.623 Post-comment internal editing.

2008-12-19 0.700 - 0.703 Final internal editing.

2008-12-23 0.920 Pre-approval Report to ESO TCs – Refs completed

2009-02-10 1.000 Final version approved by CEN, CENELEC and ETSI 15

Editorial project team:

Pantelis Evangelidis, Georg Heidenreich, Charles Parisot, Melvin Reynolds (lead editor). 20

Please submit any comments on this document to:

Ms Mary van den Berg Standardization administrator

[email protected] Tel.+ 31 152 690390 Fax + 31 152 690190

Ms. Shirin Golyardi Standardization consultant

[email protected] Tel.+ 31 152690313 Fax + 31 152690563

NEN-Healthcare Vlinderweg 6 NL-2623 AX Delft

http://www.ehealth-interop.eu


Page iv


Page v

Contents Contents ................................................................................................................................... v Foreword to the eHealth-INTEROP Report.............................................................................vii Guide to the reader ................................................................................................................. ix Summary of the eHealth-INTEROP Report............................................................................. xi 5

eHealth-INTEROP Report ........................................................................................................1

1 Scope..............................................................................................................................3 2 Background.....................................................................................................................5

2.1 Market influences...............................................................................................................5 2.2 Definitions ........................................................................................................................12 10

3 Standards......................................................................................................................21 3.1 General introduction to standards activities.....................................................................21 3.2 ESO Standards activities .................................................................................................21 3.3 Other Standards activities................................................................................................24 3.4 SDO coordination in eHealth ...........................................................................................37 15 3.5 Standards deliverables ....................................................................................................38 3.6 Standards process...........................................................................................................39 3.7 Barriers to standards adoption.........................................................................................41 3.8 Standards inventory .........................................................................................................44 3.9 The safety / security, privacy dilemma.............................................................................46 20

4 Standards Adoption and Lifecycle ................................................................................47 4.1 General considerations....................................................................................................47 4.2 Achieving interoperability in eHealth................................................................................47 4.3 The different classes of standards-related specifications................................................49 4.4 From standards-related specifications to quality implementations..................................53 25 4.5 Establishing organisation, coordination and governance ................................................57 4.6 International experience ..................................................................................................63

5 Inventory of requirements .............................................................................................65 5.1 Requirements analysis ....................................................................................................65 5.2 Business requirements and use cases............................................................................66 30 5.3 Requested eHealth application topics .............................................................................67

6 Proposed workplan strategy .........................................................................................75 6.1 General strategy ..............................................................................................................75 6.2 Overall coordination and governance strategy................................................................75 6.3 Use cases strategy ..........................................................................................................78 35 6.4 Base standards development and maintenance strategy ...............................................80 6.5 Profile development and maintenance strategy ..............................................................82 6.6 Profile implementation quality assurance strategy ..........................................................83 6.7 Best Practice Forum strategy ..........................................................................................84 6.8 Workplan summarised .....................................................................................................84 40

7 Conclusions ..................................................................................................................87 7.1 General ............................................................................................................................87 7.2 Background – conclusions...............................................................................................87 7.3 Existing standards activity – conclusions ........................................................................87 7.4 Standards adoption and lifecycle – conclusions..............................................................88 45 7.5 Inventory of requirements – conclusions .........................................................................89 7.6 Workplan strategy – conclusions.....................................................................................90 7.7 EU Study on the specific policy needs for ICT standardization.......................................91

8 Proposals ......................................................................................................................93 8.1 General proposals............................................................................................................93 50 8.2 Business use case definition and prioritisation................................................................93


Page vi

8.3 Base Standards development..........................................................................................94 8.4 Profile development and maintenance ............................................................................95 8.5 Profile quality assurance, test plans and tools ................................................................95 8.6 Sharing of best practices in deploying eHealth projects..................................................95

Abbreviations and glossary ....................................................................................................... I 5 Abbreviations ................................................................................................................................I Glossary ......................................................................................................................................III

References ...............................................................................................................................V

Annexes available from http://www.ehealth-interop.eu : 10

Annex A – eHealth-INTEROP Report in response to EU Mandate/403-2007: Inventory of Standards.......................... ESO_eHealth-INTEROP_A0900_20081222.pdf

Annex B – eHealth-INTEROP Report in response to EU Mandate/403-2007: Patient and Provider Identification ........ ESO_eHealth-INTEROP_B0900_20081222.pdf

Annex C – eHealth-INTEROP Report in response to EU Mandate/403-2007: 15 Semantic Interoperability ...................... ESO_eHealth-INTEROP_C0900_20081222.pdf

Annex D – eHealth-INTEROP Report in response to EU Mandate/403-2007: Use Case Examples.............................. ESO_eHealth-INTEROP_D0900_20081222.pdf

20

http://www.ehealth-interop.eu


Page vii

Foreword to the eHealth-INTEROP Report I got involved in standards back in 1987, working for a small software company with a reasonable market share in General Practice information systems. We were involved in a research project to assess the impact of electronic messages between hospitals and GPs on the quality of care. The project had selected X.400 and EDIFACT as a starting point. The project was very successful and 5 was followed by many multi-vendor, multi-region implementations, all using the same set of messages. We even had version control in place.

Then, out of the blue, a standard from abroad was introduced in our country. I remember clearly our annoyance. Why change something that works? Then, after two years, we had two successful communities doing implementations. No problem, because one dealt with messages between 10 hospitals and first line health care, and the other with intra-hospital messages.

Somewhere between then and now, health informatics standards started living a life on their own. With many real world deployment problems, like reliable data transmission, being addressed successfully by others, much of the health informatics standards world lost touch with real deployment. Standards - and more specifically EHR focused standards - became by-products from 15 subsidised research without real testing. Deployed standards – be it on a humble scale – were called out of date. The better became the enemy of the good. Stakeholders like users and industry lost interest in standards development, and started consortia to add what was missing. We, the standards developing world, called it “unneeded competition”. Frankly, it was filling gaps and solving overlaps.

This story should tell you why this eHealth Interoperability Standards Mandate was issued and why 20 this project team of M/403 took a different, requirement based, approach. Phase 2 will start with real use cases from real national and regional projects, will avoid new standards development (unless there is nothing appropriate available) and aims at making existing standards work in today’s practice.

Even this approach is bound to fail if (1) we fail to connect to real projects, (2) we fail to work jointly with other SDOs, or (3) we fail to professionalise the management of the standards lifecycle in the real 25 world. However, when this approach is successful, local/regional projects no longer have to rely on tailor-made solutions.

We received much constructive feedback during our work, especially during a month of Public Comments that included a Webinar on the 2nd October 2008. We processed the comments and then presented the main open issues on 7 November in Copenhagen, in a one-day event to which close to 30 one hundred of you contributed.

Your contributions and encouragements were critical in laying this blueprint, your engagement will be even more needed as the proposals made in this Report are implemented in the second phase of this eHealth Interoperability Standards Mandate.

Kees Molenaar, 35

Chair ESO eHealth INTEROP Coordination Group

Chair CEN/TC251


Page viii


Page ix

Guide to the reader The EU “Study on the specific policy needs for ICT standardization” (see 2.1.1) highlights many of the issues affecting the European standardisation scene across Information and Communications Technology (ICT) in general. Some familiarity with this Study is, in our view, a necessary precursor to understanding the context and recommendations of our Report. 5 Similarly, familiarity is assumed with the European Commission (EC) Mandate M/403 http://ec.europa.eu/enterprise/standards_policy/action_plan/doc/mandate_m403en.pdf

This Report is organised as follows:

Un-numbered sections; are background, informative, material including the summarised proposals.

Sections 1, 2 and 3 – Where we are; provide the scope of the Report, the background in terms of 10 market and political influences, the definitions we have used in our work of over-used and variously interpreted terms, and a review of the current 'standards' activities of relevance to eHealth in Europe.

Section 4 – Surveying the route ahead; looks at the lifecycle of standards, barriers that have to be overcome, factors for success, planning the route, establishing the "rules of the road" and ensuring that those "rules" are followed. 15

Sections 5, 6, 7 and 8 – Moving forward; on the basis of where we are and what we have and know, this part of the Report looks ahead to identification of real requirements - and puts this into practice for the topics area identified as early targets, proposes an outline workplan for the 3 official European standards organisations and then collects together the conclusions and proposals resulting from our work. 20

Italicised text is used for quoted material – and square brackets indicate editorial notes, explanations or deletions […].

http://ec.europa.eu/enterprise/standards_policy/action_plan/doc/mandate_m403en.pdf


Page x


Page xi

Summary of the eHealth-INTEROP Report Background Because this is a summary of the full Report a considerable amount of detail is necessarily omitted for the sake of brevity. For those concerned with the day-to-day implementation of the European Commission (EC) Mandate 5 M/403 (the Mandate), reading this Summary is not therefore a substitute for familiarity with the full Report.

The Scope (1) of the Report is defined by the Terms Of Reference of the Project Team appointed to carry out phase one of the Mandate. Familiarity is assumed both with the Mandate and with the 2007 EU Study on the specific policy needs for ICT standardization, which highlights many of the issues 10 affecting the European standardisation scene across ICT in general.

Where we are The background (2) of previous advisory groups on eHealth standards is reviewed briefly, as are definitions (2.2) central to the topics covered in the Report. Current activities in the 'standards' area impacting eHealth are reviewed (3) – recognising that not all 15 such activities are undertaken by formally constituted standards development organisations. A comparative review of the European standards organisations precedes descriptive reviews of the role and processes of other significant 'standards' development and adoption organisations. The existing, and earlier, eHealth standards coordination efforts are reviewed briefly in 3.4 before the different deliverables and processes are described. 20 Barriers to adoption of standards are discussed in 3.7 and a preliminary (inevitably incomplete) inventory of relevant eHealth standards (Annex A) is then introduced.

A short section (3.9) examines the relationship of safety / security, privacy issues in eHealth to those impacting society as a whole and other e-Processes in particular.

Surveying the route ahead 25

Having thus surveyed where eHealth interoperability is at present, we turn our attention in Chapter 4 to the route ahead: how, at a European level, it could be possible to establish processes to ensure mutual understanding, agreement and cooperation to meet the identified policy goals of EU health ministers. Critical success factors of standards development, but more importantly of standards adoption and 30 implementation in eHealth, are examined in some detail (4) in order to find the road to interoperability in eHealth (4.2). In particular, a use case based approach is recommended. This is followed by a more detailed analysis of the different classes of standards-related specifications (4.4), which are divided into Base Standards, Profiles and Interoperability Specifications. We see that this provides the clarity necessary to achieve interoperability while offering sufficient flexibility to 35 individual eHealth projects across Europe. We note too that achieving quality implementations needs to rely on widely available testing tools and processes to ensure conformance of implementations to Profiles and the referenced Base Standards. Section 4.5 identifies the need for five major activities to ensure that the 'rules of the road to interoperability' are established and managed. 40 The Chapter concludes with a short survey of international experience of standards implementation for eHealth interoperability (4.6).

Moving forward Based on the use case approach outlined in Chapter 4, Chapter 5 deals with specific requirements. Using readily available examples, we look at requirements from the citizen; care provision and 45 population health perspectives. Annex D provides a review of some example use cases corresponding to these groups. The Mandate required us to address specific topics: patient and healthcare professional identifiers (5.3.2), and the patient summary and emergency data set (5.3.3). For the patient identifier some clear (but not exhaustive) use cases and Profiles have been described. 50


Page xii

Annex B, provides detailed review of the use cases, Base Standards and Profiles available to address patient and, to a lesser extent, healthcare professional identification needs. However, we find that when we seek to apply the use case technique to the other topics they are sufficiently broadly scoped (i.e. set at policy level) that there is no shared European understanding of the specific requirements. 5

With that inconclusive outcome from Chapter 5 we set out in Chapter 6 to describe how, again at a European collaborative level, it could be possible to establish a mutually agreed strategic workplan to meet the policy goal of cross-border care, as well as enabling interoperability at a local (e.g. hospital or home) and at a regional/national level. Existing organisations engaged in each one of these activities are reviewed and proposals are made 10 for the Phase 2 of the Mandate in order to leverage their experience, and the need for an overall coordination at the European level is discussed (6.2). Starting with the key policy use cases (6.3), seven use cases are proposed for consideration at the European level within the first year of Phase 2 consistent with the necessary ramp-up of European-wide stakeholder engagement in delivery of the eHealth Standards Mandate. 15 The proposed phased deliverables address regional/national patient summary and prescription use cases; two use cases (ordering and results distribution for radiology enterprise workflow allied to regional or radiology cross-enterprise information sharing); and then three new use cases for laboratory enterprise workflow, laboratory cross-enterprise information sharing and for ubiquitous care outside conventional care facilities, initially focussed on remote monitoring. 20

Recognising that other use case related needs may emerge, the main areas of Base Standard priorities are currently identified (6.4) as being: 1) Fill gaps; a) continue support for safety / security and privacy strategy, b) enable development of infrastructure for care outside conventional care facilities, 2) Facilitate semantic interoperability; a) enable support for terminological interoperability in support of 25 use cases, b) enable safe semantic interoperability, and c) facilitate Maintenance arrangements, 3) Resolve inconsistencies, and 4) Increase European impact in international standardisation.

In Chapter 7 we gather together as Conclusions the "Anchor points" that have been highlighted throughout the Report. 30

Proposals Our proposals are set out in full in Chapter 8 and are, in summary, as follows:

A "European eHealth Mandate Coordination Group" should set, and monitor, the high-level business objectives.

Structure activities around five entities to execute the core outcomes of the eHealth Standards 35 Mandate and organise these activities so that they become effective in 2009 and sustainable after the end of the eHealth Standards Mandate, taking account of existing, and emerging, standard based solutions to ensure viability in a global market. The objectives set for each one of these five activities is discussed below.

1 Business use case definition and prioritisation 40

For Phase 2 of the eHealth Standards Mandate, it is proposed to establish a small project team under joint oversight of i2010 (Member States) and Stakeholder Group (users and industry), in the context of and in cooperation with other similar initiatives, to analyse, consolidate and prioritise use cases for Profile Specifications in Phase 2 and thereafter.

The following specific proposals are therefore made as the basis for discussion, possible change, and 45 agreement (see 6.3.3.1): in Phase 2 (2009) 4 use cases for Profile Specifications focus, an additional 3 for Profile Specification in 2010 and a rolling plan thereafter.

1.1 Two generic intra-country (2009) use cases Use epSOS driven cross-border cases to provide complementary intraregional/national use cases:

1. regional / national patient summary information sharing, and 50 2. regional / national prescription information sharing.

1.2 Two high-priority additional (2009/2010) use cases 1. radiology enterprise workflow, and


Page xiii

2. radiology cross-enterprise information sharing.

1.3 Three follow-on (2010) use cases 1. laboratory enterprise workflow, 2. laboratory cross-enterprise information sharing, and 3. for ubiquitous care outside conventional care facilities, involving the interoperability necessary 5

from mobile and/or home-based monitoring devices.

2 Base Standards development For Phase 2 of the eHealth Standards Mandate, rely on the existing harmonisation entities: CEN, CENELEC, ETSI ICT Standards Board (ICTSB) and Joint Initiative Council on SDO Global Health Informatics Standardization (JIC); and improve their efficiency by means of four identified actions. 10

2.1 Fill gaps in provision Identify and fill gaps in the work Base Standards programme that need to be resolved at the European and International level in order to enable use case priorities to be met.

2.1.1 Enable development of integrated safety / security and privacy strategy Standards for safety / security and privacy in eHealth should continue to be developed, in concert 15 with those for other e-Processes, with a clear plan for accommodating the needs of existing related sector-specific arrangements.

2.1.2 Enable development of integrated infrastructure for care outside conventional care facilities In accordance with the motivating Rationale of the Mandate, enable timely use of key 20 communications infrastructure components (such as body and personal area networks) needed for integrated ubiquitous care (monitoring, well-being, assisted living).

2.2 Facilitate semantic interoperability The longer-term goal should be to enable harmonisation among the various national terminologies and the adoption of consistent (at least) pan-European terminologies. 25

2.2.1 Enable consistent terminological representation in support of use cases Recognising that heterogeneity of classifications and terminologies will remain for several years in European healthcare, expand effort in Europe to achieve terminological interoperability in the context of the identified use cases.

2.2.2 Enable support for safe semantic interoperability 30 Continued urgent effort is needed to ensure that the internal relationships in, for example, communication structures are unambiguously linked to the appropriate archetypes, templates, terms, codes, identifiers and/or value sets.

2.2.3 Facilitate maintenance arrangements Provide sufficient resourced impetus to establish real-time, "gold-standard" resources to support 35 semantic interoperability in support of existing and emerging semantic requirements in eHealth.

2.3 Resolve inconsistencies Resolve the inconsistencies, or at least facilitate co-existence, between Base Standards based on fundamentally different principles (e.g. Electronic Records exchange formats using either CEN 13606 or HL7 RIM based documents). 40

2.4 Increase European impact in international standardisation Increase the coordinated contribution of Europe into international standardisation efforts to meet European needs within internationally accepted standards (e.g. for acute and home care device communications with IEEE, terminologies with WHO and IHTSDO, etc.).

3 Profile development and maintenance 45

For Phase 2 of the eHealth Standards Mandate, accredit an entity to ensure that the prioritised and documented Business use cases are broken down into Technical use cases, and specific Base Standards are selected and profiled. For this activity three success factors are identified:

1. the ability to scope the Technical use cases so that the specified Profiles are reusable across several Business use cases; 50


Page xiv

2. have the credibility to attract a good mix of industry, large medium and small and health professional organisations; and,

3. specify the Profiles supporting each Technical use case in an open and timely fashion (no more than nine months from the Business use case availability).

Profiles should cover all layers of interoperability, from transport, through messaging services, to data 5 structures and terminologies; these last two are two of the major elements necessary to provide semantic interoperability in health.

It is recommended to use the processes defined by ISO TR28380 to develop internationally agreed, or Europe specific, Profiles.

4 Profile quality assurance, test plans and tools 10

This activity is to ensure, for Profiles, the development of conformance test plans and test tools under a coordinated process among the various contributors and users. Users include industry which is implementing interoperability in its products, local, regional and national projects, care delivery organisations such as hospitals, clinics, laboratories, pharmacies, imaging centres, general practitioners, etc., for which three key success factors are identified. 15

1. the ability to develop these test plans and tools in a timely fashion so that they could be made available no later than four months after a Profile is recognised for trial implementation;

2. coordinate contributors resources to ensure that quality plans and tools are developed and maintained; and,

3. ensure open access to these test plans and tools and an effective maintenance process 20 engaging the broad range of users.

For Phase 2 of the eHealth Standards Mandate, it is proposed to accredit IHE-Europe in partnership with ETSI, Continua (assuming its capability is proven in time), and possibly others. It is important to link this activity with the existing national testing efforts in some of the European countries, and with international arrangements. 25

5 Sharing of best practices in deploying eHealth project This activity is to give every national, regional or local project a European-wide forum to share experiences and publish best-practice guides that offer guidance in conducting the deployment activities of eHealth projects. In particular, this best practice forum should address the policies for safety / security and privacy in eHealth in concert with those for other e-Processes, with a clear plan 30 for accommodating the needs of existing sector-specific arrangements.

For Phase 2 of the eHealth Standards Mandate, It is proposed to rely on EHTEL and the CALLIOPE project to conduct these activities for 2009 and 2010. Beyond 2010, a permanent accredited European entity needs to be designated to conduct these activities.

35


Page xv


Page xvi


Page 1

eHealth-INTEROP Report in response to

eHealth Interoperability Standards Mandate

(EU Mandate/403-2007) 5


Page 2


Page 3

1 Scope The following text extract is reproduced without change (except for [edited omissions]) from the Terms Of Reference of the Project Teami appointed to carry out phase one of the European Commission (EC) Mandate M/403ii See Glossary and Abbreviations (on page I) for key to acronyms, and Definitions (on page 12) for explanation of key terms. 5

The European Commission has issued in 2007 a mandate to the European Standardization Organizations (ESOs), CEN, CENELEC, and ETSI, to develop a coordinated work programme for standardization in health informatics (Mandate M/403).

A Coordination Group of the three ESOs has been established to collaborate on the preparation of the work programme in consultation with other activities as appropriate; the detailed process is contained 10 in the technical proposal for the work.

The above-mentioned work programme will be provided in the form of an overview report analysing existing work and requirements and contain a list of proposed work items for possible standards action. The resulting report will be submitted to the European Commission as required by the mandate for approval and subsequent execution by the three ESOs as phase 2 of the mandate. 15

Objective

The objective [...] is to carry out phase one of the European Commission (EC) Mandate M/403 by providing an analysis and planning of existing relevant standards, specifications and technical reports (with short descriptions), including work under way, and the creation of a proposed coordinated work programme for standardization in health informatics (eHealth) to be carried out by CEN, CENELEC 20 and ETSI. This programme will cover tasks needed to achieve the goals with priorities to be identified for those deliverables that require an earlier adoption.

The work will entail a particular examination of all the activities and issues mentioned in the mandate, in particular concerning with the electronic health record with its three priority issues:

- patient and health practitioner identifiers; 25

- the patient summary;

- an emergency data set.

It is proposed by the ESOs to establish a collaborative mechanism to elaborate this work programme. This work programme will be provided in the form of an overview report analysing existing work and requirements, and contain a list of proposed work items for possible standards action under phase 2 30 of this mandate. The results will be submitted to the EC as required by the mandate for approval and subsequent execution by the three ESOs.

Rationale

Many conditions of the current health environment are changing at the moment or are expected to change in the near future. On the one hand, the citizen changes - an ever older population, sometimes 35 referred to as the 'demographic challenge', will develop a strong need for different and more differentiated care solutions, ranging from more intensive care to mere tele-monitoring of parameters; an ever more mobile population, both patients and health professionals take the advantage of their mobility and travel to or work in another country within the EU. This shows the urgent need for citizen-centred health 40

[…]

Policy relevance and market impact

The activity will analyse and evaluate all relevant existing activities, both at European and international level. Close cooperation with the political dimension is important. Therefore, the i2010 Subgroup on eHealth, as the Member States' forum, is a means to ensure the involvement and information of the 45 EU member states. The same applies to the Commission's eHealth stakeholders' groups (respectively industrial and user groups). Also, co-operation and mutual information exchange is envisaged with the relevant European Commission services: DG Enterprise and Industry, as well as DG Information Society, Health and Consumer Protection, and Employment. In particular, due account will be taken of the forthcoming Commission Recommendation on eHealth interoperability issues. 50


Page 4

At the European level, special consideration will be paid to the reference bodies within the three ESOs, i.e. the relevant technical standards groups. Furthermore, existing stakeholder groups including the CEN/ISSS Forum and the CEN/Advisory Board for Health Standards (ABHS) will be kept informed. Input from those bodies will be taken into account when developing the work programme.

Internationally, it should be noted in particular that CEN, ISO and the HL7 consortium have 5 established a Joint Working Group under a Charter agreed in August 2007; this will establish a common work programme between the three organisations, which clearly needs to be taken into account under the activity.

Finally, […], close co-operation with international standards bodies, industry, R&D projects and other stakeholders in the process of harmonizing European and international standards will be continued 10 and extended so as to underpin success of the execution of the mandate.

Anchor points: Collaborate on the preparation of the work programme. 15 [Produce] overview report analysing existing work and requirements and contain a list of proposed work items for possible standards action. ESOs to establish a collaborative mechanism to elaborate this work programme. 20 Close co-operation with international standards bodies, industry, R&D projects and other stakeholders in the process of harmonizing European and international standards will be continued. 25


Page 5

2 Background

2.1 Market influences This Report is about the means to optimise European standards development and use to enable interoperability of eHealth applications in Europe and beyond. Inevitably, with applications come two main categories of interests: demand-side, (e.g. eHealth implementation projects, administrations, 5 care professionals, citizens and researchers) and supply-side (e.g. researchers, software developers, systems integrators, service vendors and technologists).

Demand-side interests, whilst being users of applications, do not necessarily share the same viewpoints. Citizens generally want fast, safe and effective delivery of health services at reasonable cost. Administrations might want safe, efficient and measurable delivery of health services at lowest 10 possible cost. Care professionals might seek assistance to deliver safe and effective delivery of health services regardless of cost. Researchers may want very detailed information regardless of its operational role in day-to-day care delivery. Further complexity is added by the consideration that in most situations a demand side entity will play at least two, and sometimes all, of these roles.

Applications are for the most part developed (produced) by industry, i.e. the supply-side. Companies 15 within the eHealth industry fall, broadly, into three categories:

A. International firms that are either focused on general ICT, working on a global scale; or focused on health IT applications;

B. European or national large corporations some of which have the potential or aim to advance to become members of category A; 20

C. National, and sometimes multi-country active, companies that are small/middle sized enterprises (SMEs), in some cases have their own products and/or act as value added resellers (VARs) for one or more of the category A or B companies.

The view of interoperability standards within these companies varies depending on the size and heterogeneity, marketing maturity and culture of demand-side empathy they have. In general the 25 larger and more heterogeneous the company the more will its technical research and development departments value standards as they struggle to keep pace with integration of product ranges from across acquired companies and originating manufacturing sites. Militating against this is the view commonly held in marketing departments that any standards that open interfaces to third party providers reduce the ability to lock-in a customer. This view is not incorrect but it fails to account for 30 the potential market growth that can be obtained by access to other markets when playing the 'third party' role. The experience of some customers is that, instead of claiming conformance, vendors do nothing and ask the (potential) customer what is wanted. Only if a customer explicitly demand conformance to a standard will such a company undertake bespoke work to comply with it, frequently, however, 35 providing a non-conformant "solution" and/or promoting another (possibly even conflicting) standard in another customer site.

Smaller companies, SMEs, tend to fall into two distinct groups: ones that value the access to knowledge and wider market integration that interoperability standards can bring, and those that are sufficiently commercially immature, or so technically led, that they believe that their proprietary 40 approach can dominate markets.

The IT sector in general has a poor reputation for empathy with the demand side, its customers, and this is reflected in its somewhat cavalier attitude to the adoption of, or adherence to, standards. In the health sector it is common for the terms "based on …", " derived from …" to be used in technical and marketing materials – implying a level of conformance, and thus interoperability, not actually borne out 45 in reality. This situation is exacerbated by demand-side ignorance of the detail of the standards to which they are seeking compliance. The resulting confusion has nevertheless enabled a substantial integration consultancy industry to develop; an industry that has had little or no incentive to make interoperability standards easier for both the supply- or demand-sides to comprehend, and thus reference accurately in selling and procurement. 50

Researchers are in both the demand- and supply- sides. On the demand-side the tendency is to drive for standards to support their work of innovation, thus causing a loss of focus on more immediate care benefit requirements. On the other, supply-side, the impetus is toward innovative solutions to


Page 6

'problems' (real or misconceived), which if it feeds directly into the standards space produces plurality and confusion. We will seek to address this tension (introduced by our terms of reference) in our proposals, recognising the need for innovation, direction setting and commercial independence alongside the difficulty that markets for long-life products, such as those in the eHealth sector, have to make more than incremental change. 5

Geographical aspects also influence the supply-side, and thus the economies of scale from which the demand-side can benefit. So, though the Mandate from the Commission corresponds of course to a European perimeter, it should be clear that such activity must be part of a global healthcare environment and consider its impact in that international context.

The EU Study on the specific policy needs for ICT standardizationiii (see 2.1.1) highlights many of the 10 issues affecting the European standardisation scene across ICT in general. Some familiarity with this Study is, in our view, a necessary precursor to understanding the context and recommendations of our Report, so relevant are many of its general observations and findings to the eHealth interoperability challenge. For this reason we will generally refrain from dealing in this Report with the high level challenges created by Member States' policies with respect to the role of the Union (in this case 15 represented by the European Commission), the application of Commission instruments, the increasing globalisation of markets, the nature of interoperability with respect to technological maturity (and the role of research and development), the roles of national standards bodies with respect to stakeholder representation. Some of these we will re-visit in our recommendations in the context of the specifics of the eHealth interoperability challenge, others are outside our direct scope – but which nevertheless 20 will have direct bearing on how our recommendations can be accommodated by the European specifics within the global market.

The initiative by DG Internal Market in bringing forward the Directive on mutual recognition of qualifications has increased the freedom of healthcare professionals to practice outside their country of original qualification or registration within the EU. This cross-border recognition of practice has not 25 yet been matched by the ability of citizens in general to move with any certainty that information necessary for optimal care will be available.

In the context of eHealth there have been a number of attempts to facilitate interoperability. These started in the CEN European Workshop on Open Systems (EWOS) activity and the establishment of CEN the technical committee for health informatics (CEN TC251). 30 The CEN/ISSS eHealth Standardization Focus Group was set up to investigate on standards requirements in the area of 'eHealth' and in March 2005 finalised the Report "Current and future standardisation issues in the eHealth domain: Achieving interoperability"iv. That report contains proposals and recommendations for future priorities for eHealth standardisation activities in support of the eEurope 2005 Action Plan, many of which appear to still be relevant, but which need reviewing for 35 current priorities. The i2010 Group and the Stakeholders Group set-up in 2006-2007 and hosted by the European Commission has, to some extent, continued this rolev. In this context, more recent initiatives are examined briefly below (2.1.2 - 2.1.5).

2.1.1 EU Study on the specific policy needs for ICT standardization This Study, published in mid-2007, on the specific policy needs for ICT Standardisation 40 (ENTR/05/59)iii was undertaken to analyse the present state of the European ICT standardisation policy and to bring forward recommendations for its future development.

The Study:

1. Provides a thorough analysis of the present characteristics of the ICT standardization landscape, and the expected developments within this field over the next 10 years. 45

2. Identifies, in the future ICT landscape, the new requirements to be addressed by standardization policy, in order to strengthen the competitiveness of the EU industry, while also responding to stakeholders’ needs as well as societal and market requirements;

3. Explores the alternatives for a standardization system, based on the complementarity of the policy formulated by the public actors and the operational structures established by the private sector; 50

4. Assesses the current EU ICT standardization policy and its legal framework with a view to accommodating these new requirements, specified above;

5. Elaborates on the alternatives for the future EU ICT standardization policy and its integration to other EU policies (notably research and innovation) from the point of view of the requirements, specified above; 55


Page 7

6. Distinguishes the specific standardization policy measures and their legal requirements, available to be implemented within the future EU ICT standardization system;

7. Analyses how public authorities could more efficiently use standards in support of EU policies and legislation;

8. Identifies policy measures to better promote the results of the EU standardization system and to 5 increase their impact on a global level; and

9. Provides recommendations for future policy actions in the field of EU ICT standardization.

A number of the recommendations of this Report will be reiterated as applicable directly to the eHealth standardisation area.

2.1.2 EC cross-border care initiatives 10

Most competence for action in the field of health is held by Member States, but the EU has the responsibility, set out in the Treaty, to undertake certain actions which complement the work done by Member States, for example in relation to cross border health threats, patient mobility, and reducing health inequalities.

On 23 October 2007 the European Commission adopted a new Health Strategy, 'Together for Health: 15 A Strategic Approach for the EU 2008-2013'vi to guide future work on health at the European level, and to put in place a mechanism to achieve those objectives, working in partnership with Member States.

The Strategy focuses on the three themes of Fostering Good Health in an Ageing Europe, Protecting Citizens from Health Threats, and Dynamic Health Systems and New Technologies. 20

On 2 July 2008, in the context of that strategy and as part of the Renewed Social Agenda, the Commission adopted a draft Directivevii on the application of patients' rights to cross-border healthcare, which provides a Community framework for safe, high quality and efficient cross-border healthcare.

Recognising that the vast majority of citizens receive healthcare in their own country, sometimes it is 25 best provided abroad, such as for example for highly specialised care or in border areas where the nearest appropriate facility is abroad.

To clarify the rules for receiving cross-border care the Commission has developed a proposal for a legal instrument about possibilities to seek healthcare in another Member State. The proposal will also make clear who is responsible for quality and safety of care in cross-border settings. Finally it will 30 strengthen cooperation in different areas, such as networks of centres of reference for specialised care, for example.

2.1.3 The Portorož eHealth 2008 Conference Declaration In this declarationviii, issued in the context of the Portorož Ministerial Conference in May 2008

The Member States and the European Commission […] commit to support together the deployment of 35 high-capacity infrastructure and infostructure for health and social care information networks and services such as telemedicine (teleradiology, teleconsultation, telemonitoring, telecare), ePrescription and eReferral. With continued commitment from all the actors involved, European-wide cooperation on electronic health services will lead to the successful formation of a European health information area. As a result, the health of European citizens and the sustainability of European health care 40 systems will benefit considerably.

According to the declaration:

Three key initiatives must now begin to operate harmoniously alongside each other in order to overcome the major health challenges that lie ahead over the next ten-year period.

- The first crucial area is the need to plan to deploy telemedicine and innovative ICT tools for chronic 45 disease management.

- Second, but equally important, is the need to introduce an enhanced focus on new research opportunities.

- Third, is the need for a transparent legal framework agreed between the Member States. It would help to define the responsibilities, rights and obligations of all the different subjects involved in the 50


Page 8

eHealth process, such as national, regional and local health authorities, health care professionals, patients, insurance companies, and other relevant players.

So, while the declaration refers ePrescription and eReferral as examples of development areas, it alludes to plans to issue a recommendation on cross-border interoperability of electronic health record systems, laying out clear guidelines for arriving at the keenly anticipated scenario of enabling patients 5 to access electronic health records anywhere any time. There is a need to emphasise the improvement to patient safety that ICT can facilitate, especially as a result of the enhanced interoperability of systems. Combining standardization and safety in eHealth must now be seen as a priority issue by all stakeholders. It is fundamental to define a common understanding through semantics in healthcare (see 2.1.4). 10

2.1.4 EC Recommendation on cross-border interoperability of electronic health record systems

The 2008 Commission "Recommendation on cross-border interoperability of electronic health record systems"ix (‘the Recommendation’) has been drafted as a follow-up to the Community eHealth Action Planx which, in 2004, defined interoperability of electronic health records as one of the priorities for 15 Member States in the roadmap annexed to that Plan.

The Recommendation provides guidance to individual Member States to ensure the minimum level of compatibility and communication with fellow Member States for interoperability, for a legitimate medical or healthcare purpose and for cross-border exchange of patient data within the Community so far as necessary, of electronic health record systems, including patient summaries, emergency data 20 sets, and medication records facilitating ePrescription solutions. Such electronic health record systems should enable healthcare providers to ensure that a patient receives care more effectively and efficiently by having timely and secure access to basic, and possibly vital, health information, if so needed and in conformity with the patient's fundamental rights to privacy and data protection.

The Recommendation provides a set of guidelines for developing and deploying interoperable 25 electronic health record systems, and it identifies steps required to arrive at this ideal solution, and to avoid potential problems caused by a lack of interoperability of such systems. This deployment will support the free movement of people (patients and professionals) and services and will favour the safety of travelling individuals across Europe. Due to the fact that the basic components that need to be addressed in a cross-border setting (identification, security, legal, organisational, technical and 30 semantic interoperability) also apply in local, regional and national settings, the Commission believe that this Recommendation will also influence the deployment of interoperable electronic health record systems within Member States.

The goal of the Recommendation is, therefore, to assist authorised health professionals to gain managed access to essential health information about patients, subject to the patients' consent, and 35 with full regard for data privacy and security requirements; where such information could include the appropriate parts of a patient's electronic health or medication record, patient summary, and emergency data accessible from any place in the Community.

Member States are invited to undertake actions at five levels. These are the overall political level; the organisational level; the technical level; and the semantic level; underpinning these is a commitment 40 to various education and awareness raising mechanisms.

Readers of this Report are strongly advised to familiarise themselves with the details of the Recommendation. Given the priority given to this initiative and national investments, the Project Team worked on the basis that Member States will need to apply the guidelines by building on already-existing standards and deployed systems. 45

2.1.5 Recommendation on telehealth On 4th November 2008 DG INFSO issued its "Communication on telemedicine for the benefit of patients, healthcare systems and society" xi. This document aims to encourage the wider adoption of 'telemendicine' across the EU – and globally. It recognises the need for use of existing standards and adoption of new standards and standardised approaches to achieve interoperability to be supported 50 by standards development organisations, with the active participation of industry. It also recognises that coordinated community action as explicitly called for in the proposal for a Directive on patients' rights in cross-border healthcare vii is necessary. It states:


Page 9

Trust and confidence in new and innovative technologies and ICT-based services within the health sector need to be built through rigorous testing, agreed standards and a widely accepted certification process. This applies particularly to telemonitoring devices. To avoid market fragmentation, concerted action is needed at EU level to agree on a common set of specifications for these telemedicine systems and services. Such concerted action could bring together the necessary expertise and 5 knowledge to ensure that good quality and safe and secure telemedicine services, which are not covered by existing legislation, are available throughout the EU.

Actions

- By the end of 2010, the Commission invites industry and international standardisation bodies to issue a proposal on the interoperability of telemonitoring systems, including both existing and 10 new standards.

- By the end of 2011, the Commission, in cooperation with Member States, will issue a policy strategy paper on how to ensure interoperability, quality and security of telemonitoring systems based on existing or emerging standards at European level.

2.1.6 Other texts 15

There are other texts existing or in preparation that may have consequences for the Mandate:

2.1.6.1 European Workforce for Health On December 10, 2008 DG SANCO is launching, on behalf of the European Commission, a Green Paper on ‘European Workforce for Health’ by November and has already circulated an internal working document in order for its experts to prepare a draft. 20

2.1.6.2 Recognition of professional qualifications Directive 2005/36/ECxii, adopted on 7 September 2005, consolidated and modernised the rules regulating the recognition of professional qualifications. At the end of the transposition period, on 20 October 2007, this Directive replaced fifteen existing Directives in the field of the recognition of professional qualifications. 25

2.1.6.3 Draft report on professional card for service providers Directive 2005/36/EC (recital 32) states that "the introduction, at European level, of professional cards by professional associations or organisations could facilitate the mobility of professionals, in particular by speeding up the exchange of information between the host Member State and the Member State of origin". 30

The EU Parliament draft report on the creation of a European professional card for service providers xiii notes that in some regulated and harmonised professions, such as lawyers and health professionals, European professional cards are currently in development, but that the added value of a European professional card, in addition to existing measures which aim to facilitate and stimulate mobility, needs to be established for most professions. 35

2.1.6.4 Secure identity across borders In May 2008 the European Commission announced a large-scale pilot project called STORK (Secure idenTity acrOss boRders linKed) 1xiv the aim of which is to ensure the cross-border recognition of national electronic identity (eID) systems in 13 Member States, to enable the cross-border provision of online services. 40

The project aims to establish a number of trans-border pilot projects based on existing national eID systems. In practice, some of the most useful eID services will be tested by defining a set of common specifications allowing for the recognition of different national eIDs between the participants. It is intended that without replacing national schemes, the new system will allow citizens to identify themselves electronically in a secure way using their national electronic identity (eID via electronic 45 cards or other means), and deal with foreign public administrations either from public offices, from their PC or ideally from any other mobile device. This will impact on the citizen and professional identification topics that this Report addresses in 5.3.2 and Annex B. 1 Confusingly, unrelated to the DG INFSO project: STORK- Strategic Roadmap for Crypto, IST-2002-38273


Page 10

2.1.7 Smart Open Services for European Patients (epSOS) This recently approved EU project (http://www.epsos.eu/), under the competitiveness and innovation framework programme (CIP) - ICT policy support programme (PSP) call ICT-PSP/2007/1, aims to develop a practical eHealth framework and ICT infrastructure that will enable secure access to patient health information, particularly with respect to a basic Patient Summary and ePrescription, between 5 European healthcare systems.

The Project Summary developed by the project states:

"Electronic patient record systems, with their initial focus on both patient summary/emergency data sets and medication record / ePrescribing solutions, are being driven forward by European member states. While all are committed to doing this in principle, some regions and countries are more 10 advanced than others in terms of their capacity to implement proposed solutions. To enhance the possibility of these services being provided across national or regional borders, interoperability among systems and services must be achieved between the national and/or regional systems. To ensure trust in the use of these systems on the part of patients and healthcare professionals, appropriate data protection, system security and performance criteria need to be included in any emerging cross border 15 applications. The national regulatory authorities and competence centres for eHealth that are cooperating in this large scale pilot to implement interoperability for the two proposed focal applications aim to test them in pilot applications in a range of member states. The approach, which is based on well developed and distinct use cases and associated infrastructural components, aims to deliver both a methodological process and durable implementations (termed ‘building blocks’). These 20 will form the basis for a longer term, pan-European approach to building interoperable service solutions."

The proposers further point out that:

Implementing such a European system will be subject to the following constraints:

- any access to personal information can only take place with a citizen’s explicit and informed consent; 25

- any access is in the context of a resident of one state visiting another state and seeking healthcare in that state.

It is noted that this proposal is only one element in a wider strategy to promote and encourage the development of an interoperable European eHealth infrastructure and services that builds on the eHealth strategies of individual member states. This is a long-term goal that involves considerable 30 work beyond the scope and timescale of this large-scale pilot. Essential requirements of any solution are that it must:

- be centred on the needs and wishes of citizens, patients and their carers (including wishes with respect to confidentiality and consent)

- maintain, and preferably enhance, patient safety 35

- be capable of being supported by all member state administrations within the context of their national health regulations, strategies and eHealth implementations.

There are nine specific objectives within this overarching goal for participating member states. These are to:

- agree on a minimum dataset that describes the necessary patient summary health information to 40 support citizens seeking unscheduled healthcare in a member state other than their normal country of residence;

- agree similarly on a basic dataset and other requirements for ePrescription;

- agree a minimum set of requirements for the access to information taking into account the needs of the various actors, including specifically citizens, healthcare professionals and healthcare provider 45 organisations;

- design, implement and test a practical technical solution to confidentiality and security requirements in a ‘laboratory’ setting;

- demonstrate the practical implementation of the solution, again in compliance with confidentiality and security requirements, in a number of settings in a number of participating states 50

- evaluate the results of the practical implementation;

http://www.epsos.eu/


Page 11

- demonstrate the ability to access information in compliance with relevant confidentiality and security requirements, including in particular the content of the European Data Protection Directive and any further formally agreed amendments to this that come from the Article 29 Working Party;

- contribute to the development of relevant interoperability standards;

- propose ways in which the implementation may be replicated in all other member states, in 5 collaboration with those other states.

The epSOS project states that it has the following interrelationships:

Support of the priorities of the i2010 Initiative:

i) By developing and implementing electronic cross-member state health service support in two concrete application fields, it helps to advance towards “a Single European Information Space [in 10 health] which promotes an open and competitive internal market.”

ii) By involving not only competent authorities of member states but also industry and SMEs in an ICT-related field, i.e. eHealth, where all experts do not only expect continuous RTD investment but a strong growth in future implementations, it contributes to “strengthening Innovation and Investment in ICT research to promote growth and more and better jobs.” 15

iii) By supporting all European citizens when travelling across member state borders or being abroad for other reasons and allowing them access to basic healthcare services where ever they are, the projects supports achieving “an Inclusive European Information Society that is consistent with sustainable development and that prioritises better public services and quality of life.”

Support for the objectives of the ICT PSP 20

Through developing, testing, implementing and offering for application also by not yet involved member state health systems, the project will contribute towards “stimulating innovation and competitiveness through the wider uptake and best use of ICT by citizens [and] governments”, thereby “leveraging innovation in response to growing societal demands” from European mobile citizens for equal and high quality access to healthcare where ever they are within the Union. 25

National health systems can thereby “take more advantage of advances in ICT in order to provide more efficient and higher quality services. Disparities across Europe” will also be tackled at the same time.

Improving the European eHealth infrastructure and thereby supporting public health systems in participating member states, and focusing on two concrete services is surely an “area of public 30 interest” where the project is a clear sign of “a proactive public policy including direct investments in ICT-based solutions” by the participating member states. At the same time, the eHealth LSP addresses a “major hurdle for the wider and better use of ICT in ... health”, by alleviating “the unavailability of ICT-based services, the lack of interoperability of solutions across the Member States as well as the market fragmentation of ICT-based solutions.” 35

Standardisation and related groups

This project aims to develop an open, clearly specified technically and semantically interoperable basic eHealth infrastructure across selected member states. Accordingly, stakeholders and selected experts from relevant standardization and interoperability support organisations such as HL7, CEN, ISO, IHE and others will be invited. 40

The project will cooperate with CEN/CENELEC/ETSI under the appropriate mandate (M/403).

At the semantic level, links will be sought to standards organisations responsible for classifications like WHO-ICD, WHO-ATC, IHTSDO (formerly SNOMED) or International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH) and other activities in these fields. 45

Cooperation with the CALLIOPE Thematic Networkxv and other networks

The epSOS project is promoted by 12 Member States, however what will be pursued is that all MS and relevant stakeholders may benefit from and contribute to the project; however such interaction with organisations outside the epSOS partnership should be done in a way that it will neither slow down the pace of the project nor affect the planned calendar and workplan. 50

The strategy for achieving an open approach without adding burden to the project itself is one where existing networks of stakeholders will be used to channel this type of communication. There are several such networks and fora available to the LSP such as EHTEL, the IHE, professional


Page 12

associations to mention but a few. At the same time the eHealth Initiative has promoted the establishment of an open and expandable Thematic Network - CALLIOPE (CALL for InterOPErability) - which currently brings an additional 9 EU and EFTA counties and 10 EU stakeholder associations – IT industry, doctors, pharmacists, insurance organizations and patients - together under the common theme of cross border eHealth. Its open communication platform is planned to provide for learning 5 from each other, building consensus beyond the LSP partnership on what may be good practice and arriving at broadly accepted specifications for implementing interoperable solutions, in close liaison with the Commission services, standardization bodies as well as representatives of all other stake-holders concerned and in particular the health professionals and the European citizens. CALLIOPE is offered to epSOS as an additional, but not the only, dissemination and communication platform. 10

As part of its commitments for the first 30 months, CALLIOPE will also deliver a Common European Interoperability Road Map, focused on further deployment of current and emerging use cases which will take into consideration the on going developments in the field, including the progress and the initial results of this LSP. Therefore epSOS. may also elect to pursue the definition of a roadmap to extend its current specific objectives in synergy with this specific TN activity. 15

The epSOS project has a 3-year timescale and it is anticipated that draft operational requirements will begin to feed in to Phase 2 of the ESO M403 eHealth-INTEROP program during the second quarter of 2009. The Project Team have clarified with the management of CALLIOPE that its role is to promote coordination and adoption of existing standards and articulate the need (if any) for new standards, not to produce them. 20

2.2 Definitions

2.2.1 Background Because the language used to describe the concepts central to this Report varies according to time, fashion and geography we have decided to reduce ambiguity, at least within the context of the Report, by describing which of the alternative current meanings will be used throughout the document. 25

Also, because there are already too many 'definitions', we have specifically chosen not to attempt a 'better' re-formulation in any of the cases. Following a brief discussion of some alternatives our chosen definitions of issues central to this Report are enclosed in rectangles in the remaining parts of this section.

Before examining the detail it is worth noting that the EC "Recommendation on cross-border2 30 interoperability of electronic health record systems"vii (see 2.1.4) uses the following definitions:

a) "patient" means any natural person who receives or wishes to receive health care in a Member State;

b) "health professional" means a doctor of medicine or a nurse responsible for general care or a dental practitioner or a midwife or a pharmacist within the meaning of Directive 35 2005/36/EC of the European Parliament and of the Council of 7 September 2005 on the recognition of professional qualifications46 or another professional exercising activities in the healthcare sector which are restricted to a regulated profession as defined in Article 3(1)(a) of Directive 2005/36/EC;

c) "electronic health record" means a comprehensive medical record or similar documentation 40 of the past and present physical and mental state of health of an individual in electronic form, and providing for ready availability of these data for medical treatment and other closely related purposes;

d) "electronic health record system" means a system for recording, retrieving and manipulating information in electronic health records; 45

e) "patient's summary, emergency data set, medication record" mean subsets of electronic health records that contain information for a particular application and particular purpose of use, such as an unscheduled care event or ePrescription;

f) "ePrescription" means a medicinal prescription, as defined by Article 1(19) of Directive 2001/83/EC47, issued and transmitted electronically; 50

2 For the purpose of this Recommendation, the term "cross-border" is understood to be exchanges between neighbouring

and non-neighbouring Member States and their entire territories.


Page 13

g) "interoperability of electronic health record systems" means the ability of two or more electronic health record systems to exchange both computer interpretable data and human interpretable information and knowledge;

h) "cross-border interoperability" means interoperability between neighbouring and non-neighbouring Member States and their entire territories; 5

i) "semantic interoperability" means ensuring that the precise meaning of exchanged information is understandable by any other system or application not initially developed for this purpose3.

With the exception of (e) "patient's summary, emergency data set, medication record" and (g) "interoperability of electronic health record systems" this Report adopts these definitions without 10 further comment (though it should be noted that some these may be variance with definitions used in published standards – see also the footnote relating to (i)).

A glossary and explanation of abbreviations is provided towards the end of this document in "Glossary and abbreviations" starting on page I.

2.2.2 eHealth 15

2.2.2.1 Understanding the term One of the problems with the task of examining standards for eHealth is the diversity in understanding of the term "eHealth". It is sometimes shown eHealth, Ehealth, ehealth, e-Health, E-health or e-health. This diversityxvi is symptomatic of that shown in the implied meaning. The term “eHealth” will, unless quoting other work, be used in this Report. 20

According to Eysenbachxvii "it seems quite clear that e-health encompasses more than a mere technological development". He defined the concept as follows:

- e-health an emerging field in the intersection of medical informatics, public health and business, referring to health services and information delivered or enhanced through the Internet and 25 related technologies. In a broader sense, the term characterizes not only a technical development, but also a state-of-mind, a way of thinking, an attitude, and a commitment for networked, global thinking, to improve health care locally, regionally, and worldwide by using information and communication technology 30

The term can therefore encompass a range of services that are at the edge of medicine/health care and information technology: electronic medical records, telemedicine, evidence based medicine, consumer health informatics, health knowledge management, and virtual health care teams.

It is worth noting that Eysenbach’s definition implies an ethical dimension – an aspect that should be remembered in relation to EU policy intentions. Also worth noting is the shift over time since he 35 mentioned medical informatics toward the use of the expression ‘health informatics’ as being more inclusive – but still retaining focus on the handling of information, enabled by horizontally applicable communications capability.

On the other hand, eHealth as defined by WHO on its Global Observatory for eHealth websitexviii, involves the use of information and communication technologies to support and leverage the health 40 system. These, according to WHO, are tele-education; telemedicine; ICTs for health research; and ICT for health services management; applications that cover all aspects of the health care delivery process.

- eHealth the use of information and communication technologies (ICT) for health 45

The most accessible EU DG-INFSO definitionxix appears to be based on that WHO Global Observatory for eHealth website text, but adds tools and service while removing use. This appears to

3 The "not initially developed for this purpose" element of this definition is problematic because it implies an ability to

acquire and implement semantic interoperability in a live application. This is not possible unless the application was initially (or subsequently) equipped with the means to dynamically acquire the means to achieve semantic understanding. In real terms applications not initially equipped with such capability cannot be retrofitted to achieve it.


Page 14

result in a conversion of the concept from a whole way of working to a toolset and is not a satisfactory formulation:

- eHealth information and communication technologies tools and services for health

DG-INFSO then notes: "Whether eHealth tools are used behind the scenes by healthcare 5 professionals, or directly by patients, they play a significant role in improving the health of European citizens." Given how little evidence actually exists this latter statement is a bold claimxx – though few would disagree that the potential exists for improving the health of European citizens by use of ICT.

Confusingly, the definition included in the Draft Recommendation of The Commission on eHealth Interoperability of 16th July 2007xxi adopts a different definition, which also goes into rather unhelpfully 10 over-specific detail, so despite the attractions of consistency we are not using this formulation.

Elsewhere, the WHO uses other definitions, and of these we have elected to use the last shown (in box) because it not only sets expectations around use of technology but also describes well the core areas to which it can be applied, without going into over-specific detail, as well as being the most recent formally used definition by the global community of WHO. 15

- eHealth use of information and communication technologies locally and at a distancexxii

- eHealth cost-effective and secure use of information and communications technologies in support of health and health-related fields, including health-care services, health surveillance, 20 health literature, and health education, knowledge and researchxxiii

2.2.2.2 Constraining the eHealth space In order to provide some rational structure to this document it is necessary to establish a common, even if constrained, understanding of the environment that we are seeking to address. Because the 25 eHealth Architecture is still sufficiently immature that it lacks crisp concepts, the diagram in Figure 2.1 is based upon the CEN Study on the Health Information Infrastructure, which sought to understand some of the logical requirements. Although we do not refer explicitly to this diagram until considering the use cases in Section 4 it is worth bearing it in mind throughout the intervening sections.

It has to be recognised that some of the activities legitimately seen as in support of health care are 30 somewhat difficult to differentiate from analogous activities that may support local government or a commercial enterprise. For that reason we attempt some clarification below – but recognise that even this interpretation will have borderline cases; in practical terms these functions may be thought of as a parallel plane onto which explicitly eHealth functions are layered or, in some cases, as a surrounding set of functions in the wider business space. 35

The recent EC / CEN Horizontal European Services Standardization Strategy (CHESSS) Initiativexxiv is addressing standards related activity in support of generic services so, although the chosen working definition for our Report is broad, it should be noted that we have excluded from consideration:

- such procurement or logistics functions that might be used in support of 'hotel' services in healthcare; 40

- other generic 'business' functions such as human resources, customer management, resource planning, public relations (communications), quality and risk management processes even when applied to health care organisations.

By excluding from our consideration of eHealth support functions that are not explicitly care focused we are indicating that we do not believe that items such as food, fuel, furniture or building materials for 45 maintenance need to be managed in a manner inherently different from any other enterprisexxv. However, there are areas of procurement where there are more or less obvious care implications that may differentiate them from some other business sectors; so although specialised standards may be required this should not be the starting presumption.

Similar considerations apply to logistics, human resources, customer management, resource planning 50 and public relations processes – there may be a need to have health-specific standards. To use an analogy, although a motor vehicle manufacturer requires standards for procurement and logistics


Page 15

functions, human resources, customer management, resource planning, public relations (communications), quality and risk management processes none of these would be claimed as being car construction standards – though all are critical to efficient and effective motor vehicle production.

We wish to recognise that general business standards might have a part to play in specific health informatics standards to enable efficient and effective care delivery. Again, as an example, aspects of 5 ebXML (designed to enable commercial ordering and logistics communications) are directly applicable to communication of health records in certain operational contexts.

By using the very generic logical model in Figure 2.1 covering eHealth in general terms – and not focussing only on Electronic health record - we are electing not to use the, legitimately, more constrained Electronic health record models well-described in various recent standards. 10

Figure 2.1: Health information infrastructure, based upon the CEN consultative logical model (i.e. not representing any particular technical implementation) xxvi

2.2.3 Tele— services Because in many situations eHealth is thought to be synonymous with telemedicine, telehealth or 15 other related 'tele' prefixed services, there is some value in examining the terminology of this field here. As noted in 2.2.2 the WHO has singled out tele-education and telemedicine for special mention but they are accompanied by other similar terms in common use: e.g. tele-radiology, tele-care, tele-assistance, tele-monitoring, tele-cardiology, tele-dentistry as well as the less distinctly labelled video consultation, two-way interactive television or robotic surgery. 20

The tele- prefix derives from the Greek root 'tele' meaning far, at a distance. It is notable that the first two WHO definitions (see 2.2.2) touch on different aspects of distance. With the near ubiquity of networked communications ranging from pico-nets to global virtual private networks the concept of distance is therefore of diminishing value as a determinant of the technical scope of communication (even a keyboard may now use telecommunications technology, such as Bluetooth, to communicate 25 with the computer a few centimetres distant) – though undoubted technical hurdles xlvi remain to be overcome in some use cases. However, the key impact of distance upon human interactions in health-related communication remains. It is perhaps this aspect that has, more than the technologies, to be addressed before widespread routine use is seen.


Page 16

Figure 2.2: Tele— service relationships

Note: the relationships shown here are illustrative only; though they may be typical other, different, relationships may well be seen in different delivery models.

The difficulty of making meaningful differentiations becomes clearer when the terms are generalised 5 as much as possible – see Figure 2.2. It is not then difficult to apply several of the general services to medical specialties – but it is more difficult to differentiate between health and social care, where the delivery mechanism is often determined by local policy and practice. Although the Dutch National Technical Agreement 8028xxvii provides a clear definition of telemedicine in a purely medical context it still has some overlap with the telecare area indicated in Figure 2.2; and it is not fully harmonised with 10 the WHO definition from 1998xxviii.

The "Teleservices" text in the lowest rectangle of Figure 2.2 illustrates further the difficulty of arriving at clear definitions of the concepts and is intended to represent services ordered remotely by the citizen. These services may be delivered either as additional teleservices, or as physical services.

The teleservices arena needs to be set in the wider EU context of the Ambient Assisted Living [AAL] 15 R&D programmexxix, which embraces teleservices within the overall context of the “Smart Home”, and of the COST219 group of EU supported programmes that has focused on this topic over a protracted period. Also of note is that ISO JTC1 SC25: Smart Homes has been active in this area for some years as well as various ITU-T, ISO TC12 & TC27, and IEC TC25 groups. 20

However, the teleservices approach has typically been one of technological ‘solutions’ applied to incompletely understood problems – which have to be seen in the context of care provision as a whole. The plethora of current disconnected activities is a well-recognised problem with, as yet, little use case based leadership, though the ESOs are currently in discussions on the best means to address smart house standardisation. 25


Page 17

For these reasons, though recognising the vital role of telecommunications and associated standards in eHealth, we avoid using any tele- prefixed term in this Report except where it appears as an element of quoted text, or a document title.

2.2.4 Interoperability This is another area prone to re-definitionxxx to suit the purposes of a particular interest. Again, we will 5 not redefine, but re-use another definition. In this instance it seems appropriate to use as our starting point the excellent summary provided in the "EU Study on the specific policy needs for ICT standardization" for the European Commission in July 2007xxxi; itself building extensively on the ETSI White Paper "Achieving Technical Interoperability – the ETSI Approach" of October 2006 xxxii.

Interestingly, neither the authors of the EU Study or of the ETSI White Paper selected a particular 10 definition of interoperability but elected to present commonly used definitions. The most established definition is that from the IEEE Standard Computer Dictionary of 1990 xxxiii and is used in the EU Study:

- interoperability ability of two or more systems or components to exchange information and to use the 15 information that has been exchanged

Four categories of interoperability were identified in the ETSI White Paper:

- technical interoperability – is usually associated with hardware/software components, systems and platforms that enable machine-to-machine communication to take place,

- syntactical interoperability – is usually associated with data formats. Certainly, the messages 20 transferred by communication protocols need to have a well-defined syntax and encoding, even if it is only in the form of bit-tables. However, many protocols carry data or content, and this can be represented using high-level transfer syntaxes such as HTML, XML or ASN.1,

- semantic interoperability – is usually associated with the meaning of content and concerns the human rather than machine interpretation of the content, and 25

- organisational interoperability – as the name implies, is the ability of organisations to effectively communicate and transfer (meaningful) data (information) even though they may be using a variety of different information systems over widely different infrastructures, possibly across different geographic regions and cultures.

It is widely recognised, and discussed in some detail in the EU Study, that the difficulty of achieving 30 interoperability increases down this list; with cross-cultural interoperability being notoriously tricky. The Commission has in the recent Recommendation adopted the five layers approach (probably from the i2-Health project), i.e. political, organisational, technical, semantic and educational layers. The wider literaturexxxiv frequently refers to the syntactic interoperability listed in the ETSI report, a concept that is of increasing value with the widespread use of XML which is often misleadingly described as 35 “self-describing”xxxv.

We will not explicitly adopt any of these layered approaches although we do recognise the value of the insights that they each bring – and to which we refer again in sections 4.3 and 5.3.3.

The ETSI White Paper also proposed division into levels: content interoperability, service interoperability, device interoperability, and finally device-to-device interoperability (when two devices 40 are connected). Though the last three are attractive it is not explained how content interoperability might be separated from syntactical, semantic or organisational interoperability.

Interestingly there is no definition in EN ISO 13606-1xxxvi, although it does say "The challenge for EHR interoperability is to devise a generalised approach to representing every conceivable kind of health record data structure in a consistent way. This needs to cater for records arising from any profession, 45 speciality or service, whilst recognising that the clinical data sets, value sets, templates etc. required by different health care domains will be diverse, complex and will change frequently as clinical practice and medical knowledge advance. This requirement is part of the widely acknowledged health informatics challenge of semantic interoperability."

The DG INFSO project SemanticHEALTHxxxvii has the goal of working towards and support 50 collaboration among human actors and stakeholders, rather than only interoperability among computers, so its definition is more complete than that used for more general purposes and might usefully be regarded as supporting the end goal of eHealth interoperability. In this view, semantic


Page 18

interoperability addresses the transmission and use of meaning within the framework of seamless healthcare services, between providers, patients, citizens and authorities. However, because of the poor resources available for representation of health-related expressions in multiple natural languages using existing ontological systems this cannot be seen as a short or medium term practicality – though standards that enable better semantic expression might be a valid near-term aspirationxxxviii. 5

The SemanticHEALTH project applies the following definition xxxix:

- health system interoperability the ability, facilitated by ICT applications and systems to exchange, understand and act on citizens/patient and other health related information and knowledge among linguistically and culturally disparate clinicians, patients and other actors and organizations within and across 10 health system jurisdictions in a collaborative manner.

However, for the sake of common understanding across EC departments, we propose the definition used in the Draft Recommendation of the Commission on eHealth interoperability xxi – itself based on that in the eGovernment Services to public Administrations, Business and Citizens (IDABC) Programme of the EC xl. It should be noted that this is more general than the definition used in the 15 final Recommendation of the Commission on cross-border eHealth interoperability (see 2.1.4) – and is, for the purposes of this Report, better suited.

- interoperability the ability of information and communication technology (ICT) systems and of the business processes they support to exchange data and to enable the sharing of information and 20 knowledge

Because during consultations the issue was raised a number of times, we have added Annex D, which, using examples, deals briefly with the broad topic of semantic interoperability and includes some consideration of the issues of both complex concepts and syntax. 25

2.2.5 "Patient summary" and "emergency data set" The Mandate to the European Standardization Organisations CEN, CENELEC and ETSI in the field of Information and Communication Technologies, applied to the domain of eHealth, specifically notes "… within the overall eHealth interoperability domain, patient and health practitioner identifiers, the patient summary, as well as an emergency data set, have been identified as the most critical priorities to be 30 covered by standardization activities."

According to Connected Health: Quality and Safety for European Citizens v a patient summary is defined as:

- a clinical document that is stored in repositories with cumulative indexing systems and secure access by authorised people. In order to achieve maximum benefit from this instrument, the 35 structured content of patient summaries should be agreed at an international level, starting from a few generic summaries and gradually developing a series of summaries specific for each clinical context.

As Connected Health: Quality and Safety for European Citizens notes, this definition is a citation from an eHealth ERA coordination action deliverablexli. At the early stage implied by the date of the citation 40 the definition must have been more aspirational than real. The realities reflected in the project database, or final project deliverablexlii on the "summaries" topic demonstrate, and then acknowledge, great inconsistency. The final report indeed only uses the first part of the 'definition'.

Before examining the detail it is worth recalling that the EC Recommendation on cross-border interoperability of electronic health record systemsix (see 2.1.4) uses the following definition: 45

- "patient's summary, emergency data set, medication record" mean subsets of electronic health records that contain information for a particular application and particular purpose of use, such as an unscheduled care event or ePrescription;

The problem with this definition is that it addresses three terms, each with more than one purpose (use case)xliii, which means that to be meaningful in an implementation context, and thus standards 50 production, it needs further clarification; see Figure 2.3 for a much-simplified illustration of the use case scoping problem.


Page 19

Figure 2.3: Example specialisations of "Summary"

NOTE: this illustrative Figure does not attempt to be exhaustive, or to illustrate the potential for reuse of elements of requirements for analogous purposes at the same level or other levels.

In many geographical areas the concepts of emergency data set and patient summary are used 5 interchangeably, which creates some difficulty what is meant the separate concepts. Web searching of the English-language expressions provides no useful information outside the various implementation initiatives within the UK NHS, though adding locum and referral seems to improve the number of relevant responses – but immediately implies one particular interpretation not necessarily shared by all healthcare professionals or organisations. 10

We therefore reluctantly defer adoption of a meaningful definition for the expressions "patient summary" and "emergency data set" and discuss the implications of these varied interpretations in the requirements analysis for "Patient summary" and "emergency data set" in section 5.3.3 and in Annex B.

15 Anchor points: The main needs of eHealth users remain stable despite fashions in technology and policy. Basic terms used in eHealth are not used with shared understanding adequate to achieve 20 useful results.


Page 20


Page 21

3 Standards

3.1 General introduction to standards activities This section attempts a review of the current 'standards' activities, in Europe and internationally, of relevance to eHealth. However, because of the wide-ranging nature of the activity at the level of industry consortia and national initiatives such a review cannot be exhaustive (see " ICT standards in 5 the health sector: current situation and prospects" by empirica xliv). For that reason the Report secretariat would welcome contribution of additional relevant material, which it is hoped, can be collated into an accessible resource under phase 2 of the Mandate.

For convenience we divide the remainder of this section into five further parts – starting in 3.2 with the three European standards organisations (ESOs) to which this Report is primarily addressed. 10

In 3.2.6 we examine briefly a range of organisations whose published output has significant influence on the eHealth area. It is recognised that because of the large number of activities that some which might have strong local importance may have less general visibility – and may not therefore appear in this section.

These are followed by: a brief comparison of the deliverables from the most widely cited standards 15 developers (3.4), the current standards development process (3.6), barriers to standards adoption (3.7) and then, in 3.8, an introduction to the standards inventory that forms Annex A.

Finally, and importantly, we include here a short review of the safety, security and privacy issues that have to be addressed by eHealth standards. This review is placed here because there are broad implications for other standards in the eHealth and other e-services areas – but the topic has strong 20 links to the identification of persons addressed in 5.3.2 and Annex B.

3.2 ESO Standards activities

3.2.1 Shared practice and deliverables The member states of the EU and EFTA believe that standardisation diminishes trade barriers, promotes safety, allows interoperability of products, systems and services, and promotes common 25 technical understanding. Standards therefore help to build the 'soft infrastructure' of modern, innovative economies by providing certainty, references, and benchmarks for designers, engineers and service providers – an optimum degree of order.

In addition, regional or European Standards are necessary for the Single Market and support the Union's policies for technical integration, protection of the consumer, and promotion of sustainable 30 development.

The three ESOs are: CEN, the European Committee for Standardization; CENELEC, the European Committee for Electrotechnical Standardization; and ETSI, the European Telecommunications Standards Institute.

The ESOs contribute to the objectives of the European Union and European Economic Area with 35 voluntary technical standards which promote free trade, the safety of workers and consumers, interoperability of networks, environmental protection, exploitation of research and development programmes, and public procurement.

European Standards adopted by CEN, CENELEC or ETSI, have an obligation of implementation as an identical national standard and withdrawal of conflicting national standards 40

On behalf of governments, the European Commission or EFTA Secretariat may request the European Standards organisations to develop standards in support of their policies by issuing formal 'mandates'.

The decision by the European Union to formulate legislation in terms of very general essential requirements - the "New Approach to technical harmonization and standards” (resolution of the Council of the European Union, 7 May 1985), and to require that the so-called "New Approach 45 Directives" be supported by a portfolio of European voluntary standards, was an extremely significant event in the history of modern standardisation


Page 22

This 'new approach' policy decided that:

- legislative harmonisation is limited to the 'essential requirements', these being obligatory and formulated in general terms;

- writing of the detailed technical specifications necessary for the implementation of directives is entrusted to the European, voluntary standards organisations like CEN; 5

- the standards are not mandatory, but products manufactured according to such 'harmonised' standards gives a 'presumption of conformity' to the essential legal requirements in the directives;

- compliance results in the right of the product to bear the CE marking of conformity and market release throughout Europe. 10

What follows are the principles that govern standards development amongst the ESOs:

- Standards are developed through a consensus process;

- Participants in standards development represent all interests concerned: industry, authorities and civil society — and, except in the case of ETSI, contributing mainly through their national standards bodies; 15

- Draft standards are made public for consultation at large;

- The final, formal vote is binding on all members;

- The European Standards (ENs) must be transposed into national standards and conflicting standards withdrawn.

Considerable valuable work has been done in the ESOs in partnership with other SDOs – though its 20 connection to strategic MS eHealth programmes is less clear. At present there are, at best, perceptions of mismatch between the technical approach being taken in different SDOs, and MS. So, at the least, these perceptions need to be clarified and any actual discrepancies of approach explained and if possible resolved by harmonisation or integration.

3.2.2 ICT co-ordination 25

The ICT Standards Board (ICTSB, http://www.ictsb.org/) is an initiative from the three recognized European standards organizations CEN, CENELEC, & ETSI with the participation of specification providers as partners to co-ordinate specification activities in the field of Information and Communications Technologies (ICT). […] The ICTSB listens to requirements for standards and specifications that are based on concrete market needs and expressed by any competent source. The 30 Board then considers what standards or specifications need to be created, and how the task will be carried out.

ICTSB is dealing with Design for All and Assistive Technologies (DATSCG), Intelligent Transport Systems(ITSSG), SmartHouse Standards (SHSSG), and Network & Information Security (NISSG). It has completed its co-ordination work on Electronic Signature (EESSI) and has contributed to the 35 discussion on ICT standardization (ICTSFG). The ICTSB has started to collect information on "eHealth and standardization" in support of European policies for an improved interoperability across Europe and beyond which involves numerous standards organizations. Radio Frequency Identification (RFID) is being dealt with by a number of standardization 40 organizations. The ICTSB is collecting information for the purpose of a harmonized standardization approach.

Five ICTSB partners (CEN, CENELEC, ETSI, The Open Group and W3C) combined to launch a support action under FP6 to optimize the interface between standards and research. details of this project - the Cooperation Platform for Research and Standards (COPRAS) - are found at 45 www.copras.org .

The ICTSB Board Members are drawn from Fora & Consortia (10), ESOs (3) and Observers (4): EC, EFTA, European Association for the Co-ordination of Consumer Representation in Standardization (ANEC) and The European Office of Crafts, Trades and SMEs for Standardization (Normapme).

The ICTSB has not been as active recently as it was a decade ago, although it is has established the 50 website on "eHealth and standardization" (http://www.ictsb.org/eHealth_standardization.htm). The European Commission has carried out a major policy review of ICT standardisation issues in Europe,

http://www.ictsb.org/

http://www.ictsb.org/eHealth_standardization.htm


Page 23

and is currently preparing recommendations, which will include proposals for future collaboration arrangements between the European Standards Organizations and industry consortiaxlv. These recommendations will be contained in a White Paper to be published in spring 2009; they are likely to include the creation of a "Strategy Platform" of stakeholders to advise the Commission as well as proposals related to the future of the ICTSB, and hence affect future consideration of these policy 5 issues.

3.2.3 CEN The European Committee for Standardization, CEN, was founded in 1961 by the national standards bodies in the European Economic Community and EFTA countries and is a non-profit making technical organisation set up under Belgian law. As will be seen when we review the other ESOs, the 10 scope of CEN standards work is very broad; effectively it covers by default all areas not addressed by the more specific scopes of CENELEC and ETSI.

In addition to Standards mentioned above other principal products are (see 3.4):

- Technical Specification (CEN TS) – normative documents produced in Technical Committees with national delegations, and approved by them, but not undergoing the formal national enquiry 15 process;

- Technical Report (CEN TR) – informative documents produced in Technical Committees with national delegations, and approved by them as informative publications;

- CEN Workshop Agreement (CWA) - normative or informative documents produced in open Workshops and agreed by consensus of those participating. 20

The Technical Board of CEN coordinates the standards programme.

Most standards are drawn up in technical committees and their working groups, whereas CEN Workshop Agreements are drawn up in more short-lived arrangements – Workshops.

The published and in-progress work of CEN (and ISO where the work is undertaken under the Vienna Agreement, see 3.3.10) relevant to eHealth is analysed in Annex A – Inventory. 25

3.2.4 CENELEC The European Committee for Electrotechnical Standardization, CENELEC, was created in 1973 as a result of the merger of two previous European organisations: CENELCOM and CENEL originating in the 1950s. CENELEC is a non-profit making technical organisation set up under Belgian law and is composed of the National Electrotechnical Committees of 30 European countries. In addition, 8 30 National Committees from neighbouring countries participate in CENELEC work with an Affiliate status.

CENELEC’s scope is to prepare electrotechnical standards for electrical and electronic goods and services.

Like CEN, in addition to the traditional European standard deliverables (see 3.1 and 3.4), the dynamic 35 Workshop (CWA: CENELEC Workshop Agreement) has been included in its portfolio, offering an open platform to foster the development of pre-standards for short lifetime products where time-to-market is critical.

The published and in-progress work of CENELEC relevant to eHealth is analysed in Annex A – Inventory. 40

3.2.5 ETSI The European Telecommunications Standards Institute (ETSI) defines electronic communication standards for products and processes, including protocols and testing, in information & communication technology (ICT).

Its members are drawn from ICT sectors worldwide and it is their technical experts who drive the 45 content and creation of ETSI standards and deliverables. It is worth noting that the membership and participation basis for ETSI is somewhat different from that of CEN and CENELEC, being formed from individuals and organisations – with no mediating role for NSBs.


Page 24

In an increasingly global and competitive business environment, standardisation provides a forum for consensus.

In addition to the traditional European standard deliverables ETSI has a suite of specifications, standards and reports that fulfil the various needs of the market (see 3.4). These are referred to as 'deliverables'. It is the ETSI members who determine the standards work programme according to 5 their needs.

The published work of ETSI already identified as relevant to eHealth is analysed in Annex A – Inventory. However, it should be noted that ETSI Special Task Force 355 has, in parallel with this Report, been producing a Technical Report: TR 102 764, "eHealth architecture; User service models and application classification into service models". This work is an initial step in developing eHealth 10 user service models. These models address interoperable solutions for healthcare data collection, transmission, storage and interchange with the required security, privacy and reliability. The next step of this work will be to develop requirements and service architecture to provide improved eHealth services involving the relevant stakeholders, including users, medical professionals etc. eHealth systems contribute to user ubiquitous access to more cost effective healthcare services irrespective to 15 location.xlvi

3.2.6 General eHealth considerations Because CEN deals with European standards matters not otherwise covered by CENELEC and ETSI, it is not surprising that its technical committee (TC251) for Health informatics deals, as its title implies, primarily with health information standards in the support of care in its widest sense (educational, 20 preventative, diagnostic, therapeutic and palliative). This it currently does in partnership with a number of other standards organisations.

This constraint of TC251 scope fits well with the work of CENELEC (often with IEC, on IT and medical devices) and with ETSI (on telecommunications) deal primarily with the underlying technologies. There are other committees in CEN that deal with the application of horizontal standards to particular 25 processes for IT, telecommunications or medical devices, the outputs of which are themselves applicable to TC251 work in the health informatics area. The wide range of CEN, CENELEC and ETSI documents, both published and 'in progress', and relevant to eHealth is given in Annex A – Inventory.

If support of market requirements is taken to be a prime function of eHealth standards this distribution 30 of responsibility puts CEN, and TC251 in particular, at the centre of the eHealth standards space amongst the ESOs, though with the need for responsive interaction with CENELEC and ETSI in the context of the wider activity demonstrated by global market trends and the SDOs reviewed below.

3.3 Other Standards activities

3.3.1 General observations 35

We have not attempted to differentiate in the listing below, between formally recognised standards organisations – see 3.5 for that. The list therefore shows a wide variety from eHealth specific industry consortia (some of which do not regard themselves as standards organisations) through to those formally recognised internationally (though it is notable that this formal recognition is not recognised in practice in some markets). 40

Moreover, the list is not exhaustive and omits important organisations undertaking valuable work in particular market niches. Instead we have taken a pragmatic view of the organisations that have to date had most impact across the range of eHealth standardisation in Europe.

3.3.2 Clinical Data Interchange Standards Consortium Clinical Data Interchange Standards Consortium, Inc. (CDISC, http://www.cdisc.org) is a global, 45 multidisciplinary, non-profit, membership organisation that has established standards to support the acquisition, exchange, submission and archive of clinical research data and metadata. The CDISC mission is to develop and support global, platform-independent data standards that enable information system interoperability to improve medical research and related areas of healthcare. CDISC standards are vendor-neutral, platform-independent and freely available via the CDISC website. 50

http://www.cdisc.org


Page 25

3.3.3 Continua Health Alliance The Continua Health Alliance (http://www.continuaalliance.org) is a membership organisation with around 160 members. Most members are product manufacturers, but there are a small number of both healthcare providers and research organisations.

The Continua Version 1 Guidelines (targeted to be issued in 2009) will combine healthcare informatics 5 data standards with consumer electronic technologies. This integration provides the specifications necessary to enable connectivity across a wide variety of personal telehealth devices and services. The Version One standards for devices include the Bluetooth Health Device Profile (HDP) Specification from the Bluetooth SIG for wireless connectivity, the USB Personal Health Device Specification from the USB Forum for wired device connectivity, and Personal Health Device 10 Specifications from ISO/IEEE for protocol and data definitions. The Version 1 standards for integration with standards-based electronic health records (EHRs) consist of the CDA-based Personal Health Monitoring (PHM) Specification from HL7 and the XDR Profile Specification from IHE. The Version 1 Guidelines will be made publicly available after they are finalised and issued to members.

Continua uses a Use case driven process where all members have input to decisions on which 15 integration capabilities are developed. Continua's goal is not to create new standards but to identify the best in class existing standards that satisfy the Use Case requirements and provide profiling to ensure tight interoperability. Continua will develop a set of design guidelines and will coordinate changes in existing standards to enable a set of personal telehealth use cases.

Continua collaborates with a number of government regulatory agencies to develop methods for safely 20 and effectively regulating diverse multi-vendor personal telehealth solutions.

Continua participates with other industry organisations to help create the new business models needed to appropriately reimburse professional services for personal telehealth solutions.

3.3.4 DICOM The goals of DICOM are to achieve compatibility and to improve workflow efficiency between imaging 25 systems and other information systems in healthcare IT worldwide. Since 1993 DICOM has been developed as a voluntary standard driven by both users and vendors.

The “DICOM Standards Committee” exists to create and maintain international standards for communication of bio-medical diagnostic and therapeutic information in disciplines that use digital images and associated data. The DICOM Standards Committee is an independent, international 30 standards development organisation administered by NEMA’s Medical Imaging and Technology Alliance. The complete Procedures (bylaws) of the DICOM Standards Committee are available on the DICOM Web page at http://dicom.nema.org.

An open, transparent process includes input from interested parties to update the standard. A careful "compatibility and deprecate"-procedure ensures that products will be interoperable in the long term. 35 Working groups of the DICOM Standards Committee perform the majority of work on the extension of and corrections to the Standard. Working groups are formed by the DICOM Committee to work on a particular classification of tasks. Once formed, working groups petition the DICOM Committee to approve work items for which the working group will execute the plan delineated in the work item. Since the working groups perform the majority of work on the extension of and corrections to the 40 Standard, the current status and future directions of the DICOM Standard are best represented by review of each working group.

Once the output of a work item (generally a supplement or correction proposal) has been completed, it is submitted to Base Standards Working Group (WG-06), for their review. Supplements to the Standard then go through a public comment period, after which the DICOM Committee authorises the 45 supplement for letter ballot by DICOM members. Letter ballots require approval by two-thirds of those voting affirmative or negative and return of more than one-half of the ballots sent to members in good standing relative to letter ballots.

DICOM can be considered a notable success, since virtually each product in medical imaging will support DICOM, and medical users know DICOM and ask for it. Voluntary Conformance Statements - 50 published by the device and systems vendors - ensure that products can work with all current or future imaging modalities and related peripheral equipment – regardless of vendor. Clients evaluate such conformance statements and thus get help to make their choice in the market.

http://www.continuaalliance.org

http://dicom.nema.org


Page 26

DICOM has published its latest version in 2008 with 18 Parts , with Parts 3 to 7 describing the basic elements.

In 2004, DICOM was published "by reference" as EN 12052, Health informatics - Digital imaging - Communication, workflow and data management, and in 2006 as ISO 12052. DICOM also has strong ties to both HL7 (through the Imaging Integration WG there) and to ISO TC215 through Liaison with 5 WG2 there.

DICOM normative text is freely available at ftp://medical.nema.org/medical/dicom/2008/ .

The published and in-progress eHealth work of DICOM is analysed in Annex A – Inventory.

3.3.5 GS1 GS1 is a global standard organisation, resulting from the merger of EAN International and the Uniform 10 Code Council (UCC), headquartered in both Belgium and the USA. This organisation has developed since the 1960's a suite of standards used by companies across the world to enhance the supply chain; including identification, traceability, cataloguing, and electronic communication. GS1 standards have a global scope and they are used by organisations in 20 different sectors including retail, food and beverage, transport, chemicals and healthcare. 15

GS1 is organised as a federation, with affiliate member organisations in more than 100 countries. The user’ community is affiliated to the local member organisations. The organisation works closely with ISO and UN/CEFACT to define, propose and refine standard sets which are implemented by its user community.

GS1 products are organised in four main groups, namely: BarCodes, eCom, GDSN and EPCglobal. All 20 are based on common identification keys and semantics.

- - BarCodes is the grouping of optical data carriers which are designed to carry information according to GS1’s semantic that is based on “Application Identifiers”. Different barcodes are defined to be used according to business needs, from logistics (GS1-128) to patient safety in the medication process (GS1 DataMatrix). 25

- - eCom groups the set of electronic messages for supply chain partners, to implement business processes as ordering, transport, delivery, financial transactions, etc. GS1’s users have defined EANCOM, a subset of UN/EDIFACT, and GS1-XML, largely aligned with UN/CEFACT ebXML.

- The Global Data Synchronisation Network (GDSN) is an architecture allowing manufacturers to share detailed product descriptions with their existing and potential customers through a network 30 of electronic product master data catalogues.

- - EPCglobal develops and promotes a set of standards combining RFID (radio frequency identification) technology, communication networks and the Electronic Product Code (a number for uniquely identifying an item) to enable immediate and automatic identification and tracking of items through the whole supply chain globally, resulting in improved efficiency and 35 visibility.

The Global Standards Management Process, or GSMP, is the worldwide collaborative forum where GS1 standards are built and maintained. The GSMP brings together users from all industries and from everywhere in the world to identify needs for standards, gather business requirements, document best practices, obtain consensus on solutions, and then develop and implement the resulting supply 40 chain standards.

GS1 Healthcare (Global Healthcare user group) is a voluntary, global user community bringing together healthcare stakeholders: pharmaceutical and medical devices manufacturers, wholesalers and distributors, group purchasing organisations, hospitals, pharmacies, logistics providers, governmental and regulatory bodies, and associations. Early in 2008, GS1’s users merged their 45 healthcare working groups into a single one, to work on faster and consistent deliveries for the implementation of standard tools customised for the Healthcare industry.

3.3.6 HL7 HL7 (Health Level 7) is a US-headquartered standards organisation with central offices, international country affiliates, and topic-oriented working groups. In Europe there are Affiliates in Finland, 50 Germany, Netherlands and UK; there are newer and smaller Affiliates in Sweden, Lithuania, Poland, Czech Republic, Slovenia, Greece, France and possibly other Member States. HL7 is, unlike the

ftp://medical.nema.org/medical/dicom/2008/


Page 27

representational structures of CEN and ISO and their national counterparts, based on individual or corporate membership. The original process for defining HL7 messages was established in 1987. Today HL7 is ANSI accredited and an open dialogue platform (Joint Initiative Council – JIC) with ISO and CEN has been established.

HL7 products currently come in two main modes, namely HL7 v.3 and HL7 v.2.X (X=6 currently), but 5 there are complementary standards covering other aspects of communication in healthcare. HL7 V3, like V2.x, is a standard for exchanging health information among information systems that support healthcare applications. HL7 V3 Specifications (e.g. HL7 V3 messages, structured documents, etc.) permit loosely coupled information systems to interoperate (i.e. exchange data) in a variety of healthcare delivery contexts including those found in disparate provider organisations, perspectives, 10 and jurisdictions.

In V3 HL7 volunteers have sought to improve the V2 process and its outcomes. The development principles behind HL7 V3 are intended to lead to a more robust, fully specified standard. Not all areas covered by v2.X are as yet addressed by V3; and some inherently close-coupled processes may not benefit from the functions of V3 in the short term. For that reason, and because v2.X is still in more 15 widespread use, content of both versions are presented in our inventory.

HL7 is pragmatic in its origin; it uses events as triggers and roles as central information flow entities. Although it started as a message exchange (a set of information assembled for the purpose a specific exchange) standard HL7 is no longer only a point-to-point messaging standard; in particular The Clinical Document Architecture (CDA) is designed to support standards for storing and retrieving 20 persistent information, such as Medical Records, and in its current release 2.0 is tightly integrated with the HL7 V3 Reference Information Model (RIM). HL7 develops specifications, standards, and in some cases some tools related to the electronic documentation of its standards.

HL7 has other publications covering: The Clinical Context Object Workgroup (CCOW) Context Management Specifications, Arden Syntax for Medical Logic Systems, HL7 Security Service 25 Framework, Continuity of Care Document (CCD), Functional Profiles for Personal and Medical Health Records, and GELLO: A Common Expression Language.

Although an application layer standard, thus the 7 in its name, from the number of the application layer in the ISO OSI reference modelxlvii, HL7 also produces infrastructure (transport) specifications for its messages, by building upon a selection of IT standards, such as ebXMLxlviii. 30

The published and in-progress eHealth work of HL7 is analysed in Annex A – Inventory.

3.3.7 IEC The International Electrotechnical Commission (IEC), founded in 1906, prepares and publishes international standards for all electrical, electronic and related technologies. These serve as a basis for national standardisation and as references when drafting international tenders and contracts. The 35 IEC charter embraces all electrotechnologies including electronics, magnetics and electromagnetics, electroacoustics, multimedia, telecommunication, and energy production and distribution, as well as associated general disciplines such as terminology and symbols, electromagnetic compatibility, measurement and performance, dependability, design and development, safety and the environment.

The IEC produces two categories of publications: 40

- International consensus products – International Standards (full consensus), Technical Specifications (full consensus not (yet) reached), Technical Reports (information different from an IS or TS), Publicly Available Specifications, and Guides (non-normative publications).

- Limited consensus products – Industry Technical Agreements and Technology Trend Assessments. 45

In the ICT area the IEC has a joint committee with ISO, known as Joint Technical Committee 1 (JTC1). This is largely autonomous and is examined separately below. In the eHealth area the most apparent linkage is with IEC TC62 – and its subcommittees (IEC SC62A, IEC SC 62B, IEC SC 62C and IEC SC62D); SC 62A produces a range of basic safety standards and SC62 B, C and D produce, among other standards, a set of modality-related safety standards called “particular standards". This 50 work is adopted in CENELEC TC62 (using the Dresden Agreement between the SDOs) – in support of the EU medical devices directive.


Page 28

3.3.8 IEEE A non-profit organisation, IEEE is probably the world's largest professional association for the advancement of technology with in excess of 375,000 members in more than 160 countries. The IEEE name was originally an acronym for the Institute of Electrical and Electronics Engineers, Inc. but because the organisation's scope of interest has expanded into so many related fields it is simply 5 referred to by the letters I-E-E-E (pronounced Eye-triple-E).

The IEEE Standards Association (IEEE-SA) is a developer of industry standards in a broad-range of industries and has strategic relationships with the IEC, ISO, and the ITU and satisfies all SDO requirements set by the World Trade Organization.

The best-known ICT standards originating in IEEE are undoubtedly those for 'Ethernet' and its 10 derivatives (the 802 series), though there are a number of activities of more specific relevance to eHealth; of which the 11073 (formerly known as IEEE 1073, or informally as MIB) is 'sponsored' by the Engineering in Medicine and Biology Society (EMBS) and is concerned with medical and personal health device communications.

Since the formation of ISO TC215, the IEEE 11073 has been the vehicle by which the global work on 15 point-of-care medical device communication has been harmonised by merging CEN and IEEE work into a series now, for the most part, developed, owned and published jointly by all three bodies under the lead of IEEE.

The published and in-progress work of IEEE 11073, where it is not on the ISO and CEN work programme but is nevertheless directly relevant to eHealth, is analysed in Annex A – Inventory. 20

3.3.9 IHE

3.3.9.1 General We examine the work and processes of IHE in a little more detail than for most of the other organisations. It is not a Base Standards developing organisation but explicitly integrates existing Base Standards to enable fulfilment of identified tasks. For this reason we believe that at this juncture 25 in eHealth standards development this model might be of value in a European standards context.

Integrating the Healthcare Enterprise (IHE) International is an organisation established to help users and developers of information technology for healthcare to achieve interoperability of systems through the precise definition of healthcare tasks, the specification of standards-based communication between systems required to support those tasks and the testing of systems to determine that they 30 conform to the specifications. IHE is an initiative by healthcare professionals and industry to improve the way computer systems in healthcare share information. IHE promotes the coordinated use of established Base Standards such as ISO, DICOM, HL7, IETF, OASIS, W3C, etc, to address specific clinical needs in support of optimal patient care.

Implementing integrated information systems can be complex, expensive and frustrating. Healthcare 35 professionals seeking to acquire or upgrade systems do not have a convenient, reliable way of specifying a level of adherence to communication standards sufficient to achieve truly efficient interoperability. Great progress has been made in establishing such standards, but a gap persists between the Base Standards that make interoperability possible and the actual implementation of integrated systems. To fill in that gap has, until now, required expensive, site-specific interface 40 development to integrate even Base Standards-compliant systems.

The IHE initiative is designed to bridge the gap. Within IHE healthcare professionals, including members of its sponsoring organisations, identify the integration capabilities they need to work efficiently in providing optimal patient care. Representatives of clinical modality and information systems companies then reach consensus on a specific implementation of established communication 45 standards that provides those capabilities. Their selections are recorded in the IHE Technical Framework, a detailed resource for the implementation of Base Standards that is freely available to the whole industry. The Technical Framework is open to public comment and is proven via an industry-wide testing and implementation process. The process works by annual cycles, expanding the scope of integration capabilities each year. 50

The work of IHE is managed at the International level by a broad-based Board (overseeing IHE Domain committees developing Standards-based Integration and Content Profile Specifications) which relates to a number of national (In Europe: Austria, France, Netherlands, Germany, Italy, Spain,


Page 29

UK, etc.) and regional (IHE-Europe, IHE- Asia-Pacific) deployment organisations engaged in conformance testing and education activities. IHE membership includes over 200 stakeholder organisations (professional societies, healthcare providers, vendors, governmental entities, standards development organisations, etc.). IHE has a liaison D status with ISO TC215 since 2006 and its standards adoption process was approved as ISO TR23830 in 2007. An enhanced governance 5 process was defined in 2007 (www.ihe.net/governance).

3.3.9.2 The Four Steps of the IHE Process IHE follows a defined, coordinated process for standards adoption. These steps repeat annually, promoting steady improvements in integration.

1. Identify Interoperability Problems. Clinicians and IT experts work to identify common 10 interoperability problems with information access, clinical workflow, administration and the underlying infrastructure.

2. Specify Integration Profiles. Experienced healthcare IT professionals identify relevant Base Standards and define how to apply them to address the problems, documenting them in the form of IHE Integration Profiles. 15

3. Test Systems at the Connectathon. Vendors implement IHE Integration Profiles in their products and test their systems for interoperability at the annual IHE Connectathon. This allows them to assess the maturity of their implementation and resolve issues of interoperability in a supervised testing environment.

4. Publish Integration Statements for use in requests for proposals (RFPs). Vendors publish 20 IHE integration statements to document the IHE Integration Profiles their products support. Users can reference the IHE Integration Profiles in RFPs, greatly simplifying the systems acquisition process.

3.3.9.3 Integration Profiles and Standards IHE Integration Profiles organise and leverage the integration capabilities that can be achieved by 25 coordinated implementation of communication standards. They do not replace conformance to Base Standards, and users should continue to request that vendors provide statements of their conformance to relevant Base Standards, such as DICOM and HL7.

Integration Profiles rather provide a more precise definition of how Base Standards are implemented. They define a specific implementation of standards in order to meet identified clinical needs. The IHE 30 implementation of standards also has wide support by industry partners, documented, reviewed and tested.

IHE publishes a series of Technical Frameworks, each IHE Technical Framework consisting of two parts. The first one describes the business process problem and the solution to the interoperability problem; the other part specifies the transactions and content to support these Integration and 35 Content Profiles in detail, using current, established standards to solve the business problem defined by each IHE Integration or Content Profile.

IHE Integration and Content Profiles are based on the modelling concepts of actors, transactions and content. An Actor abstracts a system or part of a system that creates, manages or acts upon data. A transaction or a content module specifies a specific interaction between Actors to exchange 40 information.

3.3.9.4 Acquiring Integrated Systems IHE Integration and Content Profiles provide a common language for purchasers and vendors to discuss integration needs of healthcare enterprises and the integration capabilities of products. They are particularly useful for writing the integration portions of purchasing specifications. The goal for 45 most healthcare organisations is to implement practical capabilities such as distributed access to diagnostic images or smooth departmental workflow. Integration and Content Profiles allow communication about those high-level capabilities while referencing the underlying technical precision necessary to make them work. They give purchasers a tool that reduces the difficulty, cost and anxiety associated with implementing integrated systems. Implementers are expected to publish 50 Integration Statements that list the specific IHE Integration and Content Profiles supported by a version of a product. Those are made available on the IHE web site (www.IHE.net).

The published and in-progress work of IHE is analysed in Annex A – Inventory.


Page 30

3.3.10 IHTSDO The International Health Terminology Standards Development Organisation (IHTSDO) is an international not-for-profit organization based in Denmark. IHTSDO acquires, owns and administers the rights to SNOMED CT and other health terminologies and related standards. The purpose of IHTSDO is to develop, maintain, promote and enable the uptake and correct use of its terminology 5 products in health systems, services and products around the world, and undertake any or all activities incidental and conducive to achieving the purpose of the Association for the benefits of the members.

The IHTSDO seeks to improve the health of humankind by fostering the development and use of suitable standardized clinical terminologies, notably SNOMED CT, in order to support safe, accurate, 10 and effective exchange of clinical and related health information. The focus is on enabling the implementation of semantically accurate health records that are interoperable. Support to Association Members and Licensees is provided on a global basis allowing the pooling of resources to achieve shared benefits.

SNOMED CT was originally created by the College of American Pathologists by combining SNOMED 15 RT and a computer based nomenclature and classification known as Clinical Terms Version 3, formerly known as Read Codes Version 3, which was created on behalf of the UK Department of Health and is Crown copyright.

SNOMED CT is designed for use in electronic health records and other tools that support direct patient care. The terminology can facilitate functions such as decision support, statistical reporting, 20 outcomes measurement, public health surveillance, health research, and cost analysis.

Content

SNOMED CT is a clinical health and healthcare terminology with comprehensive, scientifically-validated content. The July 2008 release of SNOMED CT contains 315,000 active concepts with unique meanings and formal logic-based definitions organized into hierarchies. The topics of these 25 hierarchies are described in the table below. The July 2008 release also contains 806,000 English-language Descriptions and 945,000 defining Relationships. These relationships provide formal definitions and other characteristics of the concept. One type of link is the “IS_A” relationship. This is used to define a concept’s position within a hierarchy, e.g. Diabetes Mellitus IS_A disorder of glucose regulation. SNOMED CT concepts are organized in hierarchies with multiple levels of granularity. 30

Localization

SNOMED CT is a multinational, multilingual terminology. It has a built-in framework to manage localizations (using extensions), as well as different languages and dialects. Today, SNOMED CT is available in US English, UK English and Spanish. Large-scale translations into Danish, French, Swedish, and several other languages are currently taking place. Many focused translations also 35 exist in other languages. In addition, IHTSDO members are also planning to translate the standard into other languages.

The basic objective of any SNOMED CT translation is to provide accurate representations of SNOMED CT concepts in way that is understandable, usable, and safe. Translations must be concept-based, as term-to-term translations usually yield literal expressions that are often 40 meaningless. Instead, the translator analyzes each concept based on the position within the hierarchy, the descriptions, and relationships to other concepts before deciding on the most meaningful translation of a concept. HTSDO is currently developing guidelines and other supporting documents to support countries undertaking translations.

The published and in-progress work of IHTSDO is analysed in Annex A – Inventory. 45

3.3.11 ISO Founded in 1946, the International Organization for Standardization (ISO) is the world largest standards developing organisation. Between 1947 and the present day, ISO has published more than 17000 International Standards covering broadly the same wide range of topics as does CEN.

Since 1979, ISO has taken the commitment and implemented all the necessary measures to ensure 50 that ISO’s International Standards are fully compliant with the requirements set by the Agreement on Technical Barriers to Trade of the World Trade Organisation (WTO). The General Agreement on Tariffs and Trade "Agreement on Technical Barriers to Trade" (the so-called GATT Standards Code) introduced in 1979 aims at ensuring that regulations, standards, testing and certification procedures


Page 31

do not create unnecessary obstacles to trade. The Agreement also sets out a code of good practice for both governments and non-governmental or industry bodies to prepare, adopt and apply voluntary standards. ISO immediately promoted the value of ISO’s International Standards to be used worldwide as instruments facilitating the elimination of unnecessary barriers to trade, and, whenever needed, as a suitable basis for technical regulations. 5

Most early ISO’s International Standards were highly specific to a particular product, material, or process. However, during the 1980s, ISO entered into new areas of work, dealing with quality issues, destined to have enormous impact on organisational practices and trade. This accomplishment marked the beginning of the ISO 9000 family of standards – now the most widely known standards ever. The tremendous impact of ISO 9001 and ISO 14001 on organisational practices and on trade 10 has stimulated the development of other ISO standards and deliverables that adapt the generic management system to specific sectors or aspects including Information security, Supply chain security and Medical devices.

Following the decision by the European Union to formulate legislation in terms of very general essential requirements - the so-called "New Approach Directives" there was a widespread perception 15 among European as well as international stakeholders that the single European market needed to be integrated into the wider, global market and that this could best be achieved by ensuring that the standards used to regulate the single European market were also those which regulated the global market. With this in mind, it seemed that what was needed was a set of procedural mechanisms to try to ensure that, to the largest possible extent, International Standards and European Standards are 20 compatible or, even better, identical. Thus the agreement (called the Vienna Agreement) on technical cooperation between ISO and CEN was approved by ISO Council resolution and CEN General Assembly resolution in 1990, and was published in June 1991. A major benefit is this is to make rational use of the resources available for standardisation by avoiding duplication of work - this meaning that there has to be agreement on work allocation between ISO and CEN. In the health 25 informatics technical committees of ISO and CEN most standards have developed under the Vienna Agreement.

The published and in-progress work of ISO (and CEN where the work is undertaken under the Vienna Agreement) relevant to eHealth is analysed in Annex A – Inventory.

3.3.12 ITU 30

3.3.12.1 General The International Telecommunications Union (ITU) is the United Nations agency for information and communication technologies.

ITU’s mission is to enable the growth and sustained development of telecommunications and information networks, and to facilitate universal access so that people everywhere can participate in, 35 and benefit from, the emerging information society and global economy.

ITU's biggest achievement is undoubtedly the pivotal role it has played in the creation of the international telecommunications network — the largest man-made artefact ever created.

As with IHE, this review is slightly longer than for most others because principles of the organisation and role of ITU are perhaps applicable to the organisation of eHealth standardisation in Europe. 40 Although ETSI already has some closely related features, there are aspects in ITU that might be worthy of consideration at a pan-ESO level.

3.3.12.2 Organisation The ITU role in global communications spans: Radiocommunication, Standardisation and Development. Founded in Paris in 1865 as the International Telegraph Union, ITU took its present 45 name in 1934 and, in 1947, became a specialised agency of the United Nations; it is now based in Geneva, Switzerland. A public-private partnership organisation since its inception, ITU now has a membership of 191 countries and over 700 public and private sector companies as well as international and regional telecommunication entities. The Union’s consensus-based approach is designed to give a voice to all its members. 50

The Union’s main source of financing is the contributions of its Member States, which account for 67.3% of the overall budget. The amount of the contributory unit is determined when the budget is approved and the current value of one contributory unit for a Sector Member is set at 1/5 of that of a


Page 32

Member State. Sector Members contribute 11.4% of the overall budget. Associates contribute 0.9% of the overall budget. The other sources of financing include income from cost recovery for services like the sale of publications, project execution, satellite notifications (15.1% of total funding), and other income, such as withdrawals from the Reserve Account and income from interest (5.3% of total funding). The 2008-2009 budget amounts to approximately 1.64M€ - see 5 http://www.itu.int/net/about/budget/2008.aspx.

ITU is organised into four market-facing 'sectors': Radiocommunication (ITU-R) Manages the international radio-frequency spectrum and satellite orbit resources. Standardization (ITU-T) 10 Consensus standards-making activity. Development (ITU-D) Provides an implementation guidance and task prioritisation activity to enable access to ICT. ITU TELECOM Is a marketing activity with an annual exhibition, a high-level forum and other outreach. 15

3.3.12.3 Activities The activity of the Standardization (ITU-T) and Development (ITU-D) Sectors are examined in more detail here – but the ' Radiocommunication regulatory' and ' TELECOM marketing' activities of the other Sectors are of interest in within the holistic view taken by ITU.

Telecommunication Standardization Sector (ITU-T): http://www.itu.int/net/about/itu-t.aspx 20

The main products of ITU-T are the Recommendations. At present, more than 3,000 Recommendations (Standards) are in force. Recommendations are standards that define how telecommunication networks operate and interwork. ITU-T Recommendations are non-binding, however they are generally complied with because they guarantee the interconnectivity of networks and enable telecommunication services to be provided on a worldwide scale. 25

As of 2007 *.pdf format versions of current, in-force, ITU-T Recommendations are freely available.

Individual ITU-T Recommendations are grouped by category which eases accessibility for users – see http://www.itu.int/publications/sector.aspx?lang=en&sector=2

The ITU Telecommunication Development Sector (ITU-D): http://www.itu.int/net/about/itu-d.aspx

The ITU Telecommunication Development Sector (ITU-D) was established to help spread equitable, 30 sustainable and affordable access to information and communication technologies (ICT) as a means of stimulating broader social and economic development and holds a conference to establish concrete priorities to help achieve these goals. Through a series of regional initiatives together with national programmes, activities on the global level and multiple targeted projects, the Sector works with partners in government and industry to mobilise the technical, human and financial resources needed 35 to develop ICT networks and services to connect the unconnected.

It promotes an enabling regulatory and business environment through a range of tools for policy-makers and regulators to support innovation and a more efficient marketplace. It supports the deployment of new technologies through projects to bring access to rural communities, and helps create an ICT-literate workforce through technical and policy training initiatives. Acting as a promoter 40 and catalyst for ICT development, ITU-D engages with government leaders and the international donor community to find the right balance between public and private investment. Recognising that there is no “one-size-fits-all” strategy to create digital opportunity ITU-D assists Member States in elaborating targeted national e-strategies, working to create a culture of security. In addition, ITU-D offers statistics on trends and developments in the ICT field and organises study groups on issues 45 facing governments and industry.

ITU-D provides opportunity for governments and private sector companies interested in forging new development partnerships, by identifying “win-win” opportunities for collaboration, and linking external partners with experienced ITU project specialists to ensure successful project implementation.

ITU-D’s activities, policies and strategic direction are determined by governments and shaped by the 50 industry its serves. The Development Sector’s diverse membership includes telecommunication policy-makers and regulators, network operators, equipment manufacturers, hardware and software developers, regional standards development organisations and financing institutions.

http://www.itu.int/net/about/budget/2008.aspx

http://www.itu.int/net/about/itu-t.aspx

http://www.itu.int/publications/sector.aspx?lang=en&sector=2

http://www.itu.int/net/about/itu-d.aspx


Page 33

The mission of the Telecommunication Development Sector (ITU-D) encompasses ITU’s dual responsibility as a United Nations specialised agency and an executing agency for implementing projects under the United Nations development system or other funding arrangements.

3.3.12.4 International SDO cooperation The World Standards Cooperation (WSC) was established in 2001 by the International 5 Telecommunication Union (ITU), the International Organization for Standardization (ISO), and the International Electrotechnical Commission (IEC) in order to strengthen and advance the voluntary consensus-based international standards systems of ITU, ISO, and IEC. The WSC also promotes the adoption and implementation of international consensus-based standards worldwide; and resolves any outstanding issues regarding cooperation in the technical work of the three organizations. 10

Several initiatives have been undertaken by the WSC since its constitution, including workshops, education and training, and the promotion of international standards system in several contexts.

ITU, ISO, and IEC believe that international standards are an instrument enabling the development of a harmonized, stable and globally recognized framework for the dissemination and use of technologies, best practices and agreements, which support the overall growth of the Information 15 Society. Indeed, their transparent and consensual mechanisms, based on the possible contribution of all interested stakeholders, as well as their extensive network of national members, represent strong assets for market relevance and acceptance, as well as for more equitable development.

The three organizations are working together to implement the strategic role of international ICT standards for development and trade, as recognized and reflected in the declaration of principles and 20 plan of action adopted by WSIS.

Many ITU-T Recommendations are jointly developed and/or published with IEC and ISO – usually through JTC 1. With free access to these only from ITU, and with the Dresden and Vienna Agreements between IEC/CENELEC and ISO/CEN respectively this clearly creates an asymmetry in the business models. 25

3.3.13 JTC 1 Information technology standardization has some unique requirements as a consequence of the pace of innovation. Therefore, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1, Information Technology. ISO/IEC JTC 1 has accordingly developed and maintains its own procedures, as well as collaborating with the International Telecommunication Union - 30 Telecommunication Standardization Sector (ITU-T) in the maintenance of a guide to collaboration between ISO/IEC JTC 1 and ITU-T and rules for the drafting and presentation of common ISO/IEC/ITU-T texts.

In view of the dynamic nature of IT standardization, as part of the process of maintenance of its procedures, ISO/IEC JTC 1 develops Supplements to the Procedures for the technical work of 35 ISO/IEC JTC 1 on Information Technology. Such Supplements are published by ISO/IEC and are available from the ISO/IEC Information Technology Task Force (ITTF http://www.iso.org/ittf). Such Supplements may be incorporated into subsequent editions of the Procedures for the technical work of ISO/IEC JTC 1 on Information Technology.

The ITTF is responsible for the day-to-day planning and coordination of the technical work of JTC 1 40 relative to IEC and ISO, and supervises the application of the ISO and IEC Statutes and rules of Procedure.

The scope of JTC 1 is "Standardization in the field of Information Technology" where "Information Technology" includes the specification, design and development of systems and tools dealing with the capture, representation, processing, security, transfer, interchange, presentation, management, 45 organisation, storage and retrieval of information.

Its members are National standards Organisations. There are 40 Participating (P) Members and 42 Observers (O) Members. Other organisations participate as Liaison Members. There are 14 Liaison members Internal to ISO and IEC, and 22 External Liaison members.

JTC 1 is composed of 18 Sub-Committees and 2 Special Working Groups and 3 Study Groups, 50 comprising approximately 2100 technical experts from around the world

The final product of the work conducted within JTC 1 is the published international standard. In a typical year around 140 standards are published.

http://www.iso.org/ittf


Page 34

Associated with the development of JTC 1 standards are 40 Registration Authorities which are organizations approved by ISO/IEC for performing international registration in various technical areas.

3.3.14 OASIS OASIS (Organization for the Advancement of Structured Information Standards) was founded in 1993 under the name SGML Open as a consortium of vendors and users devoted to developing guidelines 5 for interoperability among products that support the Standard Generalized Markup Language (SGML). OASIS changed its name in 1998 to reflect an expanded scope of technical work, including the Extensible Markup Language (XML) and other related standards.

OASIS is a not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society. The consortium produces more Web services standards 10 than any other organization along with standards for security, e-business, and standardization efforts in the public sector and for application-specific markets. OASIS has more than 5,000 participants representing over 600 organizations and individual members in 100 countries.

OASIS is distinguished by its transparent governance and operating procedures. Members themselves set the OASIS technical agenda, using a lightweight process expressly designed to 15 promote industry consensus and unite disparate efforts. Completed work is ratified by open ballot. Governance is accountable and unrestricted. Officers of both the OASIS Board of Directors and Technical Advisory Board are chosen by democratic election to serve two-year terms. Consortium leadership is based on individual merit and is not tied to financial contribution, corporate standing, or special appointment. 20

A wide range of informal relationships means that a number of SDOs have used OASIS specifications in an eHealth context – as can be found by searching for "health" on the OASIS website.

3.3.15 OMG OMG (Object Management Group) has been an international, open membership, not-for-profit computer industry consortium since 1989. Any organisation may join OMG and participate in its 25 standards-setting process. Its one-organisation-one-vote policy ensures that every organisation, large and small, has a voice in its process. Its membership includes hundreds of organisations, with half being software end-users in over two dozen vertical markets, and the other half representing large and small organisations in the computer industry.

OMG’s modelling standards, including the Unified Modeling Language (UML) and Model Driven 30 Architecture (MDA), enable visual design, execution and maintenance of software and other processes, including IT Systems Modeling and Business Process Management. OMG’s middleware standards and profiles are based on the Common Object Request Broker Architecture (CORBA) and support a wide variety of industries.

The requirements document that initiates each OMG standard-setting activity (the Request for 35 Proposal) and other key documents are available for viewing by anyone, member or not. Email discussion, meeting attendance, and voting are restricted to members; though prospective members are invited to attend a meeting or two as a guest observer.

The OMG Healthcare Domain Task Force is actively engaged as part of a joint collaboration with the Health Level 7 (HL7) Standards Group in producing industry healthcare SOA standards. The 40 Healthcare Services Specification Project (HSSP) is the moniker under which these join activities are occurring. All current work, minutes, agendas, and activities are available on a shared wiki site, available at: http://hssp.wikispaces.com .

Many SDOs and other consortia maintain liaison relationships with OMG. OMG is an ISO PAS submitter, able to submit specifications directly into ISO’s fast-track adoption process. OMG’s UML, 45 MOF and Interface Definition Language (IDL) standards are already ISO standards and ITU-T recommendation.

3.3.16 Regenstrief Institute Regenstrief Institute, Inc. (http://www.regenstrief.org/), an internationally recognized informatics and healthcare research organization, is dedicated to the improvement of health through research that 50 enhances the quality and cost-effectiveness of healthcare.

http://hssp.wikispaces.com

http://www.regenstrief.org/


Page 35

The Institute's informatics group […] developed the Logical Observation Identifiers Names and Codes (LOINC®) system, a standard nomenclature that enables the electronic transmission of clinical data from laboratories that produce the data to hospitals, physician's offices and payers who use the data (now over 50,000 observation terms) for clinical care and management purposes.

Regenstrief also maintains the Unified Code for Units of Measure (UCUM) code system, a related 5 standard that includes units of measures being contemporarily used in international science, engineering, and business.

3.3.16.1 Logical Observation Identifiers Names and Codes (LOINC, http://loinc.org/)

The purpose of LOINC® is to facilitate the exchange and pooling of clinical results for clinical care, 10 outcomes management, and research by providing a set of universal codes and names to identify laboratory and other clinical observations.

The Regenstrief Institute maintains the LOINC database and supporting documentation, and the RELMA mapping program.

3.3.16.2 The Unified Code for Units of Measures 15

The Unified Code for Units of Measure (UCUM http://www.regenstrief.org/medinformatics/ucum) is a code system intended to include all units of measures being contemporarily used in international science, engineering, and business. The purpose is to facilitate unambiguous electronic communication of quantities together with their units. The focus is on electronic communication, as opposed to communication between humans. A typical application of The Unified Code for Units of 20 Measure are electronic data interchange (EDI) protocols, but there is nothing that prevents it from being used in other types of machine communication.

3.3.17 W3C The World Wide Web Consortium (W3C http://www.w3.org/) develops interoperable technologies (specifications, guidelines, software, and tools) to lead the Web to its full potential. W3C is a forum for 25 information, commerce, communication, and collective understanding.

The World Wide Web Consortium (W3C) is an international consortium where Member organizations, a full-time staff, and the public work together to develop Web standards. W3C's mission is "To lead the World Wide Web to its full potential by developing protocols and guidelines that ensure long-term growth for the Web." 30

W3C primarily pursues its mission through the creation of Web standards and guidelines. Since 1994, W3C has published more than 110 such standards, called W3C Recommendations. W3C also engages in education and outreach, develops software, and serves as an open forum for discussion about the Web. In order for the Web to reach its full potential, the most fundamental Web technologies must be compatible with one another and allow any hardware and software used to 35 access the Web to work together. W3C refers to this goal as “Web interoperability.” By publishing open (non-proprietary) standards for Web languages and protocols, W3C seeks to avoid market fragmentation and thus Web fragmentation.

W3C's global initiatives also include nurturing liaisons with national, regional and international organizations around the globe. These contacts help W3C maintain a culture of global participation in 40 the development of the World Wide Web. W3C coordinates particularly closely with other organizations that are developing standards for the Web or Internet in order to enable clear progress.

W3C operations are supported by a combination of Member dues, research grants, and other sources of public and private funding, and the Supporters Program. […] The W3C Offices work with their regional Web communities to promote W3C technologies in local languages, broaden W3C's 45 geographical base, and encourage international participation in W3C Activities.

The mission of the Semantic Web Health Care and Life Sciences Interest Group (HCLS http://www.w3.org/2001/sw/hcls/), part of the Semantic Web Activity, is to develop, advocate for, and support the use of Semantic Web technologies for biological science, translational medicine and health care. These domains stand to gain tremendous benefit by adoption of Semantic Web 50 technologies, as they depend on the interoperability of information from many domains and processes for efficient decision support.

http://loinc.org/

http://www.regenstrief.org/medinformatics/ucum

http://www.w3.org/

http://www.w3.org/2001/sw/hcls/


Page 36

This group was re-chartered in June 2008, having produced no Recommendation under the previous 2-year charter started in September 2005. The focus appears to chiefly upon bioscience uses of healthcare data – and might thus be regarded as a next-generation research project.

3.3.18 WHO The World Health Organization, as a long-established contributor of standard classifications for public 5 health purposes, issued the following text on the subject of collaboration on health information standards in May 2008.

The WHO openly recognises the leading role of the International Organization for Standardization and its TC215, the European Committee for Standardization (CEN) and its TC251, Health Level 7 (HL7) and the International Health Terminology Standards Development Organisation (IHTSDO). It also 10 acknowledges the work initiated by the eHealth Standardization Coordination Group (eHSCG), in which WHO participated and which brought together representatives from ISO/TC215, CEN/TC251, HL7, DICOM, IEEE, and ITU.

Within its 2009-2015 Programme of Work, WHO has now merged all its activities in the field of Health Informatics within the newly established department called Health Statistics and Informatics. As the 15 name suggests, the department will continue the traditional role of WHO compiling health statistics under a new web portal called the World Health Observatory.

A new stream of work on health informatics has been created merging WHO's previous lines of work on eHealth, knowledge communities, classifications and terminologies and GIS to have more coordination and coherence, and to benefit from the critical mass. A new health information strategy 20 is being developed in consultation with multiple parties and stakeholders around the world.

Under that stream of work a new activity has been formally recognised in the line of Health Information Standards. To that end, a systematic review of standardization and standards implementation in the health sector is currently taking place. Until recently, the main line of activities had been in the field of ICT standards for health. The Health Information Standards, however, i.e. those relating to content 25 knowledge like indicators, diagnostic guidelines to guide the implementation of policies and the development of adequate tools, have received less attention. In view of the digitalisation of health information services, proactive thinking is needed to establish a more comprehensive and action-oriented inventory of the current health information practices and standards, together with an analysis of their actual implementation. This activity has been placed under the Classifications, terminologies 30 and Standards unit.

As a priority contribution to international work in that area, WHO considers that a Global Health Information Standards Repository could serve as an access and dissemination platform for health information standards and their implementation. Building on work already initiated elsewhere, and in partnership with leading standards development institutions, WHO would undertake to mobilise 35 support and resources to build an international health information objects repository (International IOD repository) and to coordinate health information standards implementation aspects on a web-based platform. Registered users would be invited to browse, search and download standards for use in their health information systems.

As a semantic wiki with a contextual database accessible under an open access policy, due 40 consideration being given to the administration of socio-economic and legal issues, such as liability, intellectual property and security, the proposed platform would facilitate access to existing health information standards. It would also assist in identifying needs, priority areas and gaps in content areas where health information standards are being contemplated, developed or tested, and assist in the harmonisation and complementary aspects of the work of HIS developers. It would serve to 45 communicate on, and promote the adoption and use of, endorsed health information standards. It could also be used to monitor the adequacy of health information standards, including with regard to their development, uptake and implementation.

WHO, in response to its Member States' request in numerous areas relevant to public health action, invites all interested parties to join in discussions to create a common roadmap for this activity, 50 focusing on its form, functions, resources and sustainability. It should result in a joint international plan of action that would involve other UN bodies and related organisations, EU partners, excellence centres around the world, foundations and industry partners.


Page 37

3.4 SDO coordination in eHealth Following the ITU-T Workshop on “Standardization in e-Health” in May 2003 a formal invitation to join the "eHealth Standardization Coordination Group” (eHSCG) was sent from ITU to WHO, ISO/TC 215, CEN/TC 251, IEEE/1073, IEC/TC 62, DICOM and HL7 and asked for acceptance to joint and nomination of a representative. All except IEC responded and participated in the planning phase. 5 Subsequently, OASIS also joined the group. The overall objective was to promote stronger coordination amongst the key players in the e-Health Standardisation area. Unfortunately, after reasonable initial progress on sharing of workplans and deliverables, the group became inactive due to changes in roles of the involved individuals. Although the website is still available the materials available there are now some years out of date. 10

The Healthcare Technology Task Force, formed to respond to the "Recommendations of the World Standards Cooperation High Level Workshop" of February 2004, met and discussed standardisation issues in the medical device and healthcare informatics technology sectors. The Task Force made recommendations to further the development of globally relevant standards in these sectors. However, because of the dominant representation of the medical device industries, the 15 recommendationsxlix tend to be focussed on the regulated medical device sector. The high-level guidance is nevertheless of relevance in the context of this Report:

1. Strengthen the communications [among healthcare sector committees and committees writing general (non sector-specific) standards];

2. Foster cooperation among globally relevant SDOs; 20 3. Promote the visibility of achievements and existing programs, enable optimal and effective use

of the international standardization system; 4. Incorporate effectively the risk management approach in the standardization process; 5. Join forces and achieve better synergies to support developing countries.

In 2007 the "Joint Initiative on SDO Global Health Informatics Standardization" (http://www.e-25 health.standards.org.au/cat.asp?catid=43) was established between CEN TC251, HL7 and ISO TC215, noting that:

- Standards Development Organizations (SDOs), with their respective technical committees and their stakeholders for health informatics standardization have collectively identified a need and opportunity to collaborate, coordinate and cooperate in delivering global, implementable 30 standards;

- Standards are a necessary enabler of interoperability in the health care domain to meet demands of health care participants, to meet national and regional mandates for health care and thereby to create and sustain a global informatics market;

- The overarching vision for collaboration, coordination and cooperation is one of harmonization, 35 where a singular set of standards and tests address a singular health business need;

- Harmonization of standards involves an engagement, from common scope and purpose, to aligned development and agreement on content, to a single best standard for each problem, and finally to full mutual recognition and endorsement of standards; and,

- Working together, SDOs can leverage standards development resources, solve shared issues 40 in a timely and responsive manner and avoid overlapping, counter productive and counteracting standards.

It affirmed that, in their work together, the participating SDOs will:

- Use accepted best practices for standards development;

- Be business requirements driven with a project-based approach; 45

- Agree on expectations regarding commonality of strategy and process, using appropriate quality and risk management techniques;

- Coordinate work programs using collective and individual SDO resources and eliminate standards work that is overlapping or counterproductive;

- Acknowledge and utilize standards work that can be adapted or adopted for use in health care 50 from other standards bodies and domains;

- Engage stakeholders, be customer-focused;

http://www.e-


Page 38

- Provide common communications to shared external stakeholders and communities of interest; and,

- Be issue, work and results focused (not having an “umbrella organization”.

Although the work of coordination is still in its early stages, and has only been possible because of the work already started by motivated individuals, there have already been tangible benefits in some long-5 standing areas of difficulty. In 2008 CDISC (3.3.2) and IHTSDO (3.3.10) joined the active participants, but only time will tell how effective such a voluntary arrangement is – it is always at risk because of the role of individuals. What is clear is that with increasing globalisation of the eHealth market there is little point the ESOs trying to reverse the flow of market trends – the best we can hope to achieve in some circumstances will be to ensure that the flow is diverted or temporarily restricted in order that 10 European policy, culture and practice have time to adapt.

Since the late 1990s CEN TC251 has cooperated closely with DICOM to avoid duplication of work and to reference DICOM as a formal EN; since the establishment of ISO TC215 it has developed a similar policy – in this case producing an ISO reference standard (see 3.3.4).

An earlier cooperation in CEN was with the IEEE 1073 (see 3.3.8) and is now formalised in ISO, 15 resulting in identical EN ISO/IEEE standards. The relationship between published EN ISO/IEEE 11073 standards and the proposals in the ETSI STF355 TR 102 764xlvi have yet to be assessed but will need to be managed carefully.

3.5 Standards deliverables The various terminologies applied to the types and status of formal standards can be confusing to the 20 uninitiated, so the following table (3.1) attempts to clarify some of the more commonly occurring terms, and give a (simplified) indication as to equivalence with some of the other SDOs.

Being simplified and non-exhaustive, this cannot reflect the detail of equivalence between deliverables – and in practice it makes little difference to their acceptance. Nor can we readily establish the comparative real-world value of the outputs. 25

Sadly, it is common for some groups in many of the bodies listed in Table 3.1 to issue specifications and standards without any evidence that they have actually been tested in real working systemsl.

As an example of good practice, the requirements of the Information Standards Board for Health and Social Care (ISB HASC) in the UK NHS (and perhaps analogous bodies in other MS) are explicit about their expectations of developmental stages: 30

There are three sequential stages of standard, each with a specific focus that ensures that the developer and sponsor of a standard ultimately has provided evidence through testing that a standard is needed, is fit for purpose, is implementable and integrates with other standards.

- At Requirement standard stage, … assures that there is a defined need for the standard to be developed for use within the NHS and that there is a funded development and implementation 35 plan;

- At Draft standard stage, … assures that there is early evidence [through testing] of the standard being able to deliver the benefits which were described in the 'Requirement';

- At Full standard stage, … assures that there is evidence that the standard is implementable, interoperable and safe and is supported by an ongoing maintenance and update process. 40

Although this type of rigour is difficult to enforce it is something that we attempt to provide for in our proposals in later sections of this Report (see 4.4).

Anchor points: 45 Some standards development groups issue specifications and standards without any evidence that they have actually been tested in any real working systems. Standards development needs to ensure that there is a defined need for the standard, evidence through testing of the standard being able to deliver the benefits and assures that there is 50 evidence that the standard is implementable, interoperable and safe and is supported by an ongoing maintenance and update process.


Page 39

Table 3.1: Comparison of terms and equivalence between various standards bodies

WTO* Stage /

status Body

Preliminary / preparation Non-normative Normative

CEN CENELEC

New work item (NW)

Working draft (WD) then Committee draft (CD)

Public draft for Enquiry (prEN)Draft Workshop Agreement on

web for comment (CWA)

Technical Report (TR)

Workshop Agreement

(CWA)

European Standard (EN)

Technical Specification

(TS) Workshop Agreement

(CWA)

ETSI Proposal Working draft (WD)

Committee draft (CD)

Group Specification

(GS) / Special Report (SR) /

Technical Report (TR) / ETSI Guide

(EG)

Technical Specification

(TS) ETSI Standard

(ES) European

standard (EN)

ISO IEC

New work item (NW)


Public draft for international

ballot (DIS/FDIS)

Technical report (TR)

Technical specification

(TS)

International Standard (IS)

ITU Proposal


Public draft for international

ballot

Technical report Recommend-

ation

HL7 Proposal Committee draft

Draft for Membership

Ballot

Implementation guidance

Draft standard for trial use

(DTSU) Standard

IEEE Project

authorization request (PAR)

Committee draft

Draft for Membership

Ballot Guide

Technical specification

(TS) Standard

Continua Use Case Capability Proposal

White Paper Draft for

Membership Ballot

Draft Design Guidelines

Design Guidelines N/A

DICOM Proposal Committee draft

Public draft - Membership

ballot

Implementation guidance Standard

GS1 Proposal (Change Request)

Business Requirement

Analysis Document

Business Solution Design

Technical Solution Design

Pilot Standard (Posting)

IHE Profile proposal

Draft Supplement for

Public Comments

Trial Implementation

Supplement White Paper Technical

Framework N/A

W3C Proposal Committee draft

Public draft - Membership

ballot Recommend-

ation

*NOTE: The WTO stage/status, and solid background colour, indicates direct recognition at intergovernmental treaty (World Trade Organisation) level. The striped background indicates indirect WTO recognition through ANSI affiliation. The deeper colour assigned to the EN indicates that it has priority status over all other standards and 5 requirements in public sector procurements inside the EU (see Decision 87/95).

3.6 Standards process The attempt to deliver standards in a more timely and responsive fashion, particularly in areas where they are intended to stimulate economic activity, means that shorter overall production timescales have been imposed. This has the effect of reducing time for pre-publication testing and correction. 10 While it is often said that "the best is the enemy of the good", implying that perfection is not


Page 40

achievable, it is a reasonable expectation of standards users that a standard should be fit for purpose and not contain errors.

The "EU Study on the policy needs for ICT standardization"iii examined the issue of the relationship of research to standardisation in some detail so we will not repeat those discussions. In health informatics, perhaps encouraged by the origins of CEN TC251 in the EU Advanced Informatics in 5 Medicine (AIM) R&D Programme, there has been (particularly in the early, funded, work of the TC) a tendency to use the standardisation process as a means of undertaking collaborative research and development. This has not always served the needs of the users, supply- or demand-side, well. Although, as part of standardisation development processes, collaborative research and development can be extremely important in getting standards right the work needs to be aligned with application 10 and use. R&D often lacks proper scoping and definition and the right balance of participation and in these cases has demonstrably delayed production and adoption of relevant standards in the EU, and International, eHealth areali.

It has been notedlii, maybe due to the complexity of the technical content proposed, that technical inconsistencies and erroneous application of formalised notations too often make their way through 15 standards approval into publication because these defects have not been resolved or even addressed by comments at all. This is a widespread problem where the global pool of active experts is very small, so that the whole standard is conceived, promoted, drafted, reviewed and approved by the same unrepresentative group of contributors. A misplaced sense of good manners amongst National Standards Organisations tends to mean that, instead of voting against a standard because the content 20 is too arcane to be understood or abstaining in ballots because they have no expertise in the area, they vote approval because the document editors "appear to know the subject".

The following innovative suggestions have been made to help address this problem, which may relate to the conflict of interest caused by editor(s) also being the motivator(s) of the standard:

1. That the relevant technical committees (TC) impose rules that require independent review 25 before a CD is submitted for voting. These reviewers should be mentioned in the CD and should be allowed to create a comment on the technical consistency and correctness of the CD content and have that comment published along with the CD without the TC or the authors influencing that review comment.

2. That if comments on CD, or later stages, mention apparent technical defects in the submitted 30 content it is again required to have further independent review. These reviewers may then alter the content according to the comments received in public voting procedures and/or publish an independent review comment.

A more general, and not novel, comment is that the status of document known variously as a "pre-standard", "draft for development" or "draft standard for trial use" (this last, as used by HL7, seems the 35 most accurate) be an explicit and mandatory part of the development process for all standards in areas of technical novelty. The assessment of novelty would have to be made by the reviewers of the new work item proposal – and explicitly reassessed at each development stage. Only after an agreed number of technical implementations should this status be amended to full standard. We note that the English Health and Social Care Information Standards Board (see 3.5) has a scale of maturity and 40 approval for use that might have wider application.

These problems are reduced if any standardisation project has a balance of demand and supply-side interests from the outset. The American National Standards Institute requires, but does not check rigorously, balance in ballot pools; but this is too late in the process if an apparently reasonable standard has been drafted cleverly by a particular group of interests in such a way as to result in a 45 market distortion. Standards provided by industry consortia have become common in recent years but tend to be tilted in the interests of particular industry groupings. In health there has, particularly in the area of knowledge representation, to be a very transparent means of getting properly balanced clinical input and acceptance. Again, the ICT Study reviews some of these issues in a more general context.

Thus far we have seen standards primarily from the point of view of product. In fact, there are several 50 levels of standards (oddly, there is little consistency in how these are viewed – for example the list below from the ICT Study omits the syntactic level), and standards can concern the exchange as well as process or applications:

- Business level: definition of user use cases (though as we'll see in Section 4 this becomes more layered than this simple description implies); 55

- Semantic level: information, nomenclatures, coding and conceptual models … (see too Annex C);


Page 41

- Functional level: definition of the functions supported by systems and reflecting the needs of users. Example: creation of the patient identification, research of the patient identification based on multi-criteria items, … ;

- Application level: description of the architecture based on the grouping of the functions;

- Technical level: communication, protocols, … . 5

Note that security, and other process related, aspects actually need to be addressed in all of these levels, and may usefully be thought of as orthogonal with respect to the 'levels'.

At each level, the target is not always the same – a point we develop further in Section 4. However because of this it is difficult to describe the characteristics of a “good standard”. The most satisfactory general description is perhaps to quote from the 'Guidelines to assist members of standards 10 committees in preparing user-oriented European Standards'liii published by the International Federation of Standards Users (http:// www.ifan.org) and which closely mirrors the ISO/IEC Directivesliv:

It is the purpose of a European Standard to set out clear and unambiguous provisions which facilitate trade and communication. To this end, a European Standard needs to: 15

- be as exhaustive as necessary within the limits of its scope;

- take full account of current technology and science;

- provide a basis for subsequent technological development;

- have been prepared with user and consumer acceptance in mind;

- make correct use of the appropriate phrasing and terminology (e.g. verb forms for mandatory 20 aspects);

- be comprehensible to qualified users who have not been directly involved in its preparation.

These then imply that any standard should have:

- have a clear scope – the "what";

- have a clear purpose – the "why"; 25

- have a defined audience – the "who"; and

- be able to communicate as concisely as clarity permits (only) what is necessary – the "how".

Anchor points: 30 As the eHealth market globalises, standards to address safe communication must converge to enable the benefits that can be delivered by interoperability. SDOs, including the ESOs, need to collaborate to enable their specialist strengths to address the considerable demands. 35 More rigorous development processes are needed to deliver specifications, including standards, suited to market needs.

3.7 Barriers to standards adoption 40

The analysis below highlights some of the barriers in interoperability standards adoption. We present them in a consistent format with a conclusion for each barrier topic. Understanding at least these barriers is critical in finding the road to eHealth interoperability. Although we have identified some interim conclusions from the observed barriers the editors are aware that the identified barriers have an effective solution contributed by the means to overcome them discussed in Chapter 4. 45

3.7.1 Gaps in standards Individual or expected sets of standards fail to cover all necessary aspects.

http://www.ifan.org


Page 42

Impact on eHealth-Interoperability: Despite implementers' and users' expectations a standard fails to address all the aspects necessary for implementation – so a 'local' adaptation is produced, leading to a lack of interoperability. Conclusion: Any new standard expected to assist interoperability should have a declaration of known omissions 5 from apparent scope at time of publication.

3.7.2 Overlap among standards Pairs or expected sets of standards duplicate cover at crucial points. Impact on eHealth-Interoperability: Duplicated coverage of specification leads either to unwanted optionality or to conflicting provisions – 10 both impose a lack of interoperability (noting that consistent duplication [replication] does not create inherent inconsistency – but conflicting coverage of analogous provisions does). Conclusion: Any new standard expected to assist interoperability should have a properly described analysis of incompatibilities and interdependencies with existing standards in widespread use. 15

3.7.3 Combination of standards from different SDOs Combining the use of different standards from different sources generally requires to make choices in the linkages between these standards. Impact on eHealth-Interoperability: Implementations of the same combination of standards with different approaches to linking them 20 results is incompatibilities and non-interoperability. Conclusion: Any new standard expected to assist interoperability should have a properly described analysis of interdependencies.

3.7.4 Developing or choosing the “best” standard 25

Technical excellence of a standard may reduce implementability – particularly if it has no relationship to other relevant standards. Impact on eHealth-Interoperability: Development of perfect standards is a long and near-impossible process, imposing delays in delivery and/or unforeseen implementation problems. A technically comprehensive standard in a domain tends 30 to be inaccessible to those not involved in its production, resulting in implementation errors and lack of interoperability. Conclusion: Any standard expected to assist interoperability should have clearly expressed scope, purpose and statement of relationship to other standards with a plan to provide enhancements only on an ‘as 35 needs’ and incremental basis.

3.7.5 Standards evolve faster than time to implement The temptation exists amongst technical experts to polish a finished, or completing, standard on a timescale that is shorter than the time taken to align to product life cycle. Impact on eHealth-Interoperability: 40 Uncertainty caused by rapid following of a technical or process fashion introduces adoption paralysis amongst would-be implementers, whilst waiting for the next, "better/more up-to-date", version. Conclusion: Any standard expected to assist interoperability should be stable and revised only when it serves market need to do so. 45

3.7.6 Standards offer too many options The wish to accommodate the 'needs' of different interests typically results in unsought, and often undocumented, optionality.


Page 43

Impact on eHealth-Interoperability: Unintended optionality results in variability of implementation to the extent that interoperability is lost., so that if you have seen one implementation of a standard you seen just one way to implement the standard Conclusion: 5 Any standard expected to assist interoperability should have clear constraint of optionality and dependency.

3.7.7 Poor implementer input to standards writing Lack of implementer engagement can result in theoretical standards with little or no real-world value. Impact on eHealth-Interoperability: 10 Lack of implementer engagement can mean that standards are too complex or technically demanding to work (often in informatics this is displayed by a sender-only perspective, with inadequate view of burden imposed on input-ers or receivers of implementation). Conclusion: Any standard expected to assist interoperability should have a properly representative mix of 15 stakeholders involved in both writing and testing the proposals.

3.7.8 Paper only informatics standards Paper only standards are the default means of publication by many official standards organisations but are unsuited to support of informatics implementations. Impact on eHealth-Interoperability: 20 Paper-only provisions are easier to publish with errors and can introduce transcription errors at implementation. Can paper only informatics standards be considered final? Conclusion: Any standard expected to assist interoperability should have either content that can be copied electronically and used ‘as is’ to produce a test implementation, or informative and web-based 25 material and tools freely available to support dissemination. Ideally such material should be made available in appropriate electronic formats – perhaps without ever requiring paper publication.

3.7.9 Standards cannot be implemented unless finalised The attempt to achieve perfection in a standard can cause resource to be redeployed before delivery is achieved. 30 Impact on eHealth-Interoperability: Uncertainty caused by stalled production introduces adoption paralysis amongst would-be implementers, whilst waiting for the definitive version. Conclusion: Any standard expected to assist interoperability should have a clear status, declared completion 35 timescale and an identifiable project leader who can be contacted for further clarification.

3.7.10 Poorly defined, or absent, conformance criteria Lack of specified means to truly test conformance to a standard. Impact on eHealth-Interoperability: The absence of clear and rigorous conformance criteria provides poor implementations with wriggle-40 room in contract disputes. Conclusion: Any standard expected to assist interoperability should contain clear and rigorous conformance criteria.

3.7.11 Standards do not address all communication levels 45

A standard may invalid assumptions about the ability of another aspect of the operational, process or technical infrastructure to support its provisions.


Page 44

Impact on eHealth-Interoperability: Such a standard is then, however good its internal provisions, an orphan in the interoperability landscape – and has only a distraction impact. Conclusion: Any standard expected to assist interoperability should be specific about the nature and quality of 5 services assumed of other communication levels.

3.7.12 Standards address application needs only in a generic way A standard may be so non-specific about addressing domain requirements that it has to be interpreted to make it adequately specific. Impact on eHealth-Interoperability: 10 Interpretation of any informatics standard leads to unintended discrepancies in implementation – and thus to lack of interoperability. Conclusion: The fact that general architectural terms may be unspecific to a healthcare domain does not mean that generic standards cannot be laid out. The risk of not delivering general standards is that inconsistent 15 standards be created, each one dealing with a very specific domain but all of which are incoherent with each other. A common denominator (architectural) standard must lie underneath to avoid this critical issue. So generic standards are useful to assist coherence of architectural strategy but should not be produced or used, without clear declaration of application domain, as the sole basis for interoperability. See too the brief discussion of this issue in 5.3.3 and Annex D. 20

3.8 Standards inventory

3.8.1 General considerations The terms of reference of this Report require an inventory of standards to be prepared. Such inventory exercises are commonly undertaken but usually prove to be a time-constrained study of perpetual motion because they are very difficult to scope; are inevitably out of date even before 25 publication - and are of rapidly diminishing value thereafter. Without dedicated ongoing resource, such inventories are of little value to would-be standards users. We have therefore separated the bulk of our inventory from the main Report text and that bulk is contained in Annex A – Inventory of standards. The role of this section is then simply to explain how we started to deal with inventory issues – and then, when the task became too onerous, what we now recommend instead. 30

3.8.2 Structured inventory method The extended project team analysed existing standards with reference to three orthogonal axes to which they are related: Process (design, manufacture, deployment and maintenance), Technical infrastructure and Use domain. These axes are largely independent of demand- or supply-side role and are, at different stages in the life cycle, applicable to each role. Additionally, any one standard 35 may have aspects applicable on more than one, and sometimes all three, axes.

3.8.2.1 Process-related standards Process-related standards have to be evaluated for their applicability in specific product-oriented applications from a management, governance or regulatory perspective.

3.8.2.2 Technical infrastructure standards 40

Technical infrastructure standards may be considered explicitly in implementing eHealth applications but in many instances the technical infrastructure is assumed to be in place by the specific content domain for a particular type of user. Criteria for selecting such infrastructure elements depend on the requirements of the respective application, but also on availability of implementations of such standards and their acceptance in the field. Standards in this group cover the technical and, to some 45 extent, semantic levels described in 2.2.4 and Annex C. See too the discussion of this issue in 5.3.3 and Annex D.


Page 45

3.8.2.3 Use domain related standards Use domain related standards are related to particular aspects of functionality with which a user will interact in their work. Standards in this group cover the business, semantic and application levels described in 2.2.4. See too the discussion of Semantic issues in Annex C.

3.8.2.4 Alternative methods of analysis 5

Whilst it would have been in some ways attractive to have used the 'viewpoints of the Reference Model for Open distributed processing, Viewpoint specifications (ISO/IEC 10746-1)lv it would have been difficult to manage the presentation of these views in the simple spreadsheet approach that we have been limited because of the time available. However, these viewpoints are described below for reference. 10

A viewpoint (on a system) is an abstraction that yields a specification of the whole system related to a particular set of concerns. Five viewpoints are said to cover all the domains of architectural design. These five viewpoints are:

- the enterprise viewpoint, which is concerned with the purpose, scope and policies governing the activities of the specified system within the organisation of which it is a part; 15

- the information viewpoint, which is concerned with the kinds of information handled by the system and constraints on the use and interpretation of that information;

- the computational viewpoint, which is concerned with the functional decomposition of the system into a set of objects that interact at interfaces – enabling system distribution;

- the engineering viewpoint, which is concerned with the infrastructure required to support system 20 distribution;

- the technology viewpoint, which is concerned with the choice of technology to support system distribution.

For each viewpoint there is an associated viewpoint language, which can be used to express a specification of the system from that viewpoint. 25

3.8.3 Outcome and recommendations In Annex A we started work on the basis of the tri-axial categorisation and allocation of keywords aligned on our chosen axes and by analysing the title and scope statements. The tri-axial organisation was relatively easy but the use of keywords to provide the basis for grouping the published and in-progress standards regrettably, and somewhat surprisingly, it proved difficult - to the 30 point of near-impossibility.

Attempts to access any modern or representative set of keywords applicable to health informatics when searching the resources of the International Medical Informatics Association, or its American or European counterparts were fruitless. The U.S. National Library of Medicine Medical Subject Headings (MeSH) proved to be outdated; the best found were those for the by the Association for 35 Computing Machinery (ACM) Computing Classification System (1998 Version) said to be “valid in 2007”. However, these are more generally applicable to ICT than eHealth and thus address only the process and technology keyword areas.

So, although we had intended to provide an analysis based on commonly available keywords related to healthcare, health informatics, computer technology and telecommunications this was not possible 40 in the time and resource available. Because such a list is not readily available – only the computer technology area is well covered – we have not proceeded further with this work. Annex A is therefore incomplete and inadequate as an inventory of the standards available in the eHealth domain.

Any structured inventory of eHealth standards developed would therefore need to be resourced adequately so that it can be constructed appropriately, have broad and deep international coverage, 45 and be maintained in a timely manner for the foreseeable future. This may be deemed an appropriate supporting activity for Phase 2 which may either continue in the existing manner, or it be subsumed into the one of the emergent resources, such as that of the Joint Initiative Council inventorylvi, the HL7-related-work entries in association with its work items, or the Standards Knowledge Management Tool developed by the University of Sherbrooke in Quebec, Canada (the most comprehensive such tool 50 known to the Project Team).


Page 46

Anchor points: Appropriate keywords are not readily available in a form suitable for structuring an inventory of eHealth standards. 5 Any structured inventory of eHealth standards will only be useful to users if resourced so that it can be constructed appropriately, have broad and deep international coverage, and be maintained in a timely manner for the foreseeable future. 10

3.9 The safety / security, privacy dilemma This short review of the safety, security and privacy issues that have to be addressed by eHealth standards is placed here because there are broad implications for other standards in the eHealth and other e-services areas – but the topic has strong links to the identification of persons addressed in 5.3.2 and Annex B. 15

There are frequent debates, and disagreements, about the place of standards addressing these topics (see Glossary).

In general, privacy is a relativistic socio-political construct subject to wide cultural variation in understanding. There is European legislation that governs a citizen's right to privacy.

Standards for establishing safety / security mechanisms can assist in delivering ICT that conforms to 20 the requirements for privacy. Processes to ensure safety / security can also be used to reduce the risk of harm caused by erroneous communication of information – independent of any expectations of privacy.

In the context of eHealth there are established ICT standards (or provisions in standards) that assist in meeting safety / security, and privacy requirements and expectations. In some instances (e.g. 25 telecommunications, informatics and medical devices) there are also sector specific standards that have been developed – often, in an EU context, in support of an EC Directive, under the "new approach" to legislation (see Annex A). Some of these sector specific standards are derived from the more general area standards (e.g. of ICT); others are philosophically different and specific to their sector. This difference of underlying principle is beginning to create some problems with the rapid 30 convergence of technologies from different sectors as new sectors and principles emerge.

Recent work on the European Interoperability Framework [EIF] lvii, and in CEN/ISSS Workshop on Data Protection and Privacy (WS/DPP) lviii provides pointers to the way in which this, and other organisational co-interoperability, might be accomplished. Annex B provides a survey of related requirements in the citizen and profession identification area. However, data privacy standardisation 35 is still not well-founded. The CEN/ISSS Workshop mentioned above focuses mainly on business issues to implement the Directive (there is one technological work item in terms of an early warning system). More work is needed to define the health privacy needs and standards in more depth.

At a more clinical level, engagement with activities such as The European Network for Patient Safety (http://www.eunetpas.eu) might be valuable for gaining better understanding of how ICT enabled 40 practice can deliver specific safety improvement priorities in patient care.

Anchor points: As the scope of e-Processes extends to absorb 'conventional' technologies a coherent EC 45 approach to safety / security responses to risk management will be necessary. eHealth standards, especially for safety / security and privacy, should be developed in concert with those for other e-Processes, with a clear plan for accommodating the requirements of existing sector-specific arrangements. 50

http://www.eunetpas.eu


Page 47

4 Standards Adoption and Lifecycle

4.1 General considerations Healthcare Interoperability shares some of the typical development and adoption challenges common to any business domain, but also has some specific challenges.

The common challenges include: 5

- Establishing market demand for a standard

- Prototyping the use of a standard to validate its maturity

- Synchronising product availability to support early adopter projects

The healthcare specific challenges include:

- Combining healthcare specific standards with general purpose IT standards; 10

- Significant complexity at the application level with complexity and variability in medical practice;

- A coordinated evolution from the installed base of health IT systems used within different organisations (e.g. hospital, pharmacies, doctor practices) and governmental (regions, nations) responsibilities to provide increasingly interoperable functionality.

This section proposes a high level methodology to address the most critical standards development 15 and adoption challenges. It is intended to offer an analysis framework to better manage the large portfolio of standards reviewed in this Report and to lay the foundation for an effective development and adoption process.

The DG ENTR sponsored study "ICT standards in the health sector: current situation and prospects" lixstates (page 62): 20

“A sound and enduring mechanism for e-health standards life cycle management and consolidation should be established.”

Better understanding such a lifecycle should offer a springboard in proposing a more sustainable and efficient governance not only in the area of standards development but in the even more challenging area of standards adoption to reach the objectives of this eHealth standards Mandate. 25

The principles of the “Joint Initiative on SDO Global Health Informatics Standardization" (JIC, see 3.4) proposing accepted best practices for standards development provide a useful guide:

- Be business requirements driven with a project-based approach;

- Agree on expectations regarding commonality of strategy and process, using appropriate quality and risk management techniques; 30

- Coordinate work programs using collective and individual SDO resources and eliminate standards work that is overlapping or counterproductive;

- Acknowledge and utilize standards work that can be adapted or adopted for use in health care from other standards bodies and domains;

- Engage stakeholders, be customer-focused; 35

- Provide common communications to shared external stakeholders and communities of interest; and,

- Be issue, work and results focused.

4.2 Achieving interoperability in eHealth As discussed in Section 2.2.4 interoperability means: “the ability of information and communication 40 technology (ICT) systems and of the business processes they support to exchange data and to enable the sharing of information and knowledge”, and Section 2.2.2 defines eHealth as: “cost-effective and secure use of information and communications technologies in support of health and health-related fields, including health-care services, health surveillance, health literature, and health education, knowledge and research”. 45


Page 48

This sets in front of us a large field of information exchange to be used in varied business contexts, such as the citizen’s home, within a hospital and any of its departments, pharmacies, nursing homes, physician offices, public health departments, research units, diagnostic centres (e.g. imaging, laboratory, etc.), and many more. This includes also the exchange of information between these many health related entities. 5

The requirement for this Report is to propose a three-year plan for these broader eHealth requirements, focusing on a first milestone. This focus reflects the realisation that the broader eHealth goal may have been considered too poorly focused. But it may be indicative of a concern that the health standards community has not provided a timely answer to eHealth interoperability, despite the promises. Much standards development has been accomplished over the past 10 years, but many in 10 the European health context express frustration of the lack of progress in the interoperability of deployed IT systems.

Should one focus on specific projects and bring the standards as needed in the design of the interoperability needed for each project? This appears a more pragmatic solution, which is widely used today in, for example, hospitals faced with integrating their health IT systems. Unfortunately this 15 approach has two weaknesses:

1. a fragmented use of the standards with much project specific customisation and, 2. an approach which is costly to scale and maintain at the level of regional and national

interoperability.

Over the last few years, it has become commonly recognised that technology independent 20 requirements often called “Business use cases” xliii are a good starting point, which provides the balance between generic and focused. The analysis of each use case from an interoperability point of view should form the foundation on which objective decisions can be made about standard selection, reduction of the available options and defining a clear combination of standards that together could be implemented in order to achieve the expected interoperability. The most common understanding of 25 this process revolves around four main steps:

1. Identification of a use case or set of requirements 2. Selection of supporting interoperability standards, with the selection of options 3. Implementation, conformance testing, certification 4. Deployment in projects, which closes the feedback loop from the real world. 30

Such a use case based approach (see 5 and Annexes B and D for further discussion and examples) is now widely recognised:

- is recommended by the draft European eHealth Interoperability Recommendationix;

- It has guided the definition of the European large Scale Pilot with the epSOS project launched which includes two specific use cases; 35

- It has been unanimously approved by ISO TC215 in its technical Report TR 28380lx;

- It is used by several national programs (Austria, Netherlands, USA, England, etc.), see Annex D.

In the next sections this high-level process, along with the necessary supportive education, will be further analysed and refined. 40

Anchor point: Start specification with the Identification of a use case or set of requirements — a “use case” based approach. 45 On this basis it selects and combines supporting interoperability standards with the reduction of options. It then proceeds with implementation and conformance testing/certification and leverages “real-world projects feedback” to provide the necessary balance between generality and focus. 50


Page 49

4.3 The different classes of standards-related specifications

The review of the standards that need to be combined and used to address the broad range of interoperability requirements in health leaves us with the major challenge to organise the many facets of the interoperability challenge and corresponding solutions. Not only do the standards cover 5 different quite distinct domains: security, information transport, structure of clinical information, coding of medical knowledge, identification of the citizen, management of privacy and confidentiality, etc., but one should also recognise that a project specific approach to the selection and customisation of standards results in a patchwork of solutions where similar problems find different standards-based solutions. This is unfortunately the situation today in Europe that needs to be addressed. 10

How can an overall European consistency (architecture or urbanisation some would say) be maintained so that addressing new use cases, may become easier and reuses some components of the standards solutions defined from previous use cases?

This is a complex problem, the down side of the project specific approach. What seems to be a reasonable response has emerged over the last few years: 15

- An intermediate level of “interoperability building blocks” or profiles is created in order to introduce flexibility without negative impact on interoperability.

This “componentisation” concept is increasingly used in the modern software architectures. However, Interoperability standardisation is of a different nature than software development, the building blocks are standards-based Interoperability Specification packages (rather than software modules), but the 20 principles are similar. Various industries besides health have used this approach, calling the building blocks, “profiles”, “composite standards” or “implementation guides”.

These interoperability standards-based building blocks form the middle layer in three levels of standards related specifications. For the purpose of this analysis, these interoperability building blocks will be called Profiles while the foundation layer will be called: Base Standards, and the upper 25 layer called Interoperability Specifications. This is summarised in Figure 4.1 below.

Figure 4.1: Interoperability Base Standards-based building blocks Note: the Profiles layer is made of Profile Specifications that are recognised at the European level, hence the 30

blue colour, but with a recognition that this is driven by the Member States. This portfolio of Profiles thus creates a common foundation which ensures that the country or regional Interoperability Specifications share this common interoperability foundation, but may introduce some additional constraints or extensions (shown by different texture of the same colour).


Page 50

The remainder of this section describes each one of these three levels of standards-related specifications. Building on this three level structure, quality assurance is discussed in Section 4.4 and finally the necessary management or governance to produce these specifications and their adoptions is discussed in section 4.5.

4.3.1 Base Standards 5

These specifications define terminologies, data structures and protocols that are foundational to delivering open interoperability. They are quite generic and are often specified to meet a rather broad range of needs and context of use. These are often created or endorsed by national or international standards development organisations.

As discussed in Section 3.6, standards may be classified along different levels: 10 - Business level: definition of user use cases (though as we'll see in Section 4 this becomes

more layered than this simple description implies);

- Semantic level: information, nomenclatures, coding and conceptual models … ;

- Functional level: definition of the functions supported by systems and reflecting the needs of users. Example: creation of the patient identification, research of the patient identification based 15 on multi-criteria items, … ;

- Application level: description of the architecture based on the grouping of the functions;

- Technical level: communication, protocols, …

As our objective is to drive the adoption of standards directly related to interoperability, this means standards that directly impact the way information is being exchanged between eHealth applications 20 supported by ICT systems (what goes on the “wire”), the Base Standards of first importance will be those focussed on the Semantic and the Technical Levels. Especially in the area of security and privacy, some key Base Standards will be required at the functional and application levels.

In general such Base Standards are either: (1) quite broad in scope and range of use cases they may support, so that in reality only a subset of provisions is generally used, or (2) very specific and need to 25 be combined with other Base Standards to address any real-world use case. It is not uncommon to encounter Base Standards in health that require both treatment (1) and (2) when adopted in a specific project.

Annex A provides a survey of the current portfolio of Base Standards from the major European or International healthcare SDOs introduced in 3.2.6. It is important to note that a number of more 30 specialised health or ICT SDOs not mentioned there should be accounted for, resulting in about 30, possibly 40, SDOs from which eHealth could draw Base Standards. This list is quite impressive and would discourage any policy maker from entering what appears to be a jungle, where only the expert, or the well guided, can expect to find their way.

Experiences in Base Standards selection for a typical use case such as those discussed in Section 5 35 commonly start with anywhere between 500 and 800 relevant standards4 to analyze to finally select between 20 and 30 of them. Not only this is a large effort that is too often repeated project after project, but it unfortunately leads to significant variability, and therefore fails to deliver interoperability beyond the confines of a specific project, and delivers a highly customised solutions that are quite often non replicable in other projects of similar and sometimes identical scope, within the same 40 country or across different countries.

4.3.2 Profiles Profiles form a “glue” layer of specification that both combines and refines the use of a set of Base Standards to address a specific “Technical use case". Often, Business use cases are broken down into Technical use cases, for example patient identification is a Technical use case that is in many 45 instances a subset of one or more Business use cases. Generally these Technical use cases are somewhat specific, but are selected for their ability to be reused across multiple Business-level Use

4 For example, the CWA for the eHealth Insurance card (eEHIC) was supposed to have a very narrow focus and specific

plan but ended up reviewing between 50 to 150 standards for each clause analysing between 10 to 40 in the inventory and using between 5 to 20. Multiply this by 5 clauses and this order of options is produced (and it is likely that some less visible specifications were missed).


Page 51

Cases. These Technical use case driven specifications create an intermediate layer of interoperability building blocks, which are sufficiently modular to offer flexibility for recombination, thus forming a manageable portfolio so that the risk of building incompatible solutions to the same use case is greatly reduced. As a result,the reuse of such Profiles will increase the consistency across a broad range of use cases in standards selection and implementationlxilxiilxiii. 5

Each Profile provides a well-specified interoperability service among a number of communicating actors (at least two, but often more). It should not rule how these communicating systems should be designed internally but focus on their engagement as interoperating actors in the context of the Profile. Such Profiles only constrain the way information is exchanged and in a number of cases the fact that these communicating systems must properly process the information (interoperability behaviour). 10 These concepts are quite common in the most modern IT system design and architectural methodologies. It remains important that “friendly neutrality” to these implementation methodologies be maintained in the Profile Specification to allow competition amongst implementations offered on the market and application to the large installed base of health IT systems.

Profiles address a broad range of interoperability aspects covering information transport, security, 15 data structures and related data models, associated terminologies, privacy and service contracts. Profiles are defined in such a way to ensure relative independence and different approach to their orchestration (e.g. address a broad range of country specific security and privacy policies).

One should expect that in the area of eHealth, for the most common use cases, a portfolio of a few tens of Profiles should address the core needs across a small number of domains such as security, 20 privacy, patient identification, record sharing and access, care coordination record content, specialty record content, home monitoring, referral and consultation workflows, etc. This Report will further evaluate the state of the art of “profiling” approaches (see 3.3.9 for a current example) and propose a European approach. It will also sketch the Profiles that would be needed to support the two use cases identified as first steps for this Report. 25

4.3.3 Interoperability Specifications This third level of standards-based specifications is directly related to the Business use cases it is intended to support.

Every eHealth project needs to deliver to its participants a clear set of specifications dictating the way to interface the systems used for healthcare or wellness management with an IT infrastructure 30 supported by a regional/national health information network. Such specifications are sometimes called: interface specifications, implementation specifications, project specifications, etc. As the objective of this Report is not to dictate the way to implement a regional or national health information exchange network, or specific point of care or home health systems, this section introduces the term of “Interoperability Specification” to convey that it: 35

- addresses only the specifications related to the “interfacing” of health related management systems to a home/point of care, regional or national infrastructure, not the internal design specification of all aspects of any such networks, or that of any IT system connected to it.

- offers a specification on how to exchange information, not a piece of software. This ensures technology independence to support systems of various generations, operating systems 40 environments, programming environments, hardware architectures, and business models (commercial, open source, etc.).

Figure 4.2 demonstrates how the various type of specifications that are developed by national projects are related to the project Interoperability Specification and how the Base Standards are used as a foundation for the development of a set of European-recognised Profiles, which in term form the core 45 of the projects Interoperability Specifications.


Page 52

Figure 4.2: Relationship between Interoperability Specifications, Profiles and Base Standards in the context of testing and project use

Because of the local or national requirements (administrative, clinical or regulatory), some 5 customisation of the underlying generic European-recognised Profiles is expected. If both the Base Standards and the Profiles have been designed with this in mind, one would expect that only a few specific (but critical) adjustments/additions would be required. Such Profile extensions, although of the same nature as the European-recognised Profiles, are placed at the level of the Interoperability Specification, because they will need to be developed and owned by the related project. It may be as 10 simple as requiring or forbidding an option (e.g. the exchange of race information), constraining the structure and terminology contents of specific fields (e.g. a social security identifier, or a type of provider). It may extend up to defining a project specific Profile, when the portfolio of European-recognised Profiles is incomplete. In all of these cases feedback to Profile definition bodies is essential to drive the maintenance and re-use of these Profiles - and the addition of new ones. 15

However, the main task of the Interoperability Specification will be to effectively assemble and combine the right set of Profiles to address the business-level use case. Interoperability Specifications will be specific to a project (national, regional or local to an institution), but their construction being largely based on Profiles should enable faster implementation, reuse of software and test tools, and an easier understanding of the customisation required by each project engaged in 20 leveraging standards-based interoperability. Guidelines to the developers of such specifications should be provided as part of the implementation of this Mandate to align their format across eHealth projects. This will facilitate feedback to the Profiling and Base Standards organisations in evaluating the need for additional Profiles, standards or corrections.

In addition to Interoperability Specifications that are technical in nature, there is a need to make: 25 1. implementation architecture choices (technical performance targets, configurations, etc.) which

will have significant operational implications; 2. policy decisions in terms of security, privacy, data management responsibility, etc.

These are important elements in order to achieve interoperability, but are considered to be out of the scope of this Report. However, it is critical that the Profiles offered for assembling Interoperability 30 Specifications, be aligned with the range of architectures, security and privacy policies and national laws and regulations to be supported.


Page 53

Anchor points: Distinguish, and recognise, three classes of standardisation products (specification) to enable 5 interoperability in eHealth: Base Standards; Profiles (recognised at the European level); and Interoperability Specifications (recognised at a regional or national eHealth project level). 10 Consider an approach for organising the process for adoption of eHealth Interoperability Standards around these three types of deliverables.

It is important to note that the development of Profiles and Interoperability Specifications follows a 15 different process than that of Base Standards. The two main differences rest with:

- the ability to set a fixed schedule for Profiles and Interoperability Specifications which is not easy, nor advisable, for Base Standards;

- the requirement to integrate the development of Profiles and Interoperability Specifications with actual testing, implementation and pilots, as well as in terms of governance, which 20 requires a different type of engagement for the stakeholders than does that of Base Standards development.

In the next section, 4.4, the quality management required to support implementations of these three classes of standards-related specifications will be discussed.

4.4 From standards-related specifications to quality 25

implementations With the identification of the three classes of specifications (4.3) a major foundation has been established to actually deliver, in implemented IT systems and health devices, the interoperability the users of the systems (care providers, patients and health authorities) expect. Section 4.5 discusses the processes and governance needed to ensure the relevance of Profiles and Interoperability 30 Specifications to practical use cases, their open availability, controls to be applied for their precision and robustness and their stability over time.

But a specification that is not correctly implemented, and that cannot be implemented because of internal inconsistencies or errors will not deliver its promise. This is particularly true in the field of interoperability, where a minor discrepancy between the information sent and the processing of it in 35 the receiving system results in a complete, or dangerous partial, failure of interoperability. In healthcare, many processes exist today to ensure that quality or safety in medical products is delivered — or that issues, if identified, can be promptly resolved. However, these processes generally involve a single implementer or vendor (e.g. as for regulated medical devices); eHealth interoperability brings a new challenge to healthcare in that interoperability quality needs to be 40 delivered across many systems and devices from a broad range of implementers (anywhere from fifty to several hundreds of suppliers in a regional or national project). This challenge is of a new dimension. It is a known problem to the IT and Telecommunications industry; but is a relatively new priority in the domain of eHealth interoperability, at a scale and in a market environment where the management of such processes among stakeholders is not yet in place. 45

The effective application of quality requires both a process and management. The remainder of this Section will focus first on the “what” needs to be done to deliver systems that will “plug and play” according to the specifications discussed in Section 4.3. Section 4.5 will then move to addressing the management and governance needed to ensure that quality is achieved.

4.4.1 Quality of specifications 50

Much effort is invested in the development of Base Standards to ensure their quality, but until implemented, this quality if often difficult to assess. The same applies for Profile Specifications, however their narrower focus on a specific Technical use case makes their quality an easier challenge


Page 54

to address. Once the Quality of the underlying Profile Specifications has been achieved, the quality of Interoperability Specifications, focused on well-specified Business use cases has now been greatly simplified.

The quality inheritance, and the reuse of Profiles across Europe is a significant cost saving opportunity. Most eHealth projects would recognise that reaching a solid quality level in 5 Interoperability Specifications is expensive and time consuming. By focussing investment in the short-term on Profile Specifications, some Base Standards quality issues can be addressed only in areas needed to support the specific Technical use case. This focus ensures a shorter response, and allows longer-term strategies for iteratively improving the quality of Base Standards, which is a far broader and more complex problem (see 3.5). 10

Anchor point: The reuse across eHealth projects of Profiles (recognised at the European level) is critical to improving the quality of Interoperability Specifications used in regional or national eHealth 15 projects. Quality control management in the Profile Specifications is a critical success factor.

4.4.2 Quality of implementations 20

Quality assurance of implementation needs to be gauged by reference to the related Use Cases and Specifications. Because, the objective in the quality of the implementation of interoperable eHealth application software is naturally focused on its intended use, it is necessary to establish a strong quality assurance approach at the Profile implementation level. This offers several benefits:

- Right level of specification: The balance between supporting a sizeable interoperability 25 challenge, but no so large that its implementation and quality assurance become too complex. Too small is not worth the effort, too big becomes a major risk.

- Step size: This is a significant integration step related to a real world Technical use case around which the Profile has been designed and specifies a combination of Base Standards.

- Flexibility: This can be tested in varieties of ways, offering many complementary quality 30 assurance verification strategies (peer system tests, tests against test harnesses, code reviews, etc.)

- Reuse: Because of the European-wide (possibly international) reuse of the Profile, quality assurance resources, skills and tools can be pooled. Shared quality assurance processes can be leveraged across regional and national (and possibly international) European projects. 35

- Focus: Only the applicable parts of the Base Standards called for in the Profiles need to be tested, thus focussing the quality efforts both for the eHealth projects and the implementers.

4.4.2.1 Quality of Profile implementations Quality assurance of implementations at the Profile level is therefore a central element that needs to be defined as a specific task. It may be one step removed from an actual eHealth project, but as 40 discussed above, it is a level that would gain significantly by being organised at a European level for the benefit of the national, regional and local projects. This organisation will be further discussed in Section4.5. We need to be clear about the critical elements of the quality assurance task associated with the implementation of European-recognised Profiles: 45

- A proper subset of the Profile, as defined in the Profile, shall be the focus of quality assurance. It could be defined as one of the “actors” among which the Profile defines transactions (real-world products may support specific actors related to their function, e.g. a physician medical record system may support a different actor than an infrastructure repository system). 50 It could also be defined in terms of content and vocabulary subsets to be supported by different specific systems (e.g. a pharmacy system and a laboratory system).


Page 55

- For a proper subset, a test plan should be defined associated with test tools. These Profile specific plans and tools could be specified once, developed and shared among the interested parties: eHealth projects, healthcare entities to be interconnected, commercial and open source developers, etc.

- One or more Quality Assurance complementary processes could be defined, under a 5 suitable quality control authority, to enable labelling of quality assurance outcomes. This may or not require the establishment of certification entities. The organisation of quality assurance processes will be further discussed in Section 4.4.2.3

10 Anchor point: Quality Assurance for Profile implementations requires the development and maintenance of test plans, processes and tools, which should be easy for implementers across eHealth projects in Europe to use, and reuse. 15

4.4.2.2 Quality of Interoperability Specification implementations Interoperability Specifications assemble and combine a set of relevant Profiles to address specific business-level use case. Interoperability Specifications could be specific to a project or a series of similar projects at the national, regional or local (i.e. internal to an institution). As their construction 20 should be largely based on the reuse of European-recognised Profiles (see Figure 4.3), the quality assurance associated with an Interoperability Specification should build upon that discussed in the previous section on Quality of Profile Implementations (4.4.2.1).

25

Figure 4.3: Relationship between Interoperability Specifications, Profiles and Base Standards in the context of testing and project use

Each project, or family of similar projects, would simply need to establish its quality assurance process at the local, regional or national level, with the prerequisite that any implementation meets Profile implementation Quality Assurance requirements. The test plans and tools for Interoperability 30 Specifications would need to focus only the added value brought by the Interoperability Specification and on proper integration of the selected Profiles. This should ensure that the ultimate test for an eHealth project will be at the level of its own specific Interoperability Specifications, but without duplicating the extensive testing already performed at the Profile level.

Based on experience with IHE (see 4.3.2), this approach should considerably reduce the costs and 35 the risks for eHealth projects and their participants both on the industry and the healthcare delivery side.


Page 56

4.4.2.3 Quality assurance labelling A Quality Assurance process may need to include some form of labelling to allow for the easy identification by external parties to the implementation that the quality assurance was effectively and satisfactorily performed.

This is process called by a variety of names, often using the word "certification". The term certification 5 is often misleading because it seems to imply that a third party tester has to be engaged in the attestation of the quality assurance. This is not always the case, and many schemes without third party testers have been used in the medical, and other, industries. Many of these quality assurance schemes are quite complex to understand, and what appears a simple approach may often turn into overburdening framework. 10

Some labelling programmes extend beyond the technical aspects to cover users’ and technical manuals, the quality of the assistance (e.g. help desk) and training. Whatever the quality labelling approaches used, all require the same basic infrastructure of test processes, test plans and test tools. It is the policies related to their use within the context of a labelling program that will differ.

When labelling is applied to the generic interoperability of a product, a number of variants may be 15 considered. Among these, three styles of labelling are commonly considered at the level of Profile compliance:

1. Quality system audited self-labelling A quality system is required (e.g. ISO9001) for product development. An auditing process is established that periodically ensure that the quality assurance associated with the product 20 development has been performed per the quality process using the processes, test plans and tools discussed above. A product developer may then claim support for one or more interoperability Profiles, for any product version it releases. Failure to perform the expected quality assurance is detected by the auditing process and the ability to claim any compliance is suspended until the corrective measures have been applied. 25

2. Third party labelling of a unit A third party laboratory received a “sample” of a product and performs the expected quality assurance using the processes, Profile test plans and tools discussed above. It delivers a label for the product. This approach assumes that all shipping products are identical to the sample, which the above approach does not require. 30

3. Cross-testing labelling A multi-product testing event is organised periodically and groups of interoperable products are submitted to a group test style of event – variously known as a “Connectathon” (IHE), “Plugfest” (various) or "Plugtest" (ETSIlxiv). It is usually an entry criterion that each product is individually submitted to the processes, Profile test plans and tools discussed above. 35 Experience shows that, if any product is cross-tested against at least three other independent implementations, a good level of quality is achieved. When their testing and logo systems have been proven, Continua and others may also have a role.

Labelling may also be performed at the level of a project-specific Interoperability Specification. It is reasonable to expect that products be first submitted individually to the processes, Profile test plans 40 and tools discussed above; and only then submitted to complementary tests related to the specifics of the elements added by the Interoperability Specification. This type of labelling sometimes includes performance and other functional tests.

It is important to recognise that different Member States, regional and local projects are likely to use different labelling strategies, depending on current regulation, practice and preference. 45

Anchor points:

Quality Assurance labelling may be performed at the level of Profile compliance, but also at the level of specific Interoperability Specifications. 50

The development and maintenance of test plans, processes and tools at the level of Profile conformance, will be needed irrespective of the type of labelling.

With experiences by IHE with its European Connectathon and ETSI with its Plugtest, some form 55 of cross-testing and labelling seems to be a good starting point. When their testing and logo systems have been proven, Continua and others may also have a role. .


Page 57

4.5 Establishing organisation, coordination and governance

This section builds upon the principles established in sections 4.2 through 4.4 above. It focuses on the elements of basic, but critical, governance by the European Member States and other primary stakeholders to establish the minimum coordination of the standards adoption processes that will be 5 necessary to complement the current standards development processes. As should be clear to the reader, much more than Base Standards development is required to ensure an adoption of the standards in a way that:

- Meets the expected use cases

- Delivers Profiles and Interoperability Specifications to fill the gap between the Base Standards 10 and the realisation of interoperability

- Establishes the necessary quality assurance tools and processes both at the Profile level and at the project Specific Interoperability Specifications and their implementation.

We now therefore address the objectives of the coordination and governance that will engage the primary stakeholders in a positive dynamic to ensure that the barriers listed in section 3.7 are 15 addressed.

Five major processes need to be available in a somewhat autonomous manner, with some overall governance and coordination to empower or accredit them, as discussed in Chapter 6. Figure 4.4 below depicts these five processes in the context of an overall coordination process.

20

Figure 4.4: Key activities to achieve eHealth interoperability.

The following Sections discuss each process, its critical success factors and propose an initial analysis of the European entities that have been conducting activities of this nature so far. Their potential role in forming the foundation for implementing the work programme (Phase 2) of this 25


Page 58

eHealth Standards Mandate as well as the case for a European eHealth Interoperability Coordination Committee as shown in Figure 4.4 is examined in Chapter 6.

4.5.1 Use case definition and prioritisation This process is responsible for receiving proposed Business use cases for European endorsement from the Member States, perform a synthesis among like use cases, and develop consolidated 5 European Business use cases. Among the various consolidated use cases, a critical success factor is the ability to prioritise among these candidate use cases, so that the activities related to standards development, profiling, testing may take place with the proper focus and an orderly roadmap.

The prioritisation is a critical step where the value of, or return on investment for, the use case needs to be identified. Special attention to input from real world projects will need to be analysed, including 10 the barriers to adoption, the level of semantic complexity needed and acceptable in medical practice, the implementation challenges, its contribution to a shared vision, etc.

Such a role has, to some extent, been played so far by the i2010 Group and the Stakeholders Group set-up in 2006-2007 by the European Commission. There is no need for a large forum, as long as there is a good feedback process across the various impacted and knowledgeable stakeholders 15 (empowered representatives of ministries of health, clinical/health IT professional organisations, professional organisations, industry organisations, and citizen/patient representation); see 5.1.

4.5.2 Base standards development, and maintenance This process is responsible for ensuring the continued and increased efficiency in Base Standard development, especially in relationship with the harmonisation of Base Standards. Harmonisation in 20 this context means the identification and resolution of current overlaps and avoidance of future overlaps within the development of European and International Standards. A critical success factor is the ability to engage in harmonisation both within Europe across the breadth of the scope of CEN, ETSI and CENELEC activities as well as across the international standards development, in particular CEN TC251, ISO TC215 and HL7. 25

Such a role has been played so far on the European side by the ICT Standards Board and at the International level by the CEN TC 251/HL7/ISO TC215 "Joint Initiative Council" coordination. The ICTSB has not, thus far, worked specifically in eHealth collaboration issues. The CEN TC 251/HL7/ISO TC215 coordination is in a ramp-up phase and its first projects are reaching the point where its effectiveness may be demonstrated. The challenge of these coordination bodies is their 30 reluctance to make any commitment on behalf of their voluntary membership, knowing their limited influence on their membership. There is no simple solution to this strategic decision making process, other than to ensure the education and engagement of a sufficient part of their membership who is sensitive to the overall standards adoption process. As the eHealth interoperability market is rapidly becoming global the membership of SDOs should increasingly realise the risks of ignoring calls for 35 such harmonisation. In order to ensure inherent quality assurance it is desirable to ensure that the profiling activities are kept reasonably independent from the Base Standards development organisations, thereby establishing a watchdog to measure the progress and effectiveness of the Base Standards development and maintenance.

4.5.3 Profile development and maintenance 40

Profile Technical use cases need to be matched against Business use cases on an on-going basis.

This process is responsible to ensure that the Business use case prioritised and documented by the process described in 4.5.1 is broken down into Technical use cases. Three critical success factors are:

1. the ability to scope the Technical use cases so that the specified Profiles are reusable across several Business use cases; 45

2. have the credibility to attract a good mix of industry, large medium and small and health professional organisations; and,


Profiles cover all layers of interoperability, from transport, to messaging services, to data structures 50 and terminologies; these last two are two of the major elements necessary to provide semantic interoperability in health.


Page 59

An option is to rely on the processes defined by ISO TR28380 IHE Global Standards Adoption Process.

Such a role has been played so far for eHealth by IHE-Europe in scoping the Technical use cases for Europe and contributing to the specification of the Profile through participation in IHE International, resulting in the international acceptance of the resulting Profiles. A number of European regional and 5 national projects have experience in this approach. ETSI has also been successful at playing a similar role for the European telecommunication industry. In the 1980s and part of the '90s, CEN hosted EWOS, the European Workshop on Open Systems, playing a similar role for IT data interoperability, with mixed results.

10

Figure 4.5: Key activities to achieve eHealth interoperability, with stakeholders, deliverables and feedback.

One key question to decide is how important it is for Europe to participate in definition of Profile Specifications that are internationally agreed. Such a route seems synergistic with the European Lead 15 Market Initiative and the continued development of harmonised standards at the international level, as discussed in Section 4.5.2. The experience of EWOS and similar workshops for general ICT interoperability demonstrated that parallel profiling activities are extremely difficult to coordinate5. It has also been suggested to distribute the development of Profiles depending on their scope (e.g. assign to ETSI the telecommunication related Profiles, to Continua the Home Monitoring related 20 Profiles). This is possible, but will require a single core organisation to maintain the consistency among Profiles and avoid duplicative work. Whatever the organisational model chosen for the profiling activities, it will be important that existing Profiles be considered, and if fit to support the

5 The complexities and duplication of work resulting form parallel profiling activities in the large regions of the world

(Europe, North America, etc.) in the ICT data interoperability domain in the 1980s and early '90s was challenged by the Internet Engineering Task Force (http://www.ietf.org) a global entity that successfully established the standards profiles that enabled the rapid emergence of the Internet in the beginning of the 1990s.

http://www.ietf.org


Page 60

European use case requirements, should be recognised for Europe by the Mandate consensus process, thus fostering international alignment.

The above three processes (0, 4.5.2 and 4.5.3) are distinct but should be interrelated in the context of the broader interoperability standards life-cycle. In Figure 4.5 their deliverables (green, red and blue 'document' symbols) primary relationships (corresponding arrows) and the direct contribution from 5 stakeholders are depicted.

4.5.4 Quality assurance of Profile implementations This process is to ensure, for Profiles, the development of conformance test plans and test tools under a coordinated process among the various contributors and users. Users include industry which is implementing interoperability in its products, local, regional and national projects, care delivery 10 organisations such as hospitals, clinics, laboratories, pharmacies, imaging centres, general practitioners, etc. Three critical success factors are:

1. the ability to develop these test plans and tools in a timely fashion so that they could be made available no later than four months after a Profile is recognised for trial implementation;

2. coordinate contributors resources to ensure that quality plans and tools are developed and 15 maintained; and,

3. ensure open access to these test plans and tools and an effective maintenance process engaging the broad range of users.

So far such a role has been played by such as IHE (for eHealth), or ETSI (for the telecom industry), and more recently independent efforts such as Open Health Tools (OHT). Most of these efforts are 20 limited in by their ability to engage the proper level of resources. IHE has addressed the resource problem through the international acceptance of its Profiles and a relatively small fee to participate in its Connectathons around the world. Even with well over 200 participants bringing to Connectathon testing more than 300 systems every year some, mostly specialised, Profiles with lower uptake had to see their test development delayed. The large number of care delivery organisations and smaller 25 regional projects that benefit most from test plans and tools, are the most difficult to engage.

It is therefore critical that the organisation of these quality assurance activities in Europe happens with sustainability in mind, recognising that the addition of public funding would help, but is unlikely to be effective on its own. International pooling of resources and offering supporting testing services to the regional and national projects are two among others avenues worth exploring in Phase 2. 30

It seems important to reduce organisational complexity and foster the parallel development of Profiles and their corresponding test plans and tools by placing both the Profile development and maintenance (4.5.2) and the quality assurance of Profile implementations under the same organisational responsibility. This offers the opportunity to operate both processes in parallel and gain about 12 month in each delivery cycle. 35

4.5.5 Best practice forum This activity is to give every national or regional project a forum to share experiences and publish best-practice guides that offer guidance in conducting the deployment activities of eHealth projects. One key area should be the area of privacy and security policies, where much experience sharing and consistency building would benefit the emergence of a foundation of basic European practices in this 40 complex area. A critical success factor is the ability to define foci around which various communities across Europe would wish to engage. The sharing of best practices is facilitated among projects that share a significant foundation in their Interoperability Specification, hence European-recognised Profiles.

Such a role has been played so far by EHTEL (in a role similar to the one it plays in the context of the 45 European project, CALLIOPE) and a number of conferences at the European level, e.g. World of HIT, Medical Informatics in Europe, and various conferences on interoperability. A challenge for member states will remain that of ensuring that effective bi-directional engagement with projects within their jurisdictions; this will depend on the effectiveness of current and new organisational structures.

4.5.6 Other related activities. 50

Development and maintenance of Interoperability Specifications and quality assurance of Interoperability Specification implementations may not fall within the direct scope of the eHealth


Page 61

Mandate. However, they need to be discussed because they are closely related and their interrelations with the core five activities (standards development, Profile development, Profile quality assurance, best practice forum) is critical to achieve the eHealth Standards Mandate objective of eHealth interoperability. Unless interoperability projects develop Interoperability Specifications using the portfolio of European-recognised Profiles, use quality assured implementations, and share their 5 best practices, interoperability will remain an elusive goal.

4.5.6.1 Access to European-recognised Profiles A supporting activity is needed to ensure easy access to the recognised Profiles that have been identified in support of the use cases. A proactive information and education process about these Profiles should be established to ensure that the hundreds of eHealth projects around Europe take 10 advantage of them and develop Interoperability Specifications as discussed in the next section.

4.5.6.2 Development and maintenance of Interoperability Specifications Local (e.g. hospital or home-based), regional or national projects should be encouraged to structure their Interoperability Specifications according to a common template to facilitate the feedback process (e.g. use project extensions as input for new Profile development), enable comparison, and accelerate 15 tenders. It is proposed that this Interoperability Specification template development and maintenance be managed/coordinated by the same entity as the one managing Profile development and maintenance.

Each one of the five core processes described above shall be organised to encourage and facilitate strong participation with partners’ projects (minimal face to face work, teleconference, a preset 20 calendar of input solicitation and public comments, etc.).

4.5.6.3 Quality assurance of Interoperability Specification implementations Local (e.g. hospital or home-based), regional or national projects should be encouraged to use as an entry criteria, in their quality assurance, the European-wide Profile testing process and labelling. Furthermore, they should benefit from building their test plans and tools by extension from the 25 European Profile testing plans and tools (4.3).

4.5.6.4 Risk management

4.5.6.4.1 General background The Mandate provides an opportunity to review the standards development process (3.6 and 4.3) and to gain benefits from the inevitable and necessary process of change. The application of Risk 30 Management, from early in the process, can be seen as a key factor in meeting the objectives of this development and this section suggests a way forward.

The prevailing management situation is complicated by a number of influencing factors including limited manpower and time resources and a need to encompass the requirements of a number of different organisations. Given such complexities it is considered that there are three predominant objectives that 35 drive the situation. They are as follows:

- the need understand and assess the risks that are applicable to the proposed future business process and to ensure that all aspects that can negatively impact the likelihood of success are identified and progressively mitigated;

- the requirement to keep the risk assessment process as simple as possible so that it remains 40 practicable within the working constraints of the organisation, and;

- the necessity to apply the concept in as short a time as possible so that it effectively supports the ongoing initiative within the allowable time frame.

Rather than attempting to employ a full-scale risk assessment process at this time it is suggested that above mentioned objectives could be effectively addressed through the implementation of the 45 innovative and purpose focused methodology described earlier in this section.

Risk management is a form of knowledge engineering and traditionally risk management would be applied as a stage-by-stage exercise designed to elicit a thorough understanding of the prevailing potential hazards together with an evaluation of their impacts on the business and then to develop appropriate means to reduce or mitigate the resulting risks to an acceptable residual level. 50


Page 62

Given the prevailing time constraints it is suggested that it would be appropriate to reduce this methodology to a pragmatic and very specifically focused initial exercise concentrating upon strategic, high-level management and programme initiation issues. As a starting point this could focus on two very specific factors that contribute to what is generally recognised as an effective risk managed operation, namely, risk awareness and risk based process derivation. 5

4.5.6.4.2 Risk awareness In these circumstances risk awareness is considered to encompass making use of the existing inherent knowledge of the standards development business but combining this with an assessment of the new operating environment created by the Mandate and the proposed collaboration, with a view to being able to clearly demonstrate a risk based understanding of the new working environment and to 10 identify critical issues that should be addressed.

This is considered to be the knowledge based part of the procedure and to meet the recognised time constraints it could be achieved through concentrated workshops and discussions. It is considered that making use of an adapted hazard and operability study methodology, which would provide both structure and rigour to the exercise, could facilitate this. The outcome of this exercise should be a list 15 of pertinent hazards that could be categorised and risk evaluated to provide key inputs to the second stage of the risk-based process.

4.5.6.4.3 Risk based process derivation The second part of the risk-based approach should be to construct a high level procedural model. This would inevitably be based upon the current workings of the European Standards Organisations 20 and the contributing National Bodies but should also take account of new requirements arising out of this Report and, most important of all, should incorporate appropriate mitigations to the hazards identified previously.

In its widest sense a risk-based process should encompass all the essential elements of this business including, for example, methods, resources, politics, economic considerations, relationships, 25 communications, validation and verification. However, to meet the time constraint objectives it is suggested that this initial exercise should concentrate upon the creation of a high-level procedural model that could be used to support and focus attention during inter agency discussions and to provide a foundation or framework upon which more detailed procedures could be based as time and resources allowed them to be developed. 30

4.5.6.4.4 Conclusion It has often been proposed that risk management is only a statement of the obvious and therefore an unnecessary task for experienced operators or managers. However, the obvious is primarily limited to what has actually been experienced and there are many examples of where historical experience has failed to provide sufficient protection against new and therefore unexpected hazards. It is the inherent 35 rigour in modern risk assessment processes that delivers a ‘whole systems’ approach to understanding and managing risk and it is the effective response to such outcomes that increases the likelihood of success of a venture and improves the resulting credibility of an organisation. These are valuable benefits to accrue, all the more so in a multi-cultural, remote working environment such as that of the ESOs, and therefore they should taken into account early in the standardisation/profiling 40 processes

Anchor point: Consider explicitly recognising effective risk awareness and risk based process derivation as an 45 integral part of standards development and adoption.

4.5.7 Research and Process Evaluation See "A Systemic Overview & Synthesis of the Literature - Report for the NHS Connecting for Health Evaluation Programme - The Impact of eHealth on the Quality & Safety of Healthcare"xx for some 50 detailed consideration of the issues. However, that report concludes (on page xxv):


Page 63

"The major finding from reviewing the empirical evidence—which is of variable quality—however, is that there is very limited rigorous evidence demonstrating that these technologies actually improve either the quality or safety of healthcare."

The report also concludes that more thorough research is needed. We propose such research be an adjunct to the lifecycle of standards. 5

The ICT study questioned the relationship between the EC R&D frameworks and the assumption that research provides the basis for innovative standards as follows:

[The] question ‘How can standardisation be used as a mean to leverage the results of EU R&D projects?’ can be further specified into:

- Research output push: How can knowledge from EU R&D projects be transferred to achieve 10 state-of-the-art standardisation?

- Standardisation input pull: How can industry researchers as well as academics be involved more closely in standardisation and how can barriers for participation be taken away.

The questions reframe standards as R&D output, a matter which needs to be done with caution.

The Study notes that "Design by standard committees may need to be avoided", which would appear 15 to address a criticism made of CEN TC251 and HL7 (working on v3), and goes on to note that "one often cannot tell what comes out of an R&D project; that the usability of R&D should lie at the heart of the decision to standardise and that the transition from research to standards making should be a business decision; and that the difference between a technology- and a standards-oriented platform should not be dismissed. Indeed, “the direct transformation of research results into workable 20 standards will hardly be possible in most cases. Rather, research findings typically need to be complemented by real-world implementation experience (…).” (INTEREST, 2007, p108)lxv"

It would seem to be an appropriate rule-of-thumb to assume that R&D output relating to eHealth would, if in any way relevant to standardisation, first progress along the "Workshop Agreement" route before becoming subject to wider validation and being considered for formalisation into Base 25 Standards.

Anchor point: R&D output relating to eHealth standardisation should first progress along the "Workshop 30 Agreement" route before becoming subject to wider validation and being considered for formalisation into Base Standards.

4.6 International experience The effective organisation to achieve standards-based Interoperability is a challenge that many 35 countries have undertaken around the world for the past few years.

Denmark and New Zealand were among the first to demonstrate the need for overall coordination, a coordination that did not at first impose a priori the selected standards and the associated detailed implementation guides (that we call Profiles and Interoperability Specification in this Report). They demonstrated that an organised consensus-building process was required; a consensus process that 40 engaged all primary stakeholders (health professionals, industry, health authorities, citizens) that operated in incremental steps with a focus on a very small number of specific use cases. Part of this process, was the agreement by all parties that the intent was to actually implement and integrate this new interoperability in care delivery. The health authorities were part of the process and committed to support the interoperability technology deployment with the appropriate policy and regulatory changes. 45

Much was learned by the launch of the massive national English program, NHS Connecting for Health (http://www.connectingforhealth.nhs.uk), provision of support for computer systems and services that improve how patient information is stored and accessed by redesign of large parts of the National Health Systems. This project brought forward the idea to move beyond national specific standards and leverage internationally accepted standards (e.g. SNOMED, HL7 V3) strategic for the long-term 50 sustainability of such a large national programme. A second lesson was the realisation that much work remained to be done on standards development. The NHS made significant investments in

http://www.connectingforhealth.nhs.uk


Page 64

standards development and much progress was realised over the past five years. It also highlighted that a number of significant gaps remained in the standards adoption processlxvi, and that development of large-scale conformant health IT products and deployment of interoperability remained a complex undertaking.

In the first few years of the new century (2002-2006), a number of national or regional projects 5 emerged, mainly in Europe (Netherlands, Germany, Finland, and in specific Italian, Swedish, and Spanish regions, etc.). These projects were very different in their scope and approach to the use of standards. The lessons learned from countries with earlier experience seemed to be sometimes taken into account, and sometimes not. Progress has also been rather uneven among them. Given the complexity of these projects, it is not within the scope of this Report to perform a simple analysis of 10 their interoperability strategies. However, most of these projects chose to develop their own strategy, which is generally a standards-based one. But among the great majority of these projects, a standards-based interoperability strategy was clearly realised as one of the major success factors. The same conclusion can be drawn for a few projects outside Europe that were engaged in the same timeframe (Australia, Canada, Hong-Kong). 15

In the 2005-2007 timeframe a number of regional and national projects emerged that chose deliberately a standards-based strategy relying on Profile Specifications developed externally to the project. Some of these projects have reached an operational stage (e.g. Lower Austria Region, Genoa Region), many others are only a pilot or early implementation stage (e.g. South Africa, a China Region, Kobe-Japan, Austria, France). This Report is accounting for this trend and builds upon it. 20

Two rather extensive national projects have drawn much interest and should be briefly discussed in this project. They both have been developed in countries with major responsibilities at the regional health IT jurisdictions (Canada) or a health systems with many overlapping centres of decisions (USA). They both attempted to formalise a national process to engage these various centres of decision. 25

Canada, with InfoWay (http://www.infoway-inforoute.ca/), has created a rather large central team to drive and produce Canadian Interoperability Specifications, exclusively based on International Standards such as SNOMED, HL7, IHE Profiles with external review and feedback in committees organised by InfoWay. Although financing is outside of the scope of this Report, it is important to mention that InfoWay also administers eHealth project co-financing, conditional upon implementation 30 of its specifications.

The United States of America has established a lightweight national program (Office of the National Coordinator – ONC, http://www.os.dhhs.gov/healthit/onc/mission/) with four chartered initiatives, HITSP (HIT Standards Panel, http://www.hitsp.org/), CCHIT (Certification Commission for HIT, http://www.cchit.org/), HISPC (Health Information Security and Privacy Collaborative, 35 http://tinyurl.com/7eh4pt) and NHIN (National Health Information Network, http://www.nhin.com/). Each one of these operates as independent entities, but reports to the ONC and a high-level oversight Committee (AHIC, http://www.hhs.gov/healthit/community/background/). This organisation is intended to be sustainable over time, and to be focussed not on standards development, but on standards profiling (Profiles are called HITSP Constructs), and grouped in Interoperability Specifications to 40 address Business use cases issued by ONC after AHIC prioritisations and public reviews. This system of organisations has been in operation for three years, and market adoption of HITSP specifications is demonstrating progress. The profiling activities are managed by HITSP, a volunteer based organisation, which is pragmatically recognising rather than developing new Profiles when the Business use cases can be supported (e.g. 18 IHE Profiles used in Europe and in other places in the 45 world have been adopted).

This brief overview is not intended to be exhaustive, but to simply highlight some of the background that is taken into account in this Report in term of lessons and potential best practices. While discussing a number of international experiences, the Report focus remains the European political, clinical and technical environment. 50

http://www.infoway-inforoute.ca/

http://www.os.dhhs.gov/healthit/onc/mission/

http://www.hitsp.org/

http://www.cchit.org/

http://tinyurl.com/7eh4pt

http://www.nhin.com/

http://www.hhs.gov/healthit/community/background/


Page 65

5 Inventory of requirements

5.1 Requirements analysis In section 2.2.5 we noted that the meaning of words used to describe requirements is often very ambiguous. The policy imperative to enable cross-border emergency care (or even cross-regional care) is phrased in general terms which seem adequate to a politician or public employee without 5 detailed knowledge of care processes. So, if (without considering here the particulars of the "summary" topic) we use as a study case "the patient summary, as well as an emergency data set, … " identified as a high EU priority, we are able to draw some key conclusions; to do so we will re-use Figure 2.3.

We saw from section 2.2.5 that, in order to arrive at concrete requirements we need better clarity. 10 However, a very brief examination of practice around Europe and internationally, shows that "Summary " is interpreted in a number of different ways – even at the level of semi-autonomous regionslxvii lxviii, and becomes more diverse if a synonymous expression such as "out-of-hours" is usedlxix. For this reason it is important to move the understanding of requirements to the next, organisational, level where a meaningful discussion about purpose within the context of a care 15 provision enterprise (even if very distributed) can be held.

Policy:

Organisation:

Healthcare professional:

Figure 5.1: Reuse of Figure 2.3 to illustrate the cascade of requirements analysis NOTE: this Figure does not attempt to illustrate the iteration between the levels of requirement analysis necessary to ensure

mutual agreement of requirements. Nor does it show a) the horizontal relationship to citizens' requirements that will in many, if not most, instances also be necessary; or b) the potential for reuse of elements of requirements for analogous 20 purposes at the same level.

Only when the organisational requirements are clear is it possible to begin an understanding of the healthcare professional requirements to meet them; this healthcare professional level of requirement analysis necessitates reaching a consensus of healthcare professional views about the information needed to fulfil the task identified. 25

We therefore have a cascade of requirements at different levels of detail (typically in the scale of sentence, paragraph and page), but which to successfully meet the overall "business requirements" must not only meet mutually agreed inter-layer needs, but also the needs of citizens. It is notable that here we have a supply-, demand-side model that does not yet involve any technology whatever; and that, uniquely in the context of this Report, citizens here represent the demand-side, and the totality of 30 the health system, including its suppliers, represents the supply-side.

Using as an example Figure 2.1: Health information infrastructure, we can identify that it would be possible to require all possible logical relationships with most if not all of the service types illustrated even to fulfil the need for provision of an "emergency care record for urgent care" subset of the "care record" to be incorporated. It is unlikely that this would be the explicit political requirement from the 35 outset (though it is likely that there will be implicit expectations). It is more likely that the organisational management will see an opportunity to gather some metrics and public health data from the implementation of an "emergency care record for urgent care" provision – so some "secondary use" requirements are added. It is then possible for healthcare professionals to see an opportunity to gather some interesting data about clinical practice – so more secondary use 40 requirements are added. This scope creep is typical of all such projects involving multiple interests and if any timely outcome is to be achieved has to be managed explicitly and with mutual agreement between all parties.


Page 66

Requirements analysis is then, not a technical endeavour. Only when stable draft requirements are clear is it appropriate to seek guidance about the technical implications about the feasibility of delivering applications in accordance with the requirements. Negotiation about the content and timescale may well be necessary and need further consultation with all specifiers – but a technical specification delivered without clear user-requirements is a common cause of project failure. 5

We can conclude then that in a market-driven (as opposed to technically-driven) approach requirement-driven analysis we can identify requirements from three perspectives:

- population health; what do politicians / health authorities (reimbursement, quality management, regulatory, public health authorities, researchers, etc.) need / want to achieve

- care provision; what do care provider organisations, including both administrative and clinical 10 functions, really need / want to support their work

- citizen / patient; what does the citizen want that requires eHealth standards

These then are legitimate, but different, perspectives on health information interoperability – to which can be added that of vendors as a group. Vendors play an important role in implementing eHealth and they will influence the technical delivery process – including the long-term viability of solutions in 15 the context of a global market. Their perspective should therefore be considered.

Requirements lead to products and products in a complex market need standards.

Anchor points: 20 Requirements analysis necessitates engagement of political, organisational, managerial, and healthcare professional practitioners (not titular representatives) to achieve mutual understanding of the purpose and scope any requirement, and then to agree the information required to support it. 25 Information and workflow requirements are a critical foundation to lead to interoperable products. In a complex ICT market interoperable products need standards. Requirements need to account for the three perspectives of: population health, care provision 30 and citizens' needs.

5.2 Business requirements and use cases The breadth of eHealth requirements makes their analysis quite complex. It is possible to identify particular requirements, or typical problems, and then to use these as the foci for a number of related, 35 but more generic, requirements. Both the specific requirements description, and the more generic description are referred to as use cases. One of the disadvantages of this use case oriented approach is that very often use cases overlap, and similar requirements are addressed multiple times. This issue has been accounted for in the way the Business use cases are broken down into Technical use cases supported by reusable Profiles (see 4.3.2). 40

Figure 5.2: Requirements reflected as clustered use cases


Page 67

Annex D contains an illustrative list of high-level descriptions of eHealth use cases that has been collated from various sources; it is intended to be a list of examples that will make clearer the idea of a use case and is not in an exhaustive list. Since identification and documentation of eHealth use cases is an ongoing activity, a fixed comprehensive list cannot be given, nor is the fact that these examples are cited to be regarded as any comment on their quality or strategic value; it simply reflects their 5 availability.

Each use case is listed in one of three sections using the three perspectives (population health, care provision, citizen / patient) listed in 5.1.

In the rest of this chapter we examine the topics requested by the Mandate in more detail, and in the light of the way of working outlined in Chapter 4. 10

5.3 Requested eHealth application topics

5.3.1 Background The Mandate to the European Standardisation Organisations CEN, CENELEC and ETSI in the field of Information and Communication Technologies, applied to the domain of eHealth, specifically notes "… within the overall eHealth interoperability domain, patient and health practitioner identifiers , the 15 patient summary, as well as an emergency data set, have been identified as the most critical priorities to be covered by standardisation activities." This is a direct quotation from Report of the Unit ICT for Health in collaboration with the i2010 sub-group on eHealth (formerly known as the eHealth working group) and the eHealth stakeholders’ group - Connected Health: Quality and Safety for European Citizens of July 2006v. Some of the background and development of this is reflected in the extracts 20 examined below.

The "eEurope 2005 Action Plan" from 2002lxx states as a proposed action (page 13) " Electronic health cards. Building on the agreement at the Barcelona European Council that a European health insurance card will replace paper based forms needed for health treatment in another Member State, the Commission will make a proposal before the Spring Council in 2003. The Commission intends to 25 support a common approach to patient identifiers and electronic health record architecture through standardisation and will support the exchange of good practices on possible additional functionalities, such as medical emergency data and secure access to personal health information." The 2004 update makes no further mention of the specific topics.

"e-Health - making healthcare better for European citizens: An action plan for a European e-Health 30 Area" x in 2004 stated (page 21) "On the health side, the eEurope 2005 Action Plan states that actions will be taken to build on the European health insurance card. Activities will be launched to support common approaches in Member States that are related to electronic health records, emergency data sets, and electronic patient identifiers. Promoting the use of cards in the health care sector. [Goal:] Adoption of implementation of an electronic health insurance card by 2008." 35

The DG INFO publication "Transforming the European healthcare landscape - Towards a strategy for ICT for Health"lxxi states: "The Action Plan advocates the development of interoperability approaches for patient identifiers, medical data messaging and electronic health records. The ultimate goal is to enable access to the patient’s electronic health record and emergency data from any place in Europe, even outside a citizen’s country of origin or residence, whenever this is required." 40

Indeed the "i2010 eGovernment Action Plan"lxxii under which it might be expected the requirement is stated only mentions health on page 8: "… Specific attention will be paid to citizen mobility services, such as improved job search services across Europe, social security services relating to patient records and electronic health prescriptions, benefits and pensions across Europe, and educational services relating to studying abroad. …" 45

"Ageing well in the Information Society: An i2010 Initiative - Action Plan on Information and Communication Technologies and Ageing" lxxiii states (page 9) "In line with the e-Health Action Plan the Commission will issue a recommendation on e-Health interoperability in 2007, addressing the core e-Health infrastructure data (patient summary, emergency data set)."

In the "i2010 Annual report" of April 2008 lxxiv there is no mention of the priorities; just that "future 50 growth is expected in specialised eHealth services such as e-prescriptions, electronic health records, telemonitoring and homecare."


Page 68

The EC website for i2010 Strategy and eEurope Action Planslxxv provides access to four areas: i2010 eGovernment Action Plan, Action Plan on Information and Communication Technologies and Ageing, eAccessibility and i2010: Digital libraries. Health – or the specific topics mentioned in "Transforming the European healthcare landscape…" are mentioned only in the most general terms and in passing for the first two of these. No reference is to be found there to " Report of the Unit ICT for Health - 5 Connected Health: Quality and Safety for European Citizens of July 2006"v as the source of the identified need for patient and health practitioner identifiers, the patient summary, as well as an emergency data set, as the most critical priorities to be covered by standardisation activities. This is odd in view of the stated collaboration with the i2010 sub-group on eHealth in its production.

If "the patient summary" and "an emergency data set" are interpretations of "social security services 10 relating to patient records" then they are perhaps somewhat naïve and inadequate – and the basis for the omission of the oft-mentioned (by care providers) need for "electronic health prescriptions" is not clear. Though a pragmatic constraint of aspirations from "electronic health records" might be appropriate.

Reviewing the actual contributors to these seminal documents it is clear that all are written without the 15 scale of consensus identified in 4 and 5.1 as being necessary; most participant panels reflect the interests of particular groups. Worthy, and indeed excellent, though many of the documents are they are therefore of limited community, care provider, clinical or patient value. The establishment of the epSOS (see 2.1.7) and CALLIOPExv projects appears to have mobilised for the first time a sufficient mass of potential input across the member states to achieve credibility as both a politically desirable 20 goal and a real priority in terms of service delivery.

Anchor points: Consistent presentation and prioritisation of the policy priorities is vital in ensuring that these 25 messages are taken seriously by those they are intended to influence. Varying policy messages send the message that none of them actually matter. Without consensus amongst the affected parties in Member States the policy messages 30 achieve little impact upon local priorities.

5.3.2 Patient and healthcare professional identifiers

5.3.2.1 Patient identifiers It is fundamental that patients are primarily citizens, to put it in other words every citizen is potentially a 35 (future) patient. Thus, at least at a Member State level, the patient identification is usually, but not always, mapped to another identity, the insurance and national identities being the two predominant ones. Therefore, it is true to say that at MS levels identity management systems are high profile projects with significant political stakes and involve huge investments. For these reasons every Member States has developed a national/insurance/patient identity management system with a vision 40 to achieve specific goals.

The interoperability aspect between national identity management systems and health identity management systems has not necessarily been taken into consideration, or in some cases has been explicitly excluded, while sketching the details of individual solutions. Identity management solutions in most cases were developed in silos, without useful exchange of information, and thus resulted in 45 solutions across the EU, which are lacking the interoperability aspect between them. In many cases identity solutions within a given State is not usually designed to support common standard solutions. At the individual enterprise level issues are even more complicated and divergent, except for countries that have had a single national patient health identifier for several decades.

In general, a citizen from one Member State cannot use their electronic identification (eID) token in 50 another Member State for private or public services, whereas the non-electronic ID can in most cases be used.

The Member States, however, realised that interoperability in eID projects is a requirement and therefore significant progress has been made recently. At the EU level, a roadmap has been agreed upon by Member States that indicates an interoperable eID system by 2010lxxvi. In the 55


Page 69

healthcare/insurance area interoperability work at European level was initiated by Decisions 189 and 190 for the European Health Insurance Card (EHIC) lxxvii targeting development of a means of identification for the European migrant worker (as well as tourist) and their entitlement to receive healthcare services while visiting another MS from that of their original residence – either permanently or temporarily. An electronic version of this card (eEHIC) is currently under investigation for use as an 5 interoperable solution across Europelxxviii.

It appears that there are three closely related use cases that probably need to be distinguished: 1. Interoperability of the health identity tokens carried by citizen in various Member States 2. Front Office Interoperability between health delivery IT systems and the identity management

infrastructure 10 3. Back office Interoperability within the identity management systems and between the systems

from different member states

Each one of these has rather different context of use and engages very different parties. Use Case 1 is primarily a Citizen Perspective Use Case, whereas Use Case 2 is primarily a Care provision perspective Use case. Use Case 3 is more of an infrastructure nature, and unlike Use cases 1 & 2 15 involve only a limited number of parties all over Europe.

The EU has been funding several projects that are tackling the issue of identification from different point of views (mostly point of view 1 and 3). There is also work in progress in CEN with the European Citizen Card standards (15480 series) producing already a wealth of information. CEN has also initiated, then contributed heavily on the patient and administrative healthcare data standards (EN/ISO 20 21549 Parts 5&6) which are considered as the base today not only for health cards, but also in general for identification tokens.

In the healthcare domain IHE has provided implementation guidelines under its PIX/PDQ Integration Profiles, based on HL7 standards that provide solutions for a number of pragmatic use cases for cross-enterprise and intra-enterprise identificationlxxix. 25

Anchor points: Applying the methodological approach outlined in sections 4 and 5.1 to the patient identification use case we find: 30 - A choice of Base Standards exists to address front-office interoperability (between the identity management systems and the health care IT systems used in care delivery). - Profiling has already been done. To ensure that all healthcare systems support the access to cross-referencing and patient 35 demographics queries in an interoperable manner Europe needs to recognise just one such Profile per use case.

5.3.2.2 Healthcare professional identifiers Discussing Health Professional identification is not as straightforward as citizen/patient identification. 40 Again, a number of approaches are currently in existence and are implemented with more or less success.

The main policy document underpinning identification of health professionals is the European Directive 2005/36/EClxxx on the recognition of professional qualifications.

Identification for professionals serves mainly as a) a certification means of eligibility (which is also 45 supposed to protect citizens from unauthorised practice, b) a logging mechanism and c) an access mechanism (both to physical areas as well as virtual spaces).

In regards to profiling, availability is by no means comparable to that of patient identification.

A recently (May 2008) launched project (HPRO Card)lxxxi funded by the Commission is aiming at delivering such a Profile related to a Health Professional (smart) card. In this context it is noteworthy 50 that the NETC@RDS projectlxxxii has successfully demonstrated the feasibility of secure Health Professional card identification (see too 2.1.6.3).


Page 70

However, healthcare professional need to be identified in the context of the organisations for which they work; as well as the departments, peers and patients with whom they work.

A more detailed description may be found in Annex B, but we propose awaiting the use case requirements of the HPro Card and epSOS projects before making detailed workplan suggestions.

5 Anchor points: Applying the methodological approach outlined in sections 4 and 5.1 to the professional identification use case we find: - Base Standards exist to serve some aspects. 10 - Profiling has not been done. To ensure that all healthcare systems support pan-European requirements await the use case requirements of the epSOS and HPro Card projects (synergy with NETC@RDS is welcomed) before making detailed workplan suggestions for professional identification. 15

5.3.2.3 Detailed analysis and conclusions We outline in Annex B the current identity management solutions and discuss a framework for working out a plan for adopting an internationally accepted set of interoperability standards at European level as requested by the Mandate. 20

New work in ITU-T, and associated work in IEC TC25 and ISO TC12, seeks to relate identity to an individual using various biological markers. Whilst at an early stage this has potential for long-term value, particularly in situations where healthcare professional and citizen/patient are not co-located.

5.3.3 "Patient summary" and "emergency data set"

5.3.3.1 The problem of meaning 25

We have already discussed the difficulties in ascertaining with certainty the specific use cases for other topics and will not revisit the strategic importance of establishing clarity and priority.

However, it is notable that for the first time (except for mentions in the context of standards content) since we introduced the topic in 2.2.4 we have to return to the topic of semantic content. Because the object of support for cross-border care implies "the ability, […] to exchange, understand and act on 30 citizens/patient and other health related information and knowledge among linguistically and culturally disparate clinicians, patients and other actors and organizations within and across health system jurisdictions in a collaborative manner"ix it is necessary to question how linguistically and culturally disparate clinicians, patients and other actors and organisations within and across health system jurisdictions are going to collaborate across these cultural and linguistic barriers. This requires 35 semantic interoperability – mostly at the clinical information level, to some extent at the inter- care provider, level, and minimally at the inter-community level. As it is hard to underestimate the impediment that the absence of these resources has been in the effective adoption of eHealth standards.

Annex C discusses the issue of semantic interoperability in more depth; means and ways are 40 presented there. Here we consider a number of difficult questions to demonstrate that this spectrum of dependency across interests is most burdensome at the clinical level:

- Do multilingual representations of clinical semantics for "summary" terms already exist to the level required to achieve safe mutual clinical understanding? Not that the editors of this Report are aware of; although a number of the semantics are probably 45 already available in SNOMED, they have not, for example, yet been validated across a significant number of the languages of the EU. The CEN ISO Categorial structureslxxxiii have a role to play in this regard but are not at present widely used; though the CEN ISO/IEEE 11073 standards and their CEN precursors have used a subset of them successfully, linked to a rigorous ontological model for some years. 50

- Is there in existence an identified mechanism for ensuring the clinical consensus required to achieve safe mutual clinical understanding of "summary" content?


Page 71

Not that the editors of this Report are aware of; although many professional groups have agreed to representations for aspects of their practice there are no standing groups that ensure that resource can be brought to bear across Europe in a timely fashion such that policy and clinical consensus can be reached across these groups, or across natural languages. Thus, although one can safely argue that there is a community of experience for terminology development as a 5 collaborative process (there are even tools available to support such collaborative development), there is still a lot to be decided (on which consensus has to be build) to arrive to safe semantic interoperability spaces recognised across Europe.

- Do multilingual representations of clinical constructs for context already exist to the level required to achieve safe mutual clinical understanding? 10 Not that the editors of this Report are aware of; although many professional groups have agreed data sets for aspects of their practice there are no standing groups that ensure that resource can be brought to bear across Europe in a timely fashion such that practical and policy consensus can be reached across these groups, or across natural languages. The informal collaboration amongst interested clinician-developers facilitated by the OpenEHR foundation on the use of EN 15 ISO 13606 Archetypes is rapidly producing a large number of maximal data sets – though again widespread consensus is missing. There are also templates (HL7), implementation guides or content modules (same as archetypes) on the use of CDA Release 2 content defined by several countries (Germany, Finland, France, Italy, Spain) in the context of their national or regional projects, but no widespread European consensus exists; some countries, such as England, 20 blend both approaches. It can be expected that the epSOS project will contribute to breaking those barriers.

- Do effective collaborative tools exist for testing multilingual, interoperable clinical semantics in a timely manner and at no, or minimal, cost at the point of use? Not that the editors of this Report are aware of in a European context; except for IHE that 25 provides open access tools for CDA based Profile contents and NIST provides open source tools to suit the purposes of the USA (HITSP selected terminologies).

- Do effective collaborative tools exist for developing, maintaining and disseminating interoperable clinical semantics in a timely manner and at appropriate cost to users? Not that the editors of this Report are aware of – at any cost; although a number of 30 terminology authoring groups, such as IHTSDO, WHO, LOINC, HL7 have aspects of these requirements this is a significant absence in a European and international context. This work has not reached maturity yet; IHTSDO is in the process of procuring a collaborative tool and it is only recently that IHE has considered profiling in this area - the recently issued Profile for Sharing of Value sets. 35

Whilst we have made reference to some of the large number of recent projects and papers dedicated to the topic of semantic interoperability there has been a failure of EC understanding of the critical nature of this aspect of eHealth interoperability. It is notable that while, on the evidence of HL7, DICOM and EN ISO/IEEE 11073 implementers, there is enthusiasm to support interoperable semantics the vendors are not the main beneficiaries and are therefore reluctant to commit resource 40 to what are inevitably resource-consuming terminology services. Although there is a somewhat naïve expectation that with health records lots of useful data will be available, recent grid computing projects have been bedevilled by the lack of semantic interoperability at the information level. Semantic interoperability at the level of shared technical constructs (such as in ebXML) is in comparison, though valuable, extremely simple. 45

5.3.3.2 The problem of trust Although semantics are inherent in every implementation, users (and in sometimes vendors) don’t realise their importance until they have to face the issue – it is often not manifested overtly in local system implementations until these are linked with other applications to improve the dissemination of information. In the environment that the EC is aiming toward, in which safe cross-border care is 50 possible, it is easily understood that if information is to be readily available in an interoperable environment, this information needs to be represented at a given point of care in a way that is compatible with the local language and practice. A multilingual application for example does not simply mean support of more than one languages, it means (self?) adaptation in a multicultural


Page 72

(clinical) environment6. It should be noted that even if this barrier is overcomelxxxiv there remain clinical cultural reasons why information from an unknown (in the sense of personal human, peer, networks) may not be trusted as the basis for any type of care. Although harmonised training, accreditation and care protocols across Europe might lessen this barrier (see 2.1.6.2) these should not be viewed as easy issues to resolve. These cultural and practice matters will need Europe-wide consensus before 5 there is widespread use and acceptance of eHealth.

5.3.3.3 The future of meaning Consistent terminology is a first target to meet for semantic interoperability (there are still parts not covered by SNOMED), but then a number of additional actions will be required (in terms for example of document classes or types; archetypes, DRGs, GPICs etc.). Although a number of research 10 projects (EC funded) have produce a wealth of results towards this target in the standardisation arena there is still missing a European framework that will not only provide for clinical semantics, but also a mechanism to maintain this framework alive and up-to-date with acceptable (vendor) cost. So even within a uniform linguistic and cultural environment the interoperability challenges have not yet been effectively addressed despite recent progress; and very little experience exists in the multi-lingual, 15 multicultural environment.

The Commission has identified the need for a broader effort for semantic interoperability in its recent Recommendation for cross-border interoperabilityix, where it calls the MS to: “

(a) establish an appropriate mechanism […] in the development of health semantics to advance in implementation efforts of interoperable electronic health record systems; 20

(b) […] consider […] international medical-clinical terminologies, nomenclatures and classifications of diseases;

(c) agree on standards for semantic interoperability to represent the relevant health information for a particular application through data structures (such as archetypes and templates), and subsets of terminology systems and ontologies responsive to local user needs; 25

(d) consider the need for a sustainable reference system of concepts […]”

However, there is no information on how these aspirations will be achieved. Even within a uniform linguistic and cultural environment the interoperability challenges have not yet been effectively addressed despite recent progress, and very little experience exists in the multi-lingual, multicultural environment. However, since the most immediate towards consistent and comprehensive 30 models/terminologies can be seen in finding the consensus for usage and interpretation of existing terms, the main task in development remains independent from specific notations and tools (see Annex C).

The current Mandate represents a good opportunity to address operational urgent needs and also to agree a strategic roadmap for advancing clinical semantic interoperability at a European level. 35

Anchor point: Semantic interoperability, especially at the clinical information level, is critical to achieving full exchange, understanding and appropriate consequent action among linguistically and culturally 40 disparate clinicians and other parties. For clinical semantics the following are required: - Support for multilingual representations; - Mechanism for ensuring the clinical consensus; - Support for multilingual clinical constructs for context. 45 - Support for collaborative means to develop, test, maintain and disseminate interoperable, consensus-approved, multilingual, clinical content in a timely manner and at no, or minimal, cost

6 It should be noted that even if this barrier is overcome there remain clinical cultural reasons why information from an

unknown (in the sense of personal human networks) may not be trusted as the basis for any type of care. Although harmonized training, accreditation and care protocols across Europe might lessen this barrier these should not be viewed as easy issues to resolve. These cultural and practice matters will need Europe-wide consensus before there is widespread use and acceptance of eHealth.


Page 73

5.3.3.4 Patient summary It should at this stage be stated that the eHealth ERA Report on Priority Topic Cluster One and Recommendations: Patient Summariesxlii provides a comprehensive view of the "Summary" topic, with a valuable review of the issues – albeit again with consensus from a rather small project group.

Given the above comments on semantic interoperability it has to be asked what may be safely 5 achieved by the 2010 goal for delivery of some summary of past care for cross-border care in emergency situations? In that timescale it is unlikely that anything could be implemented which enabled validated multilingual interoperability of clinical information; however, it is possible that basic patient and home provider demographic information would thought adequate as a first step to full implementation. The details of the priorities emerging from the epSOS and CALLIOPE projects will be 10 the major determinants of the requirements for standards and it is impossible to anticipate those in detail.

Because of the legitimate, but maybe not first priority, interests of those wishing to access data in a non-urgent operational context it will be necessary to achieve and retain a strong consensus on the scope of any summary (although this should allow for extension both optionally in localised use 15 contexts, and for future agreed growth).

It is to be hoped that the consensus definitions of the first use cases as part of Phase 2 of this Mandate and availability of epSOS and CALLIOPE project materials will assist in identifying some consensus around requirements and priorities for the summary record and the emergency data set.

5.3.3.5 Emergency data set (EDS) 20

The emergency data set (EDS) is a medical data set describing those elements of the patient’s health history that may be considered relevant in case of emergency care provision to that patient.

It is assumed that the author of such EDS is a medical professional who already selected among available medical data for a given patient and assumes responsibility and liability for the content (s)he entered into the EDS. No assumptions are made whether the EDS is structured into independent 25 entries.

The use cases given refer not only to the data set stored on some medium but to the whole system acquiring, storing and producing the emergency data set, the so-called emergency data set system (EDSS). In order to avoid more specific assumptions, that EDSS is considered to be patient-specific. No assumptions are made whether network access is available or whether IT systems are available in 30 addition to that EDSS. It is neither assumed nor excluded that there is a token with the patient, which provides access to the EDS of that patient by whatever means (e.g. identifying the patient, identifying the EDS record, by storing the EDS).

Comparing the long-term, patient-centric electronic health record (EHR) with the EDS analysed here, one can find that though both serve differentiated purposes, most of the issues with EHRs also appear 35 with EDS: The questions of identification of the patient, liability of the author, availability and performance of the data store are infrastructure-related, while the medical terminology used and the selection what is considered relevant for a long-term store among all data available are application-related.

Again, because of the legitimate, but not first priority, interests of those wishing to access data in a 40 non-emergency operational context it will be necessary to achieve and retain a strong consensus on the scope of the emergency data set (although, as for the summary, this should allow for extension both optionally in localised use contexts, and for future agreed growth).

The basis of the use cases, would seem, from the contexts presented in the Commission papers (see 5.3.1) to be for data to be carried on, or accessible by use of, an eHealth Card of some sort of token – 45 perhaps based on the eEuropean Health Insurance Card.

Annex D discusses use case requirements for EDS(s).

Before proposing a framework for working out a plan for internationally driven interoperability at European level as required by the Mandate we therefore propose awaiting the use case requirements of the epSOS project. Given the complexity we have outlined, to make concrete proposals at this time 50 would be entirely speculative.


Page 74

Anchor point: Applying the methodological approach outlined in sections 4 and 5.1 to the "emergency data set" and the "summary record" we find: 5 - A large number of Base Standards are likely to be applicable in whole or part. - Profiling has been engaged rather recently and needs to be extended into a multi-lingual environment. - Use cases for both the "emergency data set" and the "summary record" require further 10 consensus before specific work products can be proposed.


Page 75

6 Proposed workplan strategy

6.1 General strategy The temptation amongst any standards group is to keep developing and to keep publishing standards. The business models of the ESOs and the National Standards Organisations do not discourage this natural result of group dynamics. It would be possible to refresh the existing workplans of the ESOs, 5 and possibly some of other SDOs, on the basis of the various policy and research project documents already cited in this Report. This would certainly provide some alignment with high level policy expectations from an EU perspective, and some of the research reports could provide some slightly more targeted direction. However, in the context of addressing the spectrum of market need identified in sections 2 and 4 of this Report, the proposed workplan aligns with the broader scope of: 10

1. use case definition and prioritisation; 2. standards development; 3. profile development and maintenance; 4. profile quality assurance test plans and tools; and, 5. sharing of best practices in deploying eHealth projects. 15

Each one of these facets contributes one of the critical pieces of the interoperability puzzle. None can be ignored and they interlock in the higher-level business perspective that this Report attempts to address. It should appear clear from Figure 4.5 that an overall coordination and governance (at the top of the grey box) is needed to empower these five activities, monitor their progress and increase efficiency of the overall process as maturity and experiences develops. The challenges and 20 alternatives for such an overall coordination are discussed in section 6.2.1 below.

The following sections discuss the specific activities of each of the five processes above. The proposed workplan will therefore be shaped by:

- The high-level business objectives that should be addressed in 2009 and 2010. It is proposed to consider the current use cases that are under development by other European 25 Initiatives, leverage those and extend into new areas of use cases, based on the general trends followed by national and regional programs in Europe and some of the most pressing interoperability needs of hospitals. The selection of the use cases proposed in this Report should be considered provisional. It is intended to be reviewed as part of the formal prioritisation and approval which is of the 30 responsibility of the Use Case Definition and Prioritisation activity (see 4.5), and should fully account for the details of several national and local use cases that were not available to the writers of this Report.

- The specific work items induced by the use cases (as agreed above) in the other 4 activities. 35 Once a set of use case definitions has been finalised each needs to be decomposed into Technical use cases. Then, the need for a new Profile in each Technical use case is evaluated against existing Profiles. Eventual gaps may require some extensions to the Profiles or to Base Standards. Some additional Base Standards may be required. The final set of requirements may not be known until the prioritised use case is approved and analysed. 40

6.1.1 Resources The resources required to undertake the activities enumerated above need to be evaluated as separate exercise once the Report is agreed with the EC and ESOs, and before Phase 2 commences.

6.2 Overall coordination and governance strategy

6.2.1 General 45

It is a complex matter to organise the overall coordination management and rules of governance foreseen in 4.5 as necessary to establish, in order to manage the overall efficacy and improve the processes proposed in this Report. eHealth Interoperability is not a destination that can be set and


Page 76

defined in such a Report; it is a road that needs to be travelled in consistent way by many different types of stakeholders across many jurisdictions. Health, and a fortiori eHealth, is the responsibility of the European member States with limited direct European Commission authority (essentially guidance in support of mobility, and hence cross-border care). However, eHealth, the associated ICT technologies, and in particular interoperability, is part of an increasingly global market driven by the 5 high costs and risks of implementation and deployment – with impact in all parts of the European health system. Despite the challenges that have been, and will continue to be, the reality in which eHealth interoperability needs to be addressed, the solutions to the interoperability challenge are of common interest to most on-going and future eHealth projects – and citizens. From being almost a non-issue to most policy-makers at the start of the 21st century, difficulties encountered in many 10 projects have now raised interoperability to visibility as a major political stumbling block for which many voices are now calling for a European (and indeed international) coordinated effort.

The precedent for a coordinated response to the problem has now been set by the Large Scale epSOS project, in which twelve countries have voluntarily engaged to explore their ability to interconnect their diverse emerging national infrastructures. This cross-border project will unavoidably 15 bring the realisation that inconsistent interoperability approaches within the countries and regions will pose some challenges. Such cross-border cooperation should foster more consistency in the future. Experience in conducting a twelve member state project, together with over 30 industry partners (organised as a team under IHE-Europe), will develop a culture for collaborative approaches to interoperability – explicitly one of the objectives of the Member States and of the European 20 Commission acting as a facilitator. This will inevitably result in cross-fertilisation of ideas about national and regional architectural assumptions, and should, over time, enable shared a strategic vision for subsequent generations of eHealth provision.

We note that not all areas needing attention may be addressed by activities under this Mandate. For example: 25

- Areas needing adoption or short term action: by national e-Health programmes, and therefore by industry, and ideally internationally: maybe resulting in sufficiently robust outputs to provide input to activities under this Mandate;

- Areas needing wide-scale evaluations: results exist, but need refinement and real clinical use, to determine best practice; 30

- Areas needing investment: the business cases are not yet strong enough for industry, but products are needed: maybe sponsored open source;

- Areas needing further (focussed) research: e.g. for consideration in future EU Framework programmes.

6.2.2 European interoperability coordination committee – or not? 35

During the Public Comment phase of producing this Report much feedback has been provided on the best approach to the coordination of the various activities identified for the execution of this eHealth Standards Mandate. However there was not a clear consensus on a specific approach. Three types of approaches have been recommended:

- The first option is to not establish an overall coordination and governance entity, and simply to 40 rely on the European Commission in its directing of the Mandate for the next three years and assume that beyond the end of the Mandate the working structures put in coordinated motion may perpetuate themselves. Such an approach may be a challenge for the European Commission in assuming and staffing such a role.

- The second option is to use the framework of the Mandate to establish and experiment with such 45 a European-level coordination and governance entity. The scope of this coordination committee would be specifically focussed on the execution of the Mandate itself. If such a route is chosen, this eHealth Mandate Coordination Committee would need to establish a liaison with other related intitiatives such as the epSOS and CALLIOPE Projects.

- The third option is to place the Mandate under a broader multi-stakeholder eHealth 50 Coordination Committee that would not only provide oversight and strategic direction to the Mandate execution, but also to other related eHealth initiatives such as epSOS, CALLIOPE, etc..

Whatever the preferred option, a clear consensus emerged to have such a coordination committee as:


Page 77

- a lightweight structure,

- engaging a broad range of stakeholders and focus on the overall process efficacy,

- not engaged into operational decisions such as selecting use cases or standards (only oversee the five operational activities).

Such coordination is not a new challenge at the European level. In the field of regulated medical 5 devices, also of the primary responsibility of Member States (though in this case delivering the requirements of a Directive), a coordination body has been established, MEDDEVlxxxv. Although without any regulatory authority, MEDDEV plays a key role in ensuring a consistent approach to medical device regulation across each Member State because they realise that it is more efficient to negotiate guidance together at the European level and to transpose the resulting guidance, with 10 minimal changes, into the national regulations. Because it is clearly in the interest of all parties, Member States, Industry and of the Commission to maintain a cohesive European market for regulated medical devices the EC simply hosts this coordination, in which Member States voluntarily participate.

Device regulation and interoperability standardisation are different domains and we do not wish to 15 introduce confusion over regulatory questions here, but the precedent for such a European level coordination driven by the member states exists, and may be copied. The ICT Studyiii has already advocated this type of approach, particularly given the legal restrictions on the Commission's ability to drive direct national action in this area (pp77-78).

Other European examples exist, as in the case of interoperability of railway systems. Bi-lateral 20 agreements, which were the common practice until recently, are being transformed by establishing agreements which will eventually enable migration of the national railway systems towards a common set of standards.

Readers are again reminded of the innovative, and deliberately holistic, structures developed by ETSI and, more explicitly, by ITU; from which a number of useful features could be adopted to provide a 25 coherent approach to European interoperability coordination for eHealth. Readers are also reminded again of the ICT Study conclusions and recommendations in this area.

6.2.3 Mandated organisation It is proposed to decide between the three coordination options (described at the beginning of this section) at the start of Phase 2 of the Mandate. It may be that during the course of the Mandate the 30 type of coordination will evolve due to internal constraints or external changes. For convenience, and without making a judgement on the preferred mechanism, will use the expression "European eHealth Mandate Coordination Group" to describe this function for the remainder of the Report.

As part of the pre-launch of Phase 2 of the Mandate, a core management team will be tasked with establishing the necessary processes synchronising the various activities, setting the rights and 35 obligations of each main activity, and the conflict resolution processes. This will ensure that the minimum level of structure and resources are applied for the overall coordination before Phase 2 can begin on a more formal basis.

6.2.4 Work topics

6.2.4.1 Role 40

Irrespective of the choice among the three types of eHealth Standards Mandate coordination (by the Commission, specific to the Mandate, or with a broader eHealth scope) it is important that such a European-level coordination:

- be focussed on high-level management and governance and be kept as light-weight as possible;

- remains neutral in term of use case prioritisation, selection of standards or Profiles; 45

- has only an advisory status from a formal European legal point of view;

- can empower/accredit organisations to conduct the five core activities proposed in Sections 4.5.1 through 4.5.5; and foster collaboration between them;


Page 78

- encourages voluntary participation in the Mandate activities of all stakeholders throughout the European Member States (health authorities, competence centres, health professionals, care delivery organisations, industry, patient organisations, etc.);

- involves all health relevant DGs, especially DG Enterprise, DG Health and Consumers, DG Information Society, etc.; 5

- be an effective steward and 'spokesperson' for all activities of the Phase 2 of the Mandate;

- ensures continuity and timely progress on the workplans of the 5 activities

- ensures that the organisations accredited or entrusted with the five activities execute their objectives effectively and according to open and balanced high-level principles.

6.2.4.2 Responsibility 10

In particular, European-level eHealth Standards Mandate coordination should:

- ensure adequate visibility and foster engagement of stakeholders throughout Europe, which may require a number of focussed communication activities relevant to the overall Mandate and its activities.

- assemble from the identified five entities multi-year roadmaps, especially to provide the long 15 lead-time tasks such as Base Standards development with sufficient planning time;

- conduct regular reviews of progress achieved;

- oversee the overall process, and design/authorise changes as needed.

6.2.4.3 Requirements The European Interoperability Coordination Committee should establish the business plan and 20 budgets necessary to execute the various activities:

1. Business use case definition and prioritisation; 2. Base Standards development and maintenance; 3. Profile development and maintenance; 4. Profile quality assurance; 25 5. Best practice sharing.

6.2.4.4 Risk management Following the discussion in 4.5.6.4 it is suggested that the Phase 2 management team should consider including the two tasks of effective risk awareness and risk-aware process derivation as early as possible in the process of addressing Phase 2 of the Mandate. 30

These tasks will not hinder the overall process would provide a firm foundation for improving further the safety and security of eHealth interoperability standards and related products. It may also provide the basis for further risk management work should this be deemed to be beneficial to the ongoing development of procedures and standards

6.2.5 Resources 35

The resources needed to conduct these overall coordination activities (secretariat, overall execution management, communication initiatives) need to be evaluated.

6.3 Use cases strategy

6.3.1 General The process outlined in 0 has to receive proposed Business use cases for European endorsement 40 from the Member States, perform a synthesis among like Use Cases, and develop consolidated European Business use cases. This requires a respected and responsive entity to ensure that the Mandate goals are met.


Page 79

6.3.2 Mandated organisation For Phase 2 of the eHealth Standards Mandate, it is proposed to establish a small project team to analyse and consolidate submitted use cases. This work, especially the prioritisation could be performed either under joint oversight of i2010 (Member States) and Stakeholder Group (users and industry) or through an advisory board where a panel of experts (including designated rotating 5 representatives from i2010, the EC, user stakeholder and industry stakeholder groups) formulate high level use case recommendations on the selection, consolidation and prioritisation. It is critical that use cases be not “invented” by this small use case project team, but result from the submission of vetted use cases from a mix of projects in the Member States. Once the differences and commonalities have been identified, a common core should be proposed and re-issued for wide review especially from an 10 array of users across Europe.

It is propose to proceed in a step-wise manner, focussing first on more well understood use cases such as:

1. Select the first two Use Cases that have the highest support Europe-wide and that are easier to define; One may for example rely on deriving without duplicating from on-going European 15 activities such as epSOS. This first two use cases would be selected no later than 6 months into the Mandate Phase 2.

2. Then proceed with the definition of two additional use cases to be approved three months after the first two use cases.

3. Then prioritise a set of three Use Cases to be approved three months later. 20

Such a quarterly progressive ramp-up is necessary to engage the key stakeholders across Europe across a sufficiently wide variety of use cases and refine the work processes while building on the early experience from the epSOS project.

It is recommended that the Roadmap and Standards activities of CALLIOPE be refocused away from a primary concern with technical standards to providing the necessary engagement and visibility for 25 these use case definitions and prioritisations. This should avoid overlapping activities and prefigure a future use case management entity for Europe.

6.3.3 Work topics

6.3.3.1 Rationale for proposals So that Phase 2 of the eHealth Standards Mandate does not have to start with a "blank sheet of 30 paper", but has a basis for discussion, the following workplan is proposed, as starter, to deliver a mix of specifications to address two Intra-Border Use Cases, two Use Cases spanning both hospital/clinic and regional environments and to introduce three additional Use Cases, one of which would support personal/home-based health and wellness. By delivering the European-recognised Profiles that serve three major Stakeholders, there should then be an obvious benefit and reason to engage in the 35 eHealth Interoperability Standards Mandate. These use cases examples would be used as input into the initial work of the use case specification and prioritisation activities. Wide feedback from Member States would be sought to consolidate their use cases into a European use case.

For Phase 2 of the Mandate, the following work plan is proposed to deliver the Profiles that serve three major Stakeholders that should see a benefit and reason to engage in the Mandate work: 40

- Regional and National projects;

- Hospitals / Clinics / Diagnostic facilities;

- Citizens at home and on the move.

In each one of these categories, three waves are proposed, with two Intra-Border Regional/National Use Cases, two Connected Regional/Hospital use cases and one Home health use case 45

One important task will be to establish a set of evaluation criteria along with each Use Case in order to establish its value, identify the major barriers to its deployment and acceptance, and some of the mitigation strategies experienced by some of the more advanced projects that have started implementation of a similar Use Case. This initial value assessment would need to be further refined by the Best Practice Forum as its actual use spreads across Europe (see Section 6.7) 50


Page 80

6.3.3.2 Regional/national Patient Summary and Prescription use cases Derive from the two Cross-Border epSOS Use Cases (Access to Prescriptions and to Summaries) the corresponding generic intra-country European consolidated use cases. This is proposed as a pair of candidate initial Use Case work items that could benefit from the epSOS Use Case definition work, and the project participants (12 Countries and Industry Team) as a starting point. As the epSOS Use Cases 5 focus on the information exchange performed in a cross-border environment (the primary focus of the epSOS project), it is proposed for the Mandate to shift the focus (and demonstrate early relevance) by defining the corresponding Use Case with the same information and basic workflows, but operating within a national or regional setting. It is expected that this effort would take 3 months to produce a draft for Public Review, with finalised 10 Use Cases submitted for European Interoperability Coordination Committee approval for release less than six months after the launch of the Phase 2 Mandate.

6.3.3.3 Two high-priority additional use cases Three months after starting the work on the first two Use Cases, it is suggested to start with the definition of two additional high-priority Use Cases. It is proposed that: 15

- The first use case focuses on an intra-hospital workflow (e.g. ordering and results distribution for laboratory or radiology);

- The second use case focussed on the same information content in a regional or national project.

Laboratory information is more used by health professionals than is radiology information; however, 20 the complexity of laboratory coded information (orders and results) compared to the more standardised imaging environment (widespread use of DICOM in Europe), may align with the findings of several projects that imaging information sharing is more mature in term of standardisation. It is proposed to select the same domain for both Use Cases (intra enterprise and cross-enterprise) to ensure consistency between these two Use Cases – and demonstrate early local relevance. 25

Cross-enterprise imaging information sharing and intra-enterprise radiology integration appears as the more reasonable goal to release these use cases for Public Review in 2009, with European approval shortly after. The corresponding pair of laboratory centric use cases should be planned for the wave starting three months later (see 6.3.3.4).

6.3.3.4 Three additional use cases 30

Introduce three additional Use Cases late in 2009 or early 2010, depending on the actual launch date for the Phase 2. It is proposed that these three use cases be:

- The Laboratory Information Cross-Enterprise Sharing Use Case (see discussion in 6.3.3.);

- The Laboratory Enterprise Workflow Use Case (see discussion in 6.3.3.);

- A Ubiquitous Care Use Case relating to care outside conventional care facilities, involving the 35 interoperability necessary from home monitoring devices.

6.3.3.5 Proposed use cases summarised This staggered-start approach allows ramp-up for the new organisation of activities as proposed in this Report in progressive manner – and allows early demonstration of local relevance. This progressive approach will be important to facilitate the orderly engagement of a significant number (see 6.2.2) of 40 stakeholders throughout Europe for Phase 2 of the Mandate. It will also result in a waterfall effect to engage to the other four supporting activities discussed below. It is also recommended to distribute the Use Cases across at least three different domains: care outside conventional care facilities, conventional care facilities and regional / national care coordination.

6.4 Base standards development and maintenance strategy 45

6.4.1 General The process outlined in 4.5.2 has to ensure the continued and increased efficiency in Base Standard development, especially in relationship with the harmonisation of Base Standards.


Page 81

This Mandate workplan relies on the overall methodology introduced in Chapter 4 to provide a more efficient Base Standard development environment by:

- Putting in place more visible business level guidance (a visible set of objectives and a yearly progress report card).

- Providing the SDOs with increased leadership and organisational support to enable quality time, 5 rather than residual goodwill, to be devoted to the harmonisation activities at the international and European level;

- Establishing a representative and dedicated activity under the auspices of the ICTSB;

- Noting the recognition in the study "ICT standards in the health sector: current situation and prospects" of existing CEN TC251 engagement, opening the international coordination by 10 HL7, CEN and ISO to other SDOs (such as IHTSDO, DICOM, IEEE, LOINC) key to ensure the prime goals of interoperability (see 5.3.3);

6.4.2 Mandated organisation For Phase 2 of the eHealth Standards Mandate, it is proposed to rely on the existing harmonisation entities (ICTSB and the CENTC251 / HL7 / ISOTC215 / IHTSDO and CDISC "JIC" coordination) and 15 improve their efficiency in assuming leadership and coordination.

6.4.3 Work topics

6.4.3.1 Priorities The Base Standards work should proceed with the following priorities:

1. In order to enable use case priorities to be met, fill identified gaps that need to be resolved in the 20 standards work programme at the European and/or International level:

a. development of integrated safety / security and privacy strategy — standards for safety / security and privacy in eHealth should continue to be developed, in concert with those for other e-Processes, with a clear plan for accommodating the needs of existing related sector-specific arrangements; 25

b. development of integrated infrastructure for care outside conventional care facilities — in accordance with the motivating rationale of the Mandate, enable timely use of key communications infrastructure components (such as body and personal area networks) needed for integrated ubiquitous care (monitoring, well-being, assisted living). The detail of this will need to be determined by careful reference to existing EN/ISO 30 standards as used by the Continua Alliance in relation to the proposals for the ETSI STF355 Technical Reportxlvi.

2. Facilitate semantic interoperability because, although the longer-term goal should be to enable harmonisation among the various national terminologies and the adoption of consistent (at least) pan-European terminologies, some shorter-term steps are needed: 35

a. consistent terminological representation in support of use cases — recognising that heterogeneity of classifications and terminologies will remain for several years in European healthcare, expand effort in Europe to achieve terminological interoperability in the context of the identified use cases;

b. support for safe semantic interoperability — continued urgent effort is needed to ensure 40 that the internal relationships in, for example, CEN 13606 and HL7 RIM based, communication structures are unambiguously linked to the appropriate archetypes, templates, terms, codes, identifiers and/or value sets;

c. establish maintenance arrangements — Provide sufficient resourced impetus to establish real-time, "gold-standard" resources to support semantic interoperability in support of 45 existing and emerging semantic requirements in eHealth.

3. Resolve the inconsistencies, or at least facilitate co-existence, between standards based on fundamentally different principles (e.g. Electronic Records exchange formats using either CEN 13606 or HL7 RIM based documents – see NHS CfH, Results of Investigating the Transformability Between HL7 V3, openEHR and EN/ISO 13606 lxxxvi); 50

4. Increasingly coordinated contribution from Europe to international standardisation efforts to meet its needs in internationally accepted standards (e.g. for acute and home care devices with IEEE, terminologies with IHTSDO, etc.).


Page 82

The next three sections deal with the proposed allocation of the lead responsibility for these priority topics in the context of the ESOs – but it should be remembered that the Mandate pre-supposes full engagement with all relevant SDOs.

6.4.3.2 CEN TC251 (with HL7 and ISO TC215) CEN TC251 might be expected to take up the lead in ESO co-operation on Priorities: 5

Fill identified gaps (1) — with strong engagement of at least healthcare professional organisations, health insurance organisations and MS stakeholders;

Development of integrated safety / security and privacy strategy (1a) — with strong engagement of at least other ESOs (at TC level), SDOs healthcare professional organisations, health insurance organisations and MS stakeholders; 10

Facilitate semantic interoperability (2) — with strong engagement of at least IHTSDO, WHO and LOINC – together with MS activities;

Consistent terminological representation in support of use cases (2a) — with strong engagement of at least healthcare professional organisations, IHTSDO, WHO and LOINC, HL European Affiliates, OpenEHR and MS stakeholders; 15

Support for safe semantic interoperability (2b) — with strong engagement of at least representative healthcare professional practitioners, HL European Affiliates, OpenEHR and MS stakeholders;

Establish maintenance arrangements (2c) — with strong engagement of at least other ESOs (at TC level), SDOs, IHTSDO, WHO, LOINC and healthcare professional organisations;

Resolve inconsistencies (3) — with strong engagement of at least, for the example cited, HL7 20 European Affiliates and OpenEHR – together with MS stakeholders;

Contribution from Europe to international standardisation (4) — with strong engagement of representative healthcare professional practitioners, HL European Affiliates, OpenEHR and MS stakeholders.

6.4.3.3 ETSI eHealth (and ITU-T / IEC) 25

ETSI eHealth might be expected to take up the in ESO co-operation on Priority:

Development of integrated infrastructure for care outside conventional care facilities (1b) — with the emergence of new use cases and new telecoms (especially radio frequency) technologies we anticipate detailed specifications to be required in support of "wellness" and home, ambulant and acute care. This will need engagement of representative healthcare professional practitioners, CEN 30 ISO/IEEE device communication (informatics), clinical and telecoms engineering, device industry and MS medical device regulatory expertise.

6.4.3.4 CENELEC (and IEC) TC62 CENELEC might be expected to take up the in ESO co-operation on Priority:

Increasingly coordinated contribution from Europe to international standardisation (4) — with the 35 emergence of new use cases in home, ambulant and acute care, appropriate technology- and modality-related communications aspects of medical devices will need to be accommodated into CENELEC/IEC 60601 and other relevant CEN/ISO and CENELEC/IEC device safety standards. This will need engagement of representative healthcare professional practitioners, CEN ISO/IEEE device communications experts, the device industries, clinical and telecoms engineers, and MS medical 40 device regulators.

6.5 Profile development and maintenance strategy

6.5.1 General The Profile development and maintenance strategy process (see 4.5.3) is responsible for ensuring that the Business use case prioritised and documented by the process described in 0 and 6.3 is 45 broken down into Technical use cases to be addressed with ready to implement specifications.


Page 83

Q2 2009 will need to be used to initiate widespread European education on the concept of Use Cases, profiling, its relationship to each of Base Standards development, software development architectures, and the use of test plans and tools. It is proposed that this education programme proceeds as soon as the Phase 2 may be authorised by the European Commission (likely Q2 2009) ensuring the recruitment and engagement of a wide range of technical participants through the European countries 5 and in 2010 with the education associated with the release of the first set of European-recognised Profiles.

6.5.2 Mandated organisation For Phase 2 of the eHealth Standards Mandate, it is proposed to accredit an entity, which is independent of any of the Committees developing Base Standards in order to foster harmonisation 10 and ensure that the best standards are selected based on the prioritised Business use cases. The EC, in consultation with the European SDOs and groups such as IHE-Europe, and Continua (assuming its capability is proven in time) and possibly others, should come to a decision on how to organise and operate such an activity. The opportunity, and challenge, is to avoid reinventing, and to learn from existing experience – in this regard, although the role of CENELEC may not be large it is 15 not difficult to envisage imminent impact on its work in the medical devices sector. This mandated organisation should also ensure that the European-recognised Profiles are as much as possible consistent with internationally approved Profiles (e.g. ISO, IHE International, Continua).

6.5.3 Work topics For Phase 2 of the eHealth Standards Mandate, the workplan is proposed to deliver the profiling 20 following the specifications of the Use Cases workplan. The Profile Development activity should formally start late Q3 2009 on the basis of the first two use cases (proposed in 6.3.3). This activity should review available existing Profiles, identify gaps or issues and propose for European recognition by Q1, 2010 a first set of Profiles and, if needed, a programme of Profile extensions or new Profiles development. This activity should proceed in parallel 25 with the next two (second wave) Use Cases starting prioritisation in Q4 2009, and where Profile selection should be approved by Q1 2010.

The work on the third wave of Use Cases should proceed in 2010. Following waves of Use Cases should continue to feed the Profiling activities at a reasonable pace in 2011 and beyond to allow the development of the supporting quality assurance tools and the progressive adoption by eHealth 30 projects throughout Europe.

A supporting activity is needed to ensure easy access to the recognised Profiles that have been identified in support of the use cases. This includes a proactive information and education process about these Profiles towards the many eHealth projects around Europe that should take advantage of these Profiles in their Interoperability Specification. This activity should also propose a template for 35 Interoperability Specification so that these project specific documents can be easily reviewed and analysed by implementers.

6.6 Profile implementation quality assurance strategy

6.6.1 General The process outlined in 4.5 has to ensure, for Profiles, the development of conformance test plans 40 and test tools under a coordinated process among the various contributors and users.

6.6.2 Mandated organisation For Phase 2 of the eHealth Standards Mandate, it is proposed to accredit IHE-Europe in partnership with ETSI, Continua (assuming its capability is proven in time), and possibly others. The IHE Europe Connectathon process already engages a significant numbers of vendors and users from most 45 European countries. IHE also offers access to an operational, and international, test tools development process. Once reviewed, this may be acceptable either as it stands or as the basis for improvement. Together with the international linkage, it is equally important to link this organisation with the existing national testing efforts in some of the European countries.


Page 84

6.6.3 Work topics This activity should be initiated by mid 2009 and be focussed on engaging European contributors and ensuring that the corresponding test plans and tools associated with the European-recognised-recognised Profiles published in Q4 2009 and Q1 2010 are openly available by 2010. Some coordinated tools development for the common Profiles should be done in collaboration with the 5 epSOS project partners in charge of test tools for the epSOS implementation testing.

It is proposed to conduct a first campaign of quality assurance with product implementation in Q3 2010 on the basis of the European-recognised Profiles published in Q4 2009and Q1 2010.

In 2010, the next set of European-recognised Profiles should be addressed in the portfolio of test tools and plans recognised by the European Interoperability Coordination Committee. 10

To conduct the quality assurance of implementations of these Profiles, a quality framework for interoperability needs to be established, with test tools and test plans related to each Profile developed and maintained. The corresponding resources need to be evaluated.

The development of such a portfolio of test tools and test plans covering the portfolio of recognised Profiles is a large task. It is proposed that the Phase 2 Mandate provides sufficient resources to 15 ensure that a core development team is in place to deliver a core test platform, a development process, and key specialised test modules. It will have to establish a number of collaborative agreements with interested parties (national competence centres, hospitals, industry, etc.) ready to bring their resources to jointly meet the Mandate objectives in terms of quality assurance. Selecting an open collaborative such as those already established by IHE International (for eHealth), ETSI (for 20 the telecom industry), and Open Health Tools (OHT) ensures that open access to the tools is provided along with enough oversight by a diverse set of stakeholders to ensure a sufficient quality level.

6.7 Best Practice Forum strategy

6.7.1 General The best practice sharing activities outlined in 4.5.5 have to enable sharing of experiences and 25 publication of best-practice guides that offer guidance in conducting the deployment activities of eHealth projects. It should also provide a means to jointly evaluate the effectiveness of the European-recognised Profiles and associated Test Tools.

6.7.2 Mandated organisation For Phase 2 of the eHealth Standards Mandate, It is proposed to rely on EHTEL and the support of 30 the CALLIOPE project to conduct these activities for 2010 and 2011. Beyond 2011, a permanent accredited European entity needs to be designated to conduct these activities.

Establishing the Best Practice Forum should become one of the primary activities of the CALLIOPE network. This may require a re-orienting some of its currently planned activities to avoid duplicative work with the eHealth Standards Mandate (e.g. Common EU Interoperability Road Map and 35 Standardisation Status).

6.7.3 Work topics It is proposed that in 2010, once the first set of use cases, corresponding Profiles and test tools are released that a best practice forum focus on specific topics of direct interest to the European projects that are early adopters of the 2009 European-recognised Profiles from the eHealth Standards 40 Mandate. The end of 2010 should see the full-scale launch of the Best Practice Forum.

6.8 Workplan summarised The following Figure (6.1) shows a graphic summary of the proposed workplan (see 6.3.3) with allocation of deliverables to activity streams managed by accredited entities.

45


Page 85

Fi

gure

6.1

: Pro

pose

d Ph

ase

2 W

orkp

lan

for e

Hea

lth S

tand

ards

Man

date

200

9-20

10

Anchor points:

A " European eHealth Mandate Coordination Group " should set, and monitor, the high-level business objectives. 5

Establish processes to: 1. Business use case definition and prioritisation; 2. Base Standards development; 3. Profile development and maintenance; 10 4. Profile quality assurance test plans and tools; and, 5. Best practice sharing. Explicitly mandate qualified organisational entities to provide leadership for each of these activities under Phase 2 of the eHealth Standards Mandate. 15 Agree, and progress using these processes, specific work items induced by the Use Case prioritisation.


Page 86


Page 87

7 Conclusions

7.1 General There has been wide, and strong, engagement in the work to " Collaborate on the preparation of the work programme" and to produce this " overview report analysing existing work and requirements and contain a list of proposed work items for possible standards action". 5

This Chapter brings together the lessons from the preceding chapters, and provides the basis for the Report's proposals presented in the next, and final, chapter. The following main section numbers relate to the corresponding preceding chapters.

7.2 Background – conclusions

7.2.1 Market influences 10

Noting that the main needs of eHealth users remain stable despite fashions in technology and policy, this Report proposes concrete actions not only to support the policy goals as proposed by the Commission and agreed by health ministers of the member states, but also to serve with standards-based interoperability the intra-country and indeed intra-organisational needs in order to bring tangible short-term benefit to the full spectrum of stakeholders. 15

7.2.2 Definitions Because basic terms used in eHealth are not used with shared understanding adequate to achieve useful results, the Report is not able to deliver some of the specific recommendations requested. However, it is noted that the temptation to develop new (better) 'definitions' should be resisted and that means to reach shared understanding of existing terms would be invaluable (we applaud the 20 "Glossary" initiative of the JIC in this regard).

For the purposes of this Report we understand eHealth to be the cost-effective and secure use of information and communications technologies in support of health and health-related fields (including health-care services, health surveillance, health literature, and health education, knowledge and research); and interoperability to be the ability of information and communication technology (ICT) 25 systems and of the business processes they support to exchange data and to enable the sharing of information and knowledge.

7.3 Existing standards activity – conclusions

7.3.1 eHealth market globalisation As the eHealth market globalises, so standards to address safe communication must converge to 30 enable the benefits that can be delivered by interoperability.

7.3.2 Working arrangements of ESOs and SDOs The working arrangements of ETSI and CEN TC251 already acknowledge the need to address the needs of standardisation in support of eHealth. In so far as the HTTF Reportxlvii represents the plans of CENELEC TC62 then that group also acknowledge the need to address the eHealth topic. 35

This Report goes further and provides a basis for "ESOs to establish a collaborative mechanism to elaborate this work programme" in the context of " close co-operation with international standards bodies, industry, R&D projects and other stakeholders in the process of harmonising European and international standards". Such collaboration should enable their specialist strengths, and finite resources, to be better focussed to address the considerable demands. 40


Page 88

7.3.3 Rigorous processes needed Some standards development groups issue specifications and standards without any evidence that they have actually been tested in any real working systems.

Standards development needs to ensure that there is a defined need for the standard, evidence through testing of the standard being able to deliver the benefits and assurance of evidence that the 5 standard is implementable, interoperable and safe and is supported by an ongoing maintenance and update process.

More rigorous development processes are needed to deliver specifications, including standards, suited to market needs.

7.3.4 eHealth standards and other e-Processes 10

As the scope of e-Processes extends to absorb 'conventional' technologies a coherent EC approach to safety / security responses to risk management will be necessary.

eHealth standards, especially for safety / security and privacy, should be developed in concert with those for other e-Processes, with a clear plan for accommodating the requirements of existing sector-specific arrangements. 15

7.4 Standards adoption and lifecycle – conclusions

7.4.1 Start specification with requirements Start specification with the identification of a use case or set of requirements — a “use case” based approach. From this basis supporting interoperability standards are selected and combined with the consequent reduction of options. It is then proposed to proceed with implementation and 20 conformance testing/certification which leverages feedback from real-world projects to provide the necessary balance between generality and focus.

7.4.2 Recognise different classes of 'standard' Distinguish, and recognise, three classes of standardisation products (specification) that build upon each other to enable interoperability in eHealth: 25

- Base Standards;

- Profiles (recognised at the European level); and

- Interoperability Specifications (recognised at a local, regional or national project level).

Consider an approach for organising the process for adoption of eHealth Interoperability Standards around these three classes of deliverables. 30

7.4.3 Reuse is critical to quality improvement The reuse across eHealth projects of Profiles (recognised at the European level) is critical to improving the quality and consistency of Interoperability Specifications used in regional or national eHealth projects.

Quality control management in the Profile Specifications is, therefore, a critical success factor. 35

7.4.4 Quality assurance test plans, processes and tools Quality Assurance for Profile implementations requires the development and maintenance of test plans, processes and tools, which should be easy for implementers across eHealth projects in Europe to use, and reuse.

7.4.5 Quality assurance labelling 40

Quality Assurance labelling may be performed at the level of Profile compliance, but also at the level of project specific Interoperability Specifications.


Page 89

The development and maintenance of test plans, processes and tools at the level of Profile conformance, will be needed irrespective of the type of labelling.

With experiences by IHE with its European Connectathon and ETSI with its Plugtest, some form of cross-testing and labelling seems to be a good starting point. When their testing and logo systems have been proven, Continua and others may also have a role. . 5

7.4.6 Risk handling Consider explicitly recognising effective risk awareness and risk based process derivation as an integral part of standards development and adoption.

R&D output relating to eHealth standardisation should first progress along the "Workshop Agreement" route before becoming subject to wider validation and being considered for formalisation into Base 10 Standards.

Ensure synergy with related European Projects, in particular epSOS and CALLIOPE.

7.5 Inventory of requirements – conclusions

7.5.1 Requirements analysis Requirements analysis necessitates engagement of political, organisational, managerial, and 15 healthcare professional practitioners (not titular representatives) to achieve mutual understanding of the purpose and scope any requirement, and then to agree the information required to support it.

Information and workflow requirements are a critical foundation to for interoperable products. In a complex ICT market interoperable products need standards.

Requirements need to account for the three perspectives of: population health, care provision and 20 citizens' needs.

7.5.2 Consistent policy priorities Consistent presentation and prioritisation of the policy priorities is vital in ensuring that these messages are taken seriously by those they are intended to influence. Moreover, it is not possible to maintain stakeholder input to such a standardisation mandate activity, and thus 'standards' production, 25 if priorities are not consistent.

Varying policy messages send the message that none of them actually matter.

Without consensus amongst the affected parties in Member States the policy messages achieve little impact upon local implementation priorities.

7.5.3 Patient identification 30

Applying the methodological approach outlined in Sections 4 and 5.1 to the patient identification use case we find:

- A choice of Base Standards exist to address front-office interoperability (between the identity management systems and the health care IT systems used in care delivery);

- Profiling has already been done. 35

To ensure that all healthcare systems support the access to cross-referencing and patient demographics queries in an interoperable manner Europe needs to recognise just one such Profile per use case.

7.5.4 Professional identification Applying the methodological approach outlined in Sections 4 and 5.1 to the professional identification 40 use case we find:

- Base Standards exist to serve some aspects;

- Profiling has not been done.


Page 90

To ensure that all healthcare systems support pan-European requirements await the use case requirements of the epSOS and HPro Card projects (synergy with NETC@RDS is welcomed) before making detailed workplan suggestions for professional identification.

7.5.5 Semantic interoperability Semantic interoperability, especially at the clinical information level, is critical to achieving full 5 exchange, understanding and appropriate consequent action among linguistically and culturally disparate clinicians and other parties.

For clinical semantics the following are required:

- Support for multilingual representations: global registries of standardised information models and related metadata 10

- Common standards to allow data exchange on predefined key variables & compilation of content

- Support for multilingual clinical constructs for context;

- Mechanism for ensuring clinical consensus;

- Support for collaborative means to develop, test, maintain and disseminate interoperable, consensus-approved, multilingual, clinical content in a timely manner and at and at 15 appropriate cost to users.

7.5.6 The "emergency data set" and the "summary record" Applying the methodological approach outlined in Sections 4 and 5.1 to the "emergency data set" and the "summary record" we find:

- A large choice of Base Standards likely to be applicable in whole or part; 20

- Profiling has been engaged rather recently and needs to be extended into a multi-lingual environment.

Use cases for both the "emergency data set" and the "summary record" therefore require further consensus before specific work products can be proposed

7.6 Workplan strategy – conclusions 25

7.6.1 Structuring activity A pilot "European eHealth Mandate Coordination Group" should set, and monitor, the high-level business objectives (see 6.2.2 for important detail relating to this proposal) during Phase 2 of Mandate. Structure the activities around five entities to execute the core activities of the eHealth Standards 30 Mandate:

1. Business use case definition and prioritisation 2. Base Standards development and maintenance 3. Profile development and maintenance 4. Profile quality assurance 35 5. Best practice sharing

Explicitly mandate these organisational entities to provide leadership for each of these activities under Phase 2 of the eHealth Standards Mandate.

7.6.2 Organising activity Organise these activities so that they become effective in 2009 and are sustainable after the end of 40 Phase 2 the eHealth Standards Mandate.


Page 91

7.7 EU Study on the specific policy needs for ICT standardization

Although central to this Mandate Report we want to emphasise the importance of the Study on the specific policy needs for ICT standardization to eHealth by bringing their Recommendations to our Conclusion section. 5

Ten major Recommendations were made in this Study, and most are as applicable to the eHealth area as to ICT in general. However, the first two recommendations are not immediately relevant.

Recommendation 3

The European Commission should foster a high level strategy dialogue between Member States, technology providers, technology users, public interest organisations, SDOs and specification 10 providers. Dialogue should focus on the effective implementation of ICT standards, identify policy priorities for standardization, advise on international relations, and potential co-operation, with a view to making effective use of all available resources and providing policy makers with the required standards. The organisational implementation of this dialogue should allow an institutional dialogue between Member States and the European Commission on matters within their specific 15 responsibilities.

Recommendation 4

The high level strategy dialogue should be complemented by a platform permitting an organisational dialogue between SDOs and specification providers, technology users and providers, and public interest organisations. The platform should decide on practical matters and co-operation issues in 20 view of implementing the standardization priorities and possible accompanying measures.

Recommendation 5

To respond rapidly to standardization needs set by i2010 and the innovation policy, the new ICT standardization policy of the European Commission should build upon the synergies provided by a better integration of European Standardization Organisations and relevant consortia and fora activities 25 in the domain. A further integration of fora and consortia by including deliverables within the EU standards catalogue or by direct mandating of fora and consortia, should, however, take into account the specific requirements set by Public Authorities for standards to be used in association with EU legal and policy acts. A differentiation of criteria for this integration and the use of the deliverables should be carried out in accordance with the differentiation suggested in Recommendation 1. 30

Recommendation 8

In order to promote the implementation of European standards and in order to increase the interoperability of European applications and services, the European Commission, the Member States and all public administrations should refer to European standards in the procurement of ICT products, services and applications. The reference to European standards needs to be re-enforced 35 in general through European public procurement legislation.

Whilst we can support the principle of Recommendation 8, we can only do so where standards:

- reflect the needs of European activity in the context of a global eHealth market;

- reflect demonstrably balanced stakeholder consensus across Europe; and/or

- are the only means to satisfy the specific requirements of an EU Directive. 40

The ninth Recommendation is in response to the EC assumption that R&D output is amenable to standardisation in support of innovation – a practice that has demonstrably delayed production and adoption of relevant eHealth standards in the EU, and Internationally, xlix – and which we therefore chose not to endorse.

Recommendation 10 45

The European Commission should include, in the new ICT standardization policy, tools that promote the use and implementation of European7 standards. It is recommended that the following measures could be considered: […]

7 In the context of this Mandate, the use of the work “European” is understood to refer to international standards, as much

as possible recognised and deployed in Europe, not to promote European specific standards.


Page 92

- specific measures that allow increasing trust and stability prior to the implementation of standards such as: conformance testing, certification aspects, interoperability testing, mandatory implementation prior to the final acceptance of the standards (either simple coding implementation or reference implementation), etc.


Page 93

8 Proposals

8.1 General proposals In addition to adoption of the Recommendations from the EU Study on the specific policy needs for ICT standardization (see 7.7), and in the context of addressing the spectrum of sector needs identified in Sections 4 and 4 of this Report, the following is therefore proposed as the recommended course of 5 action for Phase 2 of work to address the Mandate:

A "European eHealth Mandate Coordination Group" should set, and monitor, the high-level business objectives. Structure five activities around associated entities to execute the core outcomes of the eHealth Standards Mandate: 10

- Business use case definition and prioritisation;

- Base Standards development and maintenance;

- Profile development and maintenance;

- Profile quality assurance, test plans and tools;

- Best practice sharing. 15

Organise these activities so that they become effective in 2009, and sustainable after the end of Phase 2 the eHealth Standards Mandate.

8.2 Business use case definition and prioritisation For Phase 2 of the eHealth Standards Mandate, it is proposed to establish a small project team under the joint oversight of i2010 (Member States) and Stakeholder Group (users and industry), in the 20 context of and in cooperation with other similar initiatives, to analyse, consolidate and prioritise use cases for Profile Specifications in Phase 2 and thereafter.

The following specific proposals are therefore made as the basis for discussion, possible change, and agreement (see 6.3.3.1): in Phase 2 (2009) 4 use cases for Profile Specifications focus, an additional 3 for Profile Specification in 2010 and a rolling plan thereafter. 25

8.2.1 Generic intra-country (2009) use cases Derive from the two epSOS Cross-Border Use Cases, for access to (1) Prescriptions and (2) Summaries, the corresponding generic intra-country European high-level business objectives that should be addressed in 2009 and 2010.

- Patient summaries for regional / national information sharing; 30

- Prescriptions for regional / national information sharing.

8.2.2 Two high-priority additional (2009/2010) use cases - Request and results distribution for radiology enterprise workflow;

- Request and results distribution for radiology in cross-enterprise sharing.

8.2.3 Three follow-on (2010) use cases 35

- Request and results distribution for laboratory enterprise workflow;

- Request and results distribution for laboratory information cross-enterprise sharing;

- For ubiquitous care outside conventional care facilities, involving the interoperability necessary from mobile and/or home-based monitoring devices.


Page 94

8.3 Base Standards development For Phase 2 of the eHealth Standards Mandate, it is proposed to rely on the existing harmonisation entities, ICTSB and JIC, and improve their efficiency by:

1. Providing them with increased leadership and organisational support to enable quality time rather than residual goodwill to be devoted to this activity; 5

2. Establishing a representative and dedicated activity under the auspices of the ICTSB; 3. Opening the JIC to other SDOs (such as IHTSDO, DICOM, IEEE, LOINC) key to ensure the

prime goals of interoperability (see 5.3.3); 4. Putting in place more visible business level guidance (a visible set of objectives and a yearly

progress report card). 10

The Base Standards work should proceed with the following priorities (see 6.4):

8.3.1 Fill gaps in provision In order to enable use case priorities to be met and fill identified gaps in the Base Standards programme that need to be resolved at the European and/or International level.

8.3.1.1 Enable development of integrated safety / security and privacy strategy 15

Standards for safety / security and privacy in eHealth should continue to be developed, in concert with those for other e-Processes, with a clear plan for accommodating the needs of existing related sector-specific arrangements.

8.3.1.2 Enable development of integrated infrastructure for care outside conventional care facilities 20

In accordance with the motivating Rationale of the Mandate, enable timely use of key communications infrastructure components (such as body and personal area networks) needed for integrated ubiquitous care (monitoring, well-being, assisted living). The detail of this will need to be determined by careful reference to existing EN/ISO Base Standards as used by the Continua Alliance in relation to the proposals for the ETSI STF355 Technical Reportxlvi. 25

8.3.2 Facilitate semantic interoperability The longer-term goal should be to enable harmonisation among the various national terminologies and the adoption of consistent (at least) pan-European terminologies – which necessitates commitment to appropriate maintenance and access arrangements.

8.3.2.1 Enable consistent terminological representation in support of use 30 cases

Recognising that heterogeneity of classifications and terminologies will remain for several years in European healthcare, expand effort in Europe to achieve terminological interoperability in the context of the identified use cases.

8.3.2.2 Enable support for safe semantic interoperability 35

Continued urgent effort is needed to ensure that the internal relationships in, for example, CEN 13606 and HL7 RIM based, communication structures are unambiguously linked to the appropriate archetypes, templates, terms, codes, identifiers and/or value sets.

8.3.2.3 Facilitate maintenance mechanisms Provide sufficient resourced impetus to establish real-time, "gold-standard" resources to support 40 semantic interoperability in support of existing and emerging semantic requirements in eHealth.


Page 95

8.3.3 Resolve inconsistencies Resolve the inconsistencies, or at least facilitate co-existence, between Base Standards based on fundamentally different principles (e.g. Electronic Records exchange formats using either CEN 13606 or HL7 RIM based documents).

8.3.4 Increase European impact in international standardisation 5

Increase the coordinated contribution of Europe into international standardisation efforts to meet European needs within internationally accepted standards (e.g. for acute and home care device communications with IEEE, terminologies with WHO and IHTSDO, etc.).

8.4 Profile development and maintenance This activity is responsible for ensuring that the Business use cases prioritised and documented by the 10 activity described in 0 are broken down into Technical use cases and detailed implementation specifications called European-recognised Profiles are produced. The three main success factors are:

1. the ability to scope the Technical use cases so that the specified Profiles are reusable across several Business use cases;

2. have the credibility to attract a good mix of industry, large medium and small and health 15 professional organisations; and,


Profiles should cover all layers of interoperability, from transport, through messaging services, to data structures and terminologies; these last two are two of the major elements necessary to provide 20 semantic interoperability in health. It is proposed to use the processes defined by ISO TR28380lx IHE Global Standards Adoption Process to develop internationally agreed, or Europe specific, Profiles.

8.5 Profile quality assurance, test plans and tools This activity is to ensure, for Profiles, the development of conformance test plans and test tools under a 25 coordinated process among the various contributors and users. Users include industry which is implementing interoperability in its products, local, regional and national projects, care delivery organisations such as hospitals, clinics, laboratories, pharmacies, imaging centres, general practitioners, etc. Three key success factors are:

1. the ability to develop these test plans and tools in a timely fashion so that they could be made 30 available no later than four months after a Profile is recognised for trial implementation;

2. coordinate contributors resources to ensure that quality plans and tools are developed and maintained; and,

3. ensure open access to these test plans and tools and an effective maintenance process engaging the broad range of users. 35

For Phase 2 of the eHealth Standards Mandate, it is proposed to accredit IHE-Europe in partnership with ETSI, Continua (assuming its capability is proven in time), and possibly others. The IHE Europe Connectathon process already engages a significant numbers of vendors and users from most European countries. IHE also offers access to an operational and international test tools development process, which once reviewed, may be acceptable either as they stand or as the basis for 40 improvement. It is important to link the proposed structure with the existing national testing efforts in some of the European countries, and with international arrangements.

8.6 Sharing of best practices in deploying eHealth projects This activity is to give every national or regional project a forum to share experiences and publish best-practice guides that offer guidance in conducting the deployment activities of eHealth projects. 45 One key area should be the area of privacy and security policies, where much experience-sharing and consistency-building would benefit the emergence of a foundation of basic European practices in this complex area. A major success factor is the ability to define a new focus around which various communities across Europe would wish to engage. The sharing of best practices is facilitated among


Page 96

projects that share, in their Interoperability Specification, a significant foundation; hence the use of European-recognised Profiles.

For Phase 2 of the eHealth Standards Mandate, It is proposed to rely on EHTEL and the CALLIOPE project to conduct these activities for 2009 and 2010. Beyond 2010, a permanent accredited European entity needs to be designated to conduct these activities. 5


Page I

Abbreviations and glossary

Abbreviations For the purposes of the present document, the following abbreviations apply:

ANEC European Association for the Co-ordination of Consumer Representation in Standardization: http://www.anec.eu/

ANSI American National Standards Institute: http://www.ansi.org

ASN.1 Abstract Syntax Notation One, asn1.elibel.tm.fr/tools/tutorial

BCS British Computer Society: http://www.bcs.org

CALLIOPE DGINFSO project, Thematic Network - CALL for InterOPErability, http://www.calliope-network.eu

CCD HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD): http://www.hl7.org/library/General/HL7_CCD_final.zip

CCR ASTM E2369 - 05 Standard Specification for Continuity of Care Record, http://www.astm.org/Standards/E2369.htm/

CCOW HL7 Clinical Context Object Workgroup, http://www.hl7.org/Library/standards_non1.htm#Clinical Context Object Workgroup

CDA HL7 Clinical Document Architecture, http://www.hl7.org/Library/standards_non1.htm#CDA

CEN Comité Européen de Normalisation (European Committee for Standardization): http://www.cen.eu/cenorm/index.htm

CEN/ISSS CEN Information Society standardization system: http://www.cen.eu/cenorm/businessdomains/businessdomains/isss/activity/ehealth_fg.asp

CENELEC Comité Européen de Normalisation Electrotechnique, the European Committee for Electrotechnical Standardization: http://www.cenelec.org/

CHESSS CEN Horizontal European Services Standardization Strategy Initiative, http://www.chesss.eu/index.cfm

COPRAS Cooperation Platform for Research and Standards, http://www.copras.org

CORBA Common Object Request Broker Architecture: http://www.corba.org

CPME Comité Permanent des Médicins Européens, Standing Committee of European Doctors: http://www.cpme.be

DG ENTR Directorate-General Enterprise and Industry: http://ec.europa.eu/dgs/enterprise

DG INFSO Directorate-General Information Society and Media: http://ec.europa.eu/dgs/information_society

DG IM&S Directorate-General Internal Market & Services: http://ec.europa.eu/dgs/internal_market

DG SANCO Directorate-General Health and Consumers: http://ec.europa.eu/dgs/health_consumer

DICOM Digital Imaging and Communications in Medicine: http://medical.nema.org

DRG Diagnostic related group

ebXML electronic business XML: http://www.ebxml.eu.org/ (a multilingual site provided by CEN/ISSS) and http://www.ebxml.org

EC European Commission: http://ec.europa.eu/index.htm

ECR European College of Radiology

EFTA European Free Trade Area (Iceland, Liechtenstein, Norway and Switzerland)

eHSCG eHealth Standards Coordination Group: http://www.who.int/ehscg/about/en/

epSOS DGINFSO project, Smart Open Services for European Patients: http://www.epsos.eu

ESO European Standards Organisation (of which there are 3: CEN, CENELEC, ETSI)

http://www.anec.eu/

http://www.ansi.org

http://www.bcs.org

http://www.calliopenetwork.eu

http://www.hl7.org/library/General/HL7_CCD_final.zip

http://www.astm.org/Standards/E2369.htm/

http://www.hl7.org/Library/standards_non1.htm#Clinical

http://www.hl7.org/Library/standards_non1.htm#CDA

http://www.cen.eu/cenorm/index.htm

http://www.cen.eu/cenorm/businessdomains/businessdomains/isss/activity/ehealth_fg.asp

http://www.cenelec.org/

http://www.chesss.eu/index.cfm

http://www.copras.org

http://www.corba.org

http://www.cpme.be

http://ec.europa.eu/dgs/enterprise

http://ec.europa.eu/dgs/information_society

http://ec.europa.eu/dgs/internal_market

http://ec.europa.eu/dgs/health_consumer

http://medical.nema.org

http://www.ebxml.eu.org/

http://www.ebxml.org

http://ec.europa.eu/index.htm

http://www.who.int/ehscg/about/en/

http://www.epsos.eu


Page II

ETSI European Telecommunications Standards Institute: http://www.etsi.org

EU European Union (Austria, Belgium, Bulgaria, Cyprus, the Czech Republic, Denmark,, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden and United Kingdom)

EuroRec European Institute for Health Records: http://www.eurorec.org/

GPIC General purpose information component

GS1 Global Standards One: http://www.gs1.org

HIMSS Health Information Management Systems Society

HL7 Health Level 7: http://www.hl7.org

ICT information and communications technology

ICT Study DG ENTR, EU Study on the specific policy needs for ICT standardisation tba

ICTSB (CEN CENELEC ETSI) ICT Standards Board: http://www.ictsb.org/eHealth_standardization.htm

IDABC (EC) Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens: http://ec.europa.eu/idabc/en/home

IETF International Engineering Task Force: http://www.ietf.org

IFAN International Federation of Standards Users: http://www.ifan.org

IHE Integrating the Healthcare Enterprise: http://www.ihe.net and http://www.ihe-europe.net

IHTSDO International Health Terminology Standards Development Organisation: http://www.ihtsdo.org

ISB HaSC Standards Board for Health and Social Care: http://www.isb.nhs.uk/

ISO International Organization for Standardization: http://www.iso.org

ISSS CEN Information Society Standardization System: http://www.cen.eu/ISSS

ITTF ISO/IEC Information Technology Task Force: http://www.iso.org/ittf

JIC Joint Initiative Council on SDO Global Health Informatics Standardization (initiated in2007 by CEN TC251, ISO TC215 and HL7): http://www. global-e-health-standards.org

JTC 1 ISO/IEC Joint Technical Committee 1: http://isotc.iso.org/livelink/livelink/fetch/2000/2122/327993/customview.html?func=ll&objId=327993&objAction=browse&sort=name

MEDDEV EC, DG ENTR, Sector - Medical Devices: http://ec.europa.eu/enterprise/medical_devices/meddev

MS (EU) Member State

NHS National Health Service (overall term for the state organised health care systems of the UK home nations: England, Northern Ireland, Scotland and Wales)

NIST National Institute of Standards and Technology: http://www.nist.gov

Normapme The European Office of Crafts, Trades and SMEs for Standardization: http://www.normapme.com/

NSB National Standards Body (e.g. AENOR (E), AFNOR (F), ANSI (USA), JIS (J), etc.

OASIS Organisation for the Advancement of Structured Information Standards (see ebXML): http://www.oasis.org

OHT Open Health Tools: http://www.openhealthtools.org

OMG Object Management Group: http://www.omg.org

openEHR openEHR Foundation: http://www.openehr.org

RFP request for proposal

RSNA Radiological Society of North America

SME small / medium enterprise

http://www.etsi.org

http://www.eurorec.org/

http://www.gs1.org

http://www.hl7.org

http://www.ictsb.org/eHealth_standardization.htm

http://ec.europa.eu/idabc/en/home

http://www.ietf.org

http://www.ifan.org

http://www.ihe.net

http://www.ihe-europe.net

http://www.ihtsdo.org

http://www.isb.nhs.uk/

http://www.iso.org

http://www.cen.eu/ISSS

http://www.iso.org/ittf

http://www

http://isotc.iso.org/livelink/livelink/fetch/2000/2122/327993/customview.html?func=ll&objId=327993&objAction=browse&so

http://ec.europa.eu/enterprise/medical_devices/meddev

http://www.nist.gov

http://www.normapme.com/

http://www.oasis.org

http://www.openhealthtools.org

http://www.omg.org

http://www.openehr.org


Page III

Terminfo HL7 working group developing the specification of a general approach to resolving issues related to the interface between HL7 information models and terminologies or code systems and a guide on use of SNOMED Clinical Terms (SNOMED CT) concepts in the HL7 Version 3 communication standards: http://www.hl7.org/Special/committees/terminfo/index.cfm

TR Technical report

TS Technical specification

UN/CEFACT United Nations Centre for Trade Facilitation and Electronic Business (see ebXML): www.unece.org/cefact

VAR value-added reseller

W3C World-Wide Web Consortium: http://www.w3.org

WHO World Health Organisation: http://www.who.int

XML extended mark-up language

Glossary See 2.2 Definitions on page 12 for discussion of definitions particular to this Report.

clinician person professionally qualified to deliver healthcare

plugfest group test event that allows participants to collectively test technical entities in accordance with a specific test plan comprised of interoperability tests based on functional aspects of a given standard (based on definition at http://www.iol.unh.edu/services/testing/dsl/grouptest/)

privacy (noun) the quality or state of being apart from company or observation: freedom from unauthorized intrusion (http://www.merriam-webster.com/dictionary/privacy)

safety (noun) the condition of being safe from undergoing or causing hurt, injury, or loss (http://www.merriam-webster.com/dictionary/safety) safe (adjective) free from harm or risk (http://www.merriam-webster.com/dictionary/safe)

security (noun) the quality or state of being secure: (adjective): freedom from danger (http://www.merriam-webster.com/dictionary/security) concept similar to safety, but with added emphasis on being protected from external dangers (based on http://en.wikipedia.org/wiki/Security)

semantic of or relating to meaning in language (http://www.merriam-webster.com/dictionary/semantic)

use case description of sequences of events that, taken together, lead to a system doing something useful (Kurt Bittner, Ian Spence (2002). Use Case Modeling. Addison Wesley Professional. pp. 2–3. ISBN 0-201-70913-9 cited at http://en.wikipedia.org/wiki/Use_case)

http://www.hl7.org/Special/committees/terminfo/index.cfm

http://www.w3.org

http://www.who.int

http://www.iol.unh.edu/services/testing/dsl/grouptest/

http://www.merriam-webster.com/dictionary/privacy

http://www.merriam-webster.com/dictionary/safety

http://www.merriam-webster.com/dictionary/safe

http://www.merriam-webster.com/dictionary/security

http://en.wikipedia.org/wiki/Security

http://www.merriam-webster.com/dictionary/semantic

http://en.wikipedia.org/wiki/Use_case


Page IV


Page V

References The following material, specifically referenced in the body of the present document, gives supporting information.

i DG ENTR, Draft Terms of Reference for Project Team (2007-20), Brussels, 2008-01-31,

http://www.ehealth-interop.nen.nl/publicaties/2877&fil_Id=137 ii DG ENTR, Mandate to the European Standardisation Organisations CEN, CENELEC and ETSI

in the field of Information and Communication Technologies, applied to the domain of eHealth, Brussels, 2007-03-06, M/403 EN, http://www.ehealth-interop.nen.nl/publicaties/2877&fil_Id=145

iii DG ENTR, EU Study on the specific policy needs for ICT standardisation, Brussels, July 2007, http://ec.europa.eu/enterprise/ict/policy/standards/piper/full_report.pdf

iv CEN, Report from the CEN/ISSS eHealth Standardization Focus Group - Current and future standardization issues in the eHealth domain: Achieving interoperability, Brussels, 2005-03-31, http://www.cen.eu/cenorm/businessdomains/businessdomains/isss/activity/ehealth_fg.asp

v DG INFSO, Report of the Unit ICT for Health in collaboration with the i2010 sub-group on eHealth (formerly known as the eHealth working group) and the eHealth stakeholders’ group - Connected Health: Quality and Safety for European Citizens, Brussels, 2006-09-23, http://ec.europa.eu/information_society/activities/health/docs/policy/interoperability_report_final092006-cover.pdf

vi DG SANCO, WHITE PAPER - Together for Health: A Strategic Approach for the EU 2008-2013, COM(2007) 630 final, Brussels, 2007-10-23, http://ec.europa.eu/health/ph_overview/strategy/health_strategy_en.htm

vii DG SANCO, Proposal for a Directive on the application of patients' rights in cross-border healthcare, COM(2008) 414 final, Brussels, 2008-07-07 from http://ec.europa.eu/health/ph_overview/co_operation/healthcare/proposal_directive_en.htm

viii DG INFSO, The Portorož eHealth 2008 Conference Declaration - eHealth in a Europe “without frontiers”: Building New Initiatives – Working Together, 2008-05-07, http://ec.europa.eu/information_society/newsroom/cf/document.cfm?action=display&doc_id=474

ix Commission Recommendation (Explanatory Memorandum and Scope of the Recommendation) on cross-border interoperability of electronic health record systems, Brussels, 2008-07-02, COM(2008)3282 final, http://ec.europa.eu/information_society/activities/health/docs/policy/20080702-interop_recom.pdf

x DG INFSO, Commission Communication on "eHealth - making healthcare better for European citizens: An action plan for a European eHealth Area", COM(2004) 356 final. http://ec.europa.eu/information_society/activities/health/policy/index_en.htm

xi DG INFSO, Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of the Regions on Telemedicine for the benefit of patients, healthcare systems and society, Brussels, 4.11.2008, COM(2008)689 final, http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2008:0689:FIN:EL:PDF

xii EU DIRECTIVE 2005/36/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on the recognition of professional qualifications, 2005-09-07, (Consolidated version of Directive 2005/36/EC of 2007-12-26), http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:2005L0036:20071226:EN:PDF

xiii EUROPEAN PARLIAMENT, Committee on the Internal Market and Consumer Protection, DRAFT REPORT on the creation of a European professional card for service providers, (2008/2172(INI)), 17.10.2008, http://www.europarl.europa.eu/sides/getDoc.do?pubRef=-//EP//NONSGML+COMPARL+PE-414.372+01+DOC+PDF+V0//EN&language=EN

xiv DG INFSO project, Cross-border recognition of national eID, IP/08/824, 20080530 http://www.epractice.eu/document/4789

xv DGINFSO project, Thematic Network - CALLIOPE (CALL for InterOPErability), http://www.calliope-network.eu/

http://www.ehealth-interop.nen.nl/publicaties/2877&fil_Id=137

http://www.ehealth-interop.nen.nl/publicaties/2877&fil_Id=145

http://ec.europa.eu/enterprise/ict/policy/standards/piper/full_report.pdf

http://www.cen.eu/cenorm/businessdomains/businessdomains/isss/activity/ehealth_fg.asp

http://ec.europa.eu/information_society/activities/health/docs/policy/interoperability_report_final092006-cover.pdf

http://ec.europa.eu/health/ph_overview/strategy/health_strategy_en.htm

http://ec.europa.eu/health/ph_overview/co_operation/healthcare/proposal_directive_en.htm

http://ec.europa.eu/information_society/newsroom/cf/document.cfm?action=display&doc_id=474

http://ec.europa.eu/information_society/activities/health/docs/policy/20080702-interop_recom.pdf

http://ec.europa.eu/information_society/activities/health/policy/index_en.htm

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2008:0689:FIN:EL:PDF

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:2005L0036:20071226:EN:PDF

http://www.europarl.europa.eu/sides/getDoc.do?pubRef=-//EP//NONSGML+COMPARL+PE-414.372+01+DOC+PDF+V0//EN&language=EN

http://www.epractice.eu/document/4789

http://www.calliope-network.eu/


Page VI

xvi For a quick review of various interpretations see http://en.wikipedia.org/wiki/E-health (at 2008-06-

10) xvii Eysenbach G, What is e-health?, J Med Internet Res. 2001 Apr–Jun; 3(2): e20.

http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=1761894 (accessed 2008-05-15) xviii WHO Global Observatory for eHealth website, http://www.who.int/goe/en/ (at 2008-05-15) xix DG INFSO, http://ec.europa.eu/information_society/activities/health/whatis_ehealth/index_en.htm xx A Systemic Overview & Synthesis of the Literature - Report for the NHS Connecting for Health

Evaluation Programme - The Impact of eHealth on the Quality & Safety of Healthcare, London, 2008-04, http://www1.imperial.ac.uk/resources/4565EF18-662B-448B-90C2-E7372B4C2E09/

xxi DG INFSO, Draft Recommendation of the Commission on eHealth interoperability, Brussels, 16.07.2007 COM(2007) xxx, http://ec.europa.eu/information_society/newsroom/cf/itemdetail.cfm?item_id=3540

xxii WHO Assembly Agenda paper 2005, Geneva, 2005-04-07, http://www.who.int/gb/ebwha/pdf_files/WHA58/A58_21-en.pdf

xxiii WHO Assembly Resolutions and Decisions 2005, Geneva, 2005-04-07, http://www.who.int/gb/ebwha/pdf_files/WHA58/WHA58_28-en.pdf

xxiv CEN Horizontal European Services Standardization Strategy (CHESSS) Initiative, http://www.chesss.eu/index.cfm

xxv CEN/ISSS eHealth Standardization Focus Group. Current and future standardization issues in the eHealth domain: Achieving interoperability - Part 2: Annex D (p12), CEN, Brussels, 2005-03-31. ftp://ftp.cenorm.be/PUBLIC/Reports/eHealth/

xxvi Reynolds MI and Wejerfelt I, CEN TC251 Short Strategic Study: Health Information Infrastructure, CEN TC251, Document 074, 2000, available on request from the Secretary to CEN TC251.

xxvii NTA 8028, National Technical Agreement, Health informatics – Telemedicine, NEN, Delft, NL, http://www2.nen.nl/nen/servlet/dispatcher.Dispatcher?id=BIBLIOGRAFISCHEGEGEVENS&contentID=247831

xxviii Information technology in support of health care, WHO, Department of Essential Health Technologies, 1998, http://www.who.int/eht/en/InformationTech.pdf

xxix DG INFSO Ambient Assisted Living [AAL] R&D programme: http://www.aal-europe.eu/ xxx DG INFSO Project, i2-health Interoperability for a European eHealth area:

http://www.i2-health.org/wiki-container/InteroperabilityDefinitions xxxi EU Study on the specific policy needs for ICT standardisation study, European Commission, DG

Enterprise, Unit D, Brussels, July 2007, http://ec.europa.eu/enterprise/ict/policy/standards/piper/full_report.pdf

xxxii ETSI White Paper No. 3 Achieving Technical Interoperability – the ETSI Approach. October 2006. http://www.etsi.org/WebSite/document/whitepapers/IOP%20whitepaper%20Edition%203%20final.pdf

xxxiii IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990, http://ieeexplore.ieee.org/servlet/opac?punumber=2238

xxxiv See review and description of LCIM at http://en.wikipedia.org/wiki/Conceptual_interoperability xxxv Glushko RJ & McGrath T, Document Engineering, MIT Press, 2005, ISBN0-262-07261-0 xxxvi EN 13606-1:2007, Health informatics – Electronic health record communication – Part 1:

Reference model, CEN, Brussels, http://www.cen.eu/catweb/35.240.80.htm xxxvii DG INFSO Project, http://www.semantichealth.org xxxviii DG INFSO Project, RIDE, http://www.srdc.metu.edu.tr/webpage/projects/ride/ xxxix DGINFSO Project, SemanticHealth, Deliverable 7.1: Draft Semantic Interoperability Deployment

and Research Roadmap, http://www.semantichealth.org/DELIVERABLES xl DGINFSO Project, i2Health project, Comprehensive Overview of Interoperability Definitions and

Sub-Definitions, completed in August 2005, http://www.i2-Health.org/

http://en.wikipedia.org/wiki/E-health

http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=1761894

http://www.who.int/goe/en/

http://ec.europa.eu/information_society/activities/health/whatis_ehealth/index_en.htm

http://www1.imperial.ac.uk/resources/4565EF18-662B-448B-90C2-E7372B4C2E09/

http://ec.europa.eu/information_society/newsroom/cf/itemdetail.cfm?item_id=3540

http://www.who.int/gb/ebwha/pdf_files/WHA58/A58_21-en.pdf

http://www.who.int/gb/ebwha/pdf_files/WHA58/WHA58_28-en.pdf

http://www.chesss.eu/index.cfm

ftp://ftp.cenorm.be/PUBLIC/Reports/eHealth/

http://www2.nen.nl/nen/servlet/dispatcher.Dispatcher?id=BIBLIOGRAFISCHEGEGEVENS&contentID=2478

http://www.who.int/eht/en/InformationTech.pdf

http://www.aal-europe.eu/

http://www.i2-health.org/wiki-container/InteroperabilityDefinitions

http://ec.europa.eu/enterprise/ict/policy/standards/piper/full_report.pdf

http://www.etsi.org/WebSite/document/whitepapers/IOP%20whitepaper%20Edition%203%20final.pdf

http://ieeexplore.ieee.org/servlet/opac?punumber=2238

http://en.wikipedia.org/wiki/Conceptual_interoperability

http://www.cen.eu/catweb/35.240.80.htm

http://www.semantichealth.org

http://www.srdc.metu.edu.tr/webpage/projects/ride/

http://www.semantichealth.org/DELIVERABLES

http://www.i2-Health.org/


Page VII

xli DG INFSO Project, eHealth ERA, Towards the establishment of a European eHealth Research

Area - a coordination service to the European Union Member States, Database of European eHealth priorities and strategies, empirica, http://www.ehealth-era.org

xlii DG INFSO Project, eHealth ERA - D2.3 Priority Topic Cluster 1, Patient Summaries Final, 2007-2-15, empirica, http://www.ehealth-era.org/documents/eH-ERA_D2.3_Patient_Summaries_final_15-02-2007_revised.pdf

xliii See review and description of use cases at http://en.wikipedia.org/wiki/Use_case xliv Special Study No. 1, 2007/2008: ICT standards in the health sector: current situation and

prospects, A Sectoral e-Business Watch study by empirica, Draft Final Report Version 2.0, January 2008, http://www.ehealth-impact.org/download/index_en.htm

xlv 14th edition of the CEN/ISSS Survey of ICT Standards Consortia is available at: http://www.cen.eu/cenorm/sectors/sectors/isss/consortia/index.asp

xlvi ETSI STF355 Technical Report: TR 102 764, "eHealth architecture; User service models and application classification into service models", publication URL awaited.

xlvii ISO/IEC 7498-1: 1994 (also freely available as ITU/T Recommendation X.200 (07/94), http://www.itu.int/rec/T-REC-X.200-199407-I/en), Information technology – Open systems interconnection – Basic reference model: the basic model

xlviii electronic business XML: http://www.ebxml.eu.org/ (a multilingual site provided by CEN/ISSS) and http://www.ebxml.org

xlix Final report, World standards cooperation, Healthcare technology task force. January 2006, http://www.tc251wgiv.nhs.uk/pages/pdf/wgiv_n06_11.pdf

l N. Goga, K. Veil. Verification results for IT standards: FireWire, ISO 11073, ANSI/HL7 - Practical experience, Methods, Results. VDM Publishers, Germany 2008, ISBN 979-3-639-00102

li Wrightson A. "Interoperability of healthcare information" in BJHC&IM, 2007-10-08, http://www.bjhcim.co.uk/features/2007/710008.htm

lii Minutes of DIN mirror panel to CENTC251 – 2008-06-24, http://www.din.de liii IFAN, Guidelines to assist members of standards committees in preparing user-oriented

European Standards, First edition, Geneva, 2008-04: http://www.ifan.org/ifanportal/livelink/fetch/2000/2035/36282/394607/publications/IFAN_Guide3-2008.pdf

liv ISO, ISO/IEC Directives, Part 2: Rules for the structure and drafting of International Standards, Fifth edition, 2004, http://isotc.iso.org/livelink/livelink?func=ll&objId=4230456&objaction=browse&sort=subtype

lv ISO/IEC 10746 parts1 to 4: 1998(E) (© ISO/IEC 1998) are freely available from: http://enterprise.shl.com/RM-ODP/default.html

lvi Joint Initiative Council Working Group: http://www.e-health.standards.org.au/cat.asp?catid=43 lvii European Interoperability Framework [eif] for Pan-European eGovernment Services [PEGS],

Draft For Public Comments, as basis for EIF 2.0, 2008-07-15, http://ec.europa.eu/idabc/servlets/Doc?id=31597

lviii CEN/ISSS Workshop on Data Protection and Privacy (WS/DPP): http://www.cen.eu/cenorm/sectors/sectors/isss/activity/wsdpp.asp

lix Special Study No. 1, 2007/2008: ICT standards in the health sector: current situation and prospects, A Sectoral e-Business Watch study by empirica, Draft Final Report Version 2.0, January 2008, http://www.ehealth-impact.org/download/index_en.htm

lx ISO TR 28380:2008 Health informatics - IHE global standards adoption, http://www.iso.org/iso/search.htm?qt=28380&published=on&active_tab=standards

lxi For example: IHE demonstrations each have a different mix of vendors and assemble different sets of profiles in about one day. See too "IHE Success Stories", www.ihe.net/Resources/user_success_stories.cfm

http://www.ehealth-era.org

http://www.ehealth-era.org/documents/eH-ERA_D2.3_Patient_Summaries_final_15-02-2007_revised.pdf

http://en.wikipedia.org/wiki/Use_case

http://www.ehealth-impact.org/download/index_en.htm

http://www.cen.eu/cenorm/sectors/sectors/isss/consortia/index.asp

http://www.itu.int/rec/T-REC-X.200-199407-I/en

http://www.ebxml.eu.org/

http://www.ebxml.org

http://www.tc251wgiv.nhs.uk/pages/pdf/wgiv_n06_11.pdf

http://www.bjhcim.co.uk/features/2007/710008.htm

http://www.din.de

http://www.ifan.org/ifanportal/livelink/fetch/2000/2035/36282/394607/publications/IFAN_Guide3-

http://isotc.iso.org/livelink/livelink?func=ll&objId=4230456&objaction=browse&sort=subtype

http://enterprise.shl.com/RM-ODP/default.html

http://www.e-health.standards.org.au/cat.asp?catid=43

http://ec.europa.eu/idabc/servlets/Doc?id=31597

http://www.cen.eu/cenorm/sectors/sectors/isss/activity/wsdpp.asp

http://www.ehealth-impact.org/download/index_en.htm

http://www.iso.org/iso/search.htm?qt=28380&published=on&active_tab=standards


Page VIII

lxii Cardiac network in the Northern Netherlands, Maarten Festen,

www.forcare.nl/News/MCLPressRelease_2_en.htm lxiii Schanner A, Integrated Healthcare provided by ELGA, the eHealth infrastructure in Austria, 2008-

11-06, WoHIT - Copenhagen, http://www.worldofhealthit.org/docs/presentations/53_Schanner.pdf lxiv See ETSI Services at http://www.etsi.org/WebSite/OurServices/services.aspx which include

Forapolis (technology-enabling), INTEROPOLIS (product-enabling, includes Testing, Interoperability and other complementary services) and Plugtests™.

lxv Strategic Research Project INTEREST (Integrating Research and Standardisation, Project no. FP6 - 503594), from the European Commission in Priority 8 "Scientific Support to Policies areas" of the 6th Framework Programme, http://www.ist-world.org/ProjectDetails.aspx?ProjectId=99463a5e1c8c40d3984a25bd191eafad&SourceDatabaseId=7cff9226e582440894200b751bab883f

lxvi NHS Connecting for Health, Evaluation Programme, accessed 2008-09-16, http://www.connectingforhealth.nhs.uk/systemsandservices/etd/nhscfhep

lxvii NHS Connecting for Health, The initial generation and continuing refreshment of the GP Summary Care Record: The way forward, version 14 May, 2006, accessed 2008-06-17, http://www.nhscarerecords.nhs.uk/what-will-change/summary-care-record

lxviii Scottish Executive Health Department, Your Emergency Care Summary: What does it mean for you? 2006-08-29, accessed 2008-06-17, http://www.scotland.gov.uk/Publications/2006/08/16152132

lxix NHS Wales, Informing Healthcare, The Individual Health Record » The IHR in out-of-hours care » How it works, accessed 2008-06-17, http://www.wales.nhs.uk/IHC/page.cfm?pid=25883

lxx eEurope 2005: An information society for all - An Action Plan to be presented in view of the Sevilla European Council, Brussels, 28.5.2002, COM(2002) 263 final: http://ec.europa.eu/information_society/eeurope/2002/news_library/documents/eeurope2005/eeurope2005_en.pdf

lxxi Transforming the European healthcare landscape - Towards a strategy for ICT for Health, Luxembourg: Office for Official Publications of the European Communities, 2006, ISBN 92-894-7060-7, http://www.ehealtheurope.net/document_library/?ID=110&download=/o.cfm?link=/img/document_library0282/ICT_for_Health_i2010.pdf

lxxii i2010 eGovernment Action Plan: Accelerating eGovernment in Europe for the Benefit of All - Brussels, 25.04.2006, COM(2006) 173 final http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2006:0173:FIN:EN:PDF

lxxiii Ageing well in the Information Society: An i2010 Initiative - Action Plan on Information and Communication Technologies and Ageing, Brussels, 14.6.2007, COM(2007) 332 final, http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2007:0332:FIN:EN:PDF

lxxiv Preparing Europe’s digital future - i2010 Mid-Term, European Commission, i2010 Annual report 2008, Luxembourg: Office for Official Publications of the European Communities, 2008, ISBN 978-92-823-2434-9: http://ec.europa.eu/information_society/eeurope/i2010/docs/annual_report/2008/i2010_ar_2008_en.pdf

lxxv i2010 Strategy and eEurope Action Plans, http://europa.eu/scadplus/leg/en/s21012.htm#eEurope lxxvi EC IDABC, eID Interoperability as a Key Enabler for eGovernment,

http://ec.europa.eu/idabc/en/document/6959 lxxvii EU2003/751/EC Official Journal of the European Union L 276 Volume 46 27 October 2003,

Decisions 189, 190, 191 (2003/751/EC) , (European Health Insurance Card (EHIC)) lxxviii CEN ISSS, Interoperability of the electronic European Health Insurance Card (WS/eEHIC),

http://www.cen.eu/cenorm/sectors/sectors/isss/activity/ws+eehic.asp lxxix IHE IT Infrastructure Technical Framework, Patient Identifier Cross-referencing (PIX), by the IHE

ITI Technical Committee, http://www.ihe.net/Technical Framework/index.cfm#IT lxxx Directive 2005/36/EC of the European Parliament and of The Council, of 2005-09-07, on the

recognition of professional qualifications, http://www.aic.lv/bolona/Recognition/dir_prof/Directive_2005_36_EC.pdf

lxxxi DG EMPLOY Project, European Health Professional Card, http://www.hprocard.eu

http://www.worldofhealthit.org/docs/presentations/53_Schanner.pdf

http://www.etsi.org/WebSite/OurServices/services.aspx

http://www.ist-world.org/ProjectDetails.aspx?ProjectId=99463a5e1c8c40d3984a25bd191eafad&SourceDatabaseId=7cff9226e582440894200b751bab883f

http://www.connectingforhealth.nhs.uk/systemsandservices/etd/nhscfhep

http://www.nhscarerecords.nhs.uk/what-will-change/summary-care-record

http://www.scotland.gov.uk/Publications/2006/08/16152132

http://www.wales.nhs.uk/IHC/page.cfm?pid=25883

http://ec.europa.eu/information_society/eeurope/2002/news_library/documents/eeurope2005/eeurope2005_en.pdf

http://www.ehealtheurope.net/document_library/?ID=110&download=/o.cfm?link=/img/document_library0282/ICT_for_Health_i2010.pdf

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2006:0173:FIN:EN:PDF

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2007:0332:FIN:EN:PDF

http://ec.europa.eu/information_society/eeurope/i2010/docs/annual_report/2008/i2010_ar_2008_en.pdf

http://europa.eu/scadplus/leg/en/s21012.htm#eEurope

http://ec.europa.eu/idabc/en/document/6959

http://www.cen.eu/cenorm/sectors/sectors/isss/activity/ws+eehic.asp

http://www.ihe.net/Technical

http://www.aic.lv/bolona/Recognition/dir_prof/Directive_2005_36_EC.pdf

http://www.hprocard.eu


Page IX

lxxxii DG INFSO Project, NETC@RDS - A step towards the electronic European Health Insurance

Card, http://netcards-project.eu lxxxiii Rodrigues J-M et al. Standards and Biomedical Terminologies: the CEN TC 251 and ISO TC 215

Categorial Structures. A step towards increased interoperability, in eHealth Beyond the Horizon – Get IT There (Proceedings of MIE 2008.), S.K. Andersen et al. (Eds.), IOS Press, 2008, http://www.hst.aau.dk/~ska/MIE2008/ParalleSessions/PapersForDownloads/11.T&O/SHTI136-0857.pdf

lxxxiv Yale Center for Medical Informatics, The Guideline Elements Model, GEM, http://gem.med.yale.edu/default.htm

lxxxv MEDDEV, DG ENTR, Guidelines relating to medical devices Directives, http://ec.europa.eu/enterprise/medical_devices/meddev

http://netcards-project.eu

http://www.hst.aau.dk/~ska/MIE2008/ParalleSessions/PapersForDownloads/11.T&O/SHTI136-0857.pdf

http://gem.med.yale.edu/default.htm

http://ec.europa.eu/enterprise/medical_devices/meddev