RAPPORT DE STAGE - Freeegrospellier.free.fr/Rapports/RapportCCAM.pdfRapport de stage : Migration des...

Rapport de stage : Migration des données d’un fichier texte vers une base de données Oracle page 1

Elisabeth GROSPELLIER IQS Année 2002/2003

RRAAPPPPOORRTT DDEE SSTTAAGGEE

MMIIGGRRAATTIIOONN DDEESS DDOONNNNEEEESS DD''UUNN FFIICCHHIIEERR TTEEXXTTEE VVEERRSS UUNNEE BBAASSEE DDEE

DDOONNNNEEEESS OORRAACCLLEE


SOMMAIRE SOMMAIRE _______________________________________ 2 REMERCIEMENTS ___________________________________ 4 INTRODUCTION ____________________________________ 5 PRESENTATION DE L’ETABLISSEMENT _____________________ 6

I. Présentation générale 6 II. Présentation du service 7 III. Présentation de l’équipe 8

PRESENTATION DU PROJET ____________________________ 9 I. Présentation de la CCAM 9 II. Rôle des NTIC dans la CCAM 9 III. Format de diffusion des informations 10 IV. Cahier des charges 10 V. Analyse 11

1. Choix des outils 11 2. Apprentissage de PL/SQL 12 3. Analyse de la documentation CCAM 13 4. Problèmes de base 14

VI. Développement et Test 14 1. Fonctions développées 15 2. Tests 17 3. Documentation 18

VII. Problèmes rencontrés 19 1. Tables 19 2. Champs 19 3. Types 20 4. Communication avec la CCAM 20

BILAN __________________________________________ 21 I. Bilan personnel 21 II. Bilan professionnel 21

ANNEXES ______________________________________ 23 ANNEXE I _______________________________________ 24 ANNEXE II _______________________________________ 29 ANNEXE III ______________________________________ 31


ANNEXE IV ______________________________________ 33 ANNEXE V_______________________________________ 35


REMERCIEMENTS Je tiens à remercier tout particulièrement mon

maître de stage, Madame Danielle GILLES ainsi que mon tuteur, Monsieur Rémi RUPPLI, pour m’avoir suivie et formée de manière constructive et pour m’avoir orientée pédagogiquement au cours de ce stage en entreprise.

J’adresse également tous mes remerciements à

Monsieur François TAVIN avec qui j’ai travaillé sur ce projet ainsi qu’aux personnes de la cellule C.PAGE Dossier Patients pour leur disponibilité.

Que tous ceux qui ont contribué de près ou de loin

au bon déroulement de ce projet reçoivent l’expression de ma sincère gratitude.


INTRODUCTION L'obtention du DUT est conditionnée par un stage

de 10 semaines en entreprise. J'ai eu la chance d'effectuer ce stage très

formateur au Centre Hospitalier Universitaire de Dijon au sein du service G.I.P. C.PAGE, cellule Suivi Dossier Patient, sous la tutelle de Madame Danielle GILLES.

Je me suis consacrée dans un premier temps à la découverte du logiciel CDP2 (« C.PAGE Dossier Patient Version 2 ») par le biais de la réalisation de fiches et des tests de sa dernière version : * Semaine 27 : Prise de contact avec l'équipe

Prise de contact avec le logiciel CDP2

* Semaine 28 : Elaboration de fiches sous CDP2 Tests de la version 7.4.0 suite à modifications

* Semaine 29 : Suite tests version 7.4.0 La deuxième partie de mon stage a été consacrée

à la réalisation du projet proprement dit : * Semaines 30 et 31 : Analyse du projet de stage * Semaines 32 à 34 : Développement et tests * Semaine 35 : Tests de la version définitive * Semaine 36 : Rédaction du dossier de

maintenance * Semaine 37 : Rédaction du rapport de stage


PRESENTATION DE L’ETABLISSEMENT

I. PRESENTATION GENERALE

A l’origine, Centre Régional Informatique Hospitalier de Bourgogne (C.R.I.H.) puis Centre Etude Systèmes Informatique Hospitalier de Bourgogne (C.E.S.I.H.B.), le G.I.P. C.PAGE assure depuis plus de trente ans la création, la diffusion et la maintenance de logiciels auprès d’établissements hospitaliers de la région Bourgogne, voire même extérieurs à la région.

Constitué en Groupement d’Intérêt Public (G.I.P.) depuis le 1er janvier 2003, il regroupe environ 230 établissements adhérents en France métropolitaine. Sa mission reste l’exploitation, le développement, la diffusion et la maintenance des progiciels de la solution C.PAGE.

Il assure également le traitement de la paie pour les établissements membres qui le souhaitent (environ 100 000 bulletins de paie/mois).

Outre l’équipe de direction, les différents départements qui composent le G.I.P. sont les suivants :

Département études recherches et développement Unité C.PAGE Gestion Clients,

Gestion économique et financière,


