Télécharger la production complète ( DOC )

Cahier des charges
Cahier des charges
Dossier Médical
V2.1
UTILISATION DE CE DOCUMENT
Lire attentivement les instructions suivantes avant toute rédaction.
Ce cahier des charges-type est auto-documenté. Les paragraphes en bleu italique, tels
que celui-ci, servent à documenter les paragraphes standard (en noir).
CONSEILS DE STRUCTURATION
FEUILLE DE STYLES
Ce document est structuré selon une feuille de styles qui aide la rédaction et la
maintenance. On y trouve en particulier les styles suivants :
- Normal (en noir) : paragraphe standard, utilisé pour les spécifications,
- Explications (en bleu italique) : instructions et conseils d'utilisation,
- Projet (en rouge gras) : style utilisé pour des annotations provisoires.
- Trace (en petits caractères gris) : ce style est utilisé pour maintenir des liens de
traçabilité entre exigences, ou indiquer l'origine d'une exigence (rédacteur, etc.).
Les paragraphes de style "explication", "projet" et "trace" doivent être supprimés
avant publication du cahier des charges.
NIVEAUX DE PARAGRAPHE
Les titres de 1er et 2ème niveau, et dans une large mesure les titres de 3ème niveau,
respectent tous la même structure d’un cahier des charges à l’autre. Il est important
de respecter cette structuration si l'on veut profiter des possibilités d'assemblage de
cahiers des charges-types.
ADAPTATION DU CAHIER DES CHARGES
En fonction de l’objectif visé et du périmètre pressenti, il est possible de n’utiliser
qu’une partie de ce cahier des charge-type, ou de réutiliser des parties de plusieurs
cahiers des charge-types, pour composer un cahier des charges adapté.
Les cahiers des charges-types ont été conçus pour minimiser les redondances et
incohérences dans le cas d'élaboration d'un cahier des charges par assemblage de
plusieurs cahiers des charges-types. Cependant, lors d'un tel assemblage, un travail
d'analyse et de mise en cohérence reste à faire.
Le cahier des charges doit comporter le nom du rédacteur et la date..
Remplacer le logo ANAP par le logo de votre établissement.
-1-
Cahier des charges
Table des matières
1
2
3
4
5
6
Contexte .............................................................................................................. 5
1.1
Préambule ..................................................................................................... 5
1.2
Objet de la consultation ................................................................................ 5
1.3
L’établissement de santé .............................................................................. 6
Objectifs de la solution ..................................................................................... 8
2.1
Améliorer l’efficacité de la prise en charge du patient ................................ 8
2.2
Structurer et partager les informations médicales ...................................... 9
Acteurs et utilisateurs .................................................................................... 11
3.1
Maîtrise d’ouvrage stratégique....................................................................11
3.2
Maîtrise d'ouvrage opérationnelle ...............................................................11
3.3
Autres intervenants sur le projet ................................................................12
3.4
Utilisateurs finaux.......................................................................................12
3.5
Participation des utilisateurs ......................................................................13
3.6
Utilisateurs de maintenance et de service ..................................................13
Périmètre .......................................................................................................... 14
4.1
La situation actuelle ....................................................................................14
4.2
Diagramme de contexte métier) ..................................................................14
4.3
Diagramme de cas d’utilisation ...................................................................15
Règles métier.................................................................................................... 17
5.1
Constitution et tenue du dossier du patient ...............................................17
5.2
Contenu du dossier du patient ....................................................................18
5.3
Dossier informatisé du patient ....................................................................20
5.4
Communication du dossier médical ............................................................21
5.5
Gestion des autorisations et des refus de soins ..........................................22
Cas d’utilisation ............................................................................................... 23
6.1
CU01 Paramétrer un formulaire .................................................................23
6.2
CU02 Consulter les documents du dossier médical ....................................25
6.3
CU03 Mettre à jour les données du dossier médical (Saisir, modifier,
supprimer des données médicales)...........................................................................26
7
6.4
CU04 Editer un document à partir d'un formulaire ...................................29
6.5
CU05 Valider la synthèse (consulter, compléter, valider) ..........................30
Besoins fonctionnels ....................................................................................... 33
7.1
Paramétrage ................................................................................................33
7.2
Identification du patient ..............................................................................34
7.3
Gestion des autorisations et des refus de soins ..........................................35
7.4
Dossier Médical Personnel (DMP)...............................................................36
-2-
7.5
Cahier des charges
Production clinique et médico-technique intégrées au dossier médical .....38
7.6
Diffusion des informations du dossier médical ...........................................40
7.7
Partage de la connaissance..........................................................................41
7.8
Exploitation statistique ...............................................................................42
7.9
Précision et exactitude.................................................................................42
7.10
Exigences sur les données ...........................................................................43
8
Interopérabilité et interfaces ....................................................................... 44
8.1
Interfaçage avec les progiciels existants .....................................................44
8.2
Interopérabilité ............................................................................................45
9
Exigences de qualité du produit .................................................................. 51
9.1
Sécurité ..................................................... Error! Bookmark not defined.
9.2
Facilité d’utilisation .....................................................................................51
9.3
Fiabilité ..................................................... Error! Bookmark not defined.
9.4
Rendement ...................................................................................................55
9.5
Maintenabilité .............................................................................................58
9.6
Portabilité ....................................................................................................59
10
Contraintes ....................................................................................................... 60
10.1
Faits pertinents et hypothèses ....................................................................60
10.2
Environnement physique ............................................................................60
10.3
Environnement informatique ......................................................................61
10.4
Compatibilité avec les logiciels et matériels de l’établissement .................62
10.5
Cartographie applicative .............................................................................63
10.6
Progiciels, logiciels de base et outils techniques .........................................64
11
Prestations et fournitures attendues .............. Error! Bookmark not defined.
11.1
Planning de mise en œuvre ...................... Error! Bookmark not defined.
11.2
Analyse des risques .................................. Error! Bookmark not defined.
11.3
Intégration de progiciels tiers .................. Error! Bookmark not defined.
11.4
Documentation.......................................... Error! Bookmark not defined.
11.5
Installation, mise en exploitation et généralisationError! Bookmark not
defined.
11.6
Migration .................................................. Error! Bookmark not defined.
11.7
Formation ................................................. Error! Bookmark not defined.
11.8
Maintenance ............................................. Error! Bookmark not defined.
11.9
Assistance ................................................. Error! Bookmark not defined.
11.10
Livraison des versions .............................. Error! Bookmark not defined.
11.11
Pérennité................................................... Error! Bookmark not defined.
12
Annexes ............................................................................................................. 65
12.1
Conventions de dénomination et définition des termes ..............................75
-3-
12.2
Cahier des charges
Modèle de données .......................................................................................79
12.3
ANNEXE : Marché ......................................................................................79
-4-
Cahier des charges
1 Contexte
1.1 Préambule
L’objet de cette section consiste à préciser le pourquoi de cette consultation et quelles
en sont les grandes lignes.
À titre d’exemple :
Dans le cadre de la refonte de schéma directeur du système d’information, le
[établissement de santé X] souhaite procéder au remplacement de son logiciel de
gestion du dossier médical. En effet, l’application actuellement utilisée n’est plus
satisfaisante pour des raisons d’obsolescence technique et ergonomique.
L'intégration dans le système d'information de l'établissement est un enjeu majeur.
Les grandes fonctions à informatiser sont les suivantes :
DGOS/MSIOS 28/06/2011
SI35REFV1








Paramétrage du système
Constitution du dossier médical
Consultation du dossier médical
Production de documents et intégration au dossier médical incluant la synthèse
Partage des informations patient
Production d'indicateurs et tableaux de bord pour le pilotage de l'activité
Création, alimentation et consultation du DMP
Autres fonctions : archivage, éditique
Dans ce document, le terme « système » désigne le système faisant l’objet du présent
cahier des charges.
1.2 Objet de la consultation
Cette section décrit le contenu de la consultation au sens « administratif » du terme.
Cette section décrit le contenu de la consultation au sens « administratif » du terme.
C’est ce contenu que l’on retrouve dans les différents composants du DCE (Dossier de
-5-
Cahier des charges
Consultation des Entreprises) : Règlement particulier, CCAP, CCTP ou Programme
Fonctionnel selon le type de consultation.
Pour les établissements privés, ce chapitre doit être adapté en conséquence.
Citons à titre d’exemple :
Le marché est passé sous la forme d’un marché unique décomposé comme suit :
1.2.1 Progiciels
 Acquisition de licences d’utilisation du progiciel de gestion du dossier médical
 Acquisition de licences d’outils techniques associés (le cas échéant)
 Intégration dans le système d'information existant
 Installation / paramétrage / assistance à la mise en place
 Reprise des données existantes
 Formation des personnels
 Dimensionnement du (ou des) serveur(s) applicatif(s) et pré-requis techniques
(réseau, poste de travail, imprimantes)
 Maintenance (engagement sur 5 ans)
1.2.2 Serveurs




Acquisition de serveurs.
Prestations de mise en place
Transfert de compétences
Extension de garantie / maintenance
1.2.3 Base de Données
 Acquisition d’un outil de gestion de base de données pour mettre en place la
solution
 Prestation de mise en place
 Maintenance
1.3 L’établissement de santé
Il s’agit ici de présenter l’établissement et ses principales caractéristiques.
Détailler les items les suivants :
- Dimensionnement de l’établissement de santé (nombre de lits et places)
- Découpe en établissements géographiques (le cas échéant)
- Découpe en pôles avec composition de chaque pôle (à adapter pour les
établissements privés)
- Volumétrie : Personnel médical, personnel paramédical et administratif
- Activités de l’établissement
-6-
Cahier des charges
-7-
Cahier des charges
2 Objectifs de la solution
Ce chapitre très bref expose les objectifs du système qui va être développé ou acquis.
L’élaboration de de ce chapitre exige la participation active de la direction générale
de l’établissement.
Décrire chaque objectif en trois parties
- objectif : aussi précis et concis que possible
- enjeu : doit être ciblé sur un (voire deux ou trois) acteurs ; décrire de manière précise
l’intérêt qu’a cet acteur à l’atteinte de cet objectif
- mesure de la performance
2.1 Améliorer l’efficacité de la prise en charge du patient
2.1.1 Énoncé de l’objectif
GMSIH SI32ASSIV1
HAS/DAQSS/SIPAQH
Améliorer l’efficacité de la prise en charge du patient en facilitant la coordination
des soins entre les différents professionnels de santé, en recherchant la performance
des circuits et en s’ouvrant sur la ville.
2.1.2 Bénéfices attendus
Pour un établissement de santé
 Améliorer la perception du service rendu (image de marque)
 Favoriser l'harmonisation des pratiques entre professionnels
 Constituer un support pour la formation des professionnels et l'évaluation de
leurs pratiques
 Améliorer la qualité et la sécurité de la réponse apportée au patient
 Évaluer l’activité, élément incontournable de la bonne gestion d’un
établissement, d’un service, d’une UF
Pour les professionnels de santé
-8-
Cahier des charges
 Faciliter l'accès aux données du patient et permettre de retrouver à tout moment
tous les éléments historiques concernant son parcours
 Assurer la continuité des soins entre les différents services en proposant un
dossier médical commun accessible par les différents intervenants des services lors
de la prise en charge du patient
 Permettre la traçabilité de chaque action sur son dossier (aspects médico-légaux)
 Améliorer les conditions de travail
Pour le patient
 bénéficier d’une meilleure qualité de sa prise en charge
 Faciliter l'accès à son dossier.
2.1.3 Indicateur de mesure
 Évolution du nombre de patients pris en charge (par type de prise en charge et
par mois par exemple)
 Évaluation des pratiques professionnelles et de la conformité de la tenue du
dossier patient au regard des recommandations disponibles actualisées (HAS).
 Délai d’envoi du courrier de fin d’hospitalisation
 Niveau de satisfaction des utilisateurs dans le temps
2.2 Structurer et partager les informations médicales
2.2.1 Énoncé de l’objectif
GMSIH SI32ASSIV1
DGOS 28 juin 2011
Structurer et partager les informations médicales
2.2.2 Bénéfices attendus
Pour un établissement de santé
 Produire des indicateurs dont l’exploitation facilite le pilotage de l’établissement
de santé
 Faciliter l'accès et la mise en perspective des données techniques, de gestion ou
administratives pertinentes
 Améliorer la prise de décision
 Réduire les coûts en évitant la ressaisie d'informations et les erreurs qui peuvent
en découler (ex : redondance d'examens)
Pour les professionnels de santé
 Obtenir un recueil d'informations standardisées dans un objectif de recherche ou
d'évaluation
 Aider à l’organisation des tâches journalières : aide à la saisie, aide à la décision,
optimisation des processus (workflow)
 Favoriser les échanges entre établissements, mais aussi entre les établissements
et les réseaux de soins tels que la médecine de ville, les cliniques spécialisées
Pour le patient
-9-
Cahier des charges
 Disposer d'une information claire (droit à l'information dont il bénéficie)
 Alimenter le DMP par l'ajout de documents jugés utiles pour la coordination de
ses soins
2.2.3 Indicateur de mesure
 Complétude du dossier médical dans le temps
 Satisfaction des professionnels de santé dans le temps
Si nécessaire, adapter la formulation de ces objectifs au contexte de l’établissement.
Inclure d’autres objectifs si nécessaire. Affiner la description des indicateurs si
nécessaire. S'appuyer sur le guide de l'ANAP.
- 10 -
Cahier des charges
3 Acteurs et utilisateurs
Ce chapitre est fondamental. Il devra être élaboré avec soin et validé par toutes les
parties prenantes.
La désignation des intervenants métier est basée sur le « répertoire des métiers de la
fonction publique hospitalière » (DGOS) et devra donc être adapté au contexte de
l’Établissement.
3.1 Maîtrise d’ouvrage stratégique
Modifier les titres et le nom des instances en fonction de votre établissement.
Dans certains établissements, en particulier les petits établissements, la même
personne peut jouer le rôle de maitrise d’ouvrage stratégique et opérationnelle.
L’expression « Maîtrise d’ouvrage stratégique » équivaut à « donneur d’ordres » ou
« pouvoir adjudicateur ». Remplacer si nécessaire, sans modifier l’ordre des
paragraphes.
La Direction Générale de l'Établissement est la maîtrise d’ouvrage stratégique du
projet.
Elle suit le projet et est amenée à décider des grandes orientations prises lors de
certaines des réunions du directoire.
3.2 Maîtrise d'ouvrage opérationnelle
Indiquer qui sera le chef de projet opérationnel, en modifiant si nécessaire les
paragraphes suivants.
Modifier le titre de directeur des soins en fonction du titre en vigueur dans
l'établissement. Répercuter la modification dans tout le document.
Le chef de projet opérationnel a en charge la mise en place de l’informatisation des
données médicales respectueuses du parcours de soins du patient à l’aide d’un
logiciel retenu par l’établissement.
- 11 -
Cahier des charges
Il est amené à travailler de façon transversale en interne avec les différents acteurs
de l’établissement et en externe avec l’éditeur du logiciel et les partenaires
hospitaliers ayant retenu la même solution.
Pour améliorer le suivi du projet et valider les choix stratégiques, il est assisté dans
sa tâche par un Comité de Pilotage constitué d'un membre de chaque métier
impliqué dans le projet et de décideurs à même de rendre les arbitrages nécessaires
à la conduite du projet (allocations de ressources ou de budget, révision du périmètre
du projet, révision des délais).
 Représentants de la direction
 Représentants de la direction des soins
 Représentants du corps médical
 Représentants du service informatiques
Préciser ici, dans les grandes lignes, la composition du Comité de Pilotage envisagé.
3.3 Autres intervenants sur le projet
La réussite d’un tel projet est liée pour une grande part à la constitution d’une équipe
permanente composée d’experts métiers ; c’est ce que l'Établissement appelle les
personnes ressources ou équipe projet.
Décrire ici la composition de l’équipe « personnes ressources ».
Par exemple, pour un établissement de 200 lits :
Les autres intervenants sont
 Médecin à X % de son temps
 Secrétaire médicale à X % de son temps
 Chef de projet(s) informatique(s) Maîtrise d’œuvre à X % de son temps
3.4 Utilisateurs finaux
3.4.1 Professionnels de santé
 Médecins
3.4.2 Personnel administratif
 Secrétaires médicales
Services
Effectifs (personnes physiques)
Médecins
Secrétaires médicales
Service A
Service B
- 12 -
A compléter si besoin
Cahier des charges
Service C
Lister ici les services concernés par le projet et les effectifs par métier en remplissant
par exemple le tableau ci-dessus.
3.5 Participation des utilisateurs
Adapter, supprimer ou enrichir les paragraphes suivants en fonction des décisions
concernant le projet.
Les utilisateurs finaux du projet, hors personnes ressources, interviendront lors des
opérations de mise en place du service auquel ils sont rattachés en participant à des
groupes de travail. Ils participent au paramétrage, aux tests et à la recette.
Dans chaque service, un utilisateur référent sera formé en priorité à l’utilisation du
système et aura la charge de former et d'accompagner les utilisateurs de son service.
3.6 Utilisateurs de maintenance et de service
Modifier la liste suivante en fonction des titres en vigueur dans votre établissement.
Par exemple, responsable informatique, correspondant système d’information, etc.
Les interlocuteurs du soumissionnaire seront
 Le Directeur du système d’information ou le correspondant du Système
d'Information
 Le chef de projet informatique en charge de la mise en place et la maintenance
du système
 Le chef de projet opérationnel
- 13 -
Cahier des charges
4 Périmètre
4.1 La situation actuelle
La description de la situation actuelle sur le plan organisationnel et technique est
très importante pour la construction du futur système, puisque le candidat devra en
tenir compte pour bâtir sa réponse. Il est donc nécessaire d’analyser l’existant et de le
décrire avec soin.
Décrire ici l’organisation actuelle et les processus métiers relatifs à l’objet de la
consultation. Ne décrire que les processus impactant le projet.
4.1.1 Organisation de l'établissement
Décrire ici l’organisation actuelle de votre établissement.
L'établissement xxx est réparti sur 3 sites :
 xxx
 xxx
 xxx
