Data Warehouse design and methodology for the 

French Health Department

Didier NAKACHE *  **

datamining@wanadoo.fr

* CEDRIC / CNAM, 292 Rue Saint Martin, 75003 Paris, France 
** CRAMIF, 17/19 rue de Flandres, 75141 Paris cedex 03, France

Abstract.     

This paper reports on a Data Warehouse application. The French national health 
department has to face numerous problems: financial, medical, social, accounts, 
public health and political. Thus, an efficient tool is needed for managing the 
decision   support   information   system.   In   this   context   we   have   proposed   the 
ERASME / SNIIR­AM Data Warehouse project. As far as our knowledge, it has 
been   considered   as   the   biggest   Data   Warehouse   in   the   world.   The   main 
challenge we had to solve were due to huge volumes. We have chosen to solve it 
by   an   ad   hoc   methodology   mainly   based   on   datamart   design.    

KEYWORDS: Datawarehouse, decision support systems, datamart, data bases, 
datamining, Health Service, health.

1. Introduction

This paper reports on a datawarehouse application for the French National  Health 
Department. The actual political and economic context wants this department to (i) 
report on his activity, (ii) control its expenses with the balance as an objective.

However this department is responsible for a considerable amount of information, 
and has to face to many problems: availability and quality of the data, heterogeneous 
 Data Warehouse design and methodology for the  French Health Department      2

data  sources,   frequent  updates,  different  way  for  computing  the  same  information 
according to different points of views. 

The consideration of these elements led to the ERASME datawarehousing project. 
The ERASME project covers all French social security regimes, in other words the 
entire population (58 million). According to experts ­ and as far as our knowledge ­ it 
has been considered as "the biggest datawarehouse in the world ". 

The purpose of this paper is to report on this experience. Section 2 presents the 
problems   and   the   objectives   of   the   application.   Section   3   shows   its   technical 
framework:   architecture,   prototype   and   costs.   In   section   4   is   developed   the 
methodology   we  used   to  design  the  datamarts   in  order   to  solve  problem  of   huge 
amount   of   data.   Finally   section   5   is   turned   to   data   analysis:   some   examples   and 
results.

2. Problems and objective of the decision support system

Problems are numerous but can be summed up in one sentence: how can the Health 
Service be improved? This question covers several aspects:

- Accounts: How can we be sure that Health Service spending is efficiently 
monitored?
- Political:   How   can   we   legislate?   What   costs   would   be   incurred   by 
introducing new measures? How can we supply opposable and shareable data 
to partners?
- Financial: how can we improve healthcare at less cost?
- Public health: do we have good healthcare? 
To understand more clearly what’s at stake a 1% error represents 1 billion Euros.

2.1 Example of problems

The   problems   treated   by   the   Health   Service   are   particularly   complex.   Take   the 
example of pathology and medicine and try to reply to a simple question: how can we 
treat ‘X’ (e.g.: the flu) in France in 2003? First is the problem of coding: is the illness 
identified? Is it possible to reach the diagnosis using a different code? Are the acts 
 Data Warehouse design and methodology for the  French Health Department      3

coded in such a way that they can be analyzed? Does the corresponding governmental 
body authorize a statistical treatment?

Even if we could manage to answer these questions, we would be then confronted 
to a second problem: Health Service is mainly interested in what is covered and what 
is reimbursed (purely financial) rather than what is really spend for health. Many 
players (chemists, social security agents, practitioners, health insurance contributors) 
do   not   believe   it   is   useful   to   record   information   where   reimbursements   are   not 
involved. A Sickness Note covering less than three days is not reimbursed (obligatory 
waiting period). The Social Security is not always notified if an individual comes to 
an arrangement with his company.

Turning   now   to   the   question   of   what   chemist   provides:   there   is   often   a   big 
difference between what is written on the prescription and what chemist actually gives 
the patient as he is authorized to substitute one medicine with another if it is cheaper 
(generic drug). This means that for two different prescriptions the chemist can hand 
out   exactly   the   same   medicine.   If   these   two   obstacles   are   removed,   how   can   we 
compare two prescriptions? About 15,000 medicines exist in France: many of which 
appear in different forms, have many variants, the packaging is different or they are 
not administered in the same way. Classification systems exist (ATC, EPHMRA, etc.) 
but the drugs are generally filed by either their chemical or anatomic principal active 
ingredient, and for example none of these helps to directly identify the antibiotic! 

It should also be added that no one way exists to identify an individual. If we take 
the example of a young woman who is either at her parent's charge or a student: she is 
entitled to healthcare cover as her parents child or in her own right as a student. She 
gets married and may become her husband’s responsibility therefore changing her 
number and also her social security regime if she was a student. She then finds work 
and finally obtains her own number in her own right. Precarious situations mean many 
changes. However, if she  is  made  redundant she  can  reverts  back to being at her 
husband’s charge. 

