La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Des nouvelles applications eHealth pour les hôpitaux.

Présentations similaires


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

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

3 3 08/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

4 4 08/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

5 5 08/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

6 6 08/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

7 7 08/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_ pdf) https://www.ehealth.fgov.be/binaries/website/fr/pdf/deliberation_ RN_021_ 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/ f FR.pdf) https://www.ehealth.fgov.be/binaries/website/fr/pdf/ f FR.pdf

8 8 08/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/sourc es/nationalregister.htmlhttps://www.ehealth.fgov.be/fr/page_menu/website/home/platform/sourc es/nationalregister.html

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

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

11 11 08/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.dochttps://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.pdfhttps://www.ehealth.fgov.be/binaries/website/fr/pdf/Demande-d- autorisation-webservice-RN-FR.pdf

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

13 13 08/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

14 14 08/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é

15 15 08/10/2009 WebServices 1.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

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

17 17 08/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

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

19 19 08/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

20 20 08/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 NISSIdentifyPerson PhoneticSearch: Identification d’une personne physique sur base de critères phonétiquesPhoneticSearch ManageInscription: Insertion et suppression au service d’abonnementManageInscription MutationSender: Mise à disposition des mutationsMutationSender PersonHistory: Mise à disposition de l'historique des données du registre national et des registres Banque Carrefour

21 21 08/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

22 22 08/10/2009 WebService IdentifyPerson Request

23 23 08/10/2009 WebService IdentifyPerson  For example:    NIHII  HOSPITAL   xxxxxxxxxxx   xxxxxxxxxxx  1    

24 24 08/10/2009 WebService IdentifyPerson Reply

25 25 08/10/2009 WebService IdentifyPerson 100 Success JEMEPPE-SUR- SAMBRE

26 26 08/10/2009 WebService IdentifyPerson PERSONNE TEST UNKNOWN STRAAT ONBEKEND ANTWERPEN 150 BELGIË

27 27 08/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

28 28 08/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

29 29 08/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

30 30 08/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

31 31 08/10/2009 Aperçu de l’architecture

32 32 08/10/2009 Aperçu de l’architecture

33 33 08/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/basicservi ces/certificates.html https://www.ehealth.fgov.be/fr/page_menu/website/home/platform/basicservi ces/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

34 34 08/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é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 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 Bruxellesformulaire

35 35 08/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 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 36 08/10/2009 Contact  contact Service PPKB   contact Technique RN Consult 

37 37 08/10/2009 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

39 39 08/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

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

41 41 08/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

42 42 08/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

43 43 08/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

44 44 08/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

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

46 46 08/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

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

48 48 08/10/2009 Conditions d'une prescription électronique  Textes juridiques (www.juridat.be)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

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

50 50 08/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

51 51 08/10/2009 Aperçu de l’architecture

52 52 08/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

53 53 08/10/2009 Journal individuel des entrées ou timestamp bags

54 54 08/10/2009 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 55 08/10/2009 Gestion des systèmes cliniques multiples au sein d’un même hôpital

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

57 57 08/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

58 58 08/10/2009 Aperçu de l’archivage

59 59 08/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

60 60 08/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

61 61 08/10/2009 Fonctionnalités du timestamp visualiser

62 62 08/10/2009 Fonctionnalités du timestamp visualiser

63 63 08/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

64 64 08/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

65 65 08/10/2009 Nouveau document de contrôle et document de visualisation des plug-ins  document viewer plug-in  document inspector plug-in

66 66 08/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

67 67 08/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

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

69 69 08/10/2009 Contact + procédure de testing  l'hôpital prend contact avec eHealth   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

71 71 08/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

72 72 08/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

73 73 08/10/2009 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 74 08/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

75 75 08/10/2009 MatMedFormulary  concerne: dispositifs médicaux  projet: intégration à Pharmaformulary  DB en construction

76

77

78 Sélection produitSélection produit

79 édition1édition1

80 papier

81 Pocket

82 82 08/10/2009 Remboursable Facturable ________________ BMF INAMI - CRI ABPH/BVZA Prescripteurs et utilisateurs AFMPS MatMedFormulary Prescription UNAMEC Affaires économiques Dispositifs médicaux (implantables)

83 Chiffrement de bout en bout

84 84 08/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

85 85 08/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

86 86 08/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

87 87 08/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

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

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

90 90 08/10/2009 Schéma (dé)chiffrement symétrique Utilisateur 2 Destinataire Utilisateur 1 Auteur du message Dépôt de clés Dépôt de messages 1 demande clé 2 envoie clé Clé symétrique Chriffé 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 de clé 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

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

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

93 93 08/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


Télécharger ppt "Des nouvelles applications eHealth pour les hôpitaux."

Présentations similaires


Annonces Google