FIGHT4PHR, a Health IT Project Proposal

1

< Project Proposal:

An ICT project for Rapid Adoption of PHR in EU>

< FP7-ICT-2011-7, Challenge 5: ICT for Health, Ageing Well, Inclusion and

Governance >

Proposed title: F.I.G.H.T. for PHR

Flexible Interoperable Grid of Health Technologies for Personal Health Record

2

Table of Contents Scientific and/or technical quality, relevant to the topics addressed by the call .......................................................... 3

Section 1. Concept and objectives ............................................................................................................................ 3

Introduction .......................................................................................................................................................... 3

Vision .................................................................................................................................................................... 4

Scope .................................................................................................................................................................... 4

Objectives ............................................................................................................................................................. 4

Outline .................................................................................................................................................................. 5

Active connection between basic research work and tangible outcomes ........................................................... 5

Outcomes ............................................................................................................................................................. 6

2. Progress beyond the state-of-the-art ................................................................................................................... 8

Interdisciplinary research for IST intensive work ................................................................................................. 9

State of the Art Roll Out Methods ........................................................................................................................ 9

Setting up the target: Patient Oriented Digital Services ....................................................................................... 9

PHR: an electronic service adopted and in use, not just an electronic record ................................................... 10

Organic IT ............................................................................................................................................................ 10

The use of CMMI for FIGHT network nodes creation ......................................................................................... 10

The use of Balance Scorecard for Organic IT software performance measurement and FIGHT Expansion ....... 11

An innovative approach for PHR use: the “Smart PHR Drive” ............................................................................ 12

The technology grid: the key to optimal PHR use and adoption ........................................................................ 13

Research Focus ................................................................................................................................................... 16

3. S/T methodology and associated work plan ....................................................................................................... 17

Work allocation .................................................................................................................................................. 17

Work plan ........................................................................................................................................................... 19

Section 2. Implementation .......................................................................................................................................... 36

2.1 Management structure and procedures ........................................................................................................... 36

Communication flow and documentation ........................................................................................................... 37

Conflict Resolution ............................................................................................................................................. 38

Quality Assurance Plan ...................................................................................................................................... 39

Section 3. Impact ......................................................................................................................................................... 39

3.1 Expected impacts listed in the work programme ............................................................................................. 39

Section 4. Ethical Issues ............................................................................................................................................... 42

General Principles of Informatics Ethics ............................................................................................................. 42

A Code of Ethics for medical staff ....................................................................................................................... 43

Duties towards HCPs .................................................................................................................................................. 43

Personal data for public good: using health information in medical research ............................................................. 44

3

Scientific and/or technical quality, relevant to the topics addressed by

the call

Section 1. Concept and objectives

Introduction

The Personal Health Records promise has been around for quite some time now, yet to fulfill its destined

purpose: personal health data, at the time and place of need beyond any geographical borders seamlessly

connected and interoperable with any Health related service providers/ systems. And there is still a long

way to go since adoption of PHR technology presents considerable challenges, the most important of

them being the following:

Technological Interoperability among Health IT Systems

Although considerable work has been carried out at the level of standards there is an even

growing need for intermediate enterprise (and cross national) systems that facilitate the

interoperability at stake.

The end users are yet to feel the ―safe harbor‖ feeling concerning PHR services. This is mainly due

to

Inadequate implication of end users to technology solutions design that make end users feel

distant and alienated the moment the technology is being presented to them

Ethical Issues: Data sharing and security. The nature and importance of medical data for each

and every one of the citizens demand crystal clear solutions (technological methods, business

models etc.) and equally crystal clear communication concerning data security and information

sharing. Currently these crystal clear solutions have yet to be communicated accordingly to the

general public.

Compliance of use according to national legislations

Law and regulations that address the use and adoption of PHR services are totally different from

state to state within the EU. To make matters more complicated interpretation of these laws and

regulations among HSPs is varied (even within the same state). The latter becomes more

complicated by the growing demand of the citizens for participatory health and shared decisions

Entrepreneurship on behalf of SME and individual software developers has yet to be triggered

Active participation from developers‘ communities (SMEs and individuals) have proven

indispensable in other more mature ICT areas such as the ones of CMS systems, Productivity

applications, Community games etc.

The present proposal introduces research that addresses all of those challenges in a unified way:

Technological Interoperability is dealt creating a technology grid that expands from HSP to HSP by

maturing their processes and technologies with the least possible effort. Work is done simultaneously

at ground level (the HSP Health IT applications) and on the Internet (supporting web services)

Software Design is studied from its infancy along with the end users that are formally represented

by patient organizations and networks coming from a variety of EU countries and relating to various

health conditions.

Compliance to law and regulations is embedded in structured methods and techniques of

technological maturity and social marketing research that leads to methods and tools for policy

makers

Entrepreneurship is addressed by offering technology tools for collaborative work decoupled from

the strict HSP IT environment.

4

Vision F.I.G.H.T. for PHR aspires to pave the way for seamless interoperability of a citizen’s PHR to the

maximum number of HSPs and Health Services in general beyond technical, red tape and other digital

divergence barriers.

The project furthers research in the IST area of Personal Health Records and specifically in the way a

European Citizen‘s PHR electronic service can support any physical transaction between a European

Citizen and a Health Service Provider (HSP).

To provide a “live” test bed of such a broad scope of research the project creates a Health Informatics

Technology Grid (the F.I.G.H.T. for PHR) that is strategically designed to innovatively establish and

expand itself from one Health Service Provider (HSP) to another providing seamless connectivity

between the HSPs’ Health IT Systems and the citizens’ PHRs relieving the demand for a unique

PHR electronic card.

Every time such connectivity is attained, the HSP at hand joins the FIGHT network as a FIGHT node.

The expansion of the F.I.G.H.T. network is based on dynamic roll out methods that are designed to

provide that seamless HSP to PHR connectivity with the least possible effort concerning HSP

Reengineering, Technology and Red Tape barriers. The whole process is governed by a custom made

CMMI maturity method for Health IT services and feeds a Balanced Scorecard reporting service that

―runs‖ the FIGHT network horizontally diffusing knowledge from one node the next (candidate) one.

Scope

The project scope of the F.I.G.H.T. network involves partners from 9 European Countries covering all

feasible partner categories of such an endeavor (Academic and Research Partners, Health Informatics

SMEs, Patient Organizations and Networks, Medical Associations of national and regional character,

Hospitals, Medical Care Partners etc.). At its initial phase the first setup of the FIGHT nodes is being

created in HSPs in Greece and the Netherlands. After the executions of the roll out methods, and counting

FIGHT nodes in all of the 9 countries that the project has official representation, all partners re

coordinated towards the core target of the project (seamless PHR interoperability) by organizing multiple

trips of FIGHT Organic Expansion Groups (FOEGs. These groups include research associates and

representatives from patient organizations around Europe (and within the F.I.G.H.T. network European

State Members). They follow a comprehensive multidimensional scenario which pools from a rich variety

of Health Provision Services and utilizes an electronic ―Health Card‖ device. Initially, each FOEG

member is provided by such a device which, according to the scenario, varies among USB flash drives,

existing PHR/ PHR related smart cards, simple membership plastic cards etc. Then, FOEG visits in

various European cities are carried out featuring carefully designed personalized patterns for each FOEG

member. These personalized patterns include all typical patterns of real life medical situations like

emergencies, prescheduled visits, hospitalization etc. with some of them even describing a ―loss of the

card‖ scenario). The use case of the device by the FOEG members (in all of the aforementioned

scenarios) is designed in an innovative way that leaves a ―trace‖ to the Health provider that hosted the

scenario incident – a ―trace‖ carefully designed to ease that Health provider‘s effort towards their

maturity for Health IT services.

Objectives The F.I.G.H.T. for PHR features the following main objectives:

Create a fully operational European Network (a prototype technology grid infrastructure) that

provides seamless connectivity to Health Informatics systems that support medical services to

European citizens relieving the demand for a unique PHR electronic service

Develop specific ―hands on‖ methods and tools, custom made for each European Member State

of the F.I.G.H.T. network, that describe specific and detailed action plans of the ―flexible

adaptation scenario for any PHR Health Card‖ covering the political, governmental, technological

and managerial domains

Provide all plausible policy and decision makers with guidelines, methods and tools designed for

rapid expansion of the F.I.G.H.T. prototype network at a regional, national and European level

Other important objectives are:

5

Diffuse knowledge in a coordinated way concerning all aspects that are involved in rapid PHR

technology adoption utilizing a new electronic library collaborative service designed for Health

and e-Health professionals as long as for general EU public

Promote entrepreneurship for Health Informatics by setting up the technology infrastructure for

software developers that supports collaborative creation and promotion of interoperability

software tools

Outline

Combining basic research with fully functional software prototypes, F.I.G.H.T for PHR furthers basic

research work from multiple disciples and formulates the research outcomes into citizen centric

personalized electronic / web services. This much needed functional connection between

multidisciplinary basic research and tangible prototypes of personalized electronic / web

applications and services is illustrated in the following graph:

Active connection between basic research work and tangible outcomes

All research papers are targeting at developing the aforementioned innovative roll out methods and

related tangible outcomes. As the whole project is strategically aligned towards its outcomes, work

allocation and roll out methods result to specific tangible research prototypes (software applications and

services at ―beta versions‖ phase). The semantic interrelations among the basic research work of the

project and the tangible outcomes‘ features is illustrated in the following graph:

6

Outcomes The F.I.G.H.T for PHR project outcomes will be the following:

Research Outcomes

Eleven Scientific Papers that further basic research in the areas of Informatics, Health

Management, Health Services Law and Regulations, Social Marketing published (and announced)

in globally reputed scientific journals and conferences. An indicative list of such journals and

conferences is following:

Informatics

The Health Informatics Conference

International Conference on Health Informatics, International Joint Conference on

Biomedical Engineering Systems and Technologies

AMIA Annual Symposium

The WSEAS International Conference on BIOMEDICAL ELECTRONICS and

BIOMEDICAL INFORMATICS

IEEE Transactions on Evolutionary Computation

IEEE Transactions on Knowledge and Data Engineering

7

IEEE Transactions on Smart Grid

Health Management

Health It Congress and leadership summit (HIMSS)

Economic and Managerial Aspects of e-health (special session in ITAB conference)

Health Services Law and Regulations

Various annual Health law Conferences

Social Marketing

Social Marketing in public Health Conference

USF Social Marketing in Public Health Conference

Annual Art and Science of Health Promotion Conference

Informatics

Health IS Semantics: ―A Framework Ontology for rapid PHR adoption by multiple heterogeneous

systems‖

Health IS Design: ―A distributed Event Driven Interface software layer design for Health Data

Entry, Sustainability and Interoperability‖

Health IS Distributed Systems: ―A Multichannel Asynchronous Information Flow and Verification

for Heterogeneous Health Informatics Systems Interoperability‖

Health IS Security and Integrity: ―A unified SSO web service in a heterogeneous Health Informatics

Technology Grid in a distributed cloud environment‖

Health IS Distributed Systems: ―A Hybrid Unified Software Development Model for both Open

Source and Proprietary Health Informatics distribution channels‖

Health Management

Health Management: ―A flexible Scenario Based Workflow Management method for rapid adoption

of foreign PHR schemas in a hospital‘s mainframe management system ‖

Health Management: ―A CMMI based maturity framework for Health Informatics initiatives

deployment following the lean production paradigm‖

Health Management: ―A balanced scorecard monitoring system under an organic IT deployment

framework‖

Policy Issues

Health Provision Management: ―Fighting Red Tape obstacles in Health Informatics adoption at the

regulatory and governmental level: Guidance and methodological tools for the regional, state and

European stakeholders‖

Social Marketing: ―A fact finding Report of the Societal Impact of Health Informatics Technology

breakthroughs‖

Social Marketing: ―The social implications of m-health applications in Europe‖

Tangible Research Functional Prototypes1

F.I.G.H.T. functional nodes

