CAHIER DES CLAUSES TECHNIQUES PARTICULIERES …direction des ressources materielles bloc operatoire cahier des clauses techniques particulieres (c.c.t.p.) marche a procedure adaptee

DIRECTION des RESSOURCES MATERIELLES

BLOC OPERATOIRE

CAHIER DES CLAUSES TECHNIQUES PARTICULIERES (C.C.T.P.)

MARCHE A PROCEDURE ADAPTEE

ACQUISITION D’UN LOGICIEL DE GESTION DE BLOC

Le présent document comporte 35 pages


BLOC OPERATOIRE

ACQUISITION D’UN LOGICIEL DE GESTION DU BLOC

Page ii

SOMMAIRE

1. PRESENTATION GENERALE 1

2. PRESENTATION DU BLOC ET DE SON ORGANISATION 2

3. DESCRIPTION DE L’ENVIRONNEMENT 10

4. DESCRIPTION DU PROJET 14

5. PRESENTATION DE L'OFFRE 24

6. PLANNING 25

7. CADRE DE REPONSE 26

8. ANNEXES 32


BLOC OPERATOIRE


Page 1

1. PRESENTATION GENERALE � Le Centre Hospitalier de Guingamp est un établissement hospitalier public de 613 lits et places, du secteur sanitaire n°7 de la région Bretagne.

• 110 lits / 3 places de MEDECINE

• 78 lits de CHIRURGIE

• 19 lits de GYNECOLOGIE-OBSTETRIQUE

• 6 lits d'UHCD

• 69 lits de soins de suite indifférenciés

• 30 lits de rééducation fonctionnelle

• Bloc opératoire

• Laboratoire

• Imagerie médicale

• Pharmacie

• SECTEUR D’HEBERGEMENT

• 284 lits d'EHPAD

• 10 places d’accueil de jour

• 4 lits d’hébergement temporaire

� Pour l’année 2008,

• 61 070 journées de Médecine, chirurgie et obstétrique (MCO)

• 31 843 journées de soins de suite et de réadaptation

• 103 439 journées d’EHPAD

• 1 864 journées d’accueil de jour

• 63 700 venues externes

� Au titre des moyens humains, le Centre hospitalier a rémunéré, au mois de Juillet 2010, 1033 emplois.

• 69 Personnels Administratifs

• 768 Personnels Soignants et Educatifs

• 50 Personnels Médico-techniques

• 76 Personnels Techniques et Ouvriers

Le corps médical est, quant à lui, constitué de 70 Praticiens et internes


BLOC OPERATOIRE


Page 2

2. PRESENTATION DU BLOC ET DE SON ORGANISATION

�� Fonctionnement :

Le bloc fonctionne sur des plages opératoires journalières en programmation et 24h/24 7 jours sur 7 pour l’urgence.

Les plages opératoires de déroulent sur une quinzaine sur les horaires suivants :

De 8h à 13 h pour le matin et de 14h à 19 h l’après-midi.

Il n’y a pas de programmation les samedi, dimanches et jours fériés.

�� Les locaux :

1 sas de transfert et 7 salles toutes localisées au bloc et réparties comme suit :.

2 salles en secteur hyper aseptique (spécialisées une pour l’activité orthopédique, l’autre pour l’ophtalmologie)

2 salles pour l’endoscopie (une pour l’activité externe, l’autre pour l’activité principalement ambulatoire)

1 salle pour les urgences vitales (principalement césariennes)

2 salles pour le reste le l’activité

1 salle de pré stérilisation

1 salle de lavage des endoscopes

1 salle de réveil avec 9 postes.

1 bureau chef de bloc

1 bureau médical

1 bureau extérieur au bloc

�� Equipement informatique :

A l’heure actuelle l’équipement se réduit à 4 imprimantes et 5 micro-ordinateurs supportant de la bureautique Microsoft. Le bloc ne bénéficie pas d’applicatif métier. Ces équipements sont connectés au réseau de l’établissement.


BLOC OPERATOIRE


Page 3

L’ensemble des 18 scopes du service est connecté sur une centrale de type DRAGER.

Depuis juillet 2010 le service bénéficie d’une couverture WiFi.

�� Volume d’activité 2009 (continuité des soins)

Nombre total d'actes au bloc dont anesthésie = 18999

Nombre hors anesthésie = 10420

RSS chirurgicaux avec acte classant opératoire = 3922

�� Effectifs détaillés

� Pour le bloc :

13,4 IBODE

11,5 IADE

7,4 AS 1 ASH

� Pour la salle de réveil :

4 IDE

1 AS

• Encadrement 1 cadre régulateur 1 cadre bloc opératoire - anesthésie

� Effectif médical :

5 anesthésistes

4 orthopédistes


BLOC OPERATOIRE


Page 4

2 ophtalmologistes

2 phlébologues

3 viscéraux

5 gynécologues obstétriciens

2 urologues

1 ORL

4 stomatologues

3 gastro-entérologues

2 pneumologues

�� Circuits patients

Dans le bloc, circuit classique sans espace d’attente en entrée du service.

Programmation existante

�� processus Bloc Opératoire


BLOC OPERATOIRE


Page 5

1 � PROGRAMMATION NORMALE


BLOC OPERATOIRE


Page 6

2 � PROGRAMMATION EN URGENCE

NB : Il n’existe pas de plage d’urgence


BLOC OPERATOIRE


Page 7

3 � PREPARATION DE L’INTERVENTION

Au BLOC :

L’équipe de Bloc,

- Plusieurs jours avant l’intervention :

� Commande des matériels et implants spécifiques (stockage des dates d’arrivées et de départ des matériels).

- La veille de l’intervention :

� Vérification de la disponibilité des matériels.

� Vérification de la bonne réalisation des préparations spécifiques.

� Signaler que toutes les conditions sont réunies pour le déroulement de l’intervention.

- Lors des urgences :

� Si des matériels spécifiques sont nécessaires, l’intervention est reportée.

4 � GESTION DE L’INTERVENTION

ARRIVEE DU PATIENT AU BLOC

� Dans le sas de transfert du bloc, un ASH est chargé de la régulation (relation avec le brancardage suivant l’avancement du programme opératoire).

� Récupérations des données médicales et administratives du patient (issues de la programmation).

� Heure d’entrée au bloc.


BLOC OPERATOIRE


Page 8

ENTREE DU PATIENT EN SALLE

� Heure d’entrée en salle.

� Check liste HAS Entrée de bloc (A valider et à produire en fin d’intervention).

� Relevé des différents intervenants.

� Actes opératoires prévus.

� Classe d’intervention.

� Type d’installation (5 possibilités).

� Type d’appui.

� Détersion, antiseptique utilisé.

� Positionnement de l’électrode du coagulateur électrique.