Doctors are identified by one number made up of the department and a number 
attributed to them by the Medical Practice Council: a doctor who changes department 
changes his number! 

  How   can   we   analyze   the   request   of   someone   who   submits   his   claim   for 
reimbursement   for   the   chemist   one   year   later   when   the   laboratory   tests   were 
reimbursed very early on (direct payment for example)? 
 Data Warehouse design and methodology for the  French Health Department      4

Finally, how can we address the problem of errors (typing mostly), which lead to 
extra/duplicate reimbursements: the accountant would like to manage the cash flow; 
the analyst would like to manage the cost. 

How   do   we   evaluate   the   quality   of   treatment   given?   The   economic   factor   is 
certainly important but is it sufficient? Other criteria like secondary effects, the length 
of the illness (with or without work stoppage), the risk of it happening again, the 
degree of suffering … all these are equally important factors difficult to quantify.

Objectives

The system has many objectives at local, regional and national level : to carry­out 
operations and analyses under the scope of cost and internal control, to put into place 
research and analyses to improve spending awareness (evolution and internal control), 
as well as the application of sanitary studies and research mentioned in the objectives 
and management agreement made between the National Health Service and the State, 
to publish official information, adapted to each category of recipient. 

3 –General Architecture of the application

The   database   is   centralized   with   only   one   interface   supplying   the   information 
judged useful to the national datawarehouse. The basic information is gathered from 
the computer centers, local insurance companies and other parts of the health service. 
Data are received every day and controls are carried out at the highest level before 
payment   wherever   possible.   They   are   included   in   the   national   datawarehouse, 

CONTROL AND RECYCLING

External Production Local insurance Other

information (internal) companies regimes

CONTROL AND RECYCLING

NATIONAL
1 national
DATAWAREHOUSE datawarehouse

Datamarts

REGIONAL REGIONAL REGIONAL REGIONAL REGIONAL

DATAWAREHOUSE DATAWAREHOUSE DATAWAREHOUSE DARAWAREHOUSE DATAWAREHOUSE

12 regional datawarehouses
 Data Warehouse design and methodology for the  French Health Department      5

datamarts,   and   loaded   to   12   regional   decisional   databases   with   the   same 

configuration. 
Fig. 1.  General Architecture of the 13 data warehouses

Volume and prototyping

The information for twenty months represents about 100 terabytes. When the project 
was initiated by the Health Minister in 1997 no DBMS could store such a volume. 
Therefore a prototype was necessary in order to validate the technical choices. It has 
been   build   with   the   following   configuration :   a   SUN   E 10 000   computer   with   18 
processors at 336 Mhz, 12 gigabytes of RAM and 2,5 terabytes of disk space (386 
disks of 9 Go ­ RAID 5 technology). For administration purposes, 2 workstations (128 
MB of RAM and a hard disk of 4,4 Go) and finally, for the software, Oracle 8i and 
UNIX.   The   prototype   acted   as   a   benchmark   (3   months)   to   choose   the   tools   for 
extraction, loading, requesting information, datamining and reporting.

Cost
The global cost of the project is 43 million Euros (human cost not included) for an 
estimated workload of about 200 man years. The total estimated return on investment 
at 5 years is about 750 million euros.

4 – The Design Methodology

When the project began (in 1997), not any design methodology had penetrated the 
industrial sector in France, but it has been the subject of various research projects 
([Inmon 96], [Kimball 1997], [Kimball 1998], [Cabibbo and Torlone 1998], [Golfarelli 
and Rizzi 1998], [Golfarelli 1999], [Moodu and Kortnk  2000] [Giovinazzo 2000], 
[Akoka et al. 2001]). An interesting state of the art can be found in [Laender 2002]).

The ERASME datawarehouse was built according to a methodology very close to 
X­META [Carneiro 2002] who proposes an implementation by successive iterations, 
according to principles of Boehm’s spiral (management of the risk) associated with 
RAD techniques, in particular: prototyping, architecture, metadata, tools, pilot project, 
then   datamarts   and   datawarehouse.   This   method   is   interesting   in   the   field   of   the 
project control, but lack of methodology for an optimization of the datamart's contains 
in order to increase performances.
 Data Warehouse design and methodology for the  French Health Department      6

4.1 Related works

Some   global   approaches   for   datawarehouse   design   have   been   proposed.   Kimball 
[Kimball   1998]   [Kimball   1997],   describes   a   complete   framework   for   applying 
dimensional modeling,  called Business Dimensional Lifecycle. The author suggest 
interviews and facilitated sessions as the basic techniques for this step. The difficulty 
of identifying dimensions is also addressed by Kimball in [Kimball 2000].  Pereira 
[Pereira 2000] presents a global methodology for development of Datawarehouse pilot 
projects, successfully tested in a military datawarehouse project.

