salus - i~hd d8_2_1_lispa_final.pdf · fp7-287800 salus salus-fp7-287800•d8.2.1-lispa pilot -...

FP7-287800 SALUS

SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 of 83

SALUS “Scalable, Standard based Interoperability Framework for

Sustainable Proactive Post Market Safety Studies”

SPECIFIC TARGETED RESEARCH PROJECT

PRIORITY Objective ICT-2011.5.3b Tools and environments enabling the re-use of

electronic health records

SALUS D.8.2.1 - Design of the Implementation of the Pilot

Application Scenario (LISPA)

Due Date: May 31, 2013

Actual Submission Date: May 28, 2013

Project Dates: Project Start Date : February 01, 2012

Project End Date : January 31, 2015

Project Duration : 36 months

Deliverable Leader: LISPA Lombardia Informatica SPA Italy

Project co-funded by the European Commission within the Seventh Framework Programme (2007-2013)

Dissemination Level

PU Public X

PP Restricted to other programme participants (including the Commission Services)

RE Restricted to a group specified by the consortium (including the Commission Services)

CO Confidential, only for members of the consortium (including the Commission Services)

FP7-287800 SALUS

SALUS –FP7-287800 • May 08, 2013 of 83

Document History:

Version Date Changes From Review

V0.1 October 24,

2012

Creation of the first version LISPA LISPA

V0.2 October 29,

2012

Add contents from the persons responsible for each topic LISPA LISPA

V0.3 November

26, 2012

The column Field was erased in the list of the SALUS DWH

attributes.

4.3 Constraints are added

LISPA LISPA

V0.4 December 4,

2012

Pharmacovigiliance process is added

Use cases description (presentation from Milano meeting)

LISPA Pilot limitations are added

LISPA GUI and Single Sign on are added

LISPA,

SRDC,

OFFIS

LISPA

V0.5 December

12, 2012

Andrea contributed ch.9

5.2 changed

LISPA LISPA

V0.6 December 14 Codes tables, Paolo remark

Version distributed to all partners for comments

Received comments from JDV

LISPA Consortium

V0.7 March 03,

2013

Restructured the Deliverable, Physical deployment figure

updated, realization of use cases have been rewritten based on

the physical deployment architecture

SRDC LISPA

V 1.1 March 06,

2013

JDV comments have been included

Use case ADE notification tool and ICSR reporting tool

merged (as from presentation in Paris meeting)

LISPA Consortium

V.1.2 March 08,

2013

Improved description of Italian process in pharmacovigilance

Conceptual design updated

Physical architecture updated

Section 5 (scenarios description) revised

9.1 Development matrix completed

INSERM comments have been included

Section 6 and section 7 general revision

Section 7 DB schema

Section 9 Pilot settings: applications, technologies. Pilot

running

LISPA LISPA

V1.3 March 26,

2013

First complete version distributed to all partners for

comments and feedbacks

LISPA Consortium

V1.4 April 10,

2013

Comments from UMC included

Comments from SRDC included

Comments from INSERM included

Changes for de-identification service

9.3 Pilot running added information

Appendix 1 and 2 added

LISPA SRDC

V1.5 April 30,

2013


Added info for ICSR de-identification

LISPA LISPA

V2.0 May 08,

2013

Second complete version distributed to all partners for

comments and feedbacks

LISPA Consortium

FP7-287800 SALUS


V2.1 May 14,

2013


LISPA LISPA

V2.2 May 21,

2013

ROCHE scenario schema update LISPA LISPA

V2.3 May 22,

2013

Comments from PI included LISPA LISPA

V3.0 May 28,

2013

Final version LISPA Consortium

Contributors (Benef.) LISPA, SRDC, OFFIS, INSERM, ROCHE

Responsible Author Alberto Daprà Email [email protected]

Beneficiary LISPA Phone +390239331605

FP7-287800 SALUS


SALUS Consortium Contacts:

Beneficiary Name Phone Fax E-Mail

SRDC Gokce Banu Laleci

Erturkmen

+90-312-2101763 +90(312)2101837 [email protected]

EUROREC Georges De Moor +32-9-2101161 +32-9-3313350 [email protected]

UMC NiklasNorén +4618656060 +46 18 65 60 80 [email protected]

OFFIS WilfriedThoben

+49-441-9722131

+49-441-9722111

[email protected]

AGFA Dirk Colaert +32-3-4448408 +32 3 444 8401 [email protected]

ERS Gerard Freriks +31 620347088 +31 847371789 [email protected]

LISPA Alberto Daprà +390239331605 +39 02 39331207 [email protected]

INSERM Marie-Christine Jaulent +33142346983 +33153109201 marie-

[email protected]

TUD Peter Schwarz +49 351 458 2715 +49 351 458 7319 Peter.Schwarz@uniklinikum-

dresden.de

ROCHE Jamie Robinson +41-61-687 9433 +41 61 68 88412 [email protected]

FP7-287800 SALUS


EXECUTIVE SUMMARY

The deliverable describes the design of the implementation for the pilot application in two different

locations, LISPA(Italy) and TUD (Germany). This document is to illustrate the design of the pilot in

LISPA settings. The TUD pilot implementation will be described in a similar document D8.2.1

Design of the Implementation of the Pilot Application Scenario - TUD.

This document aims to show how LISPA views the SALUS deployment in LISPA setting and how it

is planned to be structured to satisfy the internal requirements.

During the scenario analysis some specific deployment constraints in LISPA pilot have been

identified and different solutions have been studied.

In line with the conceptual design phase and the analysis of the pilot application scenarios in D8.1.1

and the technical requirements of the high level components presented in D3.3.1,LISPA identified all

SALUS components and interfaces which will be deployed in the final architecture.Logical and

physical architectures are described in detail and each component is clearly identified in terms of

functionalities, technologies and responsibilities. The physical deployment in LISPA is explained and

summarized in tables where roles and responsibilities are clearly identified for all components. Each

scenario is analyzed and specific needs for LISPA deployment are presented. A detailed realization of

each single use case is provided.

Moreover LISPA will set up a specific service for the use cases ADE tool and ICSR tool. This

internal service is supposed to re-identify (de-anonymise) the patient by the GP single sign on within

the LISPA Care Zone (SISS perimeter) in order to look for patient clinical information which are

needed for ADE validation and for information retrieval (ICSR reporting).

The SALUS-LISPA DWH created for SALUS purposes will contain the data extracted from DWH of

Lombardy Region. The necessary data is extracted from the Lombardy DWH flow sources table

presented in Appendix 3 of the deliverable SALUS D8.1.1 Pilot Application Scenario and

Requirement Specifications of the Pilot Application. The entity relationship model with data

attributes for SALUS-LISPA DWH is presented. Data mapping and international codifications to be

used for LISPA pilot are described.

Involvement of partners in Tasks 8.2 is presented in the following table together with the established

deliverable action plan:

DELIVERABLE D 8.2.1 ACTION PLAN

DATE ACTION

14/12/2012 LISPA provided a template and responsibilities distribution

15/01/2013 LISPA and TUD consolidated the TOC

FP7-287800 SALUS


01/03/2013 Each partner send software specification components

30/03/2013 LISPA and TUD send first complete version

12/04/2013 All partners send comments and feedbacks

03/05/2013 LISPA and TUD send second complete version

10/05/2013 All partners send comments and feedbacks

24/05/2013 Final version is released

FP7-287800 SALUS


TABLE OF CONTENTS

Executive Summary ................................................................................................................................ 5 1 PURPOSE ...................................................................................................................................... 9 2 REFERENCE DOCUMENTS ....................................................................................................... 9

2.1 Definitions and Acronyms ...................................................................................................... 9 3 LISPA deployments setting and constraints ................................................................................. 11

3.1 Introduction to SALUS pilot scenarios ................................................................................. 11 3.2 Data source to be used in SALUS Pilot applications ............................................................ 11 3.3 Creation of a specific database for SALUS project, namely SALUS-LISPA DWH ............ 12 3.4 DWH update constraints ....................................................................................................... 12 3.5 Limitations about involving GPs in pilot phase .................................................................... 13 3.6 The ICSR Reporting: workflow in the Italian process and constraints analysis ................... 13 3.7 Anonymity of the data........................................................................................................... 16 3.8 Separation of Extranet from Internet .................................................................................... 18

4 SALUS-LISPA architecture ......................................................................................................... 19 4.1 Logical architecture............................................................................................................... 19

4.1.1 Logical Components ..................................................................................................... 20 4.1.2 DWH and SISS perimeter ............................................................................................. 20

4.2 Physical architecture ............................................................................................................. 26 5 Design of the Realization of the Selected SALUS SCENARIOS in Lombardy Region ............. 28

5.1 SALUS Scenario #1 (a and b): Detailed realization of ADE Notification and ICSR

Reporting case in LISPA .................................................................................................................. 29 5.2 SALUS scenario #2_a:Detailed realization of CSC case in LISPA ...................................... 33 5.3 SALUS scenario # 2_b and #3_a: Detailed realization of Temporal Pattern Characterization

(TPC) and Temporal Pattern Association Screening (TAS) Screening Scenarios in LISPA ........... 35 5.4 SALUS scenario #3_b: Detailed realization of Manual Clinical Review of Patient History

scenario in LISPA ............................................................................................................................. 37 5.5 SALUS scenario #4_a: Detailed realization of Using EHRs as secondary use data sources

for Post Marketing safety studies (Estimate incidence rates of chronic heart failure (CHF) in

diabetic patients with a recent acute coronary syndrome (ACS) event on different diabetic

medications) scenario in LISPA ....................................................................................................... 38 6 Specific services for salus ............................................................................................................ 41

6.1 LISPA GUI for De-Anonymization service .......................................................................... 41 6.2 GP Single Sign On ................................................................................................................ 42

6.2.1 Access to Web Application ........................................................................................... 42 6.2.2 Interfaces design requirements ...................................................................................... 42

7 SALUS-LISPA DWH .................................................................................................................. 47 7.1 Data requirements ................................................................................................................. 47 7.2 Entity Relationship Model .................................................................................................... 51 7.3 Mapping of the required data to be provided by LISPA ....................................................... 71

7.3.1 Condition table .............................................................................................................. 71 7.3.2 Vaccination table........................................................................................................... 71 7.3.3 Ambulatory table........................................................................................................... 71 7.3.4 Pregnancy table ............................................................................................................. 71

7.4 DB update ............................................................................................................................. 71 7.5 Metadata ................................................................................................................................ 71 7.6 Physical data base ................................................................................................................. 72

8 Standard Codification used for data source in SALUS-LISPA DWH ......................................... 73 9 System actors ............................................................................................................................... 74

9.1 Pilot settings: applications .................................................................................................... 74 9.2 Pilot settings: technologies.................................................................................................... 77 9.3 Pilot running .......................................................................................................................... 79

FP7-287800 SALUS


FIGURES LIST

Figure 1- Italian Pharmacovigilance Process ........................................................................................ 15 Figure 2 – ADRs under-reporting situation .......................................................................................... 15 Figure 3 - SALUS Logical architecture for LISPA .............................................................................. 19 Figure 4- Physical architecture ............................................................................................................. 26 Figure 5- Logicalrealization of ADE Notification and ICSR reporting case in LISPA. ....................... 29 Figure 6 - Detailed realization of scenario #1_a in LISPA: ADE Notification. ................................... 31 Figure 7 - Detailed realization of scenario #1_b in LISPA: ICSR Reporting. ...................................... 32 Figure 8–Logicalrealization of CSC case in LISPA. ............................................................................ 33 Figure 9- Detailed realization of scenario #2_a in LISPA: CSC. ......................................................... 34 Figure 10–Logical realization of Temporal Pattern Characterisation (TPC) and Temporal pattern

association screening(TAS) screening scenario in LISPA .................................................................... 35 Figure 11- Detailed realization of scenario #2_b and #3_a in LISPA: TPC and TAS cases ................ 36 Figure 12- Logical realization of Manual clinical review of patient history scenario in LISPA .......... 37 Figure 13–Detailed realization of scenario #3b in LISPA: Manual clinical reviewof relevant medical

history ................................................................................................................................................... 38 Figure 14-Logical realization of Roche case in LISPA ........................................................................ 39 Figure 15- Detailed realization of scenario #4_a in LISPA: Roche case .............................................. 39 Figure 16 - LISPA GUI de-anonymization service............................................................................... 41 Figure 17 – Mapping between RL-DWH pseudo-code and SALUS-LISPA DWH pseudo-code ........ 42 Figure 18 – SALUS-LISPA DWH: Entity Relationship Diagram ........................................................ 52 Figure 19– Conditions codification example ........................................................................................ 71

TABLES LIST

Table 1 - List of Abbreviations and Acronyms ..................................................................................... 10 Table 2 – Pilot scenarios ....................................................................................................................... 11 Table 3 – Scenarios list in LISPA pilot................................................................................................. 28 Table 4 – Scenario #1_a and 1_b in LISPA pilot: steps description ..................................................... 31 Table 5 - Scenario #2_a in LISPA pilot: steps description ................................................................... 35 Table 6 - Scenario #2_b and 3_a in LISPA pilot: steps description ..................................................... 36 Table 7 - Scenario #4_a in LISPA pilot: steps description ................................................................... 40 Table 8 – Parameters example .............................................................................................................. 43 Table 9 – Data requirements ................................................................................................................. 51 Table 10 - SALUS–LISPA DWH data description............................................................................... 70 Table 11 – Standard codification system used in SALUS-LISPA DWH ............................................. 73 Table 12 – Pilot settings: applications .................................................................................................. 76 Table 13 – Pilot settings: Technologies ................................................................................................ 78 Table 14 – Pilot running ....................................................................................................................... 79

FP7-287800 SALUS


1 PURPOSE

The purpose of this document is to describe the design for the implementation of pilot scenarios in

LISPA premises. In particular the document contains information about

1. LISPA deployment settings and existing constraints;

2. The physical and logical architecture for SALUS deployment at LISPA;

3. The characterization and the realization design for each single scenarios in LISPA pilot;

4. The SALUS-LISPADWH available for SALUS project, which will be used for use case

scenarios in the pilot application deployment; the specific services needed for SALUS

project;

5. The standard codification used for data interoperability

2 REFERENCE DOCUMENTS

The following documents were used or referenced in the development of this document:

SALUS D8.1.1: Pilot Application Scenario and Requirement Specifications of the Pilot

Application.

SALUS D8.4.1Data Protection Plan v.03

SALUS D3.3.1 Requirement Specification of the SALUS Architecture

SALUS D5.4.1 Interoperability Profiles and OpenSource Toolsets for Security and Privacy

ISO/TS 25237:2008 Health informatics – Pseudonymization,

http://www.iso.org/iso/catalogue_detail?csnumber=42807

SIAU n.25 Exposing Web applications to the LISPA Extranet

2.1 Definitions and Acronyms

Abbreviation/

Acronym DEFINITION

ADE Adverse Drug Event

ADR Adverse Drug Reaction

AIFA Italian Medicines Agency

ASL Azienda Sanitaria Locale (LHU)

ATC Anatomical Therapeutic Chemical

CGI Centro di Gestione Integrato Extranet Center for integrated management

CDE Common Data Element

CF Codice Fiscale – Social security number1

CRR Centro regionale di riferimento – Pharmacovigilance regional centre

CSC Tool Case Series Characterization Tool

DDD Defined Daily Dose

DWH Data warehouse

E2B(R2) Electronic Transmission of Individual Case Safety Reports Message Specification

EHR Electronic Health Record

FE Front End

FSE Fascicolo Sanitario Elettronico (EHR)

GP General Practitioner

HL7 Health Level Seven

HP Health Professional

ICD9CM The International Classification of Diseases, Ninth Revision, Clinical Modification

1 The Italian “fiscal code”, officially known as Italy's Codice Fiscale, is the tax code in Italy, similar to a Social

Security Number (SSN) in the United States. The tax code in Italy is an alphanumeric code of 16 characters.

Designed by and for the Italian tax office, it is now used for several other purposes, e.g. uniquely identifying

individuals in the health system, or natural persons who act as parties in private contracts

http://www.iso.org/iso/catalogue_detail?csnumber=42807

FP7-287800 SALUS


ICSR Individual Case Safety Report

IHE Integrating the Healthcare Enterprise

LHU Local Healthcare Unit

OMOP Observational Medical Outcomes Partnership

PH Tool Patient History Tool

PMSS Tool Post Marketing Safety Study Tool

PSN Pseudonym

RPV Responsible of Pharmacovigiliance

RNF Rete Nazionale di Farmacovigilianza-Pharmacovigilance National Network

QED Query for Existing Data

SISS Sistema Informativo Socio Sanitario - Social Healthcare Information System

