nathcare model description - alpine space programme · 2016-03-29 · capitalization of alias in...

NATHCAREModel description

REPORT 1

The value of health and well-beingAn integrated approach to patient centred care

Model_1.indd 1 07/03/14 11.29

SUmmary

1INTRODUCTION NATHCARE pAg 3

2MODEL DESIgN METHODOLOgY pAg 4User RequirementsGroups of functionalities and Functional SubsetLocal Context of Functional Subset

3THE NATHCARE MODEL pAg 6Standalone SolutionIntegrated SolutionOwn application (Standalone Site)NathCaRe Model implementation at Pilot Sites

4CApITALIZATION OF ALIAS IN THE NATHCARE pROJECT pAg 10the aLIaS projectNathCaRe re-use of aLIaS components

5CONCLUSIONS pAg 14

NATHCAREMOdEl dEsCRiPTiON

Authors:Natalia allegretti**antoine Geissbuhler*Caroline Perrin*Nicolas Roduit*Stéphane Spahni*

* hôpitaux Universitaires de Genève

** Lombardia Informatica S.p.a.

INTrODUcTION NATHCARE

The project aims to

design, consolidate and

validate a “healthcare local

community” based model

embracing all the players of the

care system for securing a sustainable

and improved organizational adaptation

of healthcare services.

The project is capitalising on the AliAs project 1,

and targets the process for a hospital-territory

integration addressing mainly long term diseases

in the perspective of continuity of care

as dimension of the demographic change.

NATHCARE (Networking Alpine Health

for Continuity of Care Project) is a

project co-funded by the Alpine

space Programme 2007-2013,

that addresses the theme

of demographic change in

the framework

of public services

devoted

to healthcare

provision.

this document is

a publishable summary of

the Deliverable D5.1

Model Design of the

NathCaRe Project.

1

www.nathcareproject.eu

1) www.aliasproject.eu

MOdEl dEsCRiPTiON

3

Model_1.indd 2-3 07/03/14 11.29

4 5

MOdEl dEsCRiPTiON

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.

2.1 User Requirementsthe 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).

these functionalities were pooled into five Groups, which are described below.

2

mODEL DESIGN METHOdOlOGY

d4.1 User Requirements

Functional subset (Groups 1-5)

local context analysis

NATHCARE Model

Figure 1 overview Wp5 Methodology

2.2 Groups of functionalities and Functional Subset

GROUP 1

GROUP 5

GROUP 4

GROUP 3

GROUP 2

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

these five groups are:

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.

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 Subsetafter 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.

2

Model_1.indd 4-5 07/03/14 11.29

6 7

MOdEl dEsCRiPTiON

THE NaTHcarE MOdEl

Figure 2 Model: standalone with AliAs central server

Nathcare development

Alias existing component

Alias extended component

2

1

3

7

CiRClE OF TRUsT

LOC

AL

SIT

EC

EN

TR

AL

SE

Rv

ICE

S

User Authentication

Alias Library

User Authorization

Execution Tool

Document Registry

New ApI

patient Registry

Alias ApI

4

6

5

Alias Central Server

Knowledge Management

Tool

8

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.

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 demo-

graphic data. the Patient Registry is accessed

through the application Programming Interface

(aPI) defined in aLIaS.

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.

If documents are uploaded by the user, these

documents are stored locally. the Document

Registry is accessed through the same aPI as ( ).

Services from the knowledge manager are

being used. the aPI has to be clarified.

the knowledge manager may retrieve user’s

information from the aLIaS Server.

1

2

3

4

5

6

7

8

standalone Care Plan Application

User’s data

Anonymous data

Patient’s data

3.2 Integrated Solution

3 3



Tool

Figure 3 Model: local integration with AliAs central server

2

CiRClE OF TRUsT

LOC

AL

SIT

EC

EN

TR

AL

SE

Rv

ICE

S

User Authentication

Alias Library

Care plan Application

User Authorization

Execution Tool

3

7



Alias extended component

site’s own component

Document Registry

New ApI

patient Registry

Alias ApI

4 6

5

User’s data

Anonymous data

Patient’s data

1

8

the user is authenticated, a SaML token is generated.

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

a security token is created on the alias Central

Server and a handle on it is returned.

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 demo-

graphic data. the Patient Registry is accessed

through the aPI defined in aLIaS.

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.

If documents are uploaded by the user, these

documents are stored locally. the document

registry is accessed through the same aPI as ( ).

Services from the knowledge manager are being

used.



1

2

3

4

5

6

7

8

Model_1.indd 6-7 07/03/14 11.29

8 9