Gestion Ressources Humaines, Structure et outils Infocentre C.PAGE Analyse

de gestion, Gestion des équipements, Gestion des tutelles, Applications médicales (dossier patient, PMSI,

Samu, Gestion des Rendez-Vous), Département système et réseaux, Département versions C.PAGE (diffusion

versions), Département suivi de clientèle (help desk,

diffusion,…), soit environ une centaine de personnes au total. J’ai effectué mon stage dans le service

Applications Médicales.

II. PRESENTATION DU SERVICE

Le service Applications Médicales est composé de quatre cellules représentant une quinzaine de personnes. J’ai été affectée à la cellule consacrée au développement du progiciel d’aide à la gestion des dossiers des patients (CDP2 pour « C.PAGE Dossier Patient version 2 »).

Un peu de technique : Le module C.PAGE Dossier Patient fonctionne sur

base de données ORACLE en mode client serveur sous réseau ETHERNET. Le serveur évolue dans un environnement UNIX et les clients sont gérés en mode graphique par WINDOWS 95, 97 et 2000, respectant les normes d’ergonomie de MICROSOFT.

Le serveur UNIX peut être commun à l’ensemble des modules C.PAGE et partager la base de données ORACLE.


III. PRESENTATION DE L’EQUIPE

Notre équipe de travail était constituée de François TAVIN (ancien élève de l’IUT de Dijon, actuellement en maîtrise informatique à l’université de Bourgogne) et de moi-même.

Nous étions supervisés par Mademoiselle Sabine MIMOUNI.


PRESENTATION DU PROJET

I. PRESENTATION DE LA CCAM

La CCAM (Classification Commune des Actes Médicaux) est, comme son nom l’indique, une classification nationale de tous les actes médicaux. Elle permet, comme la nomenclature précédente, d’alimenter le PMSI (Programme de Médicalisation du Système d’Information), de référencer les actes de tous les centres hospitaliers français et d’évaluer leur activité globale.

De cette évaluation va dépendre en particulier le contenu de l’enveloppe budgétaire attribuée à chaque centre d’une année sur l’autre.

II. ROLE DES NTIC DANS LA CCAM

Comme tout projet de référencement à l’échelle nationale, la CCAM requiert la mise en place d’un réseau de communication entre le serveur national et les différents centres « clients ».

Chaque centre possède donc un « serveur d’actes » qui contient la liste exhaustive des pratiques médicales (leurs noms, leurs interactions et autres informations utiles) et qui référence les différents actes réalisés (date, heure, praticien, patient, …).

La structure de ces serveurs a été décidée au niveau national par la CNAM (Caisse Nationale


d’Assurance Maladie). Un Modèle Physique des Données (Annexe I) a été distribué aux différents services informatiques responsables de l’implémentation de ce système. Dans notre cas (groupe G.I.P. C.Page), une base de données relationnelle a été réalisée sous Oracle à partir de ce modèle.

Avant de pouvoir référencer les pratiques des médecins du centre, il est nécessaire d’initialiser la base de données afin qu’elle connaisse tous les actes ainsi que leurs descriptions.

III. FORMAT DE DIFFUSION DES INFORMATIONS

La CNAM a choisi de diffuser les informations dont je parlais précédemment sous la forme d’un fichier texte composé d’une liste d’enregistrements (Annexe II).

Le premier des fichiers transmis contient les valeurs initiales de la base, les suivants indiqueront les modifications ainsi que l’apparition de nouvelles pratiques médicales.

IV. CAHIER DES CHARGES

Le but de ce projet est de réaliser un mécanisme de migration des données depuis ces fichiers vers la base de données.

Ce mécanisme devra ouvrir le fichier texte, en lire les enregistrements et les traiter un par un dans le but de réaliser des insertions dans la base de données.

Il est nécessaire que ce mécanisme soit contrôlable à partir de code PHP (à la demande de Madame LAGOUTTE, service « Liaison avec les applications régionales »).

Bien entendu le projet doit être facilement « maintenable » et évolutif car la CCAM est sujette à modifications jusqu’au 31 décembre 2003.


V. ANALYSE

1. Choix des outils

Pour mener ce projet à son terme, il a fallu dans un premier temps choisir un langage de programmation adapté au traitement des informations.

Nous avons retenu trois langages connus du personnel du service (à leur demande, pour permettre une maintenance sans nouvel apprentissage) :

Visual Basic (VB) : c’est le langage utilisé majoritairement au sein de la cellule Dossier Patient. Il présente l’avantage d’être assez simple d’emploi tout en proposant la majorité des fonctionnalités requises dans ce projet (traitement de fichier, interaction avec des bases de données). Hélas, d’après le cahier des charges, la procédure doit pouvoir être lancée à partir de code PHP (interface Web), ce qui est difficile, voire impossible, avec ce langage.