1 The term “Functional Research Prototypes” refers to fully functional software applications and services at the

“beta” version phase.

8

A ―F.I.G.H.T. functional node‖ is a Health Provider that has adopted a functional PHR scheme and

is ready to provide services to patients based on their PHR health data. F.I.G.H.T. functional nodes

vary in adoption levels (1-5) based on a CMMI based scale of Health Informatics maturity level

“Follow-me Health Data” Electronic Service

―Follow-me Health Data‖ is an electronic/web service that recognizes PHR owners and authenticates

them as users on any F.I.G.H.T. functional node. The authentication is triggered by the owner‘s

request (it is event driven) by means of a web portal featuring a ―smart‖ mobile phone interface and

a corresponding mobile app. Multiple authentication scenarios are supported covering extremities

such as emergency ambulance alerts, loss of credential information (―loss of card‖), third person

activation (loss of consciousness) etc

“PHR Connect” Electronic Interoperability Repository

―PHR Connect‖ is a Master Index Repository that catalogues APIs from any PHR related Heath

Informatics software systems. All API catalogues are available to plausible stakeholders by means of

a digital library that features the APIs‘ code libraries and related documentation. Upload to ―PHR

connect‖ requires a minimum compliance to F.I.G.H.T.

“Health Hippo: Health Informatics Interoperability Developers’ Community”

―Health Hippo‖ is a Collaboration Portal that promotes software developers‘ collaboration (on ―per

Project‖ basis) regarding creating and sustaining Interoperability Software that connects

heterogeneous Software systems to any F.I.G.H.T. functional node.

“Euterpe: Regional, National and European PHR Adoption Methods and Guidelines”

Collaboration Portal and Digital Library The ―Euterpe‖ digital library is a thematic digital library that embodies all the deliverables of the

project which are

The research papers with their full documentation

Any software documentation (manuals etc)

Specific guidelines for PHR adoption methods

Walkthroughs for Health Providers towards a rapid development of a F.I.G.H.T. functional node

within their domain

Guidelines and Walkthroughs for rapid creation and adoption of PHR related regulations and

law at a regional, state and European level

2. Progress beyond the state-of-the-art

In the EU the State of Art concerning the use of Health Informatics technologies in favor to the European

Citizen Patient predominantly lies with two main European funded projects: The epSOS project (Smart

Open Services for European Patients) and the Calliope thematic Network.

The epSOS features two main use cases for cross border communication, the Patient Summary and

ePrescription.

The main goal of the CALLIOPE Network has been to produce value for decision makers for

national eHealth implementations. CALLIOPE comprises a dedicated forum where decision

makers, implementers, professionals, patients and other stakeholders can share visions, experiences

and good practices on how to establish interoperable eHealth services and has recently communicated

a Strategic Roadmap towards these objectives.

The main points of complementarity of the present project with both epSOS and Calliope could be the

following:

Complementarity with epSOS

FIGHT for PHR will provide specific Patient Centered PHR services within a Network of European

stakeholders that operate on a technology grid. A complement to what epSOS has already achieved

would be to populate the ―PHR Connect‖ Electronic Interoperability Repository with APIs of the

9

NCPs‘ epSOS applications/ services with the purpose of populating a citizen‘s PHR with any

personal medical data these services route.

Complementarity with Calliope

CALLIOPE has established a successful collaborative platform for many actors in eHealth

interoperability in Europe covering the topic of mobile patients that will be one of the basic

references of the 2,5,6 and 8 FIGHT WPs

Interdisciplinary research for IST intensive work The research that is conducted within the project‘s scope produces tangible research outcomes from

different science disciplines. Specifically, although these outcomes enhance and empower strictly Health

Informatics applications, they demand expertise from HSPs performance management and also from

areas such as Health Law and Regulations and Social Marketing. This structure is due to the fact that the

proposed project is equally targeting at both the creation and adoption of the related Health

Informatics services and applications – the latter as viewed by any plausible stakeholder‘s point of

view at the regional, state and EU level.

State of the Art Roll Out Methods The roll out methods of the project combine a state of the art deployment technique featuring bottom up

organic IT scorecard monitoring and dynamic business workflow management. The resulting combination

avoids chaos by utilizing a laconic event driven User Interface software layer which handles multichannel

feeds from heterogeneous software systems in an Enterprise Service Bus environment featuring the

demanding security required for the endeabour. The UI events’ rules are populated by both the bottom

up scorecard approach (in the Organic IT fashion described above) and the top down multichannel

information and business dynamic workflow scenarios (the FOEG visits) being the functional

interoperability layer unifying the roll out of the project from the users’ point of view. Horizontal

interoperability is assured by means of a Unified Interface software layer Subsystem (the Enterprise

Service Bus, described in WP3) that functions under a Domain Framework Ontology created specifically

for the purposes of the project (WP2). Red-tape regulatory and social implication research findings are

utilized as filters to the events of the UI. Also, the FOEG visits feature use cases of maximum flexibility

and scenarios that are designed to leave a ―trace‖ in each Health Provider carefully designed to ease that

Health provider‘s effort towards their maturity for Health IT services.

Setting up the target: Patient Oriented Digital Services The interdisciplinary character of the research combined with the geographic and regulatory disparity of

the endeavor demands state of the art roll out methods that have to combine robust scientific

methodologies with unavoidable original work. The strict alignment of the project to tangible outcomes

presents an opportunity to bond the interdisciplinary research work respecting the geographic and

regulatory disparity. Since the main workflow of the project leads to tangible research software

prototypes alignment of all aspects of work within the project is governed by the features and

characteristics of these software prototypes - with the scientific publications being the documentation and

knowledge diffusion agents of the way these software outcomes have evolved. Specifically, the governing

feature of these software prototypes has to satisfy the core need of the users, thus, taking into account the

users need described in the FP7 ICT Objective 5.3, a), the governing feature should be Patient Guidance.

Having tied the governing feature of the research outcomes (software prototypes) of the present project

with Objective 5.3, a), Patient Guidance, the challenge remains to the methods used. In order to fully

support the logic behind the selection of these methods and illustrate their complementarity two notions

are introduced: a clarification of our view concerning PHR as an electronic service and our interpretation

of an Organic IT software (or system). Following these notions the CMMI-SVC, V1.3 maturity model

integration method and the Balanced Scorecard performance management methods are introduced in

order to complement an innovative approach of PHR use involving a PHR physical device and the

creation and expansion of the technology grid of the project.

10

PHR: an electronic service adopted and in use, not just an electronic record A “citizen centric personalized electronic /web service” is not only a UI of a web application (available

for all to use) but all that including documented proof of its functionality by a critical mass of users /

stakeholders. In our case the ―critical mass of users‖ consists of

a. Citizens (and patients) as the ―PHR owners‖

b. Health provider staff

c. People of the medical (or medical related) profession (apart from the ones of the Health provider)

that have a correlation with the ―PHR owner‖

d. Payer‘s staff

e. Related government staff (and from other regulatory bodies)

f. People trusted by the ―PHR owner‖

So, in FIGHT, PHR actually means ―citizen centric personalized electronic /web service for PHR‖ which

includes adoption and use by all of the above stakeholder‘s categories (our interpretation of a PHR

system)

Organic IT An Organic Software (or IT System) is the one that presents strong interaction with users‘ activity in all

of its phases of development (from inception to continuous improvement). It is a Software (or system)

that ―listens‖ to its users and is able to change its behavior according to users‘ feedback regardless the

depth of the changes (from a slight UI alteration to core architecture changes). Software (or IT systems)

that are created and operate in this fashion are characterized as ―organic‖ because they represent a

technological interpretation of users‘ behavior. The robustness of an Organic Software (or system)

depends on the quality of experts‘ moderation on the changes that are needed to meet the users‘ demands.

Organic Software (and systems) need to be particularly flexible in their architecture. The three distinctive

characteristics of Organic Software (and systems) are the following:

● A modular architecture with an adequate degree of granularity

● The ability to embed modules created by developers that interact with the main software‘s users (and

stakeholders) in social styled developer‘s communities

● A dashboard / scorecard module that enables feedback information flow from the front-end users (the

dashboard section) to the back-end moderators, administrators and module developers (the scorecard

section). This can be done in an automatic or manual way: the first being users’ actions/ states

monitoring and rules firing and the second including user’s feedback by polls and follow up actions

by admins and developers. An indicative implementation of feedback information flow would be

according to the balanced scorecard method. Following a careful setup by system architects (that

need to closely cooperate with business and other regulatory related stakeholders) the method could

“translate” user’s behavior (their dashboard reads) to moderators’, administrators’ and developers’

meaningful actions (their scorecard reads)

The use of CMMI for FIGHT network nodes creation The initial nodes of the FIGHT network will be the HSPs located in the Netherlands and Greece. An

examination of one or more processes by a trained team of professionals using an appraisal reference

model as the basis for determining, at a minimum, strengths and weaknesses will be carried out with the

sole purpose of appraising the level of maturity of these HSPs concerning their ability to offer the

service of seamless connectivity of their EHR / EMR systems with any PHR services. The boundaries

of the appraisal encompassing the organizational limits within which the processes to be investigated

operate are set to the minimum possible taking into account that one of the main objectives of the project

is rapid adoption of PHR connectivity and use which is preferred in contrast to full adoption that might

cause unwanted complexity concerning the reengineering needed on behalf of the HSPs. A capability

level profile is set for appraising the HSPs maturity towards the aforementioned connectivity that includes

the following process areas of the HSPs (CMMI-SVC, V1.3): Incident Resolution and Prevention (IRP),

Service Delivery (SD), Service System Development (SSD), Service System Transition (SST) and

Strategic Service Management (STSM). A relationship entity diagram illustrating the process areas and

11

the tools that will be used to support the Service Establishment and Delivery of EHR/ EMR to PHR

connectivity is following:

Following the appraisal of each HSP a strategic goal is set and documented as a Service Contract /

Agreement for the desired maturity level for offering the desired EHR / EMR to PHR connectivity

service. The minimum threshold level of maturity towards embedding the HSP into the FIGHT network is

set to level 3. Work towards this maturity level is done using the standard work procedures of CMMI-

SVC, V1.3 is carried out in all phases of the creation and expansion of the FIGHT network described

below

The use of Balance Scorecard for Organic IT software performance measurement and FIGHT Expansion The Balanced Scorecard method is proposed due to the results based character of the present project and

the strong relation between the strategic targets and the outcomes. This relation has to be kept robust in an

ever expanding environment of an Enterprise System such as the one of FIGHT that operates across

geographical and regulatory disparity. Additionally, the outcomes themselves (the software prototypes)

are of an intensive dynamic character featuring Organic IT characteristics (see section Organic IT). In this

highly volatile and distributed environment a two dimensional implementation of the Balanced Scorecard

technique is proposed. The first dimension covers the performance measurement of the software

prototypes as described in section ―Organic IT‖ and the second supports knowledge diffusion as described

in phase three ―Organic Expansion Phase‖ of section ―The technology grid: the key to optimal PHR use

and adoption‖ below. The volatility of the aforementioned environment is the principal reason for

choosing this two-dimensional BS implementation. BC is a well proven technique for capturing and

diffusing knowledge where ―closed group‖ controllability is not the prime characteristic of the application

Customer/End User

STSM

SSD

SST

IRP

SD

Process Areas for

Managing Services

StrategicServiceNeeds

ServiceCatalog

Corrective Actions

StrategicServiceNeeds

IRP = Incident Resolution and Prevention

SD = Service Delivery

SSD = Service System Development

SST = Service System Transition

STSM = Strategic Service Management

ServiceValue

Transition Plans

ServiceCatalog

RequestStatus

ServiceRequirements

Contract / ServiceAgreement

ServiceRequests

Incident Response Information

Service Issues

IncidentStatus

Service Requirements

Operations andService Delivery

Data

Deployed Service System

Validated Service System

Revised Resource Constraints and

Service Thresholds

Service Requirements

StandardService

Requirements

12

