Des nouvelles applications eHealth pour les hôpitaux

Présentation au sujet: "Des nouvelles applications eHealth pour les hôpitaux"— Transcription de la présentation:

1 Des nouvelles applications eHealth pour les hôpitaux
1

2 Consultation du Registre National et du Registre BCSS Aperçu général
2

3 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

4 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

5 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

6 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

7 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 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

8 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

9 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)

10 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)

11 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) 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

12 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)

13 Renseignements polique de sécurité (1/2)
faire usage des services d'un conseiller en sécurité de l'information évaluer les risques et les besoins en matière de sécurité sur le plan du traitement de données à caractère personnel tenir à jour une version écrite de la politique de sécurité de l'information identifier les divers supports sur lesquels les données sont traitées informer les membres du personnel en ce qui concerne leurs obligations de confidentialité et de sécurité prendre des mesures contre tout accès illicite ou inutile à des données à caractère personnel prendre des mesures contre des dommages physiques qui pourraient mettre en péril des données à caractère personnel

14 Renseignements polique de sécurité (2/2)
prendre des mesures de protection des différents réseaux interconnectés disposer d'une liste actuelle des personnes qui ont accès à des données à caractère personnel et de leur niveau d'accès mettre en place un mécanisme d'autorisation d'accès sur les systèmes d'information disposer d'un système d'enregistrement des personnes qui ont accès aux données à caractère personnel contrôler la validité et l'efficacité dans le temps des mesures organisationnelles et techniques disposer de procédures d'urgence en cas d'incidents de sécurité disposer d'une documentation mise à jour relative aux mesures de sécurité

15 WebServices IdentifyPerson PhoneticSearch ManageInscription
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) 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) 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) MutationSender mise à disposition journalière des mutations (= modifications aux données à caractère personnel disponibles) à l'hôpital PersonHistory consultation de l’historique des données du registre national et des registres Banque Carrefour d’un patient à partir d’un NISS

16 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é

17 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

18 Consultation du Registre National et du Registre BCSS Aspects techniques et procédure
18

19 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

20 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

21 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

22 WebService IdentifyPerson
Request

23 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=" xmlns:ns1="urn:be:fgov:ehealth:consultRN:1_0:protocol"> <Organisation> <Id> </Id> <Type>NIHII</Type> <SubType>HOSPITAL</SubType> </Organisation> <ApplicationID>xxxxxxxxxxx</ApplicationID> <Inscription> <SSIN>xxxxxxxxxxx</SSIN> <QualityCode>1</QualityCode> <Period> <BeginDate> </BeginDate> <EndDate> </EndDate> </Period> </Inscription> </ns1:SearchBySSINRequest>

24 WebService IdentifyPerson
Reply

25 WebService IdentifyPerson
<?xml version="1.0" encoding="UTF-8"?> <ns1:SearchBySSINReply Id=" " xsi:schemaLocation="urn:be:fgov:ehealth:consultRN:1_0:protocol IdentifyPerson-1-0.xsd" xmlns:xsi=" 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> </SSIN> <PersonData> <Birth> <Date> </Date> <Localisation> <Description Lang="FR">JEMEPPE-SUR-SAMBRE</Description> <Municipality> <InsCode>92140</InsCode> </Municipality> <Country> <InsCode>150</InsCode> </Country> </Localisation> </Birth>

26 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>

27 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

28 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

29 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

30 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

31 Aperçu de l’architecture

32 Aperçu de l’architecture

33 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: 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

34 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

35 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 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 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 à sur le résultat de tests de mise en production un support technique est fourni par eHealth:

36 Contact contact Service PPKB  Request@ehealth.fgov.be
contact Technique RN Consult 

37 Certificat eHealth Important : Le certificat eHealth est valable pour l’utilisation de plusieurs applications

38 La prescription électronique de médicaments (ePrescription) en milieu hospitalier Aperçu
38

39 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

40 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é

41 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

42 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

43 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

44 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

45 Conditions d'une prescription électronique
Hôpital Plate-forme eHealth 1 6 prescription A prescription B archives hachage 2 code de hachage A code de hachage B 5 signature électronique 3 timestamp bag 4 datation électronique 6 archives

46 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

47 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é