4.1.2 Périmètre du dossier médical
Décrire ici le dossier médical existant :
- sa structure
- son contenu
- le processus de constitution, d'alimentation et de consultation
4.2 Diagramme de contexte métier)
Ce diagramme a pour objet d’identifier les flux d’informations entre les différents
acteurs et le système d’information.
- 14 -
Cahier des charges
Il s’agit là d’une description des frontières du système d’information, dont le
périmètre peut être plus large que le système informatique que l’on veut mettre en
place.
s
le
i ca
éd
m
s
ée
e
o
sc
mm
u
mm
ne
s
édicales
Données m
Donn
ées a
dmin
ées a
dmin
De
ce
u
s
ne
o
sc
ée
n
n
Do mptes-rendus
Co
s
Ré
su
lta
Dossier de spécialité
(réanimation …)
GAP / GAM
ma
nd
es
ts
Plateaux
techniques
ttre
s
connaissan
om
re
s-
u
nd
Le
C
Co
mp
DMP
Donn
icales
e
pt
é
nn
dossier médical
tes
-re
nd
Éléments de
mé d
nées
le s
Dossier de soins
paramédical
nn
us
t
Logiciel de
dispensation
d i ca
Do
ns
Do
nd
ie n
at
Don
s mé
tre
s
-re
sp
née
mè
es
pt
ée
Don
riptio
PMSI
Médecin
gestionnaire
de formulaires
Pa
ra
Observations
cliniques
m
nn
Pres
c
Diagnostics,
Actes
Co
Do
LAP-H
Éléments de comptes-rendus
Médecin
praticien
Bureautique
us
LAP-H = Logiciel d’aide à
la prescription hospitalier
Référentiels
Médecin
de ville
Comme précédemment vous pouvez reprendre ce diagramme tel quel ou le modifier
en fonction des besoins de votre établissement.
4.3 Diagramme de cas d’utilisation
Cette section décrit le périmètre de la solution souhaitée par l’établissement de santé.
En fonction de vos objectifs reprendre le périmètre tel quel, ou le compléter, ou
supprimer certains éléments du périmètre.
- 15 -
Cahier des charges
Préciser le périmètre sous forme de diagramme de cas d’utilisation, ou indiquer
« sans objet ». Les cas d’utilisation découlent du diagramme de contexte.
Dossier médical
Paramétrer un
formulaire
Constituer le
dossier médical
Mettre à jour les
données médicales
«uses»
Compléter les
données
«uses»
Médecin gestionnaires de formulaires
«uses»
Supprimer des
données
Modifier les
données
Consulter les
documents
Editer un document à
partir d'un formulaire
Secretaire médicale
Envoyer un document
Valider synthèse
- 16 -
Médecin praticien
Cahier des charges
5 Règles métier
Les règles métier, également appelées règles de gestion, sont des règles
organisationnelles dont dérivent des exigences. Compléter si nécessaire les chapitres
ci-dessous. Citer ici les règles de fonctionnement qui correspondent soit à la
réglementation soit à des modes de fonctionnement interne.
Compléter si nécessaire les paragraphes ci-dessous :
CSP
ANAES / Service évaluation des pratiques professionnelles - "Dossier du patient : réglementation et recommandations",
juin 2003
Article 1316-3 du Code civil
Loi n° 2002-303 du 4 mars 2002
5.1 Constitution et tenue du dossier du patient
5.1.1 Réglementation
Le décret n° 2002-637 du 29 avril 2002 confirme dans son article 9 l’obligation de
constituer un dossier pour tout patient hospitalisé ou consultant dans un
établissement de santé public ou privé. Le décret n° 2003-462 du 21 mai 2003
reprend cette obligation dans son article R. 1112-2.
Article R. 1112-2 modifié du CSP
Un dossier médical est constitué pour chaque patient hospitalisé dans un
établissement de santé public ou privé. Ce dossier contient au moins les éléments
suivants, ainsi classés :
1º Les informations formalisées recueillies lors des consultations externes
dispensées dans l'établissement, lors de l'accueil au service des urgences ou au
moment de l'admission et au cours du séjour hospitalier,…"
 Chaque pièce du dossier doit comporter l'identification du patient et chaque écrit
doit être daté et mentionner l’identité du professionnel qui l'a réalisé.
Article R. 1112-3 du CSP
"Chaque pièce du dossier est datée et comporte l'identité du patient avec son nom,
son prénom, sa date de naissance ou son numéro d'identification, ainsi que l'identité
du professionnel de santé qui a recueilli ou produit les informations."
- 17 -
Cahier des charges
 En ce qui concerne les prescriptions médicales, celles-ci doivent être horodatées
et signées par le médecin prescripteur et comporter le nom lisible du médecin.
Article R. 1112-3 du CSP
"Les prescriptions médicales sont datées avec indication de l'heure et signées ; le
nom du médecin signataire est mentionné en caractères lisibles."
5.1.2 Recommandations
 Des recommandations incitent à la constitution d'un dossier unifié du patient.
Manuel d'accréditation, critère DPA.1.b
Une politique vise à favoriser le regroupement des informations détenues pour
chaque patient dans l'établissement.
La notion de dossier unifié a pour objet de permettre à tout professionnel de santé
intervenant dans le processus de soins, d'accéder à tout moment, y compris en
urgence, à l'ensemble des informations pertinentes concernant le patient qu’il prend
en charge. Il s'agit d'un dossier regroupé et partagé.
Manuel d'accréditation (4), une référence concerne la tenue du dossier du patient :
DPA - Référence 4 -
La tenue du dossier du patient permet une gestion fiable des informations.
DPA.4.a.
Le dossier du patient comporte l’ensemble des éléments nécessaires à son
identification.
DPA.4.b.
Les responsabilités des différents intervenants (infirmier(ère)s, praticiens, internes,
secrétaires médicales, étudiants hospitaliers, autres intervenants) sur la tenue du
dossier du patient sont établies par écrit.
DPA.4.c.
Les prescriptions médicales sont rédigées par le praticien prescripteur, datées, et
comportent le nom et la signature du praticien.
DPA.4.d.
Le dossier du patient est organisé et classé.
5.2 Contenu du dossier du patient
5.2.1 Réglementation
Article R1112-2 Modifié par Décret n°2006-119 du 6 février 2006 - art. 2 JORF 7 février 2006
Un dossier médical est constitué pour chaque patient hospitalisé dans un
établissement de santé public ou privé. Ce dossier contient au moins les éléments
suivants, ainsi classés :
1° Les informations formalisées recueillies lors des consultations externes
dispensées dans l'établissement, lors de l'accueil au service des urgences ou au
moment de l'admission et au cours du séjour hospitalier, et notamment :
a) La lettre du médecin qui est à l'origine de la consultation ou de l'admission ;
b) Les motifs d'hospitalisation ;
- 18 -
Cahier des charges
c) La recherche d'antécédents et de facteurs de risques ;
d) Les conclusions de l'évaluation clinique initiale ;
e) Le type de prise en charge prévu et les prescriptions effectuées à l'entrée ;
f) La nature des soins dispensés et les prescriptions établies lors de la consultation
externe ou du passage aux urgences ;
g) Les informations relatives à la prise en charge en cours d'hospitalisation : état
clinique, soins reçus, examens para-cliniques, notamment d'imagerie ;
h) Les informations sur la démarche médicale, adoptée dans les conditions prévues à
l'article L. 1111-4 ;
i) Le dossier d'anesthésie ;
j) Le compte rendu opératoire ou d'accouchement ;
k) Le consentement écrit du patient pour les situations où ce consentement est
requis sous cette forme par voie légale ou réglementaire ;
l) La mention des actes transfusionnels pratiqués sur le patient et, le cas échéant,
copie de la fiche d'incident transfusionnel mentionnée au deuxième alinéa de
l'article R. 1221-40 ;
m) Les éléments relatifs à la prescription médicale, à son exécution et aux examens
complémentaires ;
n) Le dossier de soins infirmiers ou, à défaut, les informations relatives aux soins
infirmiers ;
o) Les informations relatives aux soins dispensés par les autres professionnels de
santé ;
p) Les correspondances échangées entre professionnels de santé ;
q) Les directives anticipées mentionnées à l'article L. 1111-11 ou, le cas échéant, la
mention de leur existence ainsi que les coordonnées de la personne qui en est
détentrice.
2° Les informations formalisées établies à la fin du séjour. Elles comportent
notamment :
a) Le compte rendu d'hospitalisation et la lettre rédigée à l'occasion de la sortie ;
b) La prescription de sortie et les doubles d'ordonnance de sortie ;
c) Les modalités de sortie (domicile, autres structures) ;
d) La fiche de liaison infirmière ;
3° Les informations mentionnant qu'elles ont été recueillies auprès de tiers
n'intervenant pas dans la prise en charge thérapeutique ou concernant de tels tiers.
Sont seules communicables les informations énumérées aux 1° et 2°.
5.2.2 Recommandations
- 19 -
Cahier des charges
Manuel d'accréditation (4)
DPA - Référence 5 -
Le contenu du dossier du patient permet d’assurer la coordination de la prise en
charge entre professionnels et entre secteurs d’activité.
DPA.5.a.
Le dossier du patient comporte, sous l’autorité du praticien responsable, dans les
meilleurs délais après son admission, les motifs d’hospitalisation et les conclusions
de l’évaluation initiale de la situation du patient.
DPA.5.b.
Le dossier du patient comporte des informations actualisées sur l’évolution de son
état clinique et de sa prise en charge.
DPA.5.c.
Le dossier du patient permet à tout moment de connaître les traitements, les
examens et les soins reçus ou devant être reçus par le patient.
DPA.5.d.
Le dossier du patient comporte, lorsque sa prise en charge l’exige, des éléments
d’information spécialisés.
DPA.5.e.
Le dossier du patient comporte la trace de la réflexion bénéfice-risque de la stratégie
diagnostique et thérapeutique adoptée pour le patient avant chaque acte invasif.
DPA.5.f.
Le dossier du patient comporte, après sa sortie, les conclusions du séjour et les
éventuelles modalités de suivi.
DPA.5.g.
Le médecin désigné par le patient est destinataire d’un document écrit qui lui
parvient dans un délai permettant la continuité de la prise en charge.
5.3 Dossier informatisé du patient
La valeur juridique de l'écrit sous forme électronique est désormais reconnue.
Article 1316-3 du Code civil inséré par la loi n° 2000-230 du 13 mars 2000 :
L’écrit sur support électronique a la même force probante que l’écrit sur support
papier.
Le décret n° 2001- 272 du 30 mars 2001 précise les conditions de mise en œuvre de
la signature électronique.
Le droit d'accès aux informations est identique quel que soit le support du dossier à
quelques différences près qui résultent de la mise en œuvre de la loi du 6 janvier
1978. Les seuls éléments qui diffèrent du dossier papier concernent les droits du
patient et les devoirs des médecins vis-à-vis des dossiers médicaux informatisés.
Sont ainsi précisés :
 L’obligation de déclaration à la CNIL
 Le droit à l'information du patient
 Le droit à l'opposition
 Le droit à l'oubli
- 20 -
Cahier des charges
 Le droit de contestation et de rectification
 Le droit à la sécurité
5.4 Communication du dossier médical
Le dossier du patient constitué d'éléments relatifs au patient est un document qui
relève à la fois des règles du secret professionnel et du droit à la communication des
informations qu’il contient.
5.4.1 Secret professionnel
Les règles de respect du secret des informations concernant le patient sont précisées
dans l’article L. 1110-4 du CSP modifié par la loi n° 2002-303 du 4 mars 2002.
Le dossier et les informations médicales qui y sont contenues sont confidentiels et
relèvent du secret professionnel. Les informations médicales ne peuvent être
partagées qu’entre les professionnels de santé intervenant dans la prise en charge et
la continuité des soins du patient.
5.4.2 Droit à la communication du dossier du patient
Loi du 4 mars 2002 : la communication des informations contenues dans le dossier
du patient peut se faire soit :
 au médecin, désigné par le patient, qui a ou non prescrit l’hospitalisation mais
qui assurera la continuité des soins ;
 au patient lui-même s'il est majeur et, de son vivant, uniquement à lui, à
l'exclusion de tout autre.
5.4.3 Bénéficiaires du droit d'accès au dossier du patient
Différentes réglementations se combinent pour permettre l'accès au dossier par le
patient lui-même, mais aussi éventuellement par son représentant légal, ses ayants
droit, certains médecins et la justice.
A son choix le demandeur obtient communication de son dossier : Soit sur
consultation sur place avec, le cas échéant, remise de copies de documents, soit par
l'envoi de copies de documents.
Le praticien communique les informations médicales au patient ou à son
représentant légal dans les règles de déontologie et aux ayants droit dans le respect
des règles du secret médical. Avant toute communication du dossier médical, le
médecin doit s’assurer de l’identité du demandeur.
La loi du 4 mars 2002 relative aux droits des malades et à la qualité du système de
santé a posé le principe de l’accès direct du patient à l’ensemble des informations de
santé le concernant et le décret du 29 avril 2002 a organisé cet accès.
 Pour la demande de communication du dossier (Article R.1111-1 du code de la
santé publique)
 Pour les modalités de communication (Article R.1111-2 du code de la santé
publique)
- 21 -
Cahier des charges
 Pour l'accès par les ayants droits (Article R.1111-7 du code de la santé publique)
 Pour identifier la personne chargée de communiquer les informations du dossier
patient (Article R 1112-1 du code de la santé publique)
 Pour l'accès par le médecin désigné (Article R. 1112-4 du code de la santé
publique)
5.5 Gestion des autorisations et des refus de soins
En fonction du contexte et des besoins, ces fonctions permettent de recueillir les
autorisations relatives aux soins, actes ou traitements nécessitant l’information ou
l’accord du patient ou de son entourage. De même, en cas de refus du patient ou de
son entourage, elles permettent de gérer les décharges. (Cf. Code de la santé
publique articles Livre 1er - Titre 1er L1111-1 et suivants)
La décharge de responsabilité va au-delà du refus d’un soin ou d’une hospitalisation
vise à décharger la responsabilité de l’institution lorsqu’un patient est informé des
risques qu’il prend en refusant un acte ou traitement ou en décidant de quitter le
service contre l’avis médical et qui, malgré l’avertissement, persiste dans sa
décision.
- 22 -
Cahier des charges
6 Cas d’utilisation
Un cas d'utilisation définit une manière d'utiliser le système et permet d'en décrire
les exigences fonctionnelles. Chaque cas d'utilisation contient un ou plusieurs
scénarios qui définissent comment le système doit interagir avec les utilisateurs
(appelés ici acteurs) pour atteindre un but ou une fonction spécifique. Un acteur peut
être un humain ou un autre système externe. L’acteur principal est un humain.
Si nécessaire, enrichir les cas d’utilisation décrits. Éventuellement en ajouter.
NOTE IMPORTANTE : l’élaboration de cas d’utilisation demande un savoir-faire
spécifique. Ne pas ajouter de nouveaux cas d’utilisation sans maîtrise de cette
technique. Faire valider tout nouveau cas d’utilisation par toutes les parties
prenantes.
6.1 CU01 Paramétrer un formulaire
6.1.1 Acteur principal
Médecin référent
6.1.2 Autres parties prenantes
Médecins
6.1.3 Déclencheur
Structuration des données
6.1.4 Description
Intégrer l'ensemble des données nécessaires au bon fonctionnement du formulaire
6.1.5 Préconditions
L'utilisateur s'est identifié dans le système.
Le dossier médical a été initialisé par la GAM.
- 23 -
Cahier des charges
L'ensemble des données de référence ont été recueillies et la structure du dossier
médical a été définie.
La stratégie du paramétrage a été décidée, règles de nommage et règle de
construction des intitulés. Elle est unique pour l'ensemble de l'établissement.
6.1.6 Garanties minimales
L'ensemble des actions de l'utilisateur est tracé.
6.1.7 Garanties en cas de succès
L'ensemble des données de référence du formulaire sont saisies et le formulaire est
exploitable.
6.1.8 Flux normal
1. L'utilisateur saisit les caractéristiques du formulaire qui conditionnent son
affichage et son utilisabilité (Accès en lecture/écriture/validation, emplacement du
formulaire et modalité de recherche, affichage des réponses et classement dans le
dossier)
 Son intitulé
 Sa portée : rattachement à l'ensemble de l'établissement ou spécifique à un
service, et au niveau du patient (identité ou venue)
 Sa famille métier (médical, paramédical, social)
 Son type (mode d'utilisation)
 2. L'utilisateur élabore le contenu du formulaire et précise pour chacune des
questions qui le constituent les caractéristiques suivantes :
 Sa désignation
 Son type (numérique, liste, date, binaire, texte)
 Ses attributs (ex.: saisie obligatoire)
 Les actions qui y sont rattachées
 Le cas échéant, le référentiel associé
 3. L'utilisateur élabore la mise en forme du formulaire.
4. L'utilisateur valide le paramétrage du formulaire.
5. Le système effectue les contrôles nécessaires à la validation du paramétrage du
formulaire.
6. Le système enregistre le paramétrage du formulaire.
6.1.9 Flux alternatif
5.a. Contrôle du paramétrage du formulaire
5.a.1 le système détecte une anomalie.
5.a.2 le système signale l’anomalie.
5.a.3 l'utilisateur modifie ou confirme ou abandonne le paramétrage du formulaire.
- 24 -
Cahier des charges
6.1.10
Exceptions
6.1.11
Cas inclus
6.1.12
Fréquence d’utilisation
Régulière
6.1.13
Règles métier
6.1.14
Exigences particulières
Le système offre la possibilité de consulter, modifier et supprimer le paramétrage du
formulaire.
6.2 CU02 Consulter les documents du dossier médical
6.2.1 Acteur principal
Médecin, personnel paramédical, secrétaire médicale
6.2.2 Autres parties prenantes
Aucune
6.2.3 Déclencheur
Consultation du dossier du patient
6.2.4 Description
Prendre connaissance des différents documents produits lors de la prise en charge
du patient
6.2.5 Préconditions
L'utilisateur est identifié par le système.
Toute opposition du patient est enregistrée dans le système.
6.2.6 Garanties minimales
L'ensemble des actions de l'utilisateur est tracé.
6.2.7 Garanties en cas de succès
Affichage des documents
- 25 -
Cahier des charges
La consultation des informations est tracée dans le DPI.
6.2.8 Flux normal
Le système permet d'effectuer une recherche par patient ou par type de documents.
1 recherche par patient
1.1. L'utilisateur sélectionne le patient.
1.2. L'utilisateur indique les critères de recherche (ex : venue, type de document,
auteur).
1.3. Le système affiche les documents correspondants aux critères de recherche.
1.4. L'utilisateur sélectionne le document souhaité.
1.5. Le système affiche le document.
6.2.9 Flux alternatif
1.a. Recherche par type de document
1.a.1. L'utilisateur sélectionne le type de document.
1.a.2. L'utilisateur indique les critères de recherche (ex : patient, date de validation
du document, statut du document, auteur) et le cas d'utilisation se poursuit à l'étape
1.3.
 1.3.b Aucun document ne correspond aux critères de recherche, le système