environment. It is ideal for a large (multinational/ global) organization/ company where the distance

between the leadership that decides strategy and the execution level (of that strategy) is considerable and

often involves geographical (and even regulatory) disparities – just as the FIGHT network. Furthermore,

the demand for user-centered electronic services (Patient Guidance PHR services) that is attained

through repetitive performance measurement and optimization involving the User into the process of

software development follows similar volatility and geographical and regulatory disparity as the FIGHT

network and leads to the implementation of the second dimension of the BC.

An innovative approach for PHR use: the “Smart PHR Drive” The PHR as an electronic record reside simultaneously in a USB device (conveniently carried in the

owner‘s wallet or key holder) and in an encrypted cloud based service. The USB device characteristic and

the way its contents communicate with the cloud are the following:

1. Distinctive appearance (very important in case of an acute emergency that could mean the owner is

in great pain or even unconscious). Ideally, if the PHR is provided through a Health oriented network

(a patient organization, the government, a payer etc.) funds should be invested on the social

awareness of the appearance (shape, color etc.) of that device. In a more limited (but effective)

fashion this awareness is feasible if communication / marketing is targeted primarily to regional,

national and international health systems (following a scalability similar to the expansion of the

FIGHT nodes). A proposed shape of the USB device is the credit card like USB flash drives that can

be easily fit in wallets or the key shaped USB flash drives one (in the likes of LaCie), featuring a

distinctive color that can be easily recognized and communicated / marketed. Also it is proposed that

the USB drive will have, at least, the owner‘s social security number printed on its cover.

2. The PHR electronic file in a structured form (indicatively as collection of CCD‘s)

3. Other PHR related files. These files are of great importance for both emergency situations and PHR

adoption scenarios (as explained below)

4. Encryption software that separates a private/ encrypted part of the USB flash drive and a public one

where the PHR related files are located. The software will have the ability to assign share privileges

and to synch in a cloud based encrypted service to keep mirrors of the contents of the USB drive

(both encrypted and public)

5. F.I.G.H.T. adoption software. This software has two core characteristics :

5.1. The software will ―scan‖ any file that is located in the public part of the drive and classify it

following an ―OCR style‖ recognition algorithm. After classification and upon owner‘s consent the

software will upload the files to the ―PHR connect‖ web service for further work that could entail

(indicatively):

a. Embedment of the new data to the structured PHR file

b. Initiation of a series of alerts to medical staff, payer staff etc

c. Automatic forwarding of unstructured files to specialized agents (software of human) for

further classification,

d. Other related actions.

5.2. The software will contain interface oriented software of EHR, EMR software systems and

therefore will be able to update the structured PHR file automatically if such systems are active in

the Health Provider IT infrastructure (via the USB port or via the PHR connect web service)

As illustrated in the Objectives section, FIGHT aims at creating Tangible PHR based citizen centric web

services / prototypes within a technology grid. Taken into account the aforementioned principle

regarding PHR systems it is clear to us that any PHR that aspires to have the slightest chance of

producing documented proof of its functionality (from all stakeholders) should be operating within a

technology grid. Analogous to the technology service (the PHR) the technology grid proves functional

after documentation of good use is produced by all stakeholders. The FIGHT distinguishes three classes

of such grids: the regional, the national and the international one.

13

The technology grid: the key to optimal PHR use and adoption Since PHR based services are more or less evident the creation of the technology grid that makes

optimal use of the Smart PHR Drive is quite interesting from both research and implementation point

of view. A practical approach to present such a grid is following:

In principle, the FIGHT for PHR core strategic target is to create a web of active FIGHT nodes in

various EU places. Put simple, a FIGHT node is a geographical and social domain where PHR

services are well adopted and function for the benefit of the common people. In the preliminary phases

certain EU regions will be chosen, that are under the “influence” of three core knowledge “beacons”:

1. A Research beacon: usually an Academic / Research institution that belong to that region /

country ideally ―coupled‖ with a ―sister‖ Health provider

2. A Technology beacon: usually a Health IT company that belong to that region / country

3. A Patient beacon: usually a Patient org (their local office)

Such a domain that combines the influence of these ―beacons‖ is a feasible FIGHT node. The project

initiates within the geographical and social domains of the FIGHT nodes and works in three time phases:

a. The “introvert” phase when work focuses on creating a functional PHR service within the

FIGHT node and is the ―local‖ aspect of the project,

b. The “extrovert” phase when work focuses on diffusing knowledge to the immediate neighbors

of the nodes, using tangible PHR services, accompanied with the necessary documentation (both

technical and regulatory), and

c. The “Organic Expansion ” phase when work focuses on delivering intrusive roll out methods

(equipped with the outcomes of both the ―introvert‖ and ―extrovert‖ phases) that provide both

technical and regulatory methods and tools to perform domino ―introvert‖ / ―extrovert‖ phases

from neighbor to neighbor creating FIGHT nodes in a spider web fashion

A practical view of a FIGHT node at the regional level is following (the national and international are

somewhat analogous with the unavoidable complexity):

At any region of an EU country there are:

1. The local Health Provider (a clinic and / or a diagnostic center)

2. An Academic / Research Institution of the region / country

3. A patient network with local offices (in the country)

The above are evidence of a candidate FIGHT node. The work that could transform such a candidate

node to a fully functional FIGHT node includes three basic phases, which are the following:

“Introvert” phase

The local Health Provider, the Academic / Research Institution and the Patient Network in collaboration

with partners that locality is not a question, those being the IT Companies and Consultancy companies,

conduct preparatory work for the candidate FIGHT node. This work includes the appraisal (CMMI-SVC,

V1.3) as described above that results to

A) A Service Contract / Agreement for the desired maturity level for offering the desired EHR / EMR to

PHR connectivity service and

B) Follow up actions (mini-projects) that are part of an Action Plan that aims at attaining the Service

Contract. The work of those mini-projects follows the standard procedures of CMMI-SVC, V1.3

(transition plans, corrective actions etc.). A simplified version of the mini-projects in a step by step

fashion is following:

1. Scenarios of patient visits to the Health Provider to document the Health Provider processes, any

HER, MHR evidence and (very important) the patient‘s experience

2. Development of a limited number of Smart PHR Drives for a variation of groups (ideally most of

them belonging to a patient network)

14

3. Rolling out of the scenarios following a sequence that is analogous to the maturity of the Health

Provider regarding EHR and EMR

4. Conduct research mainly on the PHR enrichment and utilization by the Health Provider via the

Smart PHR Drive and the role of all Smart PHR Drive components (both technological (software)

and physical / distinctive characteristics).

5. Diffusing knowledge produced in all stakeholders of the introvert phase. Review scenarios of step

1 and repeat all steps till optimal results are obtained. Optimal results are based on a targeted

maturity level of all stakeholders of the candidate node concerning the optimal utilization of the

Smart PHR Card. When this maturity level reaches a specific threshold the Health Provider

receives the ―Active FIGHT node‖ characterization (following an evident scalability of maturity

ranging from minimal to full compliance with of the FIGHT network).

An indicative scenario of a patient visit to the Health Provider is the following:

Scenario A: A visit to a non-FIGHT Health Provider with no active EHR, EMR following an acute

incident. The patient is in perfect communication with their environment.

1. The Patient visits the Health Provider following an acute incident.

2. Upon admittance he informs the people of the admittance office that he holds a USB drive with

vital medical data and also informs them that there is a file in the drive entitled ―Instructions of

the Smart PHR Drive for Health Providers‖. He communicates with the people at the admissions

that they should notify the medical staff about this file (suggesting that it can be easily printed)

3. When he receives any results or diagnosis by the Health Provider Staff he mentions that he holds

a USB device that contains all his medical data, that the people at admittance have been notified

about that upon admittance and that he wishes to receive any diagnosis and test results

documentation electronically (to store them into the USB drive) or if that is not possible to

receive the documentation on paper.

4. Any documentation that the patient receives electronically is stored in the drive. When possible

(obviously at a later time) the patient logs on the PHR connect service and the files update the

structured PHR via the F.I.G.H.T. adoption software 5. Any documentation the patient receives in paper is scanned into the drive either by the patient

themselves at a later time or perhaps by utilizing a payer‘s service (specially for the elderly or the

computer illiterate) and then update the PHR via the F.I.G.H.T. adoption software

6. Any of the above can be done on behalf of the patient and upon his consent, utilizing the

Encryption Software of the drive, by any of the following:

a. Health Provider‘s staff

b. Payers staff

c. Their personal physician / doctor

d. People from their immediate social environment

e. etc.

An interesting variation of the above scenario is of a non-FIGHT Health provider that presents some use

of EHR / MHR schemas. In this case if the F.I.G.H.T. adoption software in the drive is updated with APIs

of the EHR / MHR software(s) then the structured PHR is updated automatically (either in the Health

provider‘s IT environment or at a later time though PHR connect cloud service).

It is quite evident that variations of the scenario above are numerous but this particular one is indicative of

the manner that the PHR can be updated even by Health Providers that present little to none digital

convergence concerning Health Informatics. This is made possible by very few and simple actions on

behalf of the PHR owner and a ―smart‖ utilization of software components in a simple USB drive that

automatically synch with analogous cloud based services.

“Extrovert” phase

After the Health Provider receives (at least the minimal) compliance of a FIGHT node then work is

focused on diffusing knowledge to the immediate neighbors of that node, using tangible PHR services,

accompanied with the necessary documentation (both technical and regulatory). It is important to note

15

here that ―immediate neighbors‖ of a FIGHT node are Health Providers that present characteristics such

as the following:

i. Locality: a ―next door‖ Health Service Provider

ii. Medical Similarity such as Cancer Oriented clinics

iii. Technical Similarity such as use of identical / similar EHR / EMR software

It is expected that these “neighbor” HSPs will be Patient Networks affiliated (or related) General

Practitioners and small clinics rather than Hospitals of the size and magnitude of the project member’s

hospitals

1. Communication in regards of awareness of the benefits of the use of the Smart PHR Drive

a. Evidence illustrated in fact finding reports and relative presentations from the implementation

of the scenarios of the Introvert phase

b. The prerequisites and the necessary actions in order to attain a minimal FIGHT compliance.

Ideally the communication is carried out by a representative of a patient network (the local office

that conducted the Introvert scenarios / visits) possibly supported by medical staff of the new

FIGHT node and other staff from payers.

2. Repetition of the Introvert phase in the neighbor candidate node ideally with the support of not only

the local office of the patient network but also by staff (IT and medical related) from the new FIGHT

node

“Organic Expansion” phase

When a critical mass of FIGHT nodes appear in a geographical / social domain then action groups, the

FOEGs (see “introduction”), can be formulated in order to support the expansion of FIGHT in this domain

(a region or a state). Within these domain borders introvert and extrovert phases of candidate nodes can

receive support by those action groups and thus the FIGHT expansion is being accelerated. Ideally a

FOEG is led by patient organizations representatives accompanied by research associates of medical

related and IT background. The FOEGs‘ visits follow a comprehensive multidimensional scenario which

pools from a rich variety of Health Services provision and utilizes a single electronic ―Health Card‖

device. Initially, each FOEG member is provided by such a device which, according to the scenario,

varies among USB flash drives, existing PHR/ PHR related smart cards, simple membership plastic cards

etc. Then, FOEG visits in various European cities are carried out featuring carefully designed

personalized patterns for each FOEG member. These personalized patterns include all typical patterns of

real life medical situations like emergencies, prescheduled visits, hospitalization etc. with some of them

even describing a ―loss of the card‖ scenario. The use case of the device by the FOEG members (in all of

the aforementioned scenarios) is designed in an innovative way that leaves a ―trace‖ to the Health

provider that hosted the scenario incident – a ―trace‖ carefully designed to ease that Health provider‘s

effort towards their maturity for Health IT services. Depending on the scenario at hand, which in turn is

custom based according to the CMMI based maturity level of the Health provider concerning Health IT

maturity, the ―trace‖ could be:

ADOPTION ACTIONS / HSP IT MATURITY

