Introduction

Les tables de l’application sont séparées en trois bases car elles concernent 3 domaines distincts.

Cela dit, pour des raisons de praticité on peut choisir de les installer dans une seule.

Dans le cas où vous devez dupliquer l’installation d’un terminal

Prérequis IMPORTANT pour éviter des conflits de mise à jour, le terminal destination doit être déjà configuré et dans la MEME version que le terminal source.

Puis il suffit de faire ( en console bash linux )

se connecter au site source:

mysqldump base1 base2 base3 > export_tu.sql (vérifier et adapter syntaxe si besoin) récupérer le fichier export_tu.sql

se connecter au site cible et y déposer le fichier export_tu.sql :

mysql mabase -h localhost -u root < export_tu.sql (vérifier et adapter syntaxe si besoin)

( Vous pouvez également utiliser la methode de votre choix pour récupérer l’intégralité de la base du terminal source et écraser celle du terminal destination )

Descriptif des bases

NU = non utilisée

Base du framework ( utilisateurs, droits, groupes, options, logs )

• acteurs NU
• applications NU
• droits
• groupes
• listes (listes particulières de choix pour l’appli)
• logs
• navigation (correspondance url navigation -> classes controller )
• notes NU
• options
• preferences NU
• rel_application_groupe
• rel_utilisateur_groupe
• sessions_actuelles
• sessions_historique
• sessions_statistiques NU
• todo NU
• utilisateurs
• variables NU

Table droits

• idapplication : Identifiant de l’application mère
• idgroupe : identifiant du groupe qui bénéficie du droit
• libelle : nom du droit
• descriptiondroit : description du droit
• valeur : ici, c’est le même principe que les droits sous unix. On donne à chaque droit un numérique. L’attribut valeur est un total de ces numériques.
  1. r : 1
  2. w : 2
  3. m : 4
  4. d : 8
  5. a : 16

Ce qui nous fait donc un total de 31 pour tous les droits.

• lectureseule : pas utilisé

Base de l’appli

• config_alermatismes configuration des alermatismes par terminal
• config_cols configuration des colonnes du passage terminal
• config_docs_contenus configuration des documents par terminal
• config_docs_masques configuration des masques de document par terminal
• config_items configuration des items par terminal
• config_liens configuration des liens de la fiche patient par terminal
• config_listes configuration des listes de la fiche patient par terminal
• config_options configuration des options par terminal
• config_terms configuration d’un terminal
• config_transferts configuration des transferts possibles entre les terminaux
• config_transversal NU pour le moment
• config_vues configuration des vues
• crons_logs logs d’exécution des taches planifiées
• crons_taches configuration des taches planifiées
• enquetes liste des enquetes et leur etat
• formx données des formx ( formx = moteur de formulaires )
• formx_globvars (variables globales par patient des formx )
• patients_actions données des action sur les patients
• patients_alertes données des alertes sur les patients
• patients_editions données des editions sur les patients
• patients_histologs données des histologs sur les patients
• patients_messages données des messages sur les patients
• patients_mouvements données des mouvements sur les patients
• patients_notes données du bloc note sur les patients
• patients_presents données patients présents
• patients_radios données patients radio
• patients_radioscomm données patient radio commentaires
• patients_sortis données patients sortis

Base Actes et facturations (liée à la base données par idPatient et idTerminal )

• acte_local thesaurus des actes propres à chaque site
• bal_sortie boite aux lettres de sortie pré-génération des fichiers de facturation
• ccam_lettres_cle thesaurus lettres clé ccam
• configuration_terminal affectation des thesaurus aux terminaux
• consultation_specialisee données des consultations spécialisées
• cotation données de cotation
• medecin référenciel des médecins par site
• pack thesaurus des packs d’actes
• ref_acte_ccam thésaurus référentiel des actes CCAM
• ref_acte_ngap thésaurus référentiel des actes NGAP
• ref_activite_ccam thésaurus référentiel des actes-activités CCAM
• ref_categorie_diag thésaurus référentiel des categories de diag
• ref_chapitre_diag thésaurus référentiel des chapitres de diag
• ref_diag thésaurus référentiel des diags
• ref_domaine_acte thésaurus référentiel des categories de diag
• ref_modificateur NU
• ref_rel_chapitre_diag_diag relations chapitre – diag
• ref_rel_diagp_diag_relie relations diag – diag
• ref_rel_diag_typage_diag relations typage – diag
• ref_specialite_medecin relations medecins -spécialité
• ref_tarif_ccam reférentiel des spécialistés CCAM
• ref_tarif_modificateur_ccam référentiel des modificateurs CCAM
• ref_tarif_ngap référentiel des tarifs NGAP
• ref_topographie référentiel des topographies
• ref_typage_actes référentiel des typages d’acte
• ref_typage_diag référentiel des typages de diag
• rel_acte_diag relations acte – diag
• rel_cotation_actes relations cotation – acte (objet actePatient )
• rel_cotation_diags relations cotation – diag (objet diagPatient )
• rel_medecin_specialite_medecin_locale relations médecins -spécialité locale
• rel_pack_actes relation packs – actes
• rel_pack_diags relation pack – diags
• rel_typage_acte_acte relation typage – actes
• specialite_medecin_locale données des spécialités locales sur site