SOAP Simple Object Access Protocol

SSO Single Sign On

SIDS Semantic Interoperability Data Service

SIL Semantic Interoperability Layer

TAS Tool Temporal Association Screening Tool

TIL Technical Interoperability Layer

TLS Transport Layer Security

TPD Tool Temporal Pattern Discovery Tool

XML eXtensible Markup Language

Table 1 - List of Abbreviations and Acronyms

FP7-287800 SALUS


3 LISPA DEPLOYMENTS SETTING AND CONSTRAINTS

3.1 Introduction to SALUS pilot scenarios

SALUS project envisioned different pilot scenarios to strengthen the already existing signal detection

methods based on spontaneous reporting and to support complementary approaches to spontaneous

reporting through continuous screening of EHRs for safety monitoring.

The identified scenarios are represented in the following table.

SCENARIOS

Strengthening the already existing signal detection methods based on Spontaneous Reporting

1 Enabling Semi-automatic Notification of Suspected ADEs and Reporting ADEs within a

Hospital

a. Enabling Notification of Suspected ADEs (ADE notification)

b. Enabling Semi-automatic ADE Reporting (ICSR)

2 Supporting Clinical Evaluation of a Potential Signal through Accessing the EHRs

a. Characterizing the cases and contrasting them to a background population (CSC)

b. Temporal pattern characterization (TPC)

Supporting complementary approaches to spontaneous reporting through continuous screening of

EHRs for safety monitoring

3 Running Exploratory Analysis Studies over EHRs for Signal Detection

a. Temporal association screening on EHRs(TAS)

b. Manual clinical review of relevant medical history

4 Using EHRs as secondary use data sources for Post Marketing safety studies

a. Estimate incidence rates of chronic heart failure (CHF) in diabetic patients with

a recent acute coronary syndrome (ACS) event on different diabetic medications

Table 2 – Pilot scenarios

These scenarios will be implemented in two pilot sites, namely TUD and LISPA. TUD pilot is based

on a hospital information system, LISPA pilot is based on a regional healthcare information system.

The different settings of SALUS pilots require a customization of the listed scenarios and different

workflows have been identified for each use case.

LISPA pilot implements the envisaged scenarios within the regional context which has very different

characteristics from the hospital context. Furthermore the Italian pharmacovigilance process is not

completely comparable to the German pharmacovigilance process. On the basis of these differences,

both at site context level and at national process level, each scenario will be analysed in detail and

presented in the following paragraphs.

3.2 Data source to be used in SALUS Pilot applications

The Lombardy Region runs the Regional Health Data Ware House (DWH), which extracts all data

necessary for administrative and statistical purposes from the Lombardy EHR systems. The DWH has

different privacy implications and hence can be used for research related analysis. The data

maintained in the DWH has already been pseudonymized, i.e. directly identifying patient data such as

name, id is not being maintained in DWH. According to the Lombardy Region rules in force the only

data source available for pharmacovigilance activities is the DWH.

FP7-287800 SALUS


The DWH is an important data collection for the regional pharmacovigilance activities, because all

the interactions between the citizen and the public health care system are captured in this DWH.DWH

contains thematic data marts and is populated by different information flows.

Data which will be used within the scope of SALUS project are:

- Pharmaceutical (drugs prescriptions in primary care)

- Pharmaceutical in hospital setting (drugs provision in hospital care at patient

discharge or day hospital)

- Hospitalization (hospital discharge form)

- Ambulatory (laboratory analysis, diagnostic examination, …)

- Vaccinations (vaccines information)

- Allergies

- Patient clinical status (clinical condition calculated by an elaboration process of

clinical history)

- Patient pregnancy status (elaborated data)

SALUS project will take advantage in analysing each single data flow but also in analysing linkage

between different data sources (e.g. patient with a drug prescription in primary care (pharmaceutical

data source) -> adverse drug event which requires hospitalization -> information about hospital stay

(hospitalization and pharmaceutical in hospital data sources)).

3.3 Creation of a specific database for SALUS project, namely SALUS-

LISPA DWH

In D8.1.1, the data requirements of all SALUS Pilot applications have been identified. Apart from

SALUS data requirements, LISPA DWH includes different type of data which are useless for SALUS

purposes and it is of utmost importance to protect this kind of information which are very sensible

data (e.g. health expenses management data, budgeting information).

For this reason LISPA will create a new specific database for SALUS project which will include all

necessary data to be transferred into SALUS overall system and have to guarantee a separation

between the DWH and SALUS to reduce the risk of unauthorized access to the data stored in the

DWH.

3.4 DWH update constraints

The DWH is updated by specific data flows generated by the health care providers in Lombardy

region. Most of the data are sent by the health care providers on a monthly basis. Consequently

SALUS-LISPA DWH will be updated once a month and ADEs can only be identified with a

postponed approach. This constraint implies that the GPs will receive notifications of possible adverse

events with a delay of about 1day to 45days from the date in which the event occurred. The GPs will

be requested to re-analyse a patient situation on the basis of received reports and to check if the

notification really represents an adverse drug event. A further analysis of this use case is presented in

Section5.

FP7-287800 SALUS


3.5 Limitations about involving GPs in pilot phase

For two of the selected pilot applications, namely notification of ADEs, and reporting of ICSRs, there

is a need for interaction with physicians. LISPA decided to involve the professional figure of GP in

Lombardy Region for these pilot cases. However, due to the nature of the pilot, it is not possible to

predict which patients will be affected by a potential adverse drug event and it is out of the scope of

the project to involve all the GPs working in Lombardy Region in the pilot application. The pilot

involved GP doesn’t operate in the official role for his/her patient care. The GP operates in LISPA

pilot in order to evaluate the interoperability framework focusing on his/her functions (eg. correctness

of the ICSR produced by the ADR tool and effectiveness of ADE Notification tool).

Moreover LISPA will involve Lombardy Region Pharmacovigilance Centre experts for usability tests

and for scientific process validation. However due to the limitations explained above the involved GP

will not be the assigned GP of the patients for whom ADEs has been detected and to be reported.

In accordance with the SALUS requirements and LISPA processes on the Scenario 1_a (ADE

Notification), the evaluation will be performed in two steps (detailed information about the process is

available in Section 5):

ADE notification delivery validation: As explained, the data in DWH and hence in SALUS-

LISPA DWH is already pseudonymized. When ADE Notification Tool detects a possible

ADE and notifies it to the GP, GP needs to re-identify the patient to assess the detected ADE

when necessary by checking further details in the EHRs of the patient. This re-identification

will be handled by a de-anonymisation mechanism to be supported by LISPA. De-

anonymisation mechanism will be evaluated by the GPs involved in evaluation study (who

will not be the actual GPs of the patients for whom ADE is detected).

ADE Notification performance validation: The consistency of the “ADE extraction”

generated by ADE Detection and Notification Tool. LISPA can involve Lombardy Region

Pharmacovigilance Centre experts and some GPs for usability tests and scientific process

validation.

This activity will be planned in the: D8.3.1 Deployment of SALUS Pilot Application –R1 .

3.6 The ICSR Reporting: workflow in the Italian process and constraints

analysis

The Italian Pharmacovigilance System (for ADR) is based on the spontaneous reports sent by Health

Professionals (HP) and Citizens. The spontaneous reporting is regulated by a national law “D.Lgs

95/2003”.

The Hospital and Health Care Organization (Research and Care Institute) as well as the Local

HealthcareUnit (LHU, in Italian ASL: “Azienda Sanitaria Locale”) must have its Responsible of

Pharmacovigilance (RPV). The private health care organizations have to collaborate with the RPV of

LHU (ASL).

As presented in Figure 1- Italian Pharmacovigilance Process, the reporting workflow is as follows2:

NATIONAL LEVEL

The HP transmits the report to the local Responsible of Pharmacovigilance of his organization

(eg. RPV of the Hospital or of the Local Healthcare Unit in case of GP).

The consumer and HP can also upload ADR directly to the Pharmacovigilance national

network portal

2 In accordance with the ICH-E2D guideline,

• a healthcare professional is defined as a medically-qualified person such as a physician, dentist, pharmacist,

nurse, coroner or as otherwise specified by local regulations;

• a consumer is defined as a person who is not a healthcare professional such as a patient, lawyer, friend,

relative of a patient or carer.

FP7-287800 SALUS


The RPV reviews and completes the ADR report and sends the documentation to national

responsible of pharmacovigilance(AIFA- Agenzia Italiana del Farmaco) in 7 days using the

Pharmacovigilance National Network (in Italian RNF - Rete Nazionale di Farmacovigilanza).

If necessary the RPV contacts the HP and asks for further information (for example in case of

incomplete forms or data incongruence)

Based on the literatures cases, AIFA (Agenzia Italiana del Farmaco) distinguishes the ADR

registered in the RNF network in serious and not serious cases. A serious adverse reaction

corresponds to any untoward medical occurrence that at any dose results in death, is life-

threatening, requires inpatient hospitalisation or prolongation of existing hospitalisation,

results in persistent or significant disability or incapacity, is a congenital anomaly/birth

defect.3

EU LEVEL

AIFA sends the Serious ADR to EudraVigilance in 15 days, the Not Serious in 90 days.

WORLD-WIDE LEVEL

All ADRs are sent every month by AIFA to WHO-UMC (the UPPSALA MONITORING

CENTRE).

Once ICSRs are received (at national or international level) data are analysed and causalities are

studied. In case of several similar reports on the same drug describing comparable adverse events an

alarm can be instantiated for deeper investigations on that specific drug. Reports are not considered

closed as they are received from the responsible subjects, but can be further modified and updated

with follow up information.

The national law “D. Lgs 95/2003” has also introduced the pharmacovigilance centres at regional

level (CRR Centro regionale di riferimento) which are entitled to the following roles:

- Data codification control and data quality control

- Provide assistance to health care structures for data codification

- Data input in case of problem in health care structures

- Collaboration in data analysis and alarm processing

- Joined action with other region

3The characteristics/consequences should be considered at the time of the reaction to determine the seriousness

of a case. For example, life-threatening refers to a reaction in which the patient was at risk of death at the time

of the reaction; it does not refer to a reaction that hypothetically might have caused death if more severe.

FP7-287800 SALUS


Figure 1- Italian Pharmacovigilance Process

As in many other countries the Italian ADE spontaneous reporting presents some disadvantage such

as underreporting problem, low data quality, few information about drug treatment. Concerning the

underreporting problem in Italy, it is envisaged that only about 15% of ADE are reported to the

national responsible of Pharmacovigilance (see Figure 2 – ADRs under-reporting situation).

Figure 2 – ADRs under-reporting situation

In the light of the National Process, the LISPAICSR reporting pilot will be focused in the process

where the GP (HP) prepares and transmits the ICSR document to the Responsible of

Pharmacovigilance. In addition to that, as AIFA is not a direct partner in the project, and it is not

possible to test the process between AIFA and UMC for sending ICSR reports to UMC, for validation

FP7-287800 SALUS


studies, LISPA pilot will send the ICSR report directly to UMC. The main scope is to validate the

interoperability communication framework and to check if the system really helps to obtain reports

which are more complete, better structured and with a high level of correctness. The ICSR report sent

during the pilot phase to UMC by LISPA will be in E2B Format. However the ICSR Reporting Tool

will also be able to produce ICSR reports in AIFA format (see Appendix 2).

Nevertheless this approach presents some constraint: as this direct notification process to UMC is

different from the process defined by the Italian Law (the real process requires that the ICSR will be

sent to UMC by AIFA and not directly by the Local Entity (Lombardy Region and Hospital or Local

Agency)), the ICSR that is being sent to UMC needs to be de-identified at pilot phase according to

privacy and data protection plan.

Experts from the pharmacovigilance regional centre will be involved in order to validate the reporting

process and the quality of provided data.

3.7 Anonymity of the data

As already mentioned, the patient data collected in DWH is already pseudonymized. The ADE

detection and ICSR reporting tools will work on this pseudonymized data. After the ADE is notified

to the GP, only this person will be entitled to request de-anonymisation (this procedure will require

authentication and every operation is registered). The de-anonymisation process will be functionally

separated by the other tools, and none of the SALUS tools will themselves be able to de-anonymise

the patient since this is one functionality that only the GP in charge of patient care can perform after

authentication phase. The ICSR report, before being sent to UMC, will be further de-identified

according to LISPA needs. Specific requirements will be established by LISPA on the basis of the

respect of privacy rules (eg. Date of birth needs to be generalized).

In addition to this, the statistical results of the safety analysis scenarios (case series characterization,

temporal pattern discovery, temporal association screening, observational safety studies by ROCHE)

will be sent to external tools outside LISPA perimeter as anonymous data, when needed further de-

identification methods will be applied to eliminate indirectly identifiable data as well.

Only data which are sent to the Non Care/Research zone need to be de-identified, the data which are

stored in LISPA premises don’t need to be anonymous.

It is considered of utmost importance that data are correctly handled and anonimysed when needed.

De-identification, anonymization, and pseudonymization are approaches to remove information from

data that are not strictly required for the intended purpose of those data. Anonymization is a method to

disassociate all identifiers from the data, where pseudonymization supports longitudinal linking and

authorized re-identification.

This topic is carefully taken into account by project consortium and specific decisions and rules are

detailed in D8.4.1 Data Protection Plan and in D5.4.1 Interoperability Profiles and OpenSource

Toolsets for Security and Privacy.

For completeness the main definitions of data anonymity are herewith reported:

Anonymization: (Definition of ISO/TS 25237:2008) Anonymization is the process that

removes the association between a data set and the data subject. It can be done in the

following ways:

(1) Removing or transforming identifying characteristics in the data set so that the

association is not unique and relates to more than one data subject.

(2) Increasing the population in the data subjects set so that the association between the

data set and the data subject is not unique.

FP7-287800 SALUS


De-identification: De-identification is the process of removing personal identity revealing

attributes and replacing the required identifiers and attributes required for research purposes

either with pseudonyms or when possible with more generalized categories (like year of birth

instead of exact birth date). It should be noted that in some cases, such de-identification may

not serve to the needs of a specific clinical research study, when such generalization makes

the data unusable. In such cases, where indirectly identifiable data is needed, specific

agreements with data controllers may be needed which often requires patient consents.

Pseudonymization: (Definition of ISO/TS 25237:2008) Pseudonymization is a particular

type of anonymization that both removes the association with a data subject and adds an

association between a particular set of characteristics relating to the data subject and one or

more pseudonyms. It provides a means for information to be linked to the same person across

multiple data records without revealing the identity of the person as a data subject which is

often required for clinical research studies. Coded Data or Key Coded Data is also used as a

synonym to Pseudonymized Data.

FP7-287800 SALUS


3.8 Separation of Extranet from Internet

In Lombardy Region, the SISS is the perimeter where the Lombardy Health Care infrastructure

operates.

An Operator needs to be authenticated using the CRS-Operatore Smart Card from a dedicated

workstation (PDL-postazione di lavoro) which is integrated with the SSO SISS. The extranet SISS has

to be totally separated by internet for security reasons. All application related to the SISS world could

not be installed on a hardware which is directly connected to internet.

FP7-287800 SALUS


4 SALUS-LISPA ARCHITECTURE

4.1 Logical architecture

Taking into account the conceptual design and the analysis of the pilot application scenarios in

D8.1.1, the technical requirements of the high level components presented in D3.3.1 and the

limitations and constraints of the deployment in Lombardy Region (as presented in Section3),LISPA

identified SALUS components and interfaces for the deployment architecture.

As briefly discussed in D8.4.1- SALUS Data Protection Policy, the security and privacy of the patient

data will be ensured by logically designing separate zones, and having different privacy policies in

accessing patient related data in different zones.

These zones in Lombardy Region are depicted in Figure 3 and described below:

Figure 3 - SALUS Logical architecture for LISPA

DWH Zone is the zone, which is regulated by the Lombardy Regulation Scheda 12. The

DWH Zone contains the DWH and the SALUS perimeters. Lombardy Region is the Data

Controller, LISPA is the Data Processor. There are two perimeters in DWH zone:

DWH Perimeter is the operational environment where the Lombardy DWH is deployed;

SALUS Perimeter is the operational environment where the SALUS project components

will be deployed.

SISS Perimeter this is the perimeter where the Lombardy Health Care infrastructure

operates. An Operator needs to be authenticated using the CRS-Operatore Smart Card from a

Work Station (PDL), which is integrated with the SSO SISS. SISS Perimeter includes the

CARE Zone, which is the zone where the data and the documents are accessible for the

patient care purposes. In this Care Zone strong authentication is required and data contains

identified medical data (i.e. not pseudonymised).The GP can access the patient clinical folder

and the EHR (FSE).

SALUS Non Care & Research Zone: includes the interfaces of the safety analysis tools to