Some  approaches are more traditional: Senman proposes a design process near 
from   traditional   database   design   process   [Semann   2000].   Agrawal   and   Cabibbo 
[Agrawal   1997]   [Cabibbo   1998]   think   that   at   least   a   conceptual   or   logical   model 
should precede the implementation  of a data warehouse. Lambert  [Lambert  1995] 
propose to get user more involved. The project and method X­META [Carneiro 2002] 
is successfully based on this idea. 

A promising approach for multidimensional design consists in starting from OO, 
UML or ER conceptual schemas. Kripperndorf and Song [Krippendorf 1997] address 
the problem of mapping an ER schema into a star schema, and Song et al. [Song 
2001]   analyze   many­to­many  relationships  between   fact  and   dimension  tables.   An 
extension of the ER model for capturing the dimensional paradigm is presented in 
[Sapia   1998].  Moody   [Moody   2000]   explored   the   techniques   for   deriving   the 
multidimensional models from traditional entity relationship schemas and relational 
data   bases.   Akoka   [Akoka   et   Al.   2001]   proposes   an   approach,   which   consists   in 
designing datawarehouse, dimension hierarchies and datamarts from UML schemes. 
The dimensional fact model, proposed by Golfarelli et al. [Golfarelli 1998], provides a 
graphical notation for representing data warehouses based on the dimensional model. 
The mapping of ER schemas into this model is discussed in [Golfarelli et Al.1998]. In 
1999, he describes the design of data warehouses according to the dimensional fact 
model [Golfarelli 1999]. Phipps and Davis [Phipps 2002] propose a method to design 
a datawarehouse starting from an entity relation model in five steps: (i) Find entities 
with numeric fields and create a fact node for each entity identified, create numeric 
attributes of each fact node, (ii) based on numeric fields in the entities, (iii) create date 
and or time levels (dimensions) with any date/time type fields per fact node, (iv) 
create a level (dimension) containing the remaining entity attributes (non­numeric, 
non­key, and non date fields), and finally (v) recursively examine the relationships of 
 Data Warehouse design and methodology for the  French Health Department      7

the   entities   to   add   additional   levels   in   a   hierarchical   manner.   Some   other 

methodologies   approaches   are   object­oriented   based   [Firestone   1998]   [Giovinazzo 
2000] and [Trujillo 2001]. Many of oriented object approaches emphasize the user 
involvement on early stages of requirements analyzes. These approaches don’t hold 
enough account of the problems of optimization of important volumes. 

Few researchers focused on complex problems and optimization of volumes. Rizzi 
more specifically considered the optimization of volumes and indexes in a constrained 
space [Rizzi 2002]. To this end, he created a model based on a calculation of costs to 
optimize the creation of index for a given global space constraint. Rokia Missaoui 
[Missaoui 2000] focuses on recent developments in representational and processing 
aspects of complex data­intensive applications.

Others are proposing tools. Laender [Laender 2002] created a tool (MD­2) based 
on the dimensional data modeling approach, which facilitates the user participation in 
the development of a data warehouse application. MD2 assists users on identifying 
their   analytical   requirements   in   order   to   help   data   warehouse   designers   to   better 
specify business requirements and translate them into appropriate design elements. 
This   approach   is   strongly   centered   on   the   metadata   repository   used   to   build   the 
dimensional   schema   and   to   specify   reports   that   can   be   generated   from   the   data 
warehouse and visualized through a Web interface. 

4.2 Toward a methodology devoted to huge volumes

The   initial   problem   was   the   following   one:   1   billion   invoices   a   year   represent 
approximately 5 to 10 billion records a year. They correspond to prescriptions made 
by about 250.000 practitioners for 60 million potential patients, allowing them to care 
50.000 diseases. By multiplying these data by the number of years of history (to be in 
accordance with the French legislation which allows be paid off during two years and 
three months), it represents a very important volume of data.

If we wish to exploit the data directly from the datawarehouse (which contains all 
the detailed information), any request would ask for dozens hours of process. Every 
month, about 400 heavy requests have to run, to which you have to add the studies and 
punctual analyses. The time for answer would not be compatible with needs and the 
processing   of   one   month   would   need   more   than   a   month   of   delay.   It   was   thus 
necessary to find a solution which allows to cover the requirements by by­passing 
problem of volume. 
 Data Warehouse design and methodology for the  French Health Department      8

Remark   1:   A   traditional   approach   by   trade   datamart   would   have   given   no 

satisfactory result because 80 % of requirements use common data (access to the data 
of benefits, practitioners, establishments, and patients). 

Remark 2: The snowflake model is used to be an alternative to the star schema for 
dealing with big amount of data. However, in our application, problems of volume are 
located  on the facts table  rather than  on the  dimension  tables. So  this  can't be a 
solution to our problem.