signale à l'utilisateur que la recherche est infructueuse et le cas d'utilisation se
termine ou se poursuit à l'étape 1.
6.2.10
Exceptions
6.2.11
Cas inclus
6.2.12
Fréquence d’utilisation
Journalière
6.2.13
Règles métier
6.2.14
Exigences particulières
L'affichage des éléments s’effectuera en moins de 2 secondes.
6.3 CU03 Mettre à jour les données du dossier médical
(Saisir, modifier, supprimer des données médicales)
6.3.1 Acteur principal
- 26 -
Cahier des charges
Médecin
6.3.2 Autres parties prenantes
Néant
6.3.3 Déclencheur
Observation clinique; réalisation d'actes
6.3.4 Description
Opérations permettant de renseigner, enregistrer, supprimer des données du dossier
médical.
6.3.5 Préconditions
Le médecin est identifié.
Le système dispose des informations utiles sur le patient.
Le patient est admis ou pré admis dans l’unité.
6.3.6 Garanties minimales
L'ensemble des actions de l'utilisateur est tracé.
6.3.7 Garanties en cas de succès
Le dossier médical est mis à jour.
6.3.8 Flux normal
Saisir, modifier, supprimer des données médicales
1. L'utilisateur sélectionne le patient dans la liste des patients de l’UF de
responsabilité médicale pour lequel il souhaite renseigner, modifier ou supprimer
des données de son dossier médical.
2. L'utilisateur sélectionne les informations souhaitées.
3. Le système affiche les données choisies.
4. L'utilisateur sélectionne l'opération qu'il souhaite réaliser : saisir, modifier ou
supprimer des données.
5. L'utilisateur valide l'opération.
6. Le système effectue les contrôles nécessaires à la validation de l'opération.
7. Le système enregistre les données.
6.3.9 Flux alternatif
4.1. Saisir de nouvelles données médicales
- 27 -
Cahier des charges
4.1.1. L'utilisateur choisit d'ajouter des données.
4.1.2. Le système affiche le formulaire.
4.1.3. L'utilisateur saisit les nouvelles données, pour cela, il peut disposer
 de thésaurus existants ou personnalisés ( ex : CIM10, CCAM)
 d'une fonction reconnaissance vocale qui permet l'intégration directe des données
4.1.4. L'utilisateur valide
4.1.5. Le cas d'utilisation se poursuit à l'étape 5.
4.2. Modifier des données médicales
4.2.1. L'utilisateur choisit de modifier des données.
4.2.2. Le système affiche le formulaire de modification.
4.2.3. L'utilisateur saisit les nouvelles données et valide.
4.2.4 Le cas d'utilisation se poursuit à l'étape 5.
4.3. Supprimer des données médicales
4.3.1. L'utilisateur indique son choix de supprimer des données.
4.3.2. L'application affiche le formulaire de suppression.
4.3.4. L'utilisateur confirme son choix.
4.3.5. Le cas d'utilisation se poursuit à l'étape 5.
7.a. Contrôle de l'opération réalisée
7.a.1 Le système détecte une anomalie.
7.a.2 Le système signale l’anomalie.
7.a.3 L'utilisateur modifie ou confirme ou abandonne l'opération.
6.3.10
Exceptions
6.3.11
Cas inclus
Aucun
6.3.12
Fréquence d’utilisation
Journalière
6.3.13
Règles métier
Aucune
6.3.14
Exigences particulières
- 28 -
Cahier des charges
Néant
6.4 CU04 Editer un document à partir d'un formulaire
6.4.1 Acteur principal
Médecin
6.4.2 Autres parties prenantes
(néant)
6.4.3 Déclencheur
Sortie du patient
6.4.4 Description
Le médecin souhaite générer un document à partir des données saisies dans un
formulaire.
6.4.5 Préconditions
Le médecin est identifié.
Le formulaire est renseigné.
Un document associé au formulaire est paramétré.
6.4.6 Garanties minimales
L'ensemble des actions de l'utilisateur est tracé.
6.4.7 Garanties en cas de succès
Le document est édité.
6.4.8 Flux normal
1. L'utilisateur sélectionne le formulaire souhaité.
2. L'utilisateur demande l'édition du document.
3. Le système affiche le document.
4. L'utilisateur modifie le document.
5. Le système propose la validation (signature) et l'enregistrement du document OU
uniquement son enregistrement.
6. L'utilisateur indique son choix.
7. Le système effectue les contrôles nécessaires à la validation de l'opération.
- 29 -
Cahier des charges
8. Le système enregistre les données, met à jour le dossier médical et édite le
document.
6.4.9 Flux alternatif
4.1 L'utilisateur choisit de ne pas modifier le document
Le cas d'utilisation se poursuite en 5
8.a. Contrôle de l'opération réalisée
8.a.1 Le système détecte une anomalie.
8.a.2 Le système signale l’anomalie.
8.a.3 L'utilisateur modifie ou confirme ou abandonne l'opération.
6.4.10
Exceptions
(néant)
6.4.11
Cas inclus
(néant)
6.4.12
Fréquence d’utilisation
Journalière
6.4.13
Règles métier
6.4.14
Exigences particulières
6.5 CU05 Valider la synthèse (consulter, compléter,
valider)
6.5.1 Acteur principal
Médecin
6.5.2 Autres parties prenantes
6.5.3 Déclencheur
Sortie du patient
- 30 -
Cahier des charges
6.5.4 Description
Le médecin souhaite valider les données de la synthèse.
6.5.5 Préconditions
Le médecin est identifié.
Le patient est identifié.
La synthèse est complétée au fil de l'eau par le système.
6.5.6 Garanties minimales
L'ensemble des actions de l'utilisateur a été tracé.
6.5.7 Garanties en cas de succès
La synthèse est validée.
6.5.8 Flux normal
1. L'utilisateur sélectionne la synthèse.
2. Le système affiche les attributs de la synthèse
 Liste des diagnostics et hypothèse de diagnostics posés sur le patient
 Les problèmes en suspens
 La conclusion
 3. L'utilisateur choisit de modifier la synthèse et en demande l'enregistrement.
 4. L'utilisateur réalise les modifications et valide.
5. Le système propose la validation (signature) et l'enregistrement.
6. Le système effectue les contrôles nécessaires à la validation de l'opération.
7. Le système enregistre les données et met à jour les données.
6.5.9 Flux alternatif
3.a. L'utilisateur choisit de ne pas modifier la synthèse
Le cas d'utilisation se poursuit en 5
6.a. Contrôle de l'opération réalisée
6.a.1 Le système détecte une anomalie.
6.a.2 Le système signale l’anomalie.
6.a.3 L'utilisateur modifie ou confirme ou abandonne l'opération.
6.5.10
Exceptions
- 31 -
Cahier des charges
6.5.11
Cas inclus
6.5.12
Fréquence d’utilisation
Journalière
6.5.13
Règles métier
6.5.14
Exigences particulières
- 32 -
Cahier des charges
7 Besoins fonctionnels
Les exigences fonctionnelles constituent le cœur du cahier des charges. Elles décrivent
dans le détail ce que l’on attend du futur système.
Les exigences fonctionnelles décrites dans cette partie du document correspondent
fonctions les plus couramment exigées par les établissements de santé. Elles peuvent
être enrichies, modifiées ou supprimées en fonction du contexte, des objectifs et de la
situation de l’établissement.
7.1 Paramétrage
En cas de système administratif existant, il sera interfacé au système gestion du
dossier médical et partagera les informations relatives à la structure hospitalière et
au personnel.
7.1.1 Structure de l'établissement
Le système doit permettre de paramétrer les éléments suivants
 une ou plusieurs entités juridiques
 le ou les établissements
 les pôles d’activité clinique
 les pôles d’activité médico-technique
 les unités fonctionnelles
 les unités médicales
 les services
 les spécialités
 les plateaux techniques
 les secteurs
 les box
 les lits
Cette liste non exhaustive est donnée à titre d'exemple. Décrire précisément les
éléments de la structure en considérant les axes organisationnel, médico-économique
et géographique.
- 33 -
Cahier des charges
Le soumissionnaire détaillera les modalités de paramétrage et d’administration de
la structure. Il décrira les modalités de gestion de plusieurs centres hospitaliers au
sein d’une même structure.
Ces entités juridiques peuvent être considérées comme existantes ou virtuelles (cas
d’une mise en œuvre d’un partenariat avec une structure publique ou privée).
Le système doit permettre de paramétrer la liste des personnels, des différents
métiers avec leur affectation afin de pouvoir créer le plan d'habilitation (attribution
des droits d'accès et habilitations).
7.1.2 Organisation du dossier médical
Le soumissionnaire décrira précisément l'organisation du dossier médical, à minima
 la structuration et l'organisation des informations du dossier
 la visualisation des informations du dossier
 l'organisation des droits d'accès des utilisateurs associés aux informations du
dossier
 la gestion des thésaurus
7.2 Identification du patient
Ce chapitre précise les exigences relatives à la gestion administrative du patient dans
l'hypothèse ou l'établissement n'en dispose pas. S'il en dispose, celle-ci sera interfacée
avec le Dossier médical.
7.2.1 Recherche et consultation d’identité
Le système doit permettre de faire une recherche d’identité multicritères.
Le système doit permettre
l'identification d'un patient.
la consultation
des
informations associées
à
La recherche d’identité patient est l’étape de base pour accéder aux informations du
patient, pour les vérifier ou pour les compléter.
7.2.2 Création d'identité
Le système doit permettre de créer l'identité du patient avec l'IPP.
Le système doit permettre de saisir les traits d'identité du patient à partir d'un
document officiel (carte d'identité, passeport) et d'indiquer les informations de
délivrance du document, autorité de délivrance, date, identifiant du document.
Le système doit permettre de lire et d'enregistrer le contenu des cartes Sésame
Vitale.
Le soumissionnaire précisera et validera le type de matériel à utiliser, marque et
type de lecteur approprié. Il en précisera les conditions d'exploitation.
Le système doit permettre de calculer automatiquement l'lNS et de le stocker
comme un trait d'identité du patient au même titre que l'IPP.
- 34 -
Cahier des charges
Le système doit permettre la création d’un lien de parenté entre identités : lien mère
/ enfant.
Le système doit permettre de créer une identité provisoire.
Dans le cas d'une impossibilité de vérifier les traits à partir d'un document (par
exemple, patient inconscient), les traits du patient ne sont pas disponibles et ne
peuvent être saisis. Lors de l’arrivée du patient, celui-ci sera identifié de façon
formelle à partir d'un document officiel (Carte Vitale, carte d'identité, passeport)
Le système doit permettre de transformer l'identité provisoire en identité définitive
avec un IPP.
Le système doit permettre de fusionner l'identité provisoire avec une identité
existante avec l'IPP.
7.2.3 Admission volontaire sous X
Certains patients peuvent souhaiter conserver l’anonymat au cours de leur passage
dans un établissement de santé : accouchement sous X, VIP, personnel hospitalier…
Le système doit permettre
 pour un patient dont les traits sont saisis dans le système, d'indiquer que la
communication de l’identité à un tiers est interdite et de restreindre la
consultation de ses traits
 pour un patient dont les traits ne sont pas dans le système, mais pour lequel un
identifiant existe, de disposer d’une identité fictive
 Dans le cas d'un accouchement sous X, de supprimer le lien entre l’identité de la
mère et celle de l’enfant
7.2.4 Édition d'un support d'identification patient
Le système doit permettre d'éditer des supports d'identification du patient de
natures différentes.
Préciser les supports d'identification patient concernés (ex. : étiquettes, bracelets,
colliers, cartes).
Le système doit pouvoir exploiter les informations textuelles, graphiques (codes
barres par exemple) et la combinaison des deux.
7.3 Gestion des autorisations et des refus de soins
7.3.1 Création et mise à jour des autorisations et des refus de
soins
Fonction permettant de collecter et maintenir les informations d’autorisations ou de
refus relatives aux soins ou à la prise en charge fournies par le patient ou son
entourage dans le cadre de sa prise en charge.
Le système doit permettre la création et la mise à jour d'une autorisation ou d'un
refus de soins.
- 35 -
Cahier des charges
Le système doit permettre la création et la mise à jour d'une décharge.
7.3.2 Edition de documents liés l'autorisation ou au refus de
soins
Le système doit permettre l'édition du document d'autorisation ou de refus de soins.
Ce document devra comporter les éléments décrit dans le dictionnaire des données.
7.4 Dossier Médical Personnel (DMP)
www.dmp.gouv.fr (GIP ASIP Santé)
7.4.1 Recueil du consentement du patient
Pour créer un DMP, le consentement du patient doit être préalablement recueilli. Ce
recueil du consentement peut être réalisé par exemple à l'accueil ou aux admissions
de l'établissement ou directement par un professionnel de santé.
Le système doit permettre de recueillir le consentement du patient.
7.4.2 Création d'un DMP
La création du DMP ne peut se faire qu'en présence du patient et avec son
consentement.
Pour créer un DMP au service des admissions de l'établissement, le personnel
administratif s'authentifie avec une carte CPE individuelle ou le certificat de
personne morale de l'établissement. Bien entendu, le DMP peut également être créé
par un professionnel de santé de l'établissement.
Le logiciel de Gestion administrative des patients (GAP/GAM) doit être compatible
avec le DMP pour créer directement un DMP.
Vérifiez auprès de votre éditeur ou consultez la liste des logiciels homologués.
Le système doit permettre de lire la carte CPS d'un professionnel de santé de
l'établissement.
Le soumissionnaire précisera et validera le type de matériel à utiliser, marque et
type de lecteur approprié. Il en précisera les conditions d'exploitation.
Le système doit permettre de récupérer l'identifiant national de santé du patient à
partir de la lecture de la carte Vitale du patient.
Le système doit permettre au professionnel de santé de l'établissement autorisé par
le patient de créer son DMP.
7.4.3 Ajout de documents dans un DMP
Le système doit permettre au professionnel de santé de l'établissement autorisé par
le patient :
 d'ajouter automatiquement un document à son DMP ;
 de rendre invisible pour le patient le document ajouté à son DMP.
- 36 -
Cahier des charges
Vous pouvez juger certains documents « sensibles » et décider de les ajouter dans le
DMP en les rendant invisibles pour le patient mais accessibles pour les professionnels
de santé. Ils seront rendus visibles au patient dès lors que le professionnel de santé
l'aura informé, lors d'une consultation.
7.4.4 Gestion des documents d'un DMP
Le système doit permettre au professionnel de santé de l'établissement autorisé par
le patient de recevoir une notification à l'arrivée d'un nouveau document ajouté par
un confrère au DMP.
Le système doit permettre au professionnel de santé autorisé par le patient
d'archiver un document du DMP.
Le système doit permettre au professionnel de santé de l'établissement autorisé par
le patient d'avoir accès aux documents archivés du DMP.
Le système doit permettre au professionnel de santé de l'établissement autorisé par
le patient de rendre visible, au patient, un document de son DMP, que le PS lui
avait préalablement rendu invisible.
Le système doit permettre de masquer un document au professionnel de santé à la
demande du patient.
Le système doit permettre au professionnel de santé de l'établissement autorisé par
le patient de supprimer un document médical.
Le système ne permet pas de détruire un document déposé dans le DMP.
Cette opération ne peut être réalisée qu’à la demande du patient auprès du médecin
de l’hébergeur. Cette destruction est irréversible.
7.4.5 Consultation d'un DMP
Le système doit intégrer une matrice qui permet de définir les droits et habilitations
des utilisateurs.
Le système doit permettre au professionnel de santé de l'établissement autorisé par
le patient de rechercher un document dans son DMP.
Le système doit permettre au professionnel de santé de l'établissement autorisé par
le patient de trier les documents de son DMP.
Le système doit permettre au professionnel de santé de l'établissement autorisé par
le patient de consulter un document de son DMP.
Le système doit permettre au professionnel de santé de l'établissement autorisé par
le patient de consulter un document placé en accès réservé par un confrère dans le
DMP.
Le système doit permettre au professionnel de santé de l'établissement autorisé par
le patient de consulter un document masqué par le patient s'il en est l'auteur.
- 37 -
Cahier des charges
En cas d'urgence, le système doit permettre de pouvoir consulter le DMP en mode
"bris de glace".
Le système doit permettre au professionnel de santé de l'établissement autorisé par
le patient d'importer un document de son DMP.
7.5 Production clinique et médico-technique intégrées
au dossier médical
Les fonctions de ce chapitre ne traitent pas de la prescription au sens général de
demande de produits ou de services (médicaments, actes complémentaires, demandes
de prélèvement, etc.) à satisfaire (par soi même ou par un autre partenaire) dans le
contexte de la production de soins, au bénéfice du patient.
La prescription médicamenteuse est traitée dans le cahier des charges type du circuit
du médicament.
Concernant les documents bureautiques du patient, le soumissionnaire détaillera les
modalités d’intégration de sa solution.
Le soumissionnaire précisera le worflow relatif aux fonctions de production
documentaire.
7.5.1 Saisie des données
Le système doit permettre de saisir les données du dossier médical. Chaque donnée
saisie est horodatée et signée.
Le système doit permettre de créer une synthèse des données à partir des données
enregistrées.
Le système doit permettre d'enregistrer les données.
Le système doit permettre de valider les données.
Le système doit permettre de rendre obligatoire certaines données pour empêcher
l’enregistrement en leur absence.
Le système doit permettre de rendre obligatoire certaines données pour la clôture
d'une venue.
Le système doit permettre à l'utilisateur de consulter des données selon ses droits et
habilitations.
Le système doit permettre à l'utilisateur de modifier des données selon ses droits et
habilitations.
Le système doit permettre à l'utilisateur de supprimer des données selon ses droits
et habilitations.
Le système doit permettre de visualiser l'ensemble des actions de création,
modification et suppression des données du dossier médical.
7.5.2 Recherche d'informations médicales du patient
- 38 -
Cahier des charges
Le système doit permettre la recherche multicritères des informations du dossier
médical d'un patient.
7.5.3 Création et mise à jour d'un document
La structuration du document, les informations obligatoires ou facultatives sont
différentes selon le type de document réalisé.
Le système doit intégrer des fonctions de traitement de texte via un logiciel externe
ou via des fonctions propriétaires.
Le système doit permettre de proposer des modèles de documents par défaut.
Le système doit permettre de créer des modèles de documents.
Le système doit permettre d'associer un modèle de document
 à l’ensemble de l’établissement
 à un service
 à une spécialité
 à un médecin
 Le système doit permettre de créer un document pour un patient donné et une
