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

Cahier des charges
Cahier des charges
Demandes et résultats d'examens
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
7
Contexte .............................................................................................................. 4
1.1
Préambule ..................................................................................................... 4
1.2
Objet de la consultation ................................................................................ 4
1.3
L’établissement de santé .............................................................................. 5
Objectifs de la solution ..................................................................................... 6
2.1
Améliorer l’efficience de la prise en charge du patient ................................ 6
2.2
Structurer et partager les informations médicales ...................................... 7
2.3
Réduire les examens redondants.................................................................. 8
Acteurs et utilisateurs ...................................................................................... 9
3.1
Maîtrise d’ouvrage stratégique..................................................................... 9
3.2
Maîtrise d'ouvrage opérationnelle ................................................................ 9
3.3
Autres intervenants sur le projet ................................................................10
3.4
Utilisateurs finaux.......................................................................................10
3.5
Participation des utilisateurs ......................................................................11
3.6
Utilisateurs de maintenance et de service ..................................................11
Périmètre .......................................................................................................... 13
4.1
La situation actuelle ....................................................................................13
4.2
Diagramme de contexte ...............................................................................16
4.3
Diagramme de cas d’utilisation ...................................................................16
Règles métier.................................................................................................... 18
5.1
Législation ...................................................................................................18
5.2
Recommandations........................................................................................19
Cas d’utilisation ............................................................................................... 23
6.1
CU01 Demander un examen .......................................................................23
6.2
CU02 Consulter des résultats d'examens de laboratoire............................25
6.3
CU03 Consulter des résultats d'examens d'imagerie .................................26
Besoins fonctionnels ....................................................................................... 28
7.1
Paramétrage ................................................................................................28
7.2
Identification du patient ..............................................................................29
7.3
Faire une demande d'examen(s) ..................................................................30
7.4
Valider une demande d'examen(s) ..............................................................33
7.5
Éditer une demande d'examen(s) et des étiquettes ....................................34
7.6
Suivi des demandes d'examen(s) .................................................................35
7.7
Recherche multicritères des demandes d'examen(s) ..................................36
7.8
Les résultats d'examens ..............................................................................36
7.9
Exploitation statistique ...............................................................................40
-2-
7.10
Cahier des charges
Précision et exactitude.................................................................................41
7.11
Exigences sur les données ...........................................................................41
8
Interopérabilité et interfaces ....................................................................... 44
8.1
Interfaçage avec progiciels existants ..........................................................44
8.2
Interopérabilité ............................................................................................45
9
Exigences de qualité du produit .................................................................. 50
9.1
Sécurité ..................................................... Error! Bookmark not defined.
9.2
Facilité d’utilisation .....................................................................................50
9.3
Fiabilité ..................................................... Error! Bookmark not defined.
9.4
Rendement ...................................................................................................54
9.5
Maintenabilité .............................................................................................57
9.6
Portabilité ....................................................................................................58
10
Contraintes ....................................................................................................... 59
10.1
Faits pertinents et hypothèses ....................................................................59
10.2
Environnement physique ............................................................................59
10.3
Environnement informatique ......................................................................60
10.4
Compatibilité avec les logiciels et matériels de l’établissement .................62
10.5
Cartographie applicative .............................................................................62
10.6
Progiciels, logiciels de base et outils techniques .........................................63
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 ............................................................................................................. 64
12.1
Conventions de dénomination et définition des termes ..............................74
12.2
Modèle de données .......................................................................................78
12.3
ANNEXE : Marché ......................................................................................79
-3-
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 [Centre
Hospitalier X] souhaite procéder au remplacement de son logiciel de demandes et
résultats d'examen(s). En effet, l’application actuellement utilisée n’est plus
satisfaisante pour des raisons d’obsolescence technique et ergonomique.
Il convient de distinguer deux types d'examens complémentaires, les examens
nécessitant la présence du patient (imagerie) et les examens réalisés en l'absence du
patient (laboratoire). Le premier type d'examen nécessite la planification d'un
rendez-vous.
Les examens concernés par le présent cahier des charges sont :
 les examens de laboratoires (biologie et anatomie pathologie)
 l'imagerie
Les grandes fonctions à informatiser sont les suivantes :
 Paramétrage du système
 Réalisation d'une demande d'examen(s)
 Suivi de la demande d'examen(s)
 Consultation des résultats d'examen(s)
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.
Pour les établissements privés, ce chapitre doit être adapté en conséquence.
-4-
Cahier des charges
C’est ce contenu que l’on retrouve dans les différents composants du DCE (Dossier de
Consultation des Entreprises) : Règlement particulier, CCAP, CCTP ou Programme
Fonctionnel selon le type de consultation.
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 demandes et résultats
d’examens.
 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
-5-
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’efficience de la prise en charge du
patient
2.1.1 Énoncé de l’objectif
Améliorer l’efficience 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)
 Améliorer la qualité et la sécurité de la prise en charge du patient
 Évaluer l’activité, élément incontournable de la bonne gestion
établissement, d’un pôle, d'un service, d’une UF
d’un
Pour les professionnels de santé :
 Faciliter l'accès aux données du patient et permettre de retrouver à tout moment
tous les éléments historiques concernant son parcours
-6-
Cahier des charges
 Faciliter une communication plus rapide et plus fiable des informations
nécessaires à la gestion du dossier patient : acheminement de la demande,
traitement et production des résultats
 Simplifier la prise en compte des demandes d’analyse et des aspects
administratifs associés
 Apporter une aide au diagnostic
 Favoriser la mise en place d’un traitement plus précoce, donc parfois plus
efficace
 Améliorer la satisfaction des professionnels de santé internes et externes à
l'établissement
Pour le patient :
 Bénéficier d’une meilleure qualité de sa prise en charge
 Disposer d'une information claire conformément au droit à l'information dont il
bénéficie
 Alimenter le DMP par l'ajout d’éléments jugés utiles pour la coordination de ses
soins
2.1.3 Indicateur de mesure
 Délai entre la demande et le résultat d’un acte et évolution de ces paramètres
 Identification des dysfonctionnements et analyse de la fluidité de prise en charge
du patient
 Satisfaction des patients et des utilisateurs du système
2.2 Structurer et partager les informations médicales
2.2.1 Énoncé de l’objectif
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é
 Améliorer la prise de décision
 Réduire les coûts en évitant la ressaisie d’informations, les erreurs qui peuvent
en découler, ainsi que les redondances d’examens
Pour les professionnels de santé :
 Obtenir un recueil d'informations standardisées dans un objectif de recherche :
les informations recueillies peuvent être analysées à des fins de vigilance, d’études
épidémiologiques et médico-économiques
 Aider à l’organisation des tâches journalières : aide à la saisie (protocoles), aide à
la décision, optimisation des processus et de la logistique (workflow)
Pour le patient :
-7-
Cahier des charges
 Alimenter le DMP par l'ajout de documents jugés utiles pour la coordination de
ses soins
2.2.3 Indicateur de mesure
Taux de comptes rendus structurés produits lors d'un séjour du patient.
Si nécessaire, adapter la formulation de ces objectifs au contexte de l’établissement.
Inclure d’autres objectifs si nécessaire.
2.3 Réduire les examens redondants
2.3.1 Énoncé de l’objectif
Réduire les examens redondants
2.3.2 Bénéfices attendus
Pour l'établissement:
 Réduction des coûts, réduction des risques d'erreurs
Pour les professionnels :
 gain de temps
Pour le patient:
 amélioration du confort du patient