PHP Hypertext Processor (PHP) : Le PHP est actuellement le langage de prédilection des programmeurs pour les logiciels Internet (sites web, web services). C’est un langage orienté objet proche du C/C++ et donc rapidement appris de la majorité des programmeurs. Il permet la gestion des fichiers ainsi que l’interaction avec les bases de données (avec une prédilection pour MySQL, SGBD très courant sur Internet). Il est évidemment contrôlable à partir du PHP mais, malheureusement, tous les centres n’ont pas d’interpréteur de PHP (Apache). Les équiper avec cet interpréteur représente une perte non négligeable en terme de temps et d’argent.

PL/SQL : ce langage, maîtrisé par une personne de la cellule, consiste à écrire des procédures stockées dans la base de données elle-même donc appelables à partir de tout ce qui interagit avec la base de données (PHP, VB,…). C’est le langage le plus efficace


à l’heure actuelle lorsque l’on souhaite travailler sur une base Oracle. Par contre il montre quelques faiblesses en ce qui concerne les traitements de fichiers.

Compte tenu de cette analyse, j’ai exclu dans un premier temps Visual Basic qui posait trop de problèmes de lancement.

Après discussion avec Madame LAGOUTTE et Monsieur POITTEVIN (seules autres personnes du service à connaître PHP et MySQL), j’ai finalement retenu l’outil PL/SQL puisqu’il remplissait les deux conditions incontournables du cahier des charges, à savoir :

le langage utilisé devait être connu dans le service (maintenance du programme),

le programme devait pouvoir être lancé par tous les centres.

2. Apprentissage de PL/SQL

La première phase de mon travail a été l’apprentissage du langage choisi pour ce projet. En effet, nous avions eu l’occasion de l’évoquer en cours de Base de Données mais je ne connaissais pas certains aspects abordés par un programme de ce type.

Ce langage est proche de l’ADA (langage étudié au cours de notre formation à l’IUT) dont on retrouve la rigueur et la fiabilité.

