eHealthBox La Boîte aux lettres électronique sécurisée

Présentation au sujet: "eHealthBox La Boîte aux lettres électronique sécurisée"— Transcription de la présentation:

1 eHealthBox La Boîte aux lettres électronique sécurisée
1

2 Ordre du jour Partie 1 : Aspects business Partie 2 : Pratique
Objectif et fonction du service de base « eHealthBox » Besoins business Bref historique eHealthBox road map : évolution en fonction des besoins Gouvernance Partie 2 : Pratique Fonctionnalités Phases Groupes-cibles disponibles Partie 3 : Demo Partie 4 : Open panel (Q&A)

3 Objectif et fonction du service de base « eHealthBox »
Mettre à la disposition de chaque acteur des soins de santé une boîte aux lettres électronique sécurisée dans laquelle d'autres acteurs peuvent déposer des messages à caractère médical confidentiels destinés au titulaire de la boîte. Cette boîte aux lettres remplace les formulaires et documents imprimés par un flux de données électronique. But: Un échange et un traitement plus rapides et plus efficaces de données relatives à la santé. Messages à caractère médical confidentiels

4 Besoins business Chaque acteur des soins de santé doit pouvoir publier un message, un document ou une lettre d'information à l'intention d'un acteur ou d'un groupe d'acteurs (hôpital, maison de repos, ...) Chaque prestataire de soins doit pouvoir avoir accès à une zone individuelle sécurisée où il peut consulter sa boîte aux lettres électronique. Il y trouvera tous les documents publiés par les autres acteurs. Exemples de messages possibles Documents généraux & informations destinées à des groupes, p.ex. Autorités resp. autorités de santé vers les médecins ex. Influenza, FOD/SPF resp. RIZIV/INAMI vers les médecins,… Envoi de lettres + informations médicales Rapports de consultation, rapports d'hôpitaux Résultats d'analyse, protocols (labo, RX, …) Document / structured message (sont exclus des images!)

5 Bref historique Base: eBox_BCSS/KSZ pour MyCareNet Client: CIN / NIC
Utilisateurs: Infirmiers indépendants, organismes assureurs Application: MyCareNet: mise à disposition de mises à jour lors du traitement de données de facturation et du statut d'assurabilité Fonctionnel: Application web de consultation Développement des interfaces pour les services web, intégration de l'application web dans le portail eHealth Adaptations à l'application "core" pour améliorer la stabilité, la performance et le soutien

6 eHealthBox roadmap Evolution en fonction des besoins business concrets. Alignement du déploiement sur base des besoins business auprès des prestataires de soins et des institutions (publiques) et auprès des autorités en matière de soins de santé qui assurent la communication entre eux. Fonctionnalités échelonnées Dans une 1ère phase le système est mis à la disposition d'un public restreint Le système eHealthBox sera étendu à de nouveaux groupes-cibles, en fonction de leur présence dans les sources authentiques. Le timing quant à la disponibilité de chacune de ces sources authentiques n'entre pas dans le cadre du projet eHealthBox mais relève du groupe de travail "Sources authentiques", qui définit les priorités en fonction des besoins concrets du projet. Phase 1 Phase 2 Future

7 Governance eHealthBox est un service de base qui intègre l’application back end de l’utilisateur au moyen de services web Fournisseur de service: plate-forme eHealth Infrastructure de stockage: les besoins de volume de stockage vont augmenter avec l'usage. Par conséquent, il est important de respecter une éthique concernant le type de communication qui sera assurée via l’eHealthBox. L’utilisation est uniquement destinée aux soins de santé. Aucun détournement de l’utilisation d’eHealthBox ne sera permis (publicités, "spams", chaînes de lettres ...) Conception des règles d'utilisation contrôlé par un comité de pilotage spécifique

8 Gouvernance : Règlement de l'utilisateur
L'utilisation de eHealthBox est soumise à un règlement de l'utilisateur rédigé par un comité directeur spécifique au sein duquel siègent les utilisateurs institutionnels de eHealthBox, notamment l'INAMI, le SPF Santé publique et le ISP à adapter dans le futur en fonction de l'évolution de l'usage visé et de la gestion du eHealthBox à accepter par les utilisateurs préalablement à l'emploi Contenu du règlement de l'utilisateur: emploi exclusif pour les communications entre acteurs des soins de santé de données qui requièrent un haut degré de confidentialité et de protection l'emploi à des fins commerciales ou pour l'envoi de courrier électronique indésirable (spam) est strictement interdit

9 2 - Pratique Partie 2 : Pratique Fonctionnalités Phases
Partie 1 : Orienté business Objectif et fonction du service de base « eHealthBox » Besoins business Bref historique eHealthBox road map : évolution en fonction des besoins Gouvernance Partie 2 : Pratique Fonctionnalités Phases Groupes-cibles disponibles Partie 3 : Demo Partie 4 : Open panel (Q&A)