2.3.3 Indicateur de mesure
Nombre d'examens pour un même volume de patients.
-8-
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.
Le chef de projet est un docteur en biolotie.
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
-9-
Cahier des charges
à la conduite du projet (allocations de ressources ou de budget, révision du périmètre
du projet, révision des délais).
Le chef de projet est assisté par un comité de pilotage composé de
X
Y
Z
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 500 lits :
Les autres intervenants sont
 IDE à X% de son temps
 Le personnel des services prestataires à X% de leur temps
 Chef de projet(s) informatique(s) Maîtrise d’œuvre à X % de son temps
3.4 Utilisateurs finaux
3.4.1 Personnel médical
 Médecin
 Interne
 Sage femme
3.4.2 Personnel paramédical




IDE
IADE
IBODE
Puéricultrice
3.4.3 Intervenants paramédicaux transverses
Modifier la liste selon l'existant de l'établissement
 Masseur-kinésithérapeute
 Pédicure-podologue
 Ergothérapeute
 Psychomotricien
 Orthophoniste
 Orthoptiste
 Diététicien
- 10 -
Cahier des charges
3.4.4 Personnel des services prestataires





médecin biologiste
radiologue
technicien de laboratoire médical
manipulateur d'électroradiologie médicale
personnel responsable de la réception des demandes
Lister ici les services concernés par le projet et les effectifs par métier en remplissant
par exemple le tableau suivant :
Effectifs (personnes physiques)
Lieux d'exercice
Personnel
médical
Personnel
paramédical
Intervenants
transverses
Personnel
services
prestataires
Service A
Service B
Service C
Pôle
Laboratoire
Salle d'examens
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,
- 11 -
Cahier des charges
 Le chef de projet informatique en charge de la mise en place et la maintenance
du système,
 Le chef de projet opérationnel.