be used by ROCHE and UMC. The data sent to this zone is de-identified.

FP7-287800 SALUS


In the following sections, a detailed analysis of the components to be deployed in these zones is

presented.

4.1.1 Logical Components

[D-1] RL-DWH: Datawarehouse of Lombardy region which will be used to feed the SALUS-LISPA

datawarehouse for SALUS project purposes. Lombardy Region is the Data Controller, LISPA is the

Data Processor. SALUS functionalities don’t update RL-DWH. LISPA is responsible for the RL-

DWH.

[D-2] SALUS-LISPADWH: this data warehouse contains a subset of the data available in RL-DWH

which are necessary for SALUS Project

o OFFIS is responsible for the Schema Specification and installation package;

o Technology required: Oracle;

o LISPA is responsible for the deployment and data population.

[D-3] SALUS DB/Repository: this DB contains all data necessary for SALUS Components including

Safety analysis methods (Temporal Pattern Characterization and Temporal Association screening). It

will contain the signed /draft ICSR documents, saved by the Professional, also the patient data

collected as a result of the safety analysis queries on which the safety analysis methods will run. The

clinical data repository converted in OMOP format to be used in scenarios 2a, 2b and 3a by UMC will

be deployed in this local database within the SALUS perimeter.

o SALUS Project is responsible for the schema specification and installation package

(for de-identified patient data to be used in Case Series Characterization, Temporal

Pattern Characterization and Temporal Association Screening scenarios, the schema

will be the OMOP Common Data Model (CDM Schema));

o SALUS Project is responsible for the data population (in particular the [S-7] ICSR

Report Generator and [S-9] SIL subcomponents -II will populate the data after getting

the data from [S3] SIL subcomponents -I and [S4] De-identification Service);

o Technology required: Oracle;

o LISPA is responsible for deployment.

[D-4] SISS-DB: representation of the data available accessing the SISS (DC).

o Internal component: under the responsibility of LISPA.

4.1.2 DWH and SISS perimeter

DWH PERIMETER [W-1] DWH PUBLISHER COMPONENTS select and transform the data from the RL-DWH to

SALUS-LISPA-DWH. It is responsible to create the SALUS PSEUDO Code and maintain in the RL-

DWH the association with the RL PSEUDO Code respecting the LISPA-SALUS schema constraints.

This component is also responsible to maintain the SALUS-LISPA-DWH up to date.

o OFFIS is responsible for the OUTPUT Specifications, i.e. the schema of the [D-2]

SALUS LISPA-DWH;

o Technology required: Script SQL.

o LISPA is responsible for the INPUT specifications, technology, implementation,

packaging and deployment.

[W-2] SALUS-DWH COMPONENTS returns the DWH PSEUDO code starting from the SALUS

PSEUDO.

o Technology required: Java, Script SQL.

o LISPA is responsible for the specification, implementation of the interfaces and

deployment.

o Internal Component: under the responsibility of LISPA.

FP7-287800 SALUS


SISS PERIMETER [L-1] SALUS-SISS COMPONENTS is the interface of the SISS “world” for the LISPA

CONNECTOR (SALUS Perimeter). It receives the SALUS PATIENT PSEUDO Code from the GUI

(ADE and ICSR).

o Technology required: Java, Tomcat.

o LISPA will specify the pattern and the Interface that enable the GP to identify the

Patient.

o LISPA is responsible for the implementation of the component and deployment.

SALUS perimeter

[S-1] LISPA CONNECTOR is responsible to establish the communication between the [D-2]

SALUS-LISPA-DWH to the rest of the SALUS components. It implements the interoperability

profiles defined in WP5 to enable querying the [D-2] SALUS-LISPA-DWH, and subscribing the data

available in [D-2] SALUS-LISPA-DWH. In particular, it enables the communication between the [D-

2] SALUS-LISPA-DWH, and [S-2] TIDSQS (Technical Interoperability Data source Query Service),

which is the port of communication between the [D-2] SALUS-LISPA-DWH to other SALUS

components.

o OFFIS is responsible for the specification, implementation and installation package.

o Technology required: Java, Oracle DBMS, OS: Windows or Linux.

o LISPA is responsible for the deployment.

[S-2] Technical Interoperability Data Source Query Service (TIDSQS) is the port between [S-1]

LISPA Connector and other SALUS components. It provides the interfaces for the interoperability

profiles defined in WP5 to enable querying the [D-2] SALUS-LISPA-DWH, and subscribing the data

available in [D-2] SALUS-LISPA-DWH through [S-1] LISPA Connector. It will accept population

based queries in HL7 HQMF4, and will provide the result sets in conforming to HL7 CDA Entry level

templates defined in SALUS D4.1.1 in the payloads of the interoperability profiles defined in WP5.


o Technology required: Java, OS: Windows or Linux.


[S-3] Semantic Interoperability Layer (SIL) Subcomponents – I: this contains a number of

SALUS Semantic Interoperability Layer components:

[S-3.1] EHR RDF Service is responsible for semantic representation of the EHR data

retrieved from EHR sources, which are not semantically enabled. It communicates with [S-2]

TIDSQS in LISPA deployment

o SRDC is responsible for the specification, implementation and installation package.

o Technology required: Java, EYE Reasoning engine.


[S-3.2] Semantic Interoperability Layer Data Service(SIL-DS) is the interface of SALUS SIL

to EHR Sources, it is responsible for semantically mediating the data retrieved from [S-3.1]

EHR RDF Service (which are represented in local ontologies) to SALUS Common

Information Model (CIM)

o SRDC and AGFA is responsible for the specification, implementation and installation

package.



[S-3.3] ADE Notification Manager is the workflow manager within SALUS Semantic

Interoperability Layer that coordinates the communication with [S-5] ADE Notification Tool.

4 Representation of the Health Quality Measures Format (eMeasure),

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=97

FP7-287800 SALUS


It queries [S-3.2] SIL-DS and when necessary invokes different Converter services to

translate the data collected to a different format.

o SRDC and AGFA is responsible for the specification, implementation and installation

package.



[S-3.4] ICSR Reporting Manager is the workflow manager within SALUS Semantic

Interoperability Layer that coordinates the communication with [S-6] ICSR Reporting Tool. It

queries [S-3.2] SIL-DS and when necessary invokes different converters to translate the data

collected to a different format.

o INSERM, SRDC and AGFA is responsible for the specification, implementation and

installation package.



[S-4] De-Identification Service is used to de-identify all data which are sent to the Research and Non

care Zone. It implements a number of de-identification methods like generalization and redaction,

substitution based on the configuration to be provided by LISPA. The component is also responsible

with de-identification of the ICSR report before it is being sent to UMC.


o LISPA is responsible for defining the configuration of De-Identification service

(which data element will be de-identified with which method).

o Technology required: Java.


[S-5] ADE Notification Tool




This component contains a sub-component:

[S-5.1] ADE GUI is the GUI of ICSR tool

o OFFIS is responsible for the implementation and installation package.


o LISPA is responsible for the specification for the integration with the SSO-SISS,

Deployment.

[S-6] ICSR Reporting Tool

o INSERM is responsible for the specification, implementation and installation

package.

o Technology required: Java, specific Java libraries—such as Jena, Tomcat 7, and Jaxb


This component contains a sub-component:

[S-6.1] ICSR GUI is the GUI of ICSR tool

o INSERM is responsible for the implementation and installation package.

o Technology required: specific Java libraries—JavaServer Face, Jquery/Javascript,

JSP, HTML, Tomcat 7.

o LISPA is responsible for the ICSR Local Specification (AIFA format)and

specification for the integration with the SSO-SISS, Deployment.

[S-7] ICSR Report Generator is a part of [S-6] ICSR Reporting Tool, that creates the ICSR report

and also the report in AIFA format, and sends it to to UMC (in de-identified format).

o The ICSR report to be sent to UMC will be de-identified.

o INSERM is responsible for the specification, implementation and installation

package.

FP7-287800 SALUS


o Technology required: Java, specific Java libraries—such as Jena, Tomcat 7, and Jaxb.


[S-8] Technical Interoperability Layer Data Service (TILDS) is the interface to be used by

external safety analysis tools to communicate with SALUS Components to express the request for

anonymized patient data, and eligibility criteria for safety studies. It implements the interoperability

profiles defined in WP5.


o Technology required: Java, OS: Windows or Linux.


o All the results of the queries will be anonymized.

[S-9] Semantic Interoperability Layer (SIL) sub components - II: this contains a number of

SALUS Semantic Interoperability Layer components:

[S-9.1] Safety Analysis Query Manager is the workflow manager in SALUS Semantic

Interoperability Layer which coordinates the query based communication between external

safety analysis tools (sometimes through [S-8] TILDS) and the EHR Data Sources (through

[S-3.2] SIL-DS). It invokes the [S-9.3] Converter and Formatter services (like OMOP

converter, and OMOP formatter), stores the data in appropriate format to [D-3] SALUS

DB/Repository, calls the Safety analysis methods like [S-10] Temporal Pattern Association

Method or [S-11] Temporal Pattern Characterization Method, and calls the [S-9.4] Query

Result Calculator Service to run the statistical analysis queries on top of the collected

anonymized data.

o AGFA and SRDC are responsible for the specification, implementation and




o The clinical data that Safety Analysis Query Manager deals with is already de-

identified.

[S-9.2] Safety Analysis Subscription Manager is the workflow manager in SALUS Semantic

Interoperability Layer which coordinates the subscription based communication between

external safety analysis tools (sometimes through [S-8] TILDS) and the EHR Data Sources

(through [S-3.2] SIL-DS). It invokes the [S-9.3] Converter and Formatter services (like

OMOP converter, and OMOP formatter), stores the data in appropriate format to [D-3]

SALUS DB/Repository, calls the Safety analysis methods like [S-10] Temporal Pattern

Association Method or [S-11] Temporal Pattern Characterization Method.





o The clinical data that Safety Analysis Subscription Manager deals with is already de-

identified.

[S-9.3] Converter and Formatter Services: these services are a part of SALUS SIL, and will

be called to transform the collected de-identified clinical data to another format before storing

them to [D-3] SALUS DB/Repository. For example, based on the pilot application scenarios,

in Temporal Pattern Association and Temporal Pattern Characterization scenarios, the clinical

data should be in OMOP Common Data Model (CDM) format. Specific converter and

formatter services will be developed for this.

o SRDCis responsible for the specification, implementation and installation package.



o The clinical data that Converter and Formatter Services deal with is already de-

identified.

FP7-287800 SALUS


[S-9.4] Query Result Calculator Service: the statistical queries that external safety analysis

tools would like to run, like “give me the number of diabetes patients in the selected eligible

patients” will be run by this component on the de-identified clinical data collected by SALUS

SIL components.





o The clinical data that Query Result Calculator Service deals with is already de-

identified.

[S-10] Temporal Pattern Association Screening Method is a statistical analysis tool that will be run

on the de-identified clinical data collected in [D-3] SALUS DB/Repository for analyzing the probable

association between medications and adverse events.

o UMC is responsible for the specification, implementation and installation package

o Technology required: Oracle, R, Internet Information Services (IIS).


[S-11] Temporal Pattern Characterization Method is a statistical analysis tool that will be run on

the de-identified clinical data collected in [D-3] SALUS DB/Repository for analyzing the probable

temporal patterns between a medication of interest and a clinical event of interest.

o UMC is responsible for the specification, implementation and installation package.

o Technology required: Oracle, R, Internet Information Services (IIS).


[S-12] Audit Record Repository & GUI implements IHE ATNA “Audit Record Repository Role”,

and provides the interfaces to store “audit trails” of all requests to access clinical data through SALUS

platform and the respective responses. These audit trails will be viewed from the GUI of the

repository.



o LISPA is responsible for the Deployment.

[S-13] Case Series Characterization Tool is a tool that will be used by UMC to characterize a

selected patient group and compare it against a background population to assess the validity of a

reported adverse event. Through the Web based tool, the eligibility criteria of the background and

foreground populations will be specified, along with the statistical analysis queries that should run on

top of the de-identified medical summaries of the eligible patients. As a result, the analysis results will

be shown to the safety analyst in UMC through a Web based interface.

o UMC and SRDC are responsible for the specification, implementation and


o Technology required: Java, HTML 5.

o UMC is responsible for the Deployment.

o The result sets presented will be de-identified.

[S-14] Temporal Pattern Characterization Toolis a tool that will be used by UMC to analyse and

visualise the possible temporal patterns between a drug of interest and a medical event of interest.

Through the Web based tool, the eligibility criteria of the populations will be specified. Temporal

Pattern Characterization Method will be run on top of the collected de-identified medical data set. As

a result, the analysis results will be graphically shown to the safety analyst in UMC through a Web

based interface.

o UMC and SRDC is responsible for the specification, implementation and installation

package.



FP7-287800 SALUS



[S-15] Temporal Pattern Association Screening Tool is a tool that will be used by UMC to search

for novel drug – adverse event associations with no prior knowledge of what they expect to find.

Through the Web based tool, the eligibility criteria of the populations will be specified. Temporal

Pattern Association Screening Method will be run on top of the collected de-identified medical data

set. As a result, the analysis results will be graphically shown to the safety analyst in UMC through a

Web based interface.


package.




[S-16] Patient History Toolis used by the safety analysts in UMC to further analyse the details of the

patient records that were already stored in the [D-3] SALUS DB/Repository (e.g. analysing the past

medications of a patient or a set of patients who are suspected for having a serious ADE).


package.




[S-17] Post Market Safety Analysis Tool is a tool that will be used by ROCHE to analyse de-

identified medical data sets of eligible patient populations to answer safety analysis queries. In

SALUS pilot, the identified query is “calculating the rates of CHF in diabetic patients with a recent

acute coronary syndrome (ACS) event and on different diabetic medications”. Through the Web

based tool, the eligibility criteria of the background and foreground populations will be specified,

along with the data collection queries that should run on top of the medical summaries of the eligible

patients (like: Has the patient taken Sulfonylurea anytime within 3 months before start date) stored

within SALUS perimeter. As a result, the statistical results will be sent to [S-17] Post Market Safety

Analysis Tool.

o ROCHE and SRDC are responsible for the specification, implementation and



o ROCHE is responsible for the Deployment.

[S-18] Incidence Rate Calculation Method is a collection of statistical methods that will be used by

ROCHE to analyse de-identified medical data sets of eligible patient populations to answer safety

analysis queries. In SALUS pilot, the identified query is “calculating the rates of CHF in diabetic

patients with a recent acute coronary syndrome (ACS) event and on different diabetic medications”.

The incidence rate calculation method will run on the collected data collection set (like: Has the

patient taken Sulfonylurea anytime within 3 months before start date) stored within SALUS

perimeter. As a result, the statistical results will be sent to [S-17] Post Market Safety Analysis Tool.

o ROCHE is responsible for the specification, implementation and installation package.

o Technology required: Oracle, R or SAS

o LISPA is responsible for the Deployment.

FP7-287800 SALUS


4.2 Physical architecture

In the light of the SALUS and LISPA requirements the physical architecture will be based on four

different servers (HW-1, HW-2, HW-3, HW-4). Two servers will be installed within SALUS

perimeter (HW-1 and HW-2); one server, HW-3, will be installed within the DWH perimeter and

contains the components to feed on a monthly basis the SALUS-LISPA DWH from the main

Lombardy region datawarehouse and to manage the pseudonymization process; one server, HW-4,

will be installed within the SISS perimeter and manages the interfaces with SISS context.

A further detailed analysis of the requirements will be explained below.

Figure 4- Physical architecture

1) The GP authentication has to be performed using the Professional Smart Card (SISS

operator). The strong authentication is performed by the SISS Single Sign On (SSO)

which requires that the GP work station (PDL SISS Postazione Di Lavoro) is connected

to Extranet SISS. SALUS and LISPA GUIs to be used by GPs are running in a dedicated

network in which the HW-2 and HW-4 are. The SALUS and LISPA GUI are exposed to

the GP on the Extranet via the SAMWEB Reverse Proxy. SAMWEB is a component of

the Front-End of LISPA that acts as a gateway between the Extranet and the LISPA

Intranet. SAMWEB contains rules that redirect the URL's used by the GPs to the different

HW-2 and HW-4 systems (respectively for SALUS GUI and LISPA GUI).

2) The SALUS scenarios require the data exchange from the LISPA site and external

site (SALUS non care & research zone: e.g. UMC / ROCHE). A dedicated machine

(HW-1) will be necessary in order to enable a secure connection over internet. HW-1 and

HW-2/HW4 (intranet) cannot be the same, because internet connection cannot be

established from a network where there is a Web Application that needs to be also

FP7-287800 SALUS


