CDC Projet Final-3

Dossier Patient Informatisé – Cahier des charges
L’Equipe ASBL
Dossier Patient Informatisé

Cahier Spécial des Charges informatique
Référence du marché : 16 12 08
Date et heures ultimes de remises des offres ainsi que de l’ouverture des offres :
le lundi 6 février 2017 à 10h00 précises
Personne de contact à l’ASBL L’Equipe : Mme Isabelle De Schutter.

Email : i.deschutter@equipe.be
1 / 83
Sommaire
1. CLAUSES ADMINISTRATIVES ET CONTRACTUELLES 5

1.1. CLAUSES ADMINISTRATIVES 5
1.1.1. IDENTITE DU POUVOIR ADJUDICATEUR 5
1.1.2. OBJET DU MARCHE 5
1.1.3. DUREE DU MARCHE 5
1.1.4. CONDITIONS DE PASSATION DU MARCHE 5
1.1.4.1. Mode de passation du marché 5
1.1.4.2. Attribution 5
1.1.5. OBTENTION DU CAHIER SPECIAL DES CHARGES 6
1.1.6. QUESTIONS RELATIVES A L'APPEL D'OFFRES 6
1.1.7. MODALITES DE PRESENTATION DES OFFRES 6
1.1.8. DEPOT ET OUVERTURE DES OFFRES 6
1.1.9. DUREE DE VALIDITE DES OFFRES 7
1.1.10. CAUTIONNEMENT 7
1.1.11. PRIX 7
1.2. CLAUSES CONTRACTUELLES 8
1.2.1. LEGISLATION APPLICABLE 8
1.2.2. ARTICLES 58 A 79 DE L’AR PASSATION DU 15 JUILLET 2011 : SELECTION DES CANDIDATS ET DES
SOUMISSIONNAIRES – DROIT D'ACCES ET SELECTION QUALITATIVE 8
1.2.2.1. Droits d’accès 8
1.2.2.2. Sélection qualitative 8
1.2.3. ARTICLE 101 DE L’AR PASSATION DU 15 JUILLET 2011 : CRITERES D’ATTRIBUTION 9
1.2.4. PLANNING 10
1.2.5. RESPONSABILITE DU PRESTATAIRE DE SERVICES 10
1.2.6. ANALYSE 10
1.2.7. RECEPTION DES SERVICES PRESTES 11
1.2.7.1. Réceptions provisoires partielles 11
1.2.7.2. Réception définitive 11
1.2.8. GARANTIE 11
1.2.9. EXECUTION DES SERVICES 12
1.2.9.1. Conditions de l'exécution 12
1.2.9.2. Personnel de l’ASBL L’Equipe 12
1.2.9.3. Personnel du prestataire 12
1.2.9.4. Suivi de la bonne exécution des livraisons et des services 12
1.2.10. PROPRIETE DES SOFTS DEVELOPPES 12
1.2.10.1. Propriété intellectuelle 12
1.2.10.2. Code source 12
1.2.11. FACTURATION ET PAIEMENT 13
1.2.12. ENGAGEMENTS PARTICULIERS POUR LE PRESTATAIRE DE SERVICES 13
1.2.13. STOCKAGE PHYSIQUE DES DONNÉES 13
1.2.14. SOUS-TRAITANCE 13
1.2.15. OBLIGATIONS DES PARTIES 14
1.2.16. AMENDES ET PÉNALITÉS 14
2. CLAUSES TECHNIQUES 15
2.1. INTRODUCTION 15
2.1.1. OBJECTIFS DE L’ASBL L’EQUIPE 15
2 / 83
2.1.2. PHASAGE DU PROJET 15

2.1.3. BENEFICES ATTENDUS 15
2.1.4. OBJET DU MARCHE 15
2.2. CONTEXTE DU PROJET 16
2.2.1. DESCRIPTION GENERALE DE L’ASBL L’EQUIPE 16
2.2.2. STRUCTURE DE GOUVERNANCE 16
2.2.3. DESCRIPTIF DE LA MISSION 17
2.2.4. SITUATION ACTUELLE DU SYSTEME D’INFORMATION ADMINISTRATIF 17
2.2.4.1. Infrastructure existante 17
2.2.4.2. Environnement de développement, de test, d'intégration et de production 17
2.2.4.3. Logiciels installés 17
2.2.4.4. Volumes 18
2.3. SPECIFICATIONS FONCTIONNELLES 18
2.3.1. GENERALITES 18
2.3.1.1. Architecture et intégration du DPI 18
2.3.1.2. Intégration du logiciel « gestion des médicaments », Evolutive Compta 18
2.3.1.3. Performances 19
2.3.1.4. Sécurité des données et droits d’accès 19
2.3.1.5. Traçabilité 20
2.3.1.6. Légalité et conformité 20
2.3.1.7. Tests et plans qualité 20
2.3.1.8. Evolutivité 20
2.3.2. POSTES A REALISER 20
2.3.2.1. Accès au DPI 20
2.3.2.2. Nomenclatures et codifications 21
2.3.2.3. Structure générale du DPI 21
2.3.2.4. Fonctionnalités du DPI 22
2.3.3. MODE DEGRADE 27
2.4. SERVICES A FOURNIR 28
2.4.1. GESTION DU PROJET 28
2.4.2. TRANSFERT DE CONNAISSANCES 28
2.4.3. ASSISTANCE COMPLEMENTAIRE 28
2.4.4. TRANSFERABILITE 28
2.4.5. MAINTENANCE ET SUPPORT 29
2.5. SLA 29
2.5.1. INTRODUCTION 29
2.5.2. ELABORATION DES SLA DANS LE CADRE DE CE MARCHE 29
2.5.3. REPORTING 30
ANNEXE 1 ETAT ACTUEL DE L'INFRASTRUCTURE ET DU RESEAU LOCAL 31
ANNEXE 2 STRUCTURE GENERALE DU DPI 38
ANNEXE 3 BELGIAN MEANINGFUL USE CRITERIA FOR OTHER HOSPITALS 51
ANNEXE 4 PROCESSUS ACTUELS ET PROCESSUS FUTURS 62
ANNEXE 5 STRUCTURE DE L'OFFRE 78
C. VOLET "ANNEXES" 83
3 / 83
4 / 83
1. CLAUSES ADMINISTRATIVES ET CONTRACTUELLES
1.1. Clauses administratives

1.1.1. Identité du Pouvoir adjudicateur
Le pouvoir adjudicateur est l’ASBL L’Equipe établie à 1070 Bruxelles rue de Veeweyde 60.
Ses représentants sont :
Monsieur D. Depuydt, directeur administratif et Madame I. De Schutter, gestionnaire du projet Dossier Patient
Informatisé.
La personne habilitée à veiller à la bonne exécution du marché est :

Monsieur D. DEPUYDT (tél. 02 556.28.30 mail : d.depuydt@equipe.be).
1.1.2. Objet du marché

Le présent marché de services porte sur l'analyse, le développement, la livraison, la mise en production y
compris les tests préalables et les services de formation et de maintenance d’un logiciel de gestion du dossier
patient informatisé (DPI) en psychiatrie.
Le présent appel d'offres vise à sélectionner un prestataire capable de proposer un tel logiciel pouvant
s'intégrer à l'environnement technique de l'ASBL L'Equipe et, si une version de base du logiciel existe déjà mais
ne dispose pas de toutes les fonctionnalités requises, de proposer les adaptations nécessaires selon les
spécifications du présent cahier des charges.
Le logiciel doit être conforme aux prescriptions du présent cahier spécial des charges et accompagné de toutes
les prestations nécessaires à sa mise en production au sein des locaux de l'ASBL L'Equipe et à sa maintenance
durant les 5 premières années après la réception définitive.
Les variantes et options au cahier des charges sont acceptées.
1.1.3. Durée du marché

Le marché débute à la date de conclusion du marché.
La durée du marché comprend deux parties :
 La durée d’analyse du projet, du développement du logiciel et de sa mise en œuvre.

Cette première partie se clôture avec la réception définitive.
 Suite à la réception définitive, la seconde partie du marché permettant d’assurer la maintenance

globale de l’ensemble de la solution débute pour une durée de 5 ans.
Cette durée est motivée par le souhait de l’ASBL L’Equipe de s’investir dans un logiciel adapté à ses besoins et
de s’assurer de l’entretien de cet outil spécifique sur un moyen terme.
1.1.4. Conditions de passation du marché

1.1.4.1. Mode de passation du marché
Le présent marché fait l’objet d’un appel d’offres ouvert.
1.1.4.2. Attribution
L’ASBL L’Equipe n’est tenue par aucune obligation d’attribuer le présent marché et se réserve le droit soit de
renoncer complètement à attribuer le marché, soit de recommencer la procédure de passation, au besoin
suivant un autre mode de passation. La renonciation à attribuer le présent marché ne crée aucun droit à
indemnisation en faveur des candidats ou soumissionnaires, quel que soit le stade de la procédure de passation
auquel cette renonciation a lieu.
5 / 83
1.1.5. Obtention du Cahier Spécial des Charges

Le Cahier Spécial des Charges informatique de ce marché peut être obtenu sans frais sur simple demande par
e-mail envoyée à l'adresse : i.deschutter@equipe.be.
Il est également téléchargeable via le site de l'ASBL L'Equipe : www.equipe.be
1.1.6. Questions relatives à l'appel d'offres

Toute question ou demande d’éclaircissement concernant cet appel d'offres peut être adressée à Isabelle De
Schutter, par voie électronique, i.deschutter@equipe.be ou par courrier à Isabelle De Schutter, ASBL L’Equipe,
rue de Veeweyde 60 à 1070 Bruxelles. Toutes les questions et toutes les réponses échangées avec un
soumissionnaire potentiel seront publiées et consultables sur notre site internet www.equipe.be
L'ASBL L'Equipe a décidé d'organiser deux séances publiques d'information à l'intention des soumissionnaires
potentiels. Les séances se tiendront le 12 janvier 2017 à 10h00 et le jeudi 19 janvier 2017 à 10h00, en présence
du directeur administratif de l'ASBL L'Equipe, du gestionnaire de projet, du responsable informatique et d'un
1
représentant de la société Logal (fournisseur du logiciel de facturation et gestion des médicaments).
Dans la mesure du possible, les entreprises intéressées sont invitées à se faire connaître avant la première
séance publique d’information en envoyant un mail à l'adresse i.deschutter@equipe.be. Les réponses aux
questions seront données oralement durant la séance d'information, puis publiées sur le site internet de l'ASBL,
www.equipe.be
1.1.7. Modalités de présentation des offres

Sous peine d’irrégularité, l’offre doit être rédigée en français et structurée selon les prescriptions du présent
cahier spécial des charges (Cfr Annexe 5). Cependant les annexes techniques pourront être fournies en anglais,
s’il s’avère qu’elles n’existent pas en français.
Les conditions générales de vente éventuellement imposées par les soumissionnaires sont déclarées nulles et
non avenues, même si l’offre s’y réfère expressément, et sont remplacées par les prescriptions du présent
cahier spécial des charges.
Remarque importante :
Du fait du dépôt de son offre, le soumissionnaire reconnaît :
1. avoir eu la possibilité de se rendre compte de l’importance et de toutes les particularités de

l’exécution du marché;
2. avoir obtenu les renseignements qu’il désirait ;
3. avoir pu présenter à l’ASBL L’Equipe toutes les observations et demandes qu’il a crues utiles ;
4. avoir établi le montant de son offre en toute connaissance de cause, rien ne lui étant vague ou
inconnu.
L’offre écrite doit être complète et établie selon la structure du cahier spécial des charges. A cet effet, le
soumissionnaire remplira de manière aussi complète que possible, les rubriques reprises en annexe 5.
1.1.8. Dépôt et ouverture des offres

Les offres doivent parvenir en trois exemplaires sous pli définitivement fermé, à l’ASBL L’Equipe, rue de
Veeweyde 60 à 1070 Bruxelles à l'attention de Monsieur D. DEPUYDT, Directeur administratif pour le
06/02/2017 à 10 heures au plus tard.
L'offre sera accompagnée d'une copie sur un support électronique courant (format PDF).
1
Cfr point 2.2.4.3.1 et point 2.3.1.2
6 / 83
Les offres pourront soit :
1. être déposées à l'accueil du siège social (le Jade) au 60 rue de Veeweyde à 1070 Bruxelles, du
lundi au vendredi entre 9h et 17h ;
2. être envoyées sous pli recommandé à l’adresse postale : ASBL L’Equipe, Rue de Veeweyde 60 à
1070 Bruxelles, – ce pli scellé portera la mention "Marché de services : Dossier Patient Informatisé
– Offre". Conformément à l’article 90, § 2 de l’Arrêté royal du 15 juillet 2011 relatif à la passation
des marchés publics dans les secteurs classiques, toute offre doit parvenir au président de séance
avant qu'il ne déclare la séance ouverte. Quelle qu'en soit la cause, les offres parvenues
tardivement auprès du président sont refusées ou conservées sans être ouvertes. Toutefois, une
telle offre est acceptée pour autant que l’ASBL L’Equipe n'ait pas encore conclu le marché et que
l'offre ait été envoyée sous pli recommandé, au plus tard le quatrième jour de calendrier
précédant la date de l'ouverture des offres.
L’ouverture publique des offres s’effectuera le 06/02/2017 à 10 heures au siège social de l’ASBL L’Equipe, Rue
de Veeweyde 60 à 1070 Bruxelles. Les prix soumissionnés ne seront pas proclamés.
1.1.9. Durée de validité des offres

En dérogation à l’article 57 de l’Arrêté royal du 15 juillet 2011 relatif à la passation des marchés publics dans les
secteurs classiques, la durée pendant laquelle les soumissionnaires restent engagés par leur offre est de 120
(cent vingt) jours de calendrier prenant cours le lendemain du jour de l’ouverture des offres.
1.1.10. Cautionnement
er
En dérogation à l’article 25, § 2, al. 1 de l’Arrêté royal du 14 janvier 2013 établissant les règles générales
d'exécution des marchés publics et des concessions de travaux publics, le cautionnement est fixé à 2% du
montant initial du marché, hors maintenance, et arrondi à la dizaine d’euros supérieure. La libération de ce
cautionnement a lieu conformément à l’article 33 de l’Arrêté royal du 14 janvier 2013 établissant les règles
générales d'exécution des marchés publics et des concessions de travaux publics.
1.1.11. Prix
Les prix sont libellés en Euros TVAC.
Le prix doit être détaillé en deux parties principales et leurs sous-parties :
 Les montants relatifs à l’analyse, au développement du logiciel, à la mise en œuvre y compris les tests
2
et la formation des utilisateurs selon le phasage prévu par le soumissionnaire. Ces montants seront
clairement distingués dans l’offre.
Cette partie est à prix global sans clause de révision des prix.
 Les montants relatifs à la maintenance durant 5 ans après la réception définitive.

Cette partie est soumise à révision des prix selon l’indexation des prix à la consommation.
Les montants relatifs aux variantes et options seront présentés de manière séparée en annexe à l’offre
principale.
Le prix inclura tous les frais tels que licences, taxes,…
Les paiements des montants dus au prestataire de services doivent intervenir dans le délai de paiement de
trente jours à compter de la date de la fin de la vérification visée à l'article 156 de l’Arrêté royal du 14 janvier
2
Cfr point 2.3.2.4
7 / 83
2013, pour autant que le pouvoir adjudicateur soit en possession des factures régulièrement établies ainsi que
des autres documents éventuellement exigés.
1.2. Clauses contractuelles

1.2.1. Législation applicable
Le présent marché est régi exclusivement par la réglementation relative aux marchés publics, à savoir :
 La Loi du 15 juin 2006 relative aux marchés publics et à certains marchés de travaux, de fournitures et
de services (M.B., 15 février 2007) ;
 La Loi du 17 juin 2013 relative à la motivation, à l'information et aux voies de recours en matière de
marchés publics et de certains marchés de travaux, de fournitures et de services (M.B., 21 juin 2013) ;
 L’Arrêté royal du 15 juillet 2011 relatif à la passation des marchés publics dans les secteurs classiques
(M.B., 9 août 2011) (ci-après l’« AR Passation du 15 juillet 2011 ») ;
 L’Arrêté royal du 14 janvier 2013 établissant les règles générales d'exécution des marchés publics et
des concessions de travaux publics (M.B., 14 février 2013) ;
 Toutes les modifications aux lois et arrêtés précités, pour autant qu’elles soient en vigueur au jour de
l’ouverture des offres ;
 Le présent cahier spécial des charges.
1.2.2. Articles 58 à 79 de l’AR Passation du 15 juillet 2011 : Sélection des candidats et des
soumissionnaires – Droit d'accès et sélection qualitative
1.2.2.1. Droits d’accès
Les soumissionnaires, par le simple fait d’introduire une offre, déclare implicitement sur l’honneur qu’ils ne se
trouvent pas dans un des cas d’exclusion du marché. La déclaration en annexe 5, volet A.1, dûment remplie
sera jointe à l’offre.
Au terme de la sélection, le soumissionnaire le mieux classé sera invité à fournir dans les 8 jours calendrier tous
les documents prouvant qu’il répond aux exigences de l’article 61 de l’Arrêté Royal du 15 juillet 2011 et en
particulier en matière d’extrait de casier judiciaire, attestation concernant les cotisations sociales, …
1.2.2.2. Sélection qualitative

 Capacité financière et économique
Etant donné la spécificité du marché pouvant s’adresser à des soumissionnaires de taille très
différentes, la capacité financière et économique sera évaluée sur la base du chiffre d’affaire réalisé
dans le secteur de l’ingénierie informatique au cours des trois dernières années ou une évaluation
3
dûment documentée du chiffre d’affaire « théorique » produit par le soumissionnaire au cours des
trois dernières années.
Annexe 5, volet A.2.1
 Capacité technique ou professionnelle
Le soumissionnaire fournira annexé à son offre :
o Une description technique de l'entreprise et de ses sous-traitants, du personnel et des
moyens mis en œuvre qui permettent à l’ASBL L’Equipe d'évaluer la manière dont l'entreprise
peut garantir l'exécution du marché ;
o Les références, c'est-à-dire la liste des institutions dans lesquelles le soumissionnaire et/ou
ses sous-traitants ont fourni, mis en place et mis en service des systèmes informatiques au
3
Théorique : par exemple, le cas d’un employé qui aura développé pour le compte de son employeur
une solution informatique. Il s’agit d’une plus-value apportée à son employeur dont le soumissionnaire
évaluera l’importance financière.
8 / 83
cours des 3 dernières années (montants, dates de début et de fin de projet, résumé du
périmètre du marché, les destinataires avec le téléphone ou e-mail d'une personne de
contact pour chaque référence) ;
o L'engagement stratégique du soumissionnaire et de ses sous-traitants dans le secteur
hospitalier et sa politique d'évolution logicielle ;
o Capacité de maintenance : le soumissionnaire joint également à son offre, le cas échéant, des
pièces attestant que la maintenance fait partie de ses activités ou de celles de ses sous-
traitants;
o Les CV des membres de son personnel et du personnel de ses sous-traitants qui seront
affectés au présent marché.
Annexe 5, volet A.2.2
1.2.3. Article 101 de l’AR Passation du 15 juillet 2011 : Critères d’attribution

L’attribution du marché se fera sur base de l’offre régulière jugée la plus intéressante compte tenu des critères
suivants, chacun d'eux étant pondéré selon les points indiqués :
La qualité de la solution proposée (30 points sur 100) basée entre autres sur :
 La présence des fonctionnalités demandées dans une version déjà existante du logiciel. Le
soumissionnaire veillera à joindre à l’offre des éléments pertinents démontrant le fonctionnement et
la couverture de l’application (version démo, copies d’écran, …);
 La possibilité de développement des fonctionnalités manquantes ;
 la richesse fonctionnelle, les possibilités de paramétrage et les paramètres offerts par défaut ;
 la conception de l’interface utilisateur : ergonomie et facilité d'utilisation ;
 l'aspect technique de la solution :
o la conception logicielle, la qualité du code et ses tests ;
4
o l'environnement informatique ,
o la liaison de la solution DPI du soumissionnaire au logiciel existant gérant la facturation et la
gestion des médicaments au sein de l'ASBL L'Equipe ;
o l'ouverture vers d’autres logiciels hospitaliers (non couverts par le présent appel d’offres);
 La sécurité des données ;
 La solution en mode dégradé ;
 …
La qualité des services (30 points sur 100) basée entre autres sur:
 la méthodologie des services d'implémentation ;

 l’évaluation des besoins et l’intégration du personnel de l’Equipe
 l'étendue de l'assistance à la mise en production ;
 La formation des utilisateurs ;
 Les SLA ;