Thus we have proposed our own methodology.  Our approach consists in designing 
several   datamarts   with   common   axes   but   different   optimized   aggregations.   This 
technique also favored the management of the rights and the security. For example, 
the data relative to the pathologies are very sensitive and confidential while the data 
for   geographic   sanitary   card   are   accessible   to   all,   including   persons   outside   the 
institution. The question then became: how to organize in best aggregated data and 
detailed   data   to   answer   all   these   imperatives   (functional   requirements,   security, 
volumes and time for answer). The solution consisted in breaking the problem in 
roughly fragments (datamarts of first level) and in breaking each fragment in 
smaller fragments (datamarts of second level). The method considers the crossings 
of axes; it consists in determining for each request the entities (or multidimensional 
axes) concerned, without worrying about data (attributes). Main axes extracted from 
the analysis are: practitioners, benefits, beneficiaries, establishments and structures, 
pathologies… To determine the datamarts of first level, it was necessary to identify 
the crossings  of axes with the strongest functional weight. We so determined,  for 
example, the following datamarts of first level: offer of care, consumption of care, 
follow   up   of   countable   expenditure,   analyze   of   pathologies,   …   To   determine   the 
datamarts   of   second   level,   we   were   interested   in   the   possibilities   of   aggregation, 
rights, and access… But  in a restricted domain, it is  easy to compose with these 
parameters. Only one question remained unresolved, concerning view materialization: 
must datamarts  (first and second level) be physically built  or just views from the 
databases? This question has been taken under consideration case by case, for each 
datamart.

4.3 The proposed design methodology

The process followed for the design can be summarized by these different steps:
 Data Warehouse design and methodology for the  French Health Department      9

Strategic objectives  operational objectives    requests    axes and attributes  

crosses of axes    functional weight    first level of datamarts    second level of 
datamarts.

Some definitions 

Strategic objective: it is a variation of a fundamental mission. Example: Countable 
follow­up of the expenditure for health. 

Operational objective: It is an operational variation of a strategic objective: either an 
essential mission, or the same requirements expressed by several sectors. Example: 
follow­up of the expenditure of health per countable account compared to the budget. 
The identification of an operational objective arises from the interviews.

Request: a request (has not to confuse with its expression in SQL for example) is the 
detailed variation of an operational objective, but with no detailed specifications. For 
example, the follow­up of the expenditure of health per countable account is expressed 
by several requests, of which: measure each month the amount  of expenditure by 
countable account, with recall of the last twelve months and comparison with the 
budget.

Functional field: It is the logical regrouping of several operational objectives at the 
level of the company. The finality is to facilitate the research and the presentation of 
work. Examples: countable spend, consumption analyze, follow­up of pathologies. It 
is generated by a synthesis. 

Axes of analysis: an axe of analysis is a dimension, but from a conceptual point of 
view. It is specified by attributes. They are obtained from the operational objectives. 
For each objective, the axes of analysis are defined. An empirical method to identify 
them  consists  in  asking  the   following  question   "what  do  I  want  to  know  for  this 
objective and how?". Each time we meet the word "BY" in an answer,we obtain either 
an attribute or an axe of analysis. So you can specify the useful attributes. Example: "I 
want   to   know   the   spends   for   health   by   patient   and   by   practitioner   to   realize   the 
monitoring   tables   of   the   expenditure   of   health".   In   this   case   "Patient"   and 
"practitioner" become axes of analysis. (NB: we often find behind the word "FOR" 
whole   or   part   of   the   objective).   Examples   of   axes:   patients,   practitioner, 
organizations...
 Data Warehouse design and methodology for the  French Health Department      10

Attribute: It is an elementary variation of an axe. It is very close to the concept of 
physical   field   of   a   table,   but   the   translation   from   the   attribute   in   field   is   not 
systematic. The physical form of the data can be modified for reasons of volume, 
optimization, cardinality... At this stage, we are still at a conceptual and logical level. 
For example, for the "patient" axe, we have the following attributes: identification / 
date of birth / sex / Socio Professional Category...

Steps of the method

Our method for datamart's design is articulated in three phases: collect the objectives 
and the requirements, express them in requests and axes, and define the datamarts by 
crossing axes. The essential word who prevailed with the design was: "Iteration". The 
analysis didn’t start by the expression of requirements but rather by the analysis of 
various documents: the Health Service’s task, it’s strategic plans, the law regarding 
social security (national health service) financing, the contracts regarding objectives 
and management…

Stage 1: Collecting the objectives and the requirements 

Collecting the requirements was held in three steps : the common base, analysis of the 
strategic objectives by direction and the collecting of the desired products. A first 
document (common base) was filled out by each direction. Its finality is to position 
the trade to the project, the strategic objectives, the legislative environment, and to 
decline the strategic objectives in operational objectives within the framework of the 
project. The questions were : definition of the trade, essential missions, position of the 
trade with the strategic orientations of the health service, the legislative and lawful 
contexts,   identification   of   the   texts   supporting   or   slowing   down   the   action, 
identification of the lawful or legislative lacks… 

The second phase is the analysis of the objectives. Each direction filled out a file 
by objective, and declined the requirements of knowledge, the type of awaited result 
and the actors. The objectives were classified by priority.