reachable from extranet connection (where SALUS GUI / LISPA GUI are hosted: HW-2 /

HW-4).

3) For security reason the SALUS installation has to be physically separated by the

DWH of Lombardy Region. For this reason the HW-2 and HW-3 cannot be the same.

4) DWH Perimeter and SALUS Perimeter don’t have any identification data of the

patient (ref.D8.1.1 Pilot Application Scenario and Requirement Specifications of the

Pilot Application; D8.4.1 Data Protection Plan). The LISPA GUI is the application which

returns to the GP the “PATIENT DATA IDENTIFICATION” in clear, which means it

cannot be in DWH perimeter. For this requirement the LISPA GUI is deployed in the

HW-4 (SISS Perimeter logically contains the Care Zone)which must be physically

separated by the HW-3/HW-2 (DWH / SALUS perimeter: Non Care Zone).

FP7-287800 SALUS


5 DESIGN OF THE REALIZATION OF THE SELECTED

SALUS SCENARIOS IN LOMBARDY REGION

In this chapter we describe in detail the different scenarios to be deployed and validated in Lombardy

Region within the scope of SALUS project in conformance to the restrictions specified in Section

3and also to the physical architecture presented in Section 4.2.

As previously explained the SALUS scenarios will be designed and realised with different

characteristics in the two pilots settings (LISPA and TUD).

In the following table scenarios are listed and for each sub-scenario is indicated the LISPA

deployment.

SCENARIOS LISPA setting

1a Enabling Notification of Suspected ADEs Within regional context, on a monthly

basis, notification versus GPs (simulation),

queries personalization

1b Enabling Semi-automatic ADE Reporting

(ICSR)

Within regional context, on a monthly

basis, reports automatically filled with

information available in SALUS-LISPA

DWH and completed by GPs (simulation)

through authorized access to SISS

perimeter

2a Characterizing the cases and contrasting them

to a background population (CSC)

UMC performs analysis of available data

in SALUS DB/REPOSITORY

2b Temporal pattern characterization UMC performs analysis of available

OMOP CDM data in SALUS

DB/REPOSITORY

3a Temporal association screening on EHRs UMC performs analysis of available

OMOP CDM data in SALUS

DB/REPOSITORY

3b Manual clinical review of relevant medical

history

UMC performs clinical review of OMOP

CDM data stored in SALUS

DB/REPOSITORY

4a Estimate incidence rates of chronic heart failure

(CHF) in diabetic patients with a recent acute

coronary syndrome (ACS) event on different

diabetic medications (ROCHE)

ROCHE performs analysis of available

data in SALUS DB/REPOSITORY

Table 3 – Scenarios list in LISPA pilot

Following an attentive analysis of LISPA DWH it was decided that the scenario 1a and scenario 1b

can be represented in one single use case since there is no real time analysis of data and it makes no

sense to have separate processes for ADE notification and for ADE reporting. Administrative and

clinical data are sent on a monthly basis by health professionals to the regional health authority. The

analysis of adverse drug events in LISPA pilot can be performed when all data are received and stored

in the central DWH at the end of each month (the minimal delay is 15days to 45 days for collecting

prescription data from pharmacies). This constraint implies that ADE notification cannot be

performed in real time but only in a follow-up phase. For that reason ADE notifications will be

received once a month and consequently ICSRs related to the identified ADE will be produced (if the

GP doesn’t consider the notified ADE a real adverse event, the ICSR will not be produced). Scenario

1a and scenario 1b are considered as one single scenario in LISPA pilot. The main objective of these

scenarios is to increase the number of GPs who could produce an ICSR report and to significantly

enhance the data quality of provided reports.

FP7-287800 SALUS


This scenario validation will be mainly based on the results obtained in sub-scenario 1b rather than in

the number of ADE notifications produced in sub-scenario 1a.

LISPA use cases are based on the DWH data protection framework (ref. D8.1.1 Pilot Application

Scenario and Requirement Specifications of the Pilot Application; D8.4.1 Data Protection Plan).

As it will be seen in the pilot scenarios, there is no need for linking the data gathered from LISPA

DWH with external data sources, as the data available in the DWH coming from different hospitals,

laboratories and GP systems are already linked. For this reason, the Pseudonymization service can

directly be hosted by the Data Processor, LISPA in our case, instead of by a trusted third party.

5.1 SALUS Scenario #1 (a and b): Detailed realization of ADE

Notification and ICSR Reporting case in LISPA

Figure 5- Logical realization of ADE Notification and ICSR reporting case in LISPA.

The overall architecture of scenario #1 (a and b) is represented in Figure 5- Logical realization of

ADE Notification and ICSR reporting case in LISPA.As explained in previous sections, the

deployment of this scenario needs to be specialized due to a number of factors in Lombardy Region:

FP7-287800 SALUS


The data in SALUS-LISPA DWH will be updated monthly; hence the analysis for unreported

ADE will be done once in a month effectively. The GP will receive a notification which asks

to re-analyse a patient situation to check if it was a possible adverse drug event.

While the GP examines the notification, s/he may need to identify the patient to check other

relevant medical records from the actual EHR System in Lombardy region (FSE) within SISS

perimeter. This is necessary, because the data analysed by the [S-5] ADE Notification Tool is

pseudonymized. For enabling this, LISPA will provide a specific de-anonymization service.

The [S-5.1] ADE GUI will be deployed in Care Zone, and requires strict authorization

mechanisms for authorization of GPs, integration with SISS single sign on (SSO) is required.

[S-5.1] ADE GUI shall be using the SAMWEB Reverse Proxy mechanism offered by LISPA.

The [S-5] ADE Notification Tool itself is inside the “DWH Zone” (a specific Non Care

Zone”) and does not share any data with a Third Party outside the Non Care Zone.

In the light of these constraints the interaction of components for realizing ADE Notification and

ICSR reporting in LISPA pilot will be as follows:

ID STEP Description

#1a_1 QUERIES [S-5] ADE Notification Tool queries the [D-2] SALUS-LISPA DWH,

through the SALUS Semantic Interoperability and Technical

Interoperability Layers. As depicted in Figure 6, all these tools are

within SALUS Perimeter (HW-2 in particular). Queries to the SALUS-

LISPA DWH need to be consistent with data stored in the database

(regional health system context).

#1a_2 NOTIFICATION After collecting the result set, [S-5] ADE Notification Tool monitors

the changes in EHR of a patient (on a monthly basis since data are not

updated in real time) and when a suspected ADE is detected, this

probable incident is notified to the treating physician through the [S-

5.1] ADE GUI to the GPs in Lombardy Region Pilot (please note that,

the GPs will not be actual GPs of the patient who have experienced the

ADEs, due to the restrictions explained but will be a simulated actor

during pilot phase). In addition there will be a modification for [S-5.1]

ADE GUI provided to the GP in Lombardy Settings. [S-6.1] ICSR GUI

will suggest only selected ADEs to be reported.

#1a_3 PRIVATE ACCESS

TO EHR

The GP checks patient data in EHR system to verify if the notified

event is a real adverse event. LISPA will set up a specific service for

the use of[S-5] ADE Notification Tool ([L-1] SALUS SISS

Components - GET PATIENT NAME). This internal service, upon the

GP request, re-identifies the patient and allows the GP to see patient

EHR through single sign on mechanism into SISS perimeter.

#1a_4 CONFIRM/NOT

CONFIRM

[S-5.1] ADE GUI receives by GP confirmation or not of the notified

ADE and passes this information to [S-5] ADE Notification Tool.

If the GP confirmed the notified event the control is given to [S-6]

ICSR Reporting Tool.

#1b_1 INITIALIZATION [S-6] ICSR Reporting Tool itself resides in DWH Zone. After initiated

by the GP, or by the [S-6] ADE Notification Tool, it communicates

with the SALUS Semantic and Technical Interoperability Layers to

collect the medical summary of the patient (through the SALUS

Pseudonym) from the [D-2] SALUS-LISPA DWH.

FP7-287800 SALUS


#1b_2 DATA RETRIEVAL After retrieving the medical summary, the ICSR is filled as much as

possible through the already available clinical data in [D-2] SALUS-

LISPA DWH.

#1b_3 REPORTING The pre-filled report is presented to the GP in care zone. The [S6.1]

ICSR GUI will be deployed in Care Zone, and requires strict

authorization mechanisms for authorization of GPs; integration with

SISS single sign on (SSO) is required. [S6.1] ICSR GUI shall be using

the SAMWEB Reverse Proxy mechanism offered by LISPA. The

remaining missing information is filled in by the GP who’s able to

access the patient EHR within the SISS perimeter through the SSO

mechanism.

#1b_4 SAVE AND SEND [S-7] Report Generator save the report in [D-3] SALUS DB/Repository

and sends it to De-identification service before final delivery to UMC.

#1b_5 DE-

IDENTIFICATION

AND FORMAT

CONVERSION

The final report is de-identified through the de-identification service

([S-4] De-identification Service) provided by SALUS. This is

necessary, as direct notification of ICSRs to UMC is different from the

process defined by the Italian Law (the real process requires that the

ICSR will be sent to UMC by AIFA and not directly by the Local

Entity (Lombardy Region and Hospital or Local Agency)), hence the

ICSR that is being sent to UMC needs to be de-identified.

#1b_6 AUDITING All communications with Non-Care Zone are audited through [S-12]

Audit Record Repository.

Table 4 – Scenario #1_a and 1_b in LISPA pilot: steps description

Figure 6 - Detailed realization of scenario #1_a in LISPA: ADE Notification.

FP7-287800 SALUS


Figure 7 - Detailed realization of scenario #1_b in LISPA: ICSR Reporting.

The ICSR sent from LISPA pilot to UMC is compliant to E2B format. An AIFA compliant ICSR

report will also be generated. An English translation of each required field has been included in

D8.1.1. For completeness the Italian form in AIFA format is reported in Appendix 2.

FP7-287800 SALUS


5.2 SALUS scenario #2_a:Detailed realization of CSC case in LISPA

Figure 8–Logicalrealization of CSC case in LISPA.

This scenario tries to evaluate the reported potential ADEs by comparing them to the results of a

background population. Data are collected from multiple sources and need to be encoded in a

common format. The Safety Analysis Manager collaborates with the Technical Interoperability

Data service to communicate with the Semantic Interoperability Data Services of each connected

clinical site to fetch needed patient records in the requested OMOP format CDM. Semantic

Interoperability Data Service use the OMOP Converter to transform the patient records expressed

in the SALUS Core Ontology to the local data format of the regulatory body (OMOP data format).

In LISPA Settings the patient records in the requested OMOP format CDM are stored in SALUS

DB/Repository and the Safety Analysis Query Manager analyses the data to calculate population

based statistics within SALUS Perimeters. In other words, for this analysis, individual patient data

does not have to leave DWH Zone, and hence does not need to be further de-identified.

For CSC the data going outside DWH Zone to [S-13] Case Series Characterization Tool (GUI) is as

follows:

List of common medications and the observance rates in Background and Foreground

populations

List of common problems and the observance rates in Background and Foreground

populations

List of common problems before Medication of Interest and the observance rates in

Background and Foreground populations

List of common problems after Medication of Interest and the observance rates in


FP7-287800 SALUS


List of common problems before Condition of Interest (eg. Myocardial Infarction) and the

observance rates in Background and Foreground populations

List of common problems after Condition of Interest (eg. Myocardial Infarction) and the

observance rates in Background and Foreground populations

List of common medications used before Condition of Interest (eg. Myocardial Infarction)

and the observance rates in Background and Foreground populations

List of common medications used after Condition of Interest (eg. Myocardial Infarction) and

the observance rates in Background and Foreground populations

List of common medications used before Medication of Interest and the observance rates in


List of common medications used after Medication of Interest and the observance rates in


The observance rates of pre-selected risk factors (e.g. diabetes) in Background and

Foreground populations

Average ages of Background and Foreground populations

Percentage of patients in different age groups in Background and Foreground populations

Percentage of patients in different gender groups in Background and Foreground populations

Percentage of patients in different country of origins in Background and Foreground

populations

Figure 9- Detailed realization of scenario #2_a in LISPA: CSC.

In the light of these remarks the interaction of components for realizing CSC case in LISPA pilot will

be as follows:

ID STEP Description

#2a_1 PATIENT GROUP

SELECTION

[S-13] Case Series Characterization tool will be used by UMC to

characterize a selected patient group and compare it against a

background population to assess the validity of a reported adverse

event.

#2a_2 DATA RETRIEVAL Through the Web based tool, the eligibility criteria of the background

and foreground populations will be specified, along with the statistical

analysis that should run on top of the medical summaries of the eligible

patients. The query will be sent to SALUS system deployed in SALUS

Perimeter (in particular to [S-9.1] Safety Analysis Query Manager in

HW-1) through HTTPS as depicted in Figure 9.

#2a_3 STATISTICAL

ANALYSIS

[S-9.1] Safety Analysis Query Manager communicates with [S-3.2]

SIL-DS to collect the medical data sets of the eligible patient groups.

These medical data sets will be collected through the other components

FP7-287800 SALUS


of SALUS Semantic Interoperability and Technical Interoperability

Layers as depicted in Figure 9[S-9.1] Safety Analysis Query Manager

stores the data sets in [D-3] SALUS DB/Repository and run the

statistical analysis queries on top of the collected data through invoking

the [S-9.4] Query Result Calculator.

#2a_4 RESULTS The results of the analysis results are sent back to [S-13] Case Series

Characterization Tool. As a result, the analysis results will be shown to

the safety analyst in UMC through a Web based interface.

#2a_5 AUDITING All communications with Non-Care Zone are audited through [S-12]


Table 5 - Scenario #2_a in LISPA pilot: steps description

5.3 SALUS scenario # 2_b and #3_a: Detailed realization of Temporal

Pattern Characterization (TPC) and Temporal Pattern Association

Screening (TAS) Screening Scenarios in LISPA

Figure 10–Logical realization of Temporal Pattern Characterisation (TPC) and Temporal pattern association

screening(TAS) screening scenario in LISPA

These use cases require the collection of coded anonymous data sets of the selected patient

populations(given inclusion/exclusion criteria) including medication and

Problems/Conditions/Diagnosis/Allergies data sets to run the Temporal Pattern Characterization and

Temporal Association Screening methods on top of them. It should be noted that, the collected data

sets are again stored in SALUS Perimeter, only the statistic results of the analysis are shared with

FP7-287800 SALUS


non-care zone as depicted in Figure 11. Hence there is no need to run [S-4] De-identification Service

in this scenario.

HW-2

[D-2]

SALUS-LISPA

DWH

[S-1]

LISPA

CONNE

CTOR

[S-2]

TIDS

QS

[S-3.1]

EHR RDF

Service

[S-3.2]

SIL-DS

SALUS Perimeter

DWH Zone (Scheda 12)

HW-1

[S-9.2] Satey

Anaysis

Subscription

Manager

[D-3]

SALUS

DB/Repository

[S-12]

AUDITRR &

GUI

[S-10] Temporal

Pattern

Characterization

Method

[S-11] Temporal

Pattern Association

Screening Method

UMC

HTTPS

DMZ-RL-InternetHTTPS

[S-14] Temporal

Pattern

Characterization

Tool (GUI)

[S-15] Temporal

Pattern

Association

Screening Tool

(GUI)

Figure 11- Detailed realization of scenario #2_b and #3_a in LISPA: TPC and TAS cases

The interaction of components for realizing TPC and TAS scenarios in LISPA pilot will be as

follows:

ID STEP Description

#2b_1

#3a_1 ELIGIBILITY

CRITERIA

The safety analysts use the [S-14] Temporal Pattern Characterization

Tool or the [S-15] Temporal Pattern Association Screening Tool to

prepare the eligibility criteria of the coded anonymous population data

to be collected. The criteria will be sent to SALUS system deployed in

SALUS Perimeter (in particular to [S-9.2] Safety Analysis

Subscription Manager in HW-1) through HTTPS as depicted inFigure

11.

#2b_2

#3a_2 DATA RETRIEVAL [S-9.2] Safety Analysis Subscription Manager communicates with [S-

3.2] SIL-DS to collect the medical data sets of the eligible patient

groups. These medical data sets will be collected through the other

components of SALUS Semantic Interoperability and Technical

Interoperability Layers as depicted in Figure 11.

#2b_3

#3a_3 STATISTICAL

ANALYSIS

[S-9.2] Safety Analysis Query Manager stores the data sets in [D-3]

SALUS DB/Repository in OMOP Common Data Model format and

run the safety analysis methods ([S-10] Temporal Pattern

Characterization Method or the [S-11] Temporal Pattern Association

Screening Method) on top of the collected data.

#2b_4

#3a_4 RESULTS There results of the analysis results are sent back to [S-14] Temporal