� Pose de garrot - Heure de début. - Interruption. - Heure de fin.

� Check liste Avant incision.

� Heure d’incision.

� Gestes réalisés (actes opératoires réalisés).

� Matériels (instrumentation) utilisés (prévisionnel et rajouts) : interface avec le logiciel de stérilisation à prévoir.

� DMI utilisés (interface applicatifs avec le logiciel PHARMA à prévoir).

� DMS à usage unique

� Actes d’imagerie éventuels. - Utilisation d’un ampli de brillance. - Patient protégé. - Radio per-op. - Radio post-op. - Utilisation de produits de contraste.

� Examens histologique et bactériologiques ou autres.

� Dénombrement des champs, compresses et liquides. - Compresses radio opaques petites ou grandes. - Compresses blanches petites ou grandes. - Compresses péritonéales. - Champs bordants.

� Systèmes de drainage (drains, lames …)


BLOC OPERATOIRE


Page 9

� Type de fermetures - Agrafes. - Fils.

� Type de pansements (gras, secs …).

� Commentaires éventuels.

SORTIE DU PATIENT EN SALLE

� Check liste Sortie de salle.

� Heure de sortie de salle.

� Heure de début de remise en état de la salle.

� Heure de fin de remise en état de la salle.

EN SALLE DE REVEIL

� Heure de sortie de bloc (après SSPI).

� Le régulateur du sas est chargé d’organiser le brancardage vers les services d’accueil.


BLOC OPERATOIRE


Page 10

3. DESCRIPTION DE L’ENVIRONNEMENT

3.1 PRESENTATION DU SIH

3.1.1 APPLICATIONS DU S.I.H :

Applicatifs patient

CLINICOM SIEMENS Gestion administrative des patients MEDIS DMC DIS BERGER LEVRAULT Dossier médical et PMSI dont modules

spécifiques : urgences, archives, SSR, obstétrique, imagerie

HEXALIS AGFA Gestion du Laboratoire SRI AGFA Résultats de laboratoire ARGOS Gestion de la dépendance en Gériatrie CURSUS Guyot Walser Informatique Gestion du dépôt de sang PHARMA Computer Engineering Circuit du médicament et des dispositifs

médicaux TRACABILITE ATMB Gestion de la stérilisation OSOFT Medibase Système Gestion de l’anesthésie

Applicatifs administratifs et logistiques

MAGH2 SIB – filière Convergence Gestion économique et financière LOGI10 NEWACT Gestion portable de sortie de stock AGIRH et AGIRH Planning

SIB – filière Convergence Gestion des ressources humaines et des plannings

GESFORM Gestion de la formation continue MAGELLAN SIB – filière Convergence Analyse de gestion PMSI PILOT PSIH Analyse de gestion activité médicale SYGAL Gestion des alertes ISODOC Gestion documentaire GESQUAL Armure Gestion documentaire Laboratoire APM Dépêches en Intranet INFOSERV AGSCOM Gestion des communications PABX ORISELF POINTECH Gestion du restaurant du personnel

Outils Logiciels

OPEN LINK SIEMENS EAI associé à CLINICOM ANTARES ENOVACOM Serveur de transfert sécuriséde données VALET DICOM ETIAM Passerelle DICOM


BLOC OPERATOIRE


Page 11

3.1.2 SCHEMA DESCRIPTIF DES ECHANGES DE DONNEES INTER-APPLICATIF :

(1) connecteur Identité/mouvements HL7 v2.3 (6) Connecteur Identité fichiers à plats ou requêtes SQL directes (2) Connecteur Activité HPRIM (7) Imagerie médicale Push DICOM

(3) Connecteur Activité Actes Laboratoire HPRIM (8) Gestion des stock (Commandes, produits, réceptions, sortie) ftp fichiers à plats

(4) Connecteur Activité fichiers à plats (9) Résultats de laboratoire HPRIM

(5) Connecteur Documents Fichiers à plats

3.1.3 DETAIL DES APPLICATIFS IMPACTES PAR LE DOMAINE :

CLINICOM

ATMB

MEDIS

PHARMA .

OSOFT

SRI

Voir détail paragraphe 4.4 page 19.


BLOC OPERATOIRE


Page 12

3.2 DESCRIPTION DU REFERENTIEL IDENTITE PATIENT ACTUEL

Conformément à la politique d'identification de l'établissement, cette fonction doit permettre d'assurer une identification fiable du patient tout au long du processus de prise en charge. Il s’agit donc de pouvoir sélectionner un patient et d’obtenir les informations administratives permettant de mieux le connaître et d’éviter toute confusion de patients.

Le système d’identification proposé dans la réponse du fournisseur est un sous-système du domaine d'identification de l'établissement. Le système de gestion de gestion de bloc devra donc s’intégrer dans le SIH en étant capable de dialoguer avec le produit de gestion administrative des malades CLINICOM de SIEMENS.

Dans notre SIH, CLINICOM est en effet le siège du référentiel identité et l’objectif est, autour de ce produit déjà en place dans notre établissement, d’harmoniser la gestion de l’identité et de supprimer les redondances de saisie. Cet applicatif assure donc la saisie initiale de l’identification patient, le recueil des séjours dans les différentes unités d’hospitalisation ou de consultation ainsi que les mouvements entre unités d’hospitalisation.

.

3.3 ENVIRONNEMENT TECHNIQUE

3.3.1.1 L’infrastructure technique

Actuellement, les fichiers de base de données des applications sont stockés sur des serveurs applicatifs dont certains sont virtualisés. Un système SAN a été mis en place en 2005. L’'établissement souhaite promouvoir l’utilisation de ces architectures.

Les applications clientes des logiciels sont accessibles à partir de postes de travail de type Pc ou Terminal léger au travers d'un serveur TSE. Certains praticiens privés sont équipés de Macintosh (type iMac OSX).

3.3.1.2 Parc de poste de travail

Le centre hospitalier dispose d’un système informatique constitué en majorité par des postes de type micro-ordinateurs qui fonctionnent en environnement Windows 95/98 (25%) et Windows XP Professionnel/Windows 2000 Pro.

Deux serveurs Windows 2003 et 2008 supportent TSE et desservent aujourd'hui 120 clients ( Terminaux légers (Wyse ou platine HP) ou Pc reconditionnés (Linux) principalement installés dans les unités de soins )

Le parc de postes de travail d’environ 400 unités au total.

Les orientations techniques en matière de constitution du parc de postes de travail sont les suivantes :

• Augmentation du ratio de terminaux légers,

• Réduction de l’encombrement physique des postes de travail : les micro-ordinateurs sont obligatoirement en format mini desktop ou mini-slim,

• Système d’exploitation des micro-ordinateurs : Windows XP Professionnel ou Windows 2000 Pro,

