13.Exigences opérationnelles et exigences relatives à l’environnement
Contrairement au chapitre 3, qui spécifie des contraintes externes, incontournables et préexistantes au système, ce chapitre spécifie des contraintes propres au système qui fait l’objet du présent cahier des charges.
13.a.Environnement physique prévu
Les postes de travail fixes sont implantés :
A l’accueil (bureau des entrées ou bureau des admissions/consultations)
Dans le bureau des médecins et des paramédicaux
Dans le bureau des secrétaires médicales
Dans les box de consultation
Aux postes de soins (IDE)
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.
13.b.Exigences d’interopérabilité
La communication entre composants du système d’information est une exigence essentielle. La notion d’interfaces entre progiciels composant le SIH global est donc vitale pour l’Établissement.
Une interface entre 2 progiciels consiste en général à transmettre des données via un fichier intermédiaire. On parlera donc, dans la suite de ce chapitre de demi-interface.
Pour réaliser une interface entre les progiciels A et B, A et B étant édités par des sociétés différentes, il y aura donc réalisation :
D’une demi-interface A vers le fichier intermédiaire réalisée et maintenue par le fournisseur du progiciel A.
D’une demi-interface fichier intermédiaire vers B réalisée et maintenue par le fournisseur du progiciel B.
Ces demi-interfaces entre progiciels peuvent être de type « temps réel » ou de « type tâche de fond ».
Pour chaque demi-interface faisant partie de l’offre du soumissionnaire, préciser :
- Quel est le mode de fonctionnement technique (voir ci-dessus),
- Quels sont les données ou groupes de données transmises,
- Quelle est la norme utilisée (HL7, etc. …)
- S’il y a utilisation ou non d’un EAI, ESB, ETL, Webservice
On distingue 2 catégories de demi-interfaces :
- Demi-interfaces entre progiciels proposés (le cas échéant),
- Demi-interfaces entre les progiciels faisant l’objet de la présente consultation et les progiciels existants dans l’Établissement.
13.b.1.Développement des demi-interfaces entre progiciels proposés
Si les progiciels ont été conçus par le même éditeur, ce chapitre est en général sans objet.
Si ce n’est le cas :
Le soumissionnaire décrira les interfaces à mettre en place entre ces progiciels tant sous l’angle technique (en particulier, la norme utilisée) que sous l’angle fonctionnel :
lorsque des standards sont mis en œuvre, le soumissionnaire indiquera précisément les standards utilisés.
lorsqu’il n’existe pas de standard, le soumissionnaire indiquera les mécanismes utilisés.
Il précisera si ces interfaces sont déjà opérationnelles dans la configuration exacte demandée par l’établissement de santé et si tel est le cas fournira la liste des établissements Hospitaliers où ces interfaces sont implantées.
13.b.2.Développement des demi-interfaces avec progiciels existants Exigences génériques d’interfaçage
ASIP Santé (F.M.) 20/07/2011
Les exigences générales d’interopérabilité avec les progiciels de l’établissement sont, par ordre de priorité décroissante, les suivantes :
1. des mécanismes conformes IHE, incluant les extensions nationales d’IHE France, dans leur version la plus récente de leur déclinaison française publiée par le représentant français d’IHE
2. les standards préconisés par la profession dans leur version la plus récente
3. des mécanismes non standard, proposés par le soumissionnaire. Dans ce dernier cas, le soumissionnaire indiquera les standards utilisés, les mécanismes utilisés, le format des messages utilisés et la sémantique retenue
Actuellement, le représentant français d’IHE est Interop’santé. Vérifier ce point avant publication du cahier des charges et préciser éventuellement.
Le soumissionnaire spécifiera les mécanismes qui seront mis en œuvre pour permettre à l’utilisateur d’accéder à des informations spécifiques du dossier patient, notamment
avec le logiciel de prescription d’examens XXX
pour la récupération des données médicales (antécédents, allergies)
pour la récupération des documents médicaux
Schéma synoptique d’interopérabilité
ASIP Santé (FM) 09/11/2011
Modifier le schéma ci-dessous en fonction de l’existant de votre établissement.
Les profils et acteurs à utiliser avec chaque logiciel du [Etablissement X] sont décrits dans le tableau suivant
Modifier en fonction de l’existant de votre établissement.
Type de flux
|
Système
|
Acteur du système
|
Profil
|
Acteur du dossier médical
|
Mouvement
|
GAM
|
PES
|
PAM
|
PEC
|
Identités
|
GAM ou serveur d’identités
|
PDS
|
PAM
|
PDC
|
PDS
|
PDQ
|
PDC
|
Document (CR)
|
Bureautique
|
Aucun référentiel n’est disponible à ce jour.
Si documents, se conformer aux standards CDA du cadre d’interopérabilité de l’ASIP Santé.
|
Données médicales
Document (CR)
|
Dossier de spécialités
|
Aucun référentiel n’est disponible à ce jour.
Si documents, se conformer aux standards CDA du cadre d’interopérabilité de l’ASIP Santé.
|
Données médicales et documents (C.R.)
|
Dossier de soins paramédical
|
Aucun référentiel n’est disponible à ce jour.
Si documents, se conformer aux standards CDA du cadre d’interopérabilité de l’ASIP Santé.
|
Demandes d’examens, résultats d’examens
|
Demandes et résultats d’examens
|
Les échanges entre les fonctions demandes et résultats d’examens et les autres systèmes sont largement détaillés dans le CDC type correspondant.
|
Alimentation du DMP
|
DMP
|
Doc repository
|
XDS
|
Doc Source (DS)
|
DMP
|
Doc registry
|
XDS
|
Doc Administrator (DA)
|
Consultation du DMP
|
DMP
|
Doc repository
|
XDS
|
Doc Consumer (DC)
|
DMP
|
Doc registry
|
XDS
|
Doc Consumer (DC)
|
Création du DMP
|
DMP
|
La création du DMP ne s’appuie sur aucun profil IHE, cependant dans le cadre d’interopérabilité (CI-SIS) est défini un flux normalisé pour la création du DMP.
|
Prescription
Données médicales
|
Logiciels de prescription
|
Aucun référentiel n’est disponible à ce jour.
Si documents, se conformer aux standards CDA du cadre d’interopérabilité de l’ASIP Santé.
|
Données médicales
|
Dispensation
|
Aucun référentiel n’est disponible à ce jour.
|
Images (Visualisation des images + objets associés)
|
PACS
(système d’archivage des images)
|
-
|
-
|
Image Display
|
Actes réalisés, diagnostics
|
PMSI
|
-
|
HPRIM-XML
|
-
|
Interface avec le système de gestion administrative du patient pour les données d’identité et de mouvements.
ASIP santé (FM) 09/11/2011
Le système doit mettre en œuvre les acteurs « Patient Demographics Consumer » (PCD) et « Patient Encounter Consumer » (PEC) des profils IHE PAM et PDQ.
Le système doit mettre en œuvre les acteurs « Patient Encounter Supplier » (PES) et « Patient Encounter Consumer » (PEC) du profil IHE PAM.
Le soumissionnaire décrira comment il envisage la communication d’identité et quelles en sont les limitations.
IHE PAM est le profil qui coordonne les échanges d’information relatives au patient, complété le cas échéant par le profil IHE PDQ
Interface avec le logiciel de prescription et de dispensation
Demande d’actes ou prescription, en fonction de l’existant dans l’établissement
Interface avec le DMP
Le système doit permettre de gérer à la fois l’import de documents contenus dans le DMP (antécédents, résumé des épisodes précédents) et son alimentation (compléments avec l’épisode en cours). Ces actions nécessitent l’utilisation de la carte CPS.
Le profil IHE XDS régit les échanges avec l’infrastructure de partage de documents. Ces documents sont au format HL7 CDA.
PMSI
L’enregistrement dans le PMSI des actes réalisés et les diagnostics posés se conforment aux standard XPRM XML.
La recommandation HPRIM XML décrit un langage XML d’échange de messages entre acteurs de santé. Plus précisément, cette recommandation décrit le contenu et le format de ces messages XML.
XML (eXtended Markup Language) est un standard issu du croisement de la gestion documentaire et de l’internet. C’est un langage de description de documents, séparant contenu, structure et présentation.
Interface avec les autres volets du Dossier Patient
Concernant le Dossier de soins, il n’existe à ce jour aucun référentiel d’interopérabilité.
Pour les Dossiers de spécialité, la Bureautique et les logiciels d’aide à la prescription et à la dispensation, le partage de documents et de métadonnées associées se conformera aux standards du CI-SIS de l’ASIP Santé (standard CDA).
Interface avec les demandes et résultats d'examens
Ces interfaces sont largement détaillées dans le cahier des charges-type demandes et résultats d'examens
13.c.Exigences d’installation, de mise en exploitation et de 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.
13.d.Exigences concernant la livraison des versions
Le soumissionnaire doit s’engager à adapter son système aux évolutions réglementaires et à livrer les versions correspondantes à leur date de mise en application. Il précisera, dans sa réponse, les modalités de mise à disposition des mises à jour et des nouvelles versions du logiciel.
À moins que cela soit imposé par une évolution réglementaire, les nouvelles versions fournies par le soumissionnaire ne régresseront pas sur le plan fonctionnel.
|