Pattern Characterization Tool or the [S-15] Temporal Pattern

Association Screening Tool. As a result, the analysis results will be

shown to the safety analyst in UMC through a Web based interface.

#2b_5



Table 6 - Scenario #2_b and 3_a in LISPA pilot: steps description

FP7-287800 SALUS


5.4 SALUS scenario #3_b: Detailed realization of Manual Clinical

Review of Patient History scenario in LISPA

Figure 12- Logical realization of Manual clinical review of patient history scenario in LISPA

The Patient History Tool is initiated either after receiving an ICSR to collect more detailed

information about the patient for whom an ICSR is reported or can be initiated after the Case Series

Characterization or Temporal Pattern Characterization Tools are run to see the details of some of the

eligible patients selected in these scenarios. In this first case, the spontaneous report identifier i.e. the

world-wide unique number from the report will be used to query the relevant medical history. In the

second case, the eligibility queries will be run and the Pseudonymized Patient Identifiers will be

depicted to the researcher at Research Zone, after which he selects some of the pseudonymized patient

identifiers to retrieve further medical histories. These Pseudonyms presented to UMC can be created

differently for each query (in order to avoid linking of data sets gathered in different queries). A

mechanism to link the unique spontaneous report identifier with the patients in LISPA will be

implemented.

The information requested by this tool is limited by:

- Prescription information

- Medical Event information

- Lab values

of the selected patients.

When necessary, the safety analysts can use the [S-16] Patient History Tool to query and visualize the

de-identified medical summaries of a patient given a SALUS Pseudo code from the data collected in

[D-3] SALUS DB/Repository. An example case could be analysing the past medications of a patient

or a set of patients who are suspected for having a serious ADE. It should be noted that, the medical

summary of the patient will pass through the [S-4] De-identification Service in this scenario to be

fully de-identified before it is being sent to Research Zone (UMC in this scenario). Agreements will

FP7-287800 SALUS


be established on the rules for de-identification based on LISPA requirements (eg remove rare

diseases, orphan drugs,...).

Currently “re-identification” of the patient’s real identity is not envisioned. Please note that

identifying data is never accessed from Research Zone.

Moreover, due to privacy reasons, in LISPA pilot only a limited number of manual clinical review

requests from UMC are allowed, in order to avoid querying all the patient data one by one to have the

whole patient population.

HW-2

[D-2]

SALUS-LISPA

DWH

[S-1]

LISPA

CONNE

CTOR

[S-2]

TIDS

QS

[S-3.1]

EHR RDF

Service

[S-3.2]

SIL-DS

SALUS Perimeter


HW-1

[S-9.1] Satey

Anaysis Query

Manager

[D-3]

SALUS

DB/Repository

[S-12]

AUDITRR &

GUI

[S-4]

De-Identification

Service

UMC

HTTPS

HTTPS

[S-16] Patient

History Tool

(GUI)

HTTPS

DMZ-RL-Internet

Figure 13–Detailed realization of scenario #3b in LISPA: Manual clinical review of relevant medical history

5.5 SALUS scenario #4_a: Detailed realization of Using EHRs as

secondary use data sources for Post Marketing safety studies

(Estimate incidence rates of chronic heart failure (CHF) in diabetic

patients with a recent acute coronary syndrome (ACS) event on

different diabetic medications) scenario in LISPA

FP7-287800 SALUS


Figure 14-Logical realization of Roche case in LISPA

These use cases require the collection of coded data sets of the selected patient populations(given

inclusion/exclusion criteria) including Medication and Problems/Conditions/Diagnosis/Allergies data

sets to run Safety analysis Methods on top of them by ROCHE researchers. It should be noted that,

the collected data sets will be extracted from SALUS LISPA DWH and stored in SALUS

DB/Repository within SALUS perimeter. On top of this data set ROCHE partner will perform

statistical analysis by initiating the “Incidence Rate Calculation Method (deployed in LISPA

Premises) through a web interface. Only statistical results are sent to the Research Zone. De-

identification methods are not required since data set will be stored in the Non Research and Care

Zone.

General remarks on this scenario are:

Inclusion/exclusion criteria of the selected patient population is specified and a particular data

set including Demographics, Social History, Previous/Active

Problems/Conditions/Diagnosis/Allergies and Previous/Active medications are collected as

coded anonymous data.

The requested data sets are stored in SALUS perimeter, and only statistical results areshared

with the Research Zone.

Please note that ID Data is never accessed from Research Zone.

SALUS Perimeter


HW-1

[S-9.1] Satey Anaysis

Query Manager

[D-3]

SALUS

DB/Repository

[S-12]

AUDITRR &

GUI

[S-9.4] Query

Result Calculator[S-18] Incidence

Rate Calculation

Method

ROCHE

HTTPS

DMZ-RL-Internet

[S-17] ROCHE

Post Market

Safety Analysis

Tool (GUI)

HW-2

[D-2]

SALUS-LISPA

DWH

[S-1]

LISPA

CONNE

CTOR

[S-2]

TIDS

QS

[S-3.1]

EHR RDF

Service

[S-3.2]

SIL-DSHTTPS

Figure 15- Detailed realization of scenario #4_a in LISPA: Roche case

The required data interested in the ROCHE scenario, for each eligible patient is as follows:

Patient id (Pseudonym)

Sex

Date of birth (or year of birth)

Date of ACS event

Date of ACS +30 days (Start date)

History of type 2 diabetes (T2D) before start date (Y/N)

Date of the first T2D diagnosis date ever

Average HbA1C over the 12 months before start date (will be missing for most non diabetic

pts)

Average systolic BP over 12 months before start date

Average diastolic BP over 12 months before start date

History of hypertension before start date (Y/N)

Last BMI before start date

Last weight before start date

Ever smoked before start date(Y/N)

Smoked within the last 3 months of start date(Y/N)

FP7-287800 SALUS


Taken Sulfonylurea anytime within 3 months before start date (Y/N)

Taken metformin anytime within 3 months before start date (Y/N)

Taken insulin anytime within 3 months before start date (Y/N)

Taken Thiazolidinediones (Glitazones) anytime within 3 months before startdate (Y/N)

Taken other oral anti-diabetic drugs within 3 months before start date (Y/N)

Had a CHF before start date (Y/N)

Had a CHF after start date (Y/N)

Date of CHF after start date

Patient died any time after start date(Y/N)

Date of Death

The interaction of components for realizing ROCHE scenario in LISPA pilot will be as follows:

ID STEP Description

#4a_1 INITIALIZATION [S-17] Port Market Safety Analysis Tool will be used by ROCHE to

collect interested data sets to run safety analysis queries. In SALUS

pilot, the identified safety analysis study is “calculating the rates of

CHF in diabetic patients with a recent acute coronary syndrome (ACS)

event and on different diabetic medications”.

#4a_2 ELIGIBILITY

CRITERIA

Through the Web based tool, the eligibility criteria of the background

and foreground populations will be specified (which are already

available in D8.1.1), along with the data collection queries that should

run on top of the medical summaries of the eligible patients (like: Has

the patient taken Sulfonylurea anytime within 3 months before start

date). The query will be sent to SALUS system deployed in SALUS

Perimeter (in particular to [S-9.1] Safety Analysis Query Manager in

HW-1) through HTTPS as depicted in Figure 15.

#4a_3 DATA RETRIEVAL [S-9.1] Safety Analysis Query Manager communicates with [S-3.2]

SIL-DS to collect the requested medical data sets starting from the

eligible patient groups. These medical data sets will be collected

through the other components of SALUS Semantic Interoperability and

Technical Interoperability Layers as depicted in Figure 15.

#4a_4 STATISTICAL

ANALYSIS

[S-9.1] Safety Analysis Query Manager stores the collected data sets in

[D-3] SALUS DB/Repository and run the data collection queries on top

of the collected medical summaries through invoking the [S-9.4] Query

Result Calculator. On top of the selected data set all the necessary

statistical analysis will be carried out by ROCHE researcher through the

[S-18] Incidence Rate Calculation Method to achieve scenario results:

“incidence rates of CHF in diabetic patients with a recent acute

coronary syndrome (ACS) event and on different diabetic medications”.

#4a_5 RESULTS The results of the statistical analysis are sent back to [S-17] Post Market

Safety Analysis Tool.



Table 7 - Scenario #4_a in LISPA pilot: steps description

FP7-287800 SALUS


6 SPECIFIC SERVICES FOR SALUS

6.1 LISPA GUI for De-Anonymization service

Within the scenarios #1_a and #1_b an additional internal component needs to be developed for

LISPA pilot. When the GP receives the ADE notification or ICSR of a suspected ADR for his/her

patient it is necessary to investigate the clinical information regarding this patient and to analyse the

data related to the possible ADR. ADE Notification Tool and ICSR Reporting Tool have access to

only pseudonymized patient data in SALUS LISPA-DWH. Thus it is important to provide the GP

with an appropriate tool which connects him directly to the patient EHR, within SISS perimeter,

through a de-anonymization process.

In particular, connecting to SALUS – GUI, the GP can de-anonymized the PATIENT PSEUDO

CODE with the GET PATIENT NAME Button. The Application invokes the LISPA WEB

application GETPATIENT, open a new browser where the GP can see the CLEAR NAME of the

PATIENT.

This solution respects the DWH perimeter rule where no Patient Personal Data have to be logged or

stored.

Figure 16 - LISPA GUI de-anonymization service

The above presented screenshot (Figure 16) provides details about the LISPA GUI de-anonymization

service. This service consists of the following steps:

1. The SALUS GUI passes to LISPA GUI (e.g. servlet) a “DATA SET” as follow: o ICSR/ADE SERIAL CODE;

o GP DATA: Social Security Number (in Italian Codice Fiscale);

o PATIENT PSEUDO CODE, AGE and SEX.

2. The LISPA GUI performs the following actions: a) Using the PATIENT PSEUDO CODE, invoke the DWH to retrieve the DWH PSEUDO

CODE;

b) Using the DWH PSEUDO CODE, invoke the SISS services to retrieve the PATIENT

DATA:NAME, LAST NAME, CF (Codice Fiscale – Social Security Number), AGE,

SEX;

c) Using the CF of the Patient and the CF of GP, invoke the SISS service in order to verify if

the GP is currently the GP of this Patient.

FP7-287800 SALUS


On the technical side, within DWH perimeter, there is a table containing the mapping between the

patient DWH pseudo-code and the patient SALUS-LISPA DWH pseudo-code.

This table is needed for the de-anonymization service of [L-1] SALUS-SISS components. Moreover,

within the SISS perimeter, a “sub table” of DWH_PATIENT_FOR_SALUS

(VIEW_for_SALUS_PSEUDO_CODE) is used by LISPA-GUI de-anonymization service for

retrieving the patient identifier.

Figure 17 – Mapping between RL-DWH pseudo-code and SALUS-LISPA DWH pseudo-code

6.2 GP Single Sign On

The GP access to the SISS Extranet is done through Single Sign On authorisation (SSO). Hereafter we

provide the interface specifications for web applications to be connected to the Extranet. Every

partner of Healthcare System who participates in SISS, and who is willing to create and/or use a web

service should consider the following requirements.

6.2.1 Access to Web Application

To access an exposed web application, the Operator has first to be logged on with the Primary Logon

to the Extranet. After the Primary Logon, the Operator can access the available Web Applications.

The following steps will be repeated for each access request:

1. The request is intercepted by the Reverse Proxy located on the Front End of the Partner;

2. The Reverse Proxy checks for an authenticated session of the user and for the access

permission to the required web service, in relation to the application role and the functional

context of the Operator;

3. The Reverse Proxy obtains the user credentials from the LDAP directory of the authentication

server and sends it to the web application of the Partner using HTTP header.These steps,

which constitute the secondary authentication (or Secondary Logon) for the web application,

are transparent to the user.

6.2.2 Interfaces design requirements

This chapter describes the specifications for exposing a proprietary web application.

The parameters exchange between SISS and Partner is done through the web standard mechanisms

(such as the headers of the HTTP protocol), therefore the Web Application of the Partner must be able

to handle the HTTP headers. In addition, the information contained in the parameters can be in XML

format, so the application must be able to process the message in XML format in order to access the

FP7-287800 SALUS


data. The access to such information is necessary in case the Partner wants to identify the user and/or

further filtering the access on the basis of parameters in addition to those indicated in the

authorization logic specified in the act of web application exposure.

6.2.2.1 Parameters format

The parameters exchanged throughout the HTTP header to the exposed web application are used to

identify and characterize the originator of the request. The parameters in the HTTP header are as

follows:

Parameter Meaning

USERID User identifier (identifies the “originator of the

request). This is the social security number of the

user.

ROLE Numerical code for the application role of

originator of the request

ACTIVCRED User credentials of originator of the request

Table 8 – Parameters example

The above listed parameters are present in the HTTP header of each request. The values of USERID

and ROLE are also inside the Credentials. The ROLE parameter can also be used to determine

whether the request belongs to the virtual circuit of the SISS. The method of access to the variables in

the header is related to the language used for the creation and management of web pages (e.g. in

PERL the prefix HTTP_ should be added). Below there are two examples of access to these variables

in JSP and PERL.

JSP example:

PERL example:

FP7-287800 SALUS


6.2.2.2 User Identification and Authentication

The web application exposed by the Partner does not have to require login for users accessing it via

Extranet, as the process of identification and authentication is already done during the Primary Logon

when the user connects to the SISS. In particular the application should not require an explicit input

from the user as a username and a password, but it can use the information in the HTTP header of

every request to identify the user. The Internet standards require that a web session opened by a user

remains active by default on the web server of the service exposed until the end of the session

timeout. In the case where an operator performs the Logout from the SISS and is replaced by another

operator (properly authenticated) without that the browser has been closed, the web application can

detect the change of the user in the same session verifying that the Social Security Number sent by the

reverse proxy at each access matches the one of the operator who opened the session. At the present

stage of the SISS in order to avoid identification mistakes it is necessary that the application

detects such a change of the user and proceeds with the automatic closing of the browsing

session and reopening a new session registered to a new operator’s name. To build this measure

and to avoid further interactions with existing application it is enough to realize a filter (if J2EE

architecture or equivalent mechanism for the other) which is able to detect the change of a user in the

field of an active session and provide for a new session “ mapped” to a new user.

6.2.2.3 User authorization

The authorization process for an access to a web application exposed by the Partner is carried out by

Reverse Proxy that enables or prevents the access to resources of the application based on the

information from the Credentials and authorization rules previously disclosed by the Partner to the

CGI Extranet.

It is up to the Partner to extend the authorization process carried out by the Reverse-Proxy, using the

information contained in the credentials in the HTTP header of each request, to create new

authorization rules.

6.2.2.4 Name conventions for the web application

A web application exposed by the Partner to the Extranet is accessible on the Extranet through a URL

structured as follows

https://<dcss>.cgi.crs.lombardia.it/<path-application>/

where<dcss> is<structure>, a unique name chosen by the Structure and <path-application> is the path

(at most it consists of a single name) selected to identify the web application on the Extranet (it is

possible to exchange parameter in the URL). NOTE: The URL must always be terminated with the” /

“character. The exposure of a web application to the Extranet will then be via the domain

cgi.crs.lombardia.it. In case the Partner exposes more than one web application, the corresponding

URLs differ only relatively to the component <path-application>, for example:

https://dcss.cgi.crs.lombardia.it/ <path-application-1> /

https://dcss.cgi.crs.lombardia.it/ < path-application -2> /

https://dcss.cgi.crs.lombardia.it/ < path-application -3> /

All services of the Structure will then be accessed through a single hostname

(struttura.cgi.crs.lombardia.it). Since https protocol is used for the authentication, this policy of

naming allows installing only one server certificate at the Partner Front End. In addition, it allows

limiting interventions on Front Ends only to the mapping rules of the Reverse Proxy in case of

exposure of additional applications. Therefore the choice of a name for a “structure” must be made

before the installation of services on the Front End itself.

6.2.2.5 Routing rules for the Reverse Proxy

The URL naming convention refers to the exposure of web applications on the Extranet, or to the way

in which these applications are exposed through Reverse Proxy and does not imply that the same

convention should necessarily be adopted internally by the Partner.

In the Partner settings, the web application can reside on one or more hosts. The matching between

the ‘Extranet name “and the” internal name “of an application is done by the Reverse Proxy by using

the routing rules. Such rules allow the Partner to put his web applications on the Intranet server,

without keeping the hostname visible to the Extranet. The path of the application in the routing (i.e.

FP7-287800 SALUS


the part of the URL that comes after the hostname) in the Extranet name must match the path of the

(internal) Intranet name.

The following figure shows the above discussed rules:

The components of “path” in the Extranet name and internal name must match.

