salus - i~hd d8_2_1_lispa_final.pdf · fp7-287800 salus salus-fp7-287800•d8.2.1-lispa pilot -...
TRANSCRIPT
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 1 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 Page 2 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
Comments from SRDC included
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 3 of 83
V2.1 May 14,
2013
Comments from SRDC included
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-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 4 of 83
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
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-
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 5 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 6 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 7 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 8 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 9 of 83
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
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 10 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 11 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 12 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 13 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 14 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 15 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 16 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 17 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 18 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 19 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 20 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 21 of 83
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 OFFIS is responsible for the specification, implementation and installation package.
o Technology required: Java, OS: Windows or Linux.
o LISPA is responsible for the deployment.
[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.
o LISPA is responsible for the deployment.
[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.
o Technology required: Java, EYE Reasoning engine.
o LISPA is responsible for the deployment.
[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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 22 of 83
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.
o Technology required: Java, EYE Reasoning engine.
o LISPA is responsible for the deployment.
[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.
o Technology required: Java, EYE Reasoning engine.
o LISPA is responsible for the deployment.
[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 SRDC is responsible for the specification, implementation and installation package.
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.
o LISPA is responsible for the deployment.
[S-5] ADE Notification Tool
o OFFIS is responsible for the specification, implementation and installation package.
o Technology required: Java.
o LISPA is responsible for the deployment.
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 Technology required: Java.
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
o LISPA is responsible for the deployment.
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 23 of 83
o Technology required: Java, specific Java libraries—such as Jena, Tomcat 7, and Jaxb.
o LISPA is responsible for the deployment.
[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 OFFIS is responsible for the specification, implementation and installation package.
o Technology required: Java, OS: Windows or Linux.
o LISPA is responsible for the deployment.
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
installation package.
o Technology required: Java, EYE Reasoning engine.
o LISPA is responsible for the deployment.
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 AGFA and SRDC are responsible for the specification, implementation and
installation package.
o Technology required: Java, EYE Reasoning engine.
o LISPA is responsible for the deployment.
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 Technology required: Java, EYE Reasoning engine.
o LISPA is responsible for the deployment.
o The clinical data that Converter and Formatter Services deal with is already de-
identified.
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 24 of 83
[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 AGFA and SRDC are responsible for the specification, implementation and
installation package.
o Technology required: Java, EYE Reasoning engine.
o LISPA is responsible for the deployment.
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).
o LISPA is responsible for the deployment.
[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).
o LISPA is responsible for the deployment.
[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 SRDC is responsible for the specification, implementation and installation package.
o Technology required: Java.
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
installation package.
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.
o Technology required: Java, HTML 5.
o UMC is responsible for the Deployment.
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 25 of 83
o The result sets presented will be de-identified.
[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.
o UMC and SRDC is responsible for the specification, implementation and installation
package.
o Technology required: Java, HTML 5.
o UMC is responsible for the Deployment.
o The result sets presented will be de-identified.
[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).
o UMC and SRDC is responsible for the specification, implementation and installation
package.
o Technology required: Java, HTML 5.
o UMC is responsible for the Deployment.
o The result sets presented will be de-identified.
[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
installation package.
o Technology required: Java, HTML 5.
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 26 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 27 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 28 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 29 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 30 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 31 of 83
#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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 32 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 33 of 83
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
Background and Foreground populations
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 34 of 83
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
Background and Foreground populations
List of common medications used after Medication of Interest and the observance rates in
Background and Foreground populations
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 35 of 83
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]
Audit Record Repository.
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 36 of 83
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
#3a_5 AUDITING All communications with Non-Care Zone are audited through [S-12]
Audit Record Repository.
Table 6 - Scenario #2_b and 3_a in LISPA pilot: steps description
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 37 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 38 of 83
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
DWH Zone (Scheda 12)
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 39 of 83
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
DWH Zone (Scheda 12)
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 40 of 83
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.
#4a_6 AUDITING All communications with Non-Care Zone are audited through [S-12]
Audit Record Repository.
Table 7 - Scenario #4_a in LISPA pilot: steps description
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 41 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 42 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 43 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 44 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 45 of 83
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.
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 46 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 47 of 83
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)
x (Year of Birth is Adequate)
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 48 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 49 of 83
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 Encounter 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)
Related Encounter 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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 50 of 83
Quantity x (o)
Days Supply x (o)
Related Encounter 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 Encounter x (o)
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 51 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 52 of 83
Figure 18 – SALUS-LISPA DWH: Entity Relationship Diagram
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 53 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 54 of 83
No Column Name Description Notes
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
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 START_DATE Y Date DOM Date_0_0_0
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 55 of 83
No Column Name PK FK M Data Type DT kind
Domain Name
12 FLAG_LAB_EXAM_AMB Y CHAR (1 BYTE) DOM CHAR_0_0_1 BYTE
13 CURRENT_DATE Y Timestamp (6) DOM Timestamp_6_0_0
Columns Comments
No Column Name Description Notes
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
Index Name State Functional Spatial Expression Column Name Sort
Order
AMBULATORY_PK PK ID ASC
AMBULATORY__IDXv1 ID ASC
PATIENT_ID ASC
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 56 of 83
Index Name State Functional Spatial Expression Column Name Sort
Order
DIAGNOSIS_CODE_ICD9CM ASC
FLAG_LAB_EXAM_AMB ASC
Foreign Keys (referring to)
Name Referring To Mandatory Transferable In Arc Column Name
AMBULATORY_PATIENT_FK PATIENT Y Y PATIENT_ID
Table Name SALUS.CONDITION
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 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
7 START_DATE Y Date DOM Date_0_0_0
8 END_DATE Date DOM Date_0_0_0
9 CURRENT_DATE Y Timestamp (6) DOM Timestamp_6_0_0
10 Column_9 DOM
Columns Comments
No Column Name Description Notes
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 57 of 83
No Column Name Description Notes
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
Index Name State Functional Spatial Expression Column Name Sort
Order
CONDITION_PK PK ID ASC
Foreign Keys (referring to)
Name Referring To Mandatory Transferable In Arc Column Name
CONDITION_PATIENT_FK PATIENT Y Y PATIENT_ID
Table Name SALUS.DRUGS
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 DELIVERY_DATE Y Date DOM Date_0_0_0
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 58 of 83
No Column Name PK FK M Data Type DT kind
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
12 CURRENT_DATE Y Timestamp (6) DOM Timestamp_6_0_0
Columns Comments
No Column Name Description Notes
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 59 of 83
Index Name State Functional Spatial Expression Column Name Sort
Order
DRUGS_PK PK ID ASC
Foreign Keys (referring to)
Name Referring To Mandatory Transferable In Arc Column Name
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
Classification Type Name
Object Type Name
Columns
No Column Name PK FK M Data Type DT kind
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 60 of 83
No Column Name PK FK M Data Type DT kind
Domain Name
15 COMPANY_DESC Y VARCHAR (1000 BYTE) DOM VARCHAR_0_0_1000 BYTE
16 CURRENT_DATE Timestamp (6) LT
Columns Comments
No Column Name Description Notes
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 61 of 83
No Column Name Description Notes
14 COMPANY_CODE LISPA CODING DATA
15 COMPANY_DESC LISPA CODING DATA
Indexes
Index Name State Functional Spatial Expression Column Name Sort
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
Classification Type Name
Object Type Name
Columns
No Column Name PK FK M Data Type DT kind
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
4 CURRENT_DATE Timestamp (6) LT
Columns Comments
No Column Name Description Notes
1 FISCAL_CODE It is the Italian ID (Unique Identifier) of the GP/MDoctor.
Indexes
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 62 of 83
Index Name State Functional Spatial Expression Column Name Sort
Order
GP_PK PK FISCAL_CODE ASC
Foreign Keys (referred from)
Name Referred From Mandatory Transferable In Arc Column Name
HAS_GP_GP_FK HAS_GP Y Y FISCAL_CODE
Table Name SALUS.HAS_GP
Functional Name
Abbreviation
Classification Type Name
Object Type Name
Columns
No Column Name PK FK M Data Type DT kind
Domain Name
1 START_DATE P Y Date DOM Date_0_0_0
2 END_DATE 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
5 CURRENT_DATE Timestamp (6) LT
Columns Comments
No Column Name Description Notes
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
Index Name State Functional Spatial Expression Column Name Sort
Order
HAS_GP_PK PK FISCAL_CODE ASC
PATIENT_ID ASC
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 63 of 83
Index Name State Functional Spatial Expression Column Name Sort
Order
START_DATE ASC
Foreign Keys (referring to)
Name Referring To Mandatory Transferable In Arc Column Name
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
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 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
10 DIAGNOSIS_CODE2_ICD9CM CHAR (10) DOM CHAR_0_0_10
11 DIAGNOSIS_DESC2_ICD9CM VARCHAR (128) DOM VARCHAR_0_0_128
12 DIAGNOSIS_CODE3_ICD9CM CHAR (10) DOM CHAR_0_0_10
13 DIAGNOSIS_DESC3_ICD9CM VARCHAR (128) DOM VARCHAR_0_0_128
14 DIAGNOSIS_CODE4_ICD9CM CHAR (10) DOM CHAR_0_0_10
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 64 of 83
No Column Name PK FK M Data Type DT kind
Domain Name
15 DIAGNOSIS_DESC4_ICD9CM VARCHAR (128) DOM VARCHAR_0_0_128
16 DIAGNOSIS_CODE5_ICD9CM CHAR (10) DOM CHAR_0_0_10
17 DIAGNOSIS_DESC5_ICD9CM VARCHAR (128) DOM VARCHAR_0_0_128
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
21 INTERV2_CODE_ICD9CM CHAR (10) DOM CHAR_0_0_10
22 INTERV3_CODE_ICD9CM CHAR (10) DOM CHAR_0_0_10
23 INTERV4_CODE_ICD9CM CHAR (10) DOM CHAR_0_0_10
24 INTERV5_CODE_ICD9CM CHAR (10) DOM CHAR_0_0_10
25 INTERV1_DESC_ICD9CM VARCHAR (128) DOM VARCHAR_0_0_128
26 INTERV2_DESC_ICD9CM VARCHAR (128) DOM VARCHAR_0_0_128
27 INTERV3_DESC_ICD9CM VARCHAR (128) DOM VARCHAR_0_0_128
28 INTERV4_DESC_ICD9CM VARCHAR (128) DOM VARCHAR_0_0_128
29 INTERV5_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
39 CURRENT_DATE Y Timestamp (6) DOM Timestamp_6_0_0
Columns Comments
No Column Name Description Notes
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 65 of 83
No Column Name Description Notes
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
10 DIAGNOSIS_CODE2_ICD9CM DWH=SDO.DIAG2_ID
11 DIAGNOSIS_DESC2_ICD9CM DWH=SDO.DIAG2_DESC Language: Italian
Language: Italian
12 DIAGNOSIS_CODE3_ICD9CM DWH=SDO.DIAG3_ID
13 DIAGNOSIS_DESC3_ICD9CM DWH=SDO.DIAG3_DESC Language: Italian
Language: Italian
14 DIAGNOSIS_CODE4_ICD9CM DWH=SDO.DIAG4_ID
15 DIAGNOSIS_DESC4_ICD9CM DWH=SDO.DIAG4_DESC Language: Italian
Language: Italian
16 DIAGNOSIS_CODE5_ICD9CM DWH=SDO.DIAG5_ID
17 DIAGNOSIS_DESC5_ICD9CM DWH=SDO.DIAG5_DESC 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
21 INTERV2_CODE_ICD9CM DWH=SDO.INT2_ID
22 INTERV3_CODE_ICD9CM DWH=SDO.INT3_ID
23 INTERV4_CODE_ICD9CM DWH=SDO.INT4_ID
24 INTERV5_CODE_ICD9CM DWH=SDO.INT5_ID
25 INTERV1_DESC_ICD9CM DWH=SDO.INT1_DESC Language: Italian
Language: Italian
26 INTERV2_DESC_ICD9CM DWH=SDO.INT2_DESC Language: Italian
Language: Italian
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 66 of 83
No Column Name Description Notes
27 INTERV3_DESC_ICD9CM DWH=SDO.INT3_DESC Language: Italian
Language: Italian
28 INTERV4_DESC_ICD9CM DWH=SDO.INT4_DESC Language: Italian
Language: Italian
29 INTERV5_DESC_ICD9CM DWH=SDO.INT5_DESC 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
Index Name State Functional Spatial Expression Column Name Sort
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 67 of 83
Index Name State Functional Spatial Expression Column Name Sort
Order
INTERV1_CODE_ICD9CM ASC
INTERV2_CODE_ICD9CM ASC
COMPLICATION_DIAG_CODE_ICD9CM ASC
MDC_CODE ASC
Foreign Keys (referring to)
Name Referring To Mandatory Transferable In Arc Column Name
HOSPITALIZATION_PATIENT_FK PATIENT Y Y PATIENT_ID
Table Name SALUS.PATIENT
Functional Name
Abbreviation
Classification Type Name
Object Type Name
Columns
No Column Name PK FK M Data Type DT kind
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
10 CURRENT_DATE Y Timestamp (6) DOM Timestamp_6_0_0
Columns Comments
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 68 of 83
No Column Name Description Notes
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
10 CURRENT_DATE TimeStamp of Record Insert / Update
Indexes
Index Name State Functional Spatial Expression Column Name Sort
Order
PATIENT_PK PK PATIENT_ID ASC
Foreign Keys (referred from)
Name Referred From Mandatory Transferable In Arc Column Name
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 69 of 83
Table Name SALUS.PATIENT_PREGNANCY
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 START_DATE Y Date DOM Date_0_0_0
4 END_DATE Date DOM Date_0_0_0
5 LAST_MESTRUAL_DATE Y Date DOM Date_0_0_0
6 CURRENT_DATE Y Timestamp (6) DOM Timestamp_6_0_0
Columns Comments
No Column Name Description Notes
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)
6 CURRENT_DATE TimeStamp of Record Insert / Update
Indexes
Index Name State Functional Spatial Expression Column Name Sort
Order
PATIENT_PREGNANCY_PK PK ID ASC
Foreign Keys (referring to)
Name Referring To Mandatory Transferable In Arc Column Name
PATIENT_PREGNANCY_PATIENT_FK PATIENT Y Y PATIENT_ID
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 70 of 83
Table Name SALUS.VACCINATION
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 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
6 CURRENT_DATE Y Timestamp (6) DOM Timestamp_6_0_0
Columns Comments
No Column Name Description Notes
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
Index Name State Functional Spatial Expression Column Name Sort
Order
VACCINATION_PK PK ID ASC
Foreign Keys (referring to)
Name Referring To Mandatory Transferable In Arc Column Name
VACCINATION_PATIENT_FK PATIENT Y Y PATIENT_ID
Table 10 - SALUS–LISPA DWH data description
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 71 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 72 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 73 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 74 of 83
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
installation package
[S-3] SIL
[S-3.1] EHR RDF service Deployment Specifications,
implementation and
installation package
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 75 of 83
[S-3.2] SIL-DS Deployment Specifications,
implementation and
installation package
Specifications,
implementation and
installation package
[S-3.3] ADE notification
manager
Deployment Specifications,
implementation and
installation package
[S-3.4] ICSR Notification
Manager
Deployment Specifications,
implementation
and installation
package
[S-4] De-identification
service
Configuration definition,
deployment
Specifications,
implementation and
installation package
[S-5] ADE notification tool Deployment Specifications,
implementation and
installation package
[S-5.1] ADE GUI Specification for the
integration with the SSO-
SISS, Deployment.
Specifications,
implementation and
installation package
[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
Deployment Specifications,
implementation
and installation
package
[S-8] TILDS Deployment Specifications,
implementation and
installation package
[S-9] SIL II
[S-9.1] Safety Analysis
Query Manager
Deployment Specifications,
implementation and
installation package
Specifications,
implementation and
installation package
[S-9.2] Safety Analysis
Subscription Manager
Deployment Specifications,
implementation and
Specifications,
implementation and
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 76 of 83
installation package installation package
[S-9.3] Converter and
Formatter Services
Deployment Specifications,
implementation and
installation package
[S-9.4] Query Result
Calculator Service
Deployment Specifications,
implementation and
installation package
Specifications,
implementation and
installation package
[S-10] Temporal Pattern
Association Method
Deployment Specifications,
implementation and
installation package
[S-11] Temporal Pattern
Characterization Method]
Deployment Specifications,
implementation and
installation package
[S-12] Audit Record
Repository & GUI
Deployment Specifications,
implementation and
installation package
[S-13] Case Series
Characterization Tool
Specifications,
implementation and
installation package
Specifications,
implementation and
installation package,
deployment
[S-14] Temporal Pattern
Characterization Tool
Specifications,
implementation and
installation package
Specifications,
implementation and
installation package,
deployment
[S-15] Temporal Pattern
Association Tool
Specifications,
implementation and
installation package
Specifications,
implementation and
installation package,
deployment
[S-16] Patient History Tool Specifications,
implementation and
installation package
Specifications,
implementation and
installation package,
deployment
[S-17] Post Market Safety
Analysis Tool
Specifications,
implementation and
installation package
Specificatio
ns,
implementat
ion and
installation
package,
deployment
Table 12 – Pilot settings: applications
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 77 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 78 of 83
[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
[S-9.2] Safety Analysis
Subscription Manager
Tomcat 7 Java, EYE Reasoning engine
[S-9.3] Converter and
Formatter Services
Java, EYE Reasoning engine
[S-9.4] Query Result
Calculator Service
Tomcat 7 Java, EYE Reasoning engine
[S-10] Temporal Pattern
Association Method
Oracle
[S-11] Temporal Pattern
Characterization Method]
Oracle
[S-12] Audit Record
Repository & GUI
MySQL Tomcat 7 Java
[S-13] Case Series
Characterization Tool
H2 Tomcat 7 Java, Javascript, HTML 5
[S-14] Temporal Pattern
Characterization Tool
H2 Tomcat 7 Java, Javascript, HTML 5
[S-15] Temporal Pattern
Association Tool
H2 Tomcat 7 Java, Javascript, HTML 5
[S-16] Patient History Tool H2 Tomcat 7 Java, Javascript, HTML 5
[S-17] Post Market Safety
Analysis Tool
H2 Tomcat 7 Java, Javascript, HTML 5
Table 13 – Pilot settings: Technologies
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 79 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 80 of 83
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
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 81 of 83
Appendix 1 – Technical sheet for SALUS component
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 82 of 83
Appendix 2 – Italian form for spontaneous ADR reporting (AIFA
format)
FP7-287800 SALUS
SALUS-FP7-287800•D8.2.1-LISPA Pilot - Version 3.0 - May 28, 2013 Page 83 of 83