venue donnée.
Le système doit permettre d'intégrer les documents créés au dossier médical d'un
patient. Cette intégration permettra de relier entre elles les actions des différents
professionnels intervenant sur un même dossier et de les tenir informés en temps
réel.
Le système doit permettre de créer un document
 depuis un document type
 sous forme de texte libre
 en intégrant des données enregistrées issues de l'ensemble du dossier patient
Le système doit permettre d'enregistrer un document en prenant en compte les
informations définies dans le dictionnaire de données.
Le système doit permettre d'attribuer un statut au document permettant son suivi
de sa dictée ou de sa saisie à son envoi. Les statuts sont les suivants
 à compléter : le document est en cours de rédaction
 à signer : le document est prêt, il doit être signé par le responsable
 à modifier : le responsable a visualisé le document et demande des modifications
au rédacteur
 à envoyer : le document a été signé par le responsable, il est prêt à être envoyé à
ses destinataires
 envoyé : le document a été envoyé à ses destinataires, il n’est plus modifiable
Le système doit permettre d’assurer le suivi des statuts de l'ensemble des courriers.
Le système doit permettre la génération automatique de documents à partir des
données enregistrées.
- 39 -
Cahier des charges
Le système doit permettre à l'utilisateur de consulter un document selon ses droits
et habilitations et selon le statut du document.
Le système doit permettre à l'utilisateur de modifier un document selon ses droits et
habilitations et selon le statut du document.
Le système doit permettre à l'utilisateur de supprimer un document selon ses droits
et habilitations et selon le statut du document.
Le système doit permettre de visualiser l'ensemble des actions de création,
modification et suppression du document.
7.5.4 Edition et envoi d'un document
Le système doit permettre d'assurer le publipostage d'un document en sélectionnant
les données enregistrées relatives au(x) destinataires ou par ajout manuel.
Le système doit permettre l'édition automatique d'un document au format papier.
Le système doit permettre l'envoi automatique d'un document par messagerie de
manière sécurisée.
Le système doit permettre d'éditer un document manuellement.
Le système doit permettre d'envoyer manuellement un document par messagerie de
manière sécurisée.
7.5.5 Recherche et de documents
Le système doit proposer différents mode de recherche de documents en prenant en
compte les différents éléments liés au patient à ses venues et aux documents.
7.5.6 Import de documents des correspondants extérieurs
Le système doit permettre l'import de documents de correspondants extérieurs.
Le système doit permettre de rattacher un document importé à un patient.
Le système doit permettre de rattacher un document importé à la venue d'un
patient.
7.5.7 Accès (ou imports) aux résultats des systèmes satellites
 Le système doit permettre l'accès aux images numérisées du serveur d’images, la
réception des examens de laboratoire, la réception d’informations provenant des
équipements biomédicaux.
7.5.8 Équipements biomédicaux
Le système doit permettre d'intégrer au dossier médical, les données des appareils
biomédicaux.
7.6 Diffusion des informations du dossier médical
- 40 -
Cahier des charges
Le système doit offrir la possibilité de paramétrer des exports compatibles avec des
réseaux de santé locaux, régionaux ou nationaux.
Le système doit permettre de reporter dans le DMP, les éléments diagnostiques et
thérapeutiques nécessaires à la coordination des soins de la personne prise en
charge.
7.7 Partage de la connaissance
Les fonctions de ce bloc permettent aux acteurs de l’établissement d’accéder de
manière efficace aux informations des bases de connaissances (i.e. les informations
non confidentielles et d’intérêt général pour les professionnels de santé dans l’exercice
de leur métier : protocoles, livret thérapeutique, recommandations de vigilances,
référentiel de codage des actes, nomenclatures diverses, etc.).
7.7.1 Recherche, consultation et édition
La mise en œuvre des ces exigences implique d’avoir précisé les bases de
connaissances présentes dans l’établissement. Ceci doit avoir été fait dans le chapitre
sur la description de l’existant. Alternativement, cette précision peut être donnée dans
les exigences qui suivent, en indiquant par exemple « … recherche dans la base
médicamenteuse X, le livret thérapeutique, etc. ».
Le système doit permettre d'effectuer une recherche multicritères d'un élément de
connaissance.
Le système doit permettre de consulter des protocoles liés aux activités médicales.
Le système doit permettre de consulter le livret thérapeutique.
A partir d'un diagnostic spécifique, le système doit permettre d'éditer pour le
patient, un document, issu de la base de connaissance, exposant les préconisations
d'hygiène de vie correspondantes.
AIDE ET ASSISTANCE
L’objet de ces fonctions est de permettre une consultation « intelligente » des éléments
de connaissance afin
- D’apprécier au mieux l’état du patient (diminution de l’incertitude) par exemple les
fonctions d’aide au diagnostic
- De faciliter le choix de la meilleure stratégie de soins ou thérapeutique, en tenant
compte également des éléments financiers (coût du traitement et alternatives)
7.7.2 Assistance au diagnostic
L’objet de cette fonction est de permettre une consultation « intelligente » des éléments
de connaissance afin d'apprécier au mieux l’état du patient (diminution de
l’incertitude).
- 41 -
Cahier des charges
Le système doit proposer un ou plusieurs diagnostic(s) à partir des réponses fournies
par l'utilisateur à une liste de questions discriminantes : symptômes identifiés,
antécédents du patient, résultats d'un examen particulier.
Le système doit permettre la présentation de la liste des codes CIM10 possibles
étant donné le diagnostic considéré.
Le système doit permettre d'identifier les examens complémentaires à mener pour
confirmer le diagnostic.
Le système doit permettre à l'utilisateur de créer son propre thésaurus.
Le système doit permettre la présentation des éléments de recommandations
associés à un diagnostic.
7.7.3 Aide au codage des actes
Le système doit permettre la présentation de la liste des codes CCAM possibles
(chaque code étant associé à une description).
Le système doit permettre la sélection et l'enregistrement d'un code.
Le système doit permettre la consultation des informations associées à un élément
codé.
Le système permet la recherche d'un acte.
Le système doit permettre à l'utilisateur de créer son propre thésaurus.
Le système doit permettre la validation du codage.
7.8 Exploitation statistique
Dans le cadre de la recherche, il est parfois nécessaire de transmettre des données
médicales des patients. Les réglementations sont désormais particulièrement
vigilantes sur la protection des données personnelles.
Le système doit permettre d'anonymiser les données du dossier médical de façon
irréversible.
Le système doit permettre d'exporter les données anonymisées extraites du dossier
médical.
Le soumissionnaire précisera le procédé d'anonymisation retenu.
Le système permet de fournir des statistiques de pilotage et de gestion pour une
période donnée, dont à minima les indicateurs de mesure de la performance de
l'efficacité de la prise en charge du patient cités au chapitre 1.b.1.
7.9 Précision et exactitude
Faire attention à la différence entre précision et exactitude (un poids au milligramme
près est plus précis qu’au kilogramme, mais pas nécessairement exact).
- 42 -
Cahier des charges
Le système doit indiquer le poids du patient en kilogrammes, arrondi au dixième.
7.10 Exigences sur les données
Ce chapitre permet, en particulier, de spécifier des formats de données.
Cette exigence peut être modifiée si l'établissement souhaite imposer un format
particulier.
Le candidat fournira un dictionnaire de données correspondant à la solution qui fera
l'objet de sa proposition.
- 43 -
Cahier des charges
8 Interopérabilité et interfaces
8.1 Interfaçage avec les progiciels existants
Le système doit reposer sur le référentiel de l'établissement constitué
 des structures et nomenclatures de l’Établissement, géographiques, de coût, de
responsabilité médicale
 de l’ensemble des annuaires et référentiels
Le soumissionnaire précisera sa capacité à s’interfacer avec ce référentiel.
Dans le cas où l'établissement dispose d'une GAP non intégrée au système qui fait
l'objet du présent cahier des charges, conserver l'exigence suivante.
8.1.1 Demi-interface avec le système de gestion administrative
du patient pour les données d’identité
Le soumissionnaire décrira comment il envisage la communication d’identité et
quelles en sont les limitations.
8.1.2 Demi-interface avec les autres volets du dossier patient
Adapter les exigences suivantes au contexte de l'établissement.
Pour accéder à des informations spécifiques du dossier patient, les dossiers de soins,
paramédical et social.
8.1.3 Demi-interface avec la prescription médicale (LAPH), le
serveur de résultats, les plateaux techniques et les
applications en charge des dossiers de spécialités
Le système doit permettre de consulter et intégrer les éléments relatifs à la
prescription médicale, à son exécution et aux examens complémentaires.
8.1.4 Demi-interface avec l'application bureautique
Adapter et modifier.
- 44 -
Cahier des charges
Le système doit permettre la génération des courriers et comptes-rendus médicaux.
Le système devra s'interfacer avec le système de dictée numérique.
Le système devra s'interfacer avec le système de reconnaissance vocale.
8.1.5 Connecteur DMP
Pour la consultation et l'alimentation du DMP.
8.1.6 Réseau Ville/Hôpital
Pour les échanges de données médicales entre praticiens hospitaliers et médecins
de ville.
8.2 Interopérabilité
La communication entre composants du système d’information est une exigence
essentielle. La notion d’interfaces entre progiciels composant le SIH global est donc
vitale pour l’Établissement.
Une interface entre 2 progiciels consiste en général à transmettre des données via un
fichier intermédiaire. On parlera donc, dans la suite de ce chapitre de demi-interface.
Pour réaliser une interface entre les progiciels A et B, A et B étant édités par des
sociétés différentes, il y aura donc réalisation :
D’une demi-interface A vers le fichier intermédiaire réalisée et maintenue par le
fournisseur du progiciel A.
D’une demi-interface fichier intermédiaire vers B réalisée et maintenue par le
fournisseur du progiciel B.
Ces demi-interfaces entre progiciels peuvent être de type « temps réel » ou de « type
tâche de fond ».
Pour chaque demi-interface faisant partie de l’offre du soumissionnaire, préciser :
- Quel est le mode de fonctionnement technique (voir ci-dessus),
- Quels sont les données ou groupes de données transmises,
- Quelle est la norme utilisée (HL7, etc. …)
- S’il y a utilisation ou non d’un EAI, ESB, ETL, Webservice
On distingue 2 catégories de demi-interfaces :
- Demi-interfaces entre progiciels proposés (le cas échéant),
- Demi-interfaces entre les progiciels faisant l’objet de la présente consultation et les
progiciels existants dans l’Établissement.
- 45 -
Cahier des charges
8.2.1 Développement des demi-interfaces entre progiciels
proposés
Si les progiciels ont été conçus par le même éditeur, ce chapitre est en général sans
objet.
Si ce n’est le cas :
Le soumissionnaire décrira les interfaces à mettre en place entre ces progiciels tant
sous l’angle technique (en particulier, la norme utilisée) que sous l’angle fonctionnel
:
 lorsque des standards sont mis en œuvre, le soumissionnaire indiquera
précisément les standards utilisés.
 lorsqu’il n’existe pas de standard, le soumissionnaire indiquera les mécanismes
utilisés.
Il précisera si ces interfaces sont déjà opérationnelles dans la configuration exacte
demandée par l’établissement de santé et si tel est le cas fournira la liste des
établissements Hospitaliers où ces interfaces sont implantées.
8.2.2 Développement des demi-interfaces avec progiciels
existants
Exigences génériques d’interfaçage
ASIP Santé (F.M.) 20/07/2011
Les exigences générales d’interopérabilité avec les progiciels de l’établissement sont,
par ordre de priorité décroissante, les suivantes :
1. des mécanismes conformes IHE, incluant les extensions nationales d’IHE France,
dans leur version la plus récente de leur déclinaison française publiée par le
représentant français d’IHE
2. les standards préconisés par la profession dans leur version la plus récente
3. des mécanismes non standard, proposés par le soumissionnaire. Dans ce dernier
cas, le soumissionnaire indiquera les standards utilisés, les mécanismes utilisés, le
format des messages utilisés et la sémantique retenue
Actuellement, le représentant français d’IHE est Interop’santé. Vérifier ce point avant
publication du cahier des charges et préciser éventuellement.
Le soumissionnaire spécifiera les mécanismes qui seront mis en œuvre pour
permettre à l’utilisateur d’accéder à des informations spécifiques du dossier patient,
notamment
 avec le logiciel de prescription d’examens XXX
 pour la récupération des données médicales (antécédents, allergies)
 pour la récupération des documents médicaux
Schéma synoptique d’interopérabilité
ASIP Santé (FM) 09/11/2011
- 46 -
Cahier des charges
Modifier le schéma ci-dessous en fonction de l’existant de votre établissement.
Dossier de
spécialité
DMP
Doc
registry
Dossier de soins
Documents
Prescriptions
XDS
ITI-57
XDS
ITI-18
Doc
admin.
Doc
repository
Bureautique
Doc
source
C.R. selon modèle
s’il en existe
CDA du CI-SIS
Logiciel de
prescription
Données médicales
CDA / CI-SIS
Analyse
pharmaceutique
Dispensation
Prescriptions
CR si modèle
de CR dans CI-SIS
XDS
ITI-41
XDS
ITI-43
Doc
consumer
Données
médicales
CDA / CI-SIS
Dispensation
Dossier médical
PDQ
ITI-21
PDC
Image
display
Serveur
d’identité
patient
PAM
ITI-30
PEC
Données médicales
CDA / CI-SIS
PAM
ITI-31
RAD-14
RAD-16
PAC-S
PDS
HPRIM XML
<evenement ServeurActes>
Demandes et résultats
d’examens
PES
GAM
PMSI
Légende :
Transaction
Flux de données
Les profils et acteurs à utiliser avec chaque logiciel du [Etablissement X] sont
décrits dans le tableau suivant
Modifier en fonction de l’existant de votre établissement.
Type de flux
Système
Acteur
système
Mouvement
GAM
PES
PAM
PEC
Identités
GAM ou serveur PDS
PAM
PDC
- 47 -
du Profil
Acteur du
médical
dossier
Cahier des charges
d’identités
Document (CR)
Bureautique
PDS
PDQ
PDC
Aucun référentiel n’est disponible à ce jour.
Si documents, se conformer aux standards CDA
du cadre d’interopérabilité de l’ASIP Santé.
Données médicales
Document (CR)
Dossier
spécialités
de Aucun référentiel n’est disponible à ce jour.
Si documents, se conformer aux standards CDA
du cadre d’interopérabilité de l’ASIP Santé.
Données médicales Dossier de soins Aucun référentiel n’est disponible à ce jour.
et documents (C.R.) paramédical
Si documents, se conformer aux standards CDA
du cadre d’interopérabilité de l’ASIP Santé.
Demandes
d’examens,
résultats d’examens
Demandes
résultats
d’examens
Alimentation
DMP
du DMP
Consultation
DMP
du DMP
et Les échanges entre les fonctions demandes et
résultats d’examens et les autres systèmes sont
largement détaillés dans le CDC type
correspondant.
Doc repository
XDS
Doc Source (DS)
Doc registry
XDS
Doc Administrator
(DA)
Doc repository
XDS
Doc Consumer (DC)
DMP
Doc registry
XDS
Doc Consumer (DC)
Création du DMP
DMP
La création du DMP ne s’appuie sur aucun
profil IHE, cependant dans le cadre
d’interopérabilité (CI-SIS) est défini un flux
normalisé pour la création du DMP.
Prescription
Logiciels
prescription
DMP
Données médicales
Données médicales
de Aucun référentiel n’est disponible à ce jour.
Si documents, se conformer aux standards CDA
du cadre d’interopérabilité de l’ASIP Santé.
Dispensation
Images
PACS
(Visualisation des
(système
images + objets
d’archivage
associés)
images)
Actes
réalisés, PMSI
diagnostics
Aucun référentiel n’est disponible à ce jour.
-
-
Image Display
-
HPRIMXML
-
des
- 48 -
Cahier des charges
Interface avec le système de gestion administrative du
patient pour les données d’identité et de mouvements.
ASIP santé (FM) 09/11/2011
Le système doit mettre en œuvre les acteurs « Patient Demographics Consumer »
(PCD) et « Patient Encounter Consumer » (PEC) des profils IHE PAM et PDQ.
Le système doit mettre en œuvre les acteurs « Patient Encounter Supplier » (PES) et
« Patient Encounter Consumer » (PEC) du profil IHE PAM.
Le soumissionnaire décrira comment il envisage la communication d’identité et
quelles en sont les limitations.
IHE PAM est le profil qui coordonne les échanges d’information relatives au patient,
complété le cas échéant par le profil IHE PDQ
Interface avec le logiciel de prescription et de dispensation
Demande d’actes ou prescription, en fonction de l’existant dans l’établissement
Interface avec le DMP
Le système doit permettre de gérer à la fois l’import de documents contenus dans le
DMP (antécédents, résumé des épisodes précédents) et son alimentation
(compléments avec l’épisode en cours). Ces actions nécessitent l’utilisation de la
carte CPS.
Le profil IHE XDS régit les échanges avec l’infrastructure de partage de documents.
Ces documents sont au format HL7 CDA.
PMSI
L’enregistrement dans le PMSI des actes réalisés et les diagnostics posés se
conforment aux standard XPRM XML.
La recommandation HPRIM XML décrit un langage XML d’échange de messages
entre acteurs de santé. Plus précisément, cette recommandation décrit le contenu et le
format de ces messages XML.
XML (eXtended Markup Language) est un standard issu du croisement de la gestion
documentaire et de l’internet. C’est un langage de description de documents, séparant
contenu, structure et présentation.
Interface avec les autres volets du Dossier Patient
Concernant le Dossier
d’interopérabilité.
de
soins,
il
n’existe
à
ce
jour
aucun
référentiel
Pour les Dossiers de spécialité, la Bureautique et les logiciels d’aide à la prescription
et à la dispensation, le partage de documents et de métadonnées associées se
conformera aux standards du CI-SIS de l’ASIP Santé (standard CDA).
- 49 -
Cahier des charges
Interface avec les demandes et résultats d'examens
Ces interfaces sont largement détaillées dans le cahier des charges-type demandes et
résultats d'examens
- 50 -
Cahier des charges
9 Exigences de qualité du
produit
Les exigences non fonctionnelles sont des exigences sur la qualité du logiciel :
- utilisabilité (facilité d’utilisation ou « ergonomie »)
- fiabilité
- rendement (temps de réponse)
- maintenabilité
- portabilité
Les exigences non fonctionnelles sont difficiles à formuler. L’établissement adaptera à
son contexte les exigences fournies dans les chapitres qui suivent.
9.1 Sécurité
9.1.1 Accès au système
L’accès au système doit se faire au moyen d’un mécanisme conforme aux
recommandations de l’ASIP Santé en matière d’accès au système par carte CPS.
Le système intègre les règles définissant la qualité des mots de passe et met en
œuvre les moyens techniques permettant de contrôler l’application de ces règles
 longueur minimale du mot de passe (8 caractères par exemple)
 pas de répétition consécutive d’un même caractère ou groupe de caractère
 utilisation à la fois des chiffres et des lettres
 utilisation à la fois des lettres minuscules et majuscules
 Le système doit intégrer les règles et procédures relatives à la gestion des