o Le taux de disponibilité du logiciel ;
o la couverture de maintenance ;
o la couverture du service d'assistance ;
o la procédure de traitement des incidents.
o Les reportings
o …
4
Prescriptions du prestataire : matériels (serveurs, postes, réseau, …) et d'outils système (OS, SGDB, …).
9 / 83
 La couverture de transférabilité des services en cas de désastre ;

 la solidité des accords formels pris avec les sous-traitants éventuels tant au niveau de la sécurité de
l’échange de données que de la permanence du service en cas de besoin d’assistance ;
 …
Le coût global (30 points sur 100), détaillé comme décrit en point 1.1.11. Les montants relatifs au
développement, à la formation et à la maintenance seront différenciés. Les montants relatifs aux variantes et
options seront présentés de manière annexe.
Le prix inclura tous les frais tels que licences, taxes,…
Les délais de réalisation (10 points sur 100) basés sur les grandes étapes du développement et entre autres :

5
Début des développements du logiciel selon le phasage choisi;
 Début des tests correspondants;
 Début de la formation correspondante ;

5
Date de mise en production selon le phasage choisi ;
 …
1.2.4. Planning
Le soumissionnaire indique dans son offre le calendrier d'exécution des services et fournitures, exprimé
éventuellement en temps relatif par rapport à la date de conclusion du marché.
5 5
Le planning sera détaillé selon le phasage choisi par le soumissionnaire. Pour chaque phase , il lui est demandé
de détailler la période de développement, de test et de mise en production.
Ce planning sera discuté, finalisé et validé par l’ASBL L’Equipe après attribution du marché.
Annexe 5, Volet A.4
1.2.5. Responsabilité du prestataire de services

Le prestataire de services assume la pleine responsabilité des fautes et omissions constatées dans les services
fournis, spécialement dans les études, les calculs, les plans ou toute autre pièce qu'il fournit dans le cadre de
l'exécution du marché.
En outre, le prestataire de services garantit que tous les services qui devront être exécutés dans le cadre du
contrat seront exécutés conformément aux meilleurs normes professionnelles, par un personnel suffisamment
formé et compétent, en respectant les délais prévus. Le prestataire a donc une obligation de résultat.
Sur la base de l'article 1384 du Code Civil, le prestataire de services est en tous cas responsable de tout fait
ayant un rapport avec les activités exercées pour le compte de l'ASBL L'Equipe commis par des membres de son
personnel.
La présente clause est sans préjudice de toute autre cause de responsabilité applicable.
1.2.6. Analyse
Le prestataire livrera une analyse préalable permettant aux deux parties, l’ASBL L’Equipe et lui-même, de
prendre conscience des besoins réels et de s’accorder sur les différents processus, écrans, interfaces, données,
… à réaliser.
Cette analyse décrira dans le détail comment le logiciel couvre les fonctions demandées dans l’appel d’offre par
l’ASBL L’Equipe.
Elle servira également de base dans les développements et de base dans les tests.
5
Cfr point 2.3.2.4
10 / 83
1.2.7. Réception des services prestés

1.2.7.1. Réceptions provisoires partielles
6
Au cours de chaque phase , pour la partie développement, un procès-verbal de réception provisoire partielle
sera établi à l'issue de chaque étape de mise en œuvre d'un ensemble de fonctionnalités.
Dans le cas où la réception provisoire partielle d'un nouvel élément a un impact sur une partie qui a été
réceptionnée antérieurement, les changements doivent être apportés à l'élément réceptionné auparavant
avant que l'ASBL L'Equipe marque son accord sur la réception provisoire partielle de cette nouvelle partie.
6
Après la dernière réception provisoire partielle au sein d’une phase , suit la réception provisoire partielle
6
globale pour l’ensemble de la phase concernée. Le procès-verbal partiel global établira les manquements par
rapport à l’analyse préalable. Ils devront être corrigés par le prestataire.
1.2.7.2. Réception définitive

La réception définitive est déclarée à la demande du prestataire à l'issue de la mise en production et après la
6
réception provisoire globale de l’ensemble des phases . Les manquements consignés dans les procès-verbaux
6
de réception provisoire partielle globale de chaque phase devront avoir été corrigés par le prestataire avant
cette demande.
La réception définitive sera consignée dans un procès-verbal signé par le prestataire et l'ASBL L'Equipe.
1.2.8. Garantie
Dans ce point, le terme "élément" fait référence à toute méthodologie, équipement ou logiciel et tout ce qui a
été développé/livré par le prestataire et fait partie du présent marché.
7 6
Après chaque réception provisoire partielle au sein d’une phase , le délai de garantie d'un élément débute ; il
6
se termine 1 an après la réception provisoire globale de la phase concernée, à condition que les services et/ou
fournitures concernées soient conformes au cahier des charges, aux règles de l’art et à toute autre règle
applicable.
Si des éléments sont défectueux, si les fonctions et/ou les prestations et/ou le respect du SLA (Service Level
Agreement – accord sur le niveau des services), prescrits dans le cahier des charges ou annoncés dans l'offre du
soumissionnaire, ne sont pas satisfaisants ou ne le sont qu'en partie, dans la mesure où les défauts ne sont pas
la conséquence d'une utilisation anormale des éléments, le prestataire s'engage à effectuer toutes les
réparations ou corrections nécessaires à ses frais ou à remplacer, le cas échéant, les éléments défectueux dans
les délais indiqués dans les spécifications du SLA.
La garantie couvre notamment :

- La réparation ou la correction de défauts de fonctionnement ou la non-conformité d'un logiciel ;
- La correction des paramètres ;
- Les frais et les déplacements du personnel du prestataire ;
- Les tests et installation de la nouvelle version ;
- Dans le cas où des données auraient été vérolées suite au défaut de fonctionnement, la correction et
la reprise éventuelle de données correctes.
6
Cfr point 2.3.2.4
7
Cfr point 1.2.7.1
11 / 83
1.2.9. Exécution des services

1.2.9.1. Conditions de l'exécution
Le matériel et autres prescriptions énoncés dans l'offre du soumissionnaire comme étant à charge de l'ASBL
L'Equipe seront préparés selon un calendrier mis au point de commun accord après la conclusion du marché.
1.2.9.2. Personnel de l’ASBL L’Equipe

L’ASBL L’Equipe mettra à disposition le personnel nécessaire pour la mise en œuvre du logiciel.
Le soumissionnaire décrira dans son offre une évaluation de ses besoins en nombre de jours de travail. Ceux-ci
8
seront détaillés selon les différentes phases de développement et selon les différentes tâches relatives à la
gestion du projet (validations, tests, …).
1.2.9.3. Personnel du prestataire

L'équipe de projet mise à disposition par le prestataire doit être suffisante afin de mener à bien les missions qui
lui sont confiées.
1.2.9.4. Suivi de la bonne exécution des livraisons et des services

Si, pendant l'exécution, des anomalies sont constatées par le prestataire de services, elles seront
immédiatement signalées par écrit à l’ASBL L’Equipe. Si, l’ASBL L’Equipe constate, pendant l’exécution, des
anomalies, elle le signalera au prestataire de services.
Dans ces cas, le prestataire de services est tenu de recommencer les services non conformes.
En vue de l'évaluation des services exécutés et du suivi du projet, l'ASBL L'Equipe peut faire appel à un tiers. Le
prestataire est tenu de collaborer avec ce tiers et de lui fournir toute l'information nécessaire au bon
accomplissement des opérations de contrôle.
1.2.10. Propriété des softs développés

1.2.10.1. Propriété intellectuelle
Le logiciel développé reste la propriété de son auteur, le prestataire, qui possède légalement les droits
d’auteur.
Néanmoins, l'ASBL L'Equipe a le droit, pendant l’exécution du marché et après l’expiration du délai d’exécution
du marché,
 d'utilisation du logiciel et de tous ses composants au sein de ses différentes structures de travail
présentes et futures ;
 d'installation sur tous les postes de travail présents et futurs ;
 de copie du logiciel en cas de back-up ou de maintenance des serveurs de l'ASBL L'Equipe ;
 de décompilation des interfaces du programme pour permettre son interopérabilité avec un autre
programme ;
 d’obtention des nouvelles versions.
Le prix global estimé par le soumissionnaire pour la fourniture des services tiendra compte du choix de l’ASBL
L’Equipe de ne pas réclamer les droits d’auteur.
1.2.10.2. Code source

En cas de force majeure, la procédure de récupération des codes source, décrite ci-dessous, s'enclenchera
auprès du notaire désigné de commun accord.
8
Cfr point 2.3.2.4
12 / 83
9
Dès la première réception provisoire globale, en d’autres mots, après la fin de la première phase choisie par le
soumissionnaire, celui-ci s'engage à stocker le code source encrypté sur le serveur de l'ASBL L'Equipe. La clé du
cryptage sera déposée chez le notaire désigné de commun accord, aux frais de l’ASBL L’Equipe. Le
soumissionnaire devra s'assurer que la version encryptée, stockée à l’ASBL L’Equipe soit toujours la version
mise en production à L'Equipe et que cette version soit en état de fonctionnement et de lisibilité. Un test
annuel sera prévu à cet effet.
1.2.11. Facturation et paiement

9
Pour la partie développement et selon le phasage prévu par le soumissionnaire dans son offre, le paiement se
fait, après chaque réception provisoire partielle sur production de factures.
Le procès-verbal de réception provisoire sera joint à la facture à laquelle il se rapporte.
9
Pour la partie maintenance, pour chacune des phases , le paiement se fait trimestriellement ou annuellement
(au choix du soumissionnaire, à préciser dans son offre), sur production de factures, sans préjudice de l’article
1.1.11 des présentes clauses.
Les factures sont à adresser à
ASBL L'EQUIPE
Rue de Veeweyde 60
1070 Anderlecht
1.2.12. Engagements particuliers pour le prestataire de services

Le soumissionnaire, ses représentants et ses éventuels sous-traitants s’engagent à respecter la plus stricte
confidentialité en ce qui concerne l’ensemble des données, les règles de sécurité physique et logique et le
contenu des serveurs auxquels ils ont accès pour la passation et l’exécution du présent marché.
Le soumissionnaire, ses représentants et ses éventuels sous-traitants déclarent connaître et se soumettre à

l’ensemble des obligations imposées par la loi relative à la protection de la vie privée applicables aux
traitements de données à caractère personnel et ses arrêtés d’exécution.
Le soumissionnaire ne communiquera à son personnel et à celui de ses sous-traitants directement impliqués au

marché, que les données nécessaires à l'exécution de leur tâche du présent marché.
Le soumissionnaire s'engage à ne pas saisir tout ou partie de l'information de l'ASBL L'Equipe sur un support
quelconque, sauf pour l'exécution des missions qui lui sont confiées par l'ASBL L'Equipe et ce uniquement si
cela s'avère nécessaire.
1.2.13. Stockage physique des données

Le soumissionnaire s'engage à stocker les données sur les serveurs de l'ASBL L'Equipe.
1.2.14. Sous-traitance
L’ASBL L’Equipe accepte la sous-traitance des services dans le cadre de ce marché mais sous la seule
responsabilité du soumissionnaire. Le sous-traitant devra alors être intégralement soumis au respect du
présent cahier des charges.
Dans tous les cas, ces sous-traitants éventuels seront connus et documentés au moment du dépôt de l’offre.
Le fait que le soumissionnaire confie tout ou partie de ses engagements à des sous-traitants ne le libère pas de
sa responsabilité envers l'ASBL L'Equipe. Le soumissionnaire restera le seul cocontractant de l’ASBL L’Equipe.
9
Cfr point 2.3.2.4
13 / 83
1.2.15. Obligations des parties

Les parties s'engagent à respecter toutes les obligations régissant le marché. Le soumissionnaire est
responsable du choix des produits proposés en vue d'obtenir les résultats visés et s'engage à observer tous les
engagements pris et toutes les garanties de son offre ainsi que tout document signé par lui. L’ASBL L’Equipe
s'engage à utiliser les produits conformément aux spécifications fournies par le soumissionnaire dans son offre.
Les litiges concernant les obligations nées des dispositions régissant le marché pourront être réglés d'un
commun accord. A défaut, et avant de faire valoir leurs droits en justice, les parties pourront convenir de faire
appel à un ou plusieurs experts acceptés par les parties et rémunérés à part égale. Ces experts doivent déposer
leurs conclusions auprès des deux parties dans les trente jours qui suivent leur désignation. Cette intervention
n’exclut pas l’application des mesures d’office. En dernière instance, seuls les tribunaux francophones de
Bruxelles sont compétents.
1.2.16. Amendes et pénalités

10
L’Equipe souhaite utiliser l’intégralité du DPI dans les meilleurs délais. En particulier, la phase 1 , qui doit être
mise en production au 01/01/2019 sous peine d’une perte de subsides. Par conséquent, pour tout service non
exécuté dans les délais prévus par le soumissionnaire dans son offre, en cas de retard, l’ASBL L’Equipe se
réserve le droit de réclamer une pénalité de maximum 20% du montant total de la phase 1 et d’un maximum
de 1% par mois pour les phases ultérieures.
10
Cfr point 2.3.2.4
14 / 83
2. CLAUSES TECHNIQUES
2.1. Introduction
2.1.1. Objectifs de l’ASBL L’Equipe
L’ASBL L’Equipe veut devenir participant actif dans l’informatisation des données de la santé, vecteur d’une
transformation sociétale en plein essor.
Dans le cadre de notre ASBL, constituée d’un hôpital psychiatrique de jour (20 lits), de 5 centres Inami/Cocof
(128 places), d’un centre ambulatoire Cocof et d’une habitation protégée (45 places), nous souhaitons
développer un outil informatique « Dossier Patient Informatisé » uniforme, interne, commun et adapté à tous.
Cet outil devra respecter les fonctionnalités imposées par la Santé Publique et les fonctionnalités définies par
les processus « métiers » de notre ASBL.
Il devra être disponible, intègre et répondre aux normes spécifiques de confidentialité relatives à la santé. Il
communiquera aussi efficacement avec le réseau santé bruxellois, Abrumet.
Cet outil devra améliorer la quantité et la qualité de temps passé auprès du patient, le bien-être du patient et
les conditions de travail des soignants.
Le papier disparaîtra complètement après analyse de risques et validation complète de l’outil par la direction.
2.1.2. Phasage du projet

Le projet se compose de plusieurs phases (cfr détail au point 2.3.2.4). La phase 1 doit obligatoirement être en
er
production au 1 janvier 2019 au sein de la structure « Centre Ados ». Les phases suivantes peuvent être
simultanées à la phase 1 mais pas obligatoirement. Dans ce cas, elles devront faire l’objet d’un planning
échelonné, à préciser par le soumissionnaire avec un maximum de 5 ans à partir de la date de conclusion du
marché.
Les phases seront toujours mises en production d’abord dans une de nos structures, le Centre Ados, structure
hospitalière de jour, ensuite, après validation, elles seront accessibles aux autres structures.
Le planning et l’offre de prix doit couvrir l’ensemble des phases et l’ensemble des structures.
2.1.3. Bénéfices attendus

Les bénéfices attendus sont une plus grande structuration de l’information, une facilité et une rapidité d’accès
aux données du patient, l’amélioration du bien-être du patient, une traçabilité de chaque action et une
amélioration des conditions de travail des soignants.
2.1.4. Objet du marché

Le marché sera constitué des éléments suivants :
 L'analyse, le développement et/ou l’adaptation d’un logiciel de gestion du dossier patient informatisé;
 L’acquisition de licence d’utilisation du logiciel de gestion ;
 L’acquisition de licences d’outils techniques associés (le cas échéant) ;
 La liaison avec le logiciel de gestion des médicaments en place (société LOGAL);
 L’installation / Le paramétrage / L’assistance à la mise en place ;
 La formation du personnel ;
 Le dimensionnement du serveur applicatif et prérequis techniques (réseau, postes de travail,
imprimantes, …) ;
 La maintenance (engagement sur 5 ans minimum) de l’ensemble de la solution.
 La garantie
15 / 83
2.2. Contexte du projet

2.2.1. Description générale de l’ASBL L’Equipe
L'ASBL L'Equipe est composée de différentes structures :
 Le Centre Ados : Hôpital psychiatrique de jour (20 lits),

o ouverture du lundi au vendredi de 8h00 à17h00
 Le Foyer : Centre d'hébergement (28 lits)
o Ouverture 7j/7, 24h/24, personnel réduit entre 20h00 et 08h00 et le week-end
 La Pièce : Centre d'hébergement double diagnostic psychique et toxicomane (15 lits)
o Ouverture 7j/7, 24h/24, personnel réduit entre 20h00 et 08h00 et le week-end
 Le Code : Centre de jour pour adultes (40 lits)
 Le Crit : Centre de jour pour adultes (30 lits)
 Imago : Centre de jour pour adultes (15 lits)
 Babel : Centre de consultation pour double diagnostic
 Le Jade : Administration Centrale
 ASBL Juan Luis Vives : Habitations protégées (45 places)
o Ouverture 7j/7, 24h/24, personnel uniquement de garde téléphonique entre 17h00 et 08h00
et le week-end
L'ASBL L'Equipe se situe géographiquement sur plusieurs sites :
 Bâtiment Central : Le Jade, Le Code et Le Crit au 60 rue de Veeweyde à Anderlecht

 Le Foyer se situe au 83 rue de Veeweyde à Anderlecht
 Le Centre Ados se situe au 47 rue de Veeweyde à Anderlecht
 Imago se situe au 89 avenue Eugène Ysaye à Anderlecht
 La Pièce et Babel se situent au 67 - 71 rue Hôtel des Monnaies à Saint-Gilles
 Prélude possède plusieurs adresses à Anderlecht et à Schaerbeek
L'ASBL L'Equipe est constituée d'environ 140 travailleurs dont la majorité est du personnel soignant.
De plus ample informations sont disponibles sur le site www.equipe.be
2.2.2. Structure de gouvernance

Le projet est piloté par un comité multidisciplinaire. Il est constitué d'un gestionnaire de projet, de la direction
et de représentants métiers. D'autres personnes peuvent y être invitées pour des aspects plus spécifiques au
projet.
Le comité se réunit en principe une fois par mois pour surveiller la bonne réalisation des objectifs du projet,
approuver le planning et ses modifications éventuelles, confirmer l'acceptation des livrables et évaluer la
qualité des produits partiels et finaux. A cette fin, le gestionnaire de projet fera régulièrement rapport au
comité.
Pour permettre le suivi précité, il sera demandé au prestataire de fournir un reporting faisant état de
l'avancement du projet et de sa mise en production.
16 / 83
2.2.3. Descriptif de la mission

Le présent marché portera sur le développement et la maintenance d'une application de gestion des
informations concernant le patient en psychiatrie incluant un dossier patient informatisé.
Il sera demandé au soumissionnaire d'assurer le cycle complet de développement de l'application. On entend

par cycle complet de développement d'assurer les étapes non exhaustives suivantes :
- Analyse fonctionnelle et technique ;

- Développement, architecture et design ;
- Implémentation ;
- Documentation complète ;
- Suivi de la qualité (tests unitaires, fonctionnels et de charge).
A côté du développement à proprement parler, il sera demandé au soumissionnaire :

- D'assurer un suivi et une gestion du projet en partenariat avec l'ASBL L'Equipe ;
- D'assurer la formation des utilisateurs et du responsable informatique ;
- De fournir un support à la mise en place du DRP (Disaster Recovery Plan) et du BCP (Business
Continuing plan).
2.2.4. Situation actuelle du système d’information administratif

2.2.4.1. Infrastructure existante
La politique de l’ASBL L’Equipe est de mettre à disposition des prestataires de logiciels, l'infrastructure
"système" nécessaire pour supporter leurs produits. A cette fin, le soumissionnaire prescrit à l’ASBL L’Equipe
les caractéristiques techniques minimales relatives à l'infrastructure pour pouvoir exécuter les logiciels qu'il
offre.
L'état actuel de l'infrastructure et du réseau local est décrit en annexe 1.
L’informatique est gérée par un consultant indépendant qui possède une bonne maîtrise système de la
configuration informatique installée sur les sites.
2.2.4.2. Environnement de développement, de test, d'intégration et de production