At least, requirements were declined in awaited products. In this step, we specify 
data sources, granularity... Collected requirements have been reformulated, compiled 
and summarized. Reformulation made possible to highlight common requirements (or 
very close) in different sectors. Summary made appear 26 functional objectives, for 
example: Follow­up of the expenditure of health, demography of the offer of care, 
 Data Warehouse design and methodology for the  French Health Department      11

follow­up   of   the   individual   activity   of   practitioners,   analyzes   the   consumption   of 

medicines... 

Stage 2: requests and axes 

Each objective is declined in requirements. From these needs, the standard requests 
and the potential axes of analysis are identified. It is from this step that the first pivot 
takes place: each need is declined in requests, attributes and axes. These last points 
become then  center  of  the  analyze.  It  was necessary  to create  a  document  which 
specifies, for each request, axes (by specifying if they are aggregated or detailed), 
attributes, and objective or covered requirements. It is useful at this stage to use the 
previously defined functional regroupings. This analysis will allow to redefine the 
functional perimeter of the datawarehouse, to create the axes, to create a meta model, 
to begin to build the metadata repository and in finality to constitute the datamarts. 
The meta model and the repository offers a good visibility of the system. All the 
necessary attributes are extracted from the analysis of the requests and constitute the 
repository, which is fed from the very start of the project. 

Stage 3: Constituting  the datamarts

The method to constitute the datamarts is done in several steps:
­ Identify crossings of axes: starting from the requests and for each one, identify axes 
to be crossed, without specifying any level of aggregation. Note the number of axes to 
be   crossed   as   well   as   the   importance   of   the   functional   requirements   (strong, 
intermediary, secondary)
­   Calculate   functional   weight   of   each   cross   of   axes:   from   the   previous   step,   by 
multiplying the importance of requirement (affected with coefficients 20, 5 and 1 
among its importance) by the number of requests concerned. Then sort the results in 
descending order to treat in priority the strong and complex requirements.
­ Create the datamarts of first level: when the functional weight is computed, it is 
enough to make functional groups. The regroupings are made from the weights, the 
requirement,   the   analysis   and   the   users   (right   and   trades).   You   can   constitute   a 
datamart, even weak weight, if it is intended for a particular category. The regroupings 
represent the datamarts of first level. Example (extract) of weight, crosses, and first 
level datamarts:
 Data Warehouse design and methodology for the  French Health Department      12

number of requests
Intermediate need
Secondary need

number of axes

DATAMART
Strong need

Weight
Axes
Patient X Establishment X Benefits X Practitioner 4 14 18 4 1200 Consum
Establishment x Benefits x Practitioner 1 9 17 27 3 1158 Offers
Benefits x Practitioner 2 6 22 30 2 944 Offers
Establishment x Benefits 1 9 17 27 2 772 Offers
Patient x Benefits 4 7 11 22 2 518 Consum
Patient x Benefits x Practitioner 1 2 7 10 3 453 Consum
Patient x Establishment x Benefits 7 7 3 420 Consum
Patient x Pathology x Benefits 2 3 5 3 210 Patho

Table 1. Example of result (cross of axes)

Consum   =   consumption   of   care,   Offers   =   offers   care   (the   patient   axis   does   not 
intervene), Patho = pathologies
­ Constitute datamarts of second level: when datamarts of first levels are designed, it 
is necessary to create datamarts of second level, by using analysis, requirements and 
users (or trades), but more especially granularity and needs of aggregation. It becomes 
easy because at this step, we are in a very restricted functional field.
­   Consolidate:   to   validate   results,   obtained   by   successive   iterations,   requests   are 
reallocated in the datamarts.

5 – Data analysis : Some results from the prototype

Some analyses have been carried out using the prototype. Here are some examples 
taking medicine as the theme : a Kohonen card, a hierarchical ascending classification 
and a neural network analysis. These studies were based on reimbursements over two 
years using only the date of reimbursement and the medicine’s code. These elements 
were joined to the medicines’ file which contained other information (in particular the 
ATC and EPHMRA classifications).

This approach may seem simple but is not without interest. Certainly over the years 
the   results   have   surprised   the   doctors   who   find   them   strongly   redoubtable. 
Nevertheless on observing the Kohonen card it can be seen that on the lower part and 
a little on the right hand part, prescribed medicines have been strongly influenced by 
the substitution of generics. 

NEURAL CLASSIFICATION ( KOHONEN NETWORK )

CLONIDINE , CROMOGLICIQUE ACIDE , CAPTOPRIL , CLOMIPRAMINE , ACEBUTOLOL , AMIODARONE , BACLOFENE , BUFLOMEDIL ,