- 12 -
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 des demandes et résultats d'examen(s)
Décrire ici le processus de demandes et résultats d'examen(s) existants :
xxxx
xxxxx
4.1.3 Diagramme général
Le diagramme ci-dessous, très général, correspond aux besoins de la grande majorité
des établissements.
Il pourra être modifié et enrichi si nécessaire.
Pour les examens de laboratoire :
- 13 -
Cahier des charges
Demandes et résultats d’examens de laboratoire (réalisés en l'absence du patient)
Demandeur
Préleveur
Personnels des services
prestataires
Demander un examen
Valider la demande
Enregistrer la demande
Planifier les actes
(mise à jour du plan de soins)
Réaliser le prélèvement
Identifier le prélèvement
(étiquetage du prélèvement)
Transmettre le prélèvement au
laboratoire
Vérifier la conformité de
l’échantillon
Valider le prélèvement
(validation analytique)
Valider le prélèvement
(validation bilogique)
Editer les Comptes rendus
Archiver les résultats
Transmettre les résultats
Consulter et analyser les
résultats
Mise à jour du dossier patient
Fin du
processus
- 14 -
Cahier des charges
Pour les examens nécessitant la présence du patient :
Demandes et résultats d’examens nécessitant la présence du patient (imagerie)
Demandeur
Service d’imagerie et de radiologie
Demander un examen
Transmettre la demande au
service de radiologie
Examiner la demande
Modifier
la demande
Valider la demande
Formuler une contreproposition
Refuser
la demande
Planifier un rendez-vous
Accepter le rdv ou
la contreproposition
Refuser le rdv ou
la contreproposition
Fin du
processus
Compléter le dossier patient avec
les données du RDV
Réaliser l’examen
Formaliser le compte rendu
Valider le C.R.
Transmettre le C.R.
Consulter et analyser
les résultats
Mettre à jour le plan
de soins
Fin du
processus
- 15 -
Cahier des charges
4.2 Diagramme de contexte
Ce diagramme a pour objet d’identifier les flux d’informations entre les différents
acteurs et le système d’information.
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.
Comme précédemment on pourra reprendre ce diagramme tel quel ou le modifier en
fonction des besoins de votre établissement.
s
DPI
tere
Ré
su
nd
lta
/d
ns
sm
éd
u
de
ts
i ca
ma
nd
le s
es
Dem
demandes
Plan de soins
Confirmatio
Demandeur
tio
ée
rip
mp
nn
sc
Do
Pr
e
Co
em
an
de
Dossier médical
n du prélèv
ement
a
sd
nde
Demandes et
résultats
d’examens
co
da
ge
ré
au
es
uett
ettes
Etiqu
de
Aid
e
’étiq
va
su
lid
lta
ts
at
io n
m
Co
an
m
de
s
pt
ere
nd
u
SI du service prestataire
(laboratoires, plateaux
techniques …)
Base de
connaissance
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.
Préciser le périmètre sous forme de diagramme de cas d’utilisation, ou indiquer
« sans objet ».
- 16 -
Préleveur
Cahier des charges
Demandes et résultats d’examen
Demander un examen
Valider la demande
d’examen
Transmettre la
demande d'examen
Mettre à jour le
plan de soins
Planifier le
prélèvement
Prendre un
rendez-vous
pour un examen
Réaliser le
prélèvement
Demandeur
Identifier le
Prélèvement
Editer les demandes
d’examens et les
étiquettes
Préleveur (IDE)
Transmettre le
prélèvement
Suivre la demande
d'examen
Consulter et
exploiter les résultats
Mettre à jour le
dossier patient
- 17 -
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.
5.1 Législation
5.1.1 Prescription et demande d'examens de laboratoire
Arrêté du 30 septembre 1997, NOR: MESP9723184A
Les demandes d’examens de biologie doivent être prescrites par les médecins et,
dans la limite de leurs compétences, par les sages-femmes.
Article R. 161-45 du code de la sécurité sociale
Article L. 162-4 du code de la sécurité sociale
La prescription doit mentionner le nom et prénom(s)du bénéficiaire des actes ou
prestations, l'identifiant du prescripteur, la date de la prescription, la référence de
la prescription, le cas échéant, le caractère non remboursable des produits,
prestations et actes qu'ils prescrivent, et la mention de la disposition législative en
vertu de laquelle la participation financière de l'assuré est limitée ou supprimée.
5.1.2 Activité de prélèvement
L'activité de prélèvement est traité dans le CDC type Dossier de soins et paramédical,
la réglementation liée à cette activité est donc plus largement détaillée dans ce cahier
des charges.
5.1.3 Identification du prélèvement
Arrêté du 26 novembre 1999 relatif à la bonne exécution des analyses de biologie médicale modifié par l’arrêté du 26
avril 2002 - GUIDE DE BONNE EXECUTION DES ANALYSES DE BIOLOGIE MEDICALE
L'étiquetage des tubes ou récipients contenant l'échantillon biologique doit être fait
au moment du prélèvement par la personne ayant réalisé celui-ci.
L'étiquetage doit être conçu pour éviter toute erreur sur l'identité de la personne.
- 18 -
Cahier des charges
5.1.4 Prélèvement des échantillons biologiques
Arrêté du 26 novembre 1999 relatif à la bonne exécution des analyses de biologie médicale modifié par l’arrêté du 26
avril 2002 - GUIDE DE BONNE EXECUTION DES ANALYSES DE BIOLOGIE MEDICALE
Le biologiste fournit aux médecins prescripteurs toutes les précisions utiles aux
conditions de mise en œuvre des analyses médicales.
Dans le cas où l'échantillon n'est pas conforme et est refusé par le laboratoire, le
motif de ce refus sera porté à la connaissance du médecin prescripteur.
5.1.5 Résultats des demandes de biologie
Arrêté du 26 novembre 1999 relatif à la bonne exécution des analyses de biologie médicale modifié par l’arrêté du 26
avril 2002 - GUIDE DE BONNE EXECUTION DES ANALYSES DE BIOLOGIE MEDICALE
L'expression des résultats doit être précise et sans équivoque.
Les valeurs de référence doivent être indiquées. La méthode d'analyse et/ou les
réactifs utilisé(e)(s) doivent être mentionné(e)(s) chaque fois qu'ils peuvent influer
sur l'expression du résultat ainsi que lorsque la réglementation l'exige. Pour les
résultats quantitatifs, le cas échéant, les performances analytiques de la méthode
peuvent être indiquées. Les unités du système international doivent être utilisées
quand elles existent.
Le biologiste doit, en accord avec les dispositions réglementaires :
- valider les résultats des examens biologiques après s'être assuré que leur exécution
est conforme aux recommandations du guide ;
- signer les comptes rendus d'analyses ;
- s'assurer que leur transmission se fait dans les délais compatibles avec leur bonne
utilisation clinique et dans des conditions de confidentialité préservant le secret
professionnel.
Les comptes rendus ne peuvent être communiqués qu'après les opérations de
validation. Toutefois, pour les patients hospitalisés et dans le cas des examens
demandés en urgence, des résultats partiels peuvent être transmis dans des
conditions définies par le biologiste et sous sa responsabilité, avant la validation
biologique de l'ensemble des résultats demandés.
Ils doivent être confirmés dès que celle-ci aura été effectuée par un biologiste et le
médecin prescripteur doit être informé de cette particularité.
5.2 Recommandations
5.2.1 Demandes d'examens d'imagerie
HAS - Indicateur Conformité des demandes d’examens d’imagerie -
Une demande est conforme dès lors qu’elle est retrouvée et qu’elle contient les huit
critères nécessaires à la réalisation et à l’interprétation de l’examen.
Cinq critères administratifs :
- 19 -
Cahier des charges
1. Date de la demande
2. Service demandeur
3. Nom du médecin demandeur
4. Identité du patient
5. Date de naissance du patient
Trois critères cliniques :
6. Région anatomique
7. Motif de l’examen (histoire clinique)
8. Finalité de l’examen (question posée)
5.2.2 Comptes rendus d'examens d'imagerie
ANAES - DOSSIER DU PATIENT - REGLEMENTATION ET RECOMMANDATIONS - JUIN 2003
Les comptes rendus d'examens d'imagerie médicale doivent être horodatés pour
permettre de les situer précisément dans la chronologie des soins.
5.2.3 Demande d'examens de laboratoire
Norme 15189 - AFNOR - Laboratoires d'analyses de biologie médicale — Exigences particulières concernant la qualité et
la compétence
La feuille de prescription doit contenir les informations nécessaires pour identifier le
patient et le prescripteur autorisé. Elle doit également fournir les données cliniques
pertinentes. Les exigences nationales, régionales ou locales doivent s’appliquer.
Il convient que la feuille de prescription ou un équivalent électronique prévoit
suffisamment d’espace pour indiquer, sans s’y limiter les éléments suivants:
a) l’identification univoque du patient ;
b) le nom ou tout autre moyen d’identification unique du médecin ou de toute autre
personne légalement habilitée à prescrire des analyses ou à utiliser des informations
cliniques ;
c) le type d’échantillon et le site anatomique d’origine, le cas échéant ;
d) la nature des analyses prescrites ;
e) les renseignements cliniques relatives au patient, comprenant au minimum le
sexe et la date de naissance, pour les besoins de l’interprétation du résultat ;
f) la date et l’heure du prélèvement de l’échantillon ;
g) la date et l’heure de réception des échantillons par le laboratoire.
Il convient que le format des feuilles de prescription (par exemple papier ou
électronique) et la manière dont les prescriptions doivent être communiquées au
laboratoire soient déterminés en accord avec les utilisateurs des prestations du
laboratoire.
5.2.4 Résultats des examens de laboratoire
- 20 -
Cahier des charges
Norme 15189 - AFNOR Laboratoires d'analyses de biologie médicale — Exigences particulières concernant la qualité et
la compétence
Les résultats doivent être lisibles, ne présenter aucune erreur de transcription et
être diffusés aux personnes habilitées à recevoir et à utiliser les informations
médicales. Le compte rendu doit comprendre, sans y être limité, les renseignements
suivants:
a) l’identification univoque et claire de l’analyse, y compris, le cas échéant, la
méthode de mesure ;
b) l’identification du laboratoire ayant édité le compte rendu ;
c) l’identification unique du patient et, si possible, du lieu où il se trouve et la
destination du compte rendu ;
d) le nom ou tout autre moyen d’identification unique du prescripteur ;
e) la date et l’heure du prélèvement de l’échantillon, si elles sont disponibles et
pertinentes pour les soins prodigués au patient, et l’heure de réception par le
laboratoire ;
f) la date et l’heure de la diffusion du compte rendu ;
g) l’origine ou le type de l’échantillon ;
h) les résultats de l’analyse ;
i) les intervalles de référence biologiques, le cas échéant ;
j) l’interprétation des résultats, le cas échéant ;
k) tout autre commentaire ;
l) l’identification de la personne autorisant la diffusion du compte rendu ;
m) le cas échéant, les résultats initiaux et les résultats corrigés ;
n) si possible, la signature ou l’autorisation de la personne vérifiant ou transmettant
le compte rendu.
Le compte rendu doit indiquer si la qualité de l’échantillon primaire reçu était
insuffisante pour l’analyse ou si elle pourrait avoir compromis le résultat.
Le laboratoire doit disposer de procédures permettant d’avertir immédiatement un
médecin (ou tout autre personnel chargé des soins du patient) lorsque les résultats
des analyses effectuées se situent dans les intervalles «d’alerte» ou «critiques»
établis.
En cas de modification, le compte rendu doit indiquer l’heure, la date et le nom de la
personne responsable de la modification.
Les données initiales doivent rester lisibles en cas de modifications.
Les enregistrements électroniques d’origine doivent être conservés et les
modifications ajoutées au compte rendu sous forme de procédures appropriées de
sorte que les comptes rendus indiquent clairement la modification.
- 21 -
Cahier des charges
Les résultats déjà communiqués pour une décision clinique doivent être conservés
dans les comptes rendus cumulatifs ultérieurs et être clairement identifiés comme
ayant été modifiés.
- 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 Demander un examen
Acteur principal
Demandeur (Médecin, sage-femme)
Autres parties prenantes
Personnel soignant, services prestataires (laboratoire,
service d'imagerie)
Déclencheur
Prescription / demande d'examen
Description
Le demandeur fait une demande d'examen(s)
Préconditions
Le demandeur est identifié et est autorisé par le système
à réaliser la demande.
Le patient est identifié par le système, il est admis dans
son UF.
Le demandeur a consulté le dossier du patient
Garanties minimales
L'ensemble des actions réalisé est tracé dans le système.
Garanties en cas de succès
La demande d'examen(s) est enregistrée et le plan de
prélèvement est alimenté.
- 23 -
Cahier des charges
Flux normal
1. L'utilisateur sélectionne le patient pour lequel la
demande d'examen(s) doit être réalisée.
2. L'utilisateur sélectionne le ou les examens à réaliser
3. L'utilisateur complète la demande en indiquant la date
de réalisation, la durée, la fréquence, le prestataire et le
degré d'urgence.
4. L'utilisateur valide la demande d'examen(s).
5. Le système effectue les contrôles nécessaires à la
validation de la demande d'examen(s).
6. Aucune anomalie n'est détectée, le système enregistre
la demande d'examen(s) et alimente le plan de soins.
Flux alternatif
5.a. Le système détecte une anomalie :
5.a.1. Le système signale l’anomalie à l'utilisateur.
5.a.2. L'utilisateur choisit de poursuivre et confirme la
validation de la demande d'examen(s). Le cas d'utilisation
se poursuit à l'étape 6.
5.a.2.a. L'utilisateur choisit
d'utilisation se termine.
d'abandonner.
5.a.2.b. L'utilisateur choisit de
d'utilisation se poursuit à l'étape 2.
modifier.
Le
cas
Le
cas
5.b. Le système détecte une redondance.
5.b.1. Le système affiche les demandes d'examen(s)
détectées comme étant redondantes.
5.b.2 L'utilisateur choisit de poursuivre et confirme la
validation de la demande d'examen(s). Le cas d'utilisation
se poursuit à l'étape 6.
5.a.2.a. L'utilisateur choisit
d'utilisation se termine.
d'abandonner.
5.a.2.b. L'utilisateur choisit de
d'utilisation se poursuit à l'étape 2.
Exceptions
modifier.
Une erreur survient :
1. Le système affiche un message d'erreur.
2. Le cas d'utilisation se termine.
Cas inclus
Fréquence d’utilisation
Au fil de l'eau.
Règles métier
- 24 -
Le
cas
Le
cas
Cahier des charges
Exigences particulières
6.2 CU02 Consulter des résultats d'examens de
laboratoire
Acteur principal
Médecin
Autres parties prenantes
Déclencheur
Arrivée des résultats d'examens de laboratoire.
Description
Le médecin consulte les résultats d'un examen de
laboratoire
Préconditions
Prescripteur est identifié et est autorisé par le système à
consulter les résultats.
Les résultats sont disponibles.
Garanties minimales
L'ensemble des actions réalisées est tracé dans le
système.
Garanties en cas de succès
Les résultats sont consultés par le médecin et le système
enregistre que les résultats ont été lus par le médecin.
Flux normal
Le système permet d'effectuer une recherche par patient
ou multi patients
1 recherche par patient :
1.1. L'utilisateur sélectionne le patient
1.2. l'utilisateur indique les critères de recherche : venue,
demande, type de résultats
1.3. le système affiche les résultats correspondants aux
critères de recherche
1.4. L'utilisateur sélectionne le(s) résultat(s) et le mode
d'affichage souhaités
1.5. Le système affiche les informations.
Flux alternatif
1.a. recherche multi patients
1.a.1. l'utilisateur indique les critères de recherche : type
de résultats, type de venue, critère de normalité, degré
d'urgence. Le cas d'utilisation se poursuit à l'étape 1.3.
1.3.a Aucun résultat 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.
- 25 -
Cahier des charges
Exceptions
Une erreur survient :
1. Le système affiche un message d'erreur.
2. Le cas d'utilisation se termine.
Cas inclus
Fréquence d’utilisation
Au fil de l'eau
Règles métier
Exigences particulières
6.3 CU03 Consulter des résultats d'examens d'imagerie
Acteur principal
Médecin
Autres parties prenantes
Déclencheur
Arrivée de résultats d'examens d'imagerie : comptes
rendus et images.
Description
Le médecin
d'imagerie.
Préconditions
Prescripteur est identifié et est autorisé par le système à
consulter les résultats.
consulte
les
résultats
d'un
examen
Les résultats sont disponibles.
Garanties minimales
L'ensemble des actions réalisé est tracé dans le système.
Garanties en cas de succès
Les résultats sont consultés par le médecin et le système
enregistre que les résultats ont été lus par le médecin.
Flux normal
Le système permet d'effectuer une recherche par patient
ou multi patients
1 recherche par patient :
1.1. L'utilisateur sélectionne le patient
1.2. l'utilisateur indique les critères de recherche : venue,
demande, type de résultats
1.3. le système affiche les résultats correspondants aux
critères de recherche
1.4. L'utilisateur sélectionne le(s) résultat(s)
1.5. Le système affiche les informations, comptes rendus
et images associées, correspondantes au(x) résultat(s)
- 26 -
Cahier des charges
sélectionné(s).
Flux alternatif
1.a. recherche multi patients
1.a.1. l'utilisateur indique les critères de recherche : type
de résultats, type de venue, critère de normalité, degré
d'urgence. le cas d'utilisation se poursuit à l'étape 1.3.
1.3.b Aucun résultat 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.
Exceptions
Une erreur survient :
1. Le système affiche un message d'erreur.
2. Le cas d'utilisation se termine.
Cas inclus
Fréquence d’utilisation
Au fil de l'eau
Règles métier
Exigences particulières
- 27 -
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 de soins et paramé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.
- 28 -
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.
7.1.2 Alertes
Le système doit permettre de paramétrer les alertes des demandes et résultats
d'examen(s).
Le soumissionnaire précisera les modalités de paramétrage de ces alertes.
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 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-C en appliquant un
algorithme public sur les traits d’identité lus en carte Vitale.
Le système doit permettre de stocker l'INS-C comme un trait d'identité du patient
au même titre que l'IPP.
- 29 -
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…
Pour un patient dont les traits sont saisis dans le système, le système doit permettre
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, le système doit permettre de disposer d’une identité fictive ;
Dans le cas d'un accouchement sous X, le système doit permettre 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 Faire une demande d'examen(s)
La fonction « demande d’examens » permet :
- au niveau des unités de soins : de formuler une demande et de la transmettre au
plateau médico-technique concerné,
- au niveau des plateaux médico-techniques concernés de recevoir la demande et de la
traiter.
- 30 -
Cahier des charges
Il convient de distinguer les examens nécessitant la présence du patient (ex :
radiographies) avec une demande et un engagement de rendez-vous de ceux qui sont
réalisés en l’absence du patient (ex: prélèvement pour examens de laboratoire).
7.3.1 Saisie d’une demande d’examen(s)
Le système de demandes et résultats d'examen(s) doit permettre à l'utilisateur de
réaliser une prescription à un patient donné pour une venue donnée et d'en faire la
demande au service prestataire concerné.
Généralités
Le système doit permettre à l'utilisateur de faire une demande d'examen(s) pour un
patient donné et une venue donnée.
Pour une demande d'examen(s) donnée, le système doit permettre à l'utilisateur
d'indiquer :
 le(s) examen(s) à réaliser
 la date et l'heure souhaitées de réalisation de(s) examen(s)
 la date et l'heure souhaitées de prélèvement pour les examens de laboratoire
 la fréquence et la durée de la demande
 l’identification de l’unité de soins demandeuse
 l'identité du demandeur
 les raisons de la demande
 le diagnostic
 les résultats attendus
 l’identification du prestataire destinataire, interne ou externe à l'établissement
 les informations cliniques du patient (ex : diagnostics, antécédents, allergies,
traitements, pathologies, interventions)
 le niveau d’urgence de la demande.
Modifier et compléter en fonction des besoins de l'établissement
Le système doit proposer à l'utilisateur une aide à la saisie des demandes
d'examen(s)
 le référentiel des examens
 la liste des protocoles
 la liste des examens les plus fréquemment demandés par service ou par
spécialité
 les favoris du demandeur
Le système doit permettre à l'utilisateur de créer sa liste de favoris.
Le système doit permettre à l'utilisateur de rechercher un examen selon différents
critères :
 par type
 par nom
 par code
Modifier et compléter en fonction des besoins de l'établissement
- 31 -
Cahier des charges
Le système doit permettre à l'utilisateur de réaliser une demande d'examen(s)
conditionnelles.
Le système doit permettre à l'utilisateur de suivre l'état d'avancement de la
demande d'examens(s)
Le système doit permettre à l'utilisateur de saisir une demande d'examen(s)
itérative.
Le système doit permettre à l'utilisateur d'enregistrer une demande d'examen(s)
Le système doit permettre de valider une demande d'examen(s).
Le système doit permettre de dupliquer une demande d'examen(s).
Le système doit permettre de modifier une demande d'examen(s).
Le système doit permettre de supprimer une demande d'examen(s).
Le système doit permettre à un professionnel de santé agissant par délégation de
saisir une demande d'examen(s).
Cette personne est autorisée à saisir une demande d'examen(s), mais non pas à la
valider.
Le système doit permettre à l'utilisateur de visualiser les données du dossier patient
suivantes :
 les informations relatives à la venue du patient
 les données anthropométriques du patient
 les données cliniques du patient
 les données médico-techniques du patient
 l’historique des prescriptions du patient
 l'historique des demandes d’examen(s) réalisés du patient.
Modifier et compléter en fonction des besoins de l'établissement
Le système doit permettre à l'utilisateur de consulter les archives des résultats et
comptes rendus pour le patient concerné par la demande d'examen(s).
Spécificités liées aux demande d'examen(s) de laboratoire
Cette exigence est à adapter en fonction de la présence ou non du laboratoire au sein
de l'établissement.
Le système doit permettre à l'utilisateur d'indiquer des informations relatives au
prélèvement :
 la nature du prélèvement
 le site du prélèvement
 le matériel de prélèvement à utiliser
 les conditions de prélèvement
Le système doit permettre à l'utilisateur de faire une demande d'examen(s) dont le
prélèvement a été réalisé.
- 32 -
Cahier des charges
Le système doit permettre à l'utilisateur de savoir si le prélèvement a été ou non
réalisé.
Spécificités liée aux demandes d'examen(s) nécessitant la
présence du patient
Le système doit permettre à l'utilisateur d'associer une demande de rendez-vous à la
demande d'examen(s).
Contrôles et alertes
Le système doit effectuer des contrôles lors de l'enregistrement de la saisie par
l'utilisateur et déclencher des alertes le cas échéant.
 le système doit détecter les demandes d'examen(s) redondantes
 le système doit détecter les redondances de signification, par exemple : examens
analogues ou examens dont la juxtaposition est inutile.
 le système doit détecter l'association incompatible de certains examens
 le système doit détecter les incohérences entre la demande d'examen(s) et les
données physiopathologiques du patient.
 le système doit détecter les contre indications pour le patient à la réalisation de
l'examen demandé.
Modifier et compléter en fonction des besoins de l'établissement
Chaque contrôle doit donner lieu à une alerte.
Le système doit permettre à l'utilisateur d'acquitter les alertes :
 en permettant à l'utilisateur de modifier sa saisie
 en permettant à l'utilisateur de maintenir l'enregistrement de sa saisie
Le soumissionnaire précisera les modalités de paramétrage des contrôles et des
alertes.
7.4 Valider une demande d'examen(s)
7.4.1 Affichage des demandes d'examen(s) à valider
Le système doit permettre à l'utilisateur de faire une recherche multicritères des
demandes d'examen(s) à valider.
Le système doit permettre à l'utilisateur de filtrer l'affichage les demandes
d'examen(s) à valider par :
 unité de soins demandeuse
 demandeur
 service prestataire
 patient
 par venue du patient
 par date ou plage de dates de demande
 par type d'examen
- 33 -
Cahier des charges
Modifier et compléter en fonction des besoins de l'établissement
Le système doit permettre à l'utilisateur qui souhaite valider la demande
d'examen(s) de :
 visualiser les données relatives à la venue du patient
 visualiser les données anthropométriques du patient
 visualiser les données cliniques du patient
 visualiser les examens demandés
 visualiser les données médico-techniques
Modifier et compléter en fonction des besoins de l'établissement
Le système doit permettre à l'utilisateur :
 de valider la demande d'examen(s) sans modification,
 de modifier, puis de valider la demande d'examen(s)
 de ne pas valider la demande d'examen(s)
Si l'utilisateur valide la demande d'examen(s) :
 le système doit permettre à l'utilisateur de saisir une observation
 le système doit transmettre la demande d'examen(s) au service prestataire
 le système doit mettre à jour le plan de soins
 pour les demandes d'examen(s) nécessitant la présence du patient, le système
doit déclencher la demande de rendez-vous.
 le système doit attribuer un identifiant unique au prélèvement.
Si l'utilisateur ne valide pas la demande d'examen(s), le système doit lui permettre
de faire un commentaire et, le cas échéant, de le transmettre au demandeur (ex :
IDE agissant par délégation)
7.5 Éditer une demande d'examen(s) et des étiquettes
Le système doit permettre à l'utilisateur d'éditer une demande d'examen(s)
mentionnant :
 L'identifiant unique de l'examen
 l’identité du patient
 l'identifiant du patient
 l'identifiant de la venue du patient
 la localisation du patient
 l'examen demandé
 le nom du demandeur
Modifier et compléter en fonction des besoins de l'établissement
Le système doit permettre à l'utilisateur d'éditer des étiquettes comportant :
 l’identité du patient
 l'identifiant du patient
 la localisation du patient
 l'examen demandé
Modifier et compléter en fonction des besoins de l'établissement
- 34 -
Cahier des charges
Pour ces éditions, le système doit pouvoir exploiter les informations textuelles,
graphiques (codes barres par exemple) et la combinaison des deux.
7.6 Suivi des demandes d'examen(s)
Le système doit permettre à l'utilisateur de suivre l'avancement des demandes
d'examens.
7.6.1 Suivi des demandes d'examen(s) de laboratoire
Le système doit permettre de suivre l'avancement des demandes d'examen(s) de
laboratoire en visualisant
 le suivi des actions du personnel de l'unité de soins demandeuse,
 les demandes d'examen(s) non validées,
 la date d'enregistrement de la demande d'examen(s),
 les demandes d'examen(s) validées,
 la date de validation de la demande d'examen(s),
 les demandes d'examen(s) pour lesquelles le prélèvement est à effectué,
 les demandes d'examen(s) pour lesquelles le prélèvement a été effectué,
 la date du prélèvement,
 la date d'envoi des demandes d'examen(s) au service prestataire,
 la date d'envoi du prélèvement au service prestataire,
 le suivi des actions du personnel du service prestataire,
 l'accusé de réception de la demande d'examen(s),
 la date de réception du prélèvement,
 la vérification de l'état des échantillons du prélèvement,
 la conformité ou non-conformité des échantillons du prélèvement,
 le refus de traitement du prélèvement,
 la nouvelle demande de prélèvement au demandeur,
 la validation de la prise en compte de la demande,
 la date prévisionnelle de l'envoi des résultats.
Modifier et compléter en fonction des besoins de l'établissement
7.6.2 Suivi des demandes d'examen(s) nécessitant la présence
du patient
Le système doit permettre de suivre l'avancement des demandes d'examen(s)
nécessitant la présence du patient en visualisant
 le suivi des actions du personnel de l'unité de soins demandeuse,
 les demandes d'examen(s) non validées,
 la date d'enregistrement de la demande d'examen(s),
 les demandes d'examen(s) validées,
 la date de validation de la demande d'examen(s),
 la date de rendez-vous souhaitée,
 le suivi des actions du personnel du service prestataire,
 l'acceptation de la demande d'examen(s),
- 35 -
Cahier des charges
 la date du rendez-vous,
 la date prévisionnelle de l'envoi des résultats,
 le refus de prise en compte la demande d'examen(s).
Le système doit attribuer un statut spécifique à chaque type d'action relative à
l'avancement de la demande d'examen(s).
7.7 Recherche multicritères des demandes d'examen(s)
Le système doit permettre à l'utilisateur d'effectuer une recherche sur les demandes
d'examen(s) selon différents critères :
 unité de soins demandeuse
 demandeur
 service prestataire
 patient
 par venue du patient
 par date ou plage de dates de demande
 par type d'examen
 par numéro de demande
 selon les différent statut(s) relatifs au suivi d'avancement de la demande
Modifier et compléter en fonction des besoins de l'établissement
7.8 Les résultats d'examens
7.8.1 Généralités
Réception
Le système doit permettre d'intégrer les résultats provenant des services
prestataires.
Le système doit permettre de rapprocher les résultats d'examen(s) à la demande
associée.
Alertes
Le système doit permettre à l'utilisateur de visualiser les alertes relatives à la
réception des résultats
 pour un patient
 pour les patients d'une unité de soin
 pour les patients d'une UF
 pour les patients d'un service
 pour les patients d'une spécialité
Modifier et compléter en fonction des besoins de l'établissement
Recherche
- 36 -
Cahier des charges
Le système doit permettre à l'utilisateur de rechercher les résultats d'examen(s)
selon différents critères
 par patient
 par liste de patients
 par type de résultats : imagerie, biologie, anamo pathologie
 par date
Le système doit permettre à l'utilisateur d'accéder aux résultats d'un patient donné
à partir du résultat de la recherche multi patients.
Consultation
Le système doit permettre à l'utilisateur de consulter les résultats d'examens
 par patient
 par liste de patients
Le système doit permettre à l'utilisateur d'accéder aux résultats d'un patient donné
à partir de la liste des patients.
 Pour un patient donné, le système doit permettre à l'utilisateur de consulter :
 les résultats d'examens de la venue en cours
 les résultats de l'ensemble des venues
Le système doit permettre à l'utilisateur de visualiser l'historique de consultation
des résultats d'examen(s)
Validation
Le système doit permettre à l'utilisateur de valider les résultats.
Le système doit permettre à l'utilisateur de visualiser
 la date de validation
 le nom du valideur
Edition
Le système doit permettre à l'utilisateur d'éditer les résultats d'examen(s)
 par patient
 par liste de patients
 par type de résultats
7.8.2 Les comptes rendus textuels
Alertes
Le système doit permettre à l'utilisateur d'identifier les nouveaux comptes rendus
réceptionnés.
Recherche et consultation
- 37 -
Cahier des charges
Le système doit permettre à l'utilisateur de rechercher un compte rendu textuel à
partir d’une recherche par patient ou par type de résultats.
Dans le cas d’une recherche par patient, le système doit permettre à l'utilisateur de
visualiser :
 l’identité du patient
 l’historique de ses venues dans l’établissement et les comptes rendus produits.
Dans le cas d’une recherche par type de résultats, le système doit permettre à
l'utilisateur de visualiser :
 le compte rendu
 l’identité du patient et de la venue dans l’établissement au cours de laquelle le
compte rendu a été produit.
7.8.3 Consultation des résultats d'examens de laboratoire
Alertes
Pour un patient donné ou pour une liste de patients et pour un type de résultats
donné, le système doit permettre à l'utilisateur de visualiser une alerte
 pour les nouveaux résultats
 pour les résultats vus
 pour les résultats validés
 pour les résultats modifiés
 pour les résultats partiels
 pour les résultats dont les valeurs sont aberrantes
Modifier et compléter en fonction des besoins de l'établissement
Recherche
Le système doit permettre à l'utilisateur de rechercher les résultats d'examens
 par liste de patients
 par patient
 par venue du patient
 par demande
 par type d'examen
 par date ou intervalle de dates
Modifier et compléter en fonction des besoins de l'établissement
Consultation
Pour un patient donné, le système doit permettre à l'utilisateur de filtrer les
résultats
 par venue
 selon le statut des résultats
 par date ou intervalle de dates
 par type d'examen
- 38 -
Cahier des charges
 par demande
Modifier et compléter en fonction des besoins de l'établissement
Le système doit permettre à l'utilisateur de paramétrer ses propres filtres.
Détail des résultats d'une demande d'examen(s)
Le système doit permettre à l'utilisateur de visualiser le détail des résultats d'une
demande d'examen(s) donnée en indiquant
 le numéro, la date et les caractéristiques de la demande,
 l'identité du patient et la venue à laquelle la demande est rattachée,
 le nom de(s) examen(s),
 l'unité de mesure de la valeur du(es) résultat(s) d'examen(s),
 la valeur du résultat du(es) examen(s),
 la norme de résultat du(es) examen(s),
 l'indice d'anormalité du résultat du(es) examen(s),
 l'état de validation des résultats par le service prestataire
 s'il existe, le commentaire associé à la valeur du(es) résultat(s).
Le système doit permettre à l'utilisateur de distinguer :
 les nouveaux résultats
 les résultats anormaux
 les résultats modifiés
 les résultats pour lesquels il existe un commentaire
Depuis le détail de la demande, le système doit permettre à l'utilisateur d'accéder au
détail d'un examen.
Modifier et compléter en fonction des besoins de l'établissement
Détail des résultats d'un examen (élément unitaire d'une demande
d'examen)
Le système doit permettre à l'utilisateur de visualiser le détail d'un examen d'une
demande en indiquant
 le nom de l'examen,
 le numéro de demande correspondant,
 la date et l'heure du résultat de l'examen,
 la valeur du résultat de l'examen,
 la norme du résultat de l'examen,
 l'indice d'anormalité du résultat de l'examen, s'il existe,
 l'état de validation du résultat,
 le nom du valideur.
Modifier et compléter en fonction des besoins de l'établissement
Le système doit permettre à l'utilisateur de visualiser l'historique relatif au(x)
résultat(s) de l'examen.
Mode d'affichage des résultats
- 39 -
Cahier des charges
Le système doit proposer à l'utilisateur différents types d'affichage des résultats
d'examens.
 Affichage cumulé :
 Le système doit permettre à l'utilisateur, à partir de sa sélection, d'afficher les
résultats d'examens en mode cumulé pour pouvoir les comparer.
 Affichage graphique :
 Le système doit permettre à l'utilisateur, à partir de sa sélection, d'afficher les
résultats d'examens en mode graphique.
 Affichage de l'historique :
 Le système doit permettre à l'utilisateur, à partir de sa sélection, d'afficher les
résultats d'examens des venues antérieures.
7.8.4 Les résultats d'imagerie
Recherche
Le système doit permettre à l'utilisateur de rechercher les résultats d'examens
d'imagerie :
 par liste de patients
 par patient
 par venue du patient
 par demande
 par type d'examen
 par date ou intervalle de dates
Modifier et compléter en fonction des besoins de l'établissement
Consultation
Le système doit permettre à l'utilisateur de visualiser les résultats d'examens
d'imagerie sélectionnés.
Pour un patient donné, le système doit permettre à l'utilisateur de visualiser les
résultats d'examens d'imagerie des venues antérieures.
Le système doit permettre à l'utilisateur d'accéder aux résultats d'examens
d'imagerie archivés.
Le système doit permettre à l'utilisateur de visualiser le compte rendu qui
accompagne tout type de résultat d'imagerie transmis.
Le système doit permettre à l'utilisateur de visualiser les images animées.
7.9 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.
- 40 -
Cahier des charges
Le système doit permettre d'anonymiser les données relatives aux demandes et
résultats d'examen(s) de façon irréversible.
Le système doit permettre d'exporter les données anonymisées extraites des
demandes et résultats d'examen(s).
Le soumissionnaire précisera le procédé d'anonymisation retenu.
Le système doit permettre de fournir des statistiques de pilotage et de gestion pour
une période donnée, dont a 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.10 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).
Le système doit afficher l'hémoglobine du patient en gramme par décilitre avec un
chiffre après la virgule.
Le système doit afficher l'hématocrite du patient en pourcentage, ce pourcentage est
un entier compris entre 0 et 100.
7.11 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.
Cette section contient également les spécifications techniques des interfaces présentées
dans le modèle de contexte.
Nom
Description
Attributs
Demande
Description
de
demande d'acte
la Identification de l'unité de soins
demandeuse
Renseignements
cliniques
:
diagnostics,
traitements,
pathologies, interventions
Identité du prescripteur : nom,
prénom, adresse téléphone, email,
numéro
d'identification
professionnel, spécialité
Date et heure de la demande
Identité du prestataire
Niveau d'urgence
Statut d'avancement
- 41 -
Cahier des charges
Durée : date de début et date de la
demande d'acte
Fréquence de la demande
Examen
Description
de Types d'examen
l'examen demandé
Code CCAM
Libellé de l'examen
Mouvement
Description
des Identifiant
mouvements lors de
Situation de départ
l'hospitalisation
Situation d'arrivée
Date / heure du mouvement
Identification de la personne et/ou
du service responsable du patient
Motifs du mouvement
Changement de lit
Changement de prise en charge
médico-administrative
Patient
Prélèvement
Description
informations
patient
des IPP
du
Données cliniques
Données anthropométriques
Description
du Identité du préleveur
prélèvement pour les
date et heure du prélèvement
examens
de
Nature du prélèvement
laboratoire
Compte rendu du prélèvement
Lieu du prélèvement
Matériels de prélèvement utilisé
Conditions de prélèvement
Nombre d'échantillons
Rendez-vous
Résultat
laboratoire
Description du rendez- date et heure du rendez-vous
vous pour les examens
Lieu du rendez-vous
d'imagerie
de Description
résultats
laboratoire
des Identité du patient
de
Renseignements cliniques
Type de prélèvement
- 42 -
Cahier des charges
Etat du prélèvement
Examens demandés
Résultats des examens demandés
Antériorités
Valeurs usuelles des analyses
Contrôle de qualité
Résultat
de
analytique
la
validation
Résultat de la validation biologique
Statut du résultat
Identité du valideur
Signature
Identité du signataire
Technique utilisée
Résultat d'imagerie
Description
des Identité du patient
résultats d'imagerie
Actes demandés
Actes réalisés
Interprétation des résultats
Identité du praticien à l’origine du
compte rendu.
Image liée au CR
Venue
Description
de
la Identifiant de venue
venue du patient à
date de début
l’établissement
date de fin
motif principal
- 43 -
Cahier des charges
8 Interopérabilité et interfaces
8.1 Interfaçage avec progiciels existants
Si l'établissement dispose d'un EAI, remplacer "demi-interface" par "connecteur".
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é
Dans le cas où l'établissement dispose d'une GAP indépendante, conserver l'exigence
suivante.
Le soumissionnaire décrira comment il envisage la communication d’identité et
quelles en sont les limitations.
8.1.2 Demi-interface avec le dossier patient informatisé
Pour accéder à des informations spécifiques du dossier patient
Compléter
8.1.3 Demi-interface avec la gestion des rendez-vous
Interface avec le circuit de demande de rendez-vous (prescription d’examens)
Compléter
- 44 -
Cahier des charges
8.1.4 Demi-interface avec la gestion de(s) application(s) de
production des résultats d'examens et d'archivage.
Compléter
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.
L’interfaçage entre deux progiciels consiste en général en une transmission des
données via un fichier intermédiaire. On parlera donc, dans la suite de ce chapitre de
demi-interfaces.
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.
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 :
- 45 -
Cahier des charges
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
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, notamment avec
les logiciels de biologie (SGL), d'anatomo pathologie et d'imagerie, pour la
récupération des résultats d'examen(s).
Schéma synoptique d’interopérabilité
Modifier le schéma ci-dessous en fonction de l’existant de votre établissement.
- 46 -
Cahier des charges
SGL
SI Biologie
Order
Filler
LTW
LAB-3
Dossier médical
LTW
LAB-1
LAB-2
Order filler
APW
PAT-2
PAT-3
RAD-3
SWF
APW
PAT-3
Order
Placer
Order
Result
Tracker
RAD-2
Order filler
SI Imagerie
(RIS)
SI Anamo pathologie
Demandes et résultats
d’examen
CR structuré selon
modèle CI-SIS
ou PDF
Gestion des
Rendez-vous
Image
display
ECG
display
Report
reader
Dossier de soins
KIN
RAD-30
RAD-31
ARI
ED
RAD-44
RAD-45
RAD-26
RAD-27
CARD-6
CARD-5
Report
repository
Concentrateur de C.R.
d’imagerie
CPI
RAD-14
RAD-15
RAD-16
RAD-17
Image
archive
Concentrateur
d’image
Information
source
ECG
Légende :
Transaction
Flux de données
Les profils et acteurs à utiliser avec chaque logiciel du [Centre Hospitalier 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
du Profil
Envoi
des SI
demandes d'examen (RIS)
d'imagerie
imagerie Order Filler
Envoi des Comptes SI
imagerie Aucun référentiel n’est disponible à ce jour.
- 47 -
SWF
Acteur
demandes
résultats
d'examen(s)
Order Placer
des
et
rendus d'imagerie
Envoi
demandes
d'examen(s)
biologique(s)
Cahier des charges
(RIS)
S'il existe, selon modèle ASIP Santé (CI-SIS)
ou PDF.
des SI biologie (SGL)
Order Filler
LTW
Order Placer
Envoi des résultats SI biologie (SGL)
d'examens
biologiques
Order Filler
LTW
Order
Tracker
Envoi
des SI
Anamo Order Filler
demandes
pathologie
d'examen(s)
d'anamo pathologie
APW
Order Placer
Envoi des résultats SI
Anamo Order Filler
d'examens d'anamo pathologie
pathologie
APW
Order
Tracker
Envoi des résultats ECG
d'examens
d'
électrocardiogramm
e (ECG)
ECG
ECG Display
Envoi des compte Concentrateur
Report
rendus d''imagerie
de
comptes Repository
rendus
d'imagerie
ARI
Report Reader
Envoi des images
KIN
Image display
CPI
Image display
ED
Image display
Information
source
SI
de Image Archive
communication
Envoi
de
texte
Image Archive
d'image
accompagnant les
(concentrateur
images
d'images)
Envoi des traces,
Image Archive
preuves,
mesure
accompagnant les
images
DPI
Demandes
rendez-vous
Données Patient
Result
Result
Les échanges entre les fonctions DPI et les
autres systèmes sont largement détaillés dans
les CDC type correspondants (Dossier médical
et Dossier de soins et paramédical)
de Gestion
des Les échanges entre les fonctions Gestion des
rendez-vous
rendez-vous et les autres systèmes sont
largement détaillés dans le CDC type
- 48 -
Cahier des charges
correspondant.
- 49 -
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
- 50 -
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
- 51 -






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 secrétaires médicales (ou de leurs référents).
9.2.2 Facilité d’utilisation en usage courant
Après trois semaines d’utilisation, au moins 60 % des médecins interrogées 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 l’Hôpital
public 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.
- 52 -
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
- 53 -
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 :
- 54 -
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.
- 55 -
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 de 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.
Les temps de réponse et les temps de procédures types
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.
- 56 -
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 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
- 57 -
Cahier des charges
9.6 Portabilité
- 58 -
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 demandes d'examen(s)) nécessitant la présence ou non
du patient.
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 secrétaires médicales
 Dans le bureau des médecins et des paramédicaux
 Dans les box de consultation
 Aux postes de soins (IDE)
- 59 -
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 [centre hospitalier 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
Rappel : l'existant peut être hébergé à l'extérieur. Dans ce cas, la description de
l'existant devra être adaptée en conséquence.
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, si nécessaire : un environnement infocentre, entrepôt de
données, datawarehouse…
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
- 60 -
Cahier des charges
Aménager ce paragraphe en fonction
l’Établissement de Santé.
des
caractéristiques
du
réseau
de
Plan du réseau
Remplir si nécessaire.
Réseau filaire
Le réseau actuel permet de disposer d’un débit de XXX 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.
- 61 -
Cahier des charges
10.4 Compatibilité avec les logiciels et matériels de
l’établissement
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 XP
 Tablettes
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 administrative du patient
 Dossier patient informatisé
 Gestion des rendez-vous
 Applications de production des résultats d'examens
 Applications d'archivage
Compléter ou modifier
10.5.3
Interfaces ou connecteurs avec leur version
respective, existant entre ces différentes applications.
Compléter
- 62 -
Cahier des charges
10.5.4
Existence d’un logiciel médiateur (« middleware »)
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).
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.
- 63 -
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
- 64 -
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.
- 65 -
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
- 66 -
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,
- 67 -
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
- 68 -
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
- 69 -
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é].
- 70 -
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
- 71 -
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 ;
- 72 -
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.
- 73 -
Cahier des charges
12 Annexes
12.1 Conventions de dénomination et définition des
termes
12.1.1
Définition des termes
Biologiste : toute personne titulaire des diplômes ou titres nécessaires, requis par
la législation en vigueur, pour exercer la spécialité ou pour assurer la direction d'un
laboratoire réalisant des analyses de biologie médicale. (GBEA)
Compte rendu d'examen(s) : rapport détaillé relatif à un examen qui a été réalisé
ou un acte qui a été pratiqué suite à une prescription ou une demande. Il peut
accompagner des résultats d'examens dont il est alors une interprétation.
Délégation : transmission d’activités ou de fonction à un personnel autorisé. Cette
transmission n’exempte pas le délégateur de sa propre responsabilité. La délégation
peut être statutaire, donc de fait, ou elle peut être accordée dans le cadre d’une
organisation interne. (Ministère de l'emploi et de la solidarité Ministère délégué à la
santé - Guide de bonnes pratiques de pharmacie hospitalière - juin 2001)
Demande d'examen(s) : demande destinée à un professionnel de santé d'un
service prestataire.
Demande d'examens conditionnelle : demande d'examen(s) en fonction de
l’évaluation d’un ou plusieurs paramètres cliniques et/ou biologiques pour un
patient donné.
Demande d'examens itérative : demande d'examen(s) à réaliser plusieurs fois.
Demandeur : un demandeur sollicite un ou des acteurs dans le but d’obtenir un
bien ou un service (notamment de collaboration) en vue de réaliser un objectif
concernant quelqu’un ou quelque chose (un autre acteur). Par exemple : demande
d'examens par un médecin ou une sage-femme pour un patient.
Dossier patient : dossier comprenant l'ensemble des informations médicales,
administratives, soignantes ou paramédicales nécessaires à la prise en charge et à
- 74 -
Cahier des charges
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.
Echantillon : échantillon obtenu par recueil ou acte de prélèvement et sur lequel
vont être effectuées une ou plusieurs analyses de biologie médicale. (GBEA)
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.
Examen : examen complémentaire permettant d'orienter le diagnostic.
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).
Laboratoire : site où sont effectués les actes d'analyses de biologie médicale par des
personnels, dans des locaux et avec un matériel répondant aux dispositions
législatives et réglementaires en vigueur (GBEA).
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.
Plan de prélèvement : vue du plan de soins limitée aux activités de prélèvements.
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
- 75 -
Cahier des charges
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 de services administratifs
Prélèvement : acte permettant l'obtention d'un échantillon biologique. (GBEA)
Prescripteur : personne autorisée à prescrire, médecin ou sage-femme
Résultat d'examen : données brutes (images, résultats analyses quantifiés, …)
résultant d'un d'acte (d'investigation, d'imagerie, d'analyse biomédicale, d'anatomopathologie…). Ces données sont interprétées dans un compte rendu d'examen.
Technicien de laboratoire : Toute personne titulaire d'un diplôme ou d'une
qualification reconnus réglementairement pour assurer, sous la responsabilité du
biologiste, l'exécution des analyses de biologie médicale (GBEA).
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.
Utilisateur : associe une personne ou un élément d'organisation à un profil
d'utilisation du système d'information.
Validation : opération permettant d'assurer qu'un résultat a été obtenu dans des
conditions techniques satisfaisantes et que celui-ci est compatible avec le dossier
biologique du patient. Cette validation est à la fois analytique et biologique.
Validation analytique : vérification de la conformité des conditions d'exécution
aux procédures en tenant compte notamment des résultats obtenus avec les
échantillons de contrôle.
Validation biologique : contrôle de la vraisemblance et de la cohérence de
l'ensemble des résultats des analyses d'un même dossier, et de leur confrontation
avec les résultats antérieurs. Elle peut nécessiter la connaissance de l'état clinique
du patient et les traitements mis en œuvre. Elle est assurée par un biologiste
(GBEA).
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
CCTP
Cahier des clauses techniques particulières
- 76 -
Cahier des charges
CPS
Carte professionnelle de santé
DCE
Dossier de consultation des entreprises
DGOS
Direction générale de l'organisation des soins
DMP
Dossier Médical Personnel
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
EHPAD
Etablissement
Dépendantes
d'Hébergement
ETL
Extract Transform Load
GAP
Logiciel de Gestion Administrative du Patient
GBEA
Guide de Bonne Exécution des Analyse de biologie médicale
HL7
Health Level 7
IADE
Infirmier(ère) Anesthésiste Diplômé(e) d’Etat
IBODE
Infirmier(ère) de Bloc Opératoire Diplômé(e) d'Etat
IDE
Infirmier(ère) Diplômé(e) d’Etat
IHE
Integrating the Healthcare Enterprise
IMS
Identité, Mouvements et Séjours
IPDE
Infirmier(ère) Puericulteur(trice) Diplômé(e) d’Etat
IPP
Identifiant permanent patient
MCO
Médecine Chirurgie, obstétrique
MOM
Mise en ordre de marche (du système)
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
- 77 -
pour
Personnes
Agées
Cahier des charges
VA
Vérification d’aptitude
VSR
Vérification de service régulier
Wireless FIdelity
WIFI
Un réseau Wi-Fi permet de relier sans fil plusieurs appareils
informatiques, au sein d'un réseau informatique, afin de
permettre la transmission de données entre eux
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.
Cela peut prendre la forme d’un premier jet de modèle des données, un modèle objet
ou un modèle du domaine. Il peut aussi suffire de remplir correctement le glossaire.
Le modèle ci-dessous peut être modifié ou réécrit pour s’adapter à votre cas. S’il existe
un standard dans votre établissement pour modéliser les données, utilisez-le, cela
facilitera la réutilisation des connaissances entre projets.
Il faut définir
- Le nom de chaque élément / entité du métier
- L’objectif de chaque élément
- Les relations entre les éléments métier
- Les attributs de chaque élément
Ne pas modifier la phrase suivante.
Ce modèle de données est mentionné à titre indicatif. Il s’impose au titulaire sauf
proposition de modèle spécifique dans son offre.
Le règlement de la consultation doit prévoir que les candidats indiquent, s’ils
proposent un modèle de données différent de celui prévu dans le CdC, dans leur note
technique les différences entre le modèle indicatif et leur proposition.
- 78 -
Cahier des charges
Prélèvement
Rendez-vous
1
1
donne lieu à
donne lieu à
0,1
0,1
Demande
1
0,1
compose
1
Examen
Compose
*
Résultat
*
Concerne
0,1
Venue
*
1
Rattachée à
Résultat
Laboratoire
Résultats
d’imagerie
Patient
Mouvement
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 -