• Le poste de travail dispose de ports USB permettant la connexion de clés mémoire et éventuellement d’un lecteur de CD-ROM.


BLOC OPERATOIRE


Page 13

3.3.1.3 Serveurs

Le Centre Hospitalier de Guingamp dispose d'une majorité de serveurs au format rackable implantés dans une baie 19" localisée au service informatique.

Lorsque cela est possible, les données serveurs sont stockées sur le SAN de l’établissement et la sauvegarde est systématiquement intégrée dans la gestion centralisée de sauvegarde (OMNIBACK de HP)

Les principaux systèmes d’exploitation utilisés sont, par ordre de préférence :

- LINUX : Mandrake ou REDHAT

- AIX

- Windows 2008 Server

Les principaux systèmes de gestion de base de données utilisés sont par ordre de préférence :

- Mysql

- Informix

- Oracle

- Cache

3.3.1.4 Parc d’impression

Le parc d’imprimantes est constitué à 70% de petits matériels jet d'encre. Seuls les secrétariats sont équipés en laser 12 ou 20 pages/minutes monochromes en réseau.

3.3.1.5 Réseau informatique

Le réseau du Centre Hospitalier de Guingamp est réparti sur les deux sites géographiques. La totalité du réseau est de type Ethernet TCP/IP, base 10/100 Mo avec une grande partie du câblage en catégorie 5. Une couverture WiFi dessert les services de MCO et le plateau technique.

3.3.1.6 Outils bureautiques

Les outils bureautiques utilisés par le Centre Hospitalier sont les suivants :

� Navigateur Internet Explorer 7.0

� Clients de messagerie : Notes et E-groupware

� Traitement de texte : MICROSOFT WORD 97 et 2000 (projet de migration à court terme vers Open Office)

� Tableur : MICROSOFT EXCEL 97 et 2000 (projet de migration à court terme vers Open Office)

� Infocentre : Business Object 6.5.

L’établissement ne souhaite pas implanter d’outil tel que Microsoft Access pour ses nouvelles acquisitions.


BLOC OPERATOIRE


Page 14

4. DESCRIPTION DU PROJET

4.1 OBJECTIFS

L’informatisation des processus de programmation et de traçabilité des interventions vise à faciliter l’organisation et sécuriser la prise en charge des patients en respectant le contexte réglementaire (circulaire DH/FH/n°2000-264 du 19/05/2000 et ordonnance du 24/04/1996 décret n°97311 du 07/04/1997) ainsi que les préconisations décrites dans les travaux de la MEAH

Les objectifs sont les suivants :

1 La plannification : En uniformisant la programmation, faciliter l’organisation des différents acteurs au sein du bloc afin d’optimiser les moyens (salles, matériels, DM techniques relevant du domaine biomédical) et les ressources humaines nécessaires pour réaliser les interventions en assurant un niveau de qualité et de sécurité.

3 : La supervision : Tout au long du processus, donner à l’utilisateur la possibilité d’interagir sur le programme opératoire et les paramètres des l’interventions.

2 :La traçabilité des interventions : Sécuriser et assurer le suivi péri-opératoire ainsi que la prise en charge du patient en fournissant toutes les informations nécessaires à la traçabilité.

4.2 RESULTATS ATTENDUS

La solution informatique devra assurer :

4.2.1 LA PLANIFICATION

• Le logiciel doit être accessible en lecture et écriture par les chirurgiens et/ou leur secrétariat afin de planifier leurs interventions. Cet accès devra pouvoir être limité à un secteur ou une activité.

• Lors de la planification de l'intervention, ils devront sur un espace fiche patient saisir (obligatoirement pour être validée), le nom, prénom, date de naissance du patient, l’intervention exacte, le côté si besoin, le temps d’intervention prévu, le type d’anesthésie souhaitée, les demandes particulières et le service d’hospitalisation (Un lien avec les capacités d'hébergement sera apprécié).


BLOC OPERATOIRE


Page 15

• La saisie devra être réalisée sur un écran qui présentera un affichage type grille horodatée de programmation indiquant les créneaux des chirurgiens.

• Sur cet écran, le chirurgien doit être en mesure de positionner ses interventions, dans les vacations qui lui sont allouées, en fonction du type d’acte et des temps réels d’occupation de la salle.

• Le logiciel doit mettre en évidence les débordements de vacation tout en permettant néanmoins aux chirurgiens de passer outre.

• Les chirurgiens et/ou secrétaires auront accès en mise à jour à la planification jusqu’à une date butoir (Jeudi Midi avant la réunion de la cellule de supervision). Passé ce terme, ils pourront accéder en lecture mais, seul le cadre régulateur aura la possibilité de rajouter des interventions au programme.

• Les cadres des services doivent avoir en permanence accès à la planification en lecture, les cadres de bloc en mise à jour.

• La planification mise à jour en temps réel est imprimable par tous. • Lors de sa consultation ; l’anesthésiste aura accès à la fiche d’intervention du chirurgien

afin de valider l’intervention et de préciser le type d’anesthésie ainsi que les actes à effectuer (KTC, péri-…). Il complètera cette fiche en renseignant le temps nécessaire à l’anesthésie. Cette fiche doit être imprimable.

• Le programme ainsi planifié devra apparaître dès la programmation par le chirurgien. Un code couleur permettra de différencier l’intervention programmée par le chirurgien, puis validée par l’anesthésiste, enfin validée par la cellule de programmation ou le cadre régulateur.

• Le cadre régulateur pourra inscrire le nom des infirmières (IBODE et IADE) qui interviennent en salle.

4.2.2 LA SUPERVISION

• Le jour de l’intervention, le programme opératoire doit être disponible sur les postes de travail des services d’Ambulatoire et d’hospitalisation de Chirurgie, du sas d’entrée du bloc, de SSPI, du cadre régulateur de bloc.

• Ce dernier doit être en mesure d’intervenir en permanence sur le programme afin de modifier l’ordre des interventions, un changement de salle, une annulation ou un rajout urgent ou pas. La possibilité lui sera offerte de faire glisser les programmations d’une salle à une autre.

• L’outils devra permettre la gestion des interventions et le pilotage en temps réel (supervision de l’activité et suivi du patient au bloc opératoire tout au long de son parcours).

4.2.3 LA TRAÇABILITE DES INTERVENTIONS


BLOC OPERATOIRE


Page 16

• Un poste de travail dans le sas d’entrée du bloc doit permettre de tracer l’arrivée et la sortie du patient. A l’entrée, l’identification du patient se fera en relation avec l’applicatif Clinicom par lecture des codes à barres de l’étiquette patient.

• Dans chaque salle, l’IBODE et L’IADE doivent obligatoirement tracer chaque matin l’ouverture de salle et la validation de la vérification (check-list) avant chaque patient.