Tables à vider le jour du lancement

Afin d’épurer les tables de tous les tests effectués avant le lancement, il est utile de vider les tables suivantes le jour du lancement (ou la veille pour laisser quelques patients dans la table patients_presents).

• TRUNCATE bal_sortie;
• TRUNCATE consultation_specialisee;
• TRUNCATE cotation;
• TRUNCATE patients_adjuvants;
• TRUNCATE patients_actions;
• TRUNCATE patients_alertes;
• TRUNCATE patients_cache;
• TRUNCATE patients_editions;
• TRUNCATE patients_examens;
• TRUNCATE patients_examenscomm;
• TRUNCATE patients_histologs;
• TRUNCATE patients_medicaments;
• TRUNCATE patients_soins;
• TRUNCATE patients_messages;
• TRUNCATE patients_mouvements;
• TRUNCATE patients_notes;
• TRUNCATE patients_presents;
• TRUNCATE patients_radios;
• TRUNCATE patients_radioscomm;
• TRUNCATE patients_recours;
• TRUNCATE patients_sortis;
• TRUNCATE rel_cotation_actes;
• TRUNCATE rel_cotation_diags;
• TRUNCATE patients_observations;
• TRUNCATE patients_parametres_vitaux;
• TRUNCATE patients_recours;

Descriptions détaillée de certaines tables

Table patients_radios

Champ	Type	Commentaire
idradio	int(10)	autoincrement
etat	varchar(10)	a = initialisé, b = en cours, c = terminé
idpatient	int(10)	id du patient
position	varchar(32)	position du patient (Valide, Lit, Brancard, Fauteuil, Au lit du patient)
dt_creation	datetime	La date à laquelle est prévue la demande
dt_pec	datetime	Date de prise en charge de la demande
dt_fin	datetime	Date de fin de radio
type	varchar(16)	radio, scanner, echo
gauche	varchar(255)	liste des examens radio du flanc gauche séparés par |
centre	varchar(255)	liste des examens radio de face séparés par |
droit	varchar(255)	liste des examens radio du flanc droit séparés par |
controles	varchar(255)	liste des contrôles radio séparés par |
scanner	varchar(255)	liste des scanners séparés par |
echo	varchar(255)	liste des echo séparés par |
examens	varchar(255)	saisie libre
recours	varchar(255)	recours du patient (importé de la fiche patient mais en saisie libre)
prescripteur	varchar(64)	médecin qui a effectué la demande
iduser	varchar(32)	iduser de l’utilisation ayant créé la demande
date	datetime	date réelle de la saisie

Table patients_sortis

Colonne sexe: valeurs attendues M F I

Colonne valide

Cette colonne est égale à 1 par défaut. Lorsqu’un patient est supprimé, la colonne prend la valeur 0 et le patient n’apparaît plus dans la liste des sortis (voir ici).

Colonne manuel

Les patients créés manuellement ont cette colonne à 1. Une fois qu’ils sont fusionnés avec l’identité d’un patient automatique, la colonne prend la valeur 0.

Colonne attendu

Cette colonne est équivalente à la colonne manuel : le patient est créé manuellement, mais il est marqué comme étant attendu (violet). Le fonctionnement est le même que pour la colonne manuel : les patients attendus ont cette colonne à 1 et une fois qu’ils sont fusionnés avec l’identité d’un patient automatique, la colonne prend la valeur 0.

Colonne fusion

Cette colonne est à 0 par défaut. Une fois qu’un patient manuel et qu’un patient automatique sont fusionnés, la colonne du patient automatique prend la valeur 1 et ce patient n’est plus visible dans le terminal (la colonne valide devient égale à 0).