DIHYDROERGOTAMINE , DIHYDROERGOTOXINE ,
DIPYRIDAMOLE , DISOPYRAMIDE , INDAPAMIDE ,
ISOSORBIDE DINITRATE , METHYLDOPA ,
NIFEDIPINE , PIROXICAM , RANITIDINE ,
SELEGILINE , TIMOLOL , TRAMADOL ,
DICLOFENAC , DILTIAZEM , FLUTAMIDE ,
FUROSEMIDE , GLICAZIDE ,
INDOMETACINE , NAFTIDROFURYL ,
PIRACETAM , SULPIRIDE ,
TRANEXAMIQUE ACIDE , TRIMETAZIDINE ,
BROMOCRIPTINE , DIAZEPAM , DIOSMINE , ECONAZOLE
MIANSERINE , NICERGOLINE , (NITRATE ) , FLUNITRAZEPAM ,
PROPRANOLOL , KETOPROFENE , METOPROLOL
SPIRONOLACTONE + ALTIZIDE , (Tartrate de ), SPIRONOLACTONE ,
TAMOXIFENE , VALPROIQUE ACIDE , VERAPAMIL ,

ACICLOVIR , CIMETIDINE , CYCLANDELATE , ALLOPURINOL , ALPRAZOLAM , ATENOLOL , BETAHISTINE ,

PENTOXIFYLLINE , SUCRALFATE , BROMAZEPAM , OXYBUTYNINE , METFORMINE , TIAPRIDE ,
SULFAMETHOXAZOLE + TRIMETHOPRIME , ZOPICLONE ,

AMBROXOL , AMOXICILLINE , ERYTHROMYCINE BUSPIRONE , TRIMEBUTINE , CALCITONINE , FENOFIBRATE ,

ETHYLSUCCINATE , ERYTHROMYCINE LACTULOSE , MEBEVERINE ,
PROPIONATE , IBUPROFENE , THIOCOLCHICOSIDE ,
LOPERAMIDE (CHLORHYDRATE DE ),
PHLOROGLUCINOL ,

CARBOCISTEINE , CEFADROXIL , CEFALEXINE , DEXTROPROPOXYPHENE +, MINOCYCLINE , TETRAZEPAM ,

CEFRADINE , DOXYCYCLINE , NIFUROXAZIDE , PYRANTEL , TETRACYCLINE , TIAPROFENIQUE ACIDE ,
 Data Warehouse design and methodology for the  French Health Department      13

Fig. 2.  Kohonen Card ­ Medicines

A Kohonen card concerning molecules and principal active ingredients can enable 
the detection of niches and could influence laboratory research. 

The second graph is equally interesting : atypical behavior appears quite clearly for 
three categories of medicine (Dextropropoxyphene, Amoxicilline, Carbocistéine and 
very slightly for Buflomedil). It seems that during this period their reimbursement 
was modified (becoming non­reimbursable or reduced from 65% to 35%) or they 
were   criticized   in   the   press   for   « being   almost   ineffective »   or   replaced   by   other 
generic medicines 
1.5

DEXTROPROPOXYPHENE+
1

0.5
BUFLOMEDIL
SommeDeaoût-99 DIOSMINE
SommeDejuillet-99 ZOPICLONE
FUROSEMIDE
SommeDemai-99 BROMAZEPAM
METFORMINE
ALPRAZOLAM
FENOFIBRATESPIRONOLACTONE
ALLOPURINOL ECONAZOLE + ALTIZIDE
(NITRATE)
SommeDejuin-99
SommeDeavril-99 NAFTIDROFURYL
ACEBUTOLOL
FLUNITRAZEPAM
GLICAZIDE
THIOCOLCHICOSIDE
ATENOLOL
LACTULOSE SPIRONOLACTONE
NICERGOLINE
SommeDeseptembre-99 DICLOFENAC
PIROXICAM
TRIMEBUTINE
TETRAZEPAM KETOPROFENE
CAPTOPRIL
PIRACETAM
SULFAMETHOXAZOLE
MEBEVERINE
AMIODARONE
TIMOLOL
MIANSERINE
VERAPAMIL
LOPERAMIDE ERYTHROMYCINE
(CHLORHYDRATE +
SommeDenovembre-99 PHLOROGLUCINOL
0 TRAMADOL
BETAHISTINE
SULPIRIDE
DILTIAZEM
PROPRANOLOL
TIAPRIDE
PENTOXIFYLLINE
ISOSORBIDE
CLONIDINE
RANITIDINE
OXYBUTYNINE
CLOMIPRAMINE
DIAZEPAM
BROMOCRIPTINE
TAMOXIFENE
TRANEXAMIQUE
DIPYRIDAMOLE
METHYLDOPA DINITRATE
DIHYDROERGOTAMINE
VALPROIQUE
BACLOFENE
METOPROLOL
NIFEDIPINE
ACICLOVIR ACIDE
ACIDE
(Tartrate
DIHYDROERGOTOXINE
INDOMETACINE
BUSPIRONE
SUCRALFATE de)
SommeDemars-99
SommeDeoctobre-99 IBUPROFENE TIAPROFENIQUE
CIMETIDINE
TRIMETAZIDINE
INDAPAMIDE
CALCITONINE
FLUTAMIDE
SELEGILINE
ERYTHROMYCINE
CROMOGLICIQUE
PYRANTEL
DISOPYRAMIDE
CYCLANDELATE
TETRACYCLINE
MINOCYCLINE
CEFALEXINE
AMBROXOL ACIDE
PROPIONATE
ACIDE
TRIMETHOPRIME
ETHYLSUCCINATE
CEFRADINE
DOXYCYCLINE DE)
Axe Vertical F 2