Health IT

Maturity

Level

Trace FIGHT “smart card”

device components’ use

Suggested Follow up actions

(coordinated by patient networks)

1

No IST present

Documented proof

of the service

provided (i.e. a

receipt)

The imprinted social

security number

Telephone communication to arrange

meeting with a legal representative and

try to initiate an ―introvert‖ phase

2

Limited use of

IST (office

apps, email)

Contact details of

the Health

Providers‘ IT staff


security number

Possible use of the

―public‖ space of the drive

Telephone communication to arrange an

informative meeting and try to retrieve

relevant patient‘s electronic records.

Establish Electronic communication via

16

for information retrieval mail with all necessary documentation

for the information retrieval process

3

Extensive use

of office apps

but no use of

Health IT apps

(EHR, EMR,

PHR)

Contact details of

the Health

Providers‘ IT staff


security number

Possible use of the

―public‖ space of the drive

for information retrieval

Telephone communication to arrange an

informative meeting and try to retrieve

relevant patient‘s electronic records.

Establish Electronic communication via

mail with all necessary documentation

for the information retrieval process

4

Extensive use

of office apps

with limited use

of Health IT

apps (EHR,

EMR, PHR)

Contact details of

the Health

Providers‘ Health

IT admin

FIGHT adoption software

to scan the technical

details of the Health IT

apps

When plugged on the Internet synch

with Health Hippo and post a commit

ticket for developing an API

5

Extensive use

of Health IT

apps (EHR,

EMR, PHR)*

*at least one

Contact details of

the Health

Providers‘ Health

IT admin

FIGHT adoption software

to scan the technical

details of the Health IT

apps and try to connect to

the Health IT apps via

PHR connect

When plugged on the Internet synch

any retrieved data with the PHR

through PHR Connect if connection

with any of the Health IT apps was

successful. If not then perform same

actions as level 4

At this point it is important to stress out that because the expansion is led by specific patient networks

then it is much easier for FIGHT to expand beyond the physical borders of a (EU) country taken into

account the traits of the ―immediate neighbors‖ and specially the Medical and Technical one mentioned

above.

Research Focus The research proposed is meant to be multidisciplinary taken the fact that the project‘s main objectives

demand state of art scientific work on a) Informatics, b) Health Management and c) Policy Issues as

illustrated in the ―Objectives‘ section.

Taken into account the aforementioned, research focuses on:

1. The Software Components of the Smart PHR Drive

2. The Supporting cloud based services for the Smart PHR Drive: PHR Connect and Health Hippo (the

latter being an active community of Health IT developers and related Academics that develop open

source software components for both the Smart PHR Drive and the supporting cloud services)

3. The optimal implementation of the three phases for the Expansion of FIGHT (and, by result, the

expansion of PHR related services) including the maturity of Health Providers concerning PHR

services adoption at the regional, state and international level. The research will make use of CMMI

and BS methods and metrics.

17

3. S/T methodology and associated work plan

Work allocation

The work demanded for the implementation of the proposed F.I.G.H.T for PHR project requires a robust

project management scheme which will have to allocate and manage work to multiple resources of

various professional origins. These resources are expected to: a) be widely distributed (all over Europe),

b) collaborate on a synchronous / asynchronous fashion towards a good number of deliverables and

deadlines and c) be of varied professional backgrounds taking into account the multidisciplinary character

of the project. Having all those in mind, the implementation of the project is divided vertically into three

main pillars. These three pillars will be coordinated under a single work package, WP1 Project

Management, horizontally set and common to all pillars. The overall work allocation of the project is

following:

On the Pillar level, work allocation follows the project objectives (see. “Objectives”), the project

consortium members list and the research areas of the project.

On the Work Package level, work is allocated to partners according to their project work

complementarities (see Table WORK Complementarities below) and the deliverables list.

WP01: Project Management

Pillar 1: Knowledge Base and Initial Setup

WP No WP title

02 Health Informatics PHR-centric Framework Ontology

03 A distributed Event Driven User Interface software layer for

Health Data Entry, Sustainability and Interoperability

04 F.I.G.H.T. network initial setup

Pillar 2: Development and Integration

WP No WP title

05 Scenario Based Workflow Management module

06 Organic IT Scorecard Monitoring subsystem

07 F.I.G.H.T. network base Integration

Pillar 3: Expansion and Sustainability

WP No WP title

08 e-Health Social Marketing PHR adoption framework

09 F.I.G.H.T. network “follow me” PHR demonstrations

10 F.I.G.H.T. network sustainable expansion field scenarios

implementation

11 Case Studies

12 Dissemination Activities

18

WORK

Complementarities

Pillars / Partners

Pillar 1: Knowledge

Base and Initial

Setup

Pillar 2: Development

and Integration

Pillar 3: Expansion and

Sustainability

Project

Coordinator and

Technical

Consultants

WP01

WP02

WP01

WP05

WP06

WP01

WP09

Academic Research

WP02

WP03

WP04

WP11

WP05

WP06 WP08

Software Vendors /

Integrators

WP02

WP03

WP05

WP06

WP07

WP09

WP10

Patient Networks WP04 WP07

WP08

WP09

WP10

WP11

WP12

PROJECT VALUE

Stakeholders /

Outcomes

EU citizens Academics /

Researchers

Health

Professionals IT Industry

F.I.G.H.T.

network

Get on-the-

spot health

services

N/A

Provide on-the-

spot health

services

Support on-the-

spot health

services

Follow-me Health

Data

Get on-the-

spot health

services

N/A

Provide on-the-

spot health

services

Support on-the-

spot health

services

PHR Connect N/A Interact with

Industry

Interact with

Industry

Develop

Software

Health Hippo N/A Interact with

Industry

Interact with

Industry

Develop

Software

Euterpe

Get

information

about Points

Of Service

Publish

Papers

Publish Reports,

Get state-of-art

scientific info

Publish Reports,

Get state-of-art

scientific info

Research Papers N/A

Get state-of-

art scientific

info

Get state-of-art

scientific info

Get state-of-art

scientific info

19

Work plan

WPs / MOs 3 6 9 12 15 18 21 24 27 31 34 36

WP01 Project

Management

WP02

Health

Informatics PHR

centric

Framework

Ontology

WP03

A distributed

Event Driven

User Interface

software layer for

Health Data

Entry,

Sustainability and

Interoperability

WP04 F.I.G.H.T.

network initial

setup

WP05

Scenario Based

Workflow

Management

module

WP06

Organic IT

Scorecard

Monitoring

subsystem

WP07 F.I.G.H.T.

network base

Integration

WP08

e-Health Social

Marketing PHR

adoption

framework

WP09 F.I.G.H.T.

network “follow

me” PHR

demonstrations

WP10

F.I.G.H.T.

network

sustainable

expansion - field

scenarios

implementation

WP11 Case Studies

WP12 Dissemination

Activities

*0-36: from the beginning of the project up to the end of the 36th month.

01: 0 – 36*

03: 1- 25

04: 2 - 12

02: 1 - 31

05: 3 - 25

06: 3 - 35

08: 9 - 35

07: 12 - 24

09: 15 - 35

10: 12 - 36

11: 24 – 35

06: 12 - 35

20

List of Deliverables (44 deliverables out of 12 work packages)

Del.

no. Deliverable name

WP

no. Nature

Dissemi-

nation

level

Delivery

date(proj.

month)

01.01 Project Reports 1 MGT PU Monthly

02.01

―A concept ontology for a flexible PHR

schema in an distributed heterogeneous

IS environment‖

2 RTD PU 6

02.02 ―Merging CEN 251 and HL7 based

ontologies into a unifying framework‖ 2

RTD PU 12

02.03

―A Framework Ontology for rapid PHR

adoption by multiple heterogeneous

systems‖

2 RTD PU 31

03.01

A unified Interface software layer

subsystem for heterogeneous health

informatics systems

3 RTD PU 6

03.02

A unified PHR interoperability web

service for heterogeneous health

informatics systems

3 RTD PU 12

03.03

―A distributed Event Driven User

Interface software layer design for Health

Data Entry, Sustainability and

Interoperability‖

3 RTD PU 25

04.01 CCMI based maturity deployment for

F.I.G.H.T. network Initial Setup nodes 4 RTD PU 6

04.02 F.I.G.H.T. network: Initial Setup 4 DEM PU 12

04.03

―PHR Connect‖ Electronic Marketplace

and Interoperability Repository: dev

package

4 DEM PU 12

04.04

―Health Hippo: Health Informatics

Interoperability Developers‘

Community‖ Collaboration Portal: dev

package

4 DEM PU 12

04.05

―Euterpe: Regional, National and

European PHR Adoption Methods and

Guidelines‖ Collaboration Portal and

Digital Library: dev package

4 DEM PU 12

21

05.01 CCMI based maturity deployment for

rapid PHR schemas adoption 5

RTD PU 6

05.02

Seamless Management Health Provision

Reengineering for rapid PHR schemas

adoption 5 RTD PU 12

05.03 Balanced Scorecard Deployment for rapid

PHR schemas adoption 5 RTD PU 12

05.04

―A flexible Scenario Based Workflow

Management method for rapid adoption

of foreign PHR schemas in a hospital‘s

mainframe management system‖

5 RTD PU 25

05.05

―A CMMI based maturity framework for

Health Informatics initiatives

deployment‖

5 RTD PU 25

06.01

Self-replicating organic IT deployment

for PHR based Health Informatics

applications

6 RTD PU 12

06.02

―A balanced scorecard monitoring system

under an organic IT deployment

framework‖

6 RTD PU 35

07.01 F.I.G.H.T. network base Integration 7 RTD PU 24

07.02


and Interoperability Repository: Alpha

Version

7 DEM PU 24

07.03



Community‖ Collaboration Portal:

Alpha Version

7 DEM PU 24

07.04




Digital Library: Alpha Version

7 DEM PU 24

07.05

―A Multichannel Asynchronous

Information Flow and Verification for

Heterogeneous Health Informatics

Systems Interoperability‖

7 RTD PU 24

07.06

―A unified SSO web service in a

heterogeneous Health Informatics

Technology Grid in a distributed cloud

environment‖

8 RTD PU 24

08.01 ―Societal Impact of electronic Health 8 RTD PU 18

22

Applications: The breakthroughs

perspective‖ workshop

08.02

―A fact finding Report of the Societal

Impact of Health Informatics Technology

breakthroughs‖

8 RTD PU 35

08.03 ―The Societal Impact of m-health

applications in Europe‖ 8 RTD PU 35

09.01

Red tape obstacles regarding the rapid

adoption of PHR Health Informatics

Services at the regional level

9 RTD PU 24

09.02



Services at the state level

9 RTD PU 24

09.03



Services at the European level

9 RTD PU 24

09.04 F.I.G.H.T. network ―follow me‖ PHR

demonstrations exhibition 9

DEM PU 35

10.01 F.I.G.H.T. network functional prototype 10 RTD PU 35

10.02


and Interoperability Repository: Beta

Version

10 RTD PU 35

10.03



Community‖ Collaboration Portal: Beta

Version

10 RTD PU 35

10.04




Digital Library: Beta Version

10 RTD PU 35

10.05

―A flexible Scenario Based Workflow

Management method for rapid adoption

of foreign PHR schemas in a hospital‘s

mainframe management system ‖

10 RTD PU 35

10.06

―A Hybrid Unified Software

Development Model for both Open

Source and Proprietary Health

Informatics distribution channels‖

10 RTD PU 35

10.07 ―Fighting Red Tape obstacles in Health

Informatics adoption at the regulatory and

governmental level: Guidance and

10 RTD PU 35

23

methodological tools for the regional,

state and European stakeholders‖

11.01 A initial setup of prototype PHR centric

Health Informatics 11

RTD PU 18

11.02 F.I.G.H.T. network initial setup

stakeholders‘ workshop 11 RTD PU 18

11.03 ―PHR-centric European Technology

Grids‖ Conference A 11

RTD

OTHER PU 24

