Des nouvelles applications eHealth pour les hôpitaux
Consultation du Registre National et du Registre BCSS
Aperçu général
308/10/2009
Le Registre national banque de données à caractère personnel contenant des données
d'identification de base relatives à des personnes physiques qui sont inscrites
• dans les registres de population et des étrangers des communes• dans les registres des missions diplomatiques et des postes consulaires• dans le registre d'attente des candidats réfugiés politiques
gérée par le SPF Intérieur contient notamment, par intéressé,
• le numéro national• le nom• les prénoms• le sexe• le lieu de naissance• la date de naissance• la date de décès• la résidence principale
408/10/2009
Les registres Banque Carrefour banque de données à caractère personnel contenant des données d'identification de
base relatives à des personnes physiques
• qui ne sont pas inscrites dans le Registre national• dont toutes les données d'identification ne sont pas systématiquement mises à jour dans le
Registre national pour autant que leur identification soit requise
• pour l’application de la sécurité sociale• pour l'exécution des marchés publics belges• pour l'exécution des missions d'intérêt général
- de personnes physiques- d'organismes publics ou privés de droit belge
gérée par la Banque Carrefour de la sécurité sociale contient notamment, par intéressé,
• le numéro d'identification de la sécurité sociale (voir infra)• le nom• les prénoms• le sexe• le lieu de naissance• la date de naissance• la date de décès• la résidence principale
508/10/2009
Corrélation de ces registres les registres Banque Carrefour sont complémentaires au
Registre national : les registres Banque Carrefour complètent le Registre national et sont uniquement utilisés lorsque le Registre national ne peut (plus) fournir les données à caractère personnel souhaitées
les registres Banque Carrefour sont subsidiaires au Registre national : la priorité doit être accordée au Registre national dès que des données à caractère personnel relatives à une personne sont enregistrées et actualisées dans le Registre national
les deux banques de données à caractère personnel font régulièrement l’objet d’une synchronisation
608/10/2009
Numéro d’identification de la sécurité sociale si une personne physique possède un numéro national
• utilisation du numéro national comme clé d'identification unique• même si l'intéressé figure entre-temps dans les registres Banque
Carrefour• l'utilisation du numéro national requiert une autorisation du
Comité sectoriel du Registre national
si une personne physique ne possède pas de numéro national• utilisation d'un numéro d'identification attribué par la Banque
Carrefour de la sécurité sociale comme clé d'identification unique• jusqu'au moment où l'intéressé se voit éventuellement encore
attribuer un numéro national• l’usage du numéro d’identification attribué par la Banque
Carrefour de la sécurité sociale est libre
708/10/2009
L'accès (1/2) est limité à certaines catégories de destinataires
• entre autres aux organismes publics et privés de droit belge pour les informations dont ils ont besoin en vue de l'exécution de leurs missions d'intérêt général (→ hôpitaux)
requiert une autorisation du Comité sectoriel compétent de la Commission de la protection de la vie privée
l'accès au Registre national• Comité sectoriel du Registre national• pour les hôpitaux : délibération n° 21/2009 du 25 mars 2009 (voir
https://www.ehealth.fgov.be/binaries/website/fr/pdf/deliberation_RN_021_2009-1-.pdf)
accès aux registres Banque Carrefour• Comité sectoriel de la sécurité sociale et de la santé• pour les hôpitaux : délibération n° 09/39 du 7 juillet 2009 (voir
https://www.ehealth.fgov.be/binaries/website/fr/pdf/09-039-f063-1--FR.pdf)
808/10/2009
L'accès (2/2) autorisation générale pour les hôpitaux
• accès à certaines données à caractère personnel du Registre national et des registres Banque Carrefour (numéro d'identification, nom, prénoms, sexe, lieu de naissance, date de naissance, date de décès et résidence principale)
• utilisation du numéro d'identification conditions (voir infra)
• uniquement pour des finalités bien précises• pas de conservation illimitée des données à caractère personnel• limitation de l'accès aux données à caractère personnel• via une plate-forme sécurisée
obligations (voir infra)• transmission de documents au Comité sectoriel et à la plate-forme
eHealth• désignation d'un conseiller en sécurité de l'information• élaboration d'une polique de sécurité de l'information
pour plus d’informations : voir le site portail de la plate-forme eHealth• https://www.ehealth.fgov.be/fr/page_menu/website/home/platform/
sources/nationalregister.html
908/10/2009
Conditions (1/2) uniquement pour des finalités bien précises
• contrôle/actualisation de données d'identification de patients• identification univoque des patients au sein du dossier médical• gestion de la facturation
délai de conservation• les services de l'hôpital chargés de l'enregistrement et de la
gestion du dossier médical- jusqu'à 30 ans après le dernier contact avec le patient
• les services de l'hôpital chargés de la facturation et/ou du recouvrement
- pas au-delà de la fin de la procédure de recouvrement- ni au-delà du délai légal de prescription des actions intentées par les
prestataires de soins en ce qui concerne les prestations qu'ils ont fournies (= 2 ans à compter de la fin du mois dans lequel les prestations ont été fournies)
1008/10/2009
Conditions (2/2) limitation de l'accès à certains membres du personnel
• limiter le nombre de membres du personnel au strict minimum• les faire signer une déclaration de confidentialité• établir, actualiser et tenir à disposition une liste des membres du
personnel qui disposent d’un accès effectif, pour des raisons fonctionnelles
via une plate-forme sécurisée• la plate-forme eHealth• ou une autre plate-forme qui offre des garanties comparables en
matière de sécurité de l'information et qui fait l’objet d’un contrôle par le Comité sectoriel de la sécurité sociale et de la santé (n'existe pas à présent)
1108/10/2009
Obligations transmission de certains documents au Comité sectoriel de la
sécurité sociale et de la santé• engagement écrit et signé au terme duquel il accepte les conditions
exposées dans la délibération• copie de la prise de décision d’agréation d'un ou plusieurs services
hospitaliers• formulaire d'évaluation relatif aux mesures de référence pour la
sécurisation du traitement de données à caractère personnel- renseignements relatifs au conseiller en sécurité de l'information (voir infra)- renseignements relatifs à la politique de sécurité de l'information (voir infra)
• https://www.ehealth.fgov.be/binaries/website/fr/doc/Courrier-template-FR-Final.doc
transmission d'une demande à la plate-forme eHealth• demande relative à l'utilisation de services web (voir infra)• transmission de la demande à la section Gestion des programmes, des
projets et des clients• obtention d'un certificat eHealth (identification/authentification)• tests• https://www.ehealth.fgov.be/binaries/website/fr/pdf/Demande-d-
autorisation-webservice-RN-FR.pdf
1208/10/2009
Renseignements conseiller en sécurité identité et données de contact
formation et qualifications
description de fonction
place dans l'organisation
temps à consacrer à la fonction
autres fonctions éventuelles (non incompatibles)
1308/10/2009
Renseignements polique de sécurité (1/2)1. faire usage des services d'un conseiller en sécurité de l'information
2. évaluer les risques et les besoins en matière de sécurité sur le plan du traitement de données à caractère personnel
3. tenir à jour une version écrite de la politique de sécurité de l'information
4. identifier les divers supports sur lesquels les données sont traitées
5. informer les membres du personnel en ce qui concerne leurs obligations de confidentialité et de sécurité
6. prendre des mesures contre tout accès illicite ou inutile à des données à caractère personnel
7. prendre des mesures contre des dommages physiques qui pourraient mettre en péril des données à caractère personnel
1408/10/2009
Renseignements polique de sécurité (2/2)8. prendre des mesures de protection des différents réseaux
interconnectés
9. disposer d'une liste actuelle des personnes qui ont accès à des données à caractère personnel et de leur niveau d'accès
10.mettre en place un mécanisme d'autorisation d'accès sur les systèmes d'information
11.disposer d'un système d'enregistrement des personnes qui ont accès aux données à caractère personnel
12.contrôler la validité et l'efficacité dans le temps des mesures organisationnelles et techniques
13.disposer de procédures d'urgence en cas d'incidents de sécurité
14.disposer d'une documentation mise à jour relative aux mesures de sécurité
1508/10/2009
WebServices1. IdentifyPerson
• recherche de données à caractère personnel sur la base du numéro d'identification de la sécurité sociale du patient
• nom, prénoms, sexe, lieu de naissance, date de naissance, date de décès, résidence principale et historique des modifications (pour le service social de l'hôpital)
2. PhoneticSearch• recherche des mêmes données à caractère personnel sur la base de critères
phonétiques (éventuellement même incomplets) du patient (nom, prénom, date de naissance)
3. ManageInscription • ajout/suppression d'un patient donné (identifié à l'aide de son numéro
d'identification de la sécurité sociale) au/du service d'abonnement• l'hôpital peut ainsi recevoir les mutations (= modifications aux données à
caractère personnel disponibles)4. MutationSender
• mise à disposition journalière des mutations (= modifications aux données à caractère personnel disponibles) à l'hôpital
5. PersonHistory• consultation de l’historique des données du registre national et des registres
Banque Carrefour d’un patient à partir d’un NISS
1608/10/2009
D'autres besoins ? la plate-forme eHealth offre un accès intégré à certaines données à
caractère personnel du Registre national et des registres Banque Carrefour (voir supra)
par ailleurs, le Registre national et les registres Banque Carrefour contiennent encore d'autres données à caractère personnel• la nationalité
• le lieu de décès
• la profession
• l'état civil
• la cohabitation légale
• la composition du ménage
• la mention du registre concerné
• la situation administrative de candidats réfugiés politiques
• la situation de séjour d'étrangers
d’éventuels besoins peuvent être signalés à la plate-forme eHealth pour examen (juridique/pratique) plus détaillé
1708/10/2009
Mesures sécurité de l'information
la plate-forme eHealth organisera une concertation avec les hôpitaux
une "structure de concertation" aidera les hôpitaux à élaborer et à implémenter des polices en matière de sécurité de l'information
Consultation du Registre National et du Registre BCSS
Aspects techniques et procédure
1908/10/2009
Aperçu webservice RN Consult webservice IdentifyPerson webservice PhoneticSearch webservice ManageInscription webservice MutationSender webservice PersonHistory protocole aperçu de l’architecture contact procédure certificats eHealth
2008/10/2009
WebService RN Consult le service Web RN Consult est composé de 5 sous-
services web indépendants : • IdentifyPerson: Identification d’une personne physique à partir du
NISS • PhoneticSearch: Identification d’une personne physique sur base
de critères phonétiques • ManageInscription: Insertion et suppression au service
d’abonnement • MutationSender: Mise à disposition des mutations• PersonHistory: Mise à disposition de l'historique des données du
registre national et des registres Banque Carrefour
2108/10/2009
WebService IdentifyPerson le webservice ‘IdentifyPerson’ permet à un hôpital de
consulter les données du registre national et des registres Banque Carrefour d’un patient à partir d’un NISS (Numéro d’Identification de la Sécurité Sociale).
sur base du NISS donné par l’hôpital, le webservice ‘IdentifyPerson’ récupère les données suivantes :• le nom et le(s) prénom(s) • la date et le lieu de naissance • le sexe• la résidence principale• la date de décès
2208/10/2009
WebService IdentifyPerson Request
2308/10/2009
WebService IdentifyPerson For example:
<?xml version="1.0" encoding="UTF-8"?> <ns1:SearchBySSINRequest xsi:schemaLocation="urn:be:fgov:ehealth:consultRN:1_0:protocol
IdentifyPerson-1-0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns1="urn:be:fgov:ehealth:consultRN:1_0:protocol">
<Organisation> <Id>71099911</Id> <Type>NIHII</Type> <SubType>HOSPITAL</SubType> </Organisation> <ApplicationID>xxxxxxxxxxx</ApplicationID> <Inscription> <SSIN>xxxxxxxxxxx</SSIN> <QualityCode>1</QualityCode> <Period> <BeginDate>2009-04-20</BeginDate> <EndDate>2009-06-20</EndDate> </Period> </Inscription> </ns1:SearchBySSINRequest>
2408/10/2009
WebService IdentifyPerson Reply
2508/10/2009
WebService IdentifyPerson <?xml version="1.0" encoding="UTF-8"?><ns1:SearchBySSINReply Id="1234567890123" xsi:schemaLocation="urn:be:fgov:ehealth:consultRN:1_0:protocol
IdentifyPerson-1-0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:eH="urn:be:fgov:ehealth:commons:1_0:core" xmlns:ns1="urn:be:fgov:ehealth:consultRN:1_0:protocol"><eH:Status>
<Code>100</Code><Message>Success</Message>
</eH:Status><Person>
<SSIN>00010100000</SSIN><PersonData>
<Birth><Date>2000-01-01</Date><Localisation>
<Description Lang="FR">JEMEPPE-SUR-SAMBRE</Description>
<Municipality><InsCode>92140</InsCode>
</Municipality><Country>
<InsCode>150</InsCode></Country>
</Localisation></Birth>
2608/10/2009
WebService IdentifyPerson <Name>
<First>PERSONNE</First><Last>TEST</Last>
</Name><Gender>UNKNOWN</Gender><Address>
<StandardAddress><Street>
<Description Lang="NL">STRAAT ONBEKEND</description>
</Street><Housenumber>25</Housenumber><Municipality>
<InsCode>11002</InsCode><PostalCode>2000</PostalCode><Description>ANTWERPEN</Description>
</Municipality><Country>
<InsCode>150</InsCode><Description
Lang="NL">BELGIË</Description></Country>
</StandardAddress></Address>
</PersonData></Person>
</ns1:SearchBySSINReply>
2708/10/2009
WebService PhoneticSearch le webservice ‘PhoneticSearch’ permet à un hôpital de
consulter les données du registre national et des registres Banque Carrefour d’un patient à partir d’un nom et d’une date de naissance
sur base de critères « phonétiques » (nom, prénom, date de naissance) même incomplets, le service ‘PhoneticSearch’ tente de récupérer les données suivantes :• le nom et le(s) prénom(s)• la date et le lieu de naissance• le sexe• la résidence principale• la date de décès
2808/10/2009
WebService ManageInscription le webservice ‘ManageInscription’ permet à un hôpital
d’inscrire ou désinscrire un patient au service d’abonnement aux mutations
il s’agit pour l’hôpital de recevoir les mises à jour des différentes données disponibles
pour ajouter ou supprimer une inscription, l’hôpital fournit le NISS (Numéro d’Identification de la Sécurité Sociale) d’une personne ainsi qu’une période durant laquelle il souhaite recevoir les mutations pendant 6 mois
dans le cas où l’hôpital souhaite prolonger cette période, il rajoute la nouvelle période souhaitée
s’il souhaite réduire cette période, l’hôpital supprime la période excédentaire
2908/10/2009
WebService MutationSender
le webservice ‘MutationSender’ permet à un hôpital de recevoir les modifications des données disponibles
tous les jours, la plate-forme eHealth met à disposition de l’hôpital un fichier reprenant toutes les modifications des données disponibles de ses patients
ce fichier sera disponible pendant 45 jours
3008/10/2009
WebService PersonHistory le webservice ‘PersonHistory’ permet au service social d'un hôpital
de consulter l'historique des données du registre national et des registres Banque Carrefour d’un patient à partir d’un NISS (Numéro d’Identification de la Sécurité Sociale)
sur base du NISS donné par l’hôpital, le webservice ‘PersonHistory’ récupère, au choix, les données suivantes :• historique du nom et du(des) prénom(s)• historique de la date et du lieu de naissance• historique du sexe• historique des résidence principale• historique de la date de décès
en ce qui concerne l’enregistrement et la gestion du dossier médical, les données précitées pourront être conservées pendant 30 ans après le dernier contact avec le patient
en ce qui concerne la facturation, le délai de conservation des données précitées est de 2 ans à compter de la fin du mois au cours duquel les prestations médicales ont été fournies
3108/10/2009
Aperçu de l’architecture
eHealth platform CBSS National register
National register
BIS register
Mutation of the national register’s
subscription
CBSS reference repertory
3208/10/2009
Aperçu de l’architecture
mutations concernant les
hôpitaux
Serveur de dépôt des mutations
Webservices :manageInscriptionidentifyPersonphoneticSearchmutationSender
DB autorisations
DBService
d'abonnements
ESB BCSS
Hôpitaux,...
conseiller de sécurité
application WEB
RN
1. consultation via WS
2. récupération desmutations
OSB eHealth
Batch BCSS
batch eHealthtraitement mutations
2. récupération desmutations via WS Mutation Sender
1. consultation via WS
1. consultation via WS
Un fichier de mutations
envoyé une fois par jour
3308/10/2009
Protocole la sécurité de service Web utilise les normes standards:
• SSL one way• un certificat X.509; il contient l'identifiant de l'appelant: numéro
Inami ou numéro KBO- pour plus d'information sur le contenu des certificats et sur la façon d'obtenir
un tel certificat: https://www.ehealth.fgov.be/fr/page_menu/website/home/platform/basicservices/certificates.html
• temps de vie du message : une minute• la signature du timestamp, du body et du binary security token
permet à eHealth de vérifier l'intégrité du message et de l'identité de l'auteur du message
• pas de chiffrement du message
3408/10/2009
Procédure d'intégration l’hôpital souhaitant intégrer le webservice au sein d’une
de ses applications doit:• transmettre un engagement signé au Comité sectoriel de la
sécurité sociale et de la santé dans lequel il déclare approuver les conditions décrites dans la délibération, assorti d’un formulaire d’évaluation à compléter, portant sur les mesures de référence en matière de sécurité
• introduire une demande d’autorisation d’utilisation des webservices eHealth
• cette demande se fait via le formulaire que l’hôpital complète en précisant pour quel(s) service(s) web il souhaite l’autorisation; le formulaire dûment rempli doit être envoyé à l'adresse suivante: Plate-forme eHealth, Service PPKB, chaussée Saint-Pierre 375 à 1040 Bruxelles
3508/10/2009
Procédure d'intégration après le premier contact au service PPKB, voici les étapes de l'intégration:
• la plate-forme eHealth fournit les informations techniques (cookbook’s, url's des services de Test, WSDL) au contact IT de l'hôpital qui sera désigné
• un planning d'intégration est à fournir à eHealth ([email protected])• développement au niveau de l'hôpital• l'hôpital teste son client, d'abord avec un service de test• si test avec mock-up service concluant, l'hôpital peut utiliser l'environnement
eHealth d'acceptation pour effectuer ses tests d'intégration et ses tests fonctionnels (Durée de test minimum : 1 mois)
• eHealth ne fournit pas de test case, cependant eHealth conseille d'effectuer les tests qui sont indiqués dans le rapport de test fourni par le service PPKB
• si les tests d'acceptation sont concluants, l'hôpital envoie ses résultats de test via le formulaire qu'il aura reçu du service PPKB à l'adresse [email protected]
• si tout est ok, eHealth et l'hôpital conviendront d'une date de mise en production; eHealth devrait préparer la connexion à l'environnement de la production et fournira à l'hôpital l'URL du service de production
• durant le jour de mise en production, l'hôpital fournira du feed-back à [email protected] sur le résultat de tests de mise en production
un support technique est fourni par eHealth: [email protected]
3608/10/2009
Contact
contact Service PPKB
contact Technique RN Consult
3708/10/2009
Certificat eHealth
Important : Le certificat eHealth est valable pour l’utilisation de plusieurs applications
La prescription électronique de médicaments (ePrescription) en milieu hospitalier
Aperçu
3908/10/2009
Prescription électronique en milieu hospitalier les prescriptions médicales sont soumises à de
nombreuses conditions de forme et de contenu essentiel: toute prescription doit être signée et datée par
le prescripteur, que ce soit par la voie ordinaire ou électronique
en ce qui concerne la prescription en milieu hospitalier, une dérogation est possible:• utilisation d'un document électronique• sans signature électronique du prescripteur• toutefois avec enregistrement de la date et de l'heure et garantie
de l'intégrité par une instance compétente, p.ex. la plate-forme eHealth
4008/10/2009
Fonctionnalités fonctionnalités auxquelles doit satisfaire toute
prescription électronique:• authentification de l'identité et vérification de la qualité du
prescripteur• datation électronique de la prescription à bref délai après sa
création• système garantissant que la prescription ne peut plus être
modifiée de manière imperceptible après application de la datation électronique et de la méthode garantissant l'intégrité
• détection de celui qui a réalisé quelle opération en rapport avec la création de la prescription (à conserver pendant une période fixe)
• possibilité de validation locale et de vérification du contenu de la prescription et de la non-modification de la prescription après application de la méthode garantissant l'intégrité
4108/10/2009
Conditions d'une prescription électronique il s'agit, à l'heure actuelle, uniquement de la prescription
de médicaments du médecin et du dentiste en milieu hospitalier, donc à usage interne à l'égard de la pharmacie hospitalière
au sein de tout hôpital, il y a lieu de conclure une convention entre l'hôpital et tout prescripteur qui contient les éléments suivants:• la description de la procédure d'authentification du prescripteur• la description de la procédure de datation électronique et de
garantie de l'intégrité du document électronique
4208/10/2009
Conditions d'une prescription électronique la procédure de datation électronique et la méthode de
garantie de l'intégrité doivent satisfaire aux conditions fixées dans un protocole qui a été approuvé par la commission de convention compétente au sein de l'INAMI
en vue de l'usage de la plate-forme eHealth comme service de datation électronique, un même type de protocole comprenant les procédures suivantes a été approuvé• procédure d'authentification du prescripteur
- l'authentification de l'identité du prescripteur se fait au niveau local, au sein de l'hôpital
- l'authentification est possible sur base d'un nom d'utilisateur et mot de passe, ou du certificat d'authentification enregistré sur l'eID ou d'un autre certificat
valide
4308/10/2009
Conditions d'une prescription électronique• procédure de datation électronique et méthode de garantie
de l'intégrité - l'hôpital crée la prescription à l'aide du logiciel propre
mention de l'identité authentifiée du prescripteur mention de tous les données nécessaires à la prescription
- l'hôpital applique une procédure de hachage sur toute prescription
- les résultats du hachage (donc pas le contenu même de la prescription!) sont regroupés périodiquement (dans un timestamp bag) et sont transmis au service de datation électronique de la plate-forme eHealth
- le service de datation électronique de la plate-forme eHealth réalise une datation électronique et signe le résultat électronique
- les résultats du hachage soumis à la datation électronique et signés électroniquement sont renvoyés à l'hôpital
4408/10/2009
Conditions d'une prescription électronique• procédure de datation électronique et méthode de garantie
de l'intégrité (suite):- l'hôpital enregistre la prescription électronique et les résultats du
hachage datés et signés par la voie électronique dans ses archives
- l'hôpital prévoit la possibilité de lecture des prescriptions électroniques pendant une période de 10 ans
- la plate-forme eHealth archive également les résultats du hachage datés et signés par la voie électronique en vue de l'appui des parties concernées en cas de contestations
- l'hôpital même ainsi que les instances de contrôle sont en mesure d'à nouveau hacher les prescriptions électroniques et de vérifier si le résultat du hachage correspond au résultat du hachage qui a été daté et signé électroniquement par la plate-forme eHealth; si correspondance il y a, on est sûr que la prescription n'a pas été modifiée
4508/10/2009
Conditions d'une prescription électronique
Hôpital
prescription A1
code de hachage A
Plate-forme eHealth
2hachage
prescription B
code de hachage B
timestamp bag3
datationélectronique
4
signatureélectronique
5
archives6
archives6
4608/10/2009
Conditions d'une prescription électronique la prescription électronique en milieu hospitalier qui a fait
l'objet d'une application de la procédure d'enregistrement de la date et de l'heure par la plate-forme eHealth satisfait à l'ensemble des conditions fonctionnelles• l'authentification du prescripteur est confiée à l'hôpital même• la datation électronique de la prescription a lieu à bref délai
après sa création• l'utilisation de la procédure de hachage et de la signature
électronique de la plate-forme eHealth garantit que la prescription ne peut plus être modifiée de manière imperceptible
• l'archivage par la plate-forme eHealth de tous les résultats de hachage signés et datés par la voie électronique pour des contestations ultérieures éventuelles
4708/10/2009
Conditions d'une prescription électronique
cette procédure constitue un exemple parlant d'une réflexion out-of-the-box combinant les avantages de l'informatisation et les garanties d'authenticité et d'intégrité, en ce compris une indication temporelle valide
ce modèle peut cependant être appliqué à de nombreux autres documents et attestations dans le domaine des soins de santé
4808/10/2009
Conditions d'une prescription électronique Textes juridiques (www.juridat.be)
• arrêté royal n° 78 du 10 novembre 1967 relatif à l'exercice des professions des soins de santé, M.B.. 14 novembre 1967
• arrêté royal du 7 juin 2009 réglementant le document électronique remplaçant, dans les hôpitaux, des prescriptions du médecin compétent et du praticien de l'art dentaire compétent, en exécution de l'article 21, alinéa 2, de l'arrêté royal n° 78 du 10 novembre 1967 relatif à l'exercice des professions des soins de santé, M.B. 1er juillet 2009
La prescription électronique de médicaments (ePrescription) en milieu hospitalier
Aspects techniques et procédure
5008/10/2009
Aperçu aperçu de l’architecture détails de l’architecture
• journal individuel des entrées ou timestamp bags• protocole entre timestamp clients et timestamp serveur• gestion des systèmes cliniques multiples au sein d’un même
hôpital• aperçu de l’archivage• algorithme de hashing• choix de la longueur de clé pour la signature digitale• fonctionnalités du timestamp visualiser• développement d’un nouveau document de contrôle et d’un
document de visualisation des plug-ins installation de l’implémentation de référence certificats eHealth contact + procédure de testing
5108/10/2009
Aperçu de l’architecture
5208/10/2009
Algorithme de hashing avant de pouvoir utiliser le timestamping, l’hôpital doit
appliquer une procédure de hashing sur les données (la prescription)
pour garder des informations sécurisées jusqu‘en 2030, le hashing doit se faire au moins avec un Secure Hash Algorithm (SHA) 224
au niveau de l'implémentation de référence, il a été décidé que l’hôpital doit dès lors disposer au sein de son système informatique d’un outil de hashing basé sur des librairies d’algorithmes SHA 256
les librairies de ces algorithmes sont comprises dans les différents composants fournis via l’implémentation de référence
5308/10/2009
Journal individuel des entrées ou timestamp bags
5408/10/2009
Protocole timestamp client et timestamp serveur protocole Oasis-DSS selon le profil timestamp (voir
http://www.oasis-open.org/committees/dss/) les hôpitaux accèdent au serveur de timestamp de la plate-forme
eHealth au travers d‘Internet dans une première couche de contrôle d'accès, la plate-forme
eHealth acceptera uniquement des connexions en provenance d'adresses IP connues; cela permettra de tenir à distance des éventuelles attaques de notre service avec l’impact minimal possible
dans une seconde couche de contrôle d'accès, la requête de timestamp doit être signée par le client timestamp
les requêtes signées avec un certificat enregistré auprès de la plate-forme eHealth seront uniquement traitées
le distinguished name de la signature sera utilisé pour identifier le client timestamp appelant
le processus est détaillé dans le fichier WSDL du service de timestamp de la plate-forme
5508/10/2009
Gestion des systèmes cliniques multiples au seind’un même hôpital
5608/10/2009
Gestion des systèmes cliniques multiples au sein d’un même hôpital
Accessplugin
Accessplugin
Time stamp clientprogram
eHealth platform time stamp server
System 2
System 3
Accessplugin
Accessplugin
Time stamp clientprogram
Accessplugin
Accessplugin
Time stamp clientprogram
Hospital archiveBuffer of journal
entries to be time stamped
System 1
Buffer of journal entries to be time
stamped
Buffer of journal entries to be time
stamped
Hospital archive
Hospital archive
5708/10/2009
Aperçu de l’archivage l'archive de la plate-forme eHealth trusté
• le serveur de timestamp stocke toutes les requêtes et les réponses au sein d’une archive; ces archives seront gardées pendant une période X et l'hôpital doit également archiver les messages qui ont été timestampés (30 ans, 5 ans online)
les éléments d‘horodatage dans la figure représentent le cachet de temps complet comme rendu par le service de timestamp; il contient au moins: • le hash code du TSBag• la date et l'heure du timestamp, généré par le serveur de
timestamp• un numéro de séquence de timestamp généré par le serveur de
timestamp• la signature digitale de toutes ces données générée par le
serveur de timestamp
5808/10/2009
Aperçu de l’archivage
Timestamp
TSBag
JE 1 Ref 1Ref 1 Hash (JE 1)
JE 2 Ref 2Ref 2 Hash (JE 2)
JE 3 Ref 3Ref 3 Hash (JE 3)
JE 4 Ref 4Ref 4 Hash (JE 4)
JE 5 Ref 5Ref 5 Hash (JE 5)
TSBag 1
Hospital archive
Timestamp
eHealth platform archive
TSBag
Ref 1 Hash (JE 1)
Ref 2 Hash (JE 2)
Ref 3 Hash (JE 3)
Ref 4 Hash (JE 4)
Ref 5 Hash (JE 5)
TSBag 1
Timestamp
TSBag
JE 6 Ref 6Ref 6 Hash (JE 6)
JE 7 Ref 7Ref 7 Hash (JE 7)
JE 8 Ref 8Ref 8 Hash (JE 8)
JE 9 Ref 9Ref 9 Hash (JE 9)
TSBag 2
Timestamp
TSBag
Ref 6 Hash (JE 6)
Ref 7 Hash (JE 7)
Ref 8 Hash (JE 8)
Ref 9 Hash (JE 9)
TSBag 2
TSBag
JE 10 Ref 10Ref 10 Hash (JE 10)
JE 11 Ref 11Ref 11 Hash (JE 11)
JE 12 Ref 12Ref 12 Hash (JE 12)
JE 13 Ref 13Ref 13 Hash (JE 13)
JE 14 Ref 14Ref 14 Hash (JE 14)
TSBag 3
Timestamp Timestamp
TSBag
Ref 10 Hash (JE 10)
Ref 11 Hash (JE 11)
Ref 12 Hash (JE 12)
Ref 13 Hash (JE 13)
Ref 14 Hash (JE 14)
TSBag 3
Info on patient 1
Info on patient 4
Info on patient 3
Info on patient 2
Search fields JE 1
Search fields JE 2
Search fields JE 3
Search fields JE 4
Search fields JE 5
Search fields JE 6
Search fields JE 7
Search fields JE 8
Search fields JE 9
Search fields JE 10
Search fields JE 11
Search fields JE 12
Search fields JE 13
Search fields JE 14
5908/10/2009
Aperçu de l’archivage les hôpitaux et la plate-forme eHealth devront garder les
archives qui garantissent que le journal hospitalier, le TSBags et les timestamps sont stockés de manière sécurisés et complètement inchangés tant que le journal hospitalier est conservé
tant l'hôpital que les archives de plate-forme eHealth utiliseront l'identification du client timestamp appelant, la date et heure du timestamp et du numéro de séquence du timestamp comme clés pour accéder aux archives; cela permettra une comparaison facile des deux archives aux services d'inspection
période d'archivage: le journal des entrées, les TSBags et les timestamps devront être archivés pendant 30 ans
6008/10/2009
Longueur de clé pour la signature digitale
la première version du service de timestamp de la plate-forme eHealth utilisera une longueur de clé de 2048 bits pour la signature digitale des timestamps
6108/10/2009
Fonctionnalités du timestamp visualiser
Search parameters
List of journal entries matching the search criteria
Flag indicating the result of the check of the timestamp. Red
bullet means problem, check mark
means OK Visualisation of the selected journal entry
6208/10/2009
Fonctionnalités du timestamp visualiser
6308/10/2009
Fonctionnalités du timestamp visualiser comme le journal hospitalier contient des informations, et
vu que les médecins sont légalement responsables, les hôpitaux devront mettre à disposition le timestamp visualiser pour leurs praticiens
également utilisé par le personnel interne, le timestamp visualiser devrait respecter les règles de confidentialité des hôpitaux : lorsque certaines informations ne sont pas disponibles pour quelqu'un via le système d'information opérationnel de l'hôpital, cela ne devrait pas être non plus disponible au travers du timestamp visualiser
6408/10/2009
Service d'inspection INAMI - Timestamping le service d'inspection continuera à demander les mêmes
informations demandés actuellement le service d'inspection utilisera également certains éléments de
l'implémentation de référence pour effectuer leur contrôle : le visualiser
l'inspecteur pourra demander à l'hôpital un extrait du journal, l'incorporer sur son poste et effectuer ses investigations par le visualiser• l'extrait sera formaté dans un fichier zip et transmis soit via memory
stick, CD, ...
• l‘INAMI envisage de mettre un système en place pour utiliser un secure FTP pour l'envoi de l'extrait du journal
de plus, il pourra également consulter les archives de la plate-forme eHealth lorsqu'il désirera comparer certains TSBAG timestampés des archives d'eHealth avec l'extrait du journal
6508/10/2009
Nouveau document de contrôle et document de visualisation des plug-ins
document viewer plug-in
document inspector plug-in
6608/10/2009
Installation de l’implémentation de référence installation du client timestamp
• création d'une base de données tampon (the buffer database)• création de la base de données archive de l'hôpital• configuration
- connexion vers la base de données tampon- connexion vers la base de données - document inspection- configuration des classes pour les plug-ins- configuration de la sécurité- configuration des propriétés du proxy- configuration des certificats du serveur de timestamp- URLs des services de timestamp de la plate-forme eHealth
• installation du client timestamp client comme un service• test des programmes• installation du contrôleur de cohérence d'archives• programme d'enregistrement de rapport d'incident • outils de de-buggins
- visualiser un bag- visualiser les numéros de séries des archives de timestamp de plate-forme eHealth
6708/10/2009
Installation de l’implémentation de référence installation du visualiser
• ajout d'un utilisateur à la base de donnée• plug-ins• configuration
- cache- sql server datasources- Kmehr.xsl- interface utilisateur dans différentes langues
6808/10/2009
Certificats eHealth
Important : Le certificat eHealth est valable pour l’utilisation de plusieurs applications
6908/10/2009
Contact + procédure de testing l'hôpital prend contact avec [email protected] nous envoyons un mail présentant les différentes étapes de connexion au
service de timestamping :• l'hôpital doit installer un certificat dans l’environnement d’acceptation; pour ce
faire, il trouvera dans le mail ou sur le portail les documents nécessaires à la demande de certificat chez Fedict : la procédure et le formulaire; cette demande est traitée par le service AccessCoordination de Smals
• le certificat installé, l'hôpital peut procéder aux tests dans l’environnement d’acceptation; durant cette période, le point de contact est [email protected]
• lorsque les tests en acceptation sont concluants, l'hôpital peut passer aux tests dans l’environnement de production
• pour l’environnement de production, l'hôpital a le choix d’installer soit un nouveau certificat, soit le même certificat que pour l’acceptation; dans le premier cas, les démarches précédentes sont à refaire
• le certificat installé, l'hôpital peut procéder aux tests dans l’environnement de production; durant cette période, le point de contact est [email protected]
• lorsque les tests en production sont concluants, l'hôpital peut alors utiliser le service timestamping en production; l'hôpital est alors tenu de signer une convention
PharmaFormulary
7108/10/2009
Besoins des pharmaciens hospitaliers prescription électronique des spécialités
pharmaceutiques, des dispositifs médicaux (DM) et des dispositifs médicaux implantables (DMI) pour les patients hospitalisés et ambulants
prescription électronique pour un destinataire Extra Muros (pharmacie d’officine, Maison de repos et de soins, autres hôpitaux, …..)
gestion du formulaire thérapeutique hospitalier• spécialités pharmaceutiques -> PharmaFormulary ok• DM et DMI ->MatMedFormulary Pas ok
intégration du Plan comptable nécessité d’une base de données authentique, gratuite,
accessible à tous les acteurs concernés par la prescription électronique
7208/10/2009
?
CBIP
SPF Santé Publique
AFMPS
ABPH / BVZA
Prescripteurs et utilisateurs
INAMI - CRM
PharmaFormulary
Prescription
Affaires économiques
ABPH/BVZA
Médicaments et spécialités pharmaceutiques
7308/10/2009
PharmaFormulary outil de gestion et diffusion du formulaire thérapeutique
hospitalier
accessible à tous les professionnels de la santé via • www.health.fgov.be/telematics• www.afphb.be
utilise la DB du CBIP, enrichie des médicaments spécifiquement hospitaliers (perfusions,..)
collaboration ABPH/BVZA– CBIP/BCFI
7408/10/2009
PharmaFormulary mises à jour mensuelles de la DB (12/2009) assurent la
validité du document
personnalisation à multiples niveaux – diffusion de l’information sur le médicament
diffusion du formulaire sous différents formats complémentaires:• impression• intranet • pocket pc
7508/10/2009
MatMedFormulary
concerne: dispositifs médicaux
projet: intégration à Pharmaformulary
DB en construction
Sélection produit
édition1
papierpdapda
8208/10/2009
RemboursableFacturable
________________
BMF
INAMI - CRI
ABPH/BVZA
ABPH / BVZA
Prescripteurs et utilisateurs
AFMPS
MatMedFormulary
Prescription
UNAMEC
Affaires économiques
Dispositifs médicaux (implantables)
Chiffrement de bout en bout
8408/10/2009
Objectif de base end-to-end encryption (ETEE) ou chiffrement de bout en
bout doit permettre aux acteurs des soins de santé de s'échanger des messages électroniques au travers de réseaux ouverts• sans qu'une personne autre que l'émetteur et le destinataire final
puisse prendre connaissance de leur contenu (aspect de confidentialité)
• tout en garantissant que le contenu chiffré n'a pas été modifié depuis l'envoi (aspect intégrité)
le contenu chiffré des messages électroniques ne peut donc être déchiffré ou modifié par des instances intervenantes, telles la plate-forme eHealth ou une organisation chargée de l'enregistrement temporaire des messages
8508/10/2009
Besoins fonctionnels le système de chiffrement end-to-end permet de
• chiffrer des messages électroniques de manière end-to-end si le destinataire du message est connu au moment du chiffrement
• chiffrer des messages électroniques de manière end-to-end si le destinataire du message n'est pas connu au moment du chiffrement
• chiffrer des messages électroniques lors de l'enregistrement temporaire de sorte que seul celui qui les a créés, puisse les déchiffrer
le système doit pouvoir être utilisé• par tous les acteurs des soins de santé en Belgique• pour un maximum d'applications• sans devoir fixer de standards spécifiques par partenaire ou
application
8608/10/2009
Systèmes de chiffrement utilisés chiffrement asymétrique
• la clé utilisée pour le chiffrement est différente de celle utilisée pour le déchiffrement
• tout acteur génère une paire de clés sous sa surveillance• ce qui est chiffré avec une des clés de la paire de clés peut
uniquement être déchiffré avec l'autre clé de la même paire de clés
• une des clés de la paire de clés est enregistrée dans une banque de données publique, l'autre clé est conservée, de manière sécurisée, auprès du titulaire
• est utilisé lorsque le destinataire est connu au moment du chiffrement par l'émetteur
8708/10/2009
Systèmes de chiffrement utilisés chiffrement symétrique
• la clé utilisée pour le chiffrement est la même que celle utilisée pour le déchiffrement
• la clé est générée par la plate-forme eHealth, est mise à la disposition de l'émetteur et est conservée auprès de la plate-forme eHealth en rapport avec un numéro unique du message électronique chiffré
• le message électronique chiffré n'est JAMAIS enregistré dans la sphère d'influence de la plate-forme eHealth
• le destinataire autorisé final du message chiffré apporte la preuve de son droit au déchiffrement et reçoit de la plate-forme eHealth la clé de déchiffrement du message concerné
• est utilisé lorsque le destinataire n'est pas connu au moment du chiffrement par l'émetteur ou pour un enregistrement chiffré temporaire de messages électroniques
8808/10/2009
Schéma génération paire de clés asymétrique
Plate-forme eHealthActeur des soins de santéPersonne ou entité
Inte
rnet
Cer
tific
atd‘
iden
tific
atio
n
Cer
tific
atd‘
iden
tific
atio
n
Service webRegistre clé
Connecteur ou autre logiciel pour
générer la paire de clés
Envoieclé publique
Conserve la clé privéede manière sécurisée
Dépôt cléspubliques
1
2
2
Authentifie l'émetteur
Conserveclé publique
3
4
8908/10/2009
Schéma (dé)chiffrement asymétrique
Internet
Plate-forme eHealth
Cer
tific
atd'
iden
tific
atio
n
Dépôt cléspubliques
Authentifie l'émetteur
Envoieclé publique
2
3
Auteur du message
Cer
tific
atd'
iden
tific
atio
n
Demande clé publique
Chiffrele message
4
1
Destinataire du message
Déchiffre le message
5 Cléprivée
conservée
Certificatd'identification
Service webDemande clé publique
Envoie message
et protocole
9008/10/2009
Schéma (dé)chiffrement symétrique
Utilisateur 2Destinataire
Utilisateur 1Auteur dumessage
Dépôt de
clés
Dépôtde messages
1 demande clé
2 envoie cléClé symétriq
ueChriffé avec clé
publique d'utilisateur 1
3 envoie message chiffréMessage chiffré à l'aide de
clé symétrique
Chiffré avec clé publique du
dépôt de messages
Message chiffré à l'aide declé symétrique
4 justifie droit d'obtenir clé
4 justifie droit d'obtenir message
Clé symétrique
Chiffré avec clé
publique d'utilisateur 2
5 reçoit clé
5 reçoit message
Message chiffré à l'aide de
clé symétrique
Chiffré avec clé publique
d'utilisateur 2
9108/10/2009
Services élaborés pour chiffrement et déchiffrement asymétriques
• système est disponible• et validé par COSIC• se compose d'un software library et de la documentation y
afférente (cookbook) susceptibles d'être intégrés dans les logiciels des acteurs des soins de santé, permettant
- de générer des paires de clés au niveau local en toute sécurité- d’enregistrer la clé privée de la paire de clés au niveau local en toute sécurité- d’enregistrer la clé publique de la paire de clés dans une banque de données
publique auprès de la plate-forme eHealth au moyen d'un service web- de rechercher la clé publique du destinataire via un service web dans la
banque de données publique créée auprès de la plate-forme eHealth et de chiffrer le message électronique
- de déchiffrer un message chiffré reçu à l'aide de la clé privée propre- et par dessus tout d'apposer les signatures numériques requises et d'utiliser
les certificats y afférents et de contrôler leur validité
9208/10/2009
Services élaborés pour chiffrement et déchiffrement symétriques
• système en cours de développement et très probablement disponible d'ici fin 2009
• sera soumis au COSIC pour validation• se compose
- d'un service web avec documentation y afférente auquel il peut être fait appel auprès de la plate-forme eHealth en vue de l'obtention d'une clé symétrique de chiffrement d'un message électronique déterminé
- d'un service web avec documentation y afférente auquel il peut être fait appel auprès de la plate-forme eHealth en vue de l'obtention d'une clé symétrique de déchiffrement d'un message électronique déterminé
- d'un software library et de la documentation y afférente susceptibles d'être intégrés dans les logiciels des acteurs des soins de santé, permettant
de chiffrer le message électronique à l'aide de la clé symétrique de déchiffrer le message électronique à l'aide de la clé symétrique et par dessus tout d'apposer les signatures numériques requises et
d'utiliser les certificats y afférents et de contrôler leur validité
9308/10/2009
Déliverables déjà disponibles la documentation et les composants suivants de
l'environnement ETEE sont déjà disponibles sur le portail de la plate-forme eHealth• un ‘document architecture’ contenant une description des
composants conceptuels et techniques du système global• un ‘cookbook’ prévoyant la documentation relative aux standards
de chiffrement et aux protocoles recommandés par la plate-forme eHealth ainsi que la procédure d'obtention des 'certificats d'authentification'
• les 'spécifications techniques' des composants déjà disponibles• spécifiques au chiffrement des messages adressés
- l'application de génération de paires de clés et d'obtention de certificats de chiffrement
- la banque de données dans laquelle les paires de clés peuvent être enregistrées et recherchées, accessible via des services web documentés
- l'application/utility/source code pour le chiffrement et le déchiffrement
Top Related