-2 -1.5 -1 SommeDedécembre-99 -0.5 0 NIFUROXAZIDE 0.5

SommeDejanvier-99 CEFADROXIL
SommeDefévrier-99
-0.5

-1

CARBOCISTEINE

-1.5

AMOXICILLINE
-2

-2.5
Axe Horizontal F 1

Fig. 3. Analysis of medicines.

As an example, an analysis on the way a certain medicine (let it call "A") was taken 
showed an atypical behavior as to when it was prescribed. Mostly women particularly 
took the "A" medicine in spring. A medical enquiry showed that this medicine had 
diuretic and slimming properties (even though it wasn’t its purpose and it was not 
prescribed for these reasons), then, with the approach of summer, many women got 
this medicine to help them in losing weight.

D e c is io n T r e e f o r C a l c u l a t i n g D i s ta n c e s

S a m e m e d ic in e ?

S a m e m o le c u le ? S am e dosage?

0 0 .5 0 .7 5 S a m e p o s o lo g y ?

0 .9 1
 Data Warehouse design and methodology for the  French Health Department      14

To end, here is  an approach (not  experimented) in trying to identify difference 

between two prescriptions. The question is: how can we compare two prescriptions by 
calculating the distance between them? 
Fig. 4. Calculating the distances between the prescriptions

6 ­ Conclusion

The ERASME datawarehouse will be the support for data analyses, follow up and a
provider of knowledge for decision taking. The implementation  of this  decisional 
database represented an important technological and political challenge. Putting it into 
practice has been progressive and the first results are providing the essential elements 
in replying to multiple problems and lead us to the end result: how to treat illness at 
minimal cost. Nevertheless, there are still several complex problems to solve: 
- How   can   we   effectively   compare   two   prescriptions and,   in   particular,   which 
guidelines should be established when considering two similar prescriptions? 
- Should the datamarts be views of the datawarehouse or physical structure?
- Some analysis consists in carrying out the follow-up of permanent samples. So,
how can we define the sampling procedures, which will provide sufficient
information to cover requirements which may be expressed in 1, 5, 10, 20 years?
- How also can we identify healthcare outbreaks; qualify them, arrange them in
order, give them a signification in terms of treatment and processes (preventative,
curative, follow-up) ?

The main difficulties where mainly caused by huge volumes of data. We have
chosen to solve them by an appropriated methodology. The main conclusion issued
from this experience is the very need for a conceptual level in order to support
multidimensional requirement, a logical level and a methodology to go through
abstraction levels until physical organization in a hierarchy of data marts. Some
models such as UMM [Akoka et Al. 2001] could help to formalize our
methodological guideline.

Bibliography

[Agrawal   1997]   R.   Agrawal,   A.   Guppta,   and   S.   Sarawagi   :   Modeling   Multidimensional 

Databases. Proceedings of the Thirteenth International Conference on Data Engineering, 
Birmingham, UK, 1997, pp. 232­243.
[Akoka et al. 2001] J. Akoka, I. Comyn­Wattiau and N. Prat : "Dimension Hierarchies Design 
from UML Generalizations and Aggregations", ER'2001.
 Data Warehouse design and methodology for the  French Health Department      15

[Cabibbo   1998]   L.   Cabibbo,   and   R.   Torlone   :   A   Logical   Approach   to   Multidimensional 

