FIGHT4PHR, a Health IT Project Proposal

< 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

1

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

2

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.

3

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:
4

 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:

5

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
6



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.

7

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
8



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.

9

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
Citizens (and patients) as the ―PHR owners‖
Health provider staff
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)
a.
b.
c.

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

10

the tools that will be used to support the Service Establishment and Delivery of EHR/ EMR to PHR
connectivity is following:
Strategic
Service
Needs
Service
Catalog

STSM

Service
Requirements

Deployed
Service
System

SST

Service
Issues

Service Service
Value Requests
Request
Status

Contract / Service
Agreement
Service
Catalog

Service
Requirements

SSD

IRP

Incident
Response
Information

SD

Operations and
Service Delivery
Data

Validated
Service
System

Standard
Service
Requirements

Incident
Status

Customer/End User

Transition
Plans

Corrective
Actions

Revised Resource
Constraints and
Service Thresholds

Service
Requirements

Process Areas for
Managing Services
IRP = Incident Resolution and Prevention
SD = Service Delivery
SSD = Service System Development
SST = Service System Transition
STSM = Strategic Service Management

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 CMMISVC, 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
11

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.

2.
3.
4.

5.

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.
The PHR electronic file in a structured form (indicatively as collection of CCD‘s)
Other PHR related files. These files are of great importance for both emergency situations and PHR
adoption scenarios (as explained below)
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)
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):
Embedment of the new data to the structured PHR file
Initiation of a series of alerts to medical staff, payer staff etc
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)
a.
b.
c.

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.

12

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”:
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:
1.

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):
a.

At any region of an EU country there are:
1.
2.
3.

The local Health Provider (a clinic and / or a diagnostic center)
An Academic / Research Institution of the region / country
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:
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)
1.

13

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

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.
The Patient visits the Health Provider following an acute incident.
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).
1.
2.

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
14

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

1
No IST present

Documented proof
of the service
provided (i.e. a
receipt)

2
Limited use of
IST (office
apps, email)

Contact details of
the Health
Providers‘ IT staff

FIGHT “smart card”
device components’ use

The imprinted social
security number
security number
Possible use of the
―public‖ space of the drive

15

Suggested Follow up actions
(coordinated by patient networks)
Telephone communication to arrange
meeting with a legal representative and
try to initiate an ―introvert‖ phase
Telephone communication to arrange an
informative meeting and try to retrieve
relevant patient‘s electronic records.
Establish Electronic communication via

for information retrieval

mail with all necessary documentation
for the information retrieval process

security number

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

3
Extensive use
of office apps
but no use of
Health IT apps
(EHR, EMR,
PHR)

Contact details of
the Health
Providers‘ IT staff

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

Possible use of the
―public‖ space of the drive
for information retrieval

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:
The Software Components of the Smart PHR Drive
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.
1.
2.

16

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

17

WORK
Complementarities

Pillar 1: Knowledge
Base and Initial
Setup

Pillar 2: Development
and Integration

Pillar 3: Expansion and
Sustainability

WP01
WP02

WP01
WP05
WP06

WP01
WP09

WP02
WP03
Academic Research
WP04
WP11

WP05
WP06

WP08

Software Vendors /
Integrators

WP05
WP06
WP07

WP09
WP10

WP07

WP08
WP09
WP10
WP11
WP12

Pillars / Partners
Project
Coordinator and
Technical
Consultants

Patient Networks

WP02
WP03

WP04

PROJECT VALUE
EU citizens

Academics /
Researchers

Health
Professionals

IT Industry

Get on-thespot health
services

N/A

Provide on-thespot health
services

Support on-thespot health
services

Follow-me Health
Data

Get on-thespot health
services

N/A

Provide on-thespot health
services

Support on-thespot 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

Publish Reports,

Publish Reports,

Euterpe

Get
information
about Points
Of Service

Publish
Papers

Get state-of-art
scientific info

Get state-of-art
scientific info

Research Papers

N/A

Get state-ofart scientific
info

Get state-of-art
scientific info

Get state-of-art
scientific info

Stakeholders /
Outcomes
F.I.G.H.T.
network

18

Work plan
WPs / MOs
WP01

WP02

WP03

WP04

WP05

WP06

WP07

WP08

WP09

WP10

Project
Management
Health
Informatics PHR
centric
Framework
Ontology
A distributed
Event Driven
User Interface
software layer for
Health Data
Entry,
Sustainability and
Interoperability
F.I.G.H.T.
network initial
setup
Scenario Based
Workflow
Management
module
Organic IT
Scorecard
Monitoring
subsystem

3

6

9

12

15

21

WP12

27

31

02: 1 - 31

03: 1- 25

04: 2 - 12

05: 3 - 25

06: 3 - 35

07: 12 - 24

08: 9 - 35

09: 15 - 35

11: 24 – 35

06: 12 - 35

WP11

24

01: 0 – 36*

F.I.G.H.T.
network base
Integration
e-Health Social
Marketing PHR
adoption
framework
F.I.G.H.T.
network “follow
me” PHR
demonstrations
F.I.G.H.T.
network
sustainable
expansion - field
scenarios
implementation

18

Case Studies

Dissemination
Activities

10: 12 - 36

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

19

34

36

List of Deliverables

(44 deliverables out of 12 work packages)

Del.
no.

WP
Deliverable name

no.

Dissemi- Delivery
Nature

nation

date(proj.

level

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

20

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


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

21

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

22

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

stakeholders‘ workshop

11

RTD

PU

18

11.03

―PHR-centric European Technology
Grids‖ Conference A

PU

24

11.04

―PHR-centric European Technology
Grids‖ Conference B

PU

36

RTD
11

OTHER
RTD

11

OTHER

Work package description

Work package
number
Work package title

1

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
23

o
o
o

Financial Management
Quality Assurance
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
Work package title

2

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
24

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
Work package title

3

A distributed Event Driven User Interface software layer for Health Data
Entry, Sustainability and Interoperability

Objectives

25






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
26

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
Work package title

4


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
27

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
Work package title

5

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
28

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
Work package title

6

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.


29

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
Work package title

7


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)
30

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
Work package title

8

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
31

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.

9
Work package
number
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.

32

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
Work package title

10

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
33

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
Work package title

11

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)
34

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
Work package title

12

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

35

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

36

FIGHT4PHR, a Health IT Project Proposal

FIGHT4PHR, a Health IT Project Proposal

Recommended

Recommended

More Related Content

What's hot

What's hot (7)

Viewers also liked

Viewers also liked (7)

Similar to FIGHT4PHR, a Health IT Project Proposal

Similar to FIGHT4PHR, a Health IT Project Proposal (20)

More from Nick Glezakos

More from Nick Glezakos (14)

Recently uploaded

Recently uploaded (20)

FIGHT4PHR, a Health IT Project Proposal