11.04 ―PHR-centric European Technology

Grids‖ Conference B 11

RTD

OTHER PU 36

Work package description

Work package

number

1

Work package title

Project Management

Objectives

The objective of this activity is to provide overall coordination and management for the entire contract.

This includes technical and administrative coordination, quality assurance, taking care of partner

dynamics and conflicts, and ensuring that the project is delivered according to the planned timetable

and budget. It also includes the writing and reviewing of all kinds of management and project

monitoring documents.

Description of work (possibly broken down into tasks) and role of partners

Technical coordination; contractual management; organise and coordinate communication flow;

manage documentation, track project status; maintain travel plans; review and verify deliverables;

progress meetings and reviews (including notices, agendas, chairing and minutes); ensure coordination

between different activities; conflict resolution, risk prevention/minimization.

Communication flow between partners will be achieved using teleconferences, collaborative software

tools, mailing lists, and a controlled repository of developed software. Mobility of researchers and

developers will be favored and encouraged.

The responsibilities that the coordinator will assume consist of the following tasks:

• Setting up a web-based collaborative tool, promoting its usage by all partners. Basic functionalities of

this tool will be in operation just after the official starting date of the project.

• Self-assessment and project workplan specification. Functional and temporal dependencies between

WPs will be considered so they do not become a source of conflict or delay in deliverables.

• Ensuring technical quality of the activities, deliverables and dissemination elements.

• Reporting activities, progress and resource management, acting as interface for communication

between the partners and the EC. Issuing management reports, progress reports and cost statements

The following formal tasks have been identified;

o Consortium Administration

24

o Financial Management

o Quality Assurance

o Activity Planning and Reporting

Status reports every 6 months, Coordination meetings every 3 months

Private collaborative and administrative website deployed

Initial tools available; user groups recruited; tentative dissemination and use plan proposed;

project self-assessment & workplan specifications

New content providers recruited; first annual workshop; Revised Project workplan

specification, software progress update

Internal assessments; Final prototype components available; Initial evaluation results, revision

requests and deployment procedure

Final public and private reports issued, project ends

Deliverables (brief description) and month of delivery

01.01. Project Reports

Quality assurance protocols and policies

Mandatory management, financial and activity reports

Final Public Report

Mandatory final management, financial and activity reports

Work package

number

2

Work package title

Health Informatics PHR-centric Framework Ontology

Objectives

To set the semantic base for the software design

To include the patient networks‘ experience to the semantic base for the software design

To unify the semantics of world-wide accepted Health IT standards with the particularities of the

present project and specifically the adoption character of the software designs and the experience

of the patient networks


Academics lead research cooperating closely with the Health IT Companies. Patient networks

contribute to the domain classes that relate to a) User Interface, b) Information security and sharing (if

applicable) and c) Any other behavior oriented classes

Academic XX updates an annotated bibliography depicting state of the art in the area of Health IT

Semantics

Academic XX outlines the concept ontology of 02.01

Health IT Company XX studies HL7 RIM and CEN 251schematics and applications and contributes to

the concept ontology of 02.01

Health IT Company XX and Patient Networks XX examine the parts of the concept ontology that have

to do with a) User Interface, b) Information security and sharing (if applicable) and c) Any other

25

behavior oriented classes

Academic XX merges the results of 02.01 and 02.02 to a framework ontology

Work of the WP2 will take into account the findings of “Semantic Interoperability RTD roadmap

project EU IST 6th fw 27328” (http://www.semantichealth.org/) and the work done at SEMIC.EU

(http://www.semic.eu/semic/)


02.01 “A concept ontology for a flexible PHR schema in an distributed heterogeneous IS

environment”

A domain ontology for the FIGHT project is created. The Ontology is characterized by three main

layers: 1) The Physical layer that includes all the tangible deliverables and stakeholders of the project,

2) The Syntactical layer that refers to the obvious connections among the physical software and the

stakeholders and 3) The Flexible Dynamic layer that features behavioral patterns for both the Physical

and Syntactical layers from the requirements point of view. The Flexible Dynamic Layer functions as

follows: The behaviors at hand refer to system alterations that follow expansion scenarios of the

FIGHT ecosystem according that inevitably lead to changes to the requirements of the FIGHT

distributed IS ecosystem. The Interactions between behavioral requirements are documented using

OWL and Semantic Web Rule Language (SWRL) notation. At a given time point when expansion

activity is observed, OWL based Requirements Classes document the main Ontology Class Instances‘

values and then an Interaction description in SWRL is produced. According to this description

alterations in the FIGHT IS distributed system may be proposed. Those alterations are embodied in the

domain ontology. In this way maximum flexibility that serves the Organic Adoption Procedures (see.

section ―Organic IT‖) from the early stage of Ontological Design is assured.

02.02 “Merging CEN 251 and HL7 based ontologies into a unifying framework”

A merged Ontology that binds the CEN251 and the HL7 RIM ones is created. The purpose of this

merge is to result to an ontology that respects both CEN251 and HL7 RIM classifications that dominate

the Health IT Ontology area (and the corresponding applications) with the obvious purpose of

interoperability among heterogeneous systems.

02.03 “A Framework Ontology for rapid PHR adoption by multiple heterogeneous systems”

The framework ontology consists of:

The Domain Ontology of 02.01

The Merged CEN 251 and HL7 RIM Ontology of 02.02.

The purpose of the creation of a Framework Ontology is to combine the flexibility and adaptability of

the 02.01 Domain Ontology with the wide application spectrum covered by the merged 02.02 one. The

Framework ontology is the corner stone for the design of all aspects of the FIGHT deliverables -

tangible and intangible.

Work package

number

3

Work package title

A distributed Event Driven User Interface software layer for Health Data

Entry, Sustainability and Interoperability

Objectives

http://www.semantichealth.org/

http://www.semic.eu/semic/

26

To carry out and document thoroughly the design of the project‘s proposed software solutions

To develop the archetypes of the project‘s proposed software solutions

To develop the initial archetype software in a lab environment (server instances in a cloud

service)

To actively involve Patients contribution specifically for a) User Interface, b) Design Patterns,

c) Information Security and Sharing


Health IT Companies XX develop the design of all the software solutions of this particular WP.

Based on the framework ontology of WP2 A full UML description of the software is first created

depicting the Architecture layer‘s and module descriptions. Upon completion of the UML designs,

archetypes are created based on OOP software. These archetypes are then fine-tuned and tested in a

lab environment (server instances on cloud environment).

Patient Networks contribute to the design of the following features of the software solutions: a) User

Interface, b) Design Patterns, c) Information Security and Sharing. Patient networks‘ contribution will

be channeled through a) Specific Module Oriented Questionnaires, b) Global System Features Polls

and c) Online ―live‖ testing of software modules in a lab environment using the Balance Scorecard

Software of WP6


03.01 “A unified Interface software layer subsystem for heterogeneous health informatics

systems”

The software layer is created according to the deliverables of WP2. The modules of this layer will

include the following:

The Framework Ontology Server module responsible for the alignment of the physical

vocabularies and the data descriptions of any subsystems and software repositories using the

Framework Ontology of WP2

The Enterprise Service Bus module responsible for carrying out the messages of the

subsystems. Taken in to account the physical complexity of all the software subsystems (cloud

and USB). The architecture of the ESB will be one of the core research matters of the present

project. A number of paradigms will be under investigation (typical and hybrid) starting with

the publish-and-subscribe (pub/sub) messaging one.

03.02 “A unified PHR interoperability web service for heterogeneous health informatics

systems”

The web service relies on a repository that is a semi-structured database of Application Interfaces

(APIs). These APIs come from software systems embodied or related with the FIGHT network. The

web service functions as a bridge connector between the APIs and the ESB of 03.01 using the

Framework Ontology of WP2

03.03 “A distributed Event Driven User Interface software layer for Health Data Entry,

Sustainability and Interoperability”

The Event Driven UI (EDUI) software layer is the one that governs the principal characteristics of the

UI modules of all software subsystems of FIGHT (cloud and device based). These characteristics

include at least the following: 1) Usability, 2) Accessibility, 3) User ID preferences awareness (look

and feel, language, Customizable fields etc.), 4) ―Mood‖ function (indicatively for hospitalization,

recuperation, thematic information gathering etc.), 5) Global (community) Alerts and Alert buttons

(SOS alerts, panic alerts, ―next of keen‖ notifications, medical data consent triggers etc.) . Each UI of

every subsystem will be updated by the EDUI on every software update occurrence. All the

aforementioned characteristics are depicted in a Balanced Scorecard performance software module

27

that records feedback from the test users/ the patient networks in both manual and automatic way as

described in section (see section ―Organic IT‖) based on the work of WP6

Work package

number

4

Work package title

F.I.G.H.T. network initial setup

Objectives

To prepare and set up the initial infrastructure and related electronic services and software of

the FIGHT network

To prepare the HSPs of the project to interoperate with PHR services (belonging to the Patient

Networks)

To provide the patient networks with an active PHR service

To develop the initial archetype software of ―PHR Connect‖ in a lab environment (server

instances in a cloud service)

To populate the ―PHR connect‖ database with any available APIs from the appraisals

To develop software that supports the research work carried out in the project (Health Hippo

and Euterpe)


Academic partner XX with Health IT Companies design the CMMI appraisal method for the introvert

phase fine tuning the work done for WP5

Academic partner XX with Health IT Companies design the BS reporting tool for the introvert phase

fine tuning the work done for WP6

Health IT Companies XX develop the design of all the software solutions of this particular WP.

Based on the framework ontology of WP2 A full UML description of the software is first created

depicting the Architecture layer‘s and module descriptions. Upon completion of the UML designs,

archetypes are created based on OOP software. These archetypes are then fine-tuned and tested in a lab

environment (server instances on cloud environment).

Health IT Companies XX develop an ―out of the box‖ installation of PHR and activate it for the

patient networks of the project

Health IT Companies XX develop ―out of the box‖ installations of collaborative CMS software

(Health Hippo) and a collaboration oriented electronic library (Euterpe)

Health IT Companies, project’s HSPs (Hospitals) and Patient Networks carry out the CMMI

appraisals on the project members HPS (Hospitals)

Patient Networks contribute to the design of the following features of the software solutions: a) User

Interface, b) Design Patterns, c) Information Security and Sharing. Patient networks‘ contribution will

be channeled through a) Specific Module Oriented Questionnaires, b) Global System Features Polls

and c) Online ―live‖ testing of software modules in a lab environment.


04.01 CCMI based maturity deployment for F.I.G.H.T. network Initial Setup nodes

28

A CMMI based appraisal is conducted in the FIGHT Initial Nodes situated in the Netherlands, and

Greece. The appraisal aims at placing the initial nodes at any of the levels described in the

ADOPTION ACTIONS / HSP IT MATURITY table. The Appraisal results include the micro projects

needed to be carried out in order these initial nodes reach target HSP Maturity level (a description of

the model used is illustrated ―The use of CMMI for FIGHT network nodes creation‖) and in the

introvert phase.

04.02 F.I.G.H.T. network: Initial Setup

The Results / micro projects of the CMMI appraisal concerning the maturity of the initial FIGHT

nodes of 04.01 are activated. The micro projects‘ end deliverables are a) Documentation from the

CMMI appraisals that the initial nodes are at target maturity level (between 3 and 5) in the form of a

CMMI appraisal report and b) Available APIs of any EHR and EMR software for the ―PHR connect‖

service d) An active PHR electronic service for the patient networks of the project

04.03 “PHR Connect” Electronic Marketplace and Interoperability Repository: dev package

―PHR Connect‖ is a software subsystem that resides in the cloud as a semi-structured database

repository for EHR and EMR (and other feasible Health Informatics APIs – see indicative FOEGs‘

scenarios) APIs.

04.04 “Health Hippo: Health Informatics Interoperability Developers’ Community”

Collaboration Portal: dev package

―Health Hippo‖ is a project oriented collaboration portal for rapid software development. Within

―Health Hippo‖ independent software developers undertake commitments for software projects related