The parameter exchange in the URL is allowed, if provided by the Web application, but it is not

allowed to use the parameters to identify the Web application exposed. For example this URL is not

allowed: https://dcss.cgi.crs.lombardia.it/entrypoint?applicazione=app1.

6.2.2.6 Accessing application through the Proxy

The Partner web application must be compliant with specific requirements in order to be exposed on

the Extranet through the Reverse Proxy:

Do not contain absolute references to internal resources, but only links. In other words, any

resources referred inside the application (such as, for example, images or links to other pages)

should be sent via relative URLs, that is, the URLs where only path component is indicated

without the protocol and hostname components. Besides the URLs, the paths should also be

relative that is they do not have to start with the character”/”. For example:

Absolute URLs ( Can NOT be used ) Relative URLs ( can be used )

http(s)://hostname/logo.gif logo.gif

http(s)://hostname/subdir1/index.html subdir1/index.html

Not :It is not possible to use relative URLs of the

type /subdir1/index.html, even though being relative

(protocol and hostname are not indicated) they are

anyway absolute paths.

Provide a single entry point from which all other sub-services start. Thus, it is not allowed to

link to sub-services which do not belong to the tree of the application access URL (root

URL): for example, assuming that the access URL of the Web Application is

http(s)://hostnameX/directoryY/pageJ.jspit is not allowed to link to pages that do not reside

under the pathdirectoryY such as http(s)://hostnameX/directoryZ/pageJ.jsp.

6.2.2.7 Exposure of the Web Application architecture made in Web 2.0

This method for developing the web application involves the construction of an application

component operating in the browser which can perform operations independently, ideally delivering

locally to the web browser the entire navigation logic and presentation. Applications, built with this

architecture interacting with their back-end, working in the background (normally through

programmed http requests to the web server of the web application) in order to maximize response

times and avoid page reloads during the user interaction. Applications that perform callback http are,

for example, made through Javascript / AJAX or FLEX.

https://dcss.cgi.crs.lombardia.it/entrypoint?applicazione=app1

FP7-287800 SALUS


This architecture is supported by integration with the web browser. The above mentioned

technologies use the authenticated channel open with SAM WEB when the application is being

loaded in the browser, and therefore http requests to the web server are sent correctly.

Please, note, the accesses in cross domain, even where supported by the technology used for the

development, may cause authentication problems: the opening of a new http channel to a different

web application protected by SAM WEB causes the request to open a SSL channel in client

authentication mode. This mode is run by the browser when loading a web page but is not normally

supported by the web 2.0 development environments.

The web resources such as the file download or streams due to their size cannot use the normal

interface A2A mediated Delegated Port /Application Port, still the access can be done by the

programming (that web browsing is represented by the normal download). From a functional point of

view, interactions “web 2.0” are suitable for access to the data and services of the back-end of the

application Partner who provides it. In the event that the application needs to use services provided

under a different domain of responsibility (e.g. another Partner of the SISS) interactions in A2A mode

should use the services that the Partner-Provider offers by the specific methods callable via Delegated

Port of the Operator who are using the web application.

FP7-287800 SALUS


7 SALUS-LISPA DWH

7.1 Data requirements

The overall data requirements for the SALUS system were defined in D4.1.1 (SALUS Content

models for the Functional Interoperability Profiles for Post Market Safety Studies) and summarized in

the table below. This table is a work in progress since the data content model will be revised and

documented in D4.1.2 which will be released by month 24. Further information about RL-DWH are

also reported in D8.1.1 (Pilot Application Scenario and Requirement Specifications of the Pilot

Application).

Each data required by each SALUS scenario is evaluated in terms of required and optional. For pilot

deployment analysis in LISPA setting it is necessary to identify which data are really exportable in

SALUS-LISPA DWH and which data are not exportable since, as previously explained, these data are

originally stored in a health regional system and not in a hospital EHR system. Data availability in

LISPA setting is further detailed in the following paragraphs, however, this information is also

summarized and represented in the table below. This is a preliminary evaluation of data availability

on the basis of DWH fields. Some change can occur after content model revision and following

further investigations of required data types.

Legend

x = Required

x(o) = Optional

Available in SALUS-LISPA DWH

NOT available in SALUS-LISPA DWH

Selected SALUS Scenarios/Related EHR Sections

Selected SALUS Scenarios/Related EHR Data Items 1a

: E

nab

lin

g N

oti

ficati

on

of

Su

specte

d A

DE

s

1b: E

nab

lin

g S

emi-

au

tom

ati

c

AD

E R

ep

ort

ing

2a:

Ch

ara

cte

rizin

g t

he c

ase

s an

d

co

ntr

ast

ing

th

em

to

a

back

gro

un

d p

op

ula

tio

n

2b

: T

em

po

ral

patt

ern

ch

ara

cte

rizati

on

3a:

Ru

nn

ing

Ex

plo

rato

ry

An

aly

sis

Stu

die

s o

ver

EH

Rs

for

Sig

nal

Dete

cti

on

4a:

Calc

ula

tin

g i

ncid

en

ce r

ate

s

of

CH

F i

n d

iab

eti

c p

ati

en

ts

wit

h a

recen

t acu

te c

oro

nary

syn

dro

me

(AC

S)

even

t)

Patient(*) Patient Name or Initials x (o)

ID

x (o) (Pseudonym)

Date of Birth x

x (Age is to be derived)

x (Year of Birth is Adequate)



Gender x x (o) x x x

Race x x(o) x (o)

Birth Place (Region or City) x

Patient registration date x (o)

Patient de-registration date x (o)

Ethnicity x(o) x(o)

Provider ID x(o)

FP7-287800 SALUS


Provider Organisation ID x(o)

Address x(o)

Investigation number x (o)

Pregnancy(*) YES/NO x (o)

Delivery Date x (o)

Pregnancy Status x (o)

Last Menstrual Period Date x (o) x (o)

Condition(*) (Past Medical History) Problem Name x(o) x(o) x x x

Problem code x(o) x(o) x x x x

Start Date x(o) x(o) x x x x

End Date x(o) x(o) x x (o) x x (o)

Problem Status x(o) x(o) x

Date of Entry x x x

Related Encounter x (o)

Treating Provider x (o)

Severity x(o)

Comments / text describing Problem x(o)

Condition (Active Problems/Symptoms) Problem Name x x (o) x x x

Problem code x x (o) x x x x

Start Date x x (o) x x x x

End Date x x (o) x x x x (o)

Problem Status x x (o) x

Date of Entry x x

Related Encounter x x

Treating Provider x

Severity x

Comments / text describing Problem x(o)

Allergies/Intolerance Adverse Event Type (text) x (o) x (o) x x

Adverse Event Type (coded) x (o) x x x

Product Code x (o) x

Product Name x (o) x

Reaction x (o) x

Start Date and Time x (o) x (o) x x

Severity x (o)

x (o) (seriousness)

Date of end of reaction/event x (o) x (o)

Outcome of reaction/event at the time of last observation x (o) x (o)

Date of Entry x x

Comments / text describing the allergy/intolerance x (o)

Family History Kinship Type x (o)

Family History Observation x (o)

FP7-287800 SALUS


name

Family History Observation code x (o)

Age at Onset x (o)

Lab Results(*) Result Type (text) x x (o) x x

Result Type (Coded) x x (o) x x x

Result Value (Numeric) x x (o) x x x

Result Value (Coded) x x (o) x x x

Result Value (String) x x (o) x x x

Unit x x (o) x (o)

Result Date x x (o) x

Result Reference range x x (o) x (o) x (o) x (o)

Result Interpretation x x (o)


Related Condition x (o)

Result Provider x (o)

Procedures(*) Procedure Type (text) x x (o)

Procedure Type (coded) x x (o) x

Body Site x x (o)

Procedure Date x x (o) x

Procedure Status x x (o)

Indication x x (o)


Procedure Provider x (o)

Comments / text describing Procedure x(o)

Medications(*) Product Name x x x x x x

Product Code x x x x x x

Brand name x x (o)

Brand code x x (o)

Active Ingredient Name x x x x x

Active Ingredient Code x x x x x