comptes utilisateurs et des mots de passe en vigueur au sein de l'établissement
Le soumissionnaire précisera sous quelles conditions le système proposé pourra
s'intégrer à une solution d’authentification unique (SSO).
DSSIS GBP 26/05/2014  REFHN V1.1 §4.5.2
- 51 -
Cahier des charges
Le système est conforme aux exigences spécifiées dans les documents suivants :
 GSSI-S : Politique générale de sécurité des systèmes d’information de santé :
Règles pour les interventions à distance sur les Systèmes d’Information de Santé
(SIS) « ASIP Santé / Pôle Technique et Sécurité »
 PGSSI-S : Politique générale de sécurité des systèmes d’information de santé :
Règles pour les dispositifs connectés d’un Système d’Information de Santé (SIS) «
ASIP Santé / Pôle Technique et Sécurité »
9.1.2 Intégrité
Le système doit disposer d’outils permettant la non altération des données saisies
9.1.3 Confidentialité
Dans cette section vous devez décrire les règles souhaitées d’accès aux données par les
utilisateurs autrement dit ce que l’on appelle le Plan d’Habilitation.
Dans ce plan d’habilitation doivent figurer :
L’accès administrateur
Les règles d’accès au paramétrage en fonction des types de paramètres.
Par exemple : La mise à jour du plan d’habilitation peut être centralisée (DSIO) ou
décentralisée, chaque responsable métier ayant en charge la saisie des droits de sa
profession.
Exemple : DIM pour les médecins
Direction de soins infirmiers pour les soignants
Pharmacien pour la Pharmacie
L’accès aux données en création, mise à jour, suppression en fonction de profils
« métiers »
9.1.4 Piste d’audit
La traçabilité de la gestion des autorisations a pour objectif de répondre aisément
aux exigences de la CNIL et aux besoins internes d’audit et de supervision
- Quelles étaient les autorisations d’un utilisateur à un moment donné ou pendant
une période donnée ?
- Quels utilisateurs avaient accès à un élément de dossier et dans quelles conditions à
un moment donné ou pendant une période ?
- Qui a créé, modifié ou supprimé des informations, par quel moyen (manuel, batch..)
et quand ?
- Qui a créé, modifié ou supprimé des droits, par quel moyen (manuel, batch..) et
quand ?
Les traces enregistrées dans les journaux d’audit de sécurité du système doivent
comprendre au minimum
- 52 -






Cahier des charges
L’identifiant des utilisateurs
Les dates et heures d’ouvertures de sessions
La date et l’heure de l’événement
L’identification du terminal utilisé lorsque c’est possible
Les références aux traitements réalisés
La description de l’opération ou de l’événement journalisé
Ces traces devront être accessibles sur 6 mois glissants. Le soumissionnaire décrira
les besoins en matériel complémentaire et l’espace disque nécessaire.
9.1.5 Immunité
Le candidat précisera les actions prises par le système pour se protéger lui-même
des infections des programmes non autorisés ou indésirables comme par exemple les
virus, les vers, les chevaux de Troie.
9.1.6 Innocuité
Concernant l’accès au système, le système devra respecter les contraintes édictées
dans le décret de confidentialité du 15 mai 2007.
9.2 Facilité d’utilisation
9.2.1 Facilité d’apprentissage
Une formation initiale de xx heures doit être suffisante à l’appropriation des
fonctions d’utilisation pour yy % des médecins.
9.2.2 Facilité d’utilisation en usage courant
Après trois semaines d’utilisation, au moins 60 % des médecins interrogés devront
se déclarer « faire confiance au système ».
Les 7 paragraphes suivants correspondent aux 7 caractéristiques de la norme Afnor
Z-67 133-1 sur l’ergonomie du logiciel.
9.2.3 Compatibilité
La Compatibilité est la capacité à s’intégrer dans l’activité des utilisateurs.
L’ensemble des informations affichées à l’écran par le système, devront l’être en
cohérence avec les autres supports de travail des utilisateurs.
Le système doit utiliser les terminologies des métiers en vigueur dans les
établissements de santé aussi bien au niveau de l’identification que du titre de la
personne.
9.2.4 Guidage
Le guidage est l'ensemble des moyens mis en œuvre pour conseiller, orienter, informer
et conduire l'utilisateur lors de ses interactions sur son poste de travail.
- 53 -
Cahier des charges
Le système doit être en mesure de fournir à tout moment une aide en ligne
contextuelle. L’aide en ligne doit apporter une explication sur chaque élément
présent sur l’écran actif.
Cette aide en ligne sera mise à jour parallèlement aux mises à jour du logiciel.
Une identification du patient concerné est visible dans chaque fenêtre de saisie ou
de visualisation de données personnelles.
9.2.5 Homogénéité
L’homogénéité est la capacité du système à conserver une logique d’usage constante
(logique de navigation).
Afin d’assurer une cohérence globale de l’interface homme/machine : la logique des
commandes doit être la même.
Les fenêtres doivent suivre le même schéma d’agencement.
La sémantique des boutons de la souris doit être constante.
Le même vocabulaire doit être utilisé pour désigner les commandes du logiciel.
9.2.6 Souplesse
La souplesse est la capacité de l’interface à s’adapter aux différentes exigences de la
tâche, aux diverses stratégies, aux habitudes et niveaux de connaissances des
différents utilisateurs.
À moins que cela ne soit imposé par la réglementation ou les bonnes pratiques en
vigueur dans la profession, le système n’impose pas à l’utilisateur d’accomplir les
tâches de son activité dans une séquence particulière.
À tout moment, l’utilisateur doit pouvoir suspendre sa saisie pour obtenir les
informations dont il a besoin sur un patient donné.
9.2.7 Contrôle explicite
Le contrôle explicite est l’ensemble des moyens du dialogue homme/machine qui
permettent à l’utilisateur de maîtriser le lancement et le déroulement des opérations
exécutées par le système informatique.
Certaines rubriques doivent pouvoir être rendues obligatoires pour la clôture du
dossier.
L'utilisateur doit être informé de la complétude du dossier d'un patient à sa sortie,
avant clôture de son dossier.
De manière à éviter le double encodage, la fonction de saisie des données doit être
unique : les données sont saisies une seule fois et sont insérées automatiquement
dans les autres modules où ces données doivent trouver place.
9.2.8 Gestion des erreurs
- 54 -
Cahier des charges
La gestion des erreurs concerne tous les moyens permettant d'une part d'éviter ou de
réduire les erreurs, et d'autre part de les corriger lorsqu'elles surviennent.
L’utilisateur doit pouvoir annuler un traitement informatique qu'il aurait demandé
ou revenir à une étape antérieure du processus.
Le système doit protéger l’utilisateur contre les erreurs en lui demandant de
confirmer les actions dont les effets sont irréversibles.
Le système doit permettre à l’utilisateur de corriger ses erreurs, en lui fournissant
des messages d’erreurs clairs.
9.2.9 Concision
La concision est l'ensemble des moyens qui, pour l’utilisateur, contribuent à la
réduction de ses activités de perception et de mémorisation et concourent à
l'augmentation de l'efficacité du dialogue.
Il doit être possible de passer facilement d'une application à l'autre à l'aide d’une
fonction d'accès dans chaque application. Le passage contextuel ou plus
généralement le changement de contexte ne donnera pas lieu à une nouvelle
identification.
Afin de faciliter le dialogue entre les différentes équipes le système n’affichera que
les informations nécessaires et n’obligera pas les utilisateurs à faire des calculs qui
pourraient être automatisés.
Ces derniers doivent pouvoir disposer d’une vision synthétique des informations
essentielles, tant au niveau individuel (patient) que plus général (unité de soin).
Lors des prises de poste, les transmissions de consignes doivent être claires et
complètes. Le soumissionnaire indiquera comment la solution proposée inclut ces
fonctionnalités.
9.3 Fiabilité
9.3.1 Disponibilité
Méthodologie et moyens de contrôle
Le candidat décrira dans son offre les moyens de contrôle intégrés dans le système
pour garantir la cohérence des données. Il devra également s’engager à corriger sous
24 heures un bug signalé par l’Etablissement pouvant induire une dégradation de la
qualité des soins (pour le patient ou pour l’organisation des équipes soignantes).
Exemple : non-conformité de la prescription médicale affichée dans le plan de soins.
Compte-tenu du caractère critique de l’application la fiabilité de l’application doit
être excellente ; en conséquence
Le candidat décrira :
- 55 -
Cahier des charges
 La méthodologie de tests mis en place pour garantir la fiabilité des nouvelles
versions
 Les outils de contrôle permettant à l’Etablissement de diagnostiquer un
problème.
Cas d’une anomalie grave
Comme une application telle l’informatisation du médicament est complexe, la
fiabilité ne peut être à 100 %. D’où :
En cas d’anomalie grave, ce dernier devra s’engager à fournir dans les 3 heures
suivant l’appel de l’Etablissement une solution de contournement, le bug devant être
corrigé dans les 24 heures comme mentionné précédemment.
Taux d’indisponibilité
L’application doit pouvoir fonctionner 24 heures sur 24 et 7 jours sur 7 avec un taux
d’indisponibilité maximal de :
 15 minutes par jour dans la période comprise entre 7 heures et 23 heures,
 30 minutes par jour dans la période comprise entre 23 heures et 7 heures,
 3 heures par an pour maintenance.
Ces chiffres doivent être revus par l’établissement. Ils sont très dépendants de votre
infrastructure matérielle.
En conséquence :
 Le candidat proposera une configuration serveurs qui permettra de garantir
cette exigence.
 Il décrira dans sa réponse, à titre d’information pour l’Établissement, les règles à
respecter en matière de réseau.
 Il s’engagera à pouvoir assurer les mises à jour de version logicielles sans arrêt
de la production.
Mise à jour à chaud et indisponibilité
REFHN V1.1 §4.2.4
Le soumissionnaire indiquera sa capacité à mettre en œuvre un système de mise à
jour à chaud.
REFHN V1.1 §4.2.4
Le soumissionnaire indiquera la procédure de mise à jour du produit sur site.
REFHN V1.1 §4.2.4
La durée maximale d’indisponibilité du produit lors d’une mise à jour sous réserve
du respect, par l’établissement, des prérequis techniques fournis par le titulaire,
sera de 4 heures entre le début de l'indisponibilité sur l’ensemble des postes de
travail de l'établissement de santé et la remise en production du premier poste de
travail utilisateur.
REFHN V1.1 §4.2.4
Le soumissionnaire indiquera s’il lui est possible, et dans quelles conditions, de
réaliser la mise à jour en dehors des heures ouvrées, à la demande du client.
- 56 -
Cahier des charges
9.3.2 Robustesse et tolérance aux pannes
En cas de panne, le système doit disposer d’une procédure dégradée.
Demande générale d’origine + demande DSSIS GBP 26-05-2014
Le soumissionnaire décrira en détail les procédures de secours et de gestion en mode
dégradé, à savoir
 Les procédures de restauration des données
 Les modalités de retour à l'état antérieur pour certains types de transactions
 La méthodologie d'arrêt d'urgence
 La méthodologie de reprise après incident
 La méthodologie de vérification de l'intégrité de l'application
 La méthodologie de vérification de l'intégrité des données
REFHN V1.1 §4.2.2




le périmètre fonctionnel du mode dégradé
les éventuelles restrictions de performance
les procédures de mise en œuvre du mode dégradé
les procédures de retour au mode nominal.
9.4 Rendement
9.4.1 Rapidité d’exécution et temps de latence
Préciser les exigences de temps de réponse attendus
- soit directement dans les use-cases (exigences particulières)
- soit dans ce paragraphe (exigences génériques)
Les temps de réponse attendus doivent être précisés par le soumissionnaire. On
spécifiera en particulier les temps de réponse suivants :
 A la connexion
 En utilisation à vide (un seul utilisateur connecté)
 En utilisation en charge
En routine (sur base de données et en fonctionnement réel), les temps de réponse
sur le poste de travail resteront dans les limites suivantes :
 Le passage d'une zone à la suivante sera inférieur à 0,2 seconde dans 98% des
cas
 Le passage d'un écran au suivant ou le changement de fonction sera inférieur à
0,5 seconde dans 98% des cas, exclusion faite des interrogations portant sur
l'ensemble ou un sous-ensemble de la base de données
 L'extraction de données portant sur l'ensemble de la base de données et sur l'un
des critères ou combinaison de critères ne devra pas excéder 10 minutes dès lors
que la période extraite est inférieure ou égale à un an
Le rafraîchissement des données incorporées dans le serveur et extraites vers les
autres systèmes interfacés se fera selon une fréquence compatible avec les pratiques
médicales en vigueur et de toute façon inférieure à 1 minute.
- 57 -
Cahier des charges
Les temps de réponse du système devront être identiques sur l’ensemble des postes
installés.
Les temps de réponse devront rester stables quel que soit le moment de la journée
où les utilisateurs y accéderont notamment lors des pics de consultation prévisibles.
Ils seront conformes aux exigences décrites ci-dessus.
Il faut avoir précisé, dans les chapitres sur l'existant le nombre d’utilisateurs
connectés en régime de croisière.
Il est entendu comme temps de réponse de connexion
 Le temps mesuré entre l’activation de l’application depuis le bureau WINDOWS
ou l’appel de l’URL sur un navigateur et l’affichage de la grille d’authentification
 Le temps mesuré entre la validation de la saisie de la grille d’authentification et
l’affichage du menu personnalisé proposé à l’utilisateur
La définition des temps de réponse sera réalisée pour un choix de transactions
spécifiées dès la mise en place du projet. Elles seront détaillées dans le cahier de
recette de chaque module. Durant la période de vérification d’aptitude et de
vérification de service régulier le scénario sera rejoué afin d’évaluer l’évolution des
performances par rapport à une mesure idéale réalisée lors de la MOM (mise en
ordre de marche).
9.4.2 Dimensionnement et performances
Le nombre de postes utilisateurs prévus est le suivant :
Présenter sous la forme d’une matrice (par service et type de poste, par exemple)
Au regard de cette volumétrie, les performances de l’application doivent être
conformes à la description du point 12a sur la rapidité d’exécution et le temps de
latence.
Le soumissionnaire indiquera le dimensionnement préconisé et la méthode de
calcul.
9.5 Maintenabilité
9.5.1 Adaptabilité
La solution proposée doit pouvoir être opérationnelle dans plusieurs
environnements techniques, afin de permettre à l’Etablissement de migrer, si
nécessaire, d’un environnement à un autre.
Le soumissionnaire décrira les différents environnements techniques possibles.
La solution devra suivre les évolutions technologiques, en terme notamment
 de systèmes d’exploitation « serveurs »
 de versions de base de données
 de navigateurs
 de norme d'interopérabilité
 d’outils bureautiques
- 58 -
Cahier des charges
9.6 Portabilité
- 59 -
Cahier des charges
10 Contraintes
Les contraintes sont des exigences au même titre que les exigences fonctionnelles ou
non fonctionnelles, mais viennent de l’extérieur du projet, et lui sont généralement
préexistantes. Elles vont peser sur la conception, la construction et l’exploitation du
système qui fait l’objet du présent cahier des charges.
10.1 Faits pertinents et hypothèses
Évoquer ici les faits qui s’imposent au système.
Citons par exemple :
L’établissement enregistre X dossiers médicaux par jour.
L'établissement produit X comptes-rendus par jour.
Les hypothèses induisent des contraintes sur le projet et le futur système. Elles
doivent donc être décrites, de manière à orienter la réponse des candidats.
Préciser ici les évolutions prévisibles de la structure ou de l’organisation de
l’établissement pour lesquelles les décisions ne sont pas encore prises
On peut, par exemple, préciser une évolution de la réglementation dont
l’établissement de santé a connaissance mais qui n’est pas encore en application.
On peut également émettre des hypothèses sur l’ordonnancement du déploiement, etc.
10.2 Environnement physique
Les postes de travail fixes sont implantés :
 A l’accueil (bureau des entrées ou bureau des admissions/consultations)
 Dans le bureau des médecins et des paramédicaux
 Dans le bureau des secrétaires médicales
 Dans les box de consultation
 Aux postes de soins (IDE)