L'environnement de développement, l'environnement de test et l'environnement de production sont séparés,
mais du point de vue technique, ils sont identiques, afin d'éviter les incompatibilités.
2.2.4.3. Logiciels installés
2.2.4.3.1. Facturation et gestion des médicaments : application Evolutive Compta de LOGAL
Le logiciel Evolutive Compta conçu par la société LOGAL, Chemin du Vieux Pont 54 à 7900 Leuze-en-Hainaut, BE
0411.897.335, assure la gestion administrative des patients (admission, accords mutuelles via MyCarenet,
calendriers des présences et code des prestations, tarification – facturation) ainsi que la gestion des
médicaments (prescription électronique, distribution et facturation).
Au niveau technique, le logiciel se veut être un programme de gestion intégrée complet semblable aux ERP tels
quel Navision ou SAP. La base de données est dite propriétaire.
Le langage utilisé pour les programmes WIN est basé sur le Framework .NET. (Visual Basic, C#). Le langage
utilisé pour les programmes DOS est le Quick Basic.
17 / 83
2.2.4.3.2. Autres
Les autres logiciels sont cités dans l’annexe 1
2.2.4.4. Volumes
Ce point est détaillé dans l’annexe 1
Si cela s’avère nécessaire, après étude de la solution, des postes supplémentaires ou des appareils spécifiques
peuvent être acquis et ajoutés à cette infrastructure.
2.3. Spécifications fonctionnelles

2.3.1. Généralités
2.3.1.1. Architecture et intégration du DPI
Le DPI, faisant l’objet du présent marché, doit permettre à nos soignants de structurer, de partager les
informations médicales et de faciliter la récolte de celles-ci à chaque moment de soin du patient.
La solution à offrir est un logiciel utilisant un système de bases de données standard du marché auquel il sera
ajouté des modules complémentaires permettant
 d’introduire de manière conviviale des informations utiles pour le soin du patient
 de consulter rapidement des informations nécessaires à la prise de décision dans le trajet de soin du
patient
 de faciliter la gestion des activités autour du patient ;

11
de communiquer et d’échanger des informations via Abrumet , réseau de santé bruxellois.
2.3.1.2. Intégration du logiciel « gestion des médicaments », Evolutive Compta

La solution du soumissionnaire ne devra pas réaliser la gestion des médicaments qui est prise en charge
actuellement par la société LOGAL. Elle devra cependant communiquer avec celle-ci pour éviter toute
redondance d’informations ou tout doublon dans la création des patients et échanger des informations avec
elle.
Les informations redondantes sont au minimum :

- La création d'un nouveau patient avec un n° d'identification unique
- Les données administratives de base comme le nom, prénom, date de naissance, n°Niss, mutuelle
- Les dates d'entrée, de sortie
Les échanges d’informations sont au minimum :

- La liste des allergies (à afficher en cas de prescription d’un médicament dans Evolutive Compta de
Logal)
- Résultats de prise de sang (à afficher en cas de precription d’un médicament dans Evolutive Compta
de Logal, en format PDF par exemple)
La société Logal possède déjà une expérience dans le domaine puisqu’une situation similaire a déjà été
développée au sein d’un autre hôpital.
Logal est désigné comme maître dans la création d’un patient et échange de l’information avec le prestataire
DPI. L’interface utilisée est le HL7, l'échange des messages suivants est fonctionnel :
 Flux ADT :
o A01 Admission en hospitalisation
11
https://www.abrumet.be/. Pour l’instant, seul le rapport de sortie est communicable.
18 / 83
o A02 Mouvement intra-hospitaliers (changement de service)

o A03 Mouvement sortie patient
o A08 Mise à jour d'une admission en hospitalisation
o A11 Annulation d'admission en hospitalisation
o A12 Annulation d'un mouvement intra-hospitalier (changement de service)
o A13 Annulation mouvement sortie patient
o A21 Absence temporaire
o A22 Retour d'absence temporaire
o A28 Création d’une signalétique patiente
o A31 Mise à jour d'un signalétique patient
o A52 Annulation d'absence temporaire
o A53 Annulation du retour d'absence temporaire
 Flux PMU :
o B01 Ajout d'un médecin
o B02 Mise à jour d'un médecin
D’autres messages peuvent être ajoutés sans problème.
Si le HL7 ne convient pas, il est aussi possible de recourir à d’autres types d’interface comme :
 SQL
 Fichier plat (TXT, CSV, …)
 Fichier DBF
 Fichier XML
2.3.1.3. Performances
Le système doit être disponible 24h sur 24, 7 jours sur 7.
La période de pointe est située du lundi au vendredi de 8h00 à 17h00.

En-dehors de ces heures, seules les structures le Foyer et la Pièce sont fonctionnelles mais en personnel très
réduit.
Etant donné que notre but consiste à supprimer le dossier papier, l’accessibilité au dossier patient revêt une
grande importance.
Un test de charge sera réalisé afin de garantir la performance sur base d’un scénario d’utilisation représentatif
décrit lors de la phase d’analyse.
2.3.1.4. Sécurité des données et droits d’accès

Le type de données traitées étant sensible à caractère personnel, le logiciel DPI doit garantir l’intégrité, la
sécurité et la confidentialité des données traitées.
2.3.1.4.1. Stockage des données

Le soumissionnaire détaillera la sécurité qu'il envisage de mettre en place pour garantir la confidentialité des
données. S'il prévoit un encryptage, il nommera la méthode privilégiée.
2.3.1.4.2. Droits d'accès et authentification

Les habilitations et les droits d'accès au logiciel DPI se basent sur des "rôles" fixant les autorisations
individuelles des utilisateurs avec une granularité suffisamment fine pour répondre aux besoins d'un hôpital
psychiatrique.
Un modèle minimum a été défini comme suit, il peut être affiné.
19 / 83
Droits Rôles
Ut L'utilisateur uniquement
Ad Administration
Sec Secrétaires
So Sociothérapeutes
Soignants (S)
Co Coordinateur de structure
Me Médecin
Psy Psychologue
AS Assistant social
Inf Infirmiers
St Stagiaire
Admin Administrateur du logiciel
Certaines parties du dossier patient peuvent ou doivent être masquées en fonction du métier de l'utilisateur ou
de l'appartenance à un groupe. Les droits (droits de lecture, droits d’écriture, droits d’impression) ont été
définis pour chaque item du dossier dans les colonnes de droite que vous trouverez en annexe 2 « Structure
générale du DPI ».
2.3.1.5. Traçabilité
Le logiciel DPI assure la traçabilité de toutes les données médicales créées, modifiées ou consultées. Cette
traçabilité implique une historisation des consultations ou modifications de données avec date, auteur et
localisation. Les informations de traçabilité sont accessibles et lisibles par des utilisateurs privilégiés non
informaticiens.
2.3.1.6. Légalité et conformité

Le logiciel respecte les obligations légales et réglementaires applicables en hospitalier et en psychiatrie, y
compris les recommandations et directives en matière d’archivage et de transmission des données médicales,
de la protection de la vie privée et de l'utilisation de la signature électronique.
2.3.1.7. Tests et plans qualité

Le soumissionnaire explique l'approche qu'il entend utiliser pour assurer la qualité du code fourni ainsi que
pour tester le système.
2.3.1.8. Evolutivité
Afin de pouvoir évaluer les possibilités d’évolution de la solution proposée, le soumissionnaire précise dans son
offre les points suivants :
 La richesse de paramétrage de la solution proposée ;

 Les développements prévus, leur planification dans le temps et les stades d'avancement à la
date de remise de l'offre ;
 La politique d'interopérabilité et d'interfaçage avec d'autres progiciels du marché ;
 La politique d’adaptation aux demandes spécifiques des clients.
2.3.2. Postes à réaliser

2.3.2.1. Accès au DPI
Au login, le logiciel de DPI affiche des informations destinées à faciliter l'organisation des tâches de chaque
utilisateur : par exemple, la liste paramétrable de "ses" patients actifs, la liste de ses rendez-vous du jour, des
messages lui étant adressés personnellement, des invitations à diverses réunions ou rendez-vous, toute autre
information utile créée depuis la dernière session. L'utilisateur peut aussi accéder au dossier d'un patient sur
base d’un critère de recherche, au minimum un numéro d’identifiant, un nom, un n° de registre national ou
autre.
20 / 83
2.3.2.2. Nomenclatures et codifications

Les codifications associées aux diagnostics utilisées dans le DPI sont :
 Le DSM 5 (Diagnostic and Statistical Manual of Mental Disorders) en psychiatrie ;

 L’ICD 10 (International Statistical Classification of Diseases and Related Health Problems) ;
 La codification SNOMED CT (SYSTEMATIZED NOMENCLATURE OF MEDICINE CLINICAL TERMS ), devra,
12
même si la traduction belge est encore en cours, également faire partie du développement futur ;
 CFTMEA (Classification française des troubles mentaux de l'enfant et de l'adolescent ).
Toute corrélation possible entre ces codes constitue une force de la solution. Par exemple, la saisie d'un code
DSM propose le ou les codes équivalents en ICD 10, SNOMED CT ou CFTMEA et inversement.
Certaines corrélations existent déjà. L'Equipe s'engage à mettre à disposition le personnel médical nécessaire
pour définir ces corrélations.
Ces codifications évoluent dans le temps et une mise à jour des versions ultérieures doit être prévues dans la
maintenance du logiciel.
2.3.2.3. Structure générale du DPI

Le dossier patient informatisé de psychiatrie comprend les volets légaux et doit permettre de rassembler
toutes les informations indispensables au soin de nos patients.
Ces listes d’informations ont été récoltées auprès des représentants métiers de notre ASBL et ont été
regroupées de manière logique sous 25 rubriques différentes dépendantes de 2 groupes distincts :
Données de situation du patient : elles représentent les données de base du patient, elles sont uniques à
chaque patient, elles sont disponibles à chaque nouveau séjour du patient mais doivent être vérifiées.
 Données administratives
 Assurabilité
 Ressources financières
 Situation scolaire
 Parcours professionnel
 Situation médico-légale
 Situation judiciaire
 Réseau psycho-médico-social
 Génogramme
 Antécédents médicaux
 Consommation de toxiques
 Consentements du patient
 Limitations de thérapie
Données de séjour : elles représentent les données du séjour du patient, elles sont clôturées à la fin de chaque
séjour. Lors d’un nouveau séjour, une nouvelle batterie de rubriques vierges est disponible pour l’encodage des
données. Les données des séjours précédents restent cependant consultables.
 Projets de soin
 Données séjour
 Notes journalières
 Médicaments (doit être traité en lien avec Logal)
 Volet psychiatrie
12
http://www.health.belgium.be/fr/terminologie-et-systemes-de-codes-snomed-ct
21 / 83
 Volet psychologie
 Volet Infirmier
 Volet Social
 Volet Référent
 Volet Référent pédagogique
 Sortie / Postcure
 Ségrégations
Ces rubriques sont constituées de nombreux items qui ont été détaillés dans l’annexe 2 « Structure générale
du DPI ». Ces données constituent la base minimale d’information du DPI.
Autour de cette base de données, une série de fonctionnalités s’articulent pour permettre une facilité
d’encodage, de modification ou consultation de ces données
2.3.2.4. Fonctionnalités du DPI

Les fonctionnalités décrites ci-après sont à distinguer comme suit :
 Indispensables à l’utilisation du logiciel (phase 1)
 Obligatoires légalement (phase 1)
 Demandées par l’ASBL L’Equipe qualifiées d’urgente à implémenter en phase 1
 Demandées par l’ASBL L’Equipe qualifiées d’importantes avec possibilité
d’implémentation en phase 2
 Demandées par l’ASBL L’Equipe qualifiées d’utiles avec possibilité
d’implémentation en phases ultérieures
Il est obligatoire légalement de développer au minimum les fonctionnalités « phase 1 » pour une mise en
production au 01/01/2019 et cela au sein d’une de nos structure, le Centre Ados, structure hospitalière de jour.
Les autres phases et les autres structures peuvent, au choix, être planifiées ultérieurement (avec un maximum
de 5 ans depuis la date de conclusion du marché).
Le soumissionnaire doit donner un planning pour le développement du projet complet pour l’ensemble de
l’ASBL.
Certaines fonctionnalités ont été définies de manière plus détaillées dans l'annexe 4, processus actuels et
processus futur. Les analyses réalisées en interne décrites dans cette annexe vont permettre au
soumissionnaire de prendre connaissance des besoins et des attentes de l’adjudicateur mais cela ne le
dispense, en aucune manière, de procéder à sa propre analyse fonctionnelle qui fait partie intégrante de ce
présent marché.
Les processus seront donc réalisés sur base de ce qui aura été convenu au terme de la phase d’analyse.
1. PHASE 1 :
Les fonctionnalités permettant le traitement des informations indispensables à
l’utilisation du logiciel
1.1. Traçage et horodatage : Toute consultation ou modification par un utilisateur doit être tracée et
horodatée (auteur, localisation, date et heure). Le fichier doit pouvoir être clairement lu par un
utilisateur privilégié non informaticien.
1.2. Accès au DPI : L’accès au DPI en consultation ou modification doit être géré suivant les droits des
utilisateurs.
Le mode de connexion au DPI doit tenir compte d’un niveau de sécurité suffisant au vu de la
sensibilité des données traitées.
22 / 83
2. PHASE 1 :
Les fonctionnalités permettant le traitement des informations obligatoires
légalement (BMUC)
Ces fonctionnalités sont présentées de manière succincte dans les points ci-dessous. Il est indispensable de
prendre connaissance du document complet en annexe 3, Belgian Meaningful Use Criteria for Other Hospitals
(BMUC). Ce document constitue les fonctionnalités minimales à respecter pour le SPF Santé Publique. Il est
primordial pour l’ASBL L’Equipe de pouvoir mettre en œuvre ces 15 fonctionnalités dans le délai demandé. Il
est à noter toutefois que la gestion des médicaments ne fait pas l’objet de cet appel d’offre. Les points 2.4, 2.5
et 2.6, cités à titre informatif, ne concernent donc pas ce marché.
2.1. Création d’un DPI : tout nouveau patient, tant ambulatoire qu’hospitalisé, doit être créé et enregistré.
Actuellement, la création d’un patient se fait dans l’application Evolutive Compta de LOGAL. Cette
application restera maître dans la création des patients hospitalisés. L’interface prévu par cette
société a déjà été décrit au point 2.2.2.2.1 « Facturation et gestion des médicaments : application
Evolutive Compta de LOGAL ».
Les deux logiciels devront communiquer pour permettre une identification unique du patient et
éviter la redondance d’informations communes avec au minimum les nom, prénom, sexe, date de
naissance, données mutuelle, dates d’entrée et de sortie. Cette liste peut être complétée si
nécessaire..
2.2. Liste des diagnostics : Possibilité de compléter les champs prévus pour les diagnostics tant au niveau
des antécédents médicaux qu’au niveau des diagnostics actuels.
Possibilité de les visualiser en historique ou de sélectionner uniquement les actuels.
Les normes de codification des diagnostics doivent être accessibles (cfr liste au point 2.3.2.2
Nomenclatures et codifications)
2.3. Liste des allergies : Possibilité de compléter les champs prévus pour les allergies.
En cas de prescription des médicaments, la liste des allergies doit être visible. La gestion des
médicaments étant confiée actuellement à la société Logal, cette question devra également faire
l’objet de l’interface décrit au point 2.2.2.2.1 « Facturation et gestion des médicaments : application
Evolutive Compta de LOGAL ».
2.4. E-prescription : Ce point ne fait pas partie de ce marché
2.5. Interactions médicamenteuses : Ce point ne fait pas partie de ce marché
2.6. Administration des médicaments : Ce point ne fait pas partie de ce marché
2.7. Lettre et rapport de sortie : La lettre et le rapport de sortie doivent pouvoir être générés
automatiquement, à condition que les champs requis aient été correctement complétés par les
soignants, et doivent être validés par le médecin.
13
Ils peuvent être imprimés ou envoyés directement par email (utilisation de e-health box
obligatoire).
L’historique des lettres de sortie doit être facilement accessible (date/heure de création, de
validation, incluant une vue des destinataires et des émissaires).
A titre illustratif, les détails de la lettre et du rapport de sortie sont consignés en annexe 4 –
Processus Actuels et processus Futurs – 2.7
2.8. Enregistrement de consentements éclairés : Possibilité de consigner les consentements demandés au
patient ( avec possibilité d’annexer des documents PDF)
La liste des consentements contiendra au moins :
- l’adhésion à Abrumet (Réseau de Santé bruxellois) (statut mis à jour en ligne via le Hub)
13
Repris au point 2.10
23 / 83
- l’accord de traitement des données à caractère personnel

- l’accord pour prise de contact avec le réseau des PMS
- l’accord du descriptif de prise en charge
-…
2.9. Limitations thérapeutiques : Enregistrement des directives du patient avec date, heure, soignants
ayant recueilli l’information et référence possible à un écrit
2.10. Comunication automatique avec les Hub’s et interaction avec e-health :
14
- Utilisation de eHealthBox
15
- Partage de données via le Hub
16
- Consultation d’enregistrements d’autres institutions via le Hub
- Mise à jour automatique du statut du consentement du patient via Abrumet
- Utilisation de healthdata.be pour l’enregistrement de données :
A l’heure actuelle, nous n’avons aucune donnée à transmettre via healthdata.be. Le ministère de la
Santé Publique inclut déjà cette fonctionnalité mais nous sommes dans l’attente de directives claires
à ce sujet. Cette fonctionnalité devra donc être prévue dans les adaptations futures du logiciel.
2.11. Enregistrement multidisciplinaire et échange d’informations : Les enregistrements sont accessibles et
consultables selon les droits des utilisateurs
2.12. Contrôle du plan de traitement interdisciplinaire accessible et des tâches de chaque discipline :
Existence d’un plan de traitement interdisciplinaire
2.13. Ségrégations : Enregistrement des ségrégations
2.14. Enregistrement des observations : prises de notes servant de base pour les plans de traitement
interdisciplinaire lors des entretiens
2.14.1. Prises de notes journalières
A titre illustratif, le processus est consigné en annexe 4 – Processus Actuels et processus
Futurs – 2.14.1
2.14.2. Prises de notes en réunion de staff et mise à disposition du PV
Futurs – 2.14.2
2.14.3. Prises de notes lors des entretiens
2.14.3.1. Avec le psychiatre
2.14.3.2. Avec le psychologue
2.14.3.3. Avec l’assistant social
2.14.3.4. Avec le référent pédagogique
2.14.3.5. Avec le référent
Futurs – 2.14.3
2.15. Support des résultats internes ou demandes internes mais exécutées en externe
Les informations demandées dans notre hôpital sont des résultats de tests psychologiques ou des
résultats sanguins, … qui constituent des rapports écrits pouvant être annexés sous format PDF ou
document Word
14
L’eHealthBox est une boîte aux lettres électronique sécurisée et mise gratuitement à la disposition de chaque prestataire de
soins. Elle permet aux prestataires de soins d’échanger électroniquement et de manière sécurisée des données médicales et
confidentielles. Le système a été développé par la plate-forme eHealth.
15
https://www.ehealth.fgov.be/fr/prestataires-de-soins/services-en-ligne/hubs-metahub
16
Pour l’instant, seul le rapport de sortie est consultable
24 / 83
3. PHASE 1 :
Les fonctionnalités permettant le traitement des informations demandées par
l’ASBL L’Equipe et qualifiées d’urgentes
3.1. Architecture du dossier d’un patient : Le dossier patient contient des données appelées « situation du
patient » et celles appelées « données séjour » (Cfr 2.3.2.3). Les premières sont des données
permanentes accessibles lors de chaque admission du patient, elles doivent cependant être mises à
jour à chaque fois par l’utilisateur.
Les deuxièmes sont liées au séjour du patient, elles ne doivent donc plus être visibles lors d’une
nouvelle admission tout en restant consultables si nécessaire.
er
3.2. Formulaire spécial 1 contact :
Cette fonctionnalité est importante pour l’ASBL car il y a un taux non négligeable de demandes
d’admissions par rapport au nombre d’admission.
er
Lors d’un premier contact, un enregistrement « light » (Cfr Annexe 1, 0b 1 contact) est créé avec un
minimum d’informations dont des entretiens de préadmission avec le psychiatre.
Si ce patient est admis, le dossier patient complet peut être créé et complété.
Si ce patient n’est pas admis, l’enregistrement est archivé mais les informations restent consultables
et accessibles pour une éventuelle prochaine consultation.
3.3. Liste d’attente : Lorsqu’un patient est admis, si l’hôpital est complet, il est nécessaire d’attendre un
certain délai pour effectuer son admission physique. Une liste d’attente avec date de création doit
pouvoir être consultable. Un commentaire peut être ajouté manuellement.
3.4. Gestion du départ d’un travailleur : en cas de départ, les droits doivent être clôturés par un
utilisateur habilité et les notes dites « notes privées » reliées à ce travailleur sortant doivent être
supprimées de manière définitive sans consultation possible par un autre utilisateur.
3.5. Impressions : des impressions partielles ou complètes d’un dossier patient doivent être possibles
suivant les droits définis.
3.5.1. Impression des données à la demande du patient
Une impression du dossier patient, à la demande du patient, doit être possible.
Cette impression doit comprendre 2 parties :
- la partie "données de situation du patient" qui est imprimable dans sa totalité et comprend
toutes les données récoltées auprès du patient.
- la partie "données de séjour" où, pour l'instant, seule la lettre et le rapport de sortie sont
accessibles au patient.
Sur avis du conseil médical, il est possible que, dans l'avenir, d'autres items fassent également
partie de cette impression. Il est donc à prévoir des possibilités d'adaptations pour cette
impression.
4. PHASE 2 :
l’ASBL L’Equipe et qualifiées d’importantes
4.1. Encodage des jours de présences par mois :

Un calendrier mensuel doit pouvoir être complété avec les présences et codes d’absence spécifiques.
Des statistiques doivent pouvoir être calculées.
A titre illustratif, le processus est consigné en annexe 4 – Processus Actuels et processus Futurs – 4.1
25 / 83
4.2. Lettre d’entrée : Une lettre d’entrée doit pouvoir être générée automatiquement si les champs requis
ont été correctement complétés par le travailleur.
Elle peut être imprimée ou envoyée directement par email (utilisation de e-health box obligatoire).
A titre illustratif, le processus est consigné en annexe 4 – Processus Actuels et Processus Futurs –
2.7
4.3. Demande de tra itement à un médecin extérieur : Une lettre automatique de demande de traitement
peut être générée automatiquement. Elle peut être imprimée ou directement envoyée par e-mail (e-
health box obligatoire).
4.4. Calendrier des activités hebdomadaires : Un calendrier des activités du centre doit pouvoir être tenu.
4.5. Agenda du patient : un agenda du patient doit pouvoir être tenu, relié au calendrier mensuel des
présences, au calendrier des activités et au calendrier des travailleurs. La liste des rendez-vous
journalier ou hebdomadaire doit pouvoir être imprimée.
4.6. Agenda du travailleur : un agenda du travailleur doit pouvoir être tenu per le travailleur concerné en
relation avec l’agenda des patients. La liste des rendez-vous journaliers ou hebdomadaires doit
pouvoir être imprimée.
17
4.7. RPM : Les données RPM doivent pouvoir être extraites du DPI.
Les données sont consignées au début du séjour médico-psychiatrique, ainsi qu'à la fin du traitement.
Le RPM comprend entre autres :
 Le diagnostic à l'admission
 Les données socio-démographiques du patient
 Le type d'admission et de sortie
 le diagnostic et les problèmes résiduels à la sortie.
18
Il est à prévoir un mode de récupération du RPM pour envoi au Ministère SPF Santé Publique.
4.8. Statistiques : Les statistiques courantes en psychiatrie doivent être calculées. Il est nécessaire de
produire également un outil élémentaire permettant de développer d’autres statistiques non offertes
en standard dans le logiciel.
5. PHASES ULTERIEURES :
l’ASBL L’Equipe et qualifiées d’utiles
5.1. Module de consultation : Le centre Ados et les autres structures de L’Equipe ont le projet
d’augmenter leur activité de consultations. Il est donc important de déjà prévoir ce besoin et de
planifier un tel module. Ce point peut éventuellement être couplé au point 3.2
5.2. Message à un ou plusieurs travailleurs : possibilité de laisser un message à un ou plusieurs
travailleurs. Le message s’affichera lorsque le travailleur se connectera au DPI.
5.3. Mise en production du projet pour toutes les structures de L’Equipe : L’objectif de la direction est de
développer un outil unique pour l’ensemble de l’ASBL.
17
http://www.health.belgium.be/fr/sante/organisation-des-soins-de-sante/hopitaux/systemes-
denregistrement/rpm
18
http://www.health.belgium.be/fr/sante/organisation-des-soins-de-sante/hopitaux/systemes-
denregistrement/rpm/directives-rpm
26 / 83
5.4. Choix des items : Certains items présents dans les données de situation et les données de séjour
peuvent être inutiles pour certaines de nos structures. Lors de l’implémentation du DPI dans une
structure, elle peut choisir les items qui apparaissent (sauf certaines obligatoires légalement). Ce
choix permet quand même de visualiser les différents formulaires de manière conviviale.
5.5. N° d’identification unique : Le patient possède un n° d’identifiant unique dans toute l’ASBL. Les
structures ne peuvent consulter les dossiers patients des autres structures.
Elles ont néanmoins accès aux champs permettant l’identification du patient (N° identifiant, N° NISS,
Nom, Prénom, date de naissance, …) pour éviter de créer un doublon.
5.6. Passage d’un patient d’une structure 1 à une autre (structure 2) : Lorsque l’identification du patient
est terminée, la structure 2 récupère les données dites « de situation » de la structure 1 mais ne peut
pas visualiser les données séjour.
La structure 2 peut demander à la structure 1 la lettre et rapport de sortie via Abrumet comme une
institution étrangère à L’Equipe.
5.7. Agenda des réunions dans une structure : Un travailleur peut créer une réunion et inviter d’autres
travailleurs, connexion avec les agendas des travailleurs et messages d’alerte si indisponibilité
5.8. Agenda des réunions entre structures : Le travailleur habilité peut créer une réunion entre structures
et inviter certains travailleurs ou certaines fonctions, connexion avec les agendas des travailleurs et
message d’alerte si indisponibilité.
5.9. Mise à disposition des PV des réunions
5.10. Archivage :
 Sauvegarder la date de la dernière mise à jour (MAJ) du dossier ou date de majorité pour les
mineurs (si date de majorité > date de MAJ).
 Etablir une distinction entre dossiers en cours et dossiers clôturés.
Les dossiers clôturés doivent néanmoins rester consultables facilement et peuvent redevenir « en
cours ».
Les rapports de sortie doivent rester imprimables ou pouvoir être envoyés sur demande. (Dans ce
cas, pas de nouvelle date de MAJ)
 Les dossiers clôturés doivent être conservés 30 ans après la dernière date de MAJ, prévoir une
classification aisée des dossiers par date de MAJ et une suppression totale possible de ces
données.
2.3.3. Mode dégradé

Le mode dégradé intervient lorsque la solution DPI est hors service, quelle qu’en soit la cause.
Dans cette situation critique, la consultation des dossiers des patients reste indispensable et une procédure
alternative doit permettre de consulter les dossiers des patients pendant la durée du sinistre. Par exemple, en
tenant à jour régulièrement dans chaque unité une copie imprimable des DPI des patients présents. Ceci
impliquerait la maintenance automatique, sur un poste local de chacune des structures, de copies des dossiers
des patients de la structure en format affichable ou imprimable (par exemple en PDF). Pendant la durée du
sinistre, chaque intervenant pourrait dès lors consulter et/ou imprimer les données utiles des dossiers patients
pour assurer la continuité des soins. Les mises à jour des dossiers des patients se feraient sur papier pendant la
durée du sinistre. A la reprise après sinistre, ces mises à jour manuscrites seraient encodées dans les dossiers
patients du logiciel DPI.
Une solution équivalente peut être proposée par le soumissionnaire.
Une procédure de passage en mode dégradé et une procédure de redémarrage du DPI après sinistre doit être
prévue et testée avant la mise en production.
27 / 83
2.4. Services à fournir

2.4.1. Gestion du projet
Le soumissionnaire détaillera les procédures qu’il envisage concernant la gestion du projet dans sa globalité :
 Analyse fonctionnelle
 Politique de développement de l’application
 Politique de test, de livraison, d’implémentation
2.4.2. Transfert de connaissances

Le soumissionnaire doit prévoir l'organisation de formations en langue française de type :
- Utilisateurs
Après cette formation, l’utilisateur est capable
o D’utiliser le logiciel ;
o De signaler un incident selon la procédure adéquate ;
o De connaître les procédures à suivre en cas de panne, mode dégradé.
Cette formation doit avoir lieu en partenariat avec l’ASBL L’Equipe qui délèguera un ou plusieurs
gestionnaires internes pour permettre, à terme, de former ses utilisateurs elle-même.
- Gestionnaire interne :
Après cette formation, le gestionnaire en interne est capable
o D'utiliser le logiciel ;
o De comprendre et de paramétrer le logiciel de manière plus approfondie qu'un simple
utilisateur ;
o de former les utilisateurs afin qu'ils puissent se servir de l'application ;
o D'analyser les demandes et les problèmes des utilisateurs en première ligne et de transférer à
la deuxième ligne (prestataire) uniquement les demandes le concernant.
- Gestionnaire de système :
Après cette formation, le gestionnaire informatique est capable
o De comprendre de manière approfondie le fonctionnement du logiciel au niveau technique et
sécuritaire ;
o D'effectuer, en cas de panne, une première analyse.
2.4.3. Assistance complémentaire

Pour tous besoins supplémentaires au présent cahier des charges ou pour tout développement
complémentaire, des heures d'assistance pourraient être facturées au fur et à mesure de l'utilisation. Le
soumissionnaire précisera dans son offre le taux horaire de cette assistance ainsi que sa politique de révision
des prix.
2.4.4. Transférabilité
Le soumissionnaire remettra à l'ASBL L'Equipe toutes les informations nécessaires pour transférer le contrat
afin que l'ASBL L'Equipe puisse effectuer toutes les opérations nécessaires au bon fonctionnement ou à
l'évolution de la solution ou pour en confier l'exécution à un tiers si le soumissionnaire ou un de ses sous-
traitants reste en défaut (cessation de ses activités ou rupture du contrat).
Il s'engagera explicitement à ce que l'ASBL L'Equipe puisse récupérer ses données en clair (non crypté) dans un
format standard du marché. Le format est à décrire dans l’offre.
A la fin du contrat, que ce soit par expiration ou rupture, le soumissionnaire prêtera de bonne foi son concours
à l'ASBL L'Equipe afin que celle-ci ou un tiers puisse poursuivre sans difficulté les prestations exécutées dans le
cadre du contrat.
28 / 83
Le soumissionnaire expliquera comment il compte aborder le cas d'une rupture de contrat ou d'une cessation
d'activités en détaillant les informations qu'il juge utiles.
2.4.5. Maintenance et support

La maintenance de l'application doit être assurée durant toute la durée d'exécution du marché.
Le soumissionnaire doit décrire la maintenance à assurer pour les produits livrés.

Cela couvre notamment :
- La maintenance préventive
Elle doit couvrir au minimum l’évolution des versions de l’infrastructure technique de l’Equipe (Cfr
politique de changement en annexe 1).
- La maintenance corrective
Elle doit être identique à la garantie (cfr point 1.2.8)
- La maintenance évolutive
Elle doit contenir au moins l’engagement du soumissionnaire à intégrer les demandes d’évolutions
fonctionnelles ou réglementaires dans les délais prescrits par la loi.
Le soumissionnaire doit toujours prévenir l'ASBL L'Equipe d'une opération de maintenance de tous types, avec
un délai de 2 jours ouvrables s'il n'y a pas d'urgence absolue.
Chaque maintenance sera documentée et le soumissionnaire veillera que l'ASBL L'Equipe ait accès à cette
documentation.
Si une assistance technique en interne est nécessaire, elle peut être assurée moyennant un délai de 2 jours et
elle doit avoir lieu durant les heures d'ouverture de l'administration de L'ASBL L'Equipe.
Si un arrêt du logiciel est nécessaire lors d'une opération de maintenance, cette intervention devra être
effectuée de façon à perturber le moins possible la production, autrement dit de préférence dans des périodes
calmes (en fin d'après-midi par exemple).
En cas de problème technique (maintenance corrective), un gestionnaire en interne assurera la première ligne
et transmettra l'incident en deuxième ligne (adjudicataire). Le gestionnaire devra ensuite être tenu au courant
du suivi et de la résolution du problème. Le délai d'intervention sera défini dans le SLA.
2.5. SLA
2.5.1. Introduction
Afin de garantir un niveau de qualité de soins, l'ASBL L'Equipe souhaite, dans le cadre du présent cahier des
charges, qu'un SLA soit présenté par le soumissionnaire.
Les SLA permettent de surveiller les objectifs et les risques pour l'organisation liés aux services demandés.
Ce SLA comprendra un descriptif fixant les délais dans lesquels les services levels respectifs sont valables. Après
l'attribution du marché et jusqu'à l'échéance de la période d'exploitation, le soumissionnaire s'engage à
respecter les niveaux de service et les obligations de résultats fixés par le SLA qui figurent dans le cahier des
charges et dans son offre.
2.5.2. Elaboration des SLA dans le cadre de ce marché

Le soumissionnaire doit présenter un tableau reprenant au minimum les points suivants. Chaque point sera
détaillé pour permettre à l'ASBL L'Equipe d'évaluer la capacité du soumissionnaire à assurer le bon
fonctionnement du logiciel en toutes circonstances.
29 / 83
 Disponibilité du logiciel (hors maintenance) ;

o exprimé en pourcentage
o période d'application choisie : annuelle, trimestrielle, mensuelle, …
Le logiciel est appelé, à terme, à fonctionner 24h/24 et 7j/7.
La période de pointe est située du lundi au vendredi de 8h00 à 17h00. En-dehors de ces heures, seules
les structures le Foyer et la Pièce sont fonctionnelles mais en personnel très réduit.
Etant donné que notre but consiste à supprimer le dossier papier, ce critère a une grande importance
pour l'ASBL L'Equipe.
 Temps de réponse de l'application ;
 Maintenance préventive, corrective, d'urgence
Quelle est la procédure ? A quels moments ?
 Assistance à l'utilisation du logiciel.
Quel est le personnel disponible ? A quelles heures ?
 Traitements d'incidents
Ce point peut être détaillé selon le niveau et le type d'incident : bloquant, non bloquant, problème
technique, …
Le traitement débute lorsque l'incident a été signalé à l'adjudicateur selon la voie qu'il aura choisie.
Quel est le personnel disponible ? A quelles heures ?
Quelle est la procédure ?
Quel est le temps d’intervention ?
 Obligations du client
2.5.3. Reporting
Lors de la phase de développement et jusqu'à la réception définitive, un reporting mensuel faisant état de
l'avancement du projet et de sa mise en production devra être fourni par le soumissionnaire au comité de
pilotage.
Après chaque réception provisoire partielle correspondant à la fin d'une phase, le soumissionnaire fournira un
reporting annuel reprenant les niveaux atteints. En cas de prestations déficientes, le soumissionnaire devra en
expliquer la ou les causes et indiquer les mesures correctives qu'il a mises en place pour remédier à la situation.
30 / 83
ANNEXE 1
Etat actuel de l'infrastructure et du
reseau local
31 / 83
1. Etat actuel de l'infrastructure et du réseau local pour toutes les structures de L'Equipe
 4 structures interconnectées via réseau virtuel privé permanent de Proximus "réseau explore"
Chaque structure dispose d'un serveur connecté au site principal Jade
 Structures “non connectées » par lien permanent et sécurisé
VIVES – CLUB VIVES – IMAGO* « Terminal » Remote Desktop Services
(*)migration “explore” en cours
2. Nombre d'utilisateurs
 Environ 150 utilisateurs (sessions Active Directory) y compris les comptes de services
 Environ 100 mailbox (serveur exchange 2010 sp 3 UR 15) y compris les mailbox de services
3. Volume des PC
 Ordinateurs : 66 (Windows pro 7 64 bits Fr)
 pc portables : 8 (Windows pro 7 64 bits Fr)
 terminaux : 14 (Windows Embedded Standard 7 Fr & Thin Uk )
soit +/- 90 appareils au total (hors imprimantes, scanner, switch, routeurs, serveurs)
4. Serveurs et logiciels installés

4.1. Serveurs « hôtes » : 5 au total (4 en prodution + 1 en Test/Dev)
4.1.1. Jade
4.1.1.1. Production
 Hp Proliant DL 380 Gen9
 2 Disques O.S. en raid 1
 3 Disques Data en raid 5
 2 alimentations redondantes
 2 processeurs 2,64 Ghz 10 cores - 64 Gb Ram
 Ups
 Garantie Hardware NBD jusqu’en 2020
4.1.1.2. Test / Développement
 Hp Proliant DL 385 Gen7
 2 Disques O.S. en raid 1
 3 Disques Data en raid 5
 1 processeur 2,x Ghz 8 cores - 24 Gb Ram
 Ups
 Plus sous garantie Hardware depuis septembre 2015
4.1.2.Structures : 3 serveurs identiques (Centre Ados, Foyer, Babel/La Pièce) :
 Hp Proliant DL 360 G 8
 3 Disques O.S. et DATA en raid 5
 1 processeur 2,64 Ghz 6 cores - 8 Gb Ram
 Ups
4.2. Système de Virtualisation
VWMARE vSphere 5.5 u3
32 / 83
4.3. Serveurs Virtuels

4.3.1. JADE
4.3.1.1. PITON
DB Oracle + Programme Comptabilité générale
4.3.1.2. LOGAL
DB + programme comptabilité & pharmacie Centre Ados
4.3.1.3. STPlanner
DB Présence/Planning & Dossiers du personnel
4.3.1.4. Firewall
4.3.1.5. Domain Controller
4.3.1.6. File & Print
4.3.1.7. Exchange
4.3.1.8. AV + WSUS + BACKUP
4.3.1.9. ITSM
Ticketing + Inventory + Change Management (doc) : Service Desk Manage Engine 9.1
4.3.1.10. Ticketing Maintenance :

Service Desk Manage Engine (free version)
4.3.1.11. TERMINAL 1
STPlanner
Bureautique télétravail
4.3.1.12. TERMINAL 2
Bureautique structures VIVES & IMAGO
4.3.1.13. SRV-RDP (Windows 2003 R2 SP2)

Ancien serveur STPlanner et bureautique télétravail
33 / 83
Utilisé uniquement pour la facturation via programme MS Access ’97

Fin d’utilisation prévue : janvier 2018
4.3.2.Centre Ados
4.3.2.1. Serveur multirôles :
 Active Directory
 Fichiers et imprimantes
 WSUS pour les mises à jour
4.3.3.Le Foyer
4.3.3.1. Serveur multi-rôles
4.3.3.2. Terminal Serveur
 Bureautique : suite MS Office 2010
4.3.4.Babel – La Pièce
4.3.4.1. Serveur multi-rôles
4.3.4.2. Terminal Serveur
 Bureautique : suite MS Office 2010
4.4. Logiciels
4.4.1.Système d’exploitation
 Windows Server 2008 r2 sp1 en général
 Windows Server 2008 32 bits Sp2 : Terminal Logal
 Windows Server 2012 r2 sp2 : Base de données (SQL Server 2014) STPlanner
 Windows Server 2003 R2 sp2 : bureau à distance pour programme facturation sous MS Access ‘97
4.4.2.Messagerie électronique
 Microsoft Exchange 2010 SP3 U.R. 15
 Outlook 2010 et OWA
4.4.3.Antivirus
AV : Symantec End Point Protection 12 R.U. 5
Le programme client est installé sur tous les pc et serveurs
Le programme de Management est installé sur le serveur et permet la gestion centralisée via la console « SEP
Manager » ci-dessous.
34 / 83
4.4.4.Antispams
Filtre antispams et antivirus e-mails Sophos
4.4.5.Firewall
 Firewall Sophos UTM
 Firewall Cisco pour la gestion du réseau internet explore (géré par Proximus)
4.5. Backup / Disaster Recovery
Le backup est effectué sur un NAS Sygnology 4 x 2 TB en raid 5
 Backup journalier des données stockées au 60 VW :

o Backup data
o Mail
o Bases de données (STPlanner – Piton – Logal)
 Backup mensuel full & bimensuel (incrémental) avec rétention de 31 jours des données stockées dans
les structures « explore »
o Centre Ados
o Foyer
o Babel & La Pièce
5. Postes de travail
 Windows 7 Pro Fr
35 / 83
 Office 2010 Pro sp1

 Adobe Reader – Flash Player (I.E.& firefox)
 Mozilla Firefox 45 – Internet Explorer 11
 VLC media player
 Java 8 update 111 + eid (sur certains postes ayant un lecteur de carte d’identité)
 Les utilisateurs n’ont pas de privilèges spéciaux
6. Politique d’évolution de l’infrastructure technique

 Changement de serveur tous les 5 ans
 Suivi des versions de windows
o Avant-dernière version installée (actuellement Windows 7 sur PC)
o Remplacement de PC défectueux avec version de windows disponible (avant-dernière version
ou dernière version)
o Harmonisation des versions suivant le remplacement du parc informatique défectueux.
36 / 83
7. Schéma général
37 / 83
ANNEXE 2
Structure generale du DPI
38 / 83
CDC Projet final
Ce premier tableau reprend une série d’items permettant de constituer un enregistrement « light », nécessaire à la
première rencontre avec un patient lors d’une pré-admission.
0b. 1er contact

Droits
Droits Droits
Champ Valeur Obl Remarques Impres
Lecture Ecriture
sion
1 Date de contact Date Par défaut : date du jour S, St S, St S
2 Identifiant Identifiant de l'encodeur Identifiant indiqué automatiquement S, St S, St S
3 N° d'Identification du patient N° unique généré par le logiciel Retranscription possible vers onglet 1.1 S, St S, St S
Lu sur la carte d'identité ou encodage manuel
Nom Patient S, St, Ad S, St, Ad S, St, Ad
4 Texte Retranscription possible vers onglet 1.2
Prénom Patient S, St S, St S
N° NISS S, St, Ad S, St, Ad S, Ad
5b Nombre Retranscription possible vers onglet 1.6 et 2.5
Date de Naissance S, St S, St S
6 Date + calcul automatique de l'âge Retranscription possible vers onglet 1.7
Lieu de Naissance S, St S, St S
8 Appelant Nom, Prénom, lien, tél de contact S, St S, St S
1er contact / Consultation
Statut S, St S, St S
9 Date d'encodage
10 Origine de la demande texte libre Retranscription possible vers onglet 1.5 S, St S, St S
Sexe S, St S, St S
11 F/H Retranscription possible vers onglet 1.12
12 N° de tél fixe texte Retranscription possible vers onglet 1.16 S, St S, St S
13 N° de gsm texte Retranscription possible vers onglet 1.17 S, St S, St S
14 Email du patient email Retranscription possible vers onglet 1.12b S, St S, St S
15 Adresse de contact Adresse S, St S, St S
Liste : famille, Institution, Autre
Milieu de vie S, St S, St S
16 + Adresse
17 Envoyeur Texte libre S, St S, St S
18 Informateur Texte libre S, St S, St S
19 Suivi ambulatoire Texte libre S, St S, St S
20 Traitement psychotrope Texte libre S, St S, St S
Colonnes du tableau
Hospitalisation psychiatrique S, St S, St S
21 o/n, nom hôpital, dates, en cours / antécédents /sortie récente
Dernière année réussie
Niveau
Situation scolaire S, St S, St S
Nom école
22 date
Colonnes du tableau :
Mesures d'aide à la jeunesse
Type (SAJ, Juge et SPJ, Mise en Observation) S, St S, St S
et judiciaires
23 Commentaire
- date
- Proposition
Proposition - rdv + travailleur concerné + date du rdv, Le rdv doit être ajouté à l'agenda du travailleur S, St S, St S
- réorientation vers + commentaire,
- Rappel à/par + commentaire,
24 - Autre + commentaire)
Etat de la question énoncée au
S, St S, St S
25 téléphone Texte de l'entretien Encodage via le Use Case E.3.2
- Date
Entretiens - Personnes présentes S, St S, St S
- Entretien (texte libre)
26 - Attestation de soins Y/N, Date, Code de Nomenclature Encodage via le Use Case E.3.3
27 N° de mutuelle Liste déroulante des mutualités belges Retranscription possible vers onglet 2.1 S,St, Ad S, St, Ad S,Ad
28 CT1/CT2 nombre/nombre Retranscription possible vers onglet 2.2 S,St, Ad S, St, Ad S,Ad
Liste déroulante
Statut préférentiel S,St, Ad S, St, Ad S,Ad
29 Titulaire, BIM, MAF Retranscription possible vers onglet 2.3
Nom
Titulaire (si différent de l'assuré) Prénom S,St, Ad S, St, Ad S,Ad
30 Adresse Retranscription possible vers onglet 2.4
39 / 83
CDC Projet final
1. Données administratives du patient

Droits Droits Droits
Champ Valeur Obl Remarques
Lectur Ecriture Impres
1 N° d'Identification du patient N° unique généré par le logiciel S,St, Ad S, St S
2 Nom Texte Lu sur la carte d'identité ou encodage manuel S,St, Ad S, St S
3 Prénom Texte Lu sur la carte d'identité ou encodage manuel S,St, Ad S, St S
Tableau reprenant l'ensemble des statuts
Statut En attente/ actif /mercredi/terminé / archivé La date permet de garder un historique de son passage chez nous S,St, Ad S, St S
4 Date d'encodage Classement par odre de dates décroissantes
5 Origine de la demande texte libre S, St S, St S
6 N° NISS Nombre Lu sur la carte d'identité ou encodage manuel S,St,Ad S, St S
7 Date de Naissance Date + calcul automatique de l'âge Lu sur la carte d'identité ou encodage manuel S,St,Ad S, St S
8 Lieu de Naissance Texte Lu sur la carte d'identité ou encodage manuel S,St,Ad S, St S
9 Photo CI Image Lu sur la carte d'identité ou scan S,St,Ad S, St S
10 Langue Texte Valeur par défaut : Français S,St,Ad S, St S
11 Culte Texte S, St S, St S
12 Sexe F/H S,St,Ad S, St S
12b Email du patient email S, St S, St S
Lien (Liste déroulante : père, mère, sœur, frère, …) Liste déroulante à compléter par l'utilisateur
Nom
Prénom
Décédé ? : O/N (par défaut : N)
13 Coordonnées familiales S, St S, St S
Adresse (Rue, N°, CP, Commune, Pays) Tableau extensible reprenant l'ensemble des coordonnées
Téléphone familiales classé selon l'ordre d'encodage
Gsm
email Possibilité de recopier facilement les coordonnées d'une ligne supérieure
Profession
Colonnes du tableau
Type (Foyer parental, foyer maternel, foyer paternel,
Tableau extensible, classé par odre de dates de validité décroissant
Institution d'hébergement, famille d'accueil, autres)
Possibilité de recopier une adresse déjà encodée dans le tableau n°13
14 Domicile Légal Placement judiciaire (O/N), S, St S, St S
Nom institution ou personne,
Un lien avec une BDD des communes de Belgique est un plus
Adresse (Rue, N°, CP, Commune, Pays)
Dates de validité
Colonnes du tableau
Type (Foyer parental, foyer maternel, foyer paternel, Tableau extensible, classé par odre de dates de validité décroissant
alternance, Institution d'hébergement, Possibilité de recopier une adresse déjà encodée dans le tableau n°13
15 Lieu de vie (si diff domicile) famille d'accueil, Mise en autonomie, autres) S, St S, St S
Nom Institution ou personne, Les institutions peuvent être recherchées dans une BDD encodée par le client,
Adresse (Rue, N°, CP, Commune, Pays) basée sur le guide social.
Dates de validité
16 N° de tél fixe texte S, St S, St S
17 N° de gsm texte S, St S, St S
Texte
18 Nationalité S, St S, St S
Si séjour temporaire : dates de validité Possibilité d'adjoindre un document scanné si nécessaire
Situation familiale
Liste déroulante : Liste extensible par l'utilisateur
S, St S, St S
19a Ménage, Séparés, Divorcés, Famille Monoparentale, …
Situation des parents (par défaut : vide)
Colonnes du tableau Tableau extensible classé par ordre décroissant de dates de validité
Lien, Possibilité de recopier facilement une ligne du tableau n°13
19b Responsable légal Nom,
Prénom,
S, St S, St S
dates de validité
Liste déroulante : Liste extensible par l'utilisateur
19c Situation du patient Célibataire, Ménage, Séparé, Divorcé, …
(Par défaut : vide)
Nom
Prénom
19d Enfants du patient S, St S, St S
date de naissance
situation (liste déroulante : à charge, droit de garde,
droit de visite, placement, plus de contact)
Lien
Nom Tableau extensible classé par ordre d'encodage S, St,
20 Contact en cas d'urgence S, St S
Prénom Possibilité de recopier facilement une ligne du tableau n°13 ou n°14 ou n°15 Ad
Tél 1
Tél 2
Assurance familiale
S, St S, St S
21 Compagnie Texte
N° de contrat Texte S, St S, St S
22 Prise en charge du paiement Peut être le patient lui-même S, St, Ad S, St S

Possibilité de recopier facilement une ligne du tableau n°13 ou n°14
40 / 83
CDC Projet final
2. Données d'assurabilité du patient

Droits
Droits Droits
Champ Valeur Obl Remarques Impressio
Lecture Ecriture
n
1 N° de mutuelle Liste déroulante des mutualités belges S,St, Ad S, St, Ad S,Ad
2 CT1/CT2 nombre/nombre S,St, Ad S, St, Ad S,Ad
Liste déroulante
3 Statut préférentiel S,St, Ad S, St, Ad S,Ad
Titulaire, BIM, MAF
Nom
4 Titulaire (si différent de l'assuré) Prénom S,St, Ad S, St, Ad S,Ad
Adresse
Valeur remplie automatiquement en copiant
S,St, Ad S,St, Ad S,Ad
5 N° NISS Nombre la rubrique 1.6
3. Ressources du patient
Droits
Droits Droits
Lecture Ecriture
n
Type
- Mutuelle
- CPAS
- Administrateurs de Biens Type est une liste déroulante à compléter
- Aide médicale urgente par l'utilisateur
- Réquisitoire
1 Revenus du patient S, St S, St S
- Allocations handicapés
- Allocations chômage
- Indemnités incapcité / invalidité Tableau extensible classé par ordre d'encodage
- Allocations de remplacement de revenus
- Revenus d'intégration
- Autre (à préciser)
Montant
O/N
2 Allocations familiales perçues Nom du percepteur S, St S, St S
Majorées ? O/N
O/N
3 Inscription ONEM Stage d'attente ? Dates du … au …. S, St S, St S
Indemnités (Montant)
Lien,
Nom,
Prénom,
dates de validité Copie automatique du tableau de la rubrique
Type de revenus : 1.19b + ajout de la colonne Type de revenus
4 Revenus du responsable légal S, St S, St S
- Travail
- CPAS
- Mutuelle
- Handicap
- Chômage
- Autre
41 / 83
CDC Projet final
4. Situation scolaire
Droits
Droits Droits
Lecture Ecriture
n
1 Arrêt de fréquentation scolaire Date S, St S, St S
O/N
2 Certificat médical d'incapacité S, St S, St S
Délivré par : nom du médecin Le noms des médecins constituent une BDD encodée par le client
Date : Année scolaire (ex : 2016-2017)
Niveau et sous-niveau
- Primaire
- général
- spécial + N° du type d'enseignement
- Secondaire
- général Tableau classé par années scolaires décroissantes
- technique de transition
- technique de qualification Mettre en vert la ligne concernant la date
- professionnel d'aujourd'hui (si existante)
3 Parcours scolaire - spécial + N° du type d'enseignement S, St S, St S
- Supérieur Mettre en bleu la ou les lignes concernant
- type court des dates futures (si existante)
- universitaire
- Autre
- texte libre
Nom de l'école : texte
Adresse de l'école : texte
Personne de contact : Nom, Prénom,
Tél, email
Réussi ? : O/N
Commentaires : texte libre
4 CEB Obtenu ? O/N S, St S, St S
5 Projet scolaire énoncé au début de la prise en charge Texte Libre S, St S, St S
Date intervention : mois, année
Nom
Adresse Tableau extensible classé par dates décroissantes
6 Interventions PMS S, St S, St S
Contact (nom, prénom) Possibilité d'annexer un document Word ou PDF
Tél
email
Conclusions : texte libre
Nom
Tableau extensible classé par dates décroissantes
7 Fréquentation antérieure d'une Ecole à l'hôpital Type d'enseignement S, St S, St S
Nom basé sur une BDD école à l'hôpital encodée par le client
Ambulatoire / Hospitalisation : A/H
Dates : du … au …
Possibilité d'annexer le Rapport PIA des enseignants de l'école
8 PIA - Robert Dubois Fichier PDF S, St S, St S
Robert Dubois
5. Parcours professionnel
Droits Droits
Droits
Champ Valeur Obl Remarques Ecritur Impressio
Lecture
e n
1 Etat passé A travaillé les 2 dernières années O/N S, St S, St S
Case(s) à cocher :
étudiant
en activité (nature emploi, de… à …)
chômeur
retraité
2 Situation actuelle Pour le centre Ados : par défaut, cocher la case étudiant S, St S, St S
foyer
incapacité (du … au ..., dévivré par
(nom du médecin)
autre
inconnu
6. Situation médico-légale
Droits
Droits Droits
Champ Valeur Obl Remarques Ecritur
Lecture Impression
e
O/N + dates début et fin Par défaut : N
1 Mise en observation S, St S, St S
Maintien : O/N, jusque (date)
Date du maintien
Libération à l'essai : O/N
Mesures probatoires : texte libre
Services assurant le suivi :
2 Défense sociale S, St S, St S
sous-tableau :
- type
(tutelle, médicale, tutelle sociale, AS, justice)
- nom
- contact
3 Antécédents d'hospitalisation for K O/N , Date, Remarque S, St S, St S
42 / 83
CDC Projet final
6b. Situation judiciaire et protectionnelle

Droits
Droits Droits
Lecture Impression
e
Nom
1 SAJ Délégué : Nom, Prénom, tél, email S, St S, St S
Conseiller : Nom, prénom, tél, email
Arrondissement
2 SPJ Juge : Nom, Prénom, tél, email S, St S, St S
Délégué : Nom, Prénom, tél, email
O/N
Nom
3 IPPJ Dates début et fin S, St S, St S
Service assurant le suivi : Par défaut : N
O/N, Nom, prénom, tel, email
Type d'institution
Nom de l'institution Tableau extensible classé par ordre de dates
4 Séjour/Placement en institution S, St S, St S
Nom du contact décroissantes si existantes
Téléphone
Dates du … au …
Nom de l'administrateur de biens
(liste déroulante par ordre
5 Administration de biens alphabétique complétable par S, St S, St S
l'utilisateur)
Adresse : rue, n°, CP, Ville
Nom
6 Antécédents COE S, St S, St S
Dates de prise en charge : du … au …
7 Justice spécifique aux stupéfiants Texte libre S, St S, St S
7. Réseau psycho-médico-social
Droits
Droits Droits
Lecture Impression
e
- Type (liste de choix : médecin traitant,
Tableau classé par type (alphabétique),
psychiatre traitant, psychologue, service
ensuite par dates de validité
social, …)
décroissantes (si existantes)
1 Liste des acteurs du réseau du patient - Nom de l'institution S, St S, St S
- Nom du contact
La ligne médecin traitant doit apparaître
- Téléphone
pour info dans la rubrique 17.2
- email
- dates de validité du … au …
8. Génogramme
Lecture Ecriture Impression
Diagramme représentant l'arbre Méthode utilisée à déterminer
1 Génogramme S, St S, St S
généalogique du patient Possibilité d'annexer un PDF
43 / 83
CDC Projet final
9. Antécédents médicaux
Droits
Droits Droits
Lecture Ecriture
n
Colonnes du tableau : Possibilité d'annexer un PDF
Hôpital Le tableau doit aussi apparaître
1 Antécédents médicaux psychiatriques S, St S, St S
Dates du … au …. en rubrique 17.4, modifiable
Rapport : O/N des 2 côtés
Nature
2 Antécédents médicaux somatiques Date Possibilité d'annexer un PDF S, St S, St S
Age
Rapport : O/N
Possibilité d'annexer un PDF
Nature
Le tableau doit aussi apparaître
3 Antécédents chirurgicaux Date S, St S, St S
en rubrique 17.3, modifiable
Age
des 2 côtés
Rapport : O/N
Nature
4 Antécédents familiaux et génétiques Possibilité d'annexer un PDF S, St S, St S
Lien
Rapport : O/N
Affections somatiques toujours
5 Diagnostic S, St S, St S
en cours à l'entrée
Depuis : date
10. Consommation de toxiques

Droits Droits
Droits
Lecture
e n
Produit principal
1 Consommation actuelle Mode de consommation S, St S, St S
Fréquence de consommation
Produit
2 Produits secondaires S, St S, St S
Mode de consommation
Fréquence de consommation
Age
3 Première prise toxique S, St S, St S
Circonstances : texte libre
Tableau classé par ordre
4 Traitements spécifiques antérieurs Année S, St S, St S
d'année décroissant
Traitement
11. Projets de soin

Droits
Droits Droits
Lecture Ecriture
n
- Texte libre, des colonnes
1 PIS (Projet Individuel de soin) S, St S, St S
pourraient être définies plus tard
2 Projets Projet : texte libre S, St S, St S

3 Finalité du traitement Finalité : texte libre S, St S, St S
4 Facteurs liés au projet Facteurs: texte libre S, St S, St S
5 Objectifs généraux Objectifs Généraux: texte libre S, St S, St S
6 Objectifs secondaires Objectifs secondaires : texte libre S, St S, St S
7 Moyens Moyens: texte libre S, St S, St S
44 / 83
CDC Projet final
12. Données Séjour Patient
Date d'entrée
1 Dates de séjour S, St S, St S
Date de sortie
2 Référent Liste de choix : personnel Une table reprenant le personnel sera encodée par le client S, St S, St S
3 Psychologue Liste de choix : personnel parmi les fonctions psy Une table reprenant le personnel sera encodée par le client S, St S, St S
4 Référent pédagogique Liste de choix : personnel Une table reprenant le personnel sera encodée par le client S, St S, St S
5 Psychiatre Liste de choix : personnel parmi les médecins Une table reprenant le personnel sera encodée par le client S, St S, St S
Possibilité de visualiser les présences ou absences du
6 Dates de présence et absence L'encodage est fait via le Use Case E.3.1 S, St S, St S
patient par mois
Posibilité de visualiser les statistiques de présence ou
7 Statistiques de présence et absence L'encodage est fait via le Use Case E.3.1 S, St S, St S
absences du patient par code/par mois/par année
Visualiser toutes les dates d'hospitalisations (code Hi)

8 Rapport d'hospitalisations intercurrentes L'encodage est fait via le Use Case E.3.1 S, St S, St S
ainsi que les noms des hôpitaux correspondants du patient
Possibilité de visualiser les rdv du patient
I/E : Interne ou Externe
type : ateliers, entretiens, autre
Remarque : texte libre
9 Agenda du patient L'encodage est fait via le Use Case E.3.8 S, St S, St S
de (heure ) à (heure)
+
faire apparaître les codes d'absences prévues si déjà
encodées dans le calendrier de présence
Liste des présences (dates) par atelier
Calcul et visualisation des statistiques de fréquentation
10 Statistiques des ateliers des ateliers pour le patient / mois/année/séjour S, St S, St S
+
Par (date) à (date)
13. Notes journalières

Droits Droits
Droits
Lecture
e n
Tableau reprenant toutes les notes concernant le
S, St
patient (sauf entretiens repris dans les rubriques Encodage via les Use Cases n° E.3.2
on ne
15,16,18,19 ) affichées par ordre de date
peut
décroissante Possibilité de trier les notes par origine ou par type ou
1 Notes S, St modifier S
Les colonnes du tableau sont : entre 2 dates sur demande de l'utilisateur
que sa
- Origine : Carnet de bord / staff / ateliers / autre Possibilité d'accéder directement au Use Case E.3.2 pour
propre
- Type (si nécessaire) : synthèse, … y ajouter une note ou un amendement
note
- Notes : texte libre
14. Données médicaments

Champ Valeur Obl Remarques Droits
1 Lien vers le logiciel LOGAL
45 / 83
CDC Projet final
15. Volet psychiatrie
Droits
Droits Droits
Lecture Impression
e
1 Motif d'entrée Texte Libre S, St Me S
1b Adressé par Nom, prénom
2 Examen mental à l'entrée Texte Libre S, St Me S
Colonnes du tableau
Classement par ordre de date de début décroissante
Date début
3 Diagnostic Possibilité d'afficher uniquement les diagnostics sans S, St Me S
Date de fin
date de fin par ordre de date de début décroissant
Texte Libre
4 Diagnostic Codification DSM V S, St Me S
5 Diagnostic Codification Snomed Dès que la version française officielle sera disponible S, St Me S
Bouton permettant de générer une lettre d'entrée,
Modèle créé par le UC SPF 7.1
Lettre type à remplir avec les valeurs
6 Lettre d'entrée N° lettre auto, Date de S, St Me S

Si une lettre est validée, elle est figée .
création,Encodage des valeurs
Plusieurs lettres peuvent être générées si des infos sont
demandées, Validation : O/N
modifiées
Colonnes du tableau
Date, Classement par ordre de date décroissante
identifiant Classement à la demande par sous-type, par identifiant,
7 Notes d'entretiens individuels Type d'entretien (Psychiatrie entre 2 dates S, St Me S
(Individuel, familial, concertation,
quintet, autre)) Le texte s'encode directement dans le DPI du patient
Texte Libre
Encodage via Use Case E.3.2
8 Notes privées Texte Libre, date, identification Ut Ut (Me) Ut
Le contenu n'est pas sauvegardé dans le traçage du log
9 Annexes Date, Sujet, Document PDF Possibilité d'annexer un PDF S, St Me S
Bouton permettant de générer une lettre de sortie,
Lettre type à remplir avec les valeurs
10 Lettre de sortie N° lettre auto, Date de S, St Me S

Si une lettre est validée, elle est figée .
création,Encodage des valeurs
Plusieurs lettres peuvent être générées si des infos sont
demandées, Validation : O/N
modifiées
Colonnes du tableau
Date :
Historique des communications N° de la lettre envoyée
10b
des lettres de sortie Destinataire
Mode de communication
Bouton permettant de générer le rapport de sortie

N° du rapport, Date de création,
11 Rapport de séjour Si un rapport est validé, il est figé . S, St Me S
Validation O/N
Plusieurs rapports peuvent être générés si des infos sont
modifiées
Colonnes du tableau
Date :
Historique des communications N° du rapport envoyé
12 S, St Me S
du rapport de séjour Destinataire
Mode de communication
Colonnes du tableau
Date :
13 Concertations pluridisciplinaires Personnel présent : S, St Me S
Texte :
46 / 83
CDC Projet final
16. Volet Psychologie
Colonnes du tableau
Classement par ordre de date décroissante Psy
Date,
Classement à la demande par identifiant, entre 2 dates (identifi
1 Notes d'entretien individuel identifiant S, St S
é en
Type d'entretien (psychologique)
Le texte s'encode directement dans le DPI du patient 12.3)
Texte Libre
Tableau reprenant :
- Identifiant (login de l'utilisateur)
Psy
- Nom psy prestataire du test
Encodage directement dans l'onglet 16, pas de Use Case (identifi
2 Testing - Nature des tests (TAT, RORSCHAH, S, St S
Possibilité d'annexer un PDF é en
WISC, Bilan attentionnel, autre)
12.3)
- texte Libre
- annexe PDF Possible
Ut (Psy
Encodage via Use Case E.3.2 (identifi
3 Notes privées Texte Libre, date, identification Ut Ut
Le contenu n'est pas sauvegardé dans le traçage du log é en
12.3))
Psy
(identifi
4 Annexes Date, Sujet, Document PDF Possibilité d'annexer un PDF S, St S
é en
12.3)
Psy
(identifi
5 Rapport de séjour Texte Libre S, St S
é en
12.3)
17. Volet Infirmier

Date,
Poids,
Taille,
Permet aussi de visualiser le BMI du patient par rapport à
1 Mesures BMI (calcul automatique S, St Inf S
la courbe de corpulence des garçons/filles de 0 à 18 ans
(poids/taille2))
Tension artérielle,
Pulsations,
Température
affichage sans modif de la ligne du
2 Médecin traitant tableau Rubrique 7.1 (médecin S, St Inf S
traitant)
affichage avec modif de la
3 Antécédents chirurgicaux Possibilité de modifier les données directement S, St Inf S
rubrique 9.3
affichage avec modif de la
4 Antécédents psychiatriques Possibilité de modifier les données directement S, St Inf S
rubrique 9.1
Colonnes du tableau : La notation des allergies aux médicaments doit encore
5 Allergies, contre-indications Type (Médicament, Alimentaire ) être déterminée en partenariat avec le logiciel LOGAL, S, St Inf S
Texte libre gestionnaire des médicaments
6 Régimes alimentaires Texte libre S, St Inf S
Colonnes du tableau
7 Vaccinations Date, S, St Inf S
Vaccin
8 Traitement à l'arrivée Texte libre S, St Inf S
9 Loisirs Texte libre S, St Inf S
10 Alcool Texte libre S, St Inf S
11 Tabac Texte libre S, St Inf S
12 Sommeil Texte libre S, St Inf S
13 Rituels Texte libre S, St Inf S
Colonnes du tableau
Horodatage automatique,
Date,
14 Feuille de soins Ne peut être modifié que par le login encodeur S, St Inf S
Identifiant,
Soins à prodiguer,
Observations,
Colonnes du tableau
Horodatage automatique,
Date,
15 Transmissions ciblées Identifiant, Ne peut être modifié que par le login encodeur S, St Inf S
Cibles,
D/A/R,
Transmissions
16 Annexes Date, Sujet, Document PDF Possibilité d'annexer un PDF S, St Inf S
47 / 83
CDC Projet final
18. Volet social

Droits Droits
Droits
Champ Valeur Obl Remarques Lectur Impressio
Ecriture
e n
Colonnes du tableau
Date,
Classement par ordre de date décroissante
1 Notes d'entretien individuel identifiant S, St AS S
Classement à la demande par identifiant, entre 2 dates
Type d'entretien (Social)
Texte Libre
Le texte s'encode directement dans le DPI du patient
2 Notes privées Texte Libre, date, identification Ut Ut (AS) Ut
3 Annexes Date, Sujet, Document PDF Possibilité d'annexer un PDF S, St AS S
18b. Référent
Droits
Droits Droits
Lecture Ecriture
n
Colonnes du tableau
So
Date,
Classement par ordre de date décroissante (identifi
1 Notes d'entretien individuel identifiant S, St S
Classement à la demande par identifiant, entre 2 dates é en
Type d'entretien (Référent)
12.2)
Texte Libre
Le texte s'encode directement dans le DPI du patient
Ut (So
2 Notes privées Texte Libre, date, identification Ut identifié Ut
en 12.2)
So
(identifi
3 Annexes Date, Sujet, Document PDF Possibilité d'annexer un PDF S, St S
é en
12.2)
So
(identifi
4 Rapport de sortie Texte Libre S, St S
é en
12.2)
19. Référent Pédagogique


Colonnes du tableau
So
Date, Classement par ordre de date décroissante
(identifi
1 Notes d'entretien individuel identifiant Classement à la demande par type, par identifiant, entre S, St S
é en
Type d'entretien (pédagogique) 2 dates
12.4)
Texte Libre Possibilité d'accéder directement au Use Case E.3.2 pour
encoder une nouvelle note ou pour faire un amendement
Ut (So
2 Notes privées Texte Libre, date, identification Ut identifié Ut
en 12.4)
So
(identifi
3 Annexes Titre de l'annexe Annexe possible d'un PDF S, St S
é en
12.4)
So
(identifi
4 Rapport de sortie Texte libre S, St S
é en
12.4)
48 / 83
CDC Projet final
20. Sortie / Postcure

Droits
Droits Droits
Lecture Ecriture
n
1 Projet de sortie Texte libre S, St S, St S
Colonnes du tableau
2 ATTP (Accueil thérapeutique à temps partiel) Date : de … à ... S, St S, St S
Jour : mercredi / autre ( à préciser)
Affichage des dates d'encodage du

3 Sorties à l'essai code SE dans le tableau des S, St S, St S
présences du patient
Liste de choix (avec commentaire
possible):
- avec approbation du staff
- avec avis réservé du staff
- à l'initiative du staff
- Trop peu de présences
- Mise à mal du cadre
4 Modalités de sortie - Age limite S, St S, St S
- Projet de suivi inadéquat
- Sans concertation
- Initiative du patient
- Initiative du patient et de sa
famille
- Initiative de la famille
- Autre (à préciser)
Tableau indépendant de la
5 Lieu de vie rubrique 1.15 mais même structure S, St S, St S
que rubrique 1. 15
Tableau indépendant de la
6 Projet de scolarité rubrique 4.3 mais même structure S, St S, St S
rubrique 4. 3
Liste indépendante mais même
7 Projet de profession S, St S, St S
structure que rubrique 5. 2
Tableau indépendant Bouton permettant de recopier une ou plusieurs lignes du
8 Projet du réseau psycho-médico-social S, St S, St S
Même structure rubrique 7. 1 tableau en rubrique 7.1
O/N
9 Hospitalisation Motif : S, St S, St S
Lieu :
O/N
Tableau avec liste de choix
10 Intervention judiciaire - SPJ, Juge, Mise en Observation, S, St S, St S
défense sociale, placement
- Commentaire
11 Aide à la jeunesse O/N S, St S, St S
21. Consentements
Droits Droits
Droits
Lecture
e n
Se base sur une liste à encoder par L'Equipe + Annexe
PDF possible du consentement signé:
- Accord pour la plate-forme de santé bruxelloise
- Consentement pour le traitement des données à
Sujet
1 Liste des consentements à obtenir caractère personnel S, St, Ad S,St S, Ad
Manière
- Contact avec PMS
Accord : O/N (par défaut : vide)
- Descriptif de prise en charge
- Transfert de données administratives inter-Equipe
- Autres : ...
22. Limitation de thérapie

Droit
Droits
s Droits
Champ Valeur Obl Remarques Impres
Lectu Ecriture
sion
re
Directive
1 Liste de refus de thérapie ou directives du patient Possibilité d'annexer un document S, St S, St S
Horodatage
Soignant encodeur
49 / 83
CDC Projet final
23. Ségrégations
Tableau reprenant les ségrégations
effectuées :
1 Enregistrement des ségrégations S, St S, St S
Date
Texte libre
50 / 83
CDC Projet final
ANNEXE 3
Belgian Meaningful Use Criteria for
Other Hospitals
51 / 83
CDC Projet final
Belgian Meaningful Use Criteria for Mental Healthcare Hospitals and

other non-general Hospitals
Introduction
This document is the result the conclusion of the WG Belgian Meaningful Use Criteria for Mental
Healthcare Hospitals and other non-general Hospitals. It is the result of a concertation of mental
healthcare hospitals and other non-general hospitals all over the country , hospitals of different sizes
and different degree of ICT maturity.
It is to be seen and read in conjunction with the text under construction by the General Hospitals
describing the ‘Belgian Meaningful Use Criteria’ for an EHR in a general hospital.
Its purpose is to propose to the federal government a number of criteria to determine whether a
mental healthcare hospital is eligible for public funding for its past and future efforts in EHR
development and implementation.
Important remarks
It is recommendable to align the stages between general and mental health care hospitals.
Therefore, the timeline for the subsequent stages is identical to the one for the general hospitals.
For every criterion, the method of measurement has to be as simple and clear as possible. For the
criteria expressed as a percentage, numerator and denominator are defined. Maximum alignment
with the general hospitals is necessary.
Where a percentage should be reached, we propose a numerator and denominator that can be
measured without too much effort.
52 / 83
CDC Projet final
Table of Core Criteria for ‘Other’ hospitals

Not reaching the criteria of a functionality for which a percentage less than 50% is demanded can be
compensated by reaching the criteria of step 2 of another functionality (except for functionality 1, 4,
6, 7, 10, 11, 12, 14 and 15).
Mental Healthcare hospitals

Criteria Step 1 Step 2 Step 3 Step 4
1. Unique patient identification and 80% 90% 98% 98%
description
2. Problem list 20% 50% 80% 98%
(active and past diagnoses)
3. Allergy list 30% 60% 90% 98%
4. e-prescription medication 80% 90% 95% 98%
5. Drug drug interaction Yes Yes Yes Yes
6. e-administration medication (linked 80% 85% 95% 98%
to e-prescription)
7. Electronic discharge letter 80% 90% 95% 98%
8. Informed consent registration 10% 50% 80% 98%
9. Therapy limitation code 10% 50% 80% 98%
10. Automated communication with 80% 90% 95% 98%
HUB’s and interaction with eHealth
11. Multidisciplinary registration and 70% 80% 95% 98%
exchange of information
12. Control of the interdisciplinary 60% 70% 95% 98%
treatment plan and of the tasks of
each discipline via the EHR
13. Segregations No Yes Yes Yes
14. Registration observations 80% 90% 98% 98%
15. Support for integrating results ( 60% 70% 80% 90%
protocols) of internal requested but
external executed studies.
Menu Criteria
A (yet to be defined) number of menu items can be selected by the hospital in order to prepare for a
full EPR implementation in the future.
Some of the menu items can become mandatory in a later step, thus becoming core from that step
on.
The following menu items could be considered:
 Structured outcome measurement is possible.

 Possibility for the patient to add directly data to the EHR, which may have an impact on the
care during the hospitalization)
 Doctors on call can access the patient record and prescribe medication.
 Therapyplanning
 Measures restricting physical freedom: other than segregation
53 / 83
CDC Projet final
Core Criteria Description
1. Unique patient identification and description
Following demographics must be registered in a structured way: full name, date of birth, gender,
nationality, National ID (in case of a Belgian civilian), address, phone number, preferred
language, insurance information, name of general practitioner, (pass) photo when possible. It
should be possible to register contact information: name, relationship to the patient and phone
number. This information must be maintained on a regular basis, at each patient visit in the
hospital. This patient information is accessible online anywhere in the institution.
One unique patient number should be used throughout all electronic systems that register
patient related data. In case a patient has two patient numbers, these numbers should be linked
together in a way so the users of the system can access all the information through one patient
number. Processes to search for double patient numbers in a regular way should be
implemented.
When the identity of the patient cannot be established at registration time, it should be possible
to create a unique temporary patient number, so one can register data for this patient. When
later the identity of the patient is established and his unique patient number is created or
determined, the registrations linked to the temporary patient number have to be transferred to
the actual patient number, or linked together.
Measure:
 Numerator: The number of unique patients in the denominator that have the listed
demographic information available plus the number of unique patients for which a
temporary patient id is created and no establishment of identity was available in the EHR
reporting period of the denominator.
 Denominator: the number of unique patients in inpatient, one day care or emergency
setting in a given EHR reporting period (to be defined).
2. Problem list (active and past diagnoses)
A persistent and managed Belgian SNOMED CT coded list of identified diagnoses or problems, or
previous procedures performed, that may influence clinical decision-making and care provision.
Problem lists are managed over time, hence giving a historical view of the patient’s condition and
may include:
 symptoms , diagnoses, allergies, devices in situ
 family and genetic information
 social problems, events

 nursing problems & risks
 functional (dis)ability,
 treatment and regimens
 interventions (done & planned)diagnostic procedures (done & planned)
 vaccinations (done & planned)
54 / 83
CDC Projet final
The source (e.g. the provider, the system id, or the patient, the location, time) of updates should
always be documented for every item and version (unique Record ID with Timestamp).
The onset and end dates, if known, should be documented for every item. The problem list can
be represented (based on the time status of each item) as historical, or / and as an “active”
problem list.
Measure
In Step 1, more than 20 percent of all unique patients hospitalized in the reference period
(denominator) have at least one SNOMED CT coded entry or an indication that no problems are
known for the patient recorded as structured data (numerator).
Important remark: The target date to reach this goal is relative to the availability of
the Dutch/French translation of the main SNOMED CT diagnostic codes. The
implementation has to be at least two years (one year for technical development and
one year for implementation)one year after the final availability of the translated
codes.
3. Allergy list
Manage patient allergies including reaction for any allergen, intolerance and adverse reaction
lists (to drug, dietary). The allergy list is used when allergenic conditions are encountered in
other modules of the EPR (drug prescription,…).
Step 1 : Recording of 2 type of allergies (drugs, food, …) and showing the list of existing allergies
at e.g. presciption time should be sufficient (due to lack of structured datasets)
Step 2: Automatic triggering of alarms when allergenic conditions are encountered (to be defined
in more detail)
Measure
 Numerator: The number of unique patients in the denominator that have at least one
entry in their allergy list (or an indication of no known allergies). Reconciliation of the
entry “no known allergies” is necessary at each new eligible contact.
 Denominator: the number of unique patients in inpatient, one day care or emergency
setting in a given EPR reporting period (to be defined).
4. e-Prescription (computerized provider medication order entry)
The benefits of computerized provider medication order entry (CPOE) are well known. The most
evidence is found in medication order entry even with little or no decision support. A CPOE
embedded in the electronic patient record is even more beneficial since the information from the
rest of the patient record becomes available to the health professional during the prescription
process (e.g. laboratory results…). Although the most benefit may be seen if the CPOE system is
used in conjunction with well designed and implemented decision support.
The beneficial effects include greater use of formulary medication, elimination of ambiguities
caused by illegible handwriting, use of order sets containing related orders for specific purposes,
55 / 83
CDC Projet final
use of templates enforcing standardization of care, use of recommended dosages and improved
efficiency of care delivery.
The use of CPOE, however, carries a non-negligible potential for harm and unintended
consequences: entering of duplicate orders, inadverted overdosing, unfavorable workflow issues,
paper persistence. Many of the latter may be overcome by implementing a well-designed CPOE
and by adding a decision support system to the CPOE.
System requirements for CPOE in medication ordering
 The drugs prescribed in the CPOE are available in a central hospital-wide medication
database managed by the pharmacy department.
 The pharmacy can define a subset of this database that represents the formulary. The
system directs the prescriber to the use of formulary medications.
 The system supports generic medication orders and medication orders by drug trade
name.
 Medication orders are entered in a structured format (e.g. drug name, dose, dosage
form, start/end time for order, unit, frequency, administration route, clinical indications
for an ‘as necessary’ order…). Each medication order is built up with all necessary
components in order to ensure compliance with the Belgian legislation concerning
medication prescriptions.
 All actions on medication orders (start, stop, change, cancel) are logged in the system
and a complete audit trail can be performed for each individual medication order.
 The system supports a workflow where the pharmacist is able to validate a medication
prescription. This validation, however, may not impede of execution of the medication
order. However, this validation process may be mandatory for some medication orders.
 The system supports a workflow where the pharmacist is able to substitute a drug for an
alternative (formulary) drug
 Only licensed health care professionals are authorized to enter medication orders. The
rights for entering medications orders are configurable.
 The system supports a workflow for oral orders. This workflow allows the administration
of a drug to a patient with mandatory retro-active approval by a licensed health care
professional.
 The prescriber has during the prescription process access to relevant information (e.g.
clinical information, lab-results, other..).
 The user has during the prescription process access to relevant drug information (e.g.
drug references)
 The system is able to deliver a complete overview of all current medication orders. The
system also can show an overview of the medication orders of a certain time frame.
These medication order overviews are available to all relevant users, including the
pharmacist. This way the system supports the role of the clinical pharmacy in the
prescription and drug workflow in hospitals.
Measure
 Numerator: Number of hospital beds for which all medication is prescribed
electronically.
56 / 83
CDC Projet final
 Denominator: Total number of hospital beds
5. Drug-drug interaction
The users legally authorized to judge drug-drug interactions and contraindications are prompted
as soon as possible by the system in the process of the drug distribution process. (e.g. for a
physician this means before completing the e-prescription. For the pharmacist before preparing
or delivering the medication).
Those alerts can be customized to specific medical specialties. Moreover the user must have the
possibility to overrule these warnings specifying the reason for overruling.
Step 1 Interaction checking includes:
 Therapeutic duplication “deduplication”: Medication with therapeutic overlap with

another new or active order; may be same drug, within drug class, or involve
components of combination products
 Min-max dose ranges : Medication with a specified dose that exceeds recommended
dose ranges or that will result in a cumulative dose that exceeds recommended
ranges
For later steps this needs to be expanded to more complex interaction checking with non-
medicational data (e.g. allergies, pregnancy, diagnoses, lab-results,...).
Local drug databases / formularies should be SNOMED CT-annotated in order to be compliant

between institutions and professionals. The use of subsets of the national reference drug
databases will guarantee interoperability. To guarantee uniformity in the implementation (and
thus uniformity of care for the patients) national databases for each of the types of interactions
should be made available.
Although the task force added this to the Step 1 criteria, the timing for reaching this goal is
relative to the availability of the databases driving this functionality. We propose at least two
years (one year for technical development and one year for implementation) between the final
delivery of the data base and the requirement to implement the corresponding interaction
(assuming that the design and specification of the database is supplied beforehand). This means
not only the availability of the SAM (Structured Authentic Medication) database (or an
alternative) and interactions defined using the keys used in this database.
The criterium is met if the hospital has implemented the check in its medication prescription
system and uses the interaction database as supplied by the government.
6. Medication administration (linked to e-prescription)
The electronic medication administration record (eMAR) supports the medication management
in the electronic medical record. Although less literature on eMAR has been published, the use of
eMAR has the potential to decrease the incidence of medication errors. The benefits are evident
57 / 83
CDC Projet final
for eMAR systems alone and in combination with CPOE. The use of eMAR in conjunction with
barcode scanning technology may even further increase patient safety.
Minimal system requirements
 The system requires personal login before any medication administration can be
documented
 The system logs the medication administration process. A complete audit trail of any
medication administration is possible.
 The eMAR provides an overview of all medication administrations in a timeline. This
includes all past and future medication administrations as well as the medication
orders that are not executed (delays/omissions).
 The system favors immediate documentation of order fulfillment i.e. drug
administration (opposite to retrospective documentation)
 The user has the possibility to document any information (preferably structured)
during the execution (or the non-execution) of a medication order.
 Any medication administration after an oral order generates a request for retroactive
approval addressed to the ordering physician.
 The system displays always the name of the drug as depicted in the medication
order. In case of medication substitution by the pharmacist, both drug names are
displayed/accessible in order to avoid misunderstanding.
 The user has during the medication administration process access to relevant drug
information (e.g. drug references)
Measure
 Numerator: Number of hospital beds for which electronic medication administration

is implemented.
 Denominator: Total number of hospital beds
7. Discharge letter
Prepared at discharge, documented in the patient’s record and contains at least the items
required by the Royal Decree of 3 May 1999 Art. 3 §3
The history of each letter is easily available (date/time of creation, validation, including an
overview to whom it has been sent and by which means).
The validated discharge letter is electronically available.
In Step 4 the electronic discharge letter should contain structured data.
Measure
 Numerator: number of electronically available discharge letters
 Denominator: number of discharged patients (patients with specific pathology that need
recurring treatment excluded)
8. Informed consent registration
58 / 83
CDC Projet final
The EPR supports the registration of a list of procedures and treatments for which consent must
be obtained, including who must obtain consent and how it has to be obtained (verbally, by
signing a consent form or through any other means).
Patients participate in the care process by making decisions about proposed care and treatment
and by accepting or refusing diagnostic procedures and treatments. After a patient has been well
informed, he is in the position to grant informed consent. Informed consent may be obtained
and registered at several points in the care process e.g.: general consent for treatment for an
inpatient, surgery, anesthesia, use of blood and blood products, dialysis, chemotherapy,
procedural sedation, abortion, other high risk treatments and procedures, … The EPR supports
the registration of the informed consent (or its refusal).
Specific for the Belgian situation, the EPR supports the registration of the patient consent that
authorizes the collection, use and disclosure of health information for providers giving birth to
the therapeutic relationship (patient – provider) in the context of the eHealth platform (see also
the Health- MetaHub, Hub project).
Measure
 Numerator: number of electronically registered obtained consents
 Denominator: number of treatments that require an informed, according to the policy of
the hospital.
9. Therapy limitation code or advance directives
The patient’s autonomy is respected. The patient has the right to refuse or choose his treatment.
Patient guidelines (advance directives) and provider therapy limiting instructions or DNR (Do Not
Resuscitate) orders are registered with necessary corresponding data such as date and time, HC
actor who registered this directive and possibly references to paper written documents.
Measure
 Numerator: Number of registered therapy limitation codes
 Denominator: Number of therapy limitations codes that should be registered, according
to the policy in the hospital
10. Automated communication with HUB’s and interaction with eHealth
The following eHealth-services must used by hospitals:

 eHealthBox
 consultation of health records (other institutions, SUMEHR, medication scheme) through
hubs by healthcare providers in the institution
 sharing of the electronic health records of patients to other hcp
 use of healthdata.be for participation in registries
 status of the informed consent in the patient administration software at registration desks of
hospital and of consultation departments (if patient does not need to perform central
registration); this status must be retrieved on-line from either a hub or the national database
 integration of services of NIHII, NIC/CIN, National Register in processes of the institution
(Chapter IV, Insurability, eBirth, Mediprima, …)
Measure
59 / 83
CDC Projet final
 Numerator: The number of unique patients in the denominator that have the listed
registered items/information available on the eHealthservices in the EHR reporting period of
the denominator.
 Denominator: the number of unique patients in inpatient, one day care or emergency setting
in a given EHR reporting period (to be defined).
 Important remark: The target date to reach this goal is relative to the availability of the
release of the technical description of a new item or register. We take into account one year
for development and getting into production.
 A task force will decide on how to proceed further for the measurement of each item.
11. Multidisciplinary registration and exchange of information.
% Of patients for whom all care providers ( intramuros ) record care data in the EHR and share
relevant information with other providers within and outside their discipline. It includes at least
the nursing record.
Measure
Numerator: Number of patients with at least 2 disciplinary registrations.
Denominator: Total Number of hospitalized patients
Measurement on one specific date
12. Control of the interdisciplinary treatment plan and of the tasks of each discipline via the EHR
In the EHR is an interdisciplinary treatment plan available and it includes the tasks of each
discipline.
Incl. equipped syntheses by the various disciplines in preparation for the interdisciplinary patient
consultation and , determining and assigning of actions.
Measure
Numerator: Total Number of hospitalized patients with an interdisciplinary treatment plan

Denomiator: Total Number of hospitalized patients
Measurement on one specific date
13. Segregations
Registration of segregations (cfr legal register) in EHR.
Measure
Numerator:Number of segregations recorded in the EHR.
60 / 83
CDC Projet final
Denomiator: Total Number of segregations recorded (in the EHR + in physical register)
14. Registration observations
Ability to record daily observations. These can serve as a basis for further processing of synthesis,
treatment plans , and can be used for transfers between health care providers.
Measure
Numerator:Number of hospitalized patients with registered observations.
Denomiator: Total Number of hospitalized patients
15. Support for integrating results ( protocols) of internal requested but external executed studies.
The availability of information regarding the internal requested but external executed studies in
the EHR as part of the EHR.
Measure
Numerator: Integrated results for internal requested but external executed studies.
Denominator: Total Patients with an internal requested but external executed studies.
61 / 83
CDC Projet final
ANNEXE 4
Processus Actuels et processus Futurs
A titre illustratif, une notion de nos processus actuels et de nos processus futurs a été consignée dans ce
document.
Les analyses réalisées en interne décrites dans cette annexe vont permettre au soumissionnaire de prendre
connaissance des besoins et des attentes de l’adjudicateur mais cela ne le dispense, en aucune manière, de
procéder à sa propre analyse fonctionnelle qui fait partie intégrante de ce présent marché.
Les processus seront donc réalisés sur base de ce qui aura été convenu au terme de la phase d’analyse.
Les abréviations « RI » suivies de n° correspondent aux champs détaillées à l’annexe 2 « Structure générale
du DPI »
Exemple RI 1.2 = Annexe 2 / Tableau 1 « Données administratives »/Champ 2 « Nom »
62 / 83
CDC Projet final
2.7 Lettres et rapports d’entrée et de sortie
Objectifs :
 Faciliter la génération des lettres et des rapports d’entrée et de sortie et garder une trace des envois
Description :
 Générer automatiquement la lettre d’entrée

 Générer automatiquement la lettre et le rapport de sortie
 Validation par le médecin
 Impression ou transmission électronique via eHealthBox
 Conservation de l’historique des lettres et rapports ainsi que la trace de leurs envois
63 / 83
CDC Projet final
Lettre d'entrée
Lettre type à remplir avec les valeurs du DPI
Votre patient <Nom, RI 1.2>, <Prénom, RI 1.3>, né le <date de naissance, RI 1.7>, est entré le <date d'entrée, RI 12.1> au Centre Ados.
Ses personnes de référence seront :
- son psychiatre : <nom> <prénom> (rubr12.5)
- son référent : <nom> <prénom> (rubr12.2)
- son référent pédagogique : <nom> <prénom> (rubr 12.4)
Salutations, …
Nom du médecin (login)
Lettre de sortie
Votre patient <Nom, RI 1.2>, <Prénom, RI 1.3>, né le <date de naissance, RI 1.7>, est sorti le <date de sortie, RI 12.1> du Centre Ados.
Un rapport de séjour vous parviendra sous peu
Salutations, …
Nom du médecin (login)
Rapport de sortie
Concerne :
<Nom, RI 1.2 > < Prénom, RI 1.3 >
Né le <date de naissance, RI 1.7 >
Séjour au CENTRE ADOS
Centre de Jour pour Adolescents de l'ASBL L'Equipe
du <date d'entrée, RI 12.1 > au <date de sortie, RI 12.1 >
1. Motifs et circonstances de l'admission

Adressé au Centre Ados à l'âge de <calcul de l'âge à partir de la date de naissance, RI 1.7 et de la date d'entrée RI, 12.1 >
par < Nom, Prénom, RI 15.1b >
2. Antécédents psychologiques et psychiatriques personnels

<RI 9.1>
3. Antécédents psychiatriques familiaux

<RI 9.4>
4. Antécédents médicaux
5. Situation et dynamique familiales
6. Parcours scolaire
<RI 4.3>
7. Mesures d'Aide à la jeunesse, mesures judiciaires ou protectionnelles
8. Déroulement du séjour et observations

<RI 18b.4>
9. Ateliers pédagogiques (en partenariat avec l'Ecole à l'Hôpital Robert Dubois)

<RI 19.4>
10. Evolution au cours des entretiens psychologiques et analyses psychopathologiques

<RI 16.5>
11. Traitement psychotrope

A l'entrée
Pendant le séjour
A la sortie
12. Hypothèses diagnostiques :
13. Modalités de sortie et dispositions à la sortie
19
19
Les abréviations « RI » suivies de n° correspondent aux champs détaillées à l’annexe 2 « Structure générale du DPI »
Exemple RI 1.2 = Annexe 2 / Tableau 1 « Données administratives »/Champ 2 « Nom »
64 / 83
CDC Projet final
Module
Lettre de sortie / rapport de séjour
Le médecin se positionne dans le dossier patient concerné

RI 15
non
Lettre/ Rapport Génération de la
déjà généré ? lettre/rapport
oui
Génération d’un
Consultation du Infos toutes Message avec
nouveau rapport/
rapport/lettre disponibles ? champs manquants
lettre
Visualisation de la oui
Visualisation
lettre/rapport sous
forcée ?
format word
non
Modifications
manuelles possibles
non
Validation ?
oui
Document
non sauvegardé sous
Envoi médecin
format PDF sous un
destinataire ?
n° généré
automatiquement
oui
Récolte des données
mode de communication : courrier, mail,
autre (préciser)
Destinataire : nom(oblig), prénom,
adresse postale, email, fax
Staockage des données de l’envoi dans

RI15
Génération d’un
Ouverture de
courrier avec nom
ehealthbox si choix
et adresse si choix
d’envoi par email
d’envoi par courrier
Impression possible
Sortie
65 / 83
CDC Projet final
2.14 Enregistrement des observations
2.14.1 Prise de notes journalières
Objectifs :
 Prise de notes rapide de manière journalière

 Accéder facilement aux informations nécessaires
Description :
 Lors d’événement en atelier ou autre, le soignant ou secrétaire peut inscrire une note pour consigner
l’information. Cette note est enregistrée et horodatée.
 Si la note concerne un ou plusieurs patients, cette note doit s’intégrer aux données du ou des patients
concernés
 La note ne peut être modifiée que par le rédacteur de la note
 La note peut être amendée par un autre travailleur
 L’historique de la note et de ses amendements doit apparaitre clairement
 Les travailleurs peuvent consulter les notes soit
o Directement via le dossier du patient
o Par date, entre deux dates
o Par rédacteur
66 / 83
CDC Projet final
Module
Consult/Prise de notes journalières
Carnet de Bord/ Atelier
Doit ouvrir un formulaire spécifique
Consultation/modification de notes, choix secondaire Rédaction d’une nouvelle note, choix par défaut
Choix non obligatoire du type de notes consultables

- carnet de bord
- Carnet de Bord
- Atelier
- Atelier
L’utilisateur peut choisir le ou les patients concernés

Classement des notes par ordre chronologique décroissant
sinon note générale d’information
Recherche possible via un moteur de recherche (nom du patient, date ou entre 2

La date du jour s’inscrit automatiquement.
dates, nom du rédacteur)
L’utilisateur veut
L’utilisateur veut L’utilisateur consulte
amender une note d’un
modifier une note simplement la note Le type s’inscrit automatiquement
commentaire
(CDB, atelier)
Un cadre de prise de notes en direct
est accessible
Vérification de ses
droits, l’utilisateur ne
peut modifier que ses
propres notes La date du jour s’inscrit
automatiquement
Une référence au commentaire
Le travailleur confirme l’enregistrement des notes
s’inscrit automatiquement
Un cadre de prise de notes en direct
Traçage de la est accessible
modification
Si amendement : la note est sauvegardée sous une forme qui permet

Si note originale : enregistrement
d’identifier l’historique depuis la note originale jusqu’au dernier
Si patient concerné : Les notes sont aussi automatiquement
amendement
sauvegardées dans le dossier patient dans le RI 13.
Si patient concerné : Les notes sont aussi automatiquement
La date encodée est sauvegardée également.
sauvegardées dans le dossier patient dans le RI 13
Chaque note est horodatée et l’encodeur est identifié
La date est sauvegardée également.
Chaque note est horodatée et l’encodeur est identifié
Impression possible
Sortie
67 / 83
CDC Projet final
2.14.2 Prise de notes en réunion de staff et mise à disposition du PV
Objectifs :
 Prendre des notes facilement et rapidement lors des réunions de staff

 Accéder facilement aux informations après les réunions
Disposer d’une solution permettant de lister les patients ayant droit au code de concertation
pluridisciplinaire.
Ce code peut être facturé à un patient de moins de 18 ans si
son cas est discuté lors d’une réunion entre soignants et s’il y
a au moins 1 médecin, 1 psychologue, 1 infirmier ou
éducateur et 1 assistant social ou enseignant présents.
Description :
 Lors d’un staff, un travailleur prend note des discussions

 Si la discussion concerne un patient, il le signifie et l’information sera consignée dans son dossier
 Possibilité d’encoder les travailleurs présents pour qu’une liste des codes de concertation puisse être
générée.
 Un PV de la réunion est disponible après encodage
 Les PV peuvent être visualisés et/ou imprimés (vérification des droits)
Module
Réunion de Satff
Doit ouvrir un formulaire spécifique aux réunions de staff
Consultation du PV d’une réunion Choix utilisateur Prise de notes lors de la réunion
Affichage de la liste des réunions de staff Concertations pluridisciplinaires

Encodage de la date
Classement par ordre chronologique décroissant Vérification des droits : uniquement fonction de Sec, Co ou Me
Visualisation du PV Choix parmi les dates de réunion disponibles Encodage des travailleurs participants si nécessaire
Si l’encodage des travailleurs participants est fait Encodage du ou des noms des patients concernés si nécessaire
Test de vérification des fonctions des travailleurs présents Encodage d’un titre particulier si nécessaire parmi une liste de
choix (ex : synthèse trimestrielle)
Visualisation des concertations possibles avec cases CP cochées

automatiquement à la première consultation Encodage de la discussion
Décochage possible manuellement Les notes vont s’insérer automatiquement dans la rubrique du DPI
Mise en mémoire des sélections/déselections concerné si encodage patient sinon figure uniquement au PV de la
Validation par le rôle Me réunion
non
Visualisation de la liste des patients concernés
Fin de réunion ?
+ liste des patients en séjour à cette date mais absents de la liste
oui
Le PV de la réunion est disponible soit via ce USE CASE soit via le

Impression possible
USE CASE Réunion si la réunion a été planifiée auparavant
Un message apparaît dans le Carnet de Bord « PV Staff <date>,

disponible> + lien vers la lecture du PV
68 / 83
Sortie
CDC Projet final
2.14.3 Prise de notes lors des entretiens
Objectifs :
 Lors d’un entretien avec le patient, le travailleur prend des notes facilement et rapidement.
Description :
 Lors d’entretiens psychologiques, psychiatriques ou autres, le soignant peut prendre des notes
 Les notes d’entretien sont consignées dans le dossier du patient dans la partie adéquate (psychologie,
psychiatrie, assistant social, référent pédagogique, référent)
 Ces notes sont modifiables uniquement par le rédacteur
 Ces notes sont consultables par l’ensemble des soignants (cfr droits des utilisateurs). Elles sont triées
chronologiquement de manière décroissante.
 Le soignant a la possibilité de prendre des notes dites « notes privées » visualisables uniquement par
lui-même. Les notes de ce type doivent être supprimées lors du départ du travailleur de l’ASBL.
69 / 83
CDC Projet final
4.1 Encodage des jours de présences par mois
Objectifs :
 Disposer des présences et absences avec justification des patients

 Générer des statistiques
Description :
 Générer automatiquement un tableau de présences par mois calendrier.

 Pour les structures de jour, les jours de week-end et les fériés sont inactifs
 Indiquer manuellement chaque jour la présence ou l’absence (différents codes possibles) du patient
 Sur chaque case, un commentaire peut être ajouté
 Répercussion automatique des absences dans l’agenda du patient (cfr 4.5)
 Calcul automatique de statistiques
A titre d’exemple, voici un modèle de calendrier que nous utilisons actuellement

dimanche 10 juillet 2016

mercredi 13 juillet 2016

vendredi 15 juillet 2016


samedi 16 juillet 2016

mardi 12 juillet 2016

lundi 11 juillet 2016
jeudi 14 juillet 2016

Nom Prénom
juil-16
Sa A 1 / / / / / / / / / / / / / / / / / / / 1
JA B 1 1 1 1 1 Df Df Df Df Df Df Df Df Df Df Df 1 Df Df Df 6
Va C S S S S S S S S S S S S S S S S S S S S 0
Bo D 0 Df Df Df Df Df Df Df Df Df Df Df Df Df Df Df Df Df Df Df 0
Va E 1 0 1 1 1 0 0 1 1 1 1 1 1 1 1 0 0 1 1 1 15
Ve F 1 1 1 1 1 1 Df Df Df Df Df Hi Hi Hi Hi Hi Hi Hi Hi Hi 6
Ko G Ex Df 1 Df 1 Df 1 1 1 1 Df 0 0 0 0 Df Df Df Df Df 6
Bf H 0 1 1 1 1 0 1 1 1 0 1 Df Df Df Df Df Df Df Df Df 8
Dw I 1 Df Df Df Df Df 1 0 0 0 0 0 0 0 / / / / / / 2
Du J 0 0 0 0 0 0 0 0 / / / / / / / / / / / / 0
Ba K 1 1 1 1 1 1 1 1 Df Df Df Df Df Df Df Df Df Df Df Df 8
Da L 0 1 1 Ex 1 1 1 1 1 1 1 1 1 1 1 Df Df Df Df Df 13
Ki M 0 1 1 0 1 1 0 M 1 1 1 1 1 0 1 1 Hi Hi Hi Hi 11
Ka N 0 Df Df Df Df Df Df Df Df Df Df Df Df Df Df Df Df Df Df Df 0
Br O 1 1 1 1 1 M 1 1 1 1 1 1 1 1 1 Df Df Df Df Df 14
H P 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 19
Ma Q Df Df Df 1 1 1 Df Df Df Df Df 1 Ex 1 1 1 1 1 1 Ex 10
Mu R 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Df Df Df Df Df Df 14
Mv S / 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 18
Je T / / / / 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 16
Van U / / / / / / / / / / / / / / / 1 1 1 1 1 5
W V / / / / / / / / / / / / / / / 1 1 1 1 1 5
Présents 9 10 12 10 14 9 10 10 10 9 9 9 8 8 0 8 5 7 7 7 6 177
Inscrits 17 17 17 17 18 18 18 18 17 17 17 16 16 16 0 15 17 16 16 16 16
-5 -4 -2 -4 0 -5 -4 -4 -4 -5 -5 -5 -6 -6 -14 -6 -9 -7 -7 -7 -8
70 / 83
CDC Projet final
Les codes que nous utilisons actuellement sont les suivants :
Codes de présence 1 présent

= compter pour 1 dans les statistiques de présences 1 Entrée - premier jour où attendu
1 Sortie - dernier jour où attendu
Codes d'absence 0 absent

= Compter pour 0 dans les statistiques de présences / pas inscrit
M malade sous certificat
0 absent pour "maladie"
RD Robert Dubois
Ex Excusé
V Mise au vert avant 14h
1 Mise au vert après 14h
R Mise au rouge
Pa temps partiel
Df dispense de fréquentation
S Suspension de prise en charge
Se Sortie à l'essai
attendu(e) seulement l'après-midi
attendu(e) seulement le matin
P Présent sans facturation
Hi Hospitalisation intercurrente pour motif somatique
Hi Hospitalisation intercurrente pour motif psychiatrique
m eo Hospitalisation pour mise en observation
Pour les codes Hi en orange ou en gris, le nom de l’hôpital doit être stocké.
Les statistiques suivantes sont calculées :
Statistiques globales :
 Nombre d’inscrits/mois/année
 Nombre de présents/mois/année
 Nombre de codes d’absences pour chaque code/mois/année
 Nombre de codes d’absences tous codes confondus /mois/année
Statistiques individuelles :
 Nombre de jours de présence/patient/mois/année
 Nombre de codes d’absence pour chaque code /patient/mois/année
 Nombre de codes d’absences tous codes confondus /mois/année
 Listing des Hi/patient avec le nom de l’hôpital
71 / 83
CDC Projet final
Module Calendrier
Affiche automatiquemet le mois en cours (+ création si pas encore créé)

Met en évidence le jour en cours
Les patients sont affichés sauf date de sortie < mois affiché
Les patients avec statut « mercredi » sont classés en début de tableau et se distinguent des autres
Possibilité d’afficher
Possibilité d’afficher
un autre mois, à
des statistiques
choisir
Encodage des présences ou

absences selon les codes
spécifiques
Vérification cohérence avec

les dates entrées et sorties
Recalcul des statistiques
Impression ou
exportation Excel
possible
Sortie
72 / 83
CDC Projet final
4.4 Calendrier des activités hebdomadaires
Objectifs :
 Disposer d’un calendrier reprenant toutes les activités prévues dans la semaine
Description :
 Le travailleur dispose d’un calendrier de même genre que celui proposé par Outlook dans lequel il
encode les activités prévues soit
o À une date précise
o Tous les mêmes jours de semaine de « date » à « date »
o 1 x par mois
o autre
Avec les informations suivantes
o Le nom de l’activité
o La plage horaire
o Le ou les travailleurs concernés
 Tous les travailleurs peuvent consulter ou modifier ce calendrier
 Possibilité d’inscrire un ou plusieurs patients à cette activité avec répétition possible
 Répercussion des informations dans les agendas patients et travailleurs (cfr 4.5 et 4.6)

20
Ce calendrier est imprimable
Module
Calendrier hebdomadaire
L’utilisateur visualise le calendrier avec les infos déjà encodées pour la semaine en
cours
Choix de
l’utilisateur
Modifier ou supprimer une activité déjà Encodage de patients à une activité déjà
Définir une nouvelle activité encodée: encodée
- modifier juste cette occurrence Possibilité de répéter l’inscription à cet
- modifier toutes les occurences atelier de <date> à <date>
Possibilité d’y attribuer 1 ou plusieurs

travailleurs
L’info apparaîtra dans le USE CASE « Agenda Message d’information si superposage
du travailleur » d’horaire pour le patient
Message d’information si superposage
d’horaire travailleur
Possibilité d’inscrire l’activité à

- 1 seule date L’info est sauvegardée dans le dossier
- tous les mêmes jours de chaque semaine patient RI12 et apparaîtra dans le Use
- toutes les mêmes dates du mois CASE « Agenda du patient »
Impression possible de la semaine ou du

mois
Sortie
20
Les abréviations « RI » suivies de n° correspondent aux champs détaillées à l’annexe 2 « Structure générale du DPI »
Exemple RI 12= Annexe 2 / Tableau 12 « Données Séjour patient »
73 / 83
CDC Projet final
4.5 Agenda du patient
Objectifs :
 Disposer d’un agenda reprenant tous les rendez-vous et les absences du patient
Description :
 Le travailleur dispose d’un calendrier de même genre que celui proposé par Outlook
 Ce calendrier reprend automatiquement
o les absences encodées via le point 4.1 « Encodage des jours de présences par mois »
o les activités auxquels il a été inscrit via le point 4.4 « calendrier des activités hebdomadaires »
o les rendez-vous auxquels il est convié via le point 4.6 « agenda du travailleur »
 Le travailleur peut encoder directement dans cet agenda
o Un rendez-vous prévu à l’extérieur du centre avec des commentaires
o Une activité au centre avec proposition d’activités encodées via le point 4.4 « calendrier des
activités hebdomadaires »
o Un rendez-vous avec un soignant du centre. Ce rendez-vous se répercutera dans l’agenda du
travailleur concerné. Un message d’information préviendra s’il y a superposition d’horaire
pour ce travailleur.
 Tous les travailleurs peuvent consulter ou modifier ce calendrier
 Ce calendrier est imprimable
Module
Agenda du patient
L’utilisateur choisit le patient concerné
Ouverture d’un formulaire spécifique sous forme d’agenda hebdomadaire du patient,

affichage automatique de la semaine actuelle
non L’utilisateur choisit

Semaine
désirée ? la semaine voulue
oui
La semaine s’affiche avec les rdv déjà prévus et les jours d’absence déjà encodés via
USE CASE « Module Calendrier »
Le travailleur se positionne sur le jour de son choix
Le travailleur choisit le type de rdv (parmi les propositions ou nv type de rdv) et

encode les données (heures + remarque)
Si rdv = ateliers, alors choix parmi les ateliers prévus ce jour là dans le calendrier
hebdomadaire
Un message d’information s’affiche en cas de superposition d’horaires
Sortie 74 / 83
CDC Projet final
4.6 Agenda du travailleur
Objectifs :
 Disposer d’un agenda reprenant tous les rendez-vous et les indisponibilités des travailleurs
Description :
 Le travailleur dispose d’un calendrier de même genre que celui proposé par Outlook
 Les travailleurs peuvent visualiser les agendas des autres travailleurs et y proposer des invitations
 Ce calendrier reprend automatiquement
o les activités auxquels il participe via le point 4.4 « calendrier des activités hebdomadaires »
o les rendez-vous auxquels il a été invité via le point 4.6 « agenda du travailleur »
 Le travailleur peut encoder directement dans son agenda
o Ses propres rendez-vous avec des patients (répercussion dans l’agenda du patient point 4.5)
o Ses réunions ou autres
o Ses indisponibilités, congés, etc …
o Une réunion avec d’autres travailleurs (invitations aux autres travailleurs)
 Le calendrier est imprimable
75 / 83
CDC Projet final
Module
Agenda du
travailleur
Ouverture d’un formulaire spécifique sous forme

Possibilité d’afficher l’agenda d’un autre
d’agenda hebdomadaire selon le login connecté,
travailleur
affichage automatique de la semaine actuelle
non Possibilité de proposer un nv rdv dans

Semaine L’utilisateur choisit
l’agenda de l’autre travailleur avec
désirée ? la semaine voulue
message à l’autre travailleur
oui
L’autre travailleur peut accepter ou

La semaine s’affiche avec les rdv déjà prévus refuser avec message à l’initiateur du rdv
Le travailleur se positionne sur le jour de son choix
Rdv patient ou
rdv perso ou
réunion
Le travailleur indique un rdv ou

Le travailleur choisit l’heure et le(s)
une indisponibilité (autre Créer une réunion
patient(s) concerné(s)
couleur)
Un message d’information non

Possibilité d’inviter d’autres
bloquant indique si superposage
travailleurs
d’horaire chez le patient
Message d’info si superposage

L’info se répercute chez le patient et
d’horaire chez un travailleur
apparaît via le Use Case « Agenda du
Message d’info aux autres
patient »
travailleurs concernés
Les autres travailleurs peuvent

Impression possible accepter ou refuser avec
message à l’initiateur du rdv
Sortie
76 / 83
CDC Projet final
5.1 Module de consultation
Objectifs :
 Disposer d’un outil permettant de conserver les informations reçues en consultation pour un patient
 Préparation des courriers aux mutuelles récapitulant l’ensemble des consultations par trimestre et le
prix total à nous verser.
 Possibilité de gérer les rdv des patients déjà connus ou pas, lien avec l’agenda du travailleur
Description :
 Le soignant donne un rendez-vous à un patient. Ce patient n’est pas forcément connu de l’application
 Le rendez-vous apparaît dans l’agenda du travailleur
 Le soignant reçoit le patient en consultation
 Le soignant crée un dossier reprenant les informations administratives de base
 Le soignant prend note de l’entretien et du suivi
 Le soignant spécifie le n° de nomenclature adéquat pour la consultation (uniquement nomenclatures
psychiatriques)
 En fin de trimestre, génération automatique d’un courrier par mutuelle avec le récapitulatif des
consultations et calcul de la somme des prix des nomenclatures.
 Statistiques des venues des patients, annulation des rendez-vous, pas venu, …
77 / 83
CDC Projet final
ANNEXE 5
Structure de l'offre
78 / 83
CDC Projet final
A. Volet Administratif
A.1. Déclaration sur l’honneur relative aux critères d’exclusion

Le, la soussigné(e) …………………………………………………………..
Agissant en son nom propre (dans le cas d’une personne physique)

Ou
Agissant en qualité de représentant de la personne morale suivante :
Dénomination officielle complète :……………………………………………………..
Forme juridique officielle :………………………………………………………………….
Adresse officielle complète :………………………………………………………………
N° d’immatriculation à la TVA :………………………………………………………..
Déclare qu’aucun des critères d’exclusion repris à l’article 61 de l’AR de passation de marché du 15 juillet 2011
ne lui est applicable.
Article 61 de l’AR de passation de marché

er
§1 . Conformément à l’article 20 de la loi, est exclu de l’accès au marché, à quelque stade que ce soit de la
procédure, le candidat ou le soumissionnaire qui a fait l’objet d’une condamnation prononcée par une décision
judiciaire ayant force de chose jugée dont le pouvoir adjudicateur a connaissance pour:
1° participation à une organisation criminelle telle que définie à l’article 324bis du Code pénal;
2° corruption, telle que définie à l’article 246 du Code pénal;
er
3° fraude au sens de l’article 1 de la convention relative à la protection des intérêts financiers des
communautés européennes, approuvée par la loi du 17 février 2002;
4° blanchiment de capitaux tel que défini à l’article 3 de la loi du 11 janvier 1993 relative à la prévention de
l’utilisation du système financier aux fins du blanchiment de capitaux et du financement du terrorisme.
En vue de l’application du présent paragraphe, le pouvoir adjudicateur demande aux candidats ou

soumissionnaires de fournir les renseignements ou documents nécessaires. Lorsqu’il a des doutes sur la
situation personnelle de ces candidats ou soumissionnaires, il peut s’adresser aux autorités compétentes
belges ou étrangères pour obtenir les informations qu’il estime nécessaires à ce propos.
Le pouvoir adjudicateur peut déroger à l’obligation visée au présent paragraphe pour des exigences
impératives d’intérêt général.
§2. Conformément à l’article 20 de la loi, peut être exclu de l’accès au marché, à quelque stade que ce soit de la
procédure le candidat ou le soumissionnaire:
1° qui est en état de faillite, de liquidation, de cessation d’activités, de réorganisation judiciaire ou dans toute
situation analogue résultant d’une procédure de même nature existant dans d’autres réglementations
nationales;
2° qui a fait l’aveu de sa faillite ou fait l’objet d’une procédure de liquidation, de réorganisation judiciaire ou de
toute autre procédure de même nature existant dans d’autres réglementations nationales;
3° qui a fait l’objet d’une condamnation prononcée par une décision judiciaire ayant force de chose jugée pour
tout délit affectant sa moralité professionnelle;
4° qui, en matière professionnelle, a commis une faute grave;
5° qui n’est pas en règle avec ses obligations relatives au paiement de ses cotisations de sécurité sociale
conformément aux dispositions de l’article 62;
6° qui n’est pas en règle avec ses obligations relatives au paiement de ses impôts et taxes selon la législation
belge ou celle du pays dans lequel il est établi, conformément aux dispositions de l’article 63;
79 / 83
CDC Projet final
7° qui s’est rendu gravement coupable de fausses déclarations en fournissant des renseignements exigibles en
application du présent chapitre ou qui n’a pas fourni ces renseignements.
Nom, Prénom Date Signature
A.2. Sélection qualitative
A.2.1. Capacité financière et économique

 Chiffre d’affaire réalisé dans le secteur de l’ingénierie informatique au cours des trois dernières
années
Et/ou

21
Evaluation documentée du chiffre d’affaire « théorique » au cours des trois dernières années
A.2.2. Capacité technique ou professionnelle du soumissionnaire

Documents à annexer :
 Une description technique de l'entreprise et de ses sous-traitants, du personnel et des moyens mis en
œuvre qui permettent à l’ASBL L’Equipe d'évaluer la manière dont l'entreprise peut garantir
l'exécution du marché ;
 Les référence, c'est-à-dire la liste des institutions dans lesquelles le soumissionnaire et/ou ses sous-
traitants ont fourni, mis en place et mis en service des systèmes informatiques au cours des 3
dernières années (montants, dates de début et de fin de projet, résumé du périmètre du marché, les
destinataires avec le téléphone ou e-mail d'une personne de contact pour chaque référence) ;
 L'engagement stratégique du soumissionnaire et de ses sous-traitants dans le secteur hospitalier
psychiatrique et sa politique d'évolution logicielle ;
 Capacité de maintenance : le soumissionnaire joint également à son offre les pièces attestant que la
maintenance fait partie de ses activités ou de celles de ses sous-traitants;
 Les CV des membres de son personnel et du personnel de ses sous-traitants qui seront affectés au
présent marché.
21
Par exemple, le cas d’un employé qui aura développé pour son employeur une solution
informatique. Il s’agit d’une plus-value apportée à son employeur dont le soumissionnaire évaluera
l’importance financière.
80 / 83
CDC Projet final
B. Volet Technique
B.1. Planning
Calendrier d’exécution des services et fournitures, exprimé en temps relatif par rapport à la date de conclusion
du marché.
22
Le planning sera détaillé selon le phasage choisi par le soumissionnaire. Pour chaque phase, il lui est demandé
de détailler la période de développement, de test, de livraison et de mise en production.
B.2. Personnel de L’Equipe

Pour les différentes phases et pour les différentes tâches, le soumissionnaire détaillera le nombre de jours de
travail à fournir par le personnel de l’ASBL L’Equipe.
B.3. Solution proposée

Détail de la solution proposée reprenant l’ensemble des fonctionnalités.
 La présence des fonctionnalités demandées dans une version déjà existante du logiciel. Le
soumissionnaire veillera à joindre à l’offre en annexe (point C) des éléments pertinents démontrant le
fonctionnement et la couverture de l’application (version démo, copies d’écran, …);
 La possibilité de développement des fonctionnalités manquantes ;
 Les possibilités de paramétrage et les paramètres offerts par défauts prévus ;
 Une idée de la conception de l'interface utilisateur : ergonomie et facilité d'utilisation ;
 L'aspect technique de la solution
o La conception logicielle ;
23
o L'environnement informatique ;
o L'intégration avec le logiciel gérant la facturation et les médicaments (Logal) ;
o L'ouverture vers d'autres logiciels hospitaliers (non couverts par le présent appel d'offres);
Correspondance avec le point 2.3.2.4 du présent cahier des charges.
1. Fonctionnalités indispensables (Phase 1)

1.1. Traçage et horodatage
1.2. Accès, méthode de gestion des droits
2. Fonctionnalités légales (BMUC)(Phase 1)
2.1. Création d’un patient.
Prévision d’une interface avec l’application Evolutive Compta de Logal
2.2. Liste des diagnostics
2.3. Liste des allergies
Prévision d’une interface avec l’application Evolutive Compta de Logal
2.4. E-prescription
2.5. Interactions médicamenteuses
2.6. Administration des médicaments
2.7. Lettre et rapport de sortie
2.8. Enregistrement de consentements éclairés
2.9. Limitations thérapeutiques
2.10. Communication avec les Hub’s et interaction avec e-health
2.11. Enregistrement multidisciplinaire et échange d’informations
22
Cfr point 2.3.2.4
23
Prescriptions du prestataire : matériels (serveurs, postes, réseau, …) et d'outils système (OS, SGDB, …).
81 / 83
CDC Projet final
2.12. Contrôle du plan de traitement interdisciplinaire accessible et des tâches de chaque discipline
2.13. Enregistrement des ségrégations
2.14. Enregistrement des observations
2.15. Support des résultats internes exécutés en externe
3. Fonctionnalités Equipe urgentes (phase 1)
3.1. Architecture du dossier
er
3.2. Formulaire et enregistrement 1 contact
3.3. Liste d’attente
3.4. Gestion du départ d’un travailleur
3.5. Impressions
4. Fonctionnalités Equipe importantes
4.1. Encodage des jours de présences par mois
4.2. Lettre d’entrée
4.3. Demande de traitement à un médecin extérieur
4.4. Calendrier des activités hebdomadaires
4.5. Agenda du patient
4.6. Agenda du travailleur
4.7. RPM
4.8. Statistiques
5. Fonctionnalités Equipe utiles
5.1. Module de consultation
5.2. Message à un ou plusieurs travailleurs
5.3. Mise en production pour toutes les structures de L’Equipe (cfr planning)
5.4. Choix des items
5.5. N° d’identification consultable
5.6. Passage d’une structure 1 à une structure 2
5.7. Agenda de réunions dans une structure
5.8. Agenda des réunions entre structures
5.9. Mise à disposition des PV de réunions
5.10. Archivage
B.4. Détails annexes

 La sécurité du stockage des données, l’éventuelle méthode de cryptage ainsi que les accords formels
pris avec les sous-traitants éventuels au niveau de l'échange de données ;
 La politique de qualité du code et les tests prévus ;
 La solution proposée de mode dégradé et tests correspondants ;
 En cas de force majeure, procédure de récupération des codes source et tests correspondants ;
 Politique d’adaptation aux demandes spécifiques du client.
B.5. Services à fournir

B.5.1. Gestion du projet
Détail des politiques de gestion du projet en ce qui concerne
 L’analyse ;
 Le développement ;
 Les tests ;
 La livraison ;
82 / 83
CDC Projet final
 L’implémentation.
B.5.2. Transfert de connaissance - formations

Détail de la politique de formation des
 Utilisateurs ;
 Gestionnaires internes ;
 Gestionnaire de système.
B.5.3. Assistance complémentaire

Détail de facturation d’heures d’assistance complémentaire.
B.5.4. Transférabilité
Détail de la procédure, en cas de rupture de contrat, pour permettre à l’ASBL L’Equipe la continuité de ses
activités.
Engagement du soumissionnaire à fournir les données en clair (non crypté) dans un format standard du
marché, à décrire dans l’offre .
B.5.5. Maintenance et support

Description de la politique de maintenance et support dans les trois cas : préventif, correctif et évolutif.
B.5.6. SLA
Tableau reprenant les points et les engagements de service minimum reprenant au moins les points suivants :
 Disponibilité du logiciel (hors maintenance) ;

 Couverture de maintenance ;
 Couverture d’assistance à l’utilisation du logiciel ;
 Traitements d’incidents ;
 Reportings.
B.6. Prix
Le prix sera détaillé par phase.
Les montants relatifs au développement et à la maintenance seront différenciés.
Si des variantes ou des options ont été évoqués, les différences en positif ou en négatif seront explicitées.
C. Volet "Annexes"
Dans ce volet, le soumissionnaire joint à son offre des documents qui permettent de clarifier son offre.
S'il existe déjà une version de base pour cette application, le soumissionnaire veillera à joindre des éléments
pertinents démontrant le fonctionnement et la couverture de l’application (version démo, copies d’écran, …).
83 / 83

CDC Projet Final-3

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

CDC Projet Final-3

Diunggah oleh

Hak Cipta:

Format Tersedia

Dossier Patient Informatisé – Cahier des charges

Dossier Patient Informatisé

le lundi 6 février 2017 à 10h00 précises

Personne de contact à l’ASBL L’Equipe : Mme Isabelle De Schutter.

1. CLAUSES ADMINISTRATIVES ET CONTRACTUELLES 5

2.1.2. PHASAGE DU PROJET 15

ANNEXE 1 ETAT ACTUEL DE L'INFRASTRUCTURE ET DU RESEAU LOCAL 31

ANNEXE 2 STRUCTURE GENERALE DU DPI 38

ANNEXE 3 BELGIAN MEANINGFUL USE CRITERIA FOR OTHER HOSPITALS 51

ANNEXE 4 PROCESSUS ACTUELS ET PROCESSUS FUTURS 62

ANNEXE 5 STRUCTURE DE L'OFFRE 78

1. CLAUSES ADMINISTRATIVES ET CONTRACTUELLES

1.1. Clauses administratives

La personne habilitée à veiller à la bonne exécution du marché est :

1.1.2. Objet du marché

Les variantes et options au cahier des charges sont acceptées.

1.1.3. Durée du marché

La durée du marché comprend deux parties :

 La durée d’analyse du projet, du développement du logiciel et de sa mise en œuvre.

 Suite à la réception définitive, la seconde partie du marché permettant d’assurer la maintenance

1.1.4. Conditions de passation du marché

1.1.5. Obtention du Cahier Spécial des Charges

Il est également téléchargeable via le site de l'ASBL L'Equipe : www.equipe.be

1.1.6. Questions relatives à l'appel d'offres

1.1.7. Modalités de présentation des offres

1. avoir eu la possibilité de se rendre compte de l’importance et de toutes les particularités de

1.1.8. Dépôt et ouverture des offres

Les offres pourront soit :

1.1.9. Durée de validité des offres

Le prix doit être détaillé en deux parties principales et leurs sous-parties :

 Les montants relatifs à la maintenance durant 5 ans après la réception définitive.

1.2. Clauses contractuelles

1.2.2.2. Sélection qualitative

1.2.3. Article 101 de l’AR Passation du 15 juillet 2011 : Critères d’attribution

 la méthodologie des services d'implémentation ;

 La couverture de transférabilité des services en cas de désastre ;

1.2.5. Responsabilité du prestataire de services

1.2.7. Réception des services prestés

1.2.7.2. Réception définitive

La garantie couvre notamment :

1.2.9. Exécution des services

1.2.9.2. Personnel de l’ASBL L’Equipe

1.2.9.3. Personnel du prestataire

1.2.9.4. Suivi de la bonne exécution des livraisons et des services

1.2.10. Propriété des softs développés

1.2.10.2. Code source

1.2.11. Facturation et paiement

Les factures sont à adresser à

1.2.12. Engagements particuliers pour le prestataire de services

Le soumissionnaire, ses représentants et ses éventuels sous-traitants déclarent connaître et se soumettre à

Le soumissionnaire ne communiquera à son personnel et à celui de ses sous-traitants directement impliqués au

1.2.13. Stockage physique des données

1.2.15. Obligations des parties

1.2.16. Amendes et pénalités

2.1.2. Phasage du projet

2.1.3. Bénéfices attendus

2.1.4. Objet du marché

2.2. Contexte du projet

L'ASBL L'Equipe est composée de différentes structures :

 Le Centre Ados : Hôpital psychiatrique de jour (20 lits),

L'ASBL L'Equipe se situe géographiquement sur plusieurs sites :

 Bâtiment Central : Le Jade, Le Code et Le Crit au 60 rue de Veeweyde à Anderlecht

2.2.2. Structure de gouvernance