Product Form (of administration x x (o)

Dose x x (o) x

Unit x x (o) x

Frequency x x (o) x

Route (Coded) x x (o) x

Start Date5 x x (o) x x x x

End Date x x (o) x x (o) x x (o)

Duration x x (o)

Indication x x (o) x (o)

Order Date x

Date of Entry x x x

Refills x (o)

5It is possible to know only when the patient bought the medication. For hospital settings in Italy patients are

treated with drugs but there is no trace of connection between hospital prescription and patient a part from the

hospital clinical record (which is often in a paper format). At hospital discharge or in day hospital the situation

is different and there is a drug prescription entitled to the patient (this contains the date).

FP7-287800 SALUS


Quantity x (o)

Days Supply x (o)


Fulfillment Instructions x (o)

Prescribing Provider x (o)

Stop reason x (o) x (o)

Encounters(*) Start Date x x

End Date x x

Encounter Performer (Provider) x

Encounter Type x x (o)

Care Provider Location (Organisation) x x (o)

Reason for Encounter x

Vital Signs(*) Result Type (text) x x (o) x

Result Type (Coded) x x (o) x x

Result Value (Numeric) x x (o) x x

Result Value (Coded) x x (o) x

Result Value (String) x x (o) x

Unit x x (o) x (o) x

Result Date x x x

Result Reference range x x (o)

Result Interpretation x


Related Condition x (o)

Result Provider x (o)

Social History Social history type x x

Social history status x x

Social history dates

Data Reporter Reporter title x(o)

Reporter given name x(o)

Reporter family name x(o)

Reporter organization x(o)

Reporter address x(o)

Reporter qualification x(o)

Death Date of Death x (o) x (o)

Cause(s) of death x (o)

Was autopsy done? x (o)

Autopsy-determined cause(s) of death

x (o)

Healthcare Provider

Provider ID x

ProviderType x (o)

Organisation x (o)

Organisation organisationID x x

organisationAddress x x (o)

organisationType x (o)

organisationName x x (o)

Code code

codeSystem

FP7-287800 SALUS


codeSystemName

codeSystemVersion

displayName

Table 9 – Data requirements

(*) It’s possible to know when a citizen became Lombardy citizen (start date) and when she/he

changes region or death. In any case it’s important to consider that the DWH has online only a certain

period for query. After 10 years the date are off line archived. So it is possible to retrieve data for a

period of about 10 years.

7.2 Entity Relationship Model

LISPA extracts on a monthly basis the necessary data attributes from Region Lombardy DWH and

send them to SALUS-LISPA DWH. Data export is based on the data requirements for all scenarios

and only relevant data is extracted into the SALUS-LISPA DWH (seeFigure 18). This preliminary

model could be affected by changes due to revision to data content model which will be further

discussed by the consortium and consolidated in D4.1.2.

All data attributes of RL DWH were presented in the Lombardy DWH flow sources table presented in

Appendix 3 of the deliverable SALUS D8.1.1 Pilot Application Scenario and Requirement

Specifications of the Pilot Application.

SALUS-LISPA DWH will contains these specific tables:

SALUS.ALLERGY

SALUS.AMBULATORY

SALUS.CONDITION

SALUS.DRUGS

SALUS.DRUGS_CODE

SALUS.GP

SALUS.HAS_GP

SALUS.HOSPITALIZATION

SALUS.PATIENT

SALUS.PATIENT_PREGNANCY

SALUS.VACCINATION

All tables are represented in the following entity relationship diagram.

FP7-287800 SALUS


Figure 18 – SALUS-LISPA DWH: Entity Relationship Diagram

FP7-287800 SALUS


For each SALUS-LISPA DWH table a detailed description about attributes is provided.

Design Name SALUS SCHEMA 04-04-2013

Version Date 08.05.2013 12:55:07

Version Comment

Model Name Relational_1

Table Name SALUS.ALLERGY

Functional Name

Abbreviation

Classification Type Name

Object Type Name

Columns

No Column Name PK FK M Data Type DT kind

Domain Name

1 ID P Y Integer DOM Integer_0_0_0

2 PATIENT_ID F Y VARCHAR (255) DOM VARCHAR_0_0_255

3 ALLERGY_CODE_ICD9CM Y CHAR (10) DOM CHAR_0_0_10

4 ALLERGY_DESC_ICD9CM Y VARCHAR (128) DOM VARCHAR_0_0_128

5 START_DATE Y Date DOM Date_0_0_0

6 END_DATE Date DOM Date_0_0_0

7 CURRENT_DATE Y Timestamp (6) DOM Timestamp_6_0_0

Columns Comments

No Column Name Description Notes

3 ALLERGY_CODE_ICD9CM Deducted by DWH=SDO.DIAGP_ID; DIAG1_ID; DIAG2_ID; DIAG3_ID; DIAG4_ID; DIAG5_ID;AMB.DIAG_ID contain ICD9 Allergy codes

4 ALLERGY_DESC_ICD9CM Language: Italian

5 START_DATE YYYYMMDD DWH=SDO.DATA_RICOVERO

6 END_DATE YYYYMMDD ISSUE: dwh doesn't have a specific end date for an Allergy

ISSUE: dwh doesn't have a specific end date for an Allergy

FP7-287800 SALUS



7 CURRENT_DATE TimeStamp of Record Insert / Update

Indexes

Index Name State Functional Spatial Expression Column Name Sort

Order

ALLERGY_PK PK ID ASC

Foreign Keys (referring to)

Name Referring To Mandatory Transferable In Arc Column Name

ALLERGY_PATIENT_FK PATIENT Y Y PATIENT_ID

Table Name SALUS.AMBULATORY

Functional Name

Abbreviation


Object Type Name

Columns


Domain Name




4 END_DATE Y Date DOM Date_0_0_0

5 DIAGNOSIS_CODE_ICD9CM Y CHAR (10) DOM CHAR_0_0_10

6 DIAGNOSIS_DESC_ICD9CM Y VARCHAR (128) DOM VARCHAR_0_0_128

7 AMB_ORDER_CODE Y CHAR (10 BYTE) DOM CHAR_0_0_10 BYTE

8 AMB_ORDER_DESC Y VARCHAR (128 BYTE) DOM VARCHAR_0_0_128 BYTE

9 AMB_SPECIALTY_ID Y CHAR (10 BYTE) DOM CHAR_0_0_10 BYTE

10 AMB_SPECIALTY_DESC Y VARCHAR (128 BYTE) DOM VARCHAR_0_0_128 BYTE

11 AMB_TYPE CHAR (1 BYTE) DOM CHAR_0_0_1 BYTE

FP7-287800 SALUS



Domain Name

12 FLAG_LAB_EXAM_AMB Y CHAR (1 BYTE) DOM CHAR_0_0_1 BYTE


Columns Comments


1 ID Unique Identifier automatically generated by oracle at record creation time

3 START_DATE DWH=AMB.DATA_EROGAZIONE

4 END_DATE DWH=AMB.DATA_FINE_EROGAZIONE

5 DIAGNOSIS_CODE_ICD9CM DWH=AMB.DIAG_ID In some cases the DIAG is not evaluated (eg. in the case of LAB)

In some cases the DIAG is not evaluated (eg. in the case of LAB)

6 DIAGNOSIS_DESC_ICD9CM

DWH=AMB.DIAG_DESC In some cases the DIAG is not evaluated (eg. in the case of LAB) Language: Italian Language: Italian

7 AMB_ORDER_CODE Italian Code ; DWH=AMB.PRESTAZ_AMB_ID ISSUE: To Map with Standard/International Code

ISSUE: To Map with Standard/International Code

8 AMB_ORDER_DESC DWH=AMB.PRESTAZ_AMB_DESC Language: Italian

Language: Italian

9 AMB_SPECIALTY_ID DWH=AMB.DISCIP_ID Lombardy SPECIALTY Code

Lombardy SPECIALTY Code

10 AMB_SPECIALTY_DESC Eg: OTORINOLARINGOIATRIA ; PNEUMOLOGIA; ORTOPEDIA E TRAUMATOLOGIA; CHIRURGIA GENERALE; PNEUMOLOGIA Language: will be Translated in English

Language: will be Translated in English

11 AMB_TYPE DWH=AMB.TIPO_PRESCRIZ_ID; O=Ordinary, P=ER; Z=PLANNED; U=URGENT; M=Other;S=Screening

12 FLAG_LAB_EXAM_AMB DWH=AMB.DISCIP_DESC combined with PRESTAZ_AMB_ID we deduct if it is a Laboratory, Examination, Procedure etc Examination=0; Laboratory = 1; Procedure=2;

Examination=0; Laboratory = 1; Procedure=2;

Indexes


Order

AMBULATORY_PK PK ID ASC

AMBULATORY__IDXv1 ID ASC

PATIENT_ID ASC

FP7-287800 SALUS



Order

DIAGNOSIS_CODE_ICD9CM ASC

FLAG_LAB_EXAM_AMB ASC



AMBULATORY_PATIENT_FK PATIENT Y Y PATIENT_ID

Table Name SALUS.CONDITION

Functional Name

Abbreviation


Object Type Name

Columns


Domain Name



3 CONDITION_CODE CHAR (10 BYTE) DOM CHAR_0_0_10 BYTE

4 CONDITION_DESC VARCHAR (128 BYTE) DOM VARCHAR_0_0_128 BYTE

5 CONDITION_CODE_SNOMED Y VARCHAR (16 BYTE) LT

6 CONDITION_DESC_SNOMED Y VARCHAR (128) DOM VARCHAR_0_0_128




10 Column_9 DOM

Columns Comments


2 PATIENT_ID The Patient condition is deducted by an algorithm (based on a complex query running on all data of DWH). This algorithm identify for every

The Patient condition is deducted by an algorithm (based on a complex query running on all data of DWH). This algorithm identify for every

FP7-287800 SALUS



patient his/her main condition. The Start Date is the first day of the year (YYYY-01-01) and the end date is the end of the year. In some cases the end date can be null.

patient his/her main condition. The Start Date is the first day of the year (YYYY-01-01) and the end date is the end of the year. In some cases the end date can be null.

3 CONDITION_CODE Lombardy Code Lombardy Code

4 CONDITION_DESC Language: Italian Language: Italian

5 CONDITION_CODE_SNOMED Lombardy Codes Mapped to SNOMED Code. Lombardy Codes Mapped to SNOMED Code.

6 CONDITION_DESC_SNOMED Language: Translated in English Language: Translated in English

7 START_DATE YYYYMMDD

8 END_DATE YYYYMMDD

Indexes


Order

CONDITION_PK PK ID ASC



CONDITION_PATIENT_FK PATIENT Y Y PATIENT_ID

Table Name SALUS.DRUGS

Functional Name

Abbreviation


Object Type Name

Columns


Domain Name



3 DELIVERY_DATE Y Date DOM Date_0_0_0

FP7-287800 SALUS



Domain Name

4 END_DATE_ESTIMATION67 Integer DOM Integer_0_0_0

5 NUM_DDD Y FLOAT DOM FLOAT_0_0_0

6 DDD_DAY Y FLOAT DOM FLOAT_0_0_0

7 THERAPY_USAGE_DAY_SUGGESTED VARCHAR (255 BYTE) DOM VARCHAR_0_0_255 BYTE

8 AMOUNT_OF_DRUG_DISTRIBUTED Y Integer DOM Integer_0_0_0

9 MEASURE_UNIT Y CHAR (4 BYTE) DOM CHAR_0_0_4 BYTE

10 AIC_CODE F Y CHAR (10 BYTE) DOM CHAR_0_0_10 BYTE

11 ATC_CODE Y CHAR (10 BYTE) DOM CHAR_0_0_10 BYTE


Columns Comments


1 ID Unique Identifier automatically generated by oracle at record creation time

3 DELIVERY_DATE YYYYMMDD DWH=FILEF.DATA_EROGAZIONE; FARMA.DATA_EROGAZIONE

4 END_DATE_ESTIMATION DWH=FILEF;FARMA.QTA_FARMA_EROG_VERIF*FARMA.GIORNI_DDD

5 NUM_DDD DWH=FILEF.NUM_DDD;FARMA.NUM_DDD. It is the NUM DDD of Active ingredient

6 DDD_DAY DWH=FILEF.GIORNI_DDD;FARMA.GIORNI_DDD. It is the TOTAL Days of the package.

7 THERAPY_USAGE_DAY_SUGGESTED ISSUE: TB Decide which field of DWH we can use ISSUE: TB Decide which field of DWH we can use

8 AMOUNT_OF_DRUG_DISTRIBUTED DWH=FARMA.QTA_FARMA_EROG_VERIF; FILEF.QTA_FARMACO_EROG

9 MEASURE_UNIT ISSUE: Gram, Mgram, etc. We need a code ISSUE: Gram, Mgram, etc. We need a code

10 AIC_CODE ISSUE: it is an Italian Code that identify univocally the drugs in term of: Form, Active ingredient, etc. To be decide if we need a map with an international code

ISSUE: it is an Italian Code that identify univocally the drugs in term of: Form, Active ingredient, etc. To be decide if we need a map with an international code

11 ATC_CODE Active Ingredient Code

Indexes

6 This is an ESTIMATION of duration of treatment (based on DDD_DAY*AMOUNT OF DRUG DISTRIBUTED).

7 This is just a timestamp required by development partner.

FP7-287800 SALUS



Order

DRUGS_PK PK ID ASC



DRUGS_DRUGS_CODE_FK DRUGS_CODE Y Y AIC_CODE

DRUGS_PATIENT_FK PATIENT Y Y PATIENT_ID

Table Name SALUS.DRUGS_CODE

Functional Name

Abbreviation


Object Type Name

Columns


Domain Name

1 AIC_CODE P Y CHAR (10 BYTE) DOM CHAR_0_0_10 BYTE

2 AIC_DESC Y CHAR (70 BYTE) DOM CHAR_0_0_70 BYTE

3 ATC_CODE Y CHAR (10 BYTE) DOM CHAR_0_0_10 BYTE

4 ATC_DESC Y CHAR (70 BYTE) DOM CHAR_0_0_70 BYTE

5 ATC_GROUP_CODE VARCHAR (10 BYTE) LT

6 ATC_GROUP_DESC_IT VARCHAR (70 BYTE) LT

7 ATC_GROUP_DESC_ENG VARCHAR (70 BYTE) LT

8 ROUTE_ADM_CODE_IT Y CHAR (10 BYTE) DOM CHAR_0_0_10 BYTE

9 ROUTE_ADM_DESC_IT VARCHAR (201 BYTE) LT

10 ROUTE_ADM_CODE_ENG VARCHAR (10 BYTE) LT

11 ROUTE_ADM_DESC_ENG VARCHAR (250 BYTE) LT

12 DDD Y CHAR (10 BYTE) DOM CHAR_0_0_10 BYTE

13 UNIT_DDD Y CHAR (10 BYTE) DOM CHAR_0_0_10 BYTE

14 COMPANY_CODE Y CHAR (4 BYTE) DOM CHAR_0_0_4 BYTE

FP7-287800 SALUS



Domain Name

15 COMPANY_DESC Y VARCHAR (1000 BYTE) DOM VARCHAR_0_0_1000 BYTE

16 CURRENT_DATE Timestamp (6) LT

Columns Comments


1 AIC_CODE DWH=FARMA.FARMACO_ID;FILEF.FARMACO_ID

2 AIC_DESC DWH=FARMA.FARMACO_DESC ;FILEF.FARMACO_DESC

3 ATC_CODE DWH=FARMA.ATC_ID ;FILEF.ATC_ID

4 ATC_DESC DWH=FARMA.ATC_DESC ;FILEF.ATC_DESC

5 ATC_GROUP_CODE ATC Code or ATC codes associations Coding Data: Table -> GRUPPO_PA.CD_GRUPPO_PA Join with Table ->Farmaco.CD_PA

ATC Code or ATC codes associations Coding Data: Table -> GRUPPO_PA.CD_GRUPPO_PA Join with Table ->Farmaco.CD_PA

6 ATC_GROUP_DESC_IT ATC Code or ATC codes associations Coding Data: Table -> GRUPPO_PA.DS_GRUPPO_PA Language: Italian if Table ->GRUPPO_PA.Lingua = ITA

ATC Code or ATC codes associations Coding Data: Table -> GRUPPO_PA.DS_GRUPPO_PA Language: Italian if Table ->GRUPPO_PA.Lingua = ITA

7 ATC_GROUP_DESC_ENG

ATC Code or ATC codes associations Coding Data: Table -> GRUPPO_PA.DS_GRUPPO_PA Language: Italian if Table ->GRUPPO_PA.Lingua = ENG (will be available in the future)

ATC Code or ATC codes associations Coding Data: Table -> GRUPPO_PA.DS_GRUPPO_PA Language: Italian if Table ->GRUPPO_PA.Lingua = ENG (will be available in the future)

8 ROUTE_ADM_CODE_IT Coding Data: Table -> TIPO_VIE_SOMMINISTRAZIONE.CD_VIESOMM For Italian Language Description

Coding Data: Table -> TIPO_VIE_SOMMINISTRAZIONE.CD_VIESOMM For Italian Language Description

9 ROUTE_ADM_DESC_IT Coding Data: Table -> TIPO_VIE_SOMMINISTRAZIONE.DS_VIESOMM Language: Italian

Coding Data: Table -> TIPO_VIE_SOMMINISTRAZIONE.DS_VIESOMM Language: Italian

10 ROUTE_ADM_CODE_ENG

Coding Data: Table -> TIPO_VIE_SOMMINISTRAZIONE.CD_EPSOS_CODE For English Language Description (will be available in the future)

Coding Data: Table -> TIPO_VIE_SOMMINISTRAZIONE.CD_EPSOS_CODE For English Language Description (will be available in the future)

11 ROUTE_ADM_DESC_ENG

Coding Data: Table -> TIPO_VIE_SOMMINISTRAZIONE.DS_EPSOS_NAME Language: English (will be available in the future)

Coding Data: Table -> TIPO_VIE_SOMMINISTRAZIONE.DS_EPSOS_NAME Language: English (will be available in the future)

12 DDD DWH=FARMA.GIORNI_DDD ;FILEF.GIORNI_DDD

13 UNIT_DDD DWH=FARMA.NUM_DDD ;FILEF.NUM_DDD oppure UNITA_MISURA_DESC

FP7-287800 SALUS



14 COMPANY_CODE LISPA CODING DATA

15 COMPANY_DESC LISPA CODING DATA

Indexes


Order

DRUGS_CODE_PK PK AIC_CODE ASC

Foreign Keys (referred from)

Name Referred From Mandatory Transferable In Arc Column Name

DRUGS_DRUGS_CODE_FK DRUGS Y Y AIC_CODE

Table Name SALUS.GP

Functional Name

Abbreviation


Object Type Name

Columns


Domain Name

1 FISCAL_CODE P Y CHAR (16) DOM CHAR_0_0_16

2 NAME VARCHAR (128 BYTE) DOM VARCHAR_0_0_128 BYTE

3 LAST_NAME VARCHAR (128 BYTE) DOM VARCHAR_0_0_128 BYTE


Columns Comments


1 FISCAL_CODE It is the Italian ID (Unique Identifier) of the GP/MDoctor.

Indexes

FP7-287800 SALUS



Order

GP_PK PK FISCAL_CODE ASC



HAS_GP_GP_FK HAS_GP Y Y FISCAL_CODE

Table Name SALUS.HAS_GP

Functional Name

Abbreviation


Object Type Name

Columns


Domain Name

1 START_DATE P Y Date DOM Date_0_0_0


3 PATIENT_ID P F Y VARCHAR (255) DOM VARCHAR_0_0_255

4 FISCAL_CODE P F Y CHAR (16) DOM CHAR_0_0_16


Columns Comments


1 START_DATE GP starts the care of the patient

2 END_DATE GP terminates the care for that Patient

4 FISCAL_CODE

ISSUE: In some cases (start_date - end_datethis value can be null)

Indexes


Order

HAS_GP_PK PK FISCAL_CODE ASC

PATIENT_ID ASC

FP7-287800 SALUS



Order

START_DATE ASC



HAS_GP_GP_FK GP Y Y FISCAL_CODE

HAS_GP_PATIENT_FK PATIENT Y Y PATIENT_ID

Table Name SALUS.HOSPITALIZATION

Functional Name

Abbreviation


Object Type Name

Columns


Domain Name



3 PRIMARY_DIAGNOSIS_CODE_ICD9CM Y CHAR (10) DOM CHAR_0_0_10

4 PRIMARY_DIAGNOSIS_DESC_ICD9CM Y VARCHAR (128) DOM VARCHAR_0_0_128

5 HOSPITALIZATION_DATE Y Date DOM Date_0_0_0

6 DATE_OF_EVENT Date DOM Date_0_0_0

7 DISCHARGE_DAY Date DOM Date_0_0_0

8 DIAGNOSIS_CODE1_ICD9CM CHAR (10) DOM CHAR_0_0_10

9 DIAGNOSIS_DESC1_ICD9CM VARCHAR (128) DOM VARCHAR_0_0_128






FP7-287800 SALUS



Domain Name




18 PRIMARY_INTERV_CODE_ICD9CM CHAR (10) DOM CHAR_0_0_10

19 PRIMARY_INTERV_DESC_ICD9CM VARCHAR (128) DOM VARCHAR_0_0_128

20 INTERV1_CODE_ICD9CM CHAR (10) DOM CHAR_0_0_10





25 INTERV1_DESC_ICD9CM VARCHAR (128) DOM VARCHAR_0_0_128





30 DRG_CODE Y CHAR (10 BYTE) DOM CHAR_0_0_10 BYTE

31 DRG_DESC Y VARCHAR (128 BYTE) DOM VARCHAR_0_0_128 BYTE

32 COMPLICATION_DIAG_CODE_ICD9CM CHAR (10) DOM CHAR_0_0_10

33 COMPLICATION_DIAG_DESC_ICD9CM VARCHAR (128) DOM VARCHAR_0_0_128

34 MDC_CODE CHAR (10 BYTE) DOM CHAR_0_0_10 BYTE

35 MDC_DESC VARCHAR (128 BYTE) DOM VARCHAR_0_0_128 BYTE

36 TREATMENT_REPEATED_ID CHAR (1 BYTE) DOM CHAR_0_0_1 BYTE

37 TREATMENT_REPEATED_DESC VARCHAR (128 BYTE) DOM VARCHAR_0_0_128 BYTE

38 MORTALITY_FLAG CHAR (1 BYTE) DOM CHAR_0_0_1 BYTE


Columns Comments


FP7-287800 SALUS



3 PRIMARY_DIAGNOSIS_CODE_ICD9CM DWH=SDO.DIAGP_ID

4 PRIMARY_DIAGNOSIS_DESC_ICD9CM DWH=SDO.DIAGP_DESC

5 HOSPITALIZATION_DATE DWH=SDO.DATA_RICOVERO

6 DATE_OF_EVENT DWH=SDO.DATA_EVENTO_INDICE In some cases it can be NULL

In some cases it can be NULL

7 DISCHARGE_DAY DWH=SDO.DATA_DIMISSIONE

8 DIAGNOSIS_CODE1_ICD9CM DWH=SDO.DIAG1_ID

9 DIAGNOSIS_DESC1_ICD9CM DWH=SDO.DIAG1_DESC Language: Italian

Language: Italian



Language: Italian



Language: Italian



Language: Italian



Language: Italian

18 PRIMARY_INTERV_CODE_ICD9CM DWH=SDO.INTP_ID

19 PRIMARY_INTERV_DESC_ICD9CM DWH=SDO.INTP_DESC Language: Italian

Language: Italian

20 INTERV1_CODE_ICD9CM DWH=SDO.INT1_ID





25 INTERV1_DESC_ICD9CM DWH=SDO.INT1_DESC Language: Italian

Language: Italian


Language: Italian

FP7-287800 SALUS




Language: Italian


Language: Italian


Language: Italian

30 DRG_CODE DWH=SDO.DRG_ID

31 DRG_DESC DWH=SDO.DRG_DESC Language: Italian

Language: Italian

32 COMPLICATION_DIAG_CODE_ICD9CM DWH=SDO.DIAG_COMPLICANZA_ID

33 COMPLICATION_DIAG_DESC_ICD9CM DWH=SDO.DIAG_COMPLICANZA_DESC Language: Italian

Language: Italian

34 MDC_CODE DWH=SDO.MDC_ID

35 MDC_DESC DWH=SDO.MDC_DESC Language: Italian

Language: Italian

36 TREATMENT_REPEATED_ID DWH=SDO.RIC_RIP_T_ID It is a code (A,B, C...) which describe if the treatment has been repeated. ISSUE: Identify an International Standard Code

It is a code (A,B, C...) which describe if the treatment has been repeated. ISSUE: Identify an International Standard Code

37 TREATMENT_REPEATED_DESC DWH=SDO.RIC_RIP_T_DESC Language: Italian

Language: Italian

38 MORTALITY_FLAG

DWH=SDO.MORTALITA_30GG_F_ID Flag that identifies hospitalization with mortality at 30 days. Takes value 1 if between the date of discharge from a shelter structure and the death of the same assisted spends a time interval less than or equal to thirty days, 0 otherwise. This indicato

Indexes


Order

HOSPITALIZATION_PK PK ID ASC

HOSPITALIZATION__IDXv1 ID ASC

PATIENT_ID ASC

PRIMARY_DIAGNOSIS_CODE_ICD9CM ASC

DIAGNOSIS_CODE1_ICD9CM ASC

DIAGNOSIS_CODE2_ICD9CM ASC

PRIMARY_INTERV_CODE_ICD9CM ASC

FP7-287800 SALUS



Order

INTERV1_CODE_ICD9CM ASC

INTERV2_CODE_ICD9CM ASC

COMPLICATION_DIAG_CODE_ICD9CM ASC

MDC_CODE ASC



HOSPITALIZATION_PATIENT_FK PATIENT Y Y PATIENT_ID

Table Name SALUS.PATIENT

Functional Name

Abbreviation


Object Type Name

Columns


Domain Name

1 PATIENT_ID P Y VARCHAR (255) DOM VARCHAR_0_0_255

2 GENDER Y CHAR (1 BYTE) DOM CHAR_0_0_1 BYTE

3 DATE_OF_BIRTH Y Date DOM Date_0_0_0

4 AGE Y Integer DOM Integer_0_0_0

5 DATE_OF_DEATH Date DOM Date_0_0_0

6 AUTOPSY_DONE CHAR (1 BYTE) DOM CHAR_0_0_1 BYTE

7 PROVIDER_ORGANIZATION_ID Y VARCHAR (30 BYTE) DOM VARCHAR_0_0_30 BYTE

8 PATIENT_REGISTRATION_DATE Date LT

9 PATIENT_DEREGISTRATION_DATE Date LT


Columns Comments

FP7-287800 SALUS



1 PATIENT_ID SALUS Pseudo Code

2 GENDER M=Male; F=Female;-=Not Available DWH=AMBULATORY.SESSO;VACCINATION.SESSO;SDO.SESSO;FILEF.SESSO;FARMA.SESSO

3 DATE_OF_BIRTH YYYYMMDD DWH=AMBULATORY.NASC_DATA;VACCINATION.NASC_DATA;SDO.NASC_DATA;FILEF.NASC_DATA;FARMA.NASC_DATA

4 AGE in YEARS DWH=AMBULATORY.ETA_ANNI;VACCINATION.ETA_ANNI;SDO.ETA_ANNI;FILEF.ETA_ANNI;FARMA.ETA_ANNI

5 DATE_OF_DEATH Filled if Dead YYYYMMDD DWH=AMBULATORY.DT_DECESSO;VACCINATION.DT_DECESSO;SDO.DT_DECESSO;FILEF.DT_DECESSO;FARMA.DT_DECESSO

6 AUTOPSY_DONE Y if DWH=SDO. AUTOPSIA_F_ID is present if representative

7 PROVIDER_ORGANIZATION_ID FIXED VALUE to Lombardy OID: 2.16.840.1.113883.2.9.2.30

8 PATIENT_REGISTRATION_DATE It is the registration date of the patient into the Regional Health System

9 PATIENT_DEREGISTRATION_DATE It is the de-registration date of the patient out of the Regional Health System


Indexes


Order

PATIENT_PK PK PATIENT_ID ASC



ALLERGY_PATIENT_FK ALLERGY Y Y PATIENT_ID

AMBULATORY_PATIENT_FK AMBULATORY Y Y PATIENT_ID

CONDITION_PATIENT_FK CONDITION Y Y PATIENT_ID

DRUGS_PATIENT_FK DRUGS Y Y PATIENT_ID

HAS_GP_PATIENT_FK HAS_GP Y Y PATIENT_ID

HOSPITALIZATION_PATIENT_FK HOSPITALIZATION Y Y PATIENT_ID

PATIENT_PREGNANCY_PATIENT_FK PATIENT_PREGNANCY Y Y PATIENT_ID

VACCINATION_PATIENT_FK VACCINATION Y Y PATIENT_ID

FP7-287800 SALUS


Table Name SALUS.PATIENT_PREGNANCY

Functional Name

Abbreviation


Object Type Name

Columns


Domain Name





5 LAST_MESTRUAL_DATE Y Date DOM Date_0_0_0


Columns Comments


1 ID Unique ID generated automatically by Oracle

3 START_DATE Is the Date of the first week of pregnancy ISSUE: the pregnancy Start_Date is an estimation

4 END_DATE Is the Date of the last week of pregnancy. If not evaluated, the Patient is pregnancy at the time of Date_Reference

ISSUE: the pregnancy Start_Date is an estimation

5 LAST_MESTRUAL_DATE ISSUE: it is an estimation (START_DATE)


Indexes


Order

PATIENT_PREGNANCY_PK PK ID ASC



PATIENT_PREGNANCY_PATIENT_FK PATIENT Y Y PATIENT_ID

FP7-287800 SALUS


Table Name SALUS.VACCINATION

Functional Name

Abbreviation


Object Type Name

Columns


Domain Name



3 TREATMENT_DATE Y Date DOM Date_0_0_0

4 VACCINE_CODE Y CHAR (10) DOM CHAR_0_0_10

5 VACCINE_DESC Y VARCHAR (128 BYTE) DOM VARCHAR_0_0_128 BYTE


Columns Comments


3 TREATMENT_DATE YYYYMMDD DWH=VACC.DATA_EROGAZIONE

4 VACCINE_CODE DWH=VACC.VACCINO_ID Map with SNOMED

ISSUE: To Map with Standard/International Code.

5 VACCINE_DESC DWH=VACC.VACCINO_DESC Language: Italian

Language: Italian

Indexes


Order

VACCINATION_PK PK ID ASC



VACCINATION_PATIENT_FK PATIENT Y Y PATIENT_ID

Table 10 - SALUS–LISPA DWH data description

FP7-287800 SALUS


7.3 Mapping of the required data to be provided by LISPA

7.3.1 Condition table

Condition table contains the clinical condition of the patient. In particular this table uses an internal

regional codification which is updated on a yearly basis. A patient can have a maximum of 12

conditions during a year. This table is populated through an algorithm which investigates the clinical

history of the patient.

In the following table an example of mapping conditions in Italian description vs SNOMED

codification is provided.

CONDITION_DESCRIPTION (ITALIAN) CONDITION_DESCRIPTION (ENGLISH)

SOTTOPOSTO A TRAPIANTO Transplantation (procedure)

INSUFFICIENZA RENALE CRONICA Chronicrenalimpairment (disorder)

HIV POSITIVO ED AIDS CONCLAMATO Human immunodeficiency virus infection (disorder)

NEOPLASTICO Neoplasticdisease

DIABETICO Diabeticcomplication (disorder)

CARDIOVASCULOPATICO (TRE SOTTOCATEGORIE) Chronic disease of cardiovascular system (disorder)

BRONCOPNEUMOPATICO Chronic disease of respiratory system (disorder)

GASTROENTEROPATICO (DUE SOTTOCATEGORIE) Chronic digestive system disorder (disorder)

NEUROPATICO (SEI SOTTOCATEGORIE) Disorder of nervoussystem

MALATTIE ENDOCRINE E METABOLICHE (NOVE SOTTOCATEGORIE)

Metabolicdisease (disorder)

AUTOIMMUNE Autoimmune disease (disorder)

Figure 19– Conditions codification example

7.3.2 Vaccination table

This table contains data regarding patient vaccinations. An Italian codification is used at the moment.

A mapping with SNOMED standard codification will be investigated.

7.3.3 Ambulatory table

This table contains data regarding patient visit and intervention in ambulatory setting. A standard

codification of different specialties is not yet identified. A translation of terminology used in RL-

DWH in English language is provided.

Furthermore this table contains data regarding the ambulatory orders which are very similar, in the

Italian process, of drugs prescription and include speciality visits; diagnostic examination, lab exams,

day hospital procedures.

7.3.4 Pregnancy table

This table contains pregnancy status which is indirectly built on the basis of different related data.

7.4 DB update

SALUS-LISPA DWH is updated monthly. The methodology used for update process will be

established on the basis of project contingency needs (total rebuilding or incremental update).

7.5 Metadata

The required metadata to be included in SALUS-LISPA DWH is “Current_date” which is inserted in

all tables and is in Timestamp data format. Other required metadata will be defined in WP4.

FP7-287800 SALUS


7.6 Physical data base

SALUS-LISPA DWH is deployed with a commercial Oracle distribution greater than 10.

LISPA is in charge of this deployment task.

FP7-287800 SALUS


8 STANDARD CODIFICATION USED FOR DATA SOURCE

IN SALUS-LISPA DWH

A summary of international standard codification used in SALUS-LISPA DWH is represented in the

following table.

Coding system What we have What we can provide

ICD9CM

Version 2007 International Code,

Italian Description

ATC

OK International Code,

Italian Description

AIC ssn-minsalute-500001

OK Italian Code

Italian Description

DRG

Version 24 International Code

Italian Description

MDC

Aggregator of DRG

Version 24 International Code

Italian Description

LOMBARDY

Condition Code

Internal codification SNOMED code-english

description or ICD9

Vaccine code

Internal codification SNOMED code-english

description

Amb_order code Internal codification TBD

Specialty Internal codification Italian Code

English Description

Table 11 – Standard codification system used in SALUS-LISPA DWH

FP7-287800 SALUS


9 SYSTEM ACTORS

9.1 Pilot settings: applications

The following table represents who’s responsible of what. Each component to be developed within SALUS project is clearly assigned to responsible partner.

Single components are described in section 4.

Responsibility

Components

LISPA OFFIS SRDC UMC AGFA INSERM ROCHE

[D-1] RL-DWH Data controller

[D-2] SALUS-LISPA DWH Deployment and Data

population

Schema specification

& installation package

[D-3] SALUS DB/repository Deployment Schema specification

& installation package

[D-4] SISS-DB Internal component –

complete control

[W-1] DWH Publisher

Components

Input specifications,

implementation,

packaging and

deployment

Output specifications

[W-2] SALUS-DWH

components

Internal component –

complete control

[L-1] SALUS-SISS

COMPONENTS

Implementation and

deployment

[S-1] LISPA Connector Deployment Specifications,

implementation and

installation package

[S-2] TIDSQS Deployment Specifications,

implementation and


[S-3] SIL

[S-3.1] EHR RDF service Deployment Specifications,

implementation and


FP7-287800 SALUS


[S-3.2] SIL-DS Deployment Specifications,

implementation and


Specifications,

implementation and


[S-3.3] ADE notification

manager

Deployment Specifications,

implementation and


[S-3.4] ICSR Notification

Manager


implementation

and installation

package

[S-4] De-identification

service

Configuration definition,

deployment

Specifications,

implementation and


[S-5] ADE notification tool Deployment Specifications,

implementation and


[S-5.1] ADE GUI Specification for the

integration with the SSO-

SISS, Deployment.

Specifications,

implementation and


[S-6] ICSR Tool Deployment Specifications,

implementation

and installation

package

[S-6.1] ICSR GUI ICSR Local Specification

(AIFA format) and

specification for the

integration with the SSO-

SISS, Deployment

Specifications,

implementation

and installation

package

[S-7] ICSR Report

Generator


implementation

and installation

package

[S-8] TILDS Deployment Specifications,

implementation and


[S-9] SIL II

[S-9.1] Safety Analysis

Query Manager


implementation and


Specifications,

implementation and



Subscription Manager


implementation and

Specifications,

implementation and

FP7-287800 SALUS


installation package installation package

[S-9.3] Converter and

Formatter Services


implementation and


[S-9.4] Query Result

Calculator Service


implementation and


Specifications,

implementation and


[S-10] Temporal Pattern

Association Method


implementation and



Characterization Method]