- 60 -
Cahier des charges
Les postes de travail nomades doivent pouvoir être utilisés dans les couloirs des
unités de soins et dans les chambres des malades (sauf chambres d’isolement) et en
consultation.
L’environnement proposé devra être disponible aussi bien sur postes PC fixes que
sur terminaux mobiles (ardoises, tablettes PC) reliés par réseau sans fil.
Pour les postes de travail visualisables par un patient ou un accompagnant, les
terminaux disposés dans les salles de consultation et les postes de soins, devront
permettre d’afficher un plan anonyme.
On décrit ici l’environnement de travail des utilisateurs pour utiliser le produit.
Décrire toutes les caractéristiques de l’environnement susceptibles d’avoir un impact
sur la conception ou la mise en œuvre de la solution, ou un impact sur la manière de
travailler.
A titre d’exemple :
Les bâtiments du [Etablissement X] répondent aux normes antisismiques,
contraignant la mise en œuvre de la technologie wifi. Le système devra garantir
toutes ses fonctionnalités sans l'usage du wifi.
Ou, si le système est utilisé par des médecins dans les chambres, ou des IDE.
Le système devra être utilisé par un utilisateur debout.
RAPPEL : dans un cahier des charges, on n’indique pas de solutions. Indiquer des
contraintes. C’est au fournisseur de trouver la solution la plus adéquate.
10.3 Environnement informatique
10.3.1
Serveurs
Liste des serveurs avec système d’exploitation correspondant.
10.3.2
Environnements matériels
L’Établissement souhaite mettre en place
 Un environnement d’exploitation
 Un environnement de paramétrage et de recette
 Un environnement de formation
Compléter. Par exemple, un environnement de pré-production.
Modifier en fonction de l’environnement de l’établissement de santé. Par exemple
remplacer « souhaite mettre en place » par les environnements déjà en place pour les
autres applications.
10.3.3
Réseau
Aménager ce paragraphe en fonction des caractéristiques du réseau de l’établissement
de santé.
- 61 -
Cahier des charges
Plan du réseau
Remplir si nécessaire.
Réseau filaire
Le réseau actuel permet de disposer d’un débit de 100 Mb au niveau du poste de
travail.
Compléter.
Réseau WIFI
Le réseau WiFi fournit un débit de XXX Mbps sur un rayon de XXXX mètres en
intérieur
10.3.4
Postes de travail
Paragraphe à aménager en fonction des caractéristiques de vos postes de travail.
Nombre et types de postes
Système d’exploitation
Outils bureautique utilisés.
Préciser si l’établissement est ouvert à la possibilité d’ajouter des postes de travail.
Configuration postes fixes
Les PC actuels disposent du système d’exploitation (XXXX) et utilisent la suite
bureautique (YYYY).
Configuration postes nomades
L'établissement dispose de terminaux graphiques de type TSE ou Citrix.
Imprimantes
Conserver l'une des deux phrases suivantes en fonction de l'infrastructure de
l'établissement:
L'établissement dispose d'imprimantes réseau.
L'établissement dispose d'imprimantes connectées directement à un poste de travail.
Mentionner les imprimantes codes à barres s’il y en a ainsi que les formats
d’étiquettes édités.
Lister dans cette section les outils techniques utilisés et que l’établissement de santé
n’envisage pas de changer pour l’acquisition du système.
10.4 Compatibilité avec les logiciels et matériels de
l’établissement
- 62 -
Cahier des charges
Décrire dans cette section les contraintes techniques liées à l’utilisation du produit
dans votre établissement sur le choix de la solution, hors volet technique
informatique qui est décrit plus loin. Par exemple,
- Les travaux de câblage,
- La mise à niveau des équipements du réseau de l’établissement,
- Des problèmes techniques de connexions au réseau sans fil (déconnexions
intempestives)
Le système devra pouvoir fonctionner sur des Postes de travail ayant les
caractéristiques suivantes :
 PC portables
 PC Utilisables en bloc opératoire
 Système d’exploitation Windows
 Tablette
 Définition des écrans 1280 x 1024
Compléter ou modifier en fonction des contraintes de l’établissement de santé.
ATTENTION : chaque contrainte réduit considérablement le nombre d'offres. On
peut anticiper sur ce qui est prévu au schéma directeur sans exagérer la contrainte.
10.5 Cartographie applicative
10.5.1
Schéma
S’il est disponible, insérer ici un schéma de la cartographie applicative.
10.5.2
Liste des applications utilisées avec leur version
respective (progiciels ou applications développées en
interne)
L’Établissement dispose des applications suivantes :
 Application de gestion des personnels
 Application de gestion administrative du patient
 Dossier patient informatisé (données médicales, paramédicales et médicoéconomiques)
Compléter ou modifier
10.5.3
Interfaces ou connecteurs avec leur version
respective, existant entre ces différentes applications,
Compléter
10.5.4
Existence d’un logiciel médiateur (« middleware »)
- 63 -
Cahier des charges
Compléter et préciser s'il s'agit de logiciels de type serveur d'application, EAI, ESB,
ETL par exemple.
10.5.5
Liste des projets informatiques en cours (avec date
prévisionnelle de mise en place).
Compléter.
10.6 Progiciels, logiciels de base et outils techniques
Le système doit pouvoir fonctionner en environnement client léger (CITRIX par
exemple).
Navigateurs : si le système fonctionne pour tout ou partie en technologie WEB, le
navigateur sera compatible avec :
Indiquer ici votre choix
Le système doit permettre d'intégrer les outils de dictée numérique et de
reconnaissance vocale à la saisie des données et à l'outil bureautique.
- 64 -
Cahier des charges
11 Prestations et fournitures
attendues
11.1 Planning de mise en œuvre
11.1.1
Planning du projet
L’objet de cette section est de décrire les souhaits de l’établissement en termes de
modalités de mise en place, de découpes en phases et de planning, et de demander
aux soumissionnaires s’ils valident le planning proposé ou s’ils proposent une
solution différente.
Le planning est fonction des moyens que va mettre le soumissionnaire pour la mise en
place mais aussi des ressources propres que l’établissement va dégager pour cette
opération. Le projet risque de ne pas aboutir sans les ressources nécessaires le projet.
Voici un exemple.
Le [Etablissement X] prévoit le début de l’opération de mise en place pour le
(préciser) et souhaite que l’informatisation du dossier médical soit totalement
terminée dans un délai de [xx] mois.
La mise en place se fera par modules et service selon les jalons suivant :
Attention : toutes les étapes ne sont pas toujours nécessaires. Sélectionner celles
concernant votre établissement.
Le soumissionnaire devra proposer un planning détaillé respectant les jalons
mentionnés dans le présent cahier des charges.
T0 date de démarrage
Caractéristiques
Mise en place technique de la
solution
et
transfert
de
compétences
équipe
Opérationnel à
T0 + X mois
- 65 -
Cahier des charges
informatique (1)
T0 + X mois
Mise en ordre de marche
T0 + X mois
Reprise des données
T0 + X mois
Formation des référents aux
fonctions et au paramétrage
(2)
T0 + X mois
T0 + X mois
Assistance au Paramétrage
avec les référents (2)
T0 + X mois
Formation des utilisateurs
finaux (si nécessaire).
Démarrage
« pilotes »
des
T0 + X mois
services
T0 + X mois
Assistance au démarrage
Vérification aptitude
Vérification de service régulier
(1) Installation des applicatifs et des environnements
Le soumissionnaire prend en charge l’installation sur le (ou les) serveur(s) des
progiciels et outils techniques, sur les différents environnements cités. Il prend
également en charge, le cas échéant, l’installation sur 4 à 5 postes clients.
(2) Prise en charge du paramétrage
Le soumissionnaire livre un paramétrage par défaut.
L’établissement prend en charge les compléments de paramétrage avec une
assistance du soumissionnaire;
Dans tous les cas de figure, l’établissement assurera lui-même le paramétrage pour
les services « non pilotes » et devra être formé pour assurer les évolutions de
paramétrage une fois le projet lancé.
Il est demandé aux soumissionnaires :
 De donner un avis sur ce planning prévisionnel
 Le cas échéant, de proposer une autre solution justifiée de mise en place
 De présenter en détail sa proposition méthodologique de mise en place dans le
cadre du projet comprenant notamment l’organisation de ses ressources et le
planning de mise en œuvre
Le soumissionnaire assure la conduite du projet pour la partie maîtrise d’œuvre. Il
gère son équipe et ses ressources et s’engage à mettre en adéquation les ressources
avec la charge de travail identifiée. Il s’engage sur les dates de démarrage des
étapes et les dates de livraison et gère le planning et les ressources en conséquence.
Il analyse les incidents et propose les mesures correctives nécessaires.
- 66 -
Cahier des charges
Demande générale + demande DSSIS GBP 26/05/2014  REFHN V1.1 §4.3.3
Le prestataire fournira un PAQ (Plan d’Assurance Qualité). Ce document précisera
obligatoirement les procédures de validation et de recette applicables pendant toute
la durée du projet.
Dans le cas où plusieurs prestataires répondraient de façon groupée, il est attendu
que ceux-ci détaillent impérativement leur mode de fonctionnement, en termes de :
 gestion de projet
 travaux de conception, de réalisation, d’intégration
Le candidat présentera dans sa réponse sa méthodologie de conduite de projet.
DSSIS GBP 26/05/2014  REFHN V1.1 §4.3.4
Le titulaire met à disposition de l'établissement les outils qu'il utilise pour le
pilotage des coûts, du planning, des jalons clés et de gestion des risques
11.1.2
Planning des développements spécifiques
La réalisation de développements spécifiques doit rester limitée, car celle-ci peut
engendrer des couts de développement et de maintenance importants. Cependant
certains développements spécifiques sont incontournables.
Pour toutes les fonctions nécessitant un développement
soumissionnaire indiquera
 Les exigences fonctionnelles qui seront prises en compte
 La date de livraison de cette fonction
spécifique,
le
11.2 Analyse des risques
Tout projet comporte des risques, l’important étant de les gérer.
Il s’agit ici d’indiquer au soumissionnaire les risques propres à l’établissement qu’il
devra prendre en compte, et qui deviennent ainsi, de facto, des contraintes.
Le soumissionnaire tiendra compte des facteurs de risques suivants
 Absence d’une cartographie applicative précise et complète
 Absence de maîtrise des outils bureautiques par des utilisateurs
 Ressources peu familiarisées aux projets de cette ampleur
 Études d’organisation conduites d’une manière imprécise ou incomplète
 Manque de disponibilités des personnes ressources (utilisateurs)
 Forte proportion de personnels intérimaires
 Manque de disponibilité des matériels (serveurs)
 Circuit de décision long
 Urgence du projet
Adapter cette liste au projet et à l’environnement de l’établissement.
Il est demandé au soumissionnaire de préciser dans sa réponse les moyens qu’il
compte mettre en place pour réduire ces risques.
DSSIS GBP 26/05/2014  REFHN V1.1 §4.3.5
- 67 -
Cahier des charges
Le titulaire fournit à l'établissement une méthode d'analyse des risques qui
comporte les éléments suivants : identification des facteurs de risque en termes de
probabilité et de criticité du risque et gestion des actions de couverture des risques.
DSSIS GBP 26/05/2014  REFHN V1.1 §4.3.5
Le titulaire fournit à l'établissement un rapport d'analyse des risques établi selon la
méthode précédemment définie.
11.3 Intégration de progiciels tiers
Liste des composants externes acquis chez un fournisseur tiers intégrés à la solution
Le soumissionnaire fera la liste des progiciels acquis chez un fournisseur tiers et
qu’il intégrera à sa solution. Il est demandé aux soumissionnaires de décrire
 L’architecture générale de la solution proposée
 Le ou les système(s) d’exploitation possible(s) en précisant les versions
 Le ou les type(s) de base de données utilisables avec la version correspondante
 Les outils techniques utilisés par le système ou nécessaires pour assurer sa
maintenance
 Les outils permettant l’installation à distance de la partie client (en mode client
serveur)
 Les outils permettant le transfert du paramétrage d’un environnement à un
autre
11.4 Documentation
Rappelons que la documentation d’un système fait partie intégrante dudit système.
Le titulaire fournira la documentation technique, en français, pour chacun des
composants logiciels, dont au minimum :
 les(s) manuel(s) d'utilisation,
 les manuels d'installation, d'administration et de paramétrage,
REFHN V1.1 §4.1.8
 un document décrivant les prérequis à respecter par [l’établissement]
Indiquer le nombre d’exemplaires papier, si nécessaire.
Remarque : les fournisseurs de logiciel fournissent de plus en plus souvent la
documentation sous forme électronique en ligne. Exiger la documentation sur CDRom et a fortiori sur papier est une contrainte importante. Supprimer l’exigence
suivante si la documentation papier ne s’avère pas indispensable.
La documentation sera fournie sur CD-Rom et sur [XX] exemplaires papier.
DSSIS GBP 26/05/2014
Le guide d'installation et le guide d'exploitation ne sont pas exigées si le système est
en mode SAAS. Modifier l’exigence suivante en fonction des exigences d’architecture.
A chaque livraison d'une nouvelle version du système, le titulaire remet à
l'établissement la documentation du système mise à jour, comprenant guide
d’installation, guide d’exploitation, guide utilisateur, guide de paramétrage,
- 68 -
Cahier des charges
préconisations de l’éditeur / phase du processus, documentation d’administration des
interfaces et un document décrivant les prérequis.
La version de l’application proposée doit être intégralement en langue française
même si le système est d’une origine étrangère. Aucun mot ou texte de la langue
d’origine (si ce n’est pas le français) ne doit être visible par un utilisateur de la
solution.
DSSIS GBP 26/05/2014 §4.1.8
Le guide d'installation, le guide utilisateur et le guide de paramétrage sont rédigés
en langue française.
REFHN V1.1 §3.1
REFHN V1.1 §3.2
Le titulaire fournit une note de politique conforme au plan en annexe 5.1 du
référentiel Hôpital Numérique ainsi que l’évolution de sa politique.
11.5 Installation, mise en exploitation et généralisation
Si le cas se présente dans le cadre du projet, le décrire finement.
S’il ne s’agit que d’une « précaution » pour l’avenir, l’expliciter.
Voici quelques exemples (ils dépendent beaucoup du contexte de l’établissement de
santé) :
Le système doit pouvoir être installé sans formation particulière par un membre du
service informatique.
DSSIS GBP 26-05-2014  REFHN V1.1 §4.1.4
Pour les versions majeures, le titulaire met à disposition de l'établissement de santé
les résultats de tests réalisés sur un site pilote identifié conforme au découpage en
blocs fonctionnels selon le modèle hôpital numérique. Le rapport de tests liste les
exigences fonctionnelles vérifiées par les tests. Le rapport de tests contient
également les données du client pilote sous réserve de son accord. Dans le cas où
l'établissement est seul client du système, l’exigence du site pilote n’est pas
maintenue.
11.6 Migration
La mise en place d'un nouveau système s'accompagne souvent d'une reprise des
données. La reprise des données est un point crucial dans la réussite du projet et ne
doit pas être négligée. Elle est source de nombreuses problématiques comme
l'identification des données à migrer (source, type, format..), la volumétrie ou encore
la conversion des données.
11.6.1
Exigences de migration
La mise en place d'un nouveau système s'accompagne souvent d'une reprise des
données. La reprise des données est un point crucial dans la réussite du projet et ne
- 69 -
Cahier des charges
doit pas être négligée. Elle est source de nombreuses problématiques comme
l'identification des données à migrer (source, type, format..), la volumétrie ou encore
la conversion des données.
Un plan de test de migration devra être élaboré et proposé par le soumissionnaire.
L’ensemble des données nécessaires au bon fonctionnement du système devront être
récupérées à partir des systèmes existants.
La migration devra s’inscrire dans le calendrier de mise en œuvre de l’ensemble des
opérations.
L’offre du soumissionnaire doit intégrer la reprise de données.
Le soumissionnaire pourra proposer
 Soit une reprise de données à partir de fichiers à plat réalisés par l’établissement
(solution de base)
 Soit une prise en charge complète de l’opération de reprise de données (variante)
11.6.2
Données à migrer
Lister ici les données à migrer avec le plus de précision possible, en fonction de
l’existant de l’établissement de santé.
11.7 Formation
11.7.1
Personnel Informatique
Le titulaire sera en charge de la formation du personnel et proposera un plan de
formation adapté (nombre d'heures de formation par profil métier, organisation à
mettre en place).
Le soumissionnaire assurera les formations suivantes
 Présentation architecture technique
 Formation installation serveurs et outils techniques
 Formation exploitation
 Transfert de compétence installation postes de travail
Transfert de compétence paramétrage des applications
Noter ici le nombre de personnes à former.
REFHN V1.1 §4.3.2
Le titulaire s’engage à fournir les prestations de services nécessaires à la bonne
mise en œuvre du produit, au personnel informatique de l’établissement dans le cas
où ils ne disposeraient pas des compétences nécessaires en matière de formation,
d’installation, de mise en production, d’appui à l’exploitation du système,
d'assistance à la rédaction de documentations et d'assistance au paramétrage.
11.7.2
Utilisateurs finaux
- 70 -
Cahier des charges
Le titulaire sera en charge de la formation du personnel et proposera un plan de
formation adapté (nombre d'heures de formation par profil métier, organisation à
mettre en place).
Le soumissionnaire assurera exclusivement la formation d’un groupe de référents
sur l’ensemble du système.
Noter ici le nombre de personnes à former.
Le soumissionnaire précisera dans sa réponse s’il bénéficie du statut d’organisme de
formation agréé.
11.8 Maintenance
Le [Établissement X] attend du soumissionnaire une proposition de contrat de
maintenance, l’engagement de maintenance étant de 5 ans (modèle à joindre dans la
proposition).
Le contrat de maintenance prend effet à l’issue de la période de garantie.
Il recouvre :
 La maintenance corrective (anomalies)
 La maintenance adaptative (évolution imposée par une nouvelle version de
logiciels système : un changement d’environnement. Exemple, changement de
système d’exploitation ou de Base de données)
 La maintenance évolutive (évolution de la réglementation et évolutions
fonctionnelles décidées par un club utilisateur s’il en existe un ou par le
soumissionnaire). L’éditeur précisera le périmètre de la maintenance évolutive
Ce contrat doit préciser
 Le mode d’intervention proposé (prise de contrôle à distance par exemple)
 Les délais d’intervention en cas d’anomalies bloquantes : dont la correction doit
intervenir dans les 24 heures
 Les délais d’intervention en cas d’anomalies non bloquantes : dont la correction