Destination confirmée (col16)

Saisie libre de la véritable destination du patient. A chaque destination, les 4 colonnes suivantes de la table sont automatiquement remplies : col17, col18, col19, col20

Mode de sortie (col17)

Les valeurs possibles sont les suivantes :

• T : Transfert (mutation vers un autre établissement)
• H : Hospitalisation (même établissement)
• D : Décès
• E : Externe
• 6 : Hospitalisation à domicile
• 7 : Structure d’hébergement médicosociale
• F : Fugue
• S : Sortie contre avis médical
• P : Partie sans attendre prise en charge
• R : Réorientation directe sans soins

Note : en version 2, il était possible de mettre également la lettre X dans cette colonne pour les erreurs d’identité. Ce fonctionnement n’est plus possible mais les anciens patients qui avaient ce type de destination sont toujours présents en base.

Cette colonne est utilisée dans le cadre du calcul du mode de sortie pour les RPU :

• H : équivalent à 6 dans les RPU : Mutation : le malade est hospitalisé vers une autre unité médicale de la même entité juridique
• T : équivalent à 7 dans les RPU : Transfert : le malade est hospitalisé dans une autre entité juridique
• E, 6, 7, F, S, P, R : équivalent à 8 dans les RPU : Domicile : le malade retourne au domicile ou son substitut (structure d’hébergement médicosociale par exemple)
• D : équivalent à 9 dans les RPU : Décès : le malade décède aux urgences

Destination (col18)

Les valeurs possibles sont les suivantes :

• 1 : MCO
• 2 : Soins de suite ou réadaptation
• 3 : Soins de longue durée
• 4 : Psychiatrie

Cette colonne est utilisée dans le cadre du calcul de la destination PMSI pour les RPU :

• Si le mode de sortie (col17) est T ou H, les codes sont envoyés directement
• Sinon, si le mode de sortie (col17) est 6 ou 7, alors le mode de sortie (col17) est envoyé dans ce cas
• Sinon, aucun code n’est envoyé

Orientation (col19)

• HDT : Hosp. sur la demande d’un tiers
• HO : Hospitalisation d’office
• SC : Surveillance continue
• SI : Soins intensifs
• REA : Réanimation
• UHCD : UHCD
• MED : Médecine hors SC, SI, REA
• CHIR : Chirurgie hors SC, SI, REA
• OBST : Obstétrique hors SC, SI, REA

UF (col20)

Cette donnée est locale à l’établissement (Unité Fonctionnelle) et n’est remplie que dans le cas d’un mode de sortie (col17) égal à H.

Motif de transfert (col21)

• Carence de lit
• Convenance personnelle
• Défaut plateau technique

Précision mode transfert (Col22)

• Ambulance privée,
• Ambulance de l’établissement,
• Moyen personnel
• Hélicoptère autre
• Hélicoptère SAMU
• SMUR
• SAMU
• VSAB

Provenance (col23)

Il s’agit de la provenance du patient (saisie libre). Cette colonne est rattachée automatiquement aux colonnes col24 (provenance PMSI), col25 (mode d’admission), col26 (transport) et col27 (prise en charge pendant le transport).

Provenance PMSI (col24)

• 1 : soins de courte durée (MCO)
• 2 : soins de suite ou de réadaptation
• 3 : Soins de longue durée
• 4 : Psychiatrie
• 5 : raisons autres que organisationnelles
• 8 : raisons organisationnelles

Mode d’admission (col25)

• 6 : mutation
• 7 : transfert
• 8 : domicile

Note : lorsque la provenance PMSI est égale à 6 ou 7, les choix du mode d’admission possible vont de 1 à 4 et lorsque la provenance PMSI est égale à 8, le choix du mode d’admission possible est 5 ou 8.

transport (col26)

• AMBU : Ambulance publique ou privée
• PERSO : Moyens personnels
• VSAB : Véhicule de secours d’aide aux blessés
• SMUR : Service Mobile d’Urgences et de Réanimation
• HELI : Hélicoptère
• FO : Forces de l’ordre

pris en charge durant le transport (col27)

• MED : Médicalisée
• PARAMED : Paramédicalisée
• AUCUN : Sans prise en charge

Opérations sur les tables

Copier les utilisateurs et les groupes d’une installation vers une autre

• les tables à copier sont les suivantes : utilisateurs, groupes, rel_utilisateur_groupe