1
< Project Proposal:
An ICT project for Rapid Adoption of PHR in EU>
< FP7-ICT-2011-7, Challenge 5: ICT for Health, Ageing Well, Inclusion and
Governance >
Proposed title: F.I.G.H.T. for PHR
Flexible Interoperable Grid of Health Technologies for Personal Health Record
2
Table of Contents Scientific and/or technical quality, relevant to the topics addressed by the call .......................................................... 3
Section 1. Concept and objectives ............................................................................................................................ 3
Introduction .......................................................................................................................................................... 3
Vision .................................................................................................................................................................... 4
Scope .................................................................................................................................................................... 4
Objectives ............................................................................................................................................................. 4
Outline .................................................................................................................................................................. 5
Active connection between basic research work and tangible outcomes ........................................................... 5
Outcomes ............................................................................................................................................................. 6
2. Progress beyond the state-of-the-art ................................................................................................................... 8
Interdisciplinary research for IST intensive work ................................................................................................. 9
State of the Art Roll Out Methods ........................................................................................................................ 9
Setting up the target: Patient Oriented Digital Services ....................................................................................... 9
PHR: an electronic service adopted and in use, not just an electronic record ................................................... 10
Organic IT ............................................................................................................................................................ 10
The use of CMMI for FIGHT network nodes creation ......................................................................................... 10
The use of Balance Scorecard for Organic IT software performance measurement and FIGHT Expansion ....... 11
An innovative approach for PHR use: the “Smart PHR Drive” ............................................................................ 12
The technology grid: the key to optimal PHR use and adoption ........................................................................ 13
Research Focus ................................................................................................................................................... 16
3. S/T methodology and associated work plan ....................................................................................................... 17
Work allocation .................................................................................................................................................. 17
Work plan ........................................................................................................................................................... 19
Section 2. Implementation .......................................................................................................................................... 36
2.1 Management structure and procedures ........................................................................................................... 36
Communication flow and documentation ........................................................................................................... 37
Conflict Resolution ............................................................................................................................................. 38
Quality Assurance Plan ...................................................................................................................................... 39
Section 3. Impact ......................................................................................................................................................... 39
3.1 Expected impacts listed in the work programme ............................................................................................. 39
Section 4. Ethical Issues ............................................................................................................................................... 42
General Principles of Informatics Ethics ............................................................................................................. 42
A Code of Ethics for medical staff ....................................................................................................................... 43
Duties towards HCPs .................................................................................................................................................. 43
Personal data for public good: using health information in medical research ............................................................. 44
3
Scientific and/or technical quality, relevant to the topics addressed by
the call
Section 1. Concept and objectives
Introduction
The Personal Health Records promise has been around for quite some time now, yet to fulfill its destined
purpose: personal health data, at the time and place of need beyond any geographical borders seamlessly
connected and interoperable with any Health related service providers/ systems. And there is still a long
way to go since adoption of PHR technology presents considerable challenges, the most important of
them being the following:
Technological Interoperability among Health IT Systems
Although considerable work has been carried out at the level of standards there is an even
growing need for intermediate enterprise (and cross national) systems that facilitate the
interoperability at stake.
The end users are yet to feel the ―safe harbor‖ feeling concerning PHR services. This is mainly due
to
Inadequate implication of end users to technology solutions design that make end users feel
distant and alienated the moment the technology is being presented to them
Ethical Issues: Data sharing and security. The nature and importance of medical data for each
and every one of the citizens demand crystal clear solutions (technological methods, business
models etc.) and equally crystal clear communication concerning data security and information
sharing. Currently these crystal clear solutions have yet to be communicated accordingly to the
general public.
Compliance of use according to national legislations
Law and regulations that address the use and adoption of PHR services are totally different from
state to state within the EU. To make matters more complicated interpretation of these laws and
regulations among HSPs is varied (even within the same state). The latter becomes more
complicated by the growing demand of the citizens for participatory health and shared decisions
Entrepreneurship on behalf of SME and individual software developers has yet to be triggered
Active participation from developers‘ communities (SMEs and individuals) have proven
indispensable in other more mature ICT areas such as the ones of CMS systems, Productivity
applications, Community games etc.
The present proposal introduces research that addresses all of those challenges in a unified way:
Technological Interoperability is dealt creating a technology grid that expands from HSP to HSP by
maturing their processes and technologies with the least possible effort. Work is done simultaneously
at ground level (the HSP Health IT applications) and on the Internet (supporting web services)
Software Design is studied from its infancy along with the end users that are formally represented
by patient organizations and networks coming from a variety of EU countries and relating to various
health conditions.
Compliance to law and regulations is embedded in structured methods and techniques of
technological maturity and social marketing research that leads to methods and tools for policy
makers
Entrepreneurship is addressed by offering technology tools for collaborative work decoupled from
the strict HSP IT environment.
4
Vision F.I.G.H.T. for PHR aspires to pave the way for seamless interoperability of a citizen’s PHR to the
maximum number of HSPs and Health Services in general beyond technical, red tape and other digital
divergence barriers.
The project furthers research in the IST area of Personal Health Records and specifically in the way a
European Citizen‘s PHR electronic service can support any physical transaction between a European
Citizen and a Health Service Provider (HSP).
To provide a “live” test bed of such a broad scope of research the project creates a Health Informatics
Technology Grid (the F.I.G.H.T. for PHR) that is strategically designed to innovatively establish and
expand itself from one Health Service Provider (HSP) to another providing seamless connectivity
between the HSPs’ Health IT Systems and the citizens’ PHRs relieving the demand for a unique
PHR electronic card.
Every time such connectivity is attained, the HSP at hand joins the FIGHT network as a FIGHT node.
The expansion of the F.I.G.H.T. network is based on dynamic roll out methods that are designed to
provide that seamless HSP to PHR connectivity with the least possible effort concerning HSP
Reengineering, Technology and Red Tape barriers. The whole process is governed by a custom made
CMMI maturity method for Health IT services and feeds a Balanced Scorecard reporting service that
―runs‖ the FIGHT network horizontally diffusing knowledge from one node the next (candidate) one.
Scope
The project scope of the F.I.G.H.T. network involves partners from 9 European Countries covering all
feasible partner categories of such an endeavor (Academic and Research Partners, Health Informatics
SMEs, Patient Organizations and Networks, Medical Associations of national and regional character,
Hospitals, Medical Care Partners etc.). At its initial phase the first setup of the FIGHT nodes is being
created in HSPs in Greece and the Netherlands. After the executions of the roll out methods, and counting
FIGHT nodes in all of the 9 countries that the project has official representation, all partners re
coordinated towards the core target of the project (seamless PHR interoperability) by organizing multiple
trips of FIGHT Organic Expansion Groups (FOEGs. These groups include research associates and
representatives from patient organizations around Europe (and within the F.I.G.H.T. network European
State Members). They follow a comprehensive multidimensional scenario which pools from a rich variety
of Health Provision Services and utilizes an electronic ―Health Card‖ device. Initially, each FOEG
member is provided by such a device which, according to the scenario, varies among USB flash drives,
existing PHR/ PHR related smart cards, simple membership plastic cards etc. Then, FOEG visits in
various European cities are carried out featuring carefully designed personalized patterns for each FOEG
member. These personalized patterns include all typical patterns of real life medical situations like
emergencies, prescheduled visits, hospitalization etc. with some of them even describing a ―loss of the
card‖ scenario). The use case of the device by the FOEG members (in all of the aforementioned
scenarios) is designed in an innovative way that leaves a ―trace‖ to the Health provider that hosted the
scenario incident – a ―trace‖ carefully designed to ease that Health provider‘s effort towards their
maturity for Health IT services.
Objectives The F.I.G.H.T. for PHR features the following main objectives:
Create a fully operational European Network (a prototype technology grid infrastructure) that
provides seamless connectivity to Health Informatics systems that support medical services to
European citizens relieving the demand for a unique PHR electronic service
Develop specific ―hands on‖ methods and tools, custom made for each European Member State
of the F.I.G.H.T. network, that describe specific and detailed action plans of the ―flexible
adaptation scenario for any PHR Health Card‖ covering the political, governmental, technological
and managerial domains
Provide all plausible policy and decision makers with guidelines, methods and tools designed for
rapid expansion of the F.I.G.H.T. prototype network at a regional, national and European level
Other important objectives are:
5
Diffuse knowledge in a coordinated way concerning all aspects that are involved in rapid PHR
technology adoption utilizing a new electronic library collaborative service designed for Health
and e-Health professionals as long as for general EU public
Promote entrepreneurship for Health Informatics by setting up the technology infrastructure for
software developers that supports collaborative creation and promotion of interoperability
software tools
Outline
Combining basic research with fully functional software prototypes, F.I.G.H.T for PHR furthers basic
research work from multiple disciples and formulates the research outcomes into citizen centric
personalized electronic / web services. This much needed functional connection between
multidisciplinary basic research and tangible prototypes of personalized electronic / web
applications and services is illustrated in the following graph:
Active connection between basic research work and tangible outcomes
All research papers are targeting at developing the aforementioned innovative roll out methods and
related tangible outcomes. As the whole project is strategically aligned towards its outcomes, work
allocation and roll out methods result to specific tangible research prototypes (software applications and
services at ―beta versions‖ phase). The semantic interrelations among the basic research work of the
project and the tangible outcomes‘ features is illustrated in the following graph:
6
Outcomes The F.I.G.H.T for PHR project outcomes will be the following:
Research Outcomes
Eleven Scientific Papers that further basic research in the areas of Informatics, Health
Management, Health Services Law and Regulations, Social Marketing published (and announced)
in globally reputed scientific journals and conferences. An indicative list of such journals and
conferences is following:
Informatics
The Health Informatics Conference
International Conference on Health Informatics, International Joint Conference on
Biomedical Engineering Systems and Technologies
AMIA Annual Symposium
The WSEAS International Conference on BIOMEDICAL ELECTRONICS and
BIOMEDICAL INFORMATICS
IEEE Transactions on Evolutionary Computation
IEEE Transactions on Knowledge and Data Engineering
7
IEEE Transactions on Smart Grid
Health Management
Health It Congress and leadership summit (HIMSS)
Economic and Managerial Aspects of e-health (special session in ITAB conference)
Health Services Law and Regulations
Various annual Health law Conferences
Social Marketing
Social Marketing in public Health Conference
USF Social Marketing in Public Health Conference
Annual Art and Science of Health Promotion Conference
Informatics
Health IS Semantics: ―A Framework Ontology for rapid PHR adoption by multiple heterogeneous
systems‖
Health IS Design: ―A distributed Event Driven Interface software layer design for Health Data
Entry, Sustainability and Interoperability‖
Health IS Distributed Systems: ―A Multichannel Asynchronous Information Flow and Verification
for Heterogeneous Health Informatics Systems Interoperability‖
Health IS Security and Integrity: ―A unified SSO web service in a heterogeneous Health Informatics
Technology Grid in a distributed cloud environment‖
Health IS Distributed Systems: ―A Hybrid Unified Software Development Model for both Open
Source and Proprietary Health Informatics distribution channels‖
Health Management
Health Management: ―A flexible Scenario Based Workflow Management method for rapid adoption
of foreign PHR schemas in a hospital‘s mainframe management system ‖
Health Management: ―A CMMI based maturity framework for Health Informatics initiatives
deployment following the lean production paradigm‖
Health Management: ―A balanced scorecard monitoring system under an organic IT deployment
framework‖
Policy Issues
Health Provision Management: ―Fighting Red Tape obstacles in Health Informatics adoption at the
regulatory and governmental level: Guidance and methodological tools for the regional, state and
European stakeholders‖
Social Marketing: ―A fact finding Report of the Societal Impact of Health Informatics Technology
breakthroughs‖
Social Marketing: ―The social implications of m-health applications in Europe‖
Tangible Research Functional Prototypes1
F.I.G.H.T. functional nodes
1 The term “Functional Research Prototypes” refers to fully functional software applications and services at the
“beta” version phase.
8
A ―F.I.G.H.T. functional node‖ is a Health Provider that has adopted a functional PHR scheme and
is ready to provide services to patients based on their PHR health data. F.I.G.H.T. functional nodes
vary in adoption levels (1-5) based on a CMMI based scale of Health Informatics maturity level
“Follow-me Health Data” Electronic Service
―Follow-me Health Data‖ is an electronic/web service that recognizes PHR owners and authenticates
them as users on any F.I.G.H.T. functional node. The authentication is triggered by the owner‘s
request (it is event driven) by means of a web portal featuring a ―smart‖ mobile phone interface and
a corresponding mobile app. Multiple authentication scenarios are supported covering extremities
such as emergency ambulance alerts, loss of credential information (―loss of card‖), third person
activation (loss of consciousness) etc
“PHR Connect” Electronic Interoperability Repository
―PHR Connect‖ is a Master Index Repository that catalogues APIs from any PHR related Heath
Informatics software systems. All API catalogues are available to plausible stakeholders by means of
a digital library that features the APIs‘ code libraries and related documentation. Upload to ―PHR
connect‖ requires a minimum compliance to F.I.G.H.T.
“Health Hippo: Health Informatics Interoperability Developers’ Community”
―Health Hippo‖ is a Collaboration Portal that promotes software developers‘ collaboration (on ―per
Project‖ basis) regarding creating and sustaining Interoperability Software that connects
heterogeneous Software systems to any F.I.G.H.T. functional node.
“Euterpe: Regional, National and European PHR Adoption Methods and Guidelines”
Collaboration Portal and Digital Library The ―Euterpe‖ digital library is a thematic digital library that embodies all the deliverables of the
project which are
The research papers with their full documentation
Any software documentation (manuals etc)
Specific guidelines for PHR adoption methods
Walkthroughs for Health Providers towards a rapid development of a F.I.G.H.T. functional node
within their domain
Guidelines and Walkthroughs for rapid creation and adoption of PHR related regulations and
law at a regional, state and European level
2. Progress beyond the state-of-the-art
In the EU the State of Art concerning the use of Health Informatics technologies in favor to the European
Citizen Patient predominantly lies with two main European funded projects: The epSOS project (Smart
Open Services for European Patients) and the Calliope thematic Network.
The epSOS features two main use cases for cross border communication, the Patient Summary and
ePrescription.
The main goal of the CALLIOPE Network has been to produce value for decision makers for
national eHealth implementations. CALLIOPE comprises a dedicated forum where decision
makers, implementers, professionals, patients and other stakeholders can share visions, experiences
and good practices on how to establish interoperable eHealth services and has recently communicated
a Strategic Roadmap towards these objectives.
The main points of complementarity of the present project with both epSOS and Calliope could be the
following:
Complementarity with epSOS
FIGHT for PHR will provide specific Patient Centered PHR services within a Network of European
stakeholders that operate on a technology grid. A complement to what epSOS has already achieved
would be to populate the ―PHR Connect‖ Electronic Interoperability Repository with APIs of the
9
NCPs‘ epSOS applications/ services with the purpose of populating a citizen‘s PHR with any
personal medical data these services route.
Complementarity with Calliope
CALLIOPE has established a successful collaborative platform for many actors in eHealth
interoperability in Europe covering the topic of mobile patients that will be one of the basic
references of the 2,5,6 and 8 FIGHT WPs
Interdisciplinary research for IST intensive work The research that is conducted within the project‘s scope produces tangible research outcomes from
different science disciplines. Specifically, although these outcomes enhance and empower strictly Health
Informatics applications, they demand expertise from HSPs performance management and also from
areas such as Health Law and Regulations and Social Marketing. This structure is due to the fact that the
proposed project is equally targeting at both the creation and adoption of the related Health
Informatics services and applications – the latter as viewed by any plausible stakeholder‘s point of
view at the regional, state and EU level.
State of the Art Roll Out Methods The roll out methods of the project combine a state of the art deployment technique featuring bottom up
organic IT scorecard monitoring and dynamic business workflow management. The resulting combination
avoids chaos by utilizing a laconic event driven User Interface software layer which handles multichannel
feeds from heterogeneous software systems in an Enterprise Service Bus environment featuring the
demanding security required for the endeabour. The UI events’ rules are populated by both the bottom
up scorecard approach (in the Organic IT fashion described above) and the top down multichannel
information and business dynamic workflow scenarios (the FOEG visits) being the functional
interoperability layer unifying the roll out of the project from the users’ point of view. Horizontal
interoperability is assured by means of a Unified Interface software layer Subsystem (the Enterprise
Service Bus, described in WP3) that functions under a Domain Framework Ontology created specifically
for the purposes of the project (WP2). Red-tape regulatory and social implication research findings are
utilized as filters to the events of the UI. Also, the FOEG visits feature use cases of maximum flexibility
and scenarios that are designed to leave a ―trace‖ in each Health Provider carefully designed to ease that
Health provider‘s effort towards their maturity for Health IT services.
Setting up the target: Patient Oriented Digital Services The interdisciplinary character of the research combined with the geographic and regulatory disparity of
the endeavor demands state of the art roll out methods that have to combine robust scientific
methodologies with unavoidable original work. The strict alignment of the project to tangible outcomes
presents an opportunity to bond the interdisciplinary research work respecting the geographic and
regulatory disparity. Since the main workflow of the project leads to tangible research software
prototypes alignment of all aspects of work within the project is governed by the features and
characteristics of these software prototypes - with the scientific publications being the documentation and
knowledge diffusion agents of the way these software outcomes have evolved. Specifically, the governing
feature of these software prototypes has to satisfy the core need of the users, thus, taking into account the
users need described in the FP7 ICT Objective 5.3, a), the governing feature should be Patient Guidance.
Having tied the governing feature of the research outcomes (software prototypes) of the present project
with Objective 5.3, a), Patient Guidance, the challenge remains to the methods used. In order to fully
support the logic behind the selection of these methods and illustrate their complementarity two notions
are introduced: a clarification of our view concerning PHR as an electronic service and our interpretation
of an Organic IT software (or system). Following these notions the CMMI-SVC, V1.3 maturity model
integration method and the Balanced Scorecard performance management methods are introduced in
order to complement an innovative approach of PHR use involving a PHR physical device and the
creation and expansion of the technology grid of the project.
10
PHR: an electronic service adopted and in use, not just an electronic record A “citizen centric personalized electronic /web service” is not only a UI of a web application (available
for all to use) but all that including documented proof of its functionality by a critical mass of users /
stakeholders. In our case the ―critical mass of users‖ consists of
a. Citizens (and patients) as the ―PHR owners‖
b. Health provider staff
c. People of the medical (or medical related) profession (apart from the ones of the Health provider)
that have a correlation with the ―PHR owner‖
d. Payer‘s staff
e. Related government staff (and from other regulatory bodies)
f. People trusted by the ―PHR owner‖
So, in FIGHT, PHR actually means ―citizen centric personalized electronic /web service for PHR‖ which
includes adoption and use by all of the above stakeholder‘s categories (our interpretation of a PHR
system)
Organic IT An Organic Software (or IT System) is the one that presents strong interaction with users‘ activity in all
of its phases of development (from inception to continuous improvement). It is a Software (or system)
that ―listens‖ to its users and is able to change its behavior according to users‘ feedback regardless the
depth of the changes (from a slight UI alteration to core architecture changes). Software (or IT systems)
that are created and operate in this fashion are characterized as ―organic‖ because they represent a
technological interpretation of users‘ behavior. The robustness of an Organic Software (or system)
depends on the quality of experts‘ moderation on the changes that are needed to meet the users‘ demands.
Organic Software (and systems) need to be particularly flexible in their architecture. The three distinctive
characteristics of Organic Software (and systems) are the following:
● A modular architecture with an adequate degree of granularity
● The ability to embed modules created by developers that interact with the main software‘s users (and
stakeholders) in social styled developer‘s communities
● A dashboard / scorecard module that enables feedback information flow from the front-end users (the
dashboard section) to the back-end moderators, administrators and module developers (the scorecard
section). This can be done in an automatic or manual way: the first being users’ actions/ states
monitoring and rules firing and the second including user’s feedback by polls and follow up actions
by admins and developers. An indicative implementation of feedback information flow would be
according to the balanced scorecard method. Following a careful setup by system architects (that
need to closely cooperate with business and other regulatory related stakeholders) the method could
“translate” user’s behavior (their dashboard reads) to moderators’, administrators’ and developers’
meaningful actions (their scorecard reads)
The use of CMMI for FIGHT network nodes creation The initial nodes of the FIGHT network will be the HSPs located in the Netherlands and Greece. An
examination of one or more processes by a trained team of professionals using an appraisal reference
model as the basis for determining, at a minimum, strengths and weaknesses will be carried out with the
sole purpose of appraising the level of maturity of these HSPs concerning their ability to offer the
service of seamless connectivity of their EHR / EMR systems with any PHR services. The boundaries
of the appraisal encompassing the organizational limits within which the processes to be investigated
operate are set to the minimum possible taking into account that one of the main objectives of the project
is rapid adoption of PHR connectivity and use which is preferred in contrast to full adoption that might
cause unwanted complexity concerning the reengineering needed on behalf of the HSPs. A capability
level profile is set for appraising the HSPs maturity towards the aforementioned connectivity that includes
the following process areas of the HSPs (CMMI-SVC, V1.3): Incident Resolution and Prevention (IRP),
Service Delivery (SD), Service System Development (SSD), Service System Transition (SST) and
Strategic Service Management (STSM). A relationship entity diagram illustrating the process areas and
11
the tools that will be used to support the Service Establishment and Delivery of EHR/ EMR to PHR
connectivity is following:
Following the appraisal of each HSP a strategic goal is set and documented as a Service Contract /
Agreement for the desired maturity level for offering the desired EHR / EMR to PHR connectivity
service. The minimum threshold level of maturity towards embedding the HSP into the FIGHT network is
set to level 3. Work towards this maturity level is done using the standard work procedures of CMMI-
SVC, V1.3 is carried out in all phases of the creation and expansion of the FIGHT network described
below
The use of Balance Scorecard for Organic IT software performance measurement and FIGHT Expansion The Balanced Scorecard method is proposed due to the results based character of the present project and
the strong relation between the strategic targets and the outcomes. This relation has to be kept robust in an
ever expanding environment of an Enterprise System such as the one of FIGHT that operates across
geographical and regulatory disparity. Additionally, the outcomes themselves (the software prototypes)
are of an intensive dynamic character featuring Organic IT characteristics (see section Organic IT). In this
highly volatile and distributed environment a two dimensional implementation of the Balanced Scorecard
technique is proposed. The first dimension covers the performance measurement of the software
prototypes as described in section ―Organic IT‖ and the second supports knowledge diffusion as described
in phase three ―Organic Expansion Phase‖ of section ―The technology grid: the key to optimal PHR use
and adoption‖ below. The volatility of the aforementioned environment is the principal reason for
choosing this two-dimensional BS implementation. BC is a well proven technique for capturing and
diffusing knowledge where ―closed group‖ controllability is not the prime characteristic of the application
Customer/End User
STSM
SSD
SST
IRP
SD
Process Areas for
Managing Services
StrategicServiceNeeds
ServiceCatalog
Corrective Actions
StrategicServiceNeeds
IRP = Incident Resolution and Prevention
SD = Service Delivery
SSD = Service System Development
SST = Service System Transition
STSM = Strategic Service Management
ServiceValue
Transition Plans
ServiceCatalog
RequestStatus
ServiceRequirements
Contract / ServiceAgreement
ServiceRequests
Incident Response Information
Service Issues
IncidentStatus
Service Requirements
Operations andService Delivery
Data
Deployed Service System
Validated Service System
Revised Resource Constraints and
Service Thresholds
Service Requirements
StandardService
Requirements
12
environment. It is ideal for a large (multinational/ global) organization/ company where the distance
between the leadership that decides strategy and the execution level (of that strategy) is considerable and
often involves geographical (and even regulatory) disparities – just as the FIGHT network. Furthermore,
the demand for user-centered electronic services (Patient Guidance PHR services) that is attained
through repetitive performance measurement and optimization involving the User into the process of
software development follows similar volatility and geographical and regulatory disparity as the FIGHT
network and leads to the implementation of the second dimension of the BC.
An innovative approach for PHR use: the “Smart PHR Drive” The PHR as an electronic record reside simultaneously in a USB device (conveniently carried in the
owner‘s wallet or key holder) and in an encrypted cloud based service. The USB device characteristic and
the way its contents communicate with the cloud are the following:
1. Distinctive appearance (very important in case of an acute emergency that could mean the owner is
in great pain or even unconscious). Ideally, if the PHR is provided through a Health oriented network
(a patient organization, the government, a payer etc.) funds should be invested on the social
awareness of the appearance (shape, color etc.) of that device. In a more limited (but effective)
fashion this awareness is feasible if communication / marketing is targeted primarily to regional,
national and international health systems (following a scalability similar to the expansion of the
FIGHT nodes). A proposed shape of the USB device is the credit card like USB flash drives that can
be easily fit in wallets or the key shaped USB flash drives one (in the likes of LaCie), featuring a
distinctive color that can be easily recognized and communicated / marketed. Also it is proposed that
the USB drive will have, at least, the owner‘s social security number printed on its cover.
2. The PHR electronic file in a structured form (indicatively as collection of CCD‘s)
3. Other PHR related files. These files are of great importance for both emergency situations and PHR
adoption scenarios (as explained below)
4. Encryption software that separates a private/ encrypted part of the USB flash drive and a public one
where the PHR related files are located. The software will have the ability to assign share privileges
and to synch in a cloud based encrypted service to keep mirrors of the contents of the USB drive
(both encrypted and public)
5. F.I.G.H.T. adoption software. This software has two core characteristics :
5.1. The software will ―scan‖ any file that is located in the public part of the drive and classify it
following an ―OCR style‖ recognition algorithm. After classification and upon owner‘s consent the
software will upload the files to the ―PHR connect‖ web service for further work that could entail
(indicatively):
a. Embedment of the new data to the structured PHR file
b. Initiation of a series of alerts to medical staff, payer staff etc
c. Automatic forwarding of unstructured files to specialized agents (software of human) for
further classification,
d. Other related actions.
5.2. The software will contain interface oriented software of EHR, EMR software systems and
therefore will be able to update the structured PHR file automatically if such systems are active in
the Health Provider IT infrastructure (via the USB port or via the PHR connect web service)
As illustrated in the Objectives section, FIGHT aims at creating Tangible PHR based citizen centric web
services / prototypes within a technology grid. Taken into account the aforementioned principle
regarding PHR systems it is clear to us that any PHR that aspires to have the slightest chance of
producing documented proof of its functionality (from all stakeholders) should be operating within a
technology grid. Analogous to the technology service (the PHR) the technology grid proves functional
after documentation of good use is produced by all stakeholders. The FIGHT distinguishes three classes
of such grids: the regional, the national and the international one.
13
The technology grid: the key to optimal PHR use and adoption Since PHR based services are more or less evident the creation of the technology grid that makes
optimal use of the Smart PHR Drive is quite interesting from both research and implementation point
of view. A practical approach to present such a grid is following:
In principle, the FIGHT for PHR core strategic target is to create a web of active FIGHT nodes in
various EU places. Put simple, a FIGHT node is a geographical and social domain where PHR
services are well adopted and function for the benefit of the common people. In the preliminary phases
certain EU regions will be chosen, that are under the “influence” of three core knowledge “beacons”:
1. A Research beacon: usually an Academic / Research institution that belong to that region /
country ideally ―coupled‖ with a ―sister‖ Health provider
2. A Technology beacon: usually a Health IT company that belong to that region / country
3. A Patient beacon: usually a Patient org (their local office)
Such a domain that combines the influence of these ―beacons‖ is a feasible FIGHT node. The project
initiates within the geographical and social domains of the FIGHT nodes and works in three time phases:
a. The “introvert” phase when work focuses on creating a functional PHR service within the
FIGHT node and is the ―local‖ aspect of the project,
b. The “extrovert” phase when work focuses on diffusing knowledge to the immediate neighbors
of the nodes, using tangible PHR services, accompanied with the necessary documentation (both
technical and regulatory), and
c. The “Organic Expansion ” phase when work focuses on delivering intrusive roll out methods
(equipped with the outcomes of both the ―introvert‖ and ―extrovert‖ phases) that provide both
technical and regulatory methods and tools to perform domino ―introvert‖ / ―extrovert‖ phases
from neighbor to neighbor creating FIGHT nodes in a spider web fashion
A practical view of a FIGHT node at the regional level is following (the national and international are
somewhat analogous with the unavoidable complexity):
At any region of an EU country there are:
1. The local Health Provider (a clinic and / or a diagnostic center)
2. An Academic / Research Institution of the region / country
3. A patient network with local offices (in the country)
The above are evidence of a candidate FIGHT node. The work that could transform such a candidate
node to a fully functional FIGHT node includes three basic phases, which are the following:
“Introvert” phase
The local Health Provider, the Academic / Research Institution and the Patient Network in collaboration
with partners that locality is not a question, those being the IT Companies and Consultancy companies,
conduct preparatory work for the candidate FIGHT node. This work includes the appraisal (CMMI-SVC,
V1.3) as described above that results to
A) A Service Contract / Agreement for the desired maturity level for offering the desired EHR / EMR to
PHR connectivity service and
B) Follow up actions (mini-projects) that are part of an Action Plan that aims at attaining the Service
Contract. The work of those mini-projects follows the standard procedures of CMMI-SVC, V1.3
(transition plans, corrective actions etc.). A simplified version of the mini-projects in a step by step
fashion is following:
1. Scenarios of patient visits to the Health Provider to document the Health Provider processes, any
HER, MHR evidence and (very important) the patient‘s experience
2. Development of a limited number of Smart PHR Drives for a variation of groups (ideally most of
them belonging to a patient network)
14
3. Rolling out of the scenarios following a sequence that is analogous to the maturity of the Health
Provider regarding EHR and EMR
4. Conduct research mainly on the PHR enrichment and utilization by the Health Provider via the
Smart PHR Drive and the role of all Smart PHR Drive components (both technological (software)
and physical / distinctive characteristics).
5. Diffusing knowledge produced in all stakeholders of the introvert phase. Review scenarios of step
1 and repeat all steps till optimal results are obtained. Optimal results are based on a targeted
maturity level of all stakeholders of the candidate node concerning the optimal utilization of the
Smart PHR Card. When this maturity level reaches a specific threshold the Health Provider
receives the ―Active FIGHT node‖ characterization (following an evident scalability of maturity
ranging from minimal to full compliance with of the FIGHT network).
An indicative scenario of a patient visit to the Health Provider is the following:
Scenario A: A visit to a non-FIGHT Health Provider with no active EHR, EMR following an acute
incident. The patient is in perfect communication with their environment.
1. The Patient visits the Health Provider following an acute incident.
2. Upon admittance he informs the people of the admittance office that he holds a USB drive with
vital medical data and also informs them that there is a file in the drive entitled ―Instructions of
the Smart PHR Drive for Health Providers‖. He communicates with the people at the admissions
that they should notify the medical staff about this file (suggesting that it can be easily printed)
3. When he receives any results or diagnosis by the Health Provider Staff he mentions that he holds
a USB device that contains all his medical data, that the people at admittance have been notified
about that upon admittance and that he wishes to receive any diagnosis and test results
documentation electronically (to store them into the USB drive) or if that is not possible to
receive the documentation on paper.
4. Any documentation that the patient receives electronically is stored in the drive. When possible
(obviously at a later time) the patient logs on the PHR connect service and the files update the
structured PHR via the F.I.G.H.T. adoption software 5. Any documentation the patient receives in paper is scanned into the drive either by the patient
themselves at a later time or perhaps by utilizing a payer‘s service (specially for the elderly or the
computer illiterate) and then update the PHR via the F.I.G.H.T. adoption software
6. Any of the above can be done on behalf of the patient and upon his consent, utilizing the
Encryption Software of the drive, by any of the following:
a. Health Provider‘s staff
b. Payers staff
c. Their personal physician / doctor
d. People from their immediate social environment
e. etc.
An interesting variation of the above scenario is of a non-FIGHT Health provider that presents some use
of EHR / MHR schemas. In this case if the F.I.G.H.T. adoption software in the drive is updated with APIs
of the EHR / MHR software(s) then the structured PHR is updated automatically (either in the Health
provider‘s IT environment or at a later time though PHR connect cloud service).
It is quite evident that variations of the scenario above are numerous but this particular one is indicative of
the manner that the PHR can be updated even by Health Providers that present little to none digital
convergence concerning Health Informatics. This is made possible by very few and simple actions on
behalf of the PHR owner and a ―smart‖ utilization of software components in a simple USB drive that
automatically synch with analogous cloud based services.
“Extrovert” phase
After the Health Provider receives (at least the minimal) compliance of a FIGHT node then work is
focused on diffusing knowledge to the immediate neighbors of that node, using tangible PHR services,
accompanied with the necessary documentation (both technical and regulatory). It is important to note
15
here that ―immediate neighbors‖ of a FIGHT node are Health Providers that present characteristics such
as the following:
i. Locality: a ―next door‖ Health Service Provider
ii. Medical Similarity such as Cancer Oriented clinics
iii. Technical Similarity such as use of identical / similar EHR / EMR software
It is expected that these “neighbor” HSPs will be Patient Networks affiliated (or related) General
Practitioners and small clinics rather than Hospitals of the size and magnitude of the project member’s
hospitals
1. Communication in regards of awareness of the benefits of the use of the Smart PHR Drive
a. Evidence illustrated in fact finding reports and relative presentations from the implementation
of the scenarios of the Introvert phase
b. The prerequisites and the necessary actions in order to attain a minimal FIGHT compliance.
Ideally the communication is carried out by a representative of a patient network (the local office
that conducted the Introvert scenarios / visits) possibly supported by medical staff of the new
FIGHT node and other staff from payers.
2. Repetition of the Introvert phase in the neighbor candidate node ideally with the support of not only
the local office of the patient network but also by staff (IT and medical related) from the new FIGHT
node
“Organic Expansion” phase
When a critical mass of FIGHT nodes appear in a geographical / social domain then action groups, the
FOEGs (see “introduction”), can be formulated in order to support the expansion of FIGHT in this domain
(a region or a state). Within these domain borders introvert and extrovert phases of candidate nodes can
receive support by those action groups and thus the FIGHT expansion is being accelerated. Ideally a
FOEG is led by patient organizations representatives accompanied by research associates of medical
related and IT background. The FOEGs‘ visits follow a comprehensive multidimensional scenario which
pools from a rich variety of Health Services provision and utilizes a single electronic ―Health Card‖
device. Initially, each FOEG member is provided by such a device which, according to the scenario,
varies among USB flash drives, existing PHR/ PHR related smart cards, simple membership plastic cards
etc. Then, FOEG visits in various European cities are carried out featuring carefully designed
personalized patterns for each FOEG member. These personalized patterns include all typical patterns of
real life medical situations like emergencies, prescheduled visits, hospitalization etc. with some of them
even describing a ―loss of the card‖ scenario. The use case of the device by the FOEG members (in all of
the aforementioned scenarios) is designed in an innovative way that leaves a ―trace‖ to the Health
provider that hosted the scenario incident – a ―trace‖ carefully designed to ease that Health provider‘s
effort towards their maturity for Health IT services. Depending on the scenario at hand, which in turn is
custom based according to the CMMI based maturity level of the Health provider concerning Health IT
maturity, the ―trace‖ could be:
ADOPTION ACTIONS / HSP IT MATURITY
Health IT
Maturity
Level
Trace FIGHT “smart card”
device components’ use
Suggested Follow up actions
(coordinated by patient networks)
1
No IST present
Documented proof
of the service
provided (i.e. a
receipt)
The imprinted social
security number
Telephone communication to arrange
meeting with a legal representative and
try to initiate an ―introvert‖ phase
2
Limited use of
IST (office
apps, email)
Contact details of
the Health
Providers‘ IT staff
The imprinted social
security number
Possible use of the
―public‖ space of the drive
Telephone communication to arrange an
informative meeting and try to retrieve
relevant patient‘s electronic records.
Establish Electronic communication via
16
for information retrieval mail with all necessary documentation
for the information retrieval process
3
Extensive use
of office apps
but no use of
Health IT apps
(EHR, EMR,
PHR)
Contact details of
the Health
Providers‘ IT staff
The imprinted social
security number
Possible use of the
―public‖ space of the drive
for information retrieval
Telephone communication to arrange an
informative meeting and try to retrieve
relevant patient‘s electronic records.
Establish Electronic communication via
mail with all necessary documentation
for the information retrieval process
4
Extensive use
of office apps
with limited use
of Health IT
apps (EHR,
EMR, PHR)
Contact details of
the Health
Providers‘ Health
IT admin
FIGHT adoption software
to scan the technical
details of the Health IT
apps
When plugged on the Internet synch
with Health Hippo and post a commit
ticket for developing an API
5
Extensive use
of Health IT
apps (EHR,
EMR, PHR)*
*at least one
Contact details of
the Health
Providers‘ Health
IT admin
FIGHT adoption software
to scan the technical
details of the Health IT
apps and try to connect to
the Health IT apps via
PHR connect
When plugged on the Internet synch
any retrieved data with the PHR
through PHR Connect if connection
with any of the Health IT apps was
successful. If not then perform same
actions as level 4
At this point it is important to stress out that because the expansion is led by specific patient networks
then it is much easier for FIGHT to expand beyond the physical borders of a (EU) country taken into
account the traits of the ―immediate neighbors‖ and specially the Medical and Technical one mentioned
above.
Research Focus The research proposed is meant to be multidisciplinary taken the fact that the project‘s main objectives
demand state of art scientific work on a) Informatics, b) Health Management and c) Policy Issues as
illustrated in the ―Objectives‘ section.
Taken into account the aforementioned, research focuses on:
1. The Software Components of the Smart PHR Drive
2. The Supporting cloud based services for the Smart PHR Drive: PHR Connect and Health Hippo (the
latter being an active community of Health IT developers and related Academics that develop open
source software components for both the Smart PHR Drive and the supporting cloud services)
3. The optimal implementation of the three phases for the Expansion of FIGHT (and, by result, the
expansion of PHR related services) including the maturity of Health Providers concerning PHR
services adoption at the regional, state and international level. The research will make use of CMMI
and BS methods and metrics.
17
3. S/T methodology and associated work plan
Work allocation
The work demanded for the implementation of the proposed F.I.G.H.T for PHR project requires a robust
project management scheme which will have to allocate and manage work to multiple resources of
various professional origins. These resources are expected to: a) be widely distributed (all over Europe),
b) collaborate on a synchronous / asynchronous fashion towards a good number of deliverables and
deadlines and c) be of varied professional backgrounds taking into account the multidisciplinary character
of the project. Having all those in mind, the implementation of the project is divided vertically into three
main pillars. These three pillars will be coordinated under a single work package, WP1 Project
Management, horizontally set and common to all pillars. The overall work allocation of the project is
following:
On the Pillar level, work allocation follows the project objectives (see. “Objectives”), the project
consortium members list and the research areas of the project.
On the Work Package level, work is allocated to partners according to their project work
complementarities (see Table WORK Complementarities below) and the deliverables list.
WP01: Project Management
Pillar 1: Knowledge Base and Initial Setup
WP No WP title
02 Health Informatics PHR-centric Framework Ontology
03 A distributed Event Driven User Interface software layer for
Health Data Entry, Sustainability and Interoperability
04 F.I.G.H.T. network initial setup
Pillar 2: Development and Integration
WP No WP title
05 Scenario Based Workflow Management module
06 Organic IT Scorecard Monitoring subsystem
07 F.I.G.H.T. network base Integration
Pillar 3: Expansion and Sustainability
WP No WP title
08 e-Health Social Marketing PHR adoption framework
09 F.I.G.H.T. network “follow me” PHR demonstrations
10 F.I.G.H.T. network sustainable expansion field scenarios
implementation
11 Case Studies
12 Dissemination Activities
18
WORK
Complementarities
Pillars / Partners
Pillar 1: Knowledge
Base and Initial
Setup
Pillar 2: Development
and Integration
Pillar 3: Expansion and
Sustainability
Project
Coordinator and
Technical
Consultants
WP01
WP02
WP01
WP05
WP06
WP01
WP09
Academic Research
WP02
WP03
WP04
WP11
WP05
WP06 WP08
Software Vendors /
Integrators
WP02
WP03
WP05
WP06
WP07
WP09
WP10
Patient Networks WP04 WP07
WP08
WP09
WP10
WP11
WP12
PROJECT VALUE
Stakeholders /
Outcomes
EU citizens Academics /
Researchers
Health
Professionals IT Industry
F.I.G.H.T.
network
Get on-the-
spot health
services
N/A
Provide on-the-
spot health
services
Support on-the-
spot health
services
Follow-me Health
Data
Get on-the-
spot health
services
N/A
Provide on-the-
spot health
services
Support on-the-
spot health
services
PHR Connect N/A Interact with
Industry
Interact with
Industry
Develop
Software
Health Hippo N/A Interact with
Industry
Interact with
Industry
Develop
Software
Euterpe
Get
information
about Points
Of Service
Publish
Papers
Publish Reports,
Get state-of-art
scientific info
Publish Reports,
Get state-of-art
scientific info
Research Papers N/A
Get state-of-
art scientific
info
Get state-of-art
scientific info
Get state-of-art
scientific info
19
Work plan
WPs / MOs 3 6 9 12 15 18 21 24 27 31 34 36
WP01 Project
Management
WP02
Health
Informatics PHR
centric
Framework
Ontology
WP03
A distributed
Event Driven
User Interface
software layer for
Health Data
Entry,
Sustainability and
Interoperability
WP04 F.I.G.H.T.
network initial
setup
WP05
Scenario Based
Workflow
Management
module
WP06
Organic IT
Scorecard
Monitoring
subsystem
WP07 F.I.G.H.T.
network base
Integration
WP08
e-Health Social
Marketing PHR
adoption
framework
WP09 F.I.G.H.T.
network “follow
me” PHR
demonstrations
WP10
F.I.G.H.T.
network
sustainable
expansion - field
scenarios
implementation
WP11 Case Studies
WP12 Dissemination
Activities
*0-36: from the beginning of the project up to the end of the 36th month.
01: 0 – 36*
03: 1- 25
04: 2 - 12
02: 1 - 31
05: 3 - 25
06: 3 - 35
08: 9 - 35
07: 12 - 24
09: 15 - 35
10: 12 - 36
11: 24 – 35
06: 12 - 35
20
List of Deliverables (44 deliverables out of 12 work packages)
Del.
no. Deliverable name
WP
no. Nature
Dissemi-
nation
level
Delivery
date(proj.
month)
01.01 Project Reports 1 MGT PU Monthly
02.01
―A concept ontology for a flexible PHR
schema in an distributed heterogeneous
IS environment‖
2 RTD PU 6
02.02 ―Merging CEN 251 and HL7 based
ontologies into a unifying framework‖ 2
RTD PU 12
02.03
―A Framework Ontology for rapid PHR
adoption by multiple heterogeneous
systems‖
2 RTD PU 31
03.01
A unified Interface software layer
subsystem for heterogeneous health
informatics systems
3 RTD PU 6
03.02
A unified PHR interoperability web
service for heterogeneous health
informatics systems
3 RTD PU 12
03.03
―A distributed Event Driven User
Interface software layer design for Health
Data Entry, Sustainability and
Interoperability‖
3 RTD PU 25
04.01 CCMI based maturity deployment for
F.I.G.H.T. network Initial Setup nodes 4 RTD PU 6
04.02 F.I.G.H.T. network: Initial Setup 4 DEM PU 12
04.03
―PHR Connect‖ Electronic Marketplace
and Interoperability Repository: dev
package
4 DEM PU 12
04.04
―Health Hippo: Health Informatics
Interoperability Developers‘
Community‖ Collaboration Portal: dev
package
4 DEM PU 12
04.05
―Euterpe: Regional, National and
European PHR Adoption Methods and
Guidelines‖ Collaboration Portal and
Digital Library: dev package
4 DEM PU 12
21
05.01 CCMI based maturity deployment for
rapid PHR schemas adoption 5
RTD PU 6
05.02
Seamless Management Health Provision
Reengineering for rapid PHR schemas
adoption 5 RTD PU 12
05.03 Balanced Scorecard Deployment for rapid
PHR schemas adoption 5 RTD PU 12
05.04
―A flexible Scenario Based Workflow
Management method for rapid adoption
of foreign PHR schemas in a hospital‘s
mainframe management system‖
5 RTD PU 25
05.05
―A CMMI based maturity framework for
Health Informatics initiatives
deployment‖
5 RTD PU 25
06.01
Self-replicating organic IT deployment
for PHR based Health Informatics
applications
6 RTD PU 12
06.02
―A balanced scorecard monitoring system
under an organic IT deployment
framework‖
6 RTD PU 35
07.01 F.I.G.H.T. network base Integration 7 RTD PU 24
07.02
―PHR Connect‖ Electronic Marketplace
and Interoperability Repository: Alpha
Version
7 DEM PU 24
07.03
―Health Hippo: Health Informatics
Interoperability Developers‘
Community‖ Collaboration Portal:
Alpha Version
7 DEM PU 24
07.04
―Euterpe: Regional, National and
European PHR Adoption Methods and
Guidelines‖ Collaboration Portal and
Digital Library: Alpha Version
7 DEM PU 24
07.05
―A Multichannel Asynchronous
Information Flow and Verification for
Heterogeneous Health Informatics
Systems Interoperability‖
7 RTD PU 24
07.06
―A unified SSO web service in a
heterogeneous Health Informatics
Technology Grid in a distributed cloud
environment‖
8 RTD PU 24
08.01 ―Societal Impact of electronic Health 8 RTD PU 18
22
Applications: The breakthroughs
perspective‖ workshop
08.02
―A fact finding Report of the Societal
Impact of Health Informatics Technology
breakthroughs‖
8 RTD PU 35
08.03 ―The Societal Impact of m-health
applications in Europe‖ 8 RTD PU 35
09.01
Red tape obstacles regarding the rapid
adoption of PHR Health Informatics
Services at the regional level
9 RTD PU 24
09.02
Red tape obstacles regarding the rapid
adoption of PHR Health Informatics
Services at the state level
9 RTD PU 24
09.03
Red tape obstacles regarding the rapid
adoption of PHR Health Informatics
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
―PHR Connect‖ Electronic Marketplace
and Interoperability Repository: Beta
Version
10 RTD PU 35
10.03
―Health Hippo: Health Informatics
Interoperability Developers‘
Community‖ Collaboration Portal: Beta
Version
10 RTD PU 35
10.04
―Euterpe: Regional, National and
European PHR Adoption Methods and
Guidelines‖ Collaboration Portal and
Digital Library: Beta Version
10 RTD PU 35
10.05
―A flexible Scenario Based Workflow
Management method for rapid adoption
of foreign PHR schemas in a hospital‘s
mainframe management system ‖
10 RTD PU 35
10.06
―A Hybrid Unified Software
Development Model for both Open
Source and Proprietary Health
Informatics distribution channels‖
10 RTD PU 35
10.07 ―Fighting Red Tape obstacles in Health
Informatics adoption at the regulatory and
governmental level: Guidance and
10 RTD PU 35
23
methodological tools for the regional,
state and European stakeholders‖
11.01 A initial setup of prototype PHR centric
Health Informatics 11
RTD PU 18
11.02 F.I.G.H.T. network initial setup
stakeholders‘ workshop 11 RTD PU 18
11.03 ―PHR-centric European Technology
Grids‖ Conference A 11
RTD
OTHER PU 24
11.04 ―PHR-centric European Technology
Grids‖ Conference B 11
RTD
OTHER PU 36
Work package description
Work package
number
1
Work package title
Project Management
Objectives
The objective of this activity is to provide overall coordination and management for the entire contract.
This includes technical and administrative coordination, quality assurance, taking care of partner
dynamics and conflicts, and ensuring that the project is delivered according to the planned timetable
and budget. It also includes the writing and reviewing of all kinds of management and project
monitoring documents.
Description of work (possibly broken down into tasks) and role of partners
Technical coordination; contractual management; organise and coordinate communication flow;
manage documentation, track project status; maintain travel plans; review and verify deliverables;
progress meetings and reviews (including notices, agendas, chairing and minutes); ensure coordination
between different activities; conflict resolution, risk prevention/minimization.
Communication flow between partners will be achieved using teleconferences, collaborative software
tools, mailing lists, and a controlled repository of developed software. Mobility of researchers and
developers will be favored and encouraged.
The responsibilities that the coordinator will assume consist of the following tasks:
• Setting up a web-based collaborative tool, promoting its usage by all partners. Basic functionalities of
this tool will be in operation just after the official starting date of the project.
• Self-assessment and project workplan specification. Functional and temporal dependencies between
WPs will be considered so they do not become a source of conflict or delay in deliverables.
• Ensuring technical quality of the activities, deliverables and dissemination elements.
• Reporting activities, progress and resource management, acting as interface for communication
between the partners and the EC. Issuing management reports, progress reports and cost statements
The following formal tasks have been identified;
o Consortium Administration
24
o Financial Management
o Quality Assurance
o Activity Planning and Reporting
Status reports every 6 months, Coordination meetings every 3 months
Private collaborative and administrative website deployed
Initial tools available; user groups recruited; tentative dissemination and use plan proposed;
project self-assessment & workplan specifications
New content providers recruited; first annual workshop; Revised Project workplan
specification, software progress update
Internal assessments; Final prototype components available; Initial evaluation results, revision
requests and deployment procedure
Final public and private reports issued, project ends
Deliverables (brief description) and month of delivery
01.01. Project Reports
Quality assurance protocols and policies
Mandatory management, financial and activity reports
Final Public Report
Mandatory final management, financial and activity reports
Work package
number
2
Work package title
Health Informatics PHR-centric Framework Ontology
Objectives
To set the semantic base for the software design
To include the patient networks‘ experience to the semantic base for the software design
To unify the semantics of world-wide accepted Health IT standards with the particularities of the
present project and specifically the adoption character of the software designs and the experience
of the patient networks
Description of work (possibly broken down into tasks) and role of partners
Academics lead research cooperating closely with the Health IT Companies. Patient networks
contribute to the domain classes that relate to a) User Interface, b) Information security and sharing (if
applicable) and c) Any other behavior oriented classes
Academic XX updates an annotated bibliography depicting state of the art in the area of Health IT
Semantics
Academic XX outlines the concept ontology of 02.01
Health IT Company XX studies HL7 RIM and CEN 251schematics and applications and contributes to
the concept ontology of 02.01
Health IT Company XX and Patient Networks XX examine the parts of the concept ontology that have
to do with a) User Interface, b) Information security and sharing (if applicable) and c) Any other
25
behavior oriented classes
Academic XX merges the results of 02.01 and 02.02 to a framework ontology
Work of the WP2 will take into account the findings of “Semantic Interoperability RTD roadmap
project EU IST 6th fw 27328” (http://www.semantichealth.org/) and the work done at SEMIC.EU
(http://www.semic.eu/semic/)
Deliverables (brief description) and month of delivery
02.01 “A concept ontology for a flexible PHR schema in an distributed heterogeneous IS
environment”
A domain ontology for the FIGHT project is created. The Ontology is characterized by three main
layers: 1) The Physical layer that includes all the tangible deliverables and stakeholders of the project,
2) The Syntactical layer that refers to the obvious connections among the physical software and the
stakeholders and 3) The Flexible Dynamic layer that features behavioral patterns for both the Physical
and Syntactical layers from the requirements point of view. The Flexible Dynamic Layer functions as
follows: The behaviors at hand refer to system alterations that follow expansion scenarios of the
FIGHT ecosystem according that inevitably lead to changes to the requirements of the FIGHT
distributed IS ecosystem. The Interactions between behavioral requirements are documented using
OWL and Semantic Web Rule Language (SWRL) notation. At a given time point when expansion
activity is observed, OWL based Requirements Classes document the main Ontology Class Instances‘
values and then an Interaction description in SWRL is produced. According to this description
alterations in the FIGHT IS distributed system may be proposed. Those alterations are embodied in the
domain ontology. In this way maximum flexibility that serves the Organic Adoption Procedures (see.
section ―Organic IT‖) from the early stage of Ontological Design is assured.
02.02 “Merging CEN 251 and HL7 based ontologies into a unifying framework”
A merged Ontology that binds the CEN251 and the HL7 RIM ones is created. The purpose of this
merge is to result to an ontology that respects both CEN251 and HL7 RIM classifications that dominate
the Health IT Ontology area (and the corresponding applications) with the obvious purpose of
interoperability among heterogeneous systems.
02.03 “A Framework Ontology for rapid PHR adoption by multiple heterogeneous systems”
The framework ontology consists of:
The Domain Ontology of 02.01
The Merged CEN 251 and HL7 RIM Ontology of 02.02.
The purpose of the creation of a Framework Ontology is to combine the flexibility and adaptability of
the 02.01 Domain Ontology with the wide application spectrum covered by the merged 02.02 one. The
Framework ontology is the corner stone for the design of all aspects of the FIGHT deliverables -
tangible and intangible.
Work package
number
3
Work package title
A distributed Event Driven User Interface software layer for Health Data
Entry, Sustainability and Interoperability
Objectives
26
To carry out and document thoroughly the design of the project‘s proposed software solutions
To develop the archetypes of the project‘s proposed software solutions
To develop the initial archetype software in a lab environment (server instances in a cloud
service)
To actively involve Patients contribution specifically for a) User Interface, b) Design Patterns,
c) Information Security and Sharing
Description of work (possibly broken down into tasks) and role of partners
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
Deliverables (brief description) and month of delivery
03.01 “A unified Interface software layer subsystem for heterogeneous health informatics
systems”
The software layer is created according to the deliverables of WP2. The modules of this layer will
include the following:
The Framework Ontology Server module responsible for the alignment of the physical
vocabularies and the data descriptions of any subsystems and software repositories using the
Framework Ontology of WP2
The Enterprise Service Bus module responsible for carrying out the messages of the
subsystems. Taken in to account the physical complexity of all the software subsystems (cloud
and USB). The architecture of the ESB will be one of the core research matters of the present
project. A number of paradigms will be under investigation (typical and hybrid) starting with
the publish-and-subscribe (pub/sub) messaging one.
03.02 “A unified PHR interoperability web service for heterogeneous health informatics
systems”
The web service relies on a repository that is a semi-structured database of Application Interfaces
(APIs). These APIs come from software systems embodied or related with the FIGHT network. The
web service functions as a bridge connector between the APIs and the ESB of 03.01 using the
Framework Ontology of WP2
03.03 “A distributed Event Driven User Interface software layer for Health Data Entry,
Sustainability and Interoperability”
The Event Driven UI (EDUI) software layer is the one that governs the principal characteristics of the
UI modules of all software subsystems of FIGHT (cloud and device based). These characteristics
include at least the following: 1) Usability, 2) Accessibility, 3) User ID preferences awareness (look
and feel, language, Customizable fields etc.), 4) ―Mood‖ function (indicatively for hospitalization,
recuperation, thematic information gathering etc.), 5) Global (community) Alerts and Alert buttons
(SOS alerts, panic alerts, ―next of keen‖ notifications, medical data consent triggers etc.) . Each UI of
every subsystem will be updated by the EDUI on every software update occurrence. All the
aforementioned characteristics are depicted in a Balanced Scorecard performance software module
27
that records feedback from the test users/ the patient networks in both manual and automatic way as
described in section (see section ―Organic IT‖) based on the work of WP6
Work package
number
4
Work package title
F.I.G.H.T. network initial setup
Objectives
To prepare and set up the initial infrastructure and related electronic services and software of
the FIGHT network
To prepare the HSPs of the project to interoperate with PHR services (belonging to the Patient
Networks)
To provide the patient networks with an active PHR service
To develop the initial archetype software of ―PHR Connect‖ in a lab environment (server
instances in a cloud service)
To populate the ―PHR connect‖ database with any available APIs from the appraisals
To develop software that supports the research work carried out in the project (Health Hippo
and Euterpe)
Description of work (possibly broken down into tasks) and role of partners
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.
Deliverables (brief description) and month of delivery
04.01 CCMI based maturity deployment for F.I.G.H.T. network Initial Setup nodes
28
A CMMI based appraisal is conducted in the FIGHT Initial Nodes situated in the Netherlands, and
Greece. The appraisal aims at placing the initial nodes at any of the levels described in the
ADOPTION ACTIONS / HSP IT MATURITY table. The Appraisal results include the micro projects
needed to be carried out in order these initial nodes reach target HSP Maturity level (a description of
the model used is illustrated ―The use of CMMI for FIGHT network nodes creation‖) and in the
introvert phase.
04.02 F.I.G.H.T. network: Initial Setup
The Results / micro projects of the CMMI appraisal concerning the maturity of the initial FIGHT
nodes of 04.01 are activated. The micro projects‘ end deliverables are a) Documentation from the
CMMI appraisals that the initial nodes are at target maturity level (between 3 and 5) in the form of a
CMMI appraisal report and b) Available APIs of any EHR and EMR software for the ―PHR connect‖
service d) An active PHR electronic service for the patient networks of the project
04.03 “PHR Connect” Electronic Marketplace and Interoperability Repository: dev package
―PHR Connect‖ is a software subsystem that resides in the cloud as a semi-structured database
repository for EHR and EMR (and other feasible Health Informatics APIs – see indicative FOEGs‘
scenarios) APIs.
04.04 “Health Hippo: Health Informatics Interoperability Developers’ Community”
Collaboration Portal: dev package
―Health Hippo‖ is a project oriented collaboration portal for rapid software development. Within
―Health Hippo‖ independent software developers undertake commitments for software projects related
with the maintenance and expansion of FIGHT. The service is public allowing any EHR / EMR
software vendor and/or HSP to post APIs that connects their software with the FIGHT cloud services.
Furthermore the service allows any stakeholder to publish RFPs for developers in order to ascertain
such APIs.
04.05 “Euterpe: Regional, National and European PHR Adoption Methods and Guidelines”
Collaboration Portal and Digital Library: dev package
―Euterpe‖ is an electronic library service that hosts all FIGHT related documentation and provides
document centered collaboration services for any tasks, projects and subprojects of FIGHT. The initial
content of the service will be the project‘s deliverables with all related documentation (original work
and references).
Work package
number
5
Work package title
Scenario Based Workflow Management module
Objectives
To develop a generic CMMI method for rapid PHR adoption on behalf of the HSPs based on
flexible scenarios that respect the behavior patterns of patients
Description of work (possibly broken down into tasks) and role of partners
Academic partner XX with Health IT Companies design a generic CMMI appraisal method for rapid
PHR adoption on behalf of the HSPs
Academic partner XX with Health IT Companies design a BS reporting tool for aligning the vertical
implementation of the CMMI method
29
Academic partner XX examines the documentation of the appraisals and the metrics of the BS
reporting tool and upgrades the generic method for del. 05.04
Academic partner XX examines the documentation of the appraisals and the metrics of the BS plus the
results of 05.04 and upgrades the generic method for del. 05.05
Deliverables (brief description) and month of delivery
05.01 CMMI based maturity deployment for rapid PHR schemas adoption
Taken in to account the 04.01 deliverable a CMMI based maturity deployment detailed action plan is
carried out (see par. ―The technology grid: the key to optimal PHR use and adoption‖, extrovert phase).
The study is based on patient networks‘ members experience of HSP ―near‖ to the initial FIGHT nodes
(as described in the extrovert phase)
05.02 Seamless Management Health Provision Reengineering for rapid PHR schemas adoption
Based on the findings of both 04.01 and 05.01 a flexible reengineering scenario for rapid PHR schemas
adoption aimed at HSPs is created as described from patients in 05.01. The scenarios respect minimal
reengineering interventions for optimal results (meaning the provision of EHR / EMR APIs) focusing
on management decision making and vertical implementation of such decisions at the level of both the
medical staff and the IT department.
05.03 Balanced Scorecard Deployment for rapid PHR schemas adoption
A balanced scorecard application is undertaken on based the scenarios of 05.02 with the purpose of
fine tuning the vertical decision flow bringing awareness on all levels of related staff of the HSP
05.04 “A flexible Scenario Based Workflow Management method for rapid adoption of foreign
PHR schemas in a hospital’s mainframe management system”
A robust method of Scenario Based Workflow Management is created based on the findings of dels
04.01, 05.01-04. The method is the walkthrough for carrying out the extrovert phase (see par. ―The
technology grid: the key to optimal PHR use and adoption‖, extrovert phase). The method is aimed at
the managerial and medical staff of the HSP that have to be implicated in any effort towards Health IT
maturity of any HSP
05.05 “A CMMI based maturity framework for Health Informatics initiatives deployment”
A robust method of CMMI based maturity framework is created based on the findings of dels
04.01, 05.01, 05.03 and 05.04. The method is the walkthrough for carrying out the extrovert phase (see
par. ―The technology grid: the key to optimal PHR use and adoption‖, extrovert phase). The method is
aimed at the IT department (and related technical) staff of the HSP that have to be implicated in any
effort towards Health IT maturity of any HSP
Work package
number
6
Work package title
Organic IT Scorecard Monitoring subsystem
Objectives
To develop a functional Balanced Scorecard performance model to diffuse knowledge from
software architects and developers to end-users and vice versa.
Description of work (possibly broken down into tasks) and role of partners
30
Academic Partner XX and Health IT company XX design the Balanced Scorecard functional model
custom made for the application area of the FIGHT project
Health IT Company XX installs the *open source* Balance Scorecard reporting software
Patient Networks and Health IT Company XX fine tunes the installation of the BC software
Deliverables (brief description) and month of delivery
06.01 Self-replicating organic IT deployment for PHR based Health Informatics applications
The scenarios of the FOEG‘s visits (as described in par. ―The technology grid: the key to optimal PHR
use and adoption‖, organic expansion phase) are created based on and enriching the findings of WP05.
The deployment includes any technical related alterations that might appear following the description
of par. ―The technology grid: the key to optimal PHR use and adoption‖, Organic IT
06.02 “A balanced scorecard monitoring system under an organic IT deployment framework”
A balanced scorecard application is undertaken on the scenarios of 06.01 with the purpose of fine
tuning the vertical decision flow bringing awareness on all levels of related staff supporting the FOEGs
visits, ranging from the steering committee of the project to the last FOEG member.
Work package
number
7
Work package title
F.I.G.H.T. network base Integration
Objectives
To expand the FIGHT network
To attract the maximum number possible of candidate FIGHT nodes
To upgrade the software components of the FIGHT to alpha version
Description of work (possibly broken down into tasks) and role of partners
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.
Deliverables (brief description) and month of delivery
07.01 F.I.G.H.T. network base Integration
A full fact finding report on the status of all FIGHT nodes: initial (del. 04.02) and candidate (WPs 6
and 7) will be carried out. The report will update all variables and indicators of the reporting tools both
CMMI and Balanced scorecard and will be accompanied by a) An mid-project evaluation report and b)
31
An mid-project ―Alterations and Alignment‖ action plan
07.02 “PHR Connect” Electronic Marketplace and Interoperability Repository: Alpha Version
The alpha version of del. 04.03
07.03 “Health Hippo: Health Informatics Interoperability Developers’ Community”
Collaboration Portal: Alpha Version
The alpha version of del. 04.04
07.04 “Euterpe: Regional, National and European PHR Adoption Methods and Guidelines”
Collaboration Portal and Digital Library: Alpha Version
The alpha version of del. 04.05
07.05 “A Multichannel Asynchronous Information Flow and Verification for Heterogeneous
Health Informatics Systems Interoperability”
The dels of WP03 in the cloud in a unified service
07.06 “A unified SSO web service in a heterogeneous Health Informatics Technology Grid in a
distributed cloud environment”
The del. Of 07.06 in a secured environment
Work package
number
8
Work package title
e-Health Social Marketing PHR adoption framework
Objectives
To embody the discipline of Social Marketing into the projects knowledge base
To investigate the role of social marketing techniques in PHR adoption
To develop a toolbox for any PHR related project that is focused on adoption
Description of work (possibly broken down into tasks) and role of partners
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
Deliverables (brief description) and month of delivery
08.01 “Societal Impact of electronic Health Applications: The breakthroughs perspective”
workshop
A fact finding report accompanied by a comparative study of the core Health Informatics applications
focused on their societal impact. Both EHR/ EMR and PHR sides will be examined from all
stakeholders‘ point of view. EHR/ EMR applications will primarily examined for the impact they
brought to a) HSP staff change of practice and b) the public in general as hospitalized patients
including pre and post hospitalization behavior and impact. PHR applications will be examined from
32
the human centered point of view treating HSPs and the related services as satellite factors of a pure
human centered study of societal behavior and impact including behavioral patterns for post trauma
treatments and treatments for chronic diseases.
08.02 “A policy makers’ toolbox for rapid PHR adoption”
A policy makers‘ toolbox will feature all societal aspects from the impact point of view of the rapid
adoption of PHR technologies. The study will include all levels of governance, regional, state and
European and will provide the policy makers with all crucial decision making documentation and
decision support tools aligned towards measurable benefits for a selected and representative pool of
communities. A comparative study will feature the importance of including patient networks‘
representation and participation in the decision making process from the early stages of policy making.
08.03 “The Societal Impact of m-health applications in Europe”
M-health informatics and services are much easier to adopt services mainly due to the
straightforwardness and simplicity of m-applications in general. The m-Health context will be
examined with emphasis given on the adoption barriers m-health informatics can penetrate based
exactly on their simple technology and business functional models.
Work package
number
9
Work package title
F.I.G.H.T. network “follow me” PHR demonstrations
Objectives
To document the red-tape barriers of rapid PHR adoption on behalf of the HSPs in the project
members‘ regions
To document the red-tape barriers of rapid PHR adoption on behalf of the HSPs in the project
members‘ states
To carry out of a fact finding report on red-tape barriers of rapid PHR adoption on behalf of
the HSPs in the EU
To perform proof of concept measurable results of red-tape barriers of PHR adoption in
specific regions of the EU based on real life patient visits scenarios and metrics from the
Patient Networks to the project members‘ HSPs
Description of work (possibly broken down into tasks) and role of partners
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
Deliverables (brief description) and month of delivery
09.01 Red tape obstacles regarding the rapid adoption of PHR Health Informatics Services at
the regional level
A fact finding report dealing with all red-tape barriers that the project had to deal with during the basic
integration of the FIGHT network accompanied by a comparative study of red-tape obstacles of the
first FIGHT nodes emphasizing on locality.
33
09.02 Red tape obstacles regarding the rapid adoption of PHR Health Informatics Services at
the state 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 national legislation.
09.03 Red tape obstacles regarding the rapid adoption of PHR Health Informatics Services at
the European 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 EU legislation.
09.04 F.I.G.H.T. network “follow me” PHR demonstrations exhibition
Full reports of the FOEGS visits as described in section 1.2 and based on the methods and scenarios of
all previous WPs (depending on the characterization of the HSP they visit: initial or candidate FIGHT
node or non-FIGH node).
Work package
number
10
Work package title
F.I.G.H.T. network sustainable expansion field scenarios implementation
Objectives
To expand the FIGHT network in a sustainable way
To attract the maximum number possible of candidate FIGHT nodes
To upgrade the software components of the FIGHT to beta version
Description of work (possibly broken down into tasks) and role of partners
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.
Deliverables (brief description) and month of delivery
10.01 F.I.G.H.T. network functional prototype
An analytical presentation of the FIGHT network: The FIGHT nodes and the candidate ones. The
presentation will include at least the following: a) Analytical documentation of all procedures followed
for setting up the network: a) CMMI appraisals, b) Balanced Scorecard documentation, c) Guidelines
for HSP staff (both IT and medical), d) Handbooks for PHR Use custom made for each project member
state, e) Policy guidelines for decision makers for all project member states.
10.02 “PHR Connect” Electronic Marketplace and Interoperability Repository: Beta Version
34
The beta version of del. 04.03
10.03 “Health Hippo: Health Informatics Interoperability Developers’ Community”
Collaboration Portal: Beta Version
The beta version of del. 04.04
10.04 “Euterpe: Regional, National and European PHR Adoption Methods and Guidelines”
Collaboration Portal and Digital Library: Beta Version
The beta version of del. 04.04
10.05 “A flexible Scenario Based Workflow Management method for rapid adoption of foreign
PHR schemas in a hospital’s mainframe management system ”
A unified method following the best practices from the work done to set up the FIGHT network. The
method will be targeted at HSP staff functioning as a handbook for rapid adoption of PHR schemas to
all related audience: board of directors (management), medical staff, technology staff (IT) and others.
10.06 “A Hybrid Unified Software Development Model for both Open Source and Proprietary
Health Informatics distribution channels”
Development of the supporting cloud services
10.07 “Fighting Red Tape obstacles in Health Informatics adoption at the regulatory and
governmental level: Guidance and methodological tools for the regional, state and European
stakeholders”
Guidance and methodological tools for policy makers and executioners. The documentation will
include discrete methods and guidelines for Regional, State and European levels and will be
accompanied by a comparative study for all project member states.
Work package
number
11
Work package title
Case Studies
Objectives
To test the knowledge acquired from the work so far with a wide variety of ―real life‖ case
studies
Description of work (possibly broken down into tasks) and role of partners
In the countries where FIGHT nodes are realized and tested, case studies will be performed.
Each case study aims at:
1. a description and analysis of the infrastructure of the country and/or region of the FIGHT node
regarding:
- Data exchange of patient data between health care providers, and Health informatics maturity;
- Data exchange between patients and health care providers (to what extent do patients have
access to their medical data);
- Internet use by patients (different target groups, such as patients with chronic conditions,
patients with low SES) related to health information and health services;
- PHR and eHealth initiatives
- Governmental policy and regulations on health care, health IT (including national standards
for Health informatics systems) and privacy.
- Financial issues (how is health care reimbursed, and how are Health IT innovations
stimulated)
35
2. an analysis of stakeholder perspectives:
- Expectations and experiences of patients who have a PHR, or would like to have one;
- Expectations and experiences of health care providers (e.g. regarding patient-doctor
relationship)
- Perspective of stakeholder groups such as patient organizations and health insurers
The case studies use mainly qualitative methods, such as document analysis, interviews and focus
groups.
The results of the case studies will be input for the other work packages, especially the WPs that
deliver the toolbox.
Deliverables (brief description) and month of delivery
Contribution by the Netherlands team
Work package
number
12
Work package title
Dissemination Activities
Objectives
To diffuse knowledge acquired by the project by means of scientific workshops and confeenes
Description of work (possibly broken down into tasks) and role of partners
Coordinator Partner organizes the workshop and the conferences
All partners contribute to the workshop and the conferences of the project
Deliverables (brief description) and month of delivery
12.01 A initial setup of prototype PHR centric Health Informatics
An analytical report of the ICT technology used to attain human centric / PHR Health Informatics
applications for the FIGHT network initial setup. All ICT technology entities will be examined stating
the rationale of the particular set up, the core and complimentary know-how demanded for the
endeavor, the architectural choices for both the grid itself and the software modules of the cloud
services, the particularities of information sharing and security focusing on the use case of the ―patient
consent‖ use case etc.
12.02 F.I.G.H.T. network initial setup stakeholders’ workshop
A two days international Health informatics workshop will be held to discuss with international
Health Informatics experts the findings of del. 11.01
12.03 “PHR-centric European Technology Grids” Conference A
A mid-term Conference will be held to present the mid-term result of the project as long as the main
challenges and breakthroughs of the project team up to that point of time.
12.04 “PHR-centric European Technology Grids” Conference B
The final Conference of the project
36
Section 2. Implementation
2.1 Management structure and procedures
Principals
Agile project management: this requires putting in place an infrastructure to allow partners to
communicate (blog and mailing list for informal communication, wiki and shared documents for
structured collaboration, ―subversion‖ tools for version control of all types of internal documents,
deliverables and software produced in the course of the project) and a project management
environment (to allow for measured tracking of the progress in time and in budget of the project, as
well as specific tools such as for bug-tracking); following the progress and assessing the results
(through measured criteria as well as feedback from users); coordinating remote (teleconferencing)
and physical meetings between the partners and when needed with external groups (such as users, or
clustering meetings); reporting (to the partners, to the Commission); conflict identification and
resolution.
Legal framework: this includes collecting precise information concerning actual contents held and
which could be provided, in total or in part, by the partners content providers; determine the
stakeholders (patient organizations) in each country with whom existing and future partners have to
negotiate; provide recommendations for various technical implementations that could be proposed to
the stakeholders in order to obtain more advantageous distribution rights (excerpting audio,
streaming, etc.).
Implementation framework: this includes surveying the existing systems holding the HSPs.
Usability studies: they include analyzing existing uses (see ―metadata modeling‖ above); analyzing
the uses of the implemented framework once it is put in place; constituting a users‘ advisory group
(patient networks to comment on the recommendations of the consortium.
Dissemination: as soon as specific results become available, such as the common model, partners
will coordinate their dissemination activities: selection of conferences in which to propose specific
workshops and other presentations; of workgroups to which to send representatives; of targeted
mailings of information on the project and on the requirements to join it.
Steering Committee
A Steering Committee will be appointed by the partners of the project. All partners will be represented in
this committee lead by the project coordinator (PARTNER 1). The steering committee will appoint a
project manager to carry out the project control procedures.
Project manager
The project manager will be responsible for the integrity of the project work plan. The project manager
will be operating with the help of two assistant project managers, one responsible for the internal
communications (among the partners) and the other for the external communications (the dissemination
activities). The project control procedures are as follows:
Project Control Procedures
37
A Project plan document and a Project log will be created and Project control procedures will be
described in respective sections. This allows precise adjustment of these procedures to project scale,
organization and other project specific requirements.
Quality Control
A quality control procedure will ensure that the product meets the expectations of all interested
parties. It will be composed of the following elements:
numeration of quality standards relevant for the project
Scope and procedure of planned reviews (document reviews, code reviews, project reviews)
Description of planned testing
Unit tests, usually performed by developers
System tests, performed by QA department according to Test Plan document
Performance tests (environment, assumptions, tools applied)
Procedure of using issue tracking tools
Progress Control
Regular project team meetings will be held producing progress reports on a weekly, monthly and
quarterly basis.
The agenda of each meeting will include:
Status of the last week‘s action items
Status of each project member‘s tasks
Important events that occurred the previous week
Planning action items for the current week.
The consortium coordinator is responsible for the preparation of the monthly status report and
sending the report to the Steering Committee members. The report will highlight progress over
the reporting period, any issues that have arisen, forecast milestones, and expected progress over
the next reporting period.
Communication flow and documentation
The Coordination Team will meet all WP leaders and Team Managers by multiple teleconferencing at
least every two months, where they will report on the progress of the project and discuss important issues.
Communication will be aided by face-to-face meetings in accordance with travel plans. These reports and
content of project meetings will be the basis for bi-monthly reports from the project coordinator to the
EC.
Participants will be encouraged to work under short-term arrangements at the headquarters of different
partners. The mobility of developers will facilitate integration and communication, and has already been
shown to be effective in prior EU projects. A schedule will be devised and these internships, typically of 1
to 2 months will be arranged based on practicality and need.
A restricted mailing list has been operative since the inception of the project, and will be used for generic
day-to-day communication. More focused lists will be organized as soon as the main flows of specific and
technical communication (for example: integration issues, user management issues, etc.) have been
identified.
The project will be managed by means of a web-based collaborative space with the appropriate
organizational structure and access restrictions. This will make it possible to share calendars and issue
reminders for periodic events (reports, conference deadlines, etc.). Office software will be used to track
the project status, including maintenance of Gantt charts and accounting spreadsheets. Document drafts
may be edited by relevant partners with the use of version tracking facilities.
38
A secure code repository will be set up at the project kick-off. WIKI tools will be used for collaborative
document development and discussion. The repository will not be publicly accessible during the project,
though repositories will be made accessible to the public as an outcome.
A Consortium Agreement will be signed by all the partners before the outset of the project. This will
cover in detail issues, exploitation, and responsibilities.
Conflict Resolution
The project has been carefully prepared as a collaborative effort from all partners in order to prevent
conflicts between them. Forthcoming documents will be created with the same attitude and purposes.
Nevertheless, if problems arise, they will be reported to the project manager as early as possible. If
necessary, the Steering Committee will be called. Conflict resolution will be approached by consensus or,
if necessary, by voting. In the case of irreconcilable disputes, the conflict procedures that will be
described in the Consortium Agreement will be adopted.
Change management
A change control procedure will control the addition of work to the originally planned activities
in order to achieve a balance between the need to improve quality by changing the project
cThese and the need to successfully complete the activities as scheduled.
An issue becomes a subject of the change control procedure whenever coordinator of the
consortium identifies it as a change in the project scope, schedule or budget. The change control
procedure will be comprised of the following steps:
Submission of a change request and identification of its scope
Agreement about possible impact of the change for the project scope, schedule and budget
Decision about acceptance or rejection of the change followed by, if necessary (i.e. if
tolerance parameters are exceeded), an update of the project schedule and or budget
Implementation of the accepted change by the project team
The procedure also defines people (roles) responsible for each step. All steps are documented in
the Project Log document.
Risk Management
Risk management procedures are documented and supported with the use of the Project Log.
The risk information is updated at least biweekly. Activities performed within the procedure are
summarized below.
Risk Assessment
Item Description
Risk
identification
List of risks that can potentially jeopardize project cost and/or
schedule
Risk analysis Assessment of the risk to the cost and schedule of the project
Risk
prioritization
List of risks that need to be dealt with first in order to minimize
their impact
Risk Control
Item Description
Risk
management
planning
Defining planned actions for each individual risk
39
Risk resolution Executing planned actions to mitigate risks
Risk monitoring Monitoring status of each risk resolution
Quality Assurance Plan
A Quality Assurance (QA) Plan will be applied to all internal and external services and deliverables.
Quality assurance is the joint responsibility of all partners during the project lifetime. The goal of the QA
plan is to ensure detection of errors as early as possible, applying planned and systematic activities to
determine and ensure achievement of quality objectives. Non-conformance to QA Plan will be
documented, and corrective actions applied.
The project manager has the authority for implementing and verifying compliance with all quality
evaluation policies and procedures related to the project. The following is a non-exhaustive list of QA
tasks that will be performed:
Develop the QA Plan, develop QA project instructions, procedures, checklists and reports.
Monitor project development to ensure that initial project goals are met in time and on budget.
1. Review internal and external deliverables for consistency, clarity, content, and adherence to the QA
plan. An internal review process will be defined and applied to each deliverable prior to its delivery to
the EU.
2. Conduct audits of processes prior to each development phase of the project, and assure existence of
specifications for each phase.
QA documentation will be maintained electronically and be accessible by partners through the collaborative
software tool that will be adopted, and also through the restricted web site pages.
Section 3. Impact
3.1 Expected impacts listed in the work programme
Health care now needs leaders who are able both to anticipate and manage strategic organizational change
incorporating appropriate information and communication technologies. They must be able to establish
an effective ‗fit‘ between the needs of clinical work, the health care system and information and
communication technologies.
Research and evaluation studies have shown how difficult it is to integrate such rapidly developing
information and communication technologies, not only into clinical practice but also at the operational
level.
Identifying information requirements, choosing, procuring and implementing such rapidly developing
technologies have a social as well as a technical dimension. It is only relatively recently that the extent of
this social and individual dimension has been recognized as critical to the successful implementation of
health and medical systems and the realization of their benefits. This philosophy underpins the design of
the programme which brings together elements of technical, clinical and organizational issues in a
pragmatic framework.
In all aspects of health care it is recognized as good practice and ethically important that technologies,
methods, and interventions are evidence-based. In other words, that they are proven to be safe and
effective, against other methods and alternative solutions.
40
When it comes to decisions whether and how best (if at all) to use IT systems for a particular task in the
health care delivery process, opportunities and options can only be appraised objectively by reference to
scientific evidence. This is dependent on the building up of a body of published scientific findings, which
is currently sadly lacking in volume and coverage given the importance and impact of health informatics
on modern healthcare practice and delivery.
There was a growing list of failed efforts to realize the benefits of IT in healthcare in the recent years,
unfortunately this continues to be true. There are numerous reasons for this including the following gaps:
People gap: A shortage of skilled Health Informatics professionals to assist in planning and
implementing health information systems and health information management strategies. At
present, demand exceeds the supply of Health Informatics professionals. The historical
investments in health IT have not had any significant prior investment in developing a stable and
skilled Health Informatics workforce. The potential available budgets for current projects
represent a workload well in excess of that supportable by the available pool of Health
Informatics professionals.
Decision Maker Skills Gap: despite the increasing number and scope of IT based initiatives in
healthcare, many health care administrators and government decision makers have little
understanding of success factors and risks in Health Informatics projects, nor is there a clear
understanding of the skills required to support these projects in delivering on time, on budget with
systems that represent real improvements in efficiency and safety.
Implementation gap: Consequently, there is a variable skill level in those that do become
involved in Health Informatics projects. Project failure is often related to poor implementation,
reflecting an absence of mature experience in deployment of complex information systems in the
health setting.
Change management gap:-Many projects fail as insufficient study of workflow has taken place
especially in clinical settings. Clinicians won‘t use systems when additional time is required for
making use of the system or where a change in work practice is required unless they fully
appreciate the benefits.
Research gap: Projects also fail because they break basic Informatics ‗rules‘. Many, for example,
are implemented in the mistaken belief that ‗technology‘ is the answer, rather than first focusing
on problem definitions at a system level, and evolving appropriate information solutions,
grounded in the science of informatics. Health Informatics is relatively young as a formalised
discipline, and the basic Health Informatics ‗rules‘ are necessarily a work in progress. There is
thus a very real need to foster research
Clinical education gap: Clinically, there is also a growing need for individuals to develop skills in
Health Informatics. Specifically, health professionals need to be trained in new information
technology skills, both to successfully harness the benefits of the new technologies, as well as to
adopt evidence-based and safe work practices. The consequence of a clinical workforce that is
under skilled in core informatics techniques like evidence-based information retrieval, use of
computerised prescription systems or electronic medical records, or communication technologies
like email or the Web, means that many options for widespread system improvement are
hampered.
Changes that the present project may bring should entail the following:
A major shift towards systems that serve patients and the public to help them to stay healthy, drive better
care, improving outcomes, innovation and the better use of resources. Transforming the way information
is collected, analysed and used by the EU and health care services.
The focus on outcomes will align efforts across the EU health care services on what really matters:
improving the lives of patients and service users. A culture of a responsible safety and accountability
policy against outcome measures will need to draw upon open, accessible information from a range of
sources.
41
The publication of the research results both locally and nationally will be more freely available to
encourage innovative information providers, such as patient and service user charities, to better inform
the public. Some indicative use cases that promote societal impact of the present project should be:
a. Monitor health status to identify community health problems.
b. Diagnose and investigate health problems and health hazards in the community.
c. Inform, educate, and empower the public about health issues.
d. Mobilize community partnerships to identify and solve health problems.
e. Develop policies and plans that support individual and community health efforts.
f. Enforce laws and regulations that protect health and ensure safety.
g. Link people to needed personal health services and assure the provision of services that
promote health when otherwise unavailable.
h. Monitor health status to identify community health problems.
i. Diagnose and investigate health problems and health hazards in the community.
j. Inform, educate, and empower the public about health issues.
k. Mobilize community partnerships to identify and solve health problems.
l. Develop policies and plans that support individual and community health efforts.
m. Enforce laws and regulations that protect health and ensure safety.
n. Link people to needed personal health services and assure the provision of services that
promote health when otherwise unavailable.
Furthermore, an indicative list of follow jup research based on the result of the present project is the
following:
Biostatistics – the development and application of statistical reasoning and methods in addressing,
analyzing, and solving problems in public health; health care; and biomedical, clinical, and
population-based research.
Environmental Health Sciences – the study of environmental factors including biological,
physical, and chemical factors that affect the health of a community.
Epidemiology – the study of patterns of disease and injury in human populations and the
application of this study to the control of health problems.
Health Policy and Management – a multidisciplinary field of inquiry and practice concerned with
the delivery, quality, and costs of health care for individuals and populations, assuming both a
managerial and policy concern with the structure, process, and outcomes of health care services
including the costs, financing, organization, outcomes, and accessibility of care.
Social and Behavioral Sciences – the behavioral, social, and cultural factors related to individual
and population health and health disparities over the life course, including research and practice
that contributes to the development, administration and evaluation of programs and policies in
public health and health services to promote and sustain healthy environments and healthy lives for
individuals and populations.
Communication and Informatics – the ability to collect, manage, and organize data to produce
information and meaning that is exchanged by the use of signs and symbols; to gather, process and
present information to different audiences in-person, through information technologies, or through
media channels; and to strategically design the information and knowledge exchange process to
achieve specific objectives.
Diversity and Culture – the ability to interact with diverse individuals and communities to
produce or impact an intended public health outcome.
Leadership – the ability to create and communicate a shared vision for a changing future;
champion solutions to organizational and community challenges; and energize commitment to
goals.
Professionalism – the ability to demonstrate ethical choices, values and professional practices
implicit in public health decisions; consider the effect of choices on community stewardship,
equity, social justice and accountability; and to commit to personal and institutional development.
42
Program Planning – the ability to plan for the design, development, implementation, and
evaluation of strategies to improve individual and community health.
Public Health Biology – the biological and molecular context of public health.
Systems Thinking – the ability to recognize system level properties that result from dynamic
interactions among human and social systems and how they affect the relationships among
individuals, groups, organizations, communities and environments.
Section 4. Ethical Issues
General Principles of Informatics Ethics
These fundamental ethical principle, when applied to the types of situations that characterize the
informatics setting, give rise to general ethical principles of informatics ethics.
1. Principle of Information-Privacy and Disposition
All persons have a fundamental right to privacy, and hence to control over the collection, storage, access,
use, communication, manipulation and disposition of data about themselves.
2. Principle of Openness
The collection, storage, access, use, communication, manipulation and disposition of personal data must
be disclosed in an appropriate and timely fashion to the subject of those data.
3. Principle of Security
Data that have been legitimately collected about a person should be protected by all reasonable and
appropriate measures against loss, degradation, unauthorized destruction, access, use, manipulation,
modification or communication.
4. Principle of Access
The subject of an electronic record has the right of access to that record and the right to correct the record
with respect to its accurateness, completeness and relevance.
5. Principle of Legitimate Infringement
The fundamental right of control over the collection, storage, access, use, manipulation, communication
and disposition of personal data is conditioned only by the legitimate, appropriate and relevant data-needs
of a free, responsible and democratic society, and by the equal and competing rights of other persons.
6. Principle of the Least Intrusive Alternative
Any infringement of the privacy rights of the individual person, and of the individual‘s right to control
over person-relative data as mandated under Principle 1, may only occur in the least intrusive fashion and
with a minimum of interference with the rights of the affected person.
7. Principle of Accountability
Any infringement of the privacy rights of the individual person, and of the right to control over person-
relative data, must be justified to the affected person in good time and in an appropriate fashion.
These general principles of informatic ethics, when applied to the types of relationships into which HIPs
enter in their professional lives, and to the types of situations that they encounter when thus engaged, give
rise to more specific ethical duties. The Rules of Conduct for HIPs that follow outline the more important
of these ethical duties. It should be noted that as with any ethical rules of conduct, the Rules cannot do
43
more than provide guidance. The precise way in which the Rules apply in a given context, and the precise
nature of a particular ethical right or obligation, depends on the specific nature of the relevant situation.
A Code of Ethics for medical staff
Codes of professional ethics serve several purposes:
to provide ethical guidance for the professionals themselves,
to furnish a set of principles against which the conduct of the professionals may be measured, and
to provide the public with a clear statement of the ethical considerations that should shape the
behaviour of the professionals themselves.
A Code of Ethics should therefore be clear, unambiguous, and easily applied in practice. Moreover, since
the field of informatics is in a state of constant flux, it should be flexible so as to accommodate ongoing
changes without sacrificing the applicability of its basic principles. It is therefore inappropriate for a Code
of Ethics to deal with the specifics of every possible situation that might arise.
The patient is in a vulnerable position, and any decision regarding the patient and the EHR must
acknowledge the fundamental necessity of striking an appropriate balance between ethically justified ends
and otherwise appropriate means. Further, the data that are contained in the EHR also provide the raw
materials for decision-making by health care institutions, governments and other agencies without which
a system of health care delivery simply could not function. The medical staff therefore, by facilitating the
construction, maintenance, storage, access, use and manipulation of EHRs, play a role that is distinct from
that of other informatics specialists.
At the same time, precisely because of this facilitating role, medical staff are embedded in a web of
relationships that are subject to unique ethical constraints. Thus, over and above the ethical constraints
that arise from the relationship between the electronic record and the patient, the ethical conduct of
medical staff is also subject to considerations that arise out of the medical staff s‘ interactions with Health
Care Professionals (HCPs), health care institutions and other agencies. These constraints pull in different
directions. It is therefore important that medical staff have some idea of how to resolve these issues in an
appropriate fashion. A Code of Ethics for medical staff provides a tool in this regard, and may be of use in
effecting a resolution when conflicting roles and constraints collide.
Duties towards HCPs
HCPs who care for patients depend on the technological skills of their staff in the fulfilment of their
patient-centred obligations. Consequently, medical staff have an obligation to assist these HCPs insofar
as this is compatible with the medical staff‘ primary duty towards the subjects of the electronic records.
Specifically, this means that
Assistance to patients
a. to assist duly empowered HCPs who are engaged in patient care in having appropriate, timely and
secure access to relevant electronic records (or parts of thereof), and to ensure the usability,
integrity, and highest possible technical quality of these records; and
b. to provide those informatics services that might be necessary for the HCPs to carry out their
mandate.
Collaborate with the HCPs’ IT Staff
Medical staff should keep HCPs informed of the status of the informatics services on which the HCPs
rely, and immediately advise them of any problems or difficulties that might be associated or that could
reasonably be expected to arise in connection with these informatics services.
44
a. Medical staff should advise the HCPs with whom they interact on a professional basis, or for
whom they provide professional services, of any circumstances that might prejudice the
objectivity of the advice they give or that might impair the nature or quality of the services that
they perform for the HCPs.
b. HIPs have a general duty to foster an environment that is conducive to the maintenance of the
highest possible ethical and material standards of data collection, storage, management,
communication and use by HCPs within the health care setting.
Intellectual Property
Medical staff who are directly involved in the construction of electronic records may have an intellectual
property right in certain formal features of these records. Consequently, HIPs have a duty to safeguard
a. those formal features of the electronic record, or
b. those formal features of the data collection, retrieval, storage or usage system in which the
electronic record is embedded in which the HCP has, or may reasonably be expected to have, an
intellectual property interest.
Personal data for public good: using health information in medical research
Respect for private life and confidentiality
The fundamental right to respect for private life and the legal obligation of confidentiality protect the
dignity, autonomy and reputation of citizens, spare them unwanted intrusion, and preserve their trust in
the medical system. Various EU member states‘ law endorses all these reasons for the protection of
confidences and privacy in health care. However, it draws attention to the need to focus in a close and
exacting way on other public interests, in particular the public interest in secondary data research—that is,
research based on data originally collected for a purpose other than research which does not involve
interaction with the patient.
Secondary data Research
Secondary data research identifies important causes of disease and epidemics, demonstrates the long-term
effects of treatment, and helps improve the provision of services. Its secondary nature means that very
large numbers of patients can be studied with complete coverage of particular populations, producing
more reliable results. The duration and costs of the research are also reduced relative to ‗primary‘
research. The area of research most affected is large scale epidemiological studies.
Difficulties with Consent
Research often takes place at a distance, both temporally and geographically, from the collection of the
data. As a result, the person communicating with the subject is probably someone other than the
investigator (thus in a poor position to seek consent) and the issues warranting research may not be
known until later.
Difficulties with Full-Anonymisation of Data
Full-anonymisation is often impracticable because identifiable data is needed to assess/avoid double-
counting, for longitudinal research which adds data to existing records, for linkage between data sets, to
validate data by cross-checking a sample of electronic records against paper records, when identifiers
contain information useful to the research (e.g. postcodes, ethnic origins of a surname), when
anonymisation is too laborious, and when the data is unusual (e.g. rare diseases). The burden of
constructing and managing partially anonymised data sets is considerable, and often determines the
quality of the subsequent research.