• Lors de chaque intervention, l’IBODE doit sélectionner l’identité du patient afin d’afficher automatiquement l’ensemble des informations déjà établies lors de la programmation. Ces données sont modifiables ou peuvent être complétées par l’IBODE en salle.

• L’IBODE complète ses informations en renseignant tous les intervenants, le type d’installation, la détersion et l’antisepsie utilisée, le positionnement de l’électrode du coagulateur électrique, la pose du garrot (heures de début et de fin), les DM utilisés (interface avec la stérilisation et saisie obligatoirement par reconnaissance des codes à barres), les DMI posés (interface avec le logiciel PHARMA par reconnaissance des codes à barres et/ou en mode manuel), les actes d’imagerie (imprimés en SSPI), les examens histologiques ou bactério, le compte des champs, compresses, les systèmes de drainage, la fermeture, le pansement, les commentaires éventuels.

• L’ensemble de ces informations devra être saisi de la manière la plus simple possible (cases à choix multiple, liste déroulante) sur des écrans tactiles (hygiène). Le candidat précisera l’étendue de l’interface tactile (totale ou partielle).

• L’édition de listes et recueil de ces informations sera possible. • L’infirmière devra pouvoir de manière simple valider les horaires d’entrée en salle,

d’induction, d’incision, de fermeture, de sortie de salle, de fin de bio nettoyage et tous les éléments nécessaires au calcul des indicateurs d’activités.

• La solution devra permettre la mise à disposition des indicateurs d'activité selon les principes "MEAH" - TROS, etc.

• De la même façon, la feuille HAS devra être générée automatiquement. • Un bouton d’appel contextuel à l’applicatif de dossier médical de l’établissement doit être

disponible en permanence sur les écrans de la solution.

4.2.4 EN TERME DE SYSTEME D’INFORMATION

La solution devra :

• Répondre aux besoins d’intégration dans le SIH (besoins décrits en 4.4). • Permettre l’exécution de requêtes sur la base de données pour le bloc et les services

supports. (stérilisation, hygiène, pharmacie etc.). Le candidat précisera la possibilité de distinguer les DMI tracées (en achat, en dépôt permanent et en prêt temporaire) ainsi que le niveau de paramétrage nécessaire à la production de rapports et d’édition personnalisés.

• Le candidat précisera les possibilités d’import des référentiels internes (médecins, UF, spécialités,…) et externes (codage CCAM, …), ainsi que le mode de mises à jour de


BLOC OPERATOIRE


Page 17

manière autonome par le service informatique de l’établissement. Une fois le logiciel pré-chargé avec ces référentiels, le candidat indiquera la liste des paramétrages à réaliser et le nombre de jours pour mettre en œuvre la planification et les indicateurs MEAH/ANAP.

• Mettre à disposition des procédures de sauvegardes de bases de données fermées et/ou ouverte. Le candidat précisera la durée du traitement et son impact éventuel sur l’utilisation de la solution (base ouverte).

• Mettre à disposition des procédures dégradées qui permettent d’avoir accès à la dernière validation.

Le jour de l’intervention

ANESTHESISTE

� Confirme

� Complète

CHIRURGIEN

� Planifie jusqu’au Jeudi précédent

Cadre Régulateur

� Consulte

� Valide la programmation

� Ajuste les modifications de planification

Dans le sas

� Validation de l’entrée au bloc Salle d’opération

� traçabilité DMS (stérilisation) et DMI (pharma)

� Indicateurs

� feuilles annexes (Rx,sté, DMS …) Dans le sas

� Validation de la sortie de SSPI


BLOC OPERATOIRE


Page 18

4.3 FOURNITURES ET PRESTATIONS ATTENDUES

Les fournitures et prestations attendues dans le cadre de ce projet sont :

� Les droits d’usage des différents logiciels et composants nécessaires pour la mise en œuvre du système. Les droits d’usage des composants standard tels que système de gestion de base de données, système d’exploitation seront proposés en option, le Centre Hospitalier se réservant la possibilité de les acquérir indépendamment du projet.

� Les équipements serveurs et lecteurs code à barres nécessaires pour la mise en œuvre de la solution proposée dans le contexte du Centre Hospitalier. Ces équipements seront proposés en option, le Centre Hospitalier se réservant la possibilité de les acquérir indépendamment du projet.

� Etude préalable, prise en compte de l’existant.

� Implantation de progiciels, intégration dans le S.I.H. et paramétrage.

� Mise en œuvre des interfaces.

� Tests des applications.

� Formation des utilisateurs et services prestataires (stérilisation, pharmacie …).

� Documentation technique et fonctionnelle.

� Assistance au démarrage.

� Maintenance et support.


BLOC OPERATOIRE


Page 19

4.4 SCHEMA CIBLE DU SIH

Le logiciel proposé doit s’inscrire dans le contexte technique du Centre Hospitalier de Guingamp.

4.4.1 AVEC LE SYSTEME DE GESTION DE L’IDENTITE DU PATIENT Le produit actuel de gestion administrative des malades est CLINICOM de SHS. Les échanges avec ce

référentiel sont aujourd’hui assurés au travers de l’outil d’intégration SIEMENS OpenLink qui est un moteur de communication répondant à différentes normes (HL7 – IHE – HPRIM) ainsi qu’à l’intégration de flux personnalisés. (pour exemple, le connecteur mis en œuvre pour la communication de l’identité et des mouvements avec notre dossier médical est au format HL7 V2.3.).

Données du référentiel identité :

Les identifiants de ce système sont le numéro IPP : identifiant permanent du patient et le numéro d’épisode : numéro alloué à chaque nouveau séjour ou consultation du patient (En hospitalisation, un même séjour peut se composer de plusieurs passages dans différentes unités d’hébergement). Cette disposition est capitale pour garantir l’intégrité du SIH.

Les autres informations pertinentes sont :

- Nom usuel, nom de naissance, Prénom, date de naissance du patient.

- Adresse patient.

- Numéro d’assuré social.

La liste des messages HL7 est en annexe du présent document page 33.

4.4.2 AVEC LE SYSTEME DE GESTION DE LA STERILISATION

Le service est équipé du système « TRACEUR » de la société ATMB.

� Le produit de gestion de bloc doit permettre de transférer au produit de gestion de stérilisation l’ensemble des informations nécessaires à l’exhaustivité de la traçabilité des dispositifs médicaux stériles réutilisables (boites, sachets).

� La cohérence et la liaison (codification) entre le référentiel des produits et DM gérés en stérilisation et la base produits du logiciel de bloc doit être impérativement assuré de manière automatique.