peut intervenir dans la prochaine version du système
REFHN V1.1 §4.1.3
 Les clauses de confidentialité entre le titulaire et [l’établissement]
DSSIS GBP 26-05-2014  REFHN V1.1 §4.1.3
Préalablement à toute installation du système dans l'établissement, le titulaire met
à la disposition de l'établissement les jeux et les résultats des tests de bon
fonctionnement du système qu'il a réalisés sur le site de développement ainsi que
ceux réalisés sur une plate-forme hors [établissement de santé].
DSSIS GBP 26-05-2014  REFHN V1.1 §4.1.3
Préalablement à toute installation de nouvelles versions de logiciels, majeure ou
mineure, dans l'établissement, le titulaire met à la disposition de l'établissement les
jeux et les résultats des tests de non régression du système qu'il a réalisés sur le site
de développement ainsi que ceux réalisés sur une plate-forme hors [établissement de
santé].
- 71 -
Cahier des charges
REFHN V1.1 §4.1.5
Le titulaire tient à jour un registre des interventions sur le système du client en
exploitation, conservant pour chaque intervention l’identification nominative de
l'intervenant, le début, la fin et l’objet de l’intervention. Ce registre des
interventions est soit partagé en continu avec [l’établissement], soit communiqué à
[l’établissement] selon une périodicité au maximum mensuelle.
REFHN V1.1 §4.1.5
Les informations documentées encadrant la maîtrise des non conformités du
produit, imposent, avant toute correction à chaud sur le produit en exploitation chez
le client :
 dans le cas où le client dispose en local ou en mode hébergé d'une instance
spécifique du produit : une phase d'autorisation préalable par le client,
 dans le cas où le client dispose du logiciel en mode SaaS : une phase
d'information préalable au client.
L’exigence suivante, conforme au référentiel Hôpital Numérique, est une contrainte
forte pour les éditeurs de logiciel. Elle peut être adaptée, si nécessaire, en fonction du
contexte et d’autres contraintes.
DSSIS GBP 26-05-2014  REFHN V1.1§ 4.1.7
En dehors des versions corrigeant les anomalies critiques, des évolutions assurant
une compatibilité avec les évolutions de l'environnement, des évolutions satisfaisant
à des exigences de sécurité ou réglementaires, le titulaire limite le nombre de
versions annuelles mise en place à 1 versions majeure et 7 versions mineures.
Dans le cas où les développements sont réalisés par l’éditeur en développement
continu, le titulaire doit informer au préalable le client de la périodicité des
livraisons, (par exemple, livraisons mensuelles) et donner la possibilité au client
d’activer les évolutions fonctionnelles dans la version livrée.
DSSIS GBP 26-05-2014  REFHN V1.1 §2
Le titulaire établit et maintient un processus de gestion des exigences conformément
aux norme ISO 9001:2008 ISO 9001:2015 et 13485:2012
DSSIS GBP 26-05-2014
Le titulaire fournira les cahiers de test qui permettront de s'assurer que toutes les
exigences du présent cahier des charges ont été respectées.
DSSIS GBP 26-05-2014
Le titulaire s'engage sur une durée de [à compléter par l'établissement] à assurer la
maintenance préventive, curative et évolutive du système.
11.9 Assistance
Le soumissionnaire proposera un contrat d’assistance. Le contrat d’assistance de
base concerne les jours ouvrables.
Si le soumissionnaire pourra proposer un contrat de type "7 jours/7, 24h/24", il
précisera si ce contrat recouvre
 l’assistance technique
 l’assistance utilisateurs
- 72 -
Cahier des charges
 d’autres formes d’assistance
DSSIS GBP 26-05-2014
Dès qu'il a connaissance d'une nouvelle anomalie, le titulaire en informe
l'établissement en lui transmettant la liste actualisée de toutes les anomalies en
cours.
DSSIS GBP 26-05-2014
Adapter l’exigence suivante à l’établissement
Dans l'éventualité où le titulaire détecte un événement indésirable critique, il en
informe l'établissement sans délai selon les modalités [à définir par l'établissement]
11.10
Livraison des versions
Le candidat doit s’engager à adapter son système en cas d’évolution réglementaire et
livrer les versions correspondantes à la date de mise en application de ces évolutions
réglementaires.
11.11
Pérennité
11.11.1
Dépôt des codes sources
REFHN V1.1 §4.2.1
Le fournisseur indiquera si ses programmes sources sont déposés à l'APP (Agence
pour le Protection des Programmes) ou auprès d'un organisme équivalent accrédité
pour la protection des programmes, à chaque version majeure ou au moins une fois
par an.
Il précisera par quels moyens et avec quelle périodicité ces dépôts sont actualisés
auprès de cet organisme.
11.11.2
Mise à disposition du plan produit
DSSIS GBP 26-05-2014  REFHN V1.1 §4.1.1
Le titulaire met à la disposition de l'établissement un plan produit qui liste les
différentes versions distribuées du produit, et donne le prévisionnel des versions
futures. Pour chacune des versions (distribuées ou futures) le plan produit précise :

La nature de la version selon les catégories définies par l’industriel dans son
processus de modification de la conception et du développement (par exemple «
version majeure », « version mineure/intermédiaire »)
 la liste des fonctionnalités ajoutées ou modifiées par la version ;
 pour une version distribuée, la référence de la documentation de la version qui
détaille le contenu de la version ;
 la date (connue ou projetée) de libération de la version ;
 la liste des versions compatibles des logiciels tiers nécessaires à l’utilisation du
produit ;
- 73 -
Cahier des charges
Le plan produit précise pour chacun des logiciels tiers les dates prévisionnelles de
mise en service, de fin de distribution ou de commercialisation, de fin de
maintenance et de fin de support ;
Le titulaire met à disposition de [établissement] la documentation d'une version
distribuée d'un produit. Cette documentation comprend au minimum :
 la liste des fonctionnalités nouvelles ou ayant évolué, avec la documentation
afférente ;
 la liste des anomalies corrigées ;
 la date de libération de la version ;
 la liste des versions compatibles des logiciels tiers nécessaires à l’utilisation de