10 Fonctionnalités Fonctionnalité Phase 1
Future Fonctionnalité Phase 1 Service web Publication (“envoyer”) WebService + WebApp Consultation (“recevoir”) Notification (de la réception d'un message eHealthBox) via l'adresse standard Module pour la mise à jour des données de contact: eHealthUpdateInfo Remarque: Il est possible de publier un message avec une annexe chiffrée

11 Mise à jour des données de contact
Module eHealthUpdateInfo Processus d'identification via token citoyen ou eID Consulter: NISS, Nom, Prénoms Mettre à jour: adresse

12 Fonctionnalités Fonctionnalités Phase 2 Autres groupes-cibles
Future Fonctionnalités Phase 2 Autres groupes-cibles WebApp Publication Intégration cryptage Accusé de reception, de publication, de lecture Reply & Forward Consultation de boîtes multiples Niveau de priorité Auto-delete

13 Fonctionnalités Phase 2 (1/2)
Nouveaux groupes-cibles Chaque groupe-cible disponible dans les sources authentiques doit être en mesure de publier et de recevoir. WebApp Publication Chaque groupe-cible (qu'il dispose d'un logiciel médical enregistré ou non) doit pouvoir publier. C'est pourquoi une application web de publication sera développée, qui sera intégrée à l'application web existante (de consultation). Intégration cryptage Services web: cryptolibs à intégrer par producteurs de SW + emploi de dépôt ETK Application web: web client (JWS) à développer. Utilisation locale de données d'identification pour (dé)chiffrement

14 Fonctionnalités Phase 2 (2/2)
Confirmation de réception, de publication et de lecture Réception: message à l'expéditeur lorsque l'information est enregistrée dans DB Publication: message à l'expéditeur lorsque le message est disponible dans l'inbox du destinataire Lecture: message à l'expéditeur lorsque le destinataire à consulté le contenu du message Reply & Forward Vers un autre eHealthBox Consultation de mailboxes multiples Pouvoir visualiser simultanément tous ses eHealthBoxes sur 1 écran Niveaux de priorité Possibilité d'attribuer la mention "important" à un message Auto-delete Tous les messages publiés il y a plus d'un an seront supprimés, indépendamment du fait qu'ils aient été lus ou non ou qu'ils aient été placés dans la poubelle.

15 Fonctionnalités Wishlist (Future) Phase 1 Phase 2 Future
Elektronisch aangetekende zending / Lettre recommandée électronique (1) … (1) Remarque: Cadre légal: Loi du 9 juillet 2001: définition des règles en matière de signatures électroniques, d'envois recommandés électroniques et de services de certification Projet de loi amendement voté (oct 2010) Commission infrastructure de la Chambre Complexité technique

16 Groupes-cibles disponibles en phase 1
Groupes-cibles Phase 1 Citoyen Prestataire de soins : professionnel Infirmier ambulatoire Médecin Prestataire de soins: institution ou groupement Groupement d’infirmiers Hôpital général Autres : Institution de soins de santé (SPF Santé publique, INAMI, CIN,…)

17 3 - Démo service de base eHealthBox
Partie 1 : Orienté business Objectif et fonction du service de base « eHealthBox » Besoins business Bref historique eHealthBox road map : évolution en fonction des besoins Gouvernance Partie 2 : Pratique Fonctionnalités Publication Groupes-cibles disponibles Partie 3 : Demo Partie 4 : Open panel (Q&A)

18 4 – Questions Partie 4 : Open panel (Q&A) Partie 1 : orienté business
Objectif et fonction du service de base « eHealthBox » Besoins business Bref historique eHealthBox road map : évolution en fonction des besoins Gouvernance Partie 2 : Pratique Fonctionnalités Phasage Groupes-cibles disponibles Partie 3 : Demo Partie 4 : Open panel (Q&A)

19 Inventaire des opportunités business
L’eHealthBox est prête à passer en production avec des fonctionnalités de base (voir Fonctionnalités phase 1 en annexe). Inventaire des besoins concrets pour des projets qui pourraient à moyen terme avoir recours à ce service de base eHealth: Les institutions concernées sont invitées à déterminer, en concertation avec les responsables (business & IT) au sein de leur organisation, quels sont les projets qu'elles souhaitent réaliser avec eHealthBox. Il est important de déterminer pour chaque projet concret une date butoir correcte et de désigner un responsable de projet chargé de garantir, au nom de l'institution, le respect de ce timing. Institutions consultées: INAMI SPF SPSE - DG1 SPF SPSE - DG2 CIN ISP AFMPS APB

20

21 Informations à déterminer
Business Scope (envoyer quoi, vers qui) Volumes Nombre de publications et fréquence (p.ex. 1 par trimestre, 4 par an) Taille des annexes moyenne (MB) par publication taille maximale des fichiers (MB) Groupes-cibles (utilisateurs visés) Timing du projet Responsable du projet s'engage quant au timing du projet