4.4.3 AVEC LE SYSTEME DE DOSSIER MEDICAL COMMUN Le système de dossier médical de l’établissement est : MEDIS de la société DIS/BERGER LEVRAULT. Cet outil de dossier minimum commun est déployé sur l’ensemble des services. Il concentre l’ensemble des documents produits dans les secrétariats médicaux et sert de collecteur d’actes et d’informations RUM pour l’activité médicale. Il est l’outil de groupage PMSI du DIM. C’est une application client serveur traditionnel (


BLOC OPERATOIRE


Page 20

développement en Visual Basic ). Les données sont stockées dans une base de données relationnelle INFORMIX hébergée sur un serveur AIX 5.3

� Le produit de gestion de bloc sera capable de faire appel à une application tiers (dossier médical Médis) au travers de l’exécution d’une ligne de commande accompagnée des paramètres suivants : utilisateur, numéro d’IPP et numéro d’épisode. L’utilisateur, après consultation du dossier médical, quittera l’application Médis pour revenir dans son contexte initial du logiciel de gestion de bloc.

� Le produit de gestion de bloc doit permettre de transférer, automatiquement a la sortie de salle, au système de gestion du dossier médical commun, un document résumant l’historique de l’intervention d’un patient. Ce document devra figurer dans le serveur de documents de médis. Si celui-ci est modifié, il devra remplacer le précédent. Un outil d’intégration de document est déjà opérationnel. Son principe de fonctionnement est le suivant :

« Les documents devront être mis à disposition sous forme de fichiers pdf déposés dans un répertoire (via FTP ou partage samba/Windows).

Le nom du fichier devra être composé de:

- l’identifiant permanent du patient (Numérique (entier) sur 9 chiffres ex : 000456789). - l’identifiant de venue du patient (Numérique (entier) sur 9 chiffres ex : 307842369). - la date et l’heure d’envoi (Texte ex :200906150906 format :yyyymmddhhmm). - d’un identifiant unique pouvant servir à reconnaître un document en cas de modification dans

l’applicatif source (et donc de renvoi dans Médis) ou de suppression dans l’applicatif source (Numérique (entier) sur 16 chiffres).

- du titre du document (Texte, sur 50 caractères). - de son extension (« .pdf »). »

4.4.4 AVEC LE SYSTEME DE GESTION DU CIRCUIT DU MEDICAMENT ET DES DISPOSITIFS MEDICAUX

4.4.5 Le système de gestion du circuit du médicament et des dispositifs médicaux de l’établissement est Pharma de la société Computer engineering.

Le logiciel de gestion du bloc sera interfacé avec le logiciel PHARMA applicatif de tracabilité des DMI pour 2 missions principales :

- La traçabilité des DMI posés (en achat et en dépôt permanent) par scannage d’une étiquette code-barrée, préalablement posée sur chaque DMI stocké au bloc. Pour les DMI en prêt temporaire, la traçabilité se fera en mode manuel. Objectif : Permettre la reconnaissance des caractéristiques de traçabilité de chaque DMI de la réception à la pose sauf pour les prêts temporaires) par le biais d’interfaçage automatique avec le logiciel PHARMA module traçabilité.

- La préconisation de commandes pour le réapprovisionnement ou la régularisation des DMI posés. Objectif : A partir des informations de traçabilité, proposer une préconisation de commande des DMI posés sur le


BLOC OPERATOIRE


Page 21

module PHARMA achat grâce à une interface automatique des sorties et pouvant être validée par des services différents (DMI hors ceux d’orthopédie par la Pharmacie et les DMI d’orthopédie par le Bloc). Cette préconisation doit différencier les DMI à facturer et à réapprovisionner de ceux à facturer uniquement (DMI en prêt temporaire).

Tous les autres DMS à usage unique seront commandés par la voie actuelle de réapprovisionnement et non par le logiciel du bloc (incompatibilité avec la globalisation et la mutualisation des commandes pour l’ensemble de l’hôpital).

Les intervenants de la Pharmacie participeront aux tests des différentes fonctionnalités énoncées ci-dessus.

En conséquence, l’application de gestion de bloc devra :

� Garantir la cohérence et la liaison (codification) entre le référentiel des produits et les DMS (stérilisation) et les DMI (pharmacie) et la base produits du logiciel de bloc doit être impérativement assuré de manière automatique.

� Afin de permettre une gestion des DM de pharmacie et de stérilisation délivrés au bloc (DMI ophtalmologiques, DMS …), le produit de gestion de bloc devra collecter et transmettre automatiquement les informations saisies au cours de l’intervention. Il conviendra pour le soumissionnaire, en fonction des préconisations de l’éditeur, de décrire le ou les liaisons qui seront mises en œuvre. Les informations nécessaires pourraient être les suivantes :

o date d’intervention

o N° de produit Pharma

o N° de lot

o Quantité

o N° de séjour patient

o Intervenant/opérateur

o Service

o Indication LPPR

o Date de péremption

o Zone commentaire : Surtout s’il y a eu des incidents avec le DMI ou DMI ouvert mais non posé.

� Le produit de gestion de bloc sera capable de faire appel à une application tiers (Applicatif Pharma) au travers de l’exécution d’une ligne de commande accompagnée des paramètres suivants : utilisateur, numéro d’IPP et numéro d’épisode. L’utilisateur après consultation ou saisie des d’informations, quittera l’application Pharma pour revenir dans son contexte initial du logiciel de gestion de bloc.

Liste des items Pharma en annexe du présent document page 34


BLOC OPERATOIRE


Page 22

4.4.6 AVEC LE SYSTEME DE GESTION DE L’ANESTHESIE Le service d’anesthésie est équipé de OSOFT de chez MEDIBASE SYSTEME.

� Le produit de gestion de bloc sera capable de faire appel à une application tiers (Applicatif Osoft) au travers de l’exécution d’une ligne de commande accompagnée des paramètres suivants : utilisateur, numéro d’IPP et numéro d’épisode, date de naissance. L’utilisateur après consultation ou saisie des d’informations, quittera l’application Osoft pour revenir dans son contexte initial du logiciel de gestion de bloc.

4.4.7 AVEC LE SERVEUR DE RESULTATS DE LABORATOIRE Le serveur de résultats de laboratoire de l’établissement est : SRI de la société AGFA.

� Le produit de gestion de bloc sera capable de faire appel à une application tiers (résultats de laboratoire) au travers de l’exécution d’une ligne de commande accompagnée des paramètres suivants : utilisateur, numéro d’IPP et numéro d’épisode. L’utilisateur, après consultation des résultats de laboratoire, quittera l’application SRI pour revenir dans son contexte initial du logiciel de gestion de bloc.

4.4.8 INTEGRATION DANS L’ENVIRONNEMENT TECHNIQUE

Le logiciel doit s’intégrer dans le système informatique existant, décrit plus haut dans le paragraphe « Infrastructure Technique », à savoir :

� L’accès à l’application doit être possible via le système TSE/ Windows 2003/2008 Serveur.