cette version du produit.
Le titulaire met régulièrement à jour la liste des anomalies connues sur une version
des produits livrés et la met à disposition de [l’établissement].
11.11.3
Stabilité des équipes
REFHN V1.1 §4.3.1
Le soumissionnaire indiquera les moyens qu’il compte mettre en œuvre afin de
maintenir une équipe projet stable en effectif et en compétence.
REFHN V1.1 §4.3.1
Le titulaire désignera un interlocuteur privilégié pour le client ;
REFHN V1.1 §4.3.1
Le soumissionnaire indiquera les modalités de modification de l’équipe projet et le
transfert systématique de compétences avec un objectif de qualité visant à
minimiser l'impact sur le projet pour le client ;
REFHN V1.1 §4.3.1
Le titulaire informera l’établissement préalablement à toute modification de l’équipe
projet.
- 74 -
Cahier des charges
12 Annexes
12.1 Conventions de dénomination et définition des
termes
12.1.1
Définition des termes
Défusion : séparation pour revenir à la situation antérieure à une fusion.
Document : élément constitutif du dossier du patient produit dans le cadre de son
parcours de soins.
Consentement : permission donnée par un patient pour procéder à une étude ou
une intervention spécifique.
Décharge : document produit dans le cadre d'un refus de soins, décharge la
responsabilité de l’institution lorsqu’un patient est informé des risques qu’il prend
en refusant un acte ou traitement ou en décidant de quitter le service contre l’avis
médical et qui, malgré l’avertissement, persiste dans sa décision.
Dépôt de valeurs : description de l’ensemble des valeurs matérielles, monétaires
ou autre, appartenant à un patient et dont l'établissement prend la responsabilité.
Dossier : vue sur les attributs d'une entité.
Dossier patient : dossier comprenant l'ensemble des informations médicales,
administratives, soignantes ou paramédicales nécessaires à la prise en charge et à
la continuité des soins d'un patient au sein d'une unité clinique. Ces informations
sont regroupées au sein d'un seul et unique dossier.
Dossier de spécialités : ensemble de données médicales propres à une spécialité.
Certains dossiers de spécialité nécessitent une application spécifique pour le
traitement de leurs données.
Dossier de venue : regroupement des informations du dossier patient
correspondant aux périodes comprises entre un mouvement d'entrée et un
mouvement de sortie donnés.
- 75 -
Cahier des charges
Elément de connaissance : élément de la base de connaissance regroupant les
informations non confidentielles et d’intérêt général pour les professionnels de santé
dans l’exercice de leur métier, tel que la SNOMED, le livret thérapeutique, les
recommandations de vigilances, les référentiels de codage des actes et des
diagnostics (CCAM, CIM10) et les diverses nomenclatures.
Formulaire : collecteur de données structuré de façon logique et cohérente, il
permet de faciliter la capture, l’organisation, l'affichage et la modification des
informations (données).
Fusion : combinaison d'informations hétérogènes issues de plusieurs sources.
Identifiant de venue : numéro du dossier administratif.
Identité : ensemble des données qui déterminent chaque personne.
Identité provisoire : identité en attente de vérification formelle à partir d'un
document officiel (Carte Vitale, carte d'identité, passeport).
Identité définitive : identité validée à partir d'un document officiel (Carte Vitale,
carte d'identité, passeport) avec IPP (identifiant Permanent du Patient).
Logiciel tiers : par logiciel tiers, on entend, sans que la liste soit limitative, les
systèmes d’exploitation client, les systèmes d’exploitation serveur, les systèmes de
gestion de base de données, les navigateurs, les serveurs d’application, et plus
généralement l’environnement technique nécessaire chez le client pour pouvoir
exploiter la version du produit.
Mise à jour à chaud : mise à jour d’un logiciel ou d’un système sans arrêt du
service.
Mouvement : événement qui décrit un changement dans la situation du patient
entraînant, le cas échéant, une modification dans la responsabilité de prise en
charge, dans le contexte de sa venue dans l'établissement.
Personnel paramédical : auxiliaires médicaux tels que définis par le livre III du
code de la santé publique. On peut les répartir en trois catégories : les professions de
soins (dont les IDE), les professionnels de rééducation et de réadaptation, les
professionnels médico-techniques
Plan de soins : planning détaillé de l'ensemble des événements liés à la venue d'un
patient (soins, actes, rendez-vous, mouvement, déplacement, etc.). Ce planning
permet de suivre également la réalisation ou la non réalisation des événements
programmés.
Pôle : Regroupement de spécialités médicales ou regroupement de services
administratifs
Pré-admission : permet d’organiser le séjour des patients et de définir le taux
d’occupation prévisionnelle des lits sur une période donnée en prenant en compte le
type de venue.
Prescripteur : personne autorisée à prescrire : médecin ou sage-femme
- 76 -
Cahier des charges
Protocole : description précise d'une procédure, d'un mode opératoire à suivre (à
respecter). Le protocole thérapeutique est un recueil d’indications rappelant les
examens ou les règles du traitement pour un contexte ou une pathologie donnée. Les
moyens d’explorations comme les divers traitements sont codifiés et le protocole aide
à soumettre le patient à ce qui est nécessaire tout en lui évitant ce qui est superflu.
Un protocole est un guide pour le médecin, il ne représente pas des obligations
absolues.
Synthèse : résumé qui rend compte d'un ensemble de documents produits par les
professionnels de santé ayant participé à la prise en charge d'un patient, sous une
présentation commune à l'ensemble de l'établissement.
Traits d'identité : les traits d'identité permettent de caractériser un individu.
Trois types de traits ont été définis, les traits stricts qui sont nécessaires à
l’identification mais pas toujours suffisants (par exemple : nom d’usage, nom de
famille, nom marital, prénoms, date de naissance, sexe), les traits étendus (par
exemple : alias, code commune du lieu de naissance, adresse domicile, numéro de
téléphone, nom de la mère / nom du père), et les traits complémentaires qui
améliorent l’identification d’un patient (par exemple : Informations
socioprofessionnelles, informations médicales caractéristiques, employeur, régime de
sécurité sociale, numéro d’assurance obligatoire, numéro d’assurance
complémentaire, nationalité, élément de biométrie).
UF d'hébergement : unité fonctionnelle dans laquelle le patient est hébergé.
UF de responsabilité médicale : unité fonctionnelle ayant la responsabilité
médicale du patient.
Venue : passage continu du patient dans l’établissement de santé (y compris HAD,
rétrocession, séance). Les cas de permission de sortie et de prestation interétablissement n’interrompent pas la venue.
12.1.2
Abréviations et acronymes utilisés dans le projet.
Glossaire de tous les noms, acronymes et abréviations utilisés dans le document.
Pour chaque terme, écrire une définition succincte. Les parties prenantes doivent être
d’accord sur ces définitions.
CCAM
Classification Commune des Actes Médicaux
CCAP
Cahier des Clauses Administratives Particulières
CIM
Classification Internationale des Maladies
CNIL
Commission Nationale de l'Informatique et des Libertés
CNOM
Conseil National de l’Ordre des Médecins
CCTP
Cahier des Clauses Techniques Particulières
CPS
Carte Professionnelle de Santé
CSP
Code de Santé Publique
- 77 -
Cahier des charges
DEC
Délai d’Envoi du Courrier de fin d’hospitalisation
DCE
Dossier de Consultation des Entreprises
DGOS
Direction Générale de l'Organisation des Soins
DMC
Dossier Médical Commun
DPI
Dossier Patient Informatisé
DSIO
Direction des Systèmes d'Information et de l'Organisation
Enterprise Application Integration / Enterprise Service Bus
EAI/ESB
Outils et méthodes visant à permettre les échanges entre les
applications qui ne sont pas originalement conçues pour
communiquer entre elles
ETL
Extract Transform Load
GAP
Logiciel de Gestion Administrative du Patient
HAD
Hospitalisation A Domicile
HAS
Haute Autorité de Santé
HL7 /IHE
Norme internationale et européenne destinée aux échanges de
données de santé
IDE
Infirmière Diplômée d’Etat
IMS
Identité, Mouvements et Séjours
INS-C
Identifiant National de Santé Calculé
IPP
Identifiant Permanent du Patient
MCO
Médecine Chirurgie Obstétrique
MOM
Mise en Ordre de Marche (du système)
PIE
Prestations Inter Etablissements
PMSI
Programme de Médicalisation des Systèmes d'Information
RPPS
Répertoire Partagé des Professionnels de Santé
SIH
Système d'Information Hospitalier
SSO
Single Sign On, signature unique : méthode permettant à un
utilisateur de ne procéder qu'à une seule authentification pour
accéder à plusieurs applications informatiques
UF
Unité Fonctionnelle
URL
Universal Resource Locator, désigne l'adresse complète vers une
page web, telle qu'affichée dans la barre d'adresses du
navigateur
VA
Vérification d’Aptitude
- 78 -
Cahier des charges
VSR
Vérification de Service Régulier
WI-FI
WIreless FIdelity est un ensemble de protocoles de
communication sans fil régis par les normes du groupe IEEE
802.11.
12.2 Modèle de données
Le modèle de données est une spécification des principaux éléments ou objets métiers
ou entités ou classes relatifs au système. Il permet de clarifier ce qui fait l’objet de la
construction du système, et ainsi faire apparaître des exigences qui n’avaient pas
encore été détectées.
Sauf dans le cas où l'établissement souhaite imposer un modèle de données
particulier, laisser la phrase suivante:
Le candidat fournira un modèle de données correspondant à la solution qui fera
l'objet de sa proposition.
12.3 ANNEXE : Marché
Dans cette section, on trouvera un exemple de clauses administratives spécifiques à ce
type de consultation, que l’on retrouve, dans le cas d’un établissement public, dans le
CCAP.
Les établissements privés peuvent modifier ce chapitre pour l’adapter à leurs
pratiques.
12.3.1
Documents contractuels
Le marché est constitué par les documents contractuels énumérés ci-dessous, par
ordre de priorité décroissante
 Les actes d’engagements, leurs annexes financières et le cadre de réponse signés
 Ce cahier des clauses administratives particulières signé et paraphé.
 Le programme fonctionnel signé et paraphé
 Le cahier des Clauses Administratives Générales Applicables aux marchés de
fournitures et services
 L’offre du soumissionnaire comportant entre autres un planning détaillé de mise
en place des applications, planning qui servira de base à l’élaboration des ordres
de service
Le PAQ proposé par le soumissionnaire dans son offre, sera, après choix du titulaire
du marché, formalisé conjointement avec l’établissement et deviendra un document
contractuel sous forme de cahier des charges de réalisation.
Fournir en annexe un plan-type de politique industrielle.
DSSIS GBP 26-05-2014
- 79 -
Cahier des charges
Le titulaire fournit une fois par an une version actualisée de sa politique
industrielle, rédigée selon le plan-type fourni en annexe et précisant les éventuels
cas de régression; ces derniers ne pouvant être liés qu'à l'évolution de l'écosystème.
DSSIS GBP 26-05-2014
La note de politique industrielle remise par le titulaire à l'appui de son offre
constitue une pièce contractuelle de dernier rang.
DSSIS GBP 26-05-2014
Le titulaire tient à jour un registre unique de ses interventions qu'il rend accessible
à l’établissement de santé ou qu'il envoie selon une périodicité à définir par
l'établissement.
DSSIS GBP 26-05-2014
À chaque version majeure et au minimum une fois par an le titulaire dépose les
sources du système chez un tiers de confiance parmi les suivants : INPI, APP,
SGDL,
12.3.2
Le marché
Le marché s’exécutera à partir d’émission d’ordres de service.
L’ordre de service déclinera précisément
 La désignation de la prestation demandée en référence au marché de base, aux
variantes admises et aux options (acquisition de licences, prestations, formation,
etc. …)
 Les quantités
 Le montant total H.T.
 Le taux et le montant de la T.V.A.
 Le montant total T.T.C.
 Les délais de réalisation, conformément au planning détaillé et notamment les
dates de MOM, VA, VSR (voir plus loin)
Le planning évoqué ci-dessus est celui figurant dans l’offre du titulaire et repris
dans le Plan d’Assurance Qualité.
Le Pouvoir Adjudicateur a toutefois la possibilité de modifier le planning mis dans
un ordre de service après concertation avec le titulaire du marché.
12.3.3
Modalités d’exécution de la prestation
Calendrier de réalisation
Le délai de mise en place du système doit être indiqué dans la proposition
commerciale.
La mise en place s’effectue, le cas échéant, par modules fonctionnels ; le délai
indiqué s’entend « installation et mise en ordre de marche effectués ».
Pour les prestations de maintenance les délais maxima d’intervention sont fixés ciaprès.
- 80 -
Cahier des charges
Toutes difficultés concernant les délais doivent être aussitôt signalées au Pouvoir
adjudicateur qui est seul habilité à accorder une prolongation de délai de livraison.
Les demandes éventuelles de prolongation de délai d’exécution doivent être
adressées au Pouvoir adjudicateur avant l’expiration du délai contractuel.
Lieu d’exécution de la prestation
Les développements spécifiques (interfaces, …) peuvent être réalisés dans les locaux
du titulaire.
Les prestations sont exécutées, d’une manière générale sur le site du [Etablissement
X].
Les réunions de suivi du projet se déroulent dans les locaux du [Etablissement X]
(sauf accord préalable du chef de projet de l’établissement).
Si nécessaire, ajouter ici des clauses relatives à la télémaintenance.
Réception d’un ordre de service
D’une manière générale, suite à la réception d’un ordre de service par le titulaire, le
soumissionnaire présentera en retour la liste des intervenants avec leur curriculum
vitae.
DSSIS GBP 26/05/2014
Le titulaire désigne lors de la conclusion du contrat un chef de projet qui est
l'interlocuteur unique de l'établissement pendant toute la durée du contat.
DSSIS GBP 26/05/2014
L'équipe affectée à l'exécution du marché est celle que le titulaire a désigné dans son
offre; toute modification est soumise à la validation de l'établissement et qui est
informé des modalités de transfert des compétences. En tout état de cause, le
titulaire s'engage à maintenir le même effectif et les mêmes compétences de ses
équipes tout au long du projet.
En cas de force majeure, le titulaire pourra proposer le remplacement d’un des
membres de l’équipe. Le [Etablissement X] devra donner son accord formel sur ce
remplacement.
Déroulement
Le programme fonctionnel décline le besoin fonctionnel et fixe le périmètre
technique des prestations.
En outre, à chaque étape du projet devant faire l’objet de décision ou de validation
par le [Etablissement X], les dossiers de projet établis par le titulaire seront
présentés au Chef de projet qui disposera d’un délai de 10 jours ouvrables pour
procéder à l’acceptation du dossier ou présenter au titulaire ses observations.
Sur chacune des phases, le titulaire devra préciser ses pré-requis en terme
d’équipement ou de moyens humains propres au [Etablissement X].
- 81 -
Cahier des charges
Contrôle et réception des prestations
L’exécution des prestations pourra être contrôlée à tout moment par l’établissement.
En tout état de cause, le suivi de l’avancement du projet fait l’objet de réunions
contradictoires qui se déroulent sur le site du [Etablissement X] suivant une
périodicité fixée à une réunion mensuelle minimum. A la demande des parties et en
fonction des besoins, cette périodicité pourra, le cas échéant, être modifiée en cours
d’exécution sans qu’il soit besoin d’établir un avenant.
Chaque réunion fera l’objet d’un compte rendu établi par le titulaire dans les 5 jours
suivant la tenue de la réunion. Les comptes rendus adressés au Directeur du projet
seront approuvés ou feront mention de réserves dans les 5 jours suivant leur
réception.
Vérification et admission des progiciels (applicatifs et
techniques)
Il y a en général une procédure d’admission par ordre de service.
L’admission du système s’effectue en 3 étapes. :
Installation et mise en ordre de marche de l’application
Le titulaire informe le [Etablissement X] de la date à partir de laquelle il estime que
l’application peut, dans sa version définitive, le cas échéant par module fonctionnel,
être installée et intégrée au système informatique du [Etablissement X]. La date de
début d’installation et de mise en ordre de marche est alors déterminée d’un
commun accord entre les parties au moins quinze jours avant la date envisagée.
L’installation et la mise en ordre de marche sont alors effectuées par le titulaire sur
le matériel indiqué par le [Etablissement X]. Le titulaire dispose pour réaliser ces
opérations d’un délai de 2 semaines à compter de la date de début d’installation.
La mise en ordre de marche (MOM) est constatée par un procès verbal de mise en
ordre de marche prononcé par le Pouvoir Adjudicateur et signé par les 2 parties.
La MOM est prononcée par le Pouvoir Adjudicateur au vu de :
 Installation du système conformément aux spécifications prévues dans le
programme fonctionnel
 Fourniture de la documentation fonctionnelle du système et d’une
documentation détaillée d’exploitation
 Transfert de compétences de l’équipe informatique réalisé (volet exploitation).
La MOM peut être prononcée sans réserve ou avec réserves.
Les réserves éventuelles doivent être impérativement levées avant prononciation de
la Vérification d’Aptitude (VA) (étape suivante).
Vérification d’aptitude
- 82 -
Cahier des charges
La VA a pour but de constater que l’application livrée présente les caractéristiques
techniques qui la rendent apte à remplir les fonctions précisées par le marché et par
la documentation du titulaire.
Cette constatation résulte notamment de l’exécution des programmes d’essais réalisés
par l’établissement de santé.
La VA est prononcée par le Pouvoir Adjudicateur juste avant la mise en exploitation
du système ou d’un ensemble de modules tel que décrit dans l’ordre de service. Pour
ce faire, l’ensemble des prestations de conception, développement, paramétrage de
l’application et de son environnement, de la fourniture de la documentation ainsi
que les formations ont été réalisées.
Après réalisation de tests sur les services pilotes, le [Etablissement X] rédige un
document dans lequel il précise, pour chaque fonctionnalité indiquée dans le cadre
de réponse et incluse dans l’ordre de service si celle-ci est
 Conforme
 Non conforme avec 4 niveaux d’anomalies
 Très grave
 Grave
 Tolérable
 Bénigne.
Trois situations peuvent se présenter :
1/.
Toutes les fonctionnalités sont conformes
La VA est positive et prononcée sans réserves.
2/.
Certaines fonctionnalités ont un statut non conforme avec un niveau
d’anomalies grave, tolérable, bénigne
La VA est prononcée avec réserves, toutes les réserves devant être impérativement
levées avant la prononciation de la VSR.
3/.
Il existe une anomalie très grave sur une ou plusieurs fonctionnalités
La VA est négative et le Pouvoir Adjudicateur prend une décision d’ajournement.
La décision d’ajournement de la VA est prise par le Pouvoir adjudicateur après
discussion contradictoire d’évaluation entre le [Etablissement X] et le Titulaire.
Cette décision est notifiée au titulaire par l’envoi d’un courrier recommandé avec
accusé de réception, qui précise les raisons qui ont motivé la décision.
Le [Etablissement X] fournit un tableau récapitulatif des anomalies constatées et
des problèmes devant être résolus avant la nouvelle présentation. La date de la
présentation suivante est négociée lors d’une réunion contradictoire. La durée entre
la date de notification de l’ajournement et la nouvelle présentation ne peut dépasser
10 jours ouvrables.
Seuls trois ajournements peuvent être prononcés. Si, à la suite du 4ème contrôle,
l’application ne donne pas satisfaction, le Pouvoir adjudicateur pourra notifier au
- 83 -
Cahier des charges
Titulaire une décision de rejet des prestations. Le contrat sera dénoncé suivant les
conditions du marché.
A la fin de la phase de VA
 Le Titulaire répond au document récapitulatif du [Etablissement X] en signifiant
son accord sur les anomalies éventuelles constatées et leur caractère (grave,
tolérable, bénigne) et précise le délai de modification.
 Il effectue en tant que de besoin la mise à jour de la documentation qu’il remet
au [Etablissement X].
Vérification de service régulier
La VSR a pour but de constater que l’application livrée est capable d’assurer un
service régulier dans les conditions normales d’exploitation sur les services pilotes.
La VSR débute le premier jour ouvré suivant la VA. Sa durée est de 40 jours
ouvrables. Cette durée peut être toutefois prolongée en cas d’ajournement comme
précisé ci-après.
Deux situations peuvent se présenter
 La VSR est positive. Un procès verbal sera établi. Le Pouvoir adjudicateur
dispose de 7 jours pour notifier au titulaire sa décision. Un procès verbal
d’admission est rédigé.
 La VSR est négative, le Pouvoir adjudicateur prend une décision d’ajournement.
La décision d’ajournement de la VSR est prise par le Pouvoir adjudicateur après
discussion contradictoire d’évaluation entre le [Etablissement X] et le Titulaire, par
suite à la constatation des éléments suivants :
La durée cumulée des défaillances partielles constatée sur 5 jours ouvrables
consécutifs, rendant une partie des fonctions du système inopérante, dépasse 4
heures.
Le système subit une défaillance complète, entraînant l’inaptitude du système à
accomplir toutes les fonctions requises.
Cette décision est notifiée au titulaire par l’envoi d’un courrier recommandé avec
accusé de réception, qui précise les raisons qui ont motivé la décision.
Le [Etablissement X] fournit la liste des anomalies constatées et des problèmes
devant être résolus avant la nouvelle présentation. La date de la présentation
suivante est négociée lors d’une réunion contradictoire. La durée entre la date de
notification de l’ajournement et la nouvelle présentation ne peut dépasser 10 jours
ouvrables.
Seules trois ajournements peuvent être prononcés. Si, à la suite du 4ème contrôle,
l’application ne donne pas satisfaction, le Pouvoir adjudicateur pourra notifier au
Titulaire une décision de rejet des prestations. Le contrat sera dénoncé suivant les
conditions du marché.
A la fin de la phase de VSR
- 84 -
Cahier des charges
 Le Titulaire fournit un document qui récapitule toutes les anomalies détectées
au cours de la VSR, ainsi que la suite donnée à chacune d’entre elles.
 Il effectue en tant que de besoin la mise à jour de la documentation qu’il remet
au [Etablissement X].
Période de garantie à adapter si nécessaire.
 La période de garantie commence à l’admission (signature du PV d’admission
après la VSR). Elle est de 1 an.
 A l’issue de la période de garantie, il y a application du contrat de maintenance.
Vérification et admission des interfaces
Chiffrage
REFHN V1.1 §4.4.1
Le titulaire documentera les surcoûts liés à la réalisation de connecteurs
spécifiques.
Spécifications
Le titulaire réalise les spécifications fonctionnelles.
Le [Etablissement X] validera formellement les spécifications.
Au vu du procès verbal, le titulaire pourra effectuer le développement spécifique (le
cas échéant).
Vérification d’aptitude
La vérification d’aptitude est conforme dans son principe à celle évoquée
précédemment pour l’offre progicielle.
Elle intervient d’une manière concomitante avec la VA du système associé.
Vérification de service régulier
La vérification de service régulier est conforme dans son principe à celle évoquée
précédemment pour l’offre progicielle.
Elle intervient d’une manière concomitante avec la VSR du système.
La période de garantie
Débute à l’admission (VSR positive) ; elle est de 1 an.
Au-delà de la période de garantie
Il y a application du contrat de maintenance.
REFHN V1.1 §4.2.3
Le soumissionnaire décrira formellement les services associés à cette période ainsi
que l’offre des prestations complémentaires d’évolution de la solution permettant, en
phase de garantie, de bénéficier du niveau de prestation d’un contrat de
maintenance.
- 85 -
Cahier des charges
Prestations
Pour chaque ordre de service, le titulaire effectue d’une manière mensuelle, un
relevé des prestations effectuées.
A la suite de la vérification des prestations effectuées, le Pouvoir adjudicateur
prononcera la réception, l’ajournement, la réception avec réfaction ou le rejet des
prestations.
Formation du groupe projet et référents
Ces prestations se déroulent préalablement à la phase de vérification d’aptitude.
La formation est dispensée dans les locaux du [Etablissement X].
Lors de chaque formation, le formateur fait remplir par les participants une fiche de
présence.
A l’issue de la formation, chaque participant remplit une fiche d’évaluation.
Maintenance et support technique (progiciels)
La maintenance est assurée, dans les conditions définies ci-après dès la
prononciation de la VA (positive).
La maintenance recouvre la maintenance corrective, adaptative et évolutive.
Le Titulaire s’engage à assurer la maintenance de l'application pendant une durée
minimale de 5 ans à compter de l’admission. Le marché de maintenance est
renouvelable par reconduction expresse formulée par le Pouvoir adjudicateur par
lettre recommandée avec AR 3 mois avant l’échéance annuelle.
Dans le cadre d’une application développée sur la base de modules fonctionnels
faisant chacun l’objet de décision d’admission propre, la durée de 5 ans s’entend à
compter de la décision d’admission du dernier module.
La maintenance couvre la correction de toutes les anomalies de fonctionnement (tels
les bogues ou les dysfonctionnements) qui pourraient être détectées dans les
programmes composant le logiciel, et la reconstitution des fichiers endommagés en
raison de l’anomalie. Elle couvre également les évolutions réglementaires et toutes
évolutions fonctionnelles décidées soit par le Titulaire soit sur proposition du Club
utilisateurs.
Lors de la détection d’une anomalie, le Titulaire intervient dans les délais maxima
suivants :
 24 heures maximum pour une anomalie bloquante
 5 jours ouvrables maximum pour une anomalie non bloquante
Après l’appel du [Etablissement X], confirmé par télécopie ou messagerie
électronique, il accuse réception par tout moyen (télécopie, messagerie électronique)
et choisit le moyen le plus approprié pour résoudre l’anomalie
 Dépannage téléphonique
- 86 -
Cahier des charges
 Déplacement d’un personnel qualifié. Dans ce cas, le Etablissement s’engage à
faciliter l’intervention des techniciens du Titulaire.
Chaque intervention fait l’objet d’une fiche de suivi établie par le titulaire qui
mentionne notamment la date et l’heure de la prise en compte de la demande
d’intervention de l’établissement, la nature de l’anomalie constatée et les moyens
utilisés pour la corriger. Cette fiche est transmise au Etablissement (Service
Informatique), après correction de l’anomalie.
D’autre part, le titulaire effectue, en tant que de besoin, la mise à jour de la
documentation qu’il remet dans les meilleurs délais au Etablissement.
Le titulaire assure également la mise en place d’un support technique (« hot line »),
aux conditions figurant dans sa proposition commerciale. Le support technique est
assuré dès la prononciation de la VA (positive).
Modalités de règlement
(% du montant de l’ordre de service)
Licences progiciels
40 % au vu du procès verbal de la MOM notifié sans réserves,
40 % au vu du procès verbal de vérification d’aptitude notifié sans réserves ou
réserves ne comportant aucune anomalie grave,
20 % à la signature du PV d’admission suite à la VSR.
Interfaces
80 % à l’issue du procès verbal de vérification d’aptitude notifié sans réserves ou
réserves ne comportant aucune anomalie grave,
20 % à la signature du PV d’admission suite à la VSR.
Prestations et formations
Facturation mensuelle au vu du procès verbal de réception de service fait, les
factures de prestations et formation étant différentes.
Outils techniques et base de données
100 % à la mise en ordre de marche notifiée sans réserves.
Modalités en cas de retard
Ces chiffres sont à revoir par l’établissement en fonction des règles en vigueur. Ils
sont donnés ici à titre indicatif.
Progiciels et interfaces
En cas de dépassement des délais contractuels par le titulaire – non respect des
dates de vérification d’aptitude mentionnées dans l’ordre de service – des pénalités
de retard pourront être appliquées.
- 87 -
Cahier des charges
Les pénalités de retard sont généralement comprises dans une fourchette entre 1/500
et 1/1000.
Les pénalités sont également données à titre indicatif.
Elles s’établiront à 1/1000 du montant T.T.C. de l’ordre de service par jour de retard,
avec un plafonnement à [X %] du montant TTC de l’ordre de service.
Maintenance (progiciels)
En cas de dépassement par sa faute des délais d’intervention prévus par le présent
contrat, le Titulaire encourt, sans mise en demeure préalable, une pénalité calculée
par application de la formule suivante : P = 75 euros x R
dans laquelle :
P = montant de la pénalité
R = le nombre cumulé, sur la période de maintenance considérée, des jours de retard
par rapport au délai maximum d’intervention prévu
Ces pénalités peuvent être appliquées dès la signature de la VA.
Limitation de la fréquence des versions
REFHN V1.1 §4.1.7
Les informations documentées encadrant la livraison du produit limitent les
livraisons à un client à au plus une version majeure et 7 versions intermédiaires par
an.
Restent hors de ce décompte :
 les versions corrigeant les anomalies critiques,
 les versions prenant en compte des nouvelles versions des logiciels tiers,
 les versions permettant de satisfaire à des évolutions des exigences de sécurité
ou des exigences règlementaires,
 les mises à jour de bases documentaires de référence auxquelles s’interface le
logiciel.
Cette limitation de la fréquence des livraisons de versions ne s’applique pas aux
produits dont l’évolution est gérée en développement continu sous réserve :
 d’une périodicité des livraisons fixée au préalable en accord avec le client,
 que l’initiative soit laissée au client pour l’activation des évolutions
fonctionnelles dans la version livrée.
Accès aux données
REFHN V1.1 §4.1.8
Le titulaire autorisera l'accès en lecture aux données contenues dans le système par
le client, et précisent les conditions de cet accès : fourniture du modèle de la base de
données, ou de vues, ou d’extractions. Le candidat précisera dans sa réponse les
modalités de cet accès.
- 88 -
Cahier des charges
Confidentialité des données et traçabilité des actions
menées
DSSIS GBP 26/05/2014
Le titulaire s'engage au respect de la confidentialité des informations de
l'établissement.
DSSIS GBP 26/05/2014
Le titulaire s'engage à tracer nominativement toutes les interventions de ses
équipes dans le système d'information de l'établissement.
REFHN V1.1 §4.5.1
Tout membre d’une équipe du titulaire intervenant sur le système d’information de
l’établissement signera un engagement de confidentialité engageant le titulaire, ses
employés et les éventuels sous-traitants et cotraitants, préalablement à tout accès à
ce système d'information.
REFHN V1.1 §4.5.1
Le titulaire documente, conserve et met à la disposition de l’établissement les
informations relatives aux interventions sur le système de l’établissement, en
précisant en particulier l’identité des intervenants.
- 89 -