Databases. Proc. of the 6th Int’l Conference on Extended Database Technology (EDBT'98), 
Valencia, Spain, March 1998, pp. 187­197. 
[Carneiro 2002] L. Carneiro, A. Brayner : X­META ­ A Methodology for Data Warehouse 
Design with Metadata Management – Caise 2002.
[Firestone   1998]   J.M.   Firestone   :   Dimensional   Object   Modeling.   Executive   Information 
Systems, Inc., White Paper n. 7, April 1998 (available at http://www.dkms.com/ DOM.htm). 
[Gardner 1998] S. R. Gardner : Building the Data Warehouse. Communications of the ACM, v. 
41, n. 9, p. 52­60. September, 1998.
[Giovinazzo 2000] W. A. Giovinazzo : Object­Oriented Data Warehouse Design. Prentice Hall, 
New Jersey, NJ, 2000. 
[Golfarelli and Rizzi. 1998] M. Golfarelli, S. Rizzi : A methodological framework for data 
warehousing design, ACM workshop on data warehousing and OLAP, 1998.
[Golfarelli   1998]   M.   Golfarelli,   D.   Maio,   and   S.   Rizzi   :   The   dimensional   fact   model:   a 
conceptual  model  for  data  warehouses.   International  Journal   of  Cooperative   Information 
Systems 7, 2­3 (1998), 215­247. 
[Golfarelli   et   Al.1998]   M.   Golfarelli,   D.   Maio,   and   S.   Rizzi   :   Conceptual   Design   of   Data 
Warehouses   from   E/R   Schemas.   Proc.   of   the   31st   Hawaii   Int’l   Conference   on   System 
Sciences, Vol. VII, Kona, Hawaii, 1998, pp. 334­343. 
[Golfarelli 1999] M. Golfarelli, and S. Rizzi : Designing data warehouses: key steps and crucial 
issues. Journal of Computer Science and Information Management 2, 3 (1999). 
[Inmon 1996] W. H. Inmon "Building the Data Warehouse", John Wiley and Son editors, ISBN 
: 0471141615, 1996.
[Kimball 1997] R. Kimball : A Dimensional Modeling manifest. DBMS 10, 9 (August 1997). 
[Kimball 1998] R. Kimball, L. Reeves, M. Ross, and W. Thomthwaite : The Data Warehouse 
Lifecycle   Toolkit:  Tools  and   Techniques   for   Designing,   Developing  and   Deploying  Data 
Warehouses. John Wiley & Sons, New York, 1998. 
[Kimball 2000] R. Kimball : Mystery Dimensions. Intelligent Enterprise Magazine 3, 5 (March 
2000). 
[Krippendorf 1997] M. Krippendorf, and I­Y. Song : The Translation of Star Schema into Entity 
Relationship Diagrams. Proc. of the Eighth Int’l Workshop on Database and Expert Systems 
Applications, DEXA'97, Toulouse, France, 1997, pp. 390­395. 
[Laender 2002] A. H. F. Laender, G. M. Freitas, M. L. Campos : MD2 – Getting Users Involved 
in the Development of Data Warehouse Applications – Caise 2002.
[Lambert 1995] B. Lambert : Break Old Habits To Define Data Warehousing Requirements. 
Data Management Review (December 1995). 
[Missaoui   2000]   R.   Missaoui,   R.   Godin,   J.M.   Gagnon   :   Mapping   an   Extended   Entity­
Relationship   into   a   Schema   of   Complex   Objects.   Advances   in   Object­Oriented   Data 
Modeling 2000: 107­130. 
[Moody 2000] L.D. Moody, and M.A.R. Kortink : From Enterprise Models to Dimensional 
Models: A Methodology for Data Warehouses and  Data Mart Design.  Proc. of  the Int’l 
Workshop on Design and Management of Data Warehouses, Stockholm, Sweden, 2000, pp. 
5.1­5.12.
 Data Warehouse design and methodology for the  French Health Department      16

[Pereira 2000] W. A. L. Pereira : A Methodology Targeted at the Insertion of Data Warehouse 
Technology in Corporations. MSc. Dissertation. Porto Alegre­PUCRS, 2000.
[Phipps   2002]   C.   Phipps,   K.   C.   Davis   :   Automating   Data   Warehouse   Conceptual   Schema 
Design and Evaluation – Caise 2002.
[Poe 1998] V. Poe, P. Klauer, S. Brobst : Building a data warehouse for decision support. New 
Jersey, Prentice Hall PTR, 1998.
[Rizzi 2002] S. Rizzi, M. Golfarelli, E. Saltarelli : Index selection for data warehousing – Caise 
2002.
[Sapia 1998] C. Sapia, M. H. Blaschka, G. Fling, and B. Dinter : Extending the E/R Model for 
the Multidimensional Paradigm. Proc. of the Int’l Workshop on Data Warehousing and Data 
Mining, Singapore, 1998, pp. 105­116. 
[Semann 2000] H. B. Semann, J. Lechtenberger, and G. Vossen : Conceptual Data Warehouse 
Design.   Proc.   of   the   Int’l   Workshop   on   Design   and   Management   of   Data   Warehouses, 
Stockholm, Sweden, 2000, pp. 6.1­6.11. 
[Song 2001] I.­Y Song, W.Rowen, C.Medsker, and E. Ewen : An Analysis of Many­to­ Many 
Relationships Between Fact and Dimension Tables in Dimension Modeling. Proc. of the Int’l 
Workshop on Design and Management of Data Warehouses, Interlaken, Switzerland, 2001, 
pp. 6.1­6.13. 
[Trujillo 2001] J.Trujillo, M.Palomar, J. Gomez, and I.­Y. Song : Designing Data Warehouses 
with OO Conceptual Models. IEEE Computer 34, 12 (2001), 66­75. 
[Tsois 2002] A. Tsois, N. Karayannidis, T. Sellis, D. Theodoratos : Cost­Based Optimization of 
Aggregation Star Queries on Hierarchically Clustered Data Warehouses – Caise 2002