with the maintenance and expansion of FIGHT. The service is public allowing any EHR / EMR

software vendor and/or HSP to post APIs that connects their software with the FIGHT cloud services.

Furthermore the service allows any stakeholder to publish RFPs for developers in order to ascertain

such APIs.

04.05 “Euterpe: Regional, National and European PHR Adoption Methods and Guidelines”

Collaboration Portal and Digital Library: dev package

―Euterpe‖ is an electronic library service that hosts all FIGHT related documentation and provides

document centered collaboration services for any tasks, projects and subprojects of FIGHT. The initial

content of the service will be the project‘s deliverables with all related documentation (original work

and references).

Work package

number

5

Work package title

Scenario Based Workflow Management module

Objectives

To develop a generic CMMI method for rapid PHR adoption on behalf of the HSPs based on

flexible scenarios that respect the behavior patterns of patients


Academic partner XX with Health IT Companies design a generic CMMI appraisal method for rapid

PHR adoption on behalf of the HSPs

Academic partner XX with Health IT Companies design a BS reporting tool for aligning the vertical

implementation of the CMMI method

29

Academic partner XX examines the documentation of the appraisals and the metrics of the BS

reporting tool and upgrades the generic method for del. 05.04

Academic partner XX examines the documentation of the appraisals and the metrics of the BS plus the

results of 05.04 and upgrades the generic method for del. 05.05


05.01 CMMI based maturity deployment for rapid PHR schemas adoption

Taken in to account the 04.01 deliverable a CMMI based maturity deployment detailed action plan is

carried out (see par. ―The technology grid: the key to optimal PHR use and adoption‖, extrovert phase).

The study is based on patient networks‘ members experience of HSP ―near‖ to the initial FIGHT nodes

(as described in the extrovert phase)

05.02 Seamless Management Health Provision Reengineering for rapid PHR schemas adoption

Based on the findings of both 04.01 and 05.01 a flexible reengineering scenario for rapid PHR schemas

adoption aimed at HSPs is created as described from patients in 05.01. The scenarios respect minimal

reengineering interventions for optimal results (meaning the provision of EHR / EMR APIs) focusing

on management decision making and vertical implementation of such decisions at the level of both the

medical staff and the IT department.

05.03 Balanced Scorecard Deployment for rapid PHR schemas adoption

A balanced scorecard application is undertaken on based the scenarios of 05.02 with the purpose of

fine tuning the vertical decision flow bringing awareness on all levels of related staff of the HSP

05.04 “A flexible Scenario Based Workflow Management method for rapid adoption of foreign

PHR schemas in a hospital’s mainframe management system”

A robust method of Scenario Based Workflow Management is created based on the findings of dels

04.01, 05.01-04. The method is the walkthrough for carrying out the extrovert phase (see par. ―The

technology grid: the key to optimal PHR use and adoption‖, extrovert phase). The method is aimed at

the managerial and medical staff of the HSP that have to be implicated in any effort towards Health IT

maturity of any HSP

05.05 “A CMMI based maturity framework for Health Informatics initiatives deployment”

A robust method of CMMI based maturity framework is created based on the findings of dels

04.01, 05.01, 05.03 and 05.04. The method is the walkthrough for carrying out the extrovert phase (see

par. ―The technology grid: the key to optimal PHR use and adoption‖, extrovert phase). The method is

aimed at the IT department (and related technical) staff of the HSP that have to be implicated in any

effort towards Health IT maturity of any HSP

Work package

number

6

Work package title

Organic IT Scorecard Monitoring subsystem

Objectives

To develop a functional Balanced Scorecard performance model to diffuse knowledge from

software architects and developers to end-users and vice versa.


30

Academic Partner XX and Health IT company XX design the Balanced Scorecard functional model

custom made for the application area of the FIGHT project

Health IT Company XX installs the *open source* Balance Scorecard reporting software

Patient Networks and Health IT Company XX fine tunes the installation of the BC software


06.01 Self-replicating organic IT deployment for PHR based Health Informatics applications

The scenarios of the FOEG‘s visits (as described in par. ―The technology grid: the key to optimal PHR

use and adoption‖, organic expansion phase) are created based on and enriching the findings of WP05.

The deployment includes any technical related alterations that might appear following the description

of par. ―The technology grid: the key to optimal PHR use and adoption‖, Organic IT

06.02 “A balanced scorecard monitoring system under an organic IT deployment framework”

A balanced scorecard application is undertaken on the scenarios of 06.01 with the purpose of fine

tuning the vertical decision flow bringing awareness on all levels of related staff supporting the FOEGs

visits, ranging from the steering committee of the project to the last FOEG member.

Work package

number

7

Work package title

F.I.G.H.T. network base Integration

Objectives

To expand the FIGHT network

To attract the maximum number possible of candidate FIGHT nodes

To upgrade the software components of the FIGHT to alpha version


Academic partner XX with Health IT Companies design the CMMI appraisal method for the extrovert

phase fine tuning the work done for WP5

Academic partner XX with Health IT Companies design the BS reporting tool for the extrovert phase

fine tuning the work done for WP6

Patient networks organize limited targeted actions attracting HSPs (candidate FIGHT nodes) that are

operating in their domains – mainly their affiliated (or related) General Practitioners and small clinics

rather than Hospitals of the size and magnitude of the project member‘s hospitals

Patient Networks with Health IT Companies coordinate mini-projects for rapid PHR adoption

custom made for the Candidate FIGHT nodes.


07.01 F.I.G.H.T. network base Integration

A full fact finding report on the status of all FIGHT nodes: initial (del. 04.02) and candidate (WPs 6

and 7) will be carried out. The report will update all variables and indicators of the reporting tools both

CMMI and Balanced scorecard and will be accompanied by a) An mid-project evaluation report and b)

31

An mid-project ―Alterations and Alignment‖ action plan

07.02 “PHR Connect” Electronic Marketplace and Interoperability Repository: Alpha Version

The alpha version of del. 04.03


Collaboration Portal: Alpha Version



Collaboration Portal and Digital Library: Alpha Version


07.05 “A Multichannel Asynchronous Information Flow and Verification for Heterogeneous

Health Informatics Systems Interoperability”

The dels of WP03 in the cloud in a unified service

07.06 “A unified SSO web service in a heterogeneous Health Informatics Technology Grid in a

distributed cloud environment”

The del. Of 07.06 in a secured environment

Work package

number

8

Work package title

e-Health Social Marketing PHR adoption framework

Objectives

To embody the discipline of Social Marketing into the projects knowledge base

To investigate the role of social marketing techniques in PHR adoption

To develop a toolbox for any PHR related project that is focused on adoption


Academic Partner XX performs an analysis of facilitators and barriers to PHR adoption, on a regional,

state, and European level

Academic partner XX with Health IT Company XX develop a toolbox for regional, state and

European stakeholders involved in PHR adoption projects

Academic Partner XX performs an analysis of successes and failures of m-health applications in

Europe

Academic partner XX with Health IT Company XX investigate the role of social marketing

techniques in PHR adoption


08.01 “Societal Impact of electronic Health Applications: The breakthroughs perspective”

workshop

A fact finding report accompanied by a comparative study of the core Health Informatics applications

focused on their societal impact. Both EHR/ EMR and PHR sides will be examined from all

stakeholders‘ point of view. EHR/ EMR applications will primarily examined for the impact they

brought to a) HSP staff change of practice and b) the public in general as hospitalized patients

including pre and post hospitalization behavior and impact. PHR applications will be examined from

32

the human centered point of view treating HSPs and the related services as satellite factors of a pure

human centered study of societal behavior and impact including behavioral patterns for post trauma

treatments and treatments for chronic diseases.

08.02 “A policy makers’ toolbox for rapid PHR adoption”

A policy makers‘ toolbox will feature all societal aspects from the impact point of view of the rapid

adoption of PHR technologies. The study will include all levels of governance, regional, state and

European and will provide the policy makers with all crucial decision making documentation and

decision support tools aligned towards measurable benefits for a selected and representative pool of

communities. A comparative study will feature the importance of including patient networks‘

representation and participation in the decision making process from the early stages of policy making.

08.03 “The Societal Impact of m-health applications in Europe”

M-health informatics and services are much easier to adopt services mainly due to the

straightforwardness and simplicity of m-applications in general. The m-Health context will be

examined with emphasis given on the adoption barriers m-health informatics can penetrate based

exactly on their simple technology and business functional models.

Work package

number

9

Work package title

F.I.G.H.T. network “follow me” PHR demonstrations

Objectives

To document the red-tape barriers of rapid PHR adoption on behalf of the HSPs in the project

members‘ regions

To document the red-tape barriers of rapid PHR adoption on behalf of the HSPs in the project

members‘ states

To carry out of a fact finding report on red-tape barriers of rapid PHR adoption on behalf of

the HSPs in the EU

To perform proof of concept measurable results of red-tape barriers of PHR adoption in

specific regions of the EU based on real life patient visits scenarios and metrics from the

Patient Networks to the project members‘ HSPs


Academic partners XX carry out fact finding reports on red-tape barriers of rapid PHR adoption for

project member states regions and states plus for the EU

Patient Networks coordinate on real life patient visits scenarios to produce metrics of their visit

experience to the HSPs focusing only to their maturity to PHR adoption and use


09.01 Red tape obstacles regarding the rapid adoption of PHR Health Informatics Services at

the regional level

A fact finding report dealing with all red-tape barriers that the project had to deal with during the basic

integration of the FIGHT network accompanied by a comparative study of red-tape obstacles of the

first FIGHT nodes emphasizing on locality.

33


the state level



first FIGHT nodes emphasizing on national legislation.


the European level



first FIGHT nodes emphasizing on EU legislation.

09.04 F.I.G.H.T. network “follow me” PHR demonstrations exhibition

Full reports of the FOEGS visits as described in section 1.2 and based on the methods and scenarios of

all previous WPs (depending on the characterization of the HSP they visit: initial or candidate FIGHT

node or non-FIGH node).

Work package

number

10

Work package title

F.I.G.H.T. network sustainable expansion field scenarios implementation

Objectives

To expand the FIGHT network in a sustainable way

To attract the maximum number possible of candidate FIGHT nodes

To upgrade the software components of the FIGHT to beta version


Academic partner XX with Health IT Companies design the CMMI appraisal method for the organic

expansion phase fine tuning the work done for WP5

Academic partner XX with Health IT Companies design the BS reporting tool for the organic

expansion phase fine tuning the work done for WP6

Patient networks organize coordinated campaigns attracting HSPs (candidate FIGHT nodes) that are

operating in their domains – mainly their affiliated (or related) General Practitioners and small clinics

rather than Hospitals of the size and magnitude of the project member‘s hospitals

Patient Networks with Health IT Companies coordinate mini-projects for rapid PHR adoption

custom made for the Candidate FIGHT nodes.


10.01 F.I.G.H.T. network functional prototype

An analytical presentation of the FIGHT network: The FIGHT nodes and the candidate ones. The

presentation will include at least the following: a) Analytical documentation of all procedures followed

for setting up the network: a) CMMI appraisals, b) Balanced Scorecard documentation, c) Guidelines

for HSP staff (both IT and medical), d) Handbooks for PHR Use custom made for each project member

state, e) Policy guidelines for decision makers for all project member states.

10.02 “PHR Connect” Electronic Marketplace and Interoperability Repository: Beta Version

34

The beta version of del. 04.03


Collaboration Portal: Beta Version



Collaboration Portal and Digital Library: Beta Version


10.05 “A flexible Scenario Based Workflow Management method for rapid adoption of foreign

PHR schemas in a hospital’s mainframe management system ”

A unified method following the best practices from the work done to set up the FIGHT network. The

method will be targeted at HSP staff functioning as a handbook for rapid adoption of PHR schemas to

all related audience: board of directors (management), medical staff, technology staff (IT) and others.

10.06 “A Hybrid Unified Software Development Model for both Open Source and Proprietary