MOdEl dEsCRiPTiON



Tool

3.3 Own Application (Standalone Site) Own application specifications.

Optional: a security token is created on the aLIaS

Central Server and a handle on it is returned.

Own application specifications.




Services from the knowledge manager are being

used.



Figure 4Model: own Application with AliAs central server

3

7

LOC

AL

SIT

EC

EN

TR

AL

SE

Rv

ICE

S

User Authentication

Alias Library

User Authorization patient Registry

Execution Tool

4

6

5

8

Document Registry

3.4 NATHCARE Model implementation at Pilot Sites 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.

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.

1

2

3

4

5

6

7

8

CiR

ClE

OF

TR

UsT

standalone Care Plan Application


site’s own component

User’s data

Anonymous data

Patient’s data

2

1


local / Regional system

local/ Regional system

UserAuthentication

Patient /document Registry

Patient Mobile App

Patient Web App

Execution Tool

NathcareConnector



Patient Mobile App

Patient Web App

Execution Tool

Hôpital Privé drôme Ardèche, Valence

Clinique Mutualiste de saint Etienne, Saint Etienne

Centre léon Bérard, Lyon

CHU Grenoble, Grenoble



Patient Mobile App

Patient Web App

local / Regional systemPatient

Mobile AppPatient

Web App

local/ Regional systemlocal / Regional system

Patient Mobile App

Patient Web App

local/ Regional system

UNiVERsiTY HOsPiTAls OF GENEVA

TRENTO HOsPiTAl

REGiONAl ONCOlOGY NETWORK

BERGAMOlOCAl HEAlTHCARECOMMUNiTY

VAREsElOCAl HEAlTHCARECOMMUNiTY

GARMisCH PARTENKiRCHEN HOsPiTAl

GOlNiK HOsPiTAl

AlTO FRiUli lOCAl HEAlTHCARE COMMUNiTY

VillACH HOsPiTAl

local / Regional systemPatient

Mobile AppPatient

Web App

Execution Tool



Execution Tool


Execution Tool

local solution

Execution Tool

UserAuthentication

UserAuthentication

UserAuthentication

UserAuthentication

UserAuthentication

UserAuthentication

UserAuthentication

UserAuthentication

Figure 5nAtHcAre system network overview

local solution

local solution

UserAuthentication


Alias Central Services

3 3

Model_1.indd 8-9 07/03/14 11.29

caPITaLIZaTION OF aLIaS IN THE NATHCARE PROJECT

4.1 The ALIAS Projectthe 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.

4.2 NATHCARE re-use of ALIAS componentsthe 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.

Figure 6system architecture of the Geneva pilot site

loGin, pAssWord, MoBile nr. orGAnizAtion, role

locAl connector

2User

Authorization

ALIASCentral Server

ALIASportal

Execution Tool

ALIAS Connector

e-toilegateway

MDM(e-toile)

ALIASSAML

connector

BrowserHUg

Browser user

non-HUg

3

Get toKen

1 loGin + sMs

6

7

iHe

5

24 5

6

5

7

7

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.

A priority of AliAs was to ensure fair access to HC public services

and related communication infrastructures within the area

covered by the programme.

AliAs established a Virtual Hospital through

a network of hospitals.

41

redirectloGin

2

AliAs coMponents

1110

MOdEl dEsCRiPTiON4 4

Model_1.indd 10-11 07/03/14 11.29

12 13

MOdEl dEsCRiPTiON4

• 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 identifies himself with his HUG

credentials (initials and password), while the smartcard is in the reader.

• the aLIaS SaML connector validates the credentials with the HUG identification system (active directory + users

profiles).

• 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.

• 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 from the aLIaS

Central Services: then the user is allowed to access the functions of the application.

• 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.

• 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.

USER LOgIN IN FOR pATIENTS, NON-HUg pHYSICIANS, OR HUg pHYSICIANS OUTSIDE THE HUg INTRANET:

FiGURE 6 illUsTRATEs THE TWO POssiBiliTiEs

TO lOG-iN TO NATHCARE, EiTHER FROM THE

HUG iNTRANET, OR ExTERNAl.

USER LOgIN IN FROM INSIDE HUg vIA THE HUg BROwSER:

4

Model_1.indd 12-13 07/03/14 11.29

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.

CONClUsiONs

5

1514

MOdEl dEsCRiPTiON

Model_1.indd 14-15 07/03/14 11.29

16

www.nathcareproject.eu

Model_1.indd 16 07/03/14 11.29

nathcare model description - alpine space programme · 2016-03-29 · capitalization of alias in...

Documents