NATHCARE Model description - Alpine Space Programme 2007-2013

NATHCARE
Model Description
The value of health and well-being
An integrated approach to patient centred care
REPORT 1
Model_1.indd 1
07/03/14 11.29
1
SUmmary
MODEL DESCRIPTION
INTRODUction
NATHCARE
1
INTRODUCTION Nathcare
pag 3
2
MODEL DESIGN METHODOLOGY
pag 4
NATHCARE (Networking Alpine Health
User Requirements
Groups of functionalities and Functional Subset
Local Context of Functional Subset
for Continuity of Care Project) is a
The project aims to
3
THE NATHCARE MODEL
project co-funded by the Alpine
design, consolidate and
pag Space Programme 2007-2013,
validate a “healthcare local
6
Standalone Solution
Integrated Solution
Own application (Standalone Site)
Nathcare Model implementation at Pilot Sites
community” based model
embracing all the players of the
care system for securing a sustainable
and improved organizational adaptation
4
CAPITALIZATION OF ALIAS
IN THE NATHCARE PROJECT of healthcare services.
pag 10
that addresses the theme
of demographic change in
the framework
of public services
devoted
to healthcare
provision.
The project is capitalising on the ALIAS project 1,
The alias project
Nathcare re-use of alias components
and targets the process for a hospital-territory
integration addressing mainly long term diseases
5
CONCLUSIONS in the perspective of continuity of care
pag 14
as dimension of the demographic change.
NATHCARE
Model Description
Authors:
Natalia Allegretti**
Antoine Geissbuhler*
Caroline Perrin*
Nicolas Roduit*
Stéphane Spahni*
*Hôpitaux Universitaires
de Genève
**Lombardia Informatica S.p.A.
This document is
a publishable summary of
the Deliverable D5.1
Model Design of the
NATHCARE Project.
www.nathcareproject.eu
1) www.aliasproject.eu
3
Model_1.indd 2-3
07/03/14 11.29
2
2
MODEL DESIGN
METHODOLOGY
2.2 Groups of
functionalities
and Functional Subset
The Methodology of the NATHCARE Model Design is
provided in the figure below.
Based on the results of the project Users Requirements
analysis, as a first step, a NATHCARE Functional Subset
has been defined.
The purpose of this functional subset was to summarise
the requirements in order to facilitate the analysis
process of the local context in the next step.
Based on the output of the analysis the NATHCARE
Model has been designed.
MODEL DESCRIPTION
In order to analyse concretely
the integration needs and
possibilities at each site, five groups
of functionalities were proposed, with
increasing complexity for integration2.
To cover the three project dimensions (Primary
Care Integration, Knowledge Management, Patient
Empowerment) pilot sites should at least
implement: 1 and 2; + 3 or 4; or 5
(which covers all
the previous).
Group
5
Group
4
Group
Group
3
1
Group
2
These five groups are:
NATHCARE
Model
Local
context analysis
Functional Subset
(Groups 1-5)
D4.1 User
Requirements
Figure 1
Overview WP5 Methodology
2.1 User Requirements
The results of the Users Requirements analysis has been summarised as ‘Functional Subset for the First Phase of
Analysis and Implementation’. This subset defines functionalities to be analysed and implemented in a first phase of
development of the NATHCARE project.
The subset includes the following functionalities (see Figure 3 for details):
•A knowledge management and sharing tool (Knowledge Management).
•An authoring tool to create care plan templates (Care Plan Definition Manager & WebApp).
•An engine to instantiate and execute care plans for a specific patient (Care Plan Instance Manager).
•A web interface for healthcare professionals to interact with the care plan & with patients (Care Plan Instance
WebApp).
•A web/mobile interface for patients to access their care plan & interact with Health Care Professionals involved
(Patient WebApp, Mobile WebApp).
Group 1: a knowledge sharing and management
environment, aimed at facilitating collaborative work
for the collection of scientific literature and other
sources of knowledge for the elaboration of care plans.
This tool would not require any integration with existing
infrastructure (with the possible exception of the
identification of authorised users).
Group 2: an authoring tool aimed at creating
structured representations of care plan templates,
based on the NATHCARE data model, including the
ability to manage and link knowledge objects used
for decision-support or education. It is likely that this
functionality would reside on a central platform. Care
plan templates should be accessible for browsing and
download through a web-services API.
Group 3: a tool providing a web interface for the
instantiation and execution of care plans. It is likely
that this functionality will reside on a local platform.
Integration will include identification and authentication
of care providers, and access to patient registries for
selecting patients.
Group 4: is similar to Group 3, but provides
additional interfaces, for example, to import/export
care plan documents in order to implement the
persistence of such documents elsewhere than in the
NATHCARE component (for example in the local clinical
system). Other options could be to implement call-back
functionalities so that notification mechanisms (for
sending alerts or reminders as defined in a care plan)
could be provided by a non-NATHCARE component.
These functionalities were pooled into five Groups, which are described below.
Group 5: provides the ability to instantiate a care
plan template for a specific patient, to modify it, to
link documents, to check for alerts, etc., using only
web-services rather than a GUI. This highest form of
integration would use specific NATHCARE components
for business logic, but not for presentation. Presentation
and workflow would be provided by the local platform.
2.3 Local Context of Functional Subset
After defining the Functional Subset with the five
different Groups, the pilot sites of all Partners have been
visited by the Geneva University Hospitals (HUG) to get
an in-depth understanding of the local context for the
Functional Subset.
The purpose of the pilot-site visits by HUG was to
perform a Gap-analysis between the Users Requirements
identified by the project (more specifically the functional
sub-sets) and the existing architecture and tools, in
order to collect information for the creation of the
model including the Networks of Networks overarching
architecture for cross-community communication.
After having visited all pilot sites and analysed their
systems it was concluded that most Partners could
implement Group 1, 2 and 3, while Group 5 does not
seem feasible for any of the Partners.
The project technical versatility has been considered
necessary to be compliant with the different needs
and in particular the technical maturity of existing
infrastructures at the different pilot sites. Based on the
analysis of the local context three different technical
configurations of the NATHCARE Model have been
conceived and will be implemented as follows:
1) Standalone Solution for a number of pilots;
2) partially Integrated Solution for Geneva;
3) Own Solutions for Rhône-Alpes and Lombardy
connected to NATHCARE system.
2) Please be aware that Group 3 and 4 are exclusive: a pilot site
integrates either Group 3 or Group 4.
4
Model_1.indd 4-5
5
07/03/14 11.29
3
3
THE NATHCARE
MODEL
3.2 Integrated Solution
MODEL DESCRIPTION
The following graphs illustrate the three different possible scenarios of the implementation of the NATHCARE Model
at the pilot sites. Either a pilot site can implement the 1) Standalone Solution, which will be completely developed
by the NATHCARE technical team, or the 2) Integrated Solution, where components of the NATHCARE Standalone
Solution will be replaced by components that are available at the pilot site, or the 3) Own Application, where the pilot
site uses an already existing solution and integrates it with the Knowledge Management Tool developed within the
project.
Document Registry
Alias API
New API
4
6
5
3.1 Standalone Solution
The user is authenticated, a SAML token is
generated. A handle on the security token is
obtained from the ALIAS Server.
A security token is created on the Alias Central
Server and a handle on it is returned.
User’s profile is retrieved (patient/GP, if GP to
which patients it has access, …). User identification
is extracted from the SAML token.
The Execution Tool retrieves the patient’s demographic data. The Patient Registry is accessed
through the Application Programming Interface
(API) defined in ALIAS.
5 The Execution Tool retrieves / modifies / stores
the instantiated care plan. The Document
Registry is accessed through the API defined in
ALIAS, with an extension to be able to store a
document.
6 If documents are uploaded by the user, these
documents are stored locally. The Document
Registry is accessed through the same API as ( ).
7 Services from the knowledge manager are
being used. The API has to be clarified.
8 The knowledge manager may retrieve user’s
information from the ALIAS Server.
Care Plan Application
Anonymous
data
User’s data
Local site
1
2
3
4
Patient Registry
User Authorization
User Authentication
Alias Library
Patient’s data
Nathcare
development
3
Alias existing
component
Execution Tool
2
1
Alias extended
component
Site’s own
component
7
Patient Registry
User Authorization
3
4
Alias API
Anonymous
data
Local site
User’s data
Execution Tool
Patient’s data
User Authentication
Document Registry
Nathcare
development
central services
Standalone Care Plan Application
Alias
Central
Server
Knowledge
Management
Tool
Circle of Trust
8
Figure 3
Model: Local Integration with ALIAS Central Server
5
Alias Library
New API
1
6
Alias existing
component
7
Alias extended
component
central services
2
Alias
Central
Server
Knowledge
Management
Tool
Circle of Trust
8
Figure 2
Model: Standalone with ALIAS Central Server
6
Model_1.indd 6-7
The
user is authenticated, a SAML token is generated.
1
A handle on the security token is obtained from
the ALIAS Server. The user is then redirected to the
Execution Tool (URL redirect with SAML token &
handle as parameters).
2
A
security token is created on the Alias Central
Server and a handle on it is returned.
3 User Authorization is retrieved (patient/GP,
if GP to which patients it has access, …). User
identification is extracted from the SAML token.
The
Execution Tool retrieves the patient’s demo4
graphic data. The Patient Registry is accessed
through the API defined in ALIAS.
The
Execution Tool retrieves / modifies / stores
5
the instantiated care plan. The document
registry is accessed through the API defined in ALIAS,
with an extension to be able to store a document.
6 If documents are uploaded by the user, these
documents are stored locally. The document
registry is accessed through the same API as ( ).
7 Services from the knowledge manager are being
used.
The
knowledge manager may retrieve user’s
8
information from the ALIAS Server.
7
07/03/14 11.29
3
3
3.3 Own Application (Standalone Site)
1
2
3
4
5
Own Application specifications.
Optional: a security token is created on the Alias
Central Server and a handle on it is returned.
Own Application specifications.
Own Application specifications.
Own Application specifications.
6 Own Application specifications.
7 Services from the knowledge manager are being
used.
The
knowledge manager may retrieve user’s
8
information from the ALIAS Server.
3.4 NATHCARE Model implementation
at Pilot Sites
The Knowledge Management can communicate with
the Execution Tool that is developed by NATHCARE, or
with the Local Solution that is used by the Standalone
Sites.
The ALIAS Central Services are connected to the User
Authentication at each pilot site and can retrieve user
data in order to provide tailored content. It is important
to point out that the only non-anonym data that is
transferred out from the pilot sites to the ALIAS Central
Server is limited to the user’s local identifier, their role
and their speciality.
The figure below provides an overview on the
NATHCARE Network and its components, also
highlighting the capitalisation of the ALIAS Central
Services3. Details about the ALIAS project and its
capitalisation within NATHCARE are given in the next
chapter.
Figure 5 illustrates the NATHCARE Network and the
implementation of the Model. The Central Services,
which are the Knowledge Management and the ALIAS
Central Services, are in the middle of the illustration.
Standalone Care Plan Application
User Authorization
MODEL DESCRIPTION
3
4
Patient Registry
Anonymous
data
User’s data
Patient’s data
Local site
Execution Tool
UNIVERSITY HOSPITALS OF GENEVA
Nathcare
development
Alias existing
component
User Authentication
6
Alias Library
Document Registry
1
5
Nathcare
Connector
Site’s own
component
Patient
Mobile App
Local / Regional System
TRENTO HOSPITAL
Patient /
Document Registry
2
VILLACH
HOSPITAL
Patient /
Document Registry
Execution
Tool
User
Authentication
User
Authentication
Execution
Tool
Patient
Web App
User
Authentication
User
Authentication
Local/ Regional System
Local / Regional System
Local/ Regional System
Patient
Mobile App
Patient
Web App
ALTO FRIULI LOCAL
HEALTHCARE
COMMUNITY
Knowledge
Management
Tool
Circle of Trust
Local / Regional System
central services
Execution
Tool
Patient
Mobile App
7
Patient
Web App
Alias
Central
Server
Patient /
Document Registry
User
Authentication
Regional Oncology Network
Figure 4
Model: Own Application with ALIAS Central Server
Hôpital Privé Drôme Ardèche,
Valence
Clinique Mutualiste de Saint Etienne,
Saint Etienne
8
Alias
Central
Services
User
Authentication
Centre Léon Bérard,
Lyon
Local / Regional System
Local/ Regional System
Knowledge
Management
Local
Solution
GOLNIK
HOSPITAL
CHU Grenoble,
Grenoble
User
Authentication
Local / Regional System
BERGAMO
LOCAL HEALTHCARE
COMMUNITY
Local
Solution
Patient /
Document Registry
Execution
Tool
Patient
Web App
Patient
Mobile App
Patient /
Document Registry
Execution
Tool
Patient
Web App
Patient
Mobile App
User
Authentication
GARMISCH
PARTENKIRCHEN
HOSPITAL
VARESE
LOCAL HEALTHCARE
COMMUNITY
Patient /
Document Registry
Patient
Mobile App
Local
Solution
User
Authentication
User
Authentication
Execution
Tool
Local / Regional System
Patient
Web App
Figure 5
NATHCARE system Network Overview
8
Model_1.indd 8-9
9
07/03/14 11.29
4
4
MODEL DESCRIPTION
CAPITALIZATION
OF ALIAS IN THE
NATHCARE PROJECT
7
5
Execution
Tool
5
Browser
HUG
ALIAS
Connector
7
e-toile
Gateway
MDM
(e-toile)
ALIAS
Portal
7
IHE
4.1 The ALIAS Project
The ALIAS Project took place from August 2009 to
October 2012 and addressed medical services and
information inadequacy to ensure Health Care (HC)
provision in the Alpine Space (AS) where telemedicine
services are not widely exploited and language barriers
represent an obstacle.
The Alpine Space tourist vocation during some periods
of the year makes its Health Care structures periodically
inadequate in facing a larger demand of services. On
the other hand, larger structures during the rest of the
year are unnecessary due to the low density of Alpine
Space local residents.
A priority of ALIAS was to ensure fair access to HC public
services and related communication infrastructures
within the area covered by the programme.
The project linked together a number of AS hospitals
and enabled the creation of a Network of ALIAS
Virtual Hospitals (VH) to share medical information,
adopt telemedicine service and exchange best clinical
practices, to improve the efficiency of the hospitals in
that area. This project included 10 partners: Regione
Lombardia (Lead Partner), Regione Friuli Venezia Giulia,
Garmisch-Partenkirchen Hospital in Oberbayern, INSA
of Lyon and SISRA in Rhône-Alpes, the General Hospital
Izola and the University Clinic of Pulmonary and Allergic
Diseases of Golnik in Slovenia, the Regional Hospital of
Villach in Kärnten, the Geneva University Hospitals and
the Republic and Canton of Geneva, Department of
Economy and Health in Région Lémanique.
A priority of ALIAS was to ensure
fair access to HC public services
and related communication
infrastructures within the area
covered by the programme.
User
Authorization
1
4
LOGIN
REDIRECT
6
ALIAS
SAML
connector
2
3
get token
6
ALIAS
Central
Server
2
ALIAS established
a Virtual Hospital through
a network of hospitals.
4
The ALIAS Project
was a telemedicine
oriented pilot initiative
carried out at transnational
level and focused on the role
of hospitals in delivering healthcare
services at a distance.
1
2
login + sms
5
Browser
user
non-HUG
4.2 NATHCARE re-use of ALIAS components
The NATHCARE Project is capitalising on the ALIAS
experience and output by re-using components that
were developed to implement the ALIAS Central
Services.
An example of the re-use of ALIAS components is
described below in relation to the implementation of
the NATHCARE solution at the Geneva pilot site.
login, password, mobile nr.
organization, role
Local Connector
ALIAS COMPONENTS
Figure 6
System architecture of the Geneva pilot site
10
Model_1.indd 10-11
11
07/03/14 11.29
4
4
MODEL DESCRIPTION
User login in from inside HUG via the HUG Browser:
• Users that can log-in from the HUG intranet is an HUG employee, who is working from the HUG.
•The user opens the HUG Browser and navigates to the NATHCARE login page and
credentials (initials and password), while the smartcard is in the reader.
identifies himself with his HUG
•The Alias SAML connector validates the credentials with the HUG identification system
profiles).
(active directory + users
• If the user is validated a security token is demanded from the ALIAS Central Services ; the security token is kept
there, just a pointer on this security token is transmitted to the ALIAS SAML connector. The security token on the
ALIAS Central Server stores information like Function and Organization of the Healthcare Professional.
Figure 6 illustrates
the two possibilities
to log-in to NATHCARE,
either from the
HUG intranet,
or external.
•
The ALIAS SAML connector sends a redirect to the browser: next page to display on the browser is https://
NATHCARE… (outside the Circle of Trust, only the ID of the token is given), which is transmitted to the Application
that is part of the Circle of Trust.
•The application (either the Alias Portal or the NATHCARE Care Plan) retrieves the security token
Central Services: then the user is allowed to access the functions of the application.
from the Alias
• If the ALIAS Portal is accessed the Healthcare Professional enters the ID and birth date of the patient, sends the
IHE profile to the ALIAS Connector (see Chapter 4.2), then it goes to the web-service of the HUG interface of the
e-toile Gateway (the role of this gateway is to ease the communication between the connector and e-toile), after
MonDossierMedical.ch [MDG] (e-toile) is accessed and the information retrieved.
• If the NATHCARE Care Plan is accessed the user enters the ID and birth date of the patient, sends the request
through the Local Connector to the e-toile Gateway, after MonDossierMedical.ch [MDG] (e-toile) is accessed and the
information retrieved.
•These users go on the Geneva NATHCARE portal and log-on with their login (username, password) + sms
challenge
• , the ALIAS SAML connector, contains a database where the login, password, mobile number and organization of
the user are stored.
User login in for patients, non-HUG physicians,
or HUG physicians outside the HUG intranet:
• If the user is validated a security token is demanded from the ALIAS Central Services ; the security token is kept
there, just a pointer on this security token is transmitted to the ALIAS SAML connector. The security token on the
ALIAS Central Server stores information like Name, Function and Organization of the Healthcare Professional.
•The ALIAS SAML connector redirects the user
to the care plan
•The care plan takes the token from the ALIAS Central Server and, then the care plan can connect directly to the e-toile
Gateway (this is possible because the care plan is a local installation).
•After e-toile is accessed and the information retrieved.
12
Model_1.indd 12-13
13
07/03/14 11.29
5
MODEL DESCRIPTION
CONCLUSIONS
In order to align the requirements and to capitalize on
existing infrastructure and achievements from previous
projects a one-fits all solution was not sufficient.
As existing infrastructure, care processes and
requirements can strongly vary between countries
and/or pilot sites a multi-solution Model needed to be
developed.
Within the NATHCARE Model a pilot site can either
implement the 1) Standalone Solution, which will be
completely developed by the NATHCARE consortium,
or the 2) Integrated Solution, where components of
the NATHCARE Standalone Solution will be replaced
by components that are available at the pilot site, or
the 3) Own Application, where the pilot site uses an
already existing solution and integrates the Knowledge
Management Tool.
The NATHCARE Model allows three different
implementation scenarios while providing a common
overarching architecture.
The three different solutions are currently being
developed and will be implemented in the next phase,
which will be followed by the piloting phase. The piloting
phase will test the solutions as well as the robustness of
the NATHCARE Model.
14
Model_1.indd 14-15
15
07/03/14 11.29
www.nathcareproject.eu
16
Model_1.indd 16
07/03/14 11.29