Health Informatics distribution channels”

Development of the supporting cloud services

10.07 “Fighting Red Tape obstacles in Health Informatics adoption at the regulatory and

governmental level: Guidance and methodological tools for the regional, state and European

stakeholders”

Guidance and methodological tools for policy makers and executioners. The documentation will

include discrete methods and guidelines for Regional, State and European levels and will be

accompanied by a comparative study for all project member states.

Work package

number

11

Work package title

Case Studies

Objectives

To test the knowledge acquired from the work so far with a wide variety of ―real life‖ case

studies


In the countries where FIGHT nodes are realized and tested, case studies will be performed.

Each case study aims at:

1. a description and analysis of the infrastructure of the country and/or region of the FIGHT node

regarding:

- Data exchange of patient data between health care providers, and Health informatics maturity;

- Data exchange between patients and health care providers (to what extent do patients have

access to their medical data);

- Internet use by patients (different target groups, such as patients with chronic conditions,

patients with low SES) related to health information and health services;

- PHR and eHealth initiatives

- Governmental policy and regulations on health care, health IT (including national standards

for Health informatics systems) and privacy.

- Financial issues (how is health care reimbursed, and how are Health IT innovations

stimulated)

35

2. an analysis of stakeholder perspectives:

- Expectations and experiences of patients who have a PHR, or would like to have one;

- Expectations and experiences of health care providers (e.g. regarding patient-doctor

relationship)

- Perspective of stakeholder groups such as patient organizations and health insurers

The case studies use mainly qualitative methods, such as document analysis, interviews and focus

groups.

The results of the case studies will be input for the other work packages, especially the WPs that

deliver the toolbox.


Contribution by the Netherlands team

Work package

number

12

Work package title

Dissemination Activities

Objectives

To diffuse knowledge acquired by the project by means of scientific workshops and confeenes


Coordinator Partner organizes the workshop and the conferences

All partners contribute to the workshop and the conferences of the project


12.01 A initial setup of prototype PHR centric Health Informatics

An analytical report of the ICT technology used to attain human centric / PHR Health Informatics

applications for the FIGHT network initial setup. All ICT technology entities will be examined stating

the rationale of the particular set up, the core and complimentary know-how demanded for the

endeavor, the architectural choices for both the grid itself and the software modules of the cloud

services, the particularities of information sharing and security focusing on the use case of the ―patient

consent‖ use case etc.

12.02 F.I.G.H.T. network initial setup stakeholders’ workshop

A two days international Health informatics workshop will be held to discuss with international

Health Informatics experts the findings of del. 11.01

12.03 “PHR-centric European Technology Grids” Conference A

A mid-term Conference will be held to present the mid-term result of the project as long as the main

challenges and breakthroughs of the project team up to that point of time.

12.04 “PHR-centric European Technology Grids” Conference B

The final Conference of the project

36

Section 2. Implementation

2.1 Management structure and procedures

Principals

Agile project management: this requires putting in place an infrastructure to allow partners to

communicate (blog and mailing list for informal communication, wiki and shared documents for

structured collaboration, ―subversion‖ tools for version control of all types of internal documents,

deliverables and software produced in the course of the project) and a project management

environment (to allow for measured tracking of the progress in time and in budget of the project, as

well as specific tools such as for bug-tracking); following the progress and assessing the results

(through measured criteria as well as feedback from users); coordinating remote (teleconferencing)

and physical meetings between the partners and when needed with external groups (such as users, or

clustering meetings); reporting (to the partners, to the Commission); conflict identification and

resolution.

Legal framework: this includes collecting precise information concerning actual contents held and

which could be provided, in total or in part, by the partners content providers; determine the

stakeholders (patient organizations) in each country with whom existing and future partners have to

negotiate; provide recommendations for various technical implementations that could be proposed to

the stakeholders in order to obtain more advantageous distribution rights (excerpting audio,

streaming, etc.).

Implementation framework: this includes surveying the existing systems holding the HSPs.

Usability studies: they include analyzing existing uses (see ―metadata modeling‖ above); analyzing

the uses of the implemented framework once it is put in place; constituting a users‘ advisory group