48 Conditions d'une prescription électronique
Textes juridiques ( 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

49 La prescription électronique de médicaments (ePrescription) en milieu hospitalier Aspects techniques et procédure 49

50 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

51 Aperçu de l’architecture

52 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

53 Journal individuel des entrées ou timestamp bags

54 Protocole timestamp client et timestamp serveur
protocole Oasis-DSS selon le profil timestamp (voir 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

55 Gestion des systèmes cliniques multiples au sein d’un même hôpital

56 Gestion des systèmes cliniques multiples au sein d’un même hôpital

57 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

58 Aperçu de l’archivage

59 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

60 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

61 Fonctionnalités du timestamp visualiser

62 Fonctionnalités du timestamp visualiser

63 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

64 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

65 Nouveau document de contrôle et document de visualisation des plug-ins
document viewer plug-in document inspector plug-in

66 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

67 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

68 Certificats eHealth Important : Le certificat eHealth est valable pour l’utilisation de plusieurs applications

69 Contact + procédure de testing
l'hôpital prend contact avec 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 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 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

70 PharmaFormulary 70

71 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 ABPH/BVZA : association belge des pharmaciens hospitaliers DM Dispositifs Médicaux DMI Dispositifs Médicaux Implantables

72 Médicaments et spécialités pharmaceutiques
Affaires économiques Prescripteurs et utilisateurs AFMPS ? CBIP Prescription INAMI - CRM PharmaFormulary SPF Santé Publique CRM: commission de remboursement des médicaments ABPH/BVZA ABPH / BVZA

73 PharmaFormulary outil de gestion et diffusion du formulaire thérapeutique hospitalier accessible à tous les professionnels de la santé via utilise la DB du CBIP, enrichie des médicaments spécifiquement hospitaliers (perfusions,..) collaboration ABPH/BVZA– CBIP/BCFI

74 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

75 MatMedFormulary concerne: dispositifs médicaux
projet: intégration à Pharmaformulary DB en construction

76 Sur la page d’acceuil du site de téléchargement, il vous est simplement demandé de vous identifier et le type d’utilisation auquel vous destinez le logiciel: Construction du formulaire hospitalier Construction d’un formulaire pour maison repos Formulaire personnel pour medecin

77 Le logiciel est structuré de la même manière que le Répertoire Commenté des Médicaments, édité par le CBIP-BCFI, et en reprend d’origine l’entièreté des textes.

78 Sélection produit Choix des produits à intégrer dans son formulaire à partir de la base de données du CBIP se réalise de façon simple et rapide.

79 édition1 Les différentes options de publication vous permettent d’éditer des documents plus ou moins détaillés.

80 papier Exemple de document sur support « papier »

81 Pocket Exemple de pages html adaptées au Pocket pc

82 Dispositifs médicaux (implantables)
Prescripteurs et utilisateurs Affaires économiques Remboursable Facturable ________________ BMF ABPH/BVZA Prescription AFMPS MatMedFormulary INAMI - CRI Projet des pharmaciens hospitaliers : accessibilité à une base de données complète sur les dispositifs médicaux et dispositifs médicaux implantables, suite à la mise en place de la notification des implants en mai 2010 à l’INAMI. Dans un premier temps, la base de données se limitera aux dispositifs médicaux implantés notifiés à l’INAMI. CRI Commission de Remboursement des Implants UNAMEC association professionnelle reconnue des entreprises qui produisent, importent et/ou distribuent des dispositifs médicaux. UNAMEC ABPH / BVZA

83 Chiffrement de bout en bout
83

84 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

85 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

86 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

87 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

88 Schéma génération paire de clés asymétrique
Plate-forme eHealth Acteur des soins de santé Personne ou entité Internet 1 3 Connecteur ou autre logiciel pour générer la paire de clés Authentifie l'émetteur 4 2 d‘identification Certificat d‘identification Certificat Conserve clé publique Envoie clé publique Service web Registre clé 2 Dépôt clés publiques Conserve la clé privée de manière sécurisée

89 Schéma (dé)chiffrement asymétrique
Plate-forme eHealth Auteur du message Internet 1 Service web Demande clé publique d'identification Certificat d'identification Certificat 2 Demande clé publique Authentifie l'émetteur Envoie message et protocole 3 4 Envoie clé publique Chiffre le message Certificat d'identification Dépôt clés publiques Destinataire du message Clé privée conservée 5 Déchiffre le message

90 Schéma (dé)chiffrement symétrique
Dépôt de clés Clé symétrique Chriffé avec clé publique d'utilisateur 1 Chiffré avec clé publique d'utilisateur 2 Clé symétrique 2 envoie clé 5 reçoit clé Utilisateur 1 Auteur du message 1 demande clé Utilisateur 2 Destinataire 4 justifie droit d' obtenir clé 4 justifie droit d' obtenir message 3 envoie message chiffré Chiffré avec clé publique du dépôt de messages 5 reçoit message Chiffré avec clé publique d'utilisateur 2 Message chiffré à l'aide de clé symétrique Dépôt de messages Message chiffré à l'aide de clé symétrique Message chiffré à l'aide de clé symétrique

91 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é

92 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é

93 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