� Les postes de travail doivent être adaptés à l’utilisation en salle d’opération. En matière d’hygiène et d’ergonomie.

� L’usage de lecteurs code à barre doit être favorisé afin d’éviter les saisies.

� Les différentes éditions doivent être réalisables sur le parc d’imprimantes existant, imprimante réseaux implémentant le langage PCL 5 ou PCL6.

� Le produit retenu devra implémenter des mécanismes permettant une continuité de service avancée, notamment dans les domaines suivants :

o Reprise en cas de coupure de connexion réseau du poste de travail (notamment en WIFI)

o Pas d’arrêt de production en production courante

o En cas d’arrêt : système alternatif léger permettant :

o A l’utilisateur de poursuivre la collecte à minima des informations nécessaire à la traçabilité en vue d’une reprise automatique

o L’accès aux derniers planning de bloc sur un poste en local

� En cas d’arrêt programmé ou non, la possibilité de reprendre manuellement, voire automatiquement les données collectées pendant le laps de temps d’inactivité du système..

� Les sauvegardes doivent être assurées par le robot du service informatique.


BLOC OPERATOIRE


Page 23

Le système proposé devra s’intégrer dans le système de gestion de sauvegarde centralisée (HP Omniback et permettre l’arrêt, et le redémarrage de l’application sans intervention humaine (par script) et la sauvegarde des données et paramètres.

� L’ergonomie logicielle doit être facile d’accès en terme de navigation et d’exploitation des données.

� L’application devra tenir compte du réseau en place afin d’offrir des temps de réponse convenables. Les équipements fournis (matériel et logiciel) doivent être compatibles avec le réseau Ethernet TCP/IP base 10/100 Mo, connections RJ 45, qualifié catégorie 5.

� L’application, dans le cas où elle nécessite l’usage d’outil bureautique et produit des fichiers, devra être compatible avec les outils du Centre Hospitalier de Guingamp, actuels et à venir.

� Le soumissionnaire présentera les outils mis en œuvre pour assurer l'archivage des données, conformément aux textes en vigueur

� Le soumissionnaire présentera les outils d’exploitation de données mis à disposition avec la solution.

Le fournisseur indiquera précisément les ressources nécessaires (puissance processeur, mémoire, composant logiciel) sur le poste de travail et le serveur pour assurer le fonctionnement satisfaisant de la solution proposée en fonction des différents modes de mise en œuvre.

De la même manière, il indiquera les moyens d’impression à prévoir (imprimantes, format papier, couleur) nécessaires au bon fonctionnement de la solution.


BLOC OPERATOIRE


Page 24

4.5 MISE EN ŒUVRE

4.5.1 REPRISE DES DONNEES Pas d’objet. 4.5.2 FORMATION Le fournisseur doit préciser pour chaque type de formation nécessaire, par profil d’utilisateur, à l’utilisation du système (formation à l’exploitation générale du système, formation au paramétrage du système, formation des utilisateurs) :

• Profil utilisateur,

• Les pré requis attendus des participants,

• La durée,

• Le contenu,

4.5.3 MAINTENANCE & SUPPORT Le soumissionnaire présentera les dispositions mises en œuvre pour assurer la maintenance des composants fournis et le support à leur mise en œuvre pendant la période de garantie et au delà.

La maintenance attendue couvre non seulement les aspects curatifs, mais également les aspects évolutifs des composants, notamment ceux liés aux évolutions réglementaires.

Le soumissionnaire décrira précisément le système de prise en compte des demandes de l’établissement et le processus mis en œuvre pour y répondre.

4.5.3.1 Maintenance curative Une procédure de télémaintenance via nos équipements de sécurité, pourra être mise en œuvre pour permettre au soumissionnaire de se connecter au système afin d’établir son diagnostic et procéder, en coordination avec le service informatique de l’établissement aux modifications nécessaires.

Chaque intervention du soumissionnaire fera l’objet d’un compte rendu écrit indiquant la date, l’heure, l’intervenant, la nature de l’intervention et les modifications effectuées.

4.5.3.2 Maintenance préventive Afin d’éviter tout risque d’arrêt ou de perturbation du système le fournisseur devra indiquer dès la mise en place puis de manière suivie les différents contrôles à effectuer :

• fichiers de traces ou logs à surveiller,

• contrôles de taux de remplissage de base à effectuer,

• Contrôle des interfaces,

• précaution à prendre avant ou après un arrêt de l’application ou du serveur .....

Il devra mettre en place l’épuration automatique des fichiers de travail à supprimer dans des délais négociés avec le service informatique.


BLOC OPERATOIRE


Page 25

Le fournisseur pourra indiquer s’il livre des outils de surveillance de base ou tout autre outil visant à la prévention d’incidents.

Par la suite, les interventions du titulaire, dans le cadre des actions de maintenance préventive, devront s'effectuer sans perturber le fonctionnement du service et suivant un calendrier négocié annuellement avec le responsable du service. Elles donneront lieu à la signature d'une fiche d'intervention indiquant le jour, le temps passé, les éléments vérifiés ou remplacés.

4.5.3.3 Support Le soumissionnaire devra obligatoirement offrir un service de support aux utilisateurs avec un engagement sur le délai de prise en charge des appels et sur l’apport de réponse en cas de dysfonctionnement bloquant ou grave.

Le soumissionnaire devra présenter le processus mis en œuvre pour informer les utilisateurs sur l’avancement du traitement de leur demande :délai, statut, etc…

Le soumissionnaire devra également expliciter le processus de diffusion de l’information concernant le contenu des nouvelles versions, des patchs, etc…

4.5.4 CONDITIONS DE MISE EN ŒUVRE

Une réunion de lancement devra être organisée par le Centre Hospitalier conjointement avec le titulaire afin présenter à l’ensemble des acteurs majeurs du projet, son organisation, le système mis en œuvre et le planning prévisionnel d’actions.

4.6 DOCUMENTATION

La documentation du projet est exclusivement et impérativement en français.

Le fournisseur doit, dans sa documentation technique inclure le descriptif des bases de données et des fichiers qui sont ouverts à des produits externes.

La documentation utilisateur doit être fournie en français et réactualisée à chaque changement de version sous forme d’aide en ligne et de documentation accessible à partir du poste de travail des utilisateurs. Les utilisateurs devront avoir la possibilité d’éditer tout ou partie de la documentation en utilisant un outil bureautique sur leur poste de travail (Word, pdf…).

5. PRESENTATION DE L’OFFRE Le soumissionnaire devra présenter :

� Les licences logicielles de la solution proposée,

� Les droits d'usage des logiciels de type système d'exploitation, gestion de base de données seront présentés en option.

� En option, également, une configuration matérielle (équipement serveur) et matériel de lecture code à barre nécessaire pour la mise en œuvre de la solution.

� Les prestations d’installation technique et de mise en œuvre dans l’environnement technique du Centre Hospitalier de la solution.

� La fourniture et la mise en place des composants nécessaires pour l’intégration dans le système d’information du Centre Hospitalier.


BLOC OPERATOIRE


Page 26

� L’adaptation de la configuration permettant de répondre aux attentes du Centre Hospitalier exprimées dans le présent document.

� Une période de garantie au moins égale à 1 an à partir de la date de passage en mode opérationnel,

� Le support et la maintenance des composants mis en œuvre pour une durée de 4 ans après la fin de la période de garantie.

� Le détail des prestations proposées depuis l'étude préalable, l’installation du progiciel, le paramétrage, les tests jusqu’à l’admission définitive par le Centre Hospitalier ainsi que la formation. Le nombre de jours devra être détaillé par nature de prestations. Les frais de déplacement devront être inclus.

� Le détail de la charge en terme d’intégration au S.I.H. et les solutions permettant de respecter l’intégrité de toutes les bases de données du système d’information.

6. PLANNING Le fournisseur devra présenter un calendrier précisant le déroulement possible du projet en indiquant précisément :

� les pré-requis datés pour le déroulement du planning proposé.

� la charge de travail qui incombe à l’établissement par phase et par profil d’intervenant pour la mise en œuvre du projet, par exemple sous la forme d’un tableau de charges mensuel.

Ce calendrier sera mis à jour par le fournisseur au fur et à mesure de l’avancement du projet.


BLOC OPERATOIRE


Page 27

7. CADRE DE REPONSE Le fournisseur répondant à ce cahier des charges présentera son offre en plusieurs documents :

Document 1

� Présentation générale de la société.

� Joindre la liste des références de systèmes identiques installés dans d’autres Centres Hospitaliers ainsi que les coordonnées des personnes pouvant être contactées.

Document 2

Description fonctionnelle et technique de l’offre

Il s’agira dans un 1er temps de compléter les tableaux ci-dessous, décrivant les spécifications fonctionnelles et techniques attendues.

Le soumissionnaire présentera obligatoirement son offre en cochant la réponse adéquate en face de chaque fonctionnalité demandée. Il pourra compléter son offre par tout document de présentation complémentaire, permettant de détailler des points particuliers.

Codification utilisée :

1 : Indispensable au démarrage si cochée

2 : terme en nombre de mois pour indispensable à terme, F pour facultatif

3 : Opérationnel sur site

4 : En cours de réalisation ou planifié (préciser la date) (inclus dans l’offre de base)

5 : O pour réalisable sur devis, N pour ne sera pas réalisé

Remarques pour complément d’information ou renvoi à un document annexe.


BLOC OPERATOIRE


Page 28

7.1 TABLEAU DES FONCTIONNALITES ATTENDUES

1. Planification

Fonctionnalités Besoins Offre du fournisseur 1 2 3 4 5 Remarques

1.1. La solution logicielle doit être accessible en lecture et écriture par les chirurgiens et/ou leur secrétariat afin de planifier leurs interventions. L’accès peut être limité par secteur ou activité

X X

1.2. Lors de la planification de l'intervention, ils devront sur un espace fiche patient saisir (obligatoirement pour être validée), le nom, prénom, date de naissance du patient, l’intervention exacte, le côté si besoin, le temps d’intervention prévu, le type d’anesthésie souhaitée, les demandes particulières et le service d’hospitalisation.

Un lien avec les capacités d'hébergement sera apprécié.

X F

1.3. La saisie devra être réalisée sur un écran de qui présentera un affichage type grille horodatée de programmation indiquant les créneaux des chirurgiens. Sur cet écran, le chirurgien doit être en mesure de positionner ses interventions, dans les vacations qui lui sont allouées, en fonction du type d’acte et des temps réels d’occupation de la salle.

Le logiciel doit mettre en évidence les débordements de vacation tout en permettant néanmoins aux chirurgiens de la passer outre.

X

X

X

1.4. Les chirurgiens et/ou secrétaires auront accès en mise à jour à la planification jusqu’à une date butoir. Passé ce terme, ils pourront accéder en lecture mais, seul le cadre régulateur aura la possibilité de rajouter des interventions au programme

X

1.5. Les cadres des services de chirurgie doivent avoir en permanence accès à la planification en lecture.

Les cadres de bloc accèdent en mise à jour.

X

X

1.6. La planification est imprimable par tous. X 1.7. Lors de sa consultation ; l’anesthésiste aura accès à la

fiche d’intervention du chirurgien afin de valider l’intervention et de préciser le type d’anesthésie ainsi que les actes à effectuer (KTC, péri-…). Il complètera cette fiche en renseignant le temps nécessaire à l’anesthésie.

Cette fiche sera imprimable

X

X

X

1.8. Le programme ainsi planifié devra apparaître dès la programmation par le chirurgien. Un code couleur permettra de différencier l’intervention programmée par le chirurgien, puis validée par l’anesthésiste, enfin validée par la cellule de programmation ou le cadre régulateur

X

X


BLOC OPERATOIRE


Page 29

1.9. Le cadre de bloc pourra rajouter le nom des infirmières qui interviennent en salle.

X

2. supervision :


2.1. Le jour de l’intervention, le programme opératoire doit être disponible sur les postes de travail des services d’Ambulatoire et d’hospitalisation de Chirurgie, du sas d’entrée du bloc, de SSPI, du cadre régulateur de bloc.

X

2.2. Celui-ci doit être en mesure d’intervenir en permanence sur le programme afin de modifier l’ordre des interventions, un changement de selle, une annulation ou un rajout. La possibilité lui sera offerte de faire glisser les programmations d’une salle à une autre.

X X

2.3. Dans chaque salle, l’IBODE et L’IADE doivent obligatoirement tracer chaque matin l’ouverture de salle.

X

3. traçabilité / suivi des interventions :


3.1. Un poste de travail dans le sas d’entrée du bloc doit permettre de tracer l’arrivée et la sortie du patient. A l’entrée, l’identification du patient se fera en relation avec l’applicatif Clinicom par lecture des codes à barres de l’étiquette patient.

X

X

3.2. Dans chaque salle, l’IBODE et L’IADE doivent obligatoirement tracer chaque matin l’ouverture de salle.

X

3.3. Lors de chaque intervention, l’IBODE doit sélectionner l’identité du patient afin d’afficher automatiquement l’ensemble des informations déjà établies lors de la programmation. Ces données sont modifiables.

X X

3.4. L’IBODE complète ses informations en renseignant tous les intervenants, le type d’installation, la détersion et l’antisepsie utilisée, le positionnement de l’électrode du coagulateur électrique, la pose du garrot (heures de début et de fin), les matériels utilisés (instrumentation réstérilisable par interface avec la stérilisation et reconnaissance des codes à barres), les DM posés (interface avec Pharma), les actes d’imagerie (imprimés en SSPI), les examens histologiques ou bactério, le compte des champs, compresses, les systèmes de drainage, la fermeture, le pansement, les commentaires éventuels. Utilisation de douchettes pour la saisie des DM

X X


BLOC OPERATOIRE


Page 30

3.5. L’ensemble de ces informations devra être saisi de la manière la plus simple possible (cases à choix multiple, liste déroulante) Compatibilité écrans tactiles.

Etendue de l’interface tactile.

X

X

F

3.6. L’infirmière devra pouvoir de manière simple valider les horaires d’entrée en salle, d’induction, d’incision, de fermeture, de sortie de salle, de fin de bio nettoyage et tous les éléments nécessaires au calcul des indicateurs d’activités.

X

3.7. La solution devra permettre la mise à disposition des indicateurs d'activité selon les principes "MEAH" - TROS, etc.

X

3.8. De la même façon, la feuille HAS devra être générée automatiquement.

X

3.9. Le codage des actes par le chirurgien sera intégré dans la solution et l’interfaçage avec le volet activité du dossier médical sera disponible.

F

3.10. Un bouton d’appel contextuel à l’applicatif de dossier médical de l’établissement doit être disponible en permanence sur les écrans de la solution.

X

4. Intégration SIH :

Fonctionnalités Besoins Offre du fournisseur Identification du patient 1 2 3 4 5 Remarques

4.4.1.1. Interfaçage avec le référentiel identité de Clinicom via l'outil openlink

X

4.4.1.2. Cohérence des données en se basant sur le n° IPP et le n° d’épisode

X

4.4.1.3. Prise en compte des évènements pertinents du référentiel identités au format HL7 v2.3

X

Gestion de la stérilisation 4.4.2.1. Transmission des informations nécessaires à la traçabilité.

X

4.4.2.2. Cohérence et liaison des référentiels ‘’produits’’. X Dossier médical commun 4.4.3.1. Appel contextuel Medis X 4.4.3.2. Transfert document historique de l’intervention vers Medis

X

Circuit du médicament et des dispositifs médicaux 4.4.5.1. Cohérence et liaison des référentiels ‘’produits’’. X 4.4.5.2. Description des mécanismes d’échanges de données produits.

X

4.4.5.3. Appel contextuel Pharma (prescription) X


BLOC OPERATOIRE


Page 31

Anesthésie 4.4.6.1. Appel contextuel Osoft X 4.4.6.2.

Résultats de laboratoire 4.4.7.1. Appel contextuel SRI X

Environnement technique 4.4.8.1. Compatibilité système d’exploitation X 4.4.8.2. Adéquation des postes de travail X 4.4.8.3. Usage de lecteurs code à barre X 4.4.8.3. Compatibilité parc d’impression X 4.4.8.4. Prise en compte des évènements pertinents du référentiel identités au format HL7 v2.3

X

4.4.8.5. Possibilité de reprise en cas de coupure de connexion X 4.4.8.6. Engagement sur la continuité de service F 4.4.8.7. Système alternatif léger en cas d’arrêt de la production X 4.4.8.8. possibilité de reprise des données après arrêt F 4.4.8.9. système de sauvegardes X 4.4.8.10. Ergonomie du logiciel X 4.4.8.11. Compatibilité des outils bureautiques X 4.4.8.12. Prise en compte de l’archivage X 4.4.8.13. Possibilité d’import de référentiels internes F 4.4.8.14. Estimation charge paramétrage X 4.4.8.15. Outil de requête sur la base de donnée X

4. Mise en oeuvre :


4.5.1. Description des modalités des formations. X 4.5.2. Description de l’offre de maintenance. X 4.5.3. Description du processus de mise en œuvre d’une action de maintenance.

X

4.5.4. Existence d’outils et de signalement et de contrôles. F 4.5.5. Support et engagement de délai. Suivi de l’avancement des demandes.

X

4.5.3. Documentation. X


BLOC OPERATOIRE


Page 32

5. Présentation de l’offre :


5.1. Présentation de l’offre. X 5.2. Période de garantie. X 5.3. Maintenance 4 ans après fin de garantie. X 5.4. Détail des prestations. X 5.5. Détail des charges d’intégration. X


BLOC OPERATOIRE


Page 33

ANNEXES


BLOC OPERATOIRE


Page 34

Liste des messages HL7

Evénement Message associé

Préadmission d’un hospitalisé A05 – Préadmission d’un patient pour hospitalisation Admission d’un patient hospitalisé A01 – Admission d’un patient Admission d’un patient pour séance A01 – Admission d’un patient Admission patient externe A04 – Admission d’un patient externe Admission d’un patient aux urgences A04 – Admission d’un patient externe (UF urgence) Confirmation de préadmission d’un patient hospitalisé A01 – Admission d’un patient Bascule urgences � hospitalisé A06 – Changement de statut urgences vers hospitalisé Bascule urgences � externe A07 – Changement de statut urgences vers externe Naissance d’un nouveau-né A01 – Admission d’un patient Annulation d’une admission A11 – Annulation de l’admission Modification état civil du patient A08 – Mise à jour du patient Modification d’une préadmission ou d’admission hospitalisé (date, UF)

A08 – Mise à jour du patient

Modification d’une admission hospitalisé (date, UF) A08 – Mise à jour du patient Modification d’une admission externe (date, UF) A08 – Mise à jour du patient Modification d’un passage aux urgences (date, UF) A08 – Mise à jour du patient Modification naissance nouveau-né (date d’entrée) A08 – Mise à jour du patient Séance élémentaire A01 – Admission Venue (dans le cadre des consultants permanents) élémentaire

A04 – Admission d’un patient externe

Annulation de séance élémentaire A12 – Suppression mutation Modification sur séance ou venue (date, UF) élémentaire


Sortie définitive A03 – Sortie de l’établissement du patient Modification d’une sortie définitive (date de sortie, mode de sortie)


Annulation d’une sortie définitive A13 – Annulation d’une sortie Départ en permission A21 – Sortie temporaire Retour de permission A22 – Retour de sortie temporaire Annulation de départ en permission A52 – Annulation de sortie temporaire Modification de date de départ en permission A08 – Mise à jour du patient Modification de date de retour de permission A08 – Mise à jour du patient Mutation (changement d’UF) A02 – Mutation Changement de chambre ou de lit A02 – Mutation Annulation de mutation A12 – Suppression mutation Correction de mouvement (date d’entrée, UF) A08 – Mise à jour du patient Annulation de mutation A12 – Suppression mutation Annulation d'une préadmission A38 – Annulation d'une préadmission Fusion d’identités (dossiers patients) A40 – Fusion de dossier


BLOC OPERATOIRE


Page 35

Informations traçabilité PHARMA