(patient networks to comment on the recommendations of the consortium.

Dissemination: as soon as specific results become available, such as the common model, partners

will coordinate their dissemination activities: selection of conferences in which to propose specific

workshops and other presentations; of workgroups to which to send representatives; of targeted

mailings of information on the project and on the requirements to join it.

Steering Committee

A Steering Committee will be appointed by the partners of the project. All partners will be represented in

this committee lead by the project coordinator (PARTNER 1). The steering committee will appoint a

project manager to carry out the project control procedures.

Project manager

The project manager will be responsible for the integrity of the project work plan. The project manager

will be operating with the help of two assistant project managers, one responsible for the internal

communications (among the partners) and the other for the external communications (the dissemination

activities). The project control procedures are as follows:

Project Control Procedures

37

A Project plan document and a Project log will be created and Project control procedures will be

described in respective sections. This allows precise adjustment of these procedures to project scale,

organization and other project specific requirements.

Quality Control

A quality control procedure will ensure that the product meets the expectations of all interested

parties. It will be composed of the following elements:

numeration of quality standards relevant for the project

Scope and procedure of planned reviews (document reviews, code reviews, project reviews)

Description of planned testing

Unit tests, usually performed by developers

System tests, performed by QA department according to Test Plan document

Performance tests (environment, assumptions, tools applied)

Procedure of using issue tracking tools

Progress Control

Regular project team meetings will be held producing progress reports on a weekly, monthly and

quarterly basis.

The agenda of each meeting will include:

Status of the last week‘s action items

Status of each project member‘s tasks

Important events that occurred the previous week

Planning action items for the current week.

The consortium coordinator is responsible for the preparation of the monthly status report and

sending the report to the Steering Committee members. The report will highlight progress over

the reporting period, any issues that have arisen, forecast milestones, and expected progress over

the next reporting period.

Communication flow and documentation

The Coordination Team will meet all WP leaders and Team Managers by multiple teleconferencing at

least every two months, where they will report on the progress of the project and discuss important issues.

Communication will be aided by face-to-face meetings in accordance with travel plans. These reports and

content of project meetings will be the basis for bi-monthly reports from the project coordinator to the

EC.

Participants will be encouraged to work under short-term arrangements at the headquarters of different

partners. The mobility of developers will facilitate integration and communication, and has already been

shown to be effective in prior EU projects. A schedule will be devised and these internships, typically of 1

to 2 months will be arranged based on practicality and need.

A restricted mailing list has been operative since the inception of the project, and will be used for generic

day-to-day communication. More focused lists will be organized as soon as the main flows of specific and

technical communication (for example: integration issues, user management issues, etc.) have been

identified.

The project will be managed by means of a web-based collaborative space with the appropriate

organizational structure and access restrictions. This will make it possible to share calendars and issue

reminders for periodic events (reports, conference deadlines, etc.). Office software will be used to track

the project status, including maintenance of Gantt charts and accounting spreadsheets. Document drafts

may be edited by relevant partners with the use of version tracking facilities.

38

A secure code repository will be set up at the project kick-off. WIKI tools will be used for collaborative

document development and discussion. The repository will not be publicly accessible during the project,

though repositories will be made accessible to the public as an outcome.

A Consortium Agreement will be signed by all the partners before the outset of the project. This will

cover in detail issues, exploitation, and responsibilities.

Conflict Resolution

The project has been carefully prepared as a collaborative effort from all partners in order to prevent

conflicts between them. Forthcoming documents will be created with the same attitude and purposes.

Nevertheless, if problems arise, they will be reported to the project manager as early as possible. If

necessary, the Steering Committee will be called. Conflict resolution will be approached by consensus or,

if necessary, by voting. In the case of irreconcilable disputes, the conflict procedures that will be

described in the Consortium Agreement will be adopted.

Change management

A change control procedure will control the addition of work to the originally planned activities

in order to achieve a balance between the need to improve quality by changing the project

cThese and the need to successfully complete the activities as scheduled.

An issue becomes a subject of the change control procedure whenever coordinator of the

consortium identifies it as a change in the project scope, schedule or budget. The change control

procedure will be comprised of the following steps:

Submission of a change request and identification of its scope

Agreement about possible impact of the change for the project scope, schedule and budget

Decision about acceptance or rejection of the change followed by, if necessary (i.e. if

tolerance parameters are exceeded), an update of the project schedule and or budget

Implementation of the accepted change by the project team

The procedure also defines people (roles) responsible for each step. All steps are documented in

the Project Log document.

Risk Management

Risk management procedures are documented and supported with the use of the Project Log.

The risk information is updated at least biweekly. Activities performed within the procedure are

summarized below.

Risk Assessment

Item Description

Risk

identification

List of risks that can potentially jeopardize project cost and/or

schedule

Risk analysis Assessment of the risk to the cost and schedule of the project

Risk

prioritization

List of risks that need to be dealt with first in order to minimize

their impact

Risk Control

Item Description

Risk

management

planning

Defining planned actions for each individual risk

39

Risk resolution Executing planned actions to mitigate risks

Risk monitoring Monitoring status of each risk resolution

Quality Assurance Plan

A Quality Assurance (QA) Plan will be applied to all internal and external services and deliverables.

Quality assurance is the joint responsibility of all partners during the project lifetime. The goal of the QA

plan is to ensure detection of errors as early as possible, applying planned and systematic activities to

determine and ensure achievement of quality objectives. Non-conformance to QA Plan will be

documented, and corrective actions applied.

The project manager has the authority for implementing and verifying compliance with all quality

evaluation policies and procedures related to the project. The following is a non-exhaustive list of QA

tasks that will be performed:

Develop the QA Plan, develop QA project instructions, procedures, checklists and reports.

Monitor project development to ensure that initial project goals are met in time and on budget.

1. Review internal and external deliverables for consistency, clarity, content, and adherence to the QA

plan. An internal review process will be defined and applied to each deliverable prior to its delivery to

the EU.

2. Conduct audits of processes prior to each development phase of the project, and assure existence of

specifications for each phase.

QA documentation will be maintained electronically and be accessible by partners through the collaborative

software tool that will be adopted, and also through the restricted web site pages.

Section 3. Impact

3.1 Expected impacts listed in the work programme

Health care now needs leaders who are able both to anticipate and manage strategic organizational change

incorporating appropriate information and communication technologies. They must be able to establish

an effective ‗fit‘ between the needs of clinical work, the health care system and information and

communication technologies.

Research and evaluation studies have shown how difficult it is to integrate such rapidly developing

information and communication technologies, not only into clinical practice but also at the operational

level.

Identifying information requirements, choosing, procuring and implementing such rapidly developing

technologies have a social as well as a technical dimension. It is only relatively recently that the extent of

this social and individual dimension has been recognized as critical to the successful implementation of

health and medical systems and the realization of their benefits. This philosophy underpins the design of

the programme which brings together elements of technical, clinical and organizational issues in a

pragmatic framework.

In all aspects of health care it is recognized as good practice and ethically important that technologies,

methods, and interventions are evidence-based. In other words, that they are proven to be safe and

effective, against other methods and alternative solutions.

40

When it comes to decisions whether and how best (if at all) to use IT systems for a particular task in the

health care delivery process, opportunities and options can only be appraised objectively by reference to

scientific evidence. This is dependent on the building up of a body of published scientific findings, which

is currently sadly lacking in volume and coverage given the importance and impact of health informatics

on modern healthcare practice and delivery.

There was a growing list of failed efforts to realize the benefits of IT in healthcare in the recent years,

unfortunately this continues to be true. There are numerous reasons for this including the following gaps:

People gap: A shortage of skilled Health Informatics professionals to assist in planning and

implementing health information systems and health information management strategies. At

present, demand exceeds the supply of Health Informatics professionals. The historical

investments in health IT have not had any significant prior investment in developing a stable and

skilled Health Informatics workforce. The potential available budgets for current projects

represent a workload well in excess of that supportable by the available pool of Health

Informatics professionals.

Decision Maker Skills Gap: despite the increasing number and scope of IT based initiatives in

healthcare, many health care administrators and government decision makers have little

understanding of success factors and risks in Health Informatics projects, nor is there a clear

understanding of the skills required to support these projects in delivering on time, on budget with

systems that represent real improvements in efficiency and safety.

Implementation gap: Consequently, there is a variable skill level in those that do become

involved in Health Informatics projects. Project failure is often related to poor implementation,

reflecting an absence of mature experience in deployment of complex information systems in the

health setting.

Change management gap:-Many projects fail as insufficient study of workflow has taken place

especially in clinical settings. Clinicians won‘t use systems when additional time is required for

making use of the system or where a change in work practice is required unless they fully

appreciate the benefits.

Research gap: Projects also fail because they break basic Informatics ‗rules‘. Many, for example,

are implemented in the mistaken belief that ‗technology‘ is the answer, rather than first focusing

on problem definitions at a system level, and evolving appropriate information solutions,

grounded in the science of informatics. Health Informatics is relatively young as a formalised

discipline, and the basic Health Informatics ‗rules‘ are necessarily a work in progress. There is

thus a very real need to foster research

Clinical education gap: Clinically, there is also a growing need for individuals to develop skills in

Health Informatics. Specifically, health professionals need to be trained in new information

technology skills, both to successfully harness the benefits of the new technologies, as well as to

adopt evidence-based and safe work practices. The consequence of a clinical workforce that is

under skilled in core informatics techniques like evidence-based information retrieval, use of

computerised prescription systems or electronic medical records, or communication technologies

like email or the Web, means that many options for widespread system improvement are

hampered.

Changes that the present project may bring should entail the following:

A major shift towards systems that serve patients and the public to help them to stay healthy, drive better

care, improving outcomes, innovation and the better use of resources. Transforming the way information

is collected, analysed and used by the EU and health care services.

The focus on outcomes will align efforts across the EU health care services on what really matters:

improving the lives of patients and service users. A culture of a responsible safety and accountability

policy against outcome measures will need to draw upon open, accessible information from a range of

sources.

41

The publication of the research results both locally and nationally will be more freely available to

encourage innovative information providers, such as patient and service user charities, to better inform

the public. Some indicative use cases that promote societal impact of the present project should be:

a. Monitor health status to identify community health problems.

b. Diagnose and investigate health problems and health hazards in the community.

c. Inform, educate, and empower the public about health issues.

d. Mobilize community partnerships to identify and solve health problems.

e. Develop policies and plans that support individual and community health efforts.

f. Enforce laws and regulations that protect health and ensure safety.

g. Link people to needed personal health services and assure the provision of services that

promote health when otherwise unavailable.

h. Monitor health status to identify community health problems.

i. Diagnose and investigate health problems and health hazards in the community.

j. Inform, educate, and empower the public about health issues.

k. Mobilize community partnerships to identify and solve health problems.

l. Develop policies and plans that support individual and community health efforts.

m. Enforce laws and regulations that protect health and ensure safety.

n. Link people to needed personal health services and assure the provision of services that

promote health when otherwise unavailable.

Furthermore, an indicative list of follow jup research based on the result of the present project is the

following:

Biostatistics – the development and application of statistical reasoning and methods in addressing,

analyzing, and solving problems in public health; health care; and biomedical, clinical, and

population-based research.

Environmental Health Sciences – the study of environmental factors including biological,

physical, and chemical factors that affect the health of a community.

Epidemiology – the study of patterns of disease and injury in human populations and the

application of this study to the control of health problems.

Health Policy and Management – a multidisciplinary field of inquiry and practice concerned with

the delivery, quality, and costs of health care for individuals and populations, assuming both a

managerial and policy concern with the structure, process, and outcomes of health care services

including the costs, financing, organization, outcomes, and accessibility of care.

Social and Behavioral Sciences – the behavioral, social, and cultural factors related to individual

and population health and health disparities over the life course, including research and practice

that contributes to the development, administration and evaluation of programs and policies in

public health and health services to promote and sustain healthy environments and healthy lives for

individuals and populations.

Communication and Informatics – the ability to collect, manage, and organize data to produce

information and meaning that is exchanged by the use of signs and symbols; to gather, process and

present information to different audiences in-person, through information technologies, or through

media channels; and to strategically design the information and knowledge exchange process to

achieve specific objectives.

Diversity and Culture – the ability to interact with diverse individuals and communities to

produce or impact an intended public health outcome.

Leadership – the ability to create and communicate a shared vision for a changing future;

champion solutions to organizational and community challenges; and energize commitment to

goals.

Professionalism – the ability to demonstrate ethical choices, values and professional practices

implicit in public health decisions; consider the effect of choices on community stewardship,

equity, social justice and accountability; and to commit to personal and institutional development.

42

Program Planning – the ability to plan for the design, development, implementation, and

evaluation of strategies to improve individual and community health.

Public Health Biology – the biological and molecular context of public health.

Systems Thinking – the ability to recognize system level properties that result from dynamic

interactions among human and social systems and how they affect the relationships among

individuals, groups, organizations, communities and environments.

Section 4. Ethical Issues

General Principles of Informatics Ethics

These fundamental ethical principle, when applied to the types of situations that characterize the

informatics setting, give rise to general ethical principles of informatics ethics.

1. Principle of Information-Privacy and Disposition

All persons have a fundamental right to privacy, and hence to control over the collection, storage, access,

use, communication, manipulation and disposition of data about themselves.

2. Principle of Openness

The collection, storage, access, use, communication, manipulation and disposition of personal data must

be disclosed in an appropriate and timely fashion to the subject of those data.

3. Principle of Security

Data that have been legitimately collected about a person should be protected by all reasonable and

appropriate measures against loss, degradation, unauthorized destruction, access, use, manipulation,

modification or communication.

4. Principle of Access

The subject of an electronic record has the right of access to that record and the right to correct the record

with respect to its accurateness, completeness and relevance.

5. Principle of Legitimate Infringement

The fundamental right of control over the collection, storage, access, use, manipulation, communication

and disposition of personal data is conditioned only by the legitimate, appropriate and relevant data-needs

of a free, responsible and democratic society, and by the equal and competing rights of other persons.

6. Principle of the Least Intrusive Alternative

Any infringement of the privacy rights of the individual person, and of the individual‘s right to control

over person-relative data as mandated under Principle 1, may only occur in the least intrusive fashion and

with a minimum of interference with the rights of the affected person.

7. Principle of Accountability

Any infringement of the privacy rights of the individual person, and of the right to control over person-

relative data, must be justified to the affected person in good time and in an appropriate fashion.

These general principles of informatic ethics, when applied to the types of relationships into which HIPs

enter in their professional lives, and to the types of situations that they encounter when thus engaged, give

rise to more specific ethical duties. The Rules of Conduct for HIPs that follow outline the more important

of these ethical duties. It should be noted that as with any ethical rules of conduct, the Rules cannot do

43

more than provide guidance. The precise way in which the Rules apply in a given context, and the precise

nature of a particular ethical right or obligation, depends on the specific nature of the relevant situation.

A Code of Ethics for medical staff

Codes of professional ethics serve several purposes:

to provide ethical guidance for the professionals themselves,

to furnish a set of principles against which the conduct of the professionals may be measured, and

to provide the public with a clear statement of the ethical considerations that should shape the

behaviour of the professionals themselves.

A Code of Ethics should therefore be clear, unambiguous, and easily applied in practice. Moreover, since

the field of informatics is in a state of constant flux, it should be flexible so as to accommodate ongoing

changes without sacrificing the applicability of its basic principles. It is therefore inappropriate for a Code

of Ethics to deal with the specifics of every possible situation that might arise.

The patient is in a vulnerable position, and any decision regarding the patient and the EHR must

acknowledge the fundamental necessity of striking an appropriate balance between ethically justified ends

and otherwise appropriate means. Further, the data that are contained in the EHR also provide the raw

materials for decision-making by health care institutions, governments and other agencies without which

a system of health care delivery simply could not function. The medical staff therefore, by facilitating the

construction, maintenance, storage, access, use and manipulation of EHRs, play a role that is distinct from

that of other informatics specialists.

At the same time, precisely because of this facilitating role, medical staff are embedded in a web of

relationships that are subject to unique ethical constraints. Thus, over and above the ethical constraints

that arise from the relationship between the electronic record and the patient, the ethical conduct of

medical staff is also subject to considerations that arise out of the medical staff s‘ interactions with Health

Care Professionals (HCPs), health care institutions and other agencies. These constraints pull in different

directions. It is therefore important that medical staff have some idea of how to resolve these issues in an

appropriate fashion. A Code of Ethics for medical staff provides a tool in this regard, and may be of use in

effecting a resolution when conflicting roles and constraints collide.

Duties towards HCPs

HCPs who care for patients depend on the technological skills of their staff in the fulfilment of their

patient-centred obligations. Consequently, medical staff have an obligation to assist these HCPs insofar

as this is compatible with the medical staff‘ primary duty towards the subjects of the electronic records.

Specifically, this means that

Assistance to patients

a. to assist duly empowered HCPs who are engaged in patient care in having appropriate, timely and

secure access to relevant electronic records (or parts of thereof), and to ensure the usability,

integrity, and highest possible technical quality of these records; and

b. to provide those informatics services that might be necessary for the HCPs to carry out their

mandate.

Collaborate with the HCPs’ IT Staff

Medical staff should keep HCPs informed of the status of the informatics services on which the HCPs

rely, and immediately advise them of any problems or difficulties that might be associated or that could

reasonably be expected to arise in connection with these informatics services.

44

a. Medical staff should advise the HCPs with whom they interact on a professional basis, or for

whom they provide professional services, of any circumstances that might prejudice the

objectivity of the advice they give or that might impair the nature or quality of the services that

they perform for the HCPs.

b. HIPs have a general duty to foster an environment that is conducive to the maintenance of the

highest possible ethical and material standards of data collection, storage, management,

communication and use by HCPs within the health care setting.

Intellectual Property

Medical staff who are directly involved in the construction of electronic records may have an intellectual

property right in certain formal features of these records. Consequently, HIPs have a duty to safeguard

a. those formal features of the electronic record, or

b. those formal features of the data collection, retrieval, storage or usage system in which the

electronic record is embedded in which the HCP has, or may reasonably be expected to have, an

intellectual property interest.

Personal data for public good: using health information in medical research

Respect for private life and confidentiality

The fundamental right to respect for private life and the legal obligation of confidentiality protect the

dignity, autonomy and reputation of citizens, spare them unwanted intrusion, and preserve their trust in

the medical system. Various EU member states‘ law endorses all these reasons for the protection of

confidences and privacy in health care. However, it draws attention to the need to focus in a close and

exacting way on other public interests, in particular the public interest in secondary data research—that is,

research based on data originally collected for a purpose other than research which does not involve

interaction with the patient.

Secondary data Research

Secondary data research identifies important causes of disease and epidemics, demonstrates the long-term

effects of treatment, and helps improve the provision of services. Its secondary nature means that very

large numbers of patients can be studied with complete coverage of particular populations, producing

more reliable results. The duration and costs of the research are also reduced relative to ‗primary‘

research. The area of research most affected is large scale epidemiological studies.

Difficulties with Consent

Research often takes place at a distance, both temporally and geographically, from the collection of the

data. As a result, the person communicating with the subject is probably someone other than the

investigator (thus in a poor position to seek consent) and the issues warranting research may not be

known until later.

Difficulties with Full-Anonymisation of Data

Full-anonymisation is often impracticable because identifiable data is needed to assess/avoid double-

counting, for longitudinal research which adds data to existing records, for linkage between data sets, to

validate data by cross-checking a sample of electronic records against paper records, when identifiers

contain information useful to the research (e.g. postcodes, ethnic origins of a surname), when

anonymisation is too laborious, and when the data is unusual (e.g. rare diseases). The burden of

constructing and managing partially anonymised data sets is considerable, and often determines the

quality of the subsequent research.