Tout au long de cet apprentissage puis du développement je me suis appuyée sur l’ouvrage « Oracle PL/SQL : Guide de Programmation » de Steven Feuerstein aux éditions O’REILLY ainsi que de sources Internet (http://sgbd.developpez.com pour ses forums et http://otn.oracle.com/documentation/content.html pour la documentation officielle Oracle).


3. Analyse de la documentation CCAM

Cette documentation (« Codage Récapitulatif Bases & Normes d’échange ») d'une centaine de pages fournit la description du fichier texte format NX et a été transmise au G.I.P. C.PAGE par la CNAM.

Pour information, le fichier texte « complet » se compose de 162 928 enregistrements qui se présentent sous forme de lignes de 128 caractères. Chaque ligne contient un en-tête de 7 caractères qui nous permet de définir dans quelle(s) table(s) les données doivent être insérées.

Dans un premier, j’ai analysé cette documentation en créant mon propre dossier de correspondances afin de refaire les liens entre les enregistrements du fichier texte et les champs de la base données fournie par la CCAM.

Cette phase a posé quelques problèmes car certaines correspondances n’étaient pas évidentes a priori. De plus, j’ai travaillé dans un premier temps sur une version réduite où tous les enregistrements n’étaient pas présents, d’où une difficulté certaine pour une « non-initiée » pour interpréter au mieux les informations transmises par la CCAM.


4. Problèmes de base

Dès le début de ce projet, j’ai été confrontée à un certain nombre de problèmes liés à l’écriture du programme.

En effet, il s’avère que le langage choisi (PL/SQL) propose une très faible gestion des types : il gère les entiers, les chaînes de caractères et même les structures mais pas les tableaux, les listes et les arbres ce qui aurait pu être utile dans ce projet.

En ce qui concerne l’interaction avec les fichiers, le langage est intéressant pour le traitement des bases de données mais pas très « ouvert » pour ce qui est de l’exploitation des fichiers : la lecture se fait ligne par ligne, le fichier doit obligatoirement être sur le même serveur que la base de données et défini comme autorisé.

Fort heureusement, le fichier texte se présentait sous forme de lignes de 128 caractères. Pour traiter les données, j’ai travaillé avec la fonction « SUBSTR » proposée par PL/SQL et qui prend en paramètres une chaîne de caractères, un emplacement dans cette chaîne et le nombre de caractères à extraire et retourne une nouvelle chaîne de caractères.

VI. DEVELOPPEMENT ET TEST

Après cette phase d’analyse, je suis entrée dans la phase de développement en créant un paquetage PL/SQL permettant un découpage des différents programmes nécessaires, ceci pour pouvoir les réutiliser.

Ce paquetage comprend toutes les fonctions qui serviront à l’insertion des données dans les tables, qu’elles soient publiques ou privées (visibles et invisibles).


1. Fonctions développées

Traitement des enregistrements du fichier texte (Annexe III)

Le corps du programme proprement dit consiste, après l’ouverture du fichier, en l’appel de 7 fonctions différentes qui exploitent directement les informations fournies par la CCAM (Annexe IV) :

Traitement de la ligne d’en tête, Traitement des tables de base, Traitement des tables de codification, Traitement des libellés des tables de base, Traitement des tables des concepts divers, Traitement de la table Glossaire, Traitement des actes qui appelle lui-même le

traitement des activités puis des phases d’activité.

Le fichier est fermé et les tables sont ensuite mises à jour par la fonction « COMMIT » fournie par PL/SQL .

Ces traitements sont appliqués en fonction de l’en-tête de l’enregistrement traité. En effet, cet en-tête est composé de 7 caractères qui nous indiquent dans quelles tables seront insérées les données. Par exemple, si l’en-tête est le suivant : 099 01 01, la fonction appelée sera le traitement de la table Glossaire « TTTGlossaire », la fonction TestType sur la ligne traitée avec en paramètre « 099 » ayant retourné « vrai ».

D’autres fonctions annexes ont également été écrites pour améliorer ce programme de base :

Gestion des exceptions Le programme gère les exceptions avec des

messages d’erreurs significatifs. PL/SQL propose une procédure « RAISE_APPLICATION_ERROR » qui permet cette gestion. J’ai donc conçu une quinzaine d’exceptions propres au programme qui gèrent entre


autre l’ouverture du fichier (message : « ouverture du fichier impossible »), sa lecture (message : « lecture après la fin du fichier »), etc.

Gestion des mots-clés La base de données contenant beaucoup d’actes,

il est important de pouvoir permettre à l’utilisateur de faire des recherches à partir de mots-clés. J’ai donc créé une fonction qui, à partir des libellés longs des actes (plus précis que les libellés courts), insère dans une table de la base la correspondance acte/mot-clé. Cette fonction doit éliminer les mots les plus simples : articles, conjonctions, mots inférieurs à trois lettres,… mais également éviter les doublons.

Soundex / Phonex (Annexe V) A cette étape du développement du programme,

j’ai pensé qu’il serait opportun d’utiliser le maintenant célèbre algorithme du Soundex. Cet algorithme de recherche porte sur la consonance des mots ; les mots sont codés de façon à permettre ensuite une recherche par comparaison dans la base de données. Par exemple, si l’utilisateur saisit « Dupont », le programme doit être capable de lui renvoyer « Dupond » ou tout nom phonétiquement similaire.

Oracle possède déjà un Soundex, le plus simple et le plus courant, mais qui offre un nombre réduit de possibilités (26 000 combinaisons possibles) et qui consiste à coder un mot sur ses quatre premières lettres (1 lettre et 3 chiffres).

Suite à une recherche effectuée sur Internet, j’ai trouvé d’autres variantes de cet algorithme dont une particulièrement intéressante : le Phonex. Cet algorithme a été élaboré par un informaticien en collaboration avec un orthophoniste. Il consiste à transformer un mot en un réel en 18 étapes : conversion du mot en majuscules, élimination des blancs, des tirets, des consonnes doublées, suppression des consonnes finales (« Dupont » devient « Dupon »), remplacement


de certaines lettres par d’autres (le « ph » devient « f »),…

Exemple : le nom de famille PHILAURHEIMSMET devient FILOR4SNY avant d’être converti en un réel : 0.179864540784299185.

Je n'ai utilisé pour écrire la fonction insérée dans notre programme principal qu'une partie de cet algorithme. En effet, la conversion du mot en réel n'était pas très explicite avec une formule de calcul assez compliquée ; de plus, son utilité ne m'a pas paru prouvée. J'en suis donc restée à l'étape 17 mais cette omission n'altère pas l'efficacité de notre fonction que j’ai testée sur une table fictive avec de bons résultats.

Exemple : pour « Dupont », il retourne aussi bien « Dupond » que « Duton ».

Le PHONEX est particulièrement intéressant quand la base contient beaucoup de données ce qui est le cas ici d'autant qu'on peut imaginer que l’utilisation du PHONEX soit étendue à la recherche sur le nom des patients par exemple. Site : http://sqlpro.developpez.com/Soundex/SQL_AZ_soundex.html

2. Tests

J’ai choisi de tester les différentes fonctions au fur et à mesure de leur conception. En effet, le programme final est assez long et il aurait été très fastidieux et plus compliqué de ne le tester qu’au terme de son écriture.

Le fait de tester chaque fonction une par une me permettait de passer à la fonction suivante en étant sûre que les fonctions déjà écrites ne poseraient pas de problèmes ultérieurement.


Pour ces tests, j’ai été obligée de créer une fonction supplémentaire « CLEARCCAM » qui consiste à vider toutes les tables de la base de données avant de traiter les informations du fichier texte par un « DELETE FROM TABLE ».

Cela m’a permis de constater « de visu » l’efficacité du programme en vérifiant après son exécution que les tables étaient bien complétées. Cette fonction devra bien entendu être supprimée dans la version finale.

3. Documentation

Enfin, pour terminer cette partie de développement, il m'a été demandé de rédiger une documentation qui permettra de maintenir ou de développer ce programme dans l'avenir, documentation que vous trouverez annexée à ce rapport (« Dossier de maintenance »).

Ce document d’une dizaine de pages reprend la structure du paquetage ainsi que l'enchaînement des différentes fonctions. Il donne également une explication sur les fonctions « bas niveaux » utilisées dans le programme. Par fonctions « bas niveaux » j'entends les fonctions nécessaires pour l'exploitation de notre fichier mais non directement « utiles » dans le traitement des informations.

A titre d'exemple, il a été nécessaire de créer une fonction « TestType » puisque la base de notre programme est de vérifier systématiquement l'en-tête de l'enregistrement afin de savoir dans quelle(s) table(s) insérer nos données. Ce traitement est répétitif, il aurait donc été fastidieux de le réécrire à chaque fois. Cette fonction est donc appelée chaque fois que nécessaire et prend en paramètre un enregistrement (128 caractères), un type d’enregistrement (en-tête : 3 caractères numériques), une rubrique (2 caractères numériques) et une séquence (2 caractères numériques).


Elle retourne « vrai » si l’enregistrement correspond bien à ce type, à cette rubrique et à cette séquence (la rubrique et la séquence sont facultatives et valent « 01 » par défaut).

VII. PROBLEMES RENCONTRES

Outre les problèmes de base mentionnés plus haut et qui concernaient principalement le langage de programmation PL/SQL, j’ai été régulièrement confrontée au cours de ce projet à des problèmes de non correspondance entre le fichier texte en format NX, la documentation fournie par la CCAM et la base Oracle.

1. Tables

Certaines tables mentionnées dans la documentation CCAM étaient inexistantes dans la base de données et nous avons été obligées de les créer avec Madame LAGOUTTE en fonction des besoins.

2. Champs

Il m’est arrivé également de trouver des champs supplémentaires dans les tables. Par exemple, certaines d’entre elles contenaient un champ « Date d’Effet » qui n’était pas présent dans le fichier texte NX. Après renseignement, il s’est avéré que cette date était identique aux données du champ « Date de Création » figurant dans les mêmes tables.

Inversement, j’ai parfois trouvé des données devant être insérées dans un champ ne figurant pas dans la table concernée. Par exemple, la table R_ASSOCIATION devait comporter un champ « Date de l’associabilité » qui ne figurait pas dans la table. Renseignements pris auprès de Madame LAGOUTTE, j’ai créé un nouveau


champ dans la table par l’intermédiaire d’une requête SQL.

3. Types

De la même façon, les types trouvés dans les tables étaient parfois différents de ceux donnés dans la documentation de la CCAM, par exemple : un VARCHAR2 (type alphanumérique) pour un NUMBER (type numérique). Parfois même, les données étaient de même type mais avec une longueur différente (NUMBER(2) au lieu d’un NUMBER(3)).

J’ai donc été obligée de vérifier systématiquement que l’insertion des données dans les tables ne posait pas de problèmes. Fort heureusement, le nombre de caractères à insérer était toujours inférieur au nombre de caractères prévus dans les champs donc aucune modification n’a été apportée aux tables dans ce cas de figure.

4. Communication avec la CCAM

Pour répondre à toutes ces questions et régler tous ces problèmes, la CNAM a intégré sur son site un forum dédié à la CCAM (http://www.ccam.sante.fr/).

Malheureusement, il s’est avéré que le site n’était pas mis à jour régulièrement et que le forum n’était pas disponible. Il m’a donc fallu trouver les réponses les plus logiques et les plus judicieuses possibles avec l’aide de Mademoiselle MIMOUNI et de Madame LAGOUTTE.

Ces problèmes m’ont parfois empêcher d’avancer sur mon projet et j’ai profité de ces « temps morts » pour mener en parallèle d’autres projets : création de fiches de saisie de données pour les services spécifiques, …


BILAN Comme toute nouvelle expérience, ce stage a été

extrêmement enrichissant à tous points de vue.

I. BILAN PERSONNEL

Même si ce stage n’a pas été pour moi une découverte du milieu professionnel, il m’a toutefois permis d’affiner ma connaissance de l’organisation d’un service informatique et de me rendre compte de ce qu’était le travail au sein d’une équipe.

II. BILAN PROFESSIONNEL

Travailler sur ce projet de migration des données m’a permis de mettre en pratique et d’approfondir les connaissances que j’avais acquises au cours de ma formation en Année Spéciale Informatique.

En particulier, j’ai dû travailler avec un langage de programmation (PL/SQL) que nous avions vu en cours mais de façon très succincte par rapport à ce qui m’a été demandé en stage.

Cette expérience a également été très formatrice en ce qui concerne mes connaissances en base de données. En effet, il m’a permis de découvrir la complexité de la base du G.I.P. C.PAGE et les cours d’A.C.S.I. (Analyse et Conception des Systèmes d’Information) ont également été extrêmement utiles pour comprendre le schéma de cette dernière et les


relations et interactions entre les différentes tables de la base.

En conclusion, un bilan très positif qui m’a permis de renforcer la confiance que j’avais dans mes compétences et dans ma capacité à intégrer le domaine professionnel dans lequel j’ai choisi de me reconvertir.


ANNEXES


ANNEXE I Modèle physique des données


ANNEXE II Extrait du fichier texte NX


000 00000001000000CODCAMCT00000001000000CCAM NACAC20030729 0000110205 0020101920030601000000001000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 0030101920030601000000001000 00000000000000000000 00000000000000000000 00000000000000000000 00000000000000000000 0040101012003060100000000TS022003060100000000TS032003060100000000TS042003060100000000TS052003060100000000TS062003060100000000TS 0040102072003060100000000TS082003060100000000TS092003060100000000TS102003060100000000TS112003060100000000TS122003060100000000TS 0040103132003060100000000TS142003060100000000TS152003060100000000TS162003060100000000TS172003060100000000TS182003060100000000TS 0040107732003060100000000TS742003060100000000TS752003060100000000TS762003060100000000TS772003060100000000TS782003060100000000TS 02001052020030601000000009 2120030601000000009 000000000000000000 000000000000000000 … 0910101000052000047000005Exerese et/ou fermeture de meningoencephalocele 0910101000053000047000006Evacuation de collection intracranienne extraencephalique 0910101000054000037000005Exerese de tumeur intracranienne extraencephalique 0910101000055000002000003ACTES THERAPEUTIQUES SUR LE SYSTEME NERVEUX CENTRAL SPINAL [RACHIDIEN] 0910101000056000055000001Interventions sur la moelle epiniere et la portion intrarachidienne des nerfs spinaux [rachidiens] 0910101000057000056000001Destruction de tissu spinal [medullaire] 0910101000058000056000002Section et liberation de la moelle epiniere et des racines nerveuses 0910101000059000056000003Exerese de tissu de la moelle epiniere et des racines nerveuses 0910101000060000056000004Parage et fermeture de plaie penetrante vertebrospinale [du rachis et de la moelle epiniere] [verteb 0910102000060000056000004romedullaire] 0910101000061000056000005Interventions pour malformations congenitales de la moelle epiniere 0910101000062000056000006Autres interventions sur la moelle epiniere 0910101000063000055000002Interventions sur les meninges, les ventricules et le liquide cerebrospinal [LCS] intrarachidiens 0910101000064000063000001Injection dans le liquide cerebrospinal [LCS] 0910101000065000063000002Evacuation de collection des meninges rachidiennes 0910101000066000063000003Derivation du liquide cerebrospinal [LCS] rachidien 0910101000067000063000004Autres interventions sur les meninges et le LCS intrarachidiens 0910101000068000055000003Exerese de tumeur extraspinale [extramedullaire] du canal vertebral 0910101000069000055000004Autres actes sur le systeme nerveux central et le liquide cerebrospinal 0910101000070000002000004STIMULATION DU SYSTEME NERVEUX CENTRAL ET INJECTION PROLONGEE DANS LE LIQUIDE CEREBROSPINAL [LCS] 0910101000071000070000001Stimulation du systeme nerveux 0910101000072000071000001Implantation d'electrodes de stimulation du systeme nerveux central … 999 00000001000000CODCAMCT00000001000000CCAM NACAC0000162562008238007246011905011936


ANNEXE III EXEMPLE DE TRAITEMENT DES ENREGISTREMENTS DU FICHIER TEXTE

(TTT10102)


PROCEDURE TTT10102 : traitement de l'enregistrement (obligatoire et unique) 101-02 PROCEDURE TTT10102 (fic IN OUT CCAM_File, acte IN OUT CCAM_ACTE) IS Position NUMBER(3); Sortie BOOLEAN; BEGIN Sortie := FALSE; IF NOT TESTTYPE(fic.LRL, '101', '02') THEN RAISE_APPLICATION_ERROR (-20006, 'Enregistrement 101-02 attendu (début d acte)'); END IF; acte.frais_dpl := ClrStr(SUBSTR(fic.LRL, 28, 1)); -- nature d'assurance permise : 0-10 occurrences de 2 caractères à insérer dans R_ACTE_NAT_ASS Position := 8; WHILE NOT Sortie LOOP IF SUBSTR(fic.LRL, Position, 2) = ' ' THEN Sortie := TRUE; ELSE INSERT INTO R_ACTE_NAT_ASS(ACTE_COD, NATASS_COD) VALUES (acte.code_acte, ClrStr(SUBSTR(fic.LRL, Position, 2))); Position := Position + 2; IF Position = 28 THEN Sortie := TRUE; END IF; END IF; END LOOP; NextLine(fic); END TTT10102;


ANNEXE IV CORPS DE LA PROCEDURE MAJCCAM


PROCEDURE MAJCCAM (Path IN VARCHAR2) IS FicCCAM CCAM_FILE; BEGIN -- traitement à retirer après la phase de test !! CLEARCCAM; COMMIT; -- ouverture du fichier en lecture OpenFile(FicCCAM, Path); -- traitement de la ligne entête TTTEntete (FicCCAM); -- traitement des enregistrements pour les tables TB01->TB20 TTTTBXX (FicCCAM); -- traitement des enregistrements pour les tables de codification TTTCodif (FicCCAM); -- traitement des enregistrements pour les libellés des tables TB01->TB20 TTTLibellesTBXX (FicCCAM); -- traitement des enregistrements pour les tables des concepts divers TTTConceptsDivers (FicCCAM); -- traitement des enregistrements pour la table glossaire TTTGlossaire (FicCCAM); -- traitement des actes TTTActes (FicCCAM); -- fermeture du fichier UTL_FILE.FCLOSE(FicCCAM.file_id); COMMIT; EXCEPTION WHEN UTL_FILE.INVALID_PATH THEN RAISE_APPLICATION_ERROR (-20004, 'Chemin du fichier invalide'); END MAJCCAM;


ANNEXE V CODE DE LA FONCTION SOUNDEX


FUNCTION SOUNDEX : renvoi l'empreinte SOUNDEX d'un mot passé en paramètre FUNCTION SOUNDEX (Chaine IN VARCHAR2) RETURN VARCHAR2 IS Empreinte FLOAT; Position NUMBER(3); ChaineTravail VARCHAR2(1000); ChaineTemp VARCHAR2(1000); Cpt NUMBER(4); LastChar VARCHAR2(1); BEGIN ChaineTemp := ''; ChaineTravail := Chaine; -- PREPARATION -- on supprime les espaces et les tirets Position := 1; WHILE Position i ChaineTravail := TRANSLATE(ChaineTravail, 'y', 'i'); -- ETAPE 2 : supprimer les 'h' non précédés par c, s ou p Position := 1; ChaineTemp := ''; WHILE Position


ChaineTravail := REPLACE(ChaineTravail, 'eine', 'yne'); ChaineTravail := REPLACE(ChaineTravail, 'aime', 'yne'); ChaineTravail := REPLACE(ChaineTravail, 'eime', 'yne'); ChaineTravail := REPLACE(ChaineTravail, 'aini', 'yni'); ChaineTravail := REPLACE(ChaineTravail, 'eini', 'yni'); ChaineTravail := REPLACE(ChaineTravail, 'aimi', 'yni'); ChaineTravail := REPLACE(ChaineTravail, 'eimi', 'yni'); ChaineTravail := REPLACE(ChaineTravail, 'aino', 'yno'); ChaineTravail := REPLACE(ChaineTravail, 'eino', 'yno'); ChaineTravail := REPLACE(ChaineTravail, 'aimo', 'yno'); ChaineTravail := REPLACE(ChaineTravail, 'eimo', 'yno'); ChaineTravail := REPLACE(ChaineTravail, 'ainu', 'ynu'); ChaineTravail := REPLACE(ChaineTravail, 'einu', 'ynu'); ChaineTravail := REPLACE(ChaineTravail, 'aimu', 'ynu'); ChaineTravail := REPLACE(ChaineTravail, 'eimu', 'ynu'); -- ETAPE 6 : remplacement de certains groupes de lettres par des chiffres ChaineTravail := REPLACE(ChaineTravail, 'eau', 'o'); ChaineTravail := REPLACE(ChaineTravail, 'oua', '2'); ChaineTravail := REPLACE(ChaineTravail, 'ein', '4'); ChaineTravail := REPLACE(ChaineTravail, 'ain', '4'); ChaineTravail := REPLACE(ChaineTravail, 'eim', '4'); ChaineTravail := REPLACE(ChaineTravail, 'aim', '4'); -- ETAPE 7 : remplacement du son « ai » par « y » ChaineTravail := REPLACE(ChaineTravail, 'é', 'y'); ChaineTravail := REPLACE(ChaineTravail, 'è', 'y'); ChaineTravail := REPLACE(ChaineTravail, 'ê', 'y'); ChaineTravail := REPLACE(ChaineTravail, 'ai', 'y'); ChaineTravail := REPLACE(ChaineTravail, 'ei', 'y'); ChaineTravail := REPLACE(ChaineTravail, 'er', 'yr'); ChaineTravail := REPLACE(ChaineTravail, 'ess', 'yss'); ChaineTravail := REPLACE(ChaineTravail, 'et', 'yt'); -- ETAPE 8 : remplacement de certains groupes de lettres par des chiffres ChaineTravail := ReplaceVoyelles(ChaineTravail, 'an', '1'); ChaineTravail := ReplaceVoyelles(ChaineTravail, 'am', '1'); ChaineTravail := ReplaceVoyelles(ChaineTravail, 'en', '1'); ChaineTravail := ReplaceVoyelles(ChaineTravail, 'em', '1'); ChaineTravail := ReplaceVoyelles(ChaineTravail, 'in', '4'); -- ETAPE 9 : remplacement du « z » par un « s » si suivi d’une voyelle ChaineTemp := ChaineTravail; ChaineTravail := ''; FOR Cpt IN 1..LENGTH(ChaineTemp) LOOP IF SUBSTR(ChaineTemp, Cpt, 1) = 's' AND Cpt > 1 AND Cpt < LENGTH(ChaineTemp) THEN IF SUBSTR(ChaineTemp, Cpt - 1, 1) IN ('a', 'e', 'i', 'o', 'u', '1', '2', '3', '4') AND SUBSTR(ChaineTemp, Cpt + 1, 1) IN ('a', 'e', 'i', 'o', 'u', '1', '2', '3', '4') THEN ChaineTravail := CONCAT(ChaineTravail, 'z'); ELSE ChaineTravail := CONCAT(ChaineTravail, 's'); END IF; ELSE ChaineTravail := CONCAT(ChaineTravail, SUBSTR(ChaineTemp, Cpt, 1)); END IF; END LOOP; -- ETAPE 10 : remplacement de certains groupes de lettres ChaineTravail := REPLACE(ChaineTravail, 'oe', 'e'); ChaineTravail := REPLACE(ChaineTravail, 'eu', 'e'); ChaineTravail := REPLACE(ChaineTravail, 'au', 'o'); ChaineTravail := REPLACE(ChaineTravail, 'oi', '2'); ChaineTravail := REPLACE(ChaineTravail, 'oy', '2'); ChaineTravail := REPLACE(ChaineTravail, 'ou', '3');


-- ETAPE 11 : remplacement du son « che » par 5 et des « sc » et « ss » par « s » ChaineTravail := REPLACE(ChaineTravail, 'ch', '5'); ChaineTravail := REPLACE(ChaineTravail, 'sch', '5'); ChaineTravail := REPLACE(ChaineTravail, 'sh', '5'); ChaineTravail := REPLACE(ChaineTravail, 'ss', 's'); ChaineTravail := REPLACE(ChaineTravail, 'sc', 's'); -- ETAPE 12 : remplacement des « ce/ci » par « se/si » ChaineTravail := REPLACE(ChaineTravail, 'ce', 'se'); ChaineTravail := REPLACE(ChaineTravail, 'ci', 'si'); -- ETAPE 13 : remplacement des sons « gue/que » par la lettre « k » ChaineTravail := REPLACE(ChaineTravail, 'c', 'k'); ChaineTravail := REPLACE(ChaineTravail, 'qu', 'k'); ChaineTravail := REPLACE(ChaineTravail, 'q', 'k'); ChaineTravail := REPLACE(ChaineTravail, 'gu', 'k'); ChaineTravail := REPLACE(ChaineTravail, 'ga', 'ka'); ChaineTravail := REPLACE(ChaineTravail, 'go', 'ko'); ChaineTravail := REPLACE(ChaineTravail, 'gy', 'ky'); -- ETAPE 14 : remplacement de certaines lettres par d’autres ChaineTravail := REPLACE(ChaineTravail, 'a', 'o'); ChaineTravail := REPLACE(ChaineTravail, 'd', 't'); ChaineTravail := REPLACE(ChaineTravail, 'p', 't'); ChaineTravail := REPLACE(ChaineTravail, 'j', 'g'); ChaineTravail := REPLACE(ChaineTravail, 'b', 'f'); ChaineTravail := REPLACE(ChaineTravail, 'v', 'f'); ChaineTravail := REPLACE(ChaineTravail, 'm', 'n'); -- ETAPE 15 : suppression des lettres doublées ChaineTemp := ChaineTravail; ChaineTravail := ''; LastChar := ''; FOR Cpt IN 1..LENGTH(ChaineTemp) LOOP IF SUBSTR(ChaineTemp, Cpt, 1) = LastChar THEN NULL; ELSE LastChar := SUBSTR(ChaineTemp, Cpt, 1); ChaineTravail := CONCAT(ChaineTravail, LastChar); END IF; END LOOP; -- ETAPE 16 : suppression des terminaisons “t” et “x” IF SUBSTR(ChaineTravail, LENGTH(ChaineTravail), 1) = 't' OR SUBSTR(ChaineTravail, LENGTH(ChaineTravail), 1) = 'x' THEN ChaineTravail := SUBSTR(ChaineTravail, 1, LENGTH(ChaineTravail)-1); END IF; -- ETAPE 17 : RETURN ChaineTravail; --RETURN Empreinte; END SOUNDEX;

RAPPORT DE STAGE - Freeegrospellier.free.fr/Rapports/RapportCCAM.pdfRapport de stage : Migration des...

Documents

Transcript of RAPPORT DE STAGE - Freeegrospellier.free.fr/Rapports/RapportCCAM.pdfRapport de stage : Migration des...