implementation and


[S-12] Audit Record

Repository & GUI


implementation and


[S-13] Case Series

Characterization Tool

Specifications,

implementation and


Specifications,

implementation and

installation package,

deployment



Specifications,

implementation and


Specifications,

implementation and


deployment


Association Tool

Specifications,

implementation and


Specifications,

implementation and


deployment

[S-16] Patient History Tool Specifications,

implementation and


Specifications,

implementation and


deployment

[S-17] Post Market Safety

Analysis Tool

Specifications,

implementation and


Specificatio

ns,

implementat

ion and

installation

package,

deployment

Table 12 – Pilot settings: applications

FP7-287800 SALUS


9.2 Pilot settings: technologies

The following table contains, for each component, the detail regarding technologies to be used (hardware requirements, operative system, DBMS,

middleware, network settings,…). This information is provided by each responsible partner.

Technology

Components

HW OS DBMS NETW

ORK

WEB

SERVER

TOOLS OTHER

[D-1] RL-DWH OS independent Oracle

[D-2] SALUS-LISPA DWH OS independent Oracle

[D-3] SALUS DB/repository OS independent Oracle

[D-4] SISS-DB OS independent Oracle

[W-1] DWH Publisher

Components

OS independent Oracle Script SQL

[W-2] SALUS-DWH

components

OS independent Oracle Script SQL

[L-1] SALUS-SISS

COMPONENTS

Tomcat Java

[S-1] LISPA Connector Windows/Linux Oracle Java

[S-2] TIDSQS Windows/Linux Java

[S-3] SIL Tomcat 7 Java, EYE Reasoning engine

[S-3.1] EHR RDF service Tomcat 7 Java, EYE Reasoning engine

[S-3.2] SIL-DS Tomcat 7 Java, EYE Reasoning engine

[S-3.3] ADE notification

manager

[S-3.4] ICSR Notification

Manager

Java, EYE Reasoning engine

[S-4] De-identification service Tomcat 7 Java

[S-5] ADE notification tool Java

FP7-287800 SALUS


[S-5.1] ADE GUI Java

[S-6] ICSR Tool 10Gb hard disk,

4Gb ram, 4CPU

OS independent X https Tomcat 7 Java, specific Java libraries—such

as Jena, Tomcat 7, and Jaxb

[S-6.1] ICSR GUI 10Gb hard disk,

4Gb ram, 4CPU

OS independent X https Tomcat 7 Java libraries—JavaServer Face,

Jquery/Javascript, JSP, HTML,

Tomcat 7

[S-7] ICSR Report Generator 10Gb hard disk,

4Gb ram, 4CPU

OS independent X https Tomcat 7 Java, specific Java libraries—such

as Jena, Tomcat 7, and Jaxb

[S-8] TILDS Windows/Linux Java

[S-9] SIL II Tomcat 7 Java, EYE Reasoning engine

[S-9.1] Safety Analysis Query

Manager

Tomcat 7 Java, EYE Reasoning engine


Subscription Manager


[S-9.3] Converter and

Formatter Services

Java, EYE Reasoning engine

[S-9.4] Query Result

Calculator Service



Association Method

Oracle


Characterization Method]

Oracle

[S-12] Audit Record

Repository & GUI

MySQL Tomcat 7 Java

[S-13] Case Series


H2 Tomcat 7 Java, Javascript, HTML 5





Association Tool


[S-16] Patient History Tool H2 Tomcat 7 Java, Javascript, HTML 5

[S-17] Post Market Safety

Analysis Tool


Table 13 – Pilot settings: Technologies

FP7-287800 SALUS


9.3 Pilot running

The following table contains the list of activities needed for pilot running distributed over partners responsibility.

Responsibility

Activities

LISPA OFFIS SRDC UMC AGFA INSERM ROCHE

ADE detection rules validation X + Lombardy region pharmacovig. centre

Query submission

GPs Simulation X + Lombardy region pharmacovig. centre

Query definition and submission

Query validation X + Lombardy region pharmacovig. centre

Query audit process X + Lombardy region pharmacovig. centre

Audit definition

Privacy audit X

Audit X + Lombardy region pharmacovig. centre

On-site maintenance X X X X X

Remote maintenance X X X

Help desk X X X X X X

Table 14 – Pilot running

The deployment process for LISPA pilot consists of several steps to be completed by responsible partners:

1. To send to LISPA the technical sheet provided in Appendix 1 containing all technical details about each SALUS component

2. To prepare installation package and technical documentation

3. To upload the ready-to-install package in project ftp (internal documents project web site)

4. To upload the component technical documentation (installation instructions, manual,…) and the software updates with changes revision list (bug

fixes, adds on)

5. LISPA technical team downloads installation packages from ftp to local management system (Polarion) and arrange installation procedures

FP7-287800 SALUS


6. During pilot phase the responsible partner is on charge of on-site or remote maintenance (together with LISPA technical team) and help desk (contact

person indicated in the provided components technical sheet)

FP7-287800 SALUS


Appendix 1 – Technical sheet for SALUS component

FP7-287800 SALUS


Appendix 2 – Italian form for spontaneous ADR reporting (AIFA

format)

FP7-287800 SALUS


salus - i~hd d8_2_1_lispa_final.pdf · fp7-287800 salus salus-fp7-287800•d8.2.1-lispa pilot -...

Documents