La plateforme eHealth: concept et

1
La plateforme eHealthconcept et état
d'avancement
Frank Robben Administrateur général Banque
Carrefour de la Sécurité Sociale Chaussée
Saint-Pierre 375 B-1040 Bruxelles E-mail
Frank.Robben_at_bcss.fgov.be Site web BCSS
www.bcss.fgov.be Site web personnel
www.law.kuleuven.ac.be/icri/frobben
2
But de la plateforme eHealth

• comment
• sur base dune prestation de services et d'un
  échange dinformations mutuels électroniques bien
  organisés entre tous les acteurs des soins de
  santé
• tout en offrant les garanties utiles au niveau de
  la sécurité de linformation et de la protection
  de la vie privée
• quoi
• optimaliser la qualité et la continuité des
  prestations de soins de santé
• optimaliser la sécurité du patient
• simplifier les formalités administratives pour
  tous les acteurs des soins de santé
• offrir un soutien optimal à la politique des
  soins de santé

3
Qu'est-ce que la plateforme ne fait pas ?

• apporter des modifications à la répartition des
  tâches concrète entre les différents acteurs des
  soins de santé
• enregistrer des données à caractère personnel de
  manière centralisée
• monopoliser la prestation de services
  électronique aux utilisateurs finaux
• réaliser soi-même des études
• soutenir soi-même la politique dans le domaine
  des soins de santé
• être dirigée sur la base de la technologie plutôt
  que compte tenu des objectifs contenus dans la
  vision

4
Fondements prévus

• plateforme de collaboration pour léchange
  électronique sécurisé de données relatives aux
  patients, aux soins donnés et aux résultats des
  soins donnés et de prescriptions de soins
  électroniques entre tous les acteurs des soins de
  santé
• réseau
• services de base
• normes, standards, spécifications fonctionnelles
  et techniques et architecture de base en matière
  de TIC
• canaux d'ouverture adaptés à lutilisateur
• Comité sectoriel de la Commission de la
  protection de la vie privée (CPVP)
• cadre juridique adapté
• la plateforme eHealth comme organisation

5
Plateforme et standards de collaboration

• utilisation de linfrastructure réseau existante
  (Internet, extranet sécurité sociale, FedMAN, )
  avec cryptage end-to-end des informations de
  contenu (concept de réseaux privés virtuels
  (VPN))
• services de base offerts par la plateforme
  eHealth
• gestion des utilisateurs et des accès
• orchestration des processus
• répertoire des références
• logging
• codification et dépersonnalisation
• time stamping
• environnement portail avec notamment un système
  de content management et un moteur de recherche
• boîte aux lettres électronique personnelle pour
  chaque prestataire de soins

6
Plateforme et standards de collaboration

• un maximum déchanges à laide de messages
  électroniques structurés dapplication à
  application
• un maximum déchanges sur base de standards
  ouverts ou, à tout le moins, de spécifications
  ouvertes

7
Répertoire des références

• contenu
• indication, à la demande du patient identifié à
  laide de son numéro didentification du patient,
  des endroits où se trouvent les différents types
  dinformations relatives au patient, aux soins
  donnés et aux résultats des soins donnés
• dune part, table avec relations de soins fixes
  actuelles entre les prestataires de soins et
  leurs patients, la nature de la relation, et les
  dates de début et de fin de la relation
• d'autre part, table contenant, outre la relation
  de soins fixe, les endroits de disponibilité
  d'informations relatives aux différents patients
• éventuellement via un système graduel (répertoire
  des références général renvoie à des répertoires
  des références spécifiques par groupe de
  prestataires de soins ou par établissement de
  soins)
• pas de données de contenu!!!

8
Répertoire des références

• fonctions
• contrôle préventif quant à la légitimé de laccès
  aux informations relatives à un patient donné
• routage des demandes dinformations vers les
  endroits où se trouvent les informations
  relatives au patient concerné
• possibilité de communication automatique
  dinformations à certains prestataires de soins

9
Codification et dépersonnalisation

• la plateforme eHealth est chargée en tant que
  tierce partie de confiance
• de codifier et de dépersonnaliser les
  informations
• de mettre des données codées ou anonymes à la
  disposition des acteurs des soins de santé, des
  responsables politiques et des chercheurs
• contrôle par le Comité sectoriel de la conformité
  des méthodes de codification et de
  dépersonnalisation avec la législation en matière
  de protection de la vie privée
• la plateforme eHealth même ne soutient ni la
  politique, ni ne réalise des études !!!

10
Canaux douverture adaptés aux utilisateurs

• différents supports
• ordinateur (portable)
• PDA
• GSM
• pour chaque groupe cible, organisé de préférence
  par les prestataires actuels de ce groupe cible
  (pas de monopole de la plateforme eHealth !)
• pour chaque groupe cible, au moins une
  application gratuite, généralement accessible, en
  vue de l'ouverture intégrée des informations,
  développée de manière résiduaire par la
  plateforme eHealth sous forme d'application web
  si nécessaire
• une ouverture intégrée maximale des informations
  que l'utilisateur peut recevoir, indépendamment
  des sources dinformations

11
Comité sectoriel

• composé de
• représentants de la CPVP
• spécialistes indépendants en matière de soins de
  santé désignés par la Chambre des représentants
• tâches
• accorder des autorisations pour léchange
  (électronique) de données à caractère personnel
  relatives à la santé, dans les cas autres que
  ceux autorisés par la loi
• déterminer lorganisation et les directives en
  matière de sécurité de linformation lors du
  traitement de données à caractère personnel
  relatives à la santé
• formuler des avis et des recommandations en
  matière de sécurité de linformation lors du
  traitement de données à caractère personnel
  relatives à la santé
• traiter les plaintes en matière dinfraction à la
  sécurité de linformation lors du traitement de
  données à caractère personnel relatives à la santé

12
Cadre juridique adapté

• création de la plateforme eHealth en tant
  qu'organisation, avec détermination de la
  structure juridique, des missions, des organes de
  gestion et de concertation et de leur composition
• possibilité resp. obligation dutiliser le numéro
  didentification du patient
• force probante des prescriptions électroniques et
  des échanges de données électroniques
• adaptation de la réglementation spécifique en
  fonction des projets à réaliser

13
Plateforme eHealth comme organisation

• missions
• développer une vision et une stratégie en matière
  de prestation de services et d'échange
  dinformations électroniques dans les soins de
  santé, tout en respectant la protection de la vie
  privée
• fixer des normes et standards fonctionnels et
  techniques en matière de TIC pour la prestation
  de services et d'échange dinformations
  électroniques dans les soins de santé
• vérifier si les logiciels de gestion des dossiers
  électroniques de patients répondent à ces normes
  et standards
• concevoir, développer et gérer une plateforme de
  collaboration pour léchange électronique de
  données sécurisé, qui est assortie des services
  de base connexes (voir supra)

14
Plateforme eHealth comme organisation

• missions
• saccorder sur une répartition des tâches en ce
  qui concerne la collecte, la validation,
  lenregistrement et la mise à disposition de
  données échangées au moyen de la plateforme de
  collaboration et sur les normes de qualité en la
  matière
• promouvoir et coordonner la réalisation de
  programmes et de projets visant à exécuter la
  vision et la stratégie et qui utilisent la
  plateforme de collaboration et/ou les services
  connexes
• coordonner les aspects TIC de cet échange de
  données dans le cadre des dossiers électroniques
  de patients et des prescriptions médicales
  électroniques
• intervenir comme tierce partie de confiance lors
  de la codification et dépersonnalisation de
  données à caractère personnel relatives à la santé

15
Plateforme eHealth comme organisation

• missions
• être le moteur des changements nécessaires en vue
  de l'exécution de la vision et de la stratégie
• organiser la collaboration avec dautres
  instances publiques chargées de la coordination
  de la prestation de services électronique

16
Plateforme eHealth comme organisation

• organes
• Comité de gestion
• prestataires de soins et établissements de soins
• Ordres des médecins et des pharmaciens
• mutualités
• services publics chargés de compétences en
  matière de soins de santé SPF Santé publique,
  INAMI, SPF Sécurité sociale, Centre fédéral
  d'expertise des soins de santé, Agence fédérale
  des médicaments et des produits de santé
• représentants des Ministres de la Santé publique,
  des Affaires sociales, de l'Informatisation et du
  Budget
• ayant voix consultative, des représentants de la
  Banque Carrefour de la sécurité sociale
• Comité de concertation avec groupes de travail
  tous les principaux gestionnaires

17
Etat davancement

• plateforme eHealth existante
• services de base existants
• sources authentiques validées actuelles
• services à valeur ajoutée actuels et en cours de
  développement
• législation existante

18
La plateforme eHealth
Patients et prestataires de soins
Portail SS
SVA
SVA
SVA
SVA
Site INAMI
PortaleHealth
MyCareNet
SVA
SVA
SVA
SVA
SVA
SVA
SVA
SVA
Utilisateurs
Plateforme avec services de base
SAV
SAV
SAV
SAV
SAV
SAV
Fournisseurs
19
La plateforme eHealth

• service de base
• un service développé et mis à la disposition par
  la plateforme eHealth, qui peut être utilisé par
  loffreur dun service à valeur ajoutée lors du
  développement et de loffre dun service à valeur
  ajoutée
• service à valeur ajoutée (SVA)
• un service mis à la disposition des patients
  et/ou prestataires de soins
• linstance chargée du développement et de la mise
  à disposition dun service à valeur ajoutée peut
  utiliser à cet effet les services de base offerts
  par la plateforme eHealth

20
La plateforme eHealth

• source authentique validée (SAV)
• une banque de données contenant des informations
  auxquelles la plateforme eHealth fait appel
• le gestionnaire de la banque de données est
  responsable de la disponibilité et de
  (lorganisation de) la qualité des informations
  mises à la disposition

21
Services de base déjà disponibles

• réseau, basé sur linfrastructure existante
  (Internet, Carenet, extranet sécurité sociale,
  FedMAN, )
• environnement portail (https//www.behealth.be),
  avec notamment
• système de content management
• moteur de recherche
• boîte aux lettres électronique personnelle pour
  chaque prestataire de soins
• gestion intégrée des utilisateurs et des accès
• orchestration des processus
• gestion de loggings
• en cours de développement
• codification et dépersonnalisation
• time stamping

22
Portail
23
Portail
24
Gestion des utilisateurs et des accès

• but
• garantir que seuls les prestataires de soins /
  établissements de soins autorisés aient accès
• aux données à caractère personnel auxquelles ils
  peuvent avoir accès conformément à la loi ou aux
  autorisations du Comité sectoriel
• relatives aux patients dont les informations
  personnelles concernées leur sont nécessaires
  dans le cadre des prestations de soins
• conditions
• gestion des autorisations daccès avec indication
• de quel prestataire de soins / établissement de
  soins / application
• en quelle qualité
• peut avoir accès dans quelle situation
• à quels types de données
• concernant quels patients
• pour quelle période

25
Gestion des utilisateurs et des accès

• conditions
• authentification de lidentité du prestataire de
  soins, par exemple au moyen de sa carte
  didentité électronique
• vérification en ligne de la qualité du
  prestataire de soins par une consultation
  électronique de la (des) banque(s) de données
  authentique(s) des prestataires de soins
• vérification en ligne des mandats de
  lutilisateur autorisé à intervenir au nom dun
  prestataire de soins / établissement de soins par
  une consultation électronique de la (des)
  banque(s) de données authentique(s) des mandats
• authentification de lidentité du patient au
  moyen de sa carte didentité électronique ou de
  sa carte SIS, sauf
• si une relation de soins fixe est enregistrée
  entre le prestataire de soins / linstitution de
  soins et le patient (voir supra, répertoire des
  références)
• dans des cas durgence

26
Gestion des utilisateurs et des accès

• organisation élaborée
• l'autorisation d'utiliser un service à valeur
  ajoutée est accordée par l'offreur du service, si
  nécessaire moyennant une autorisation du Comité
  sectoriel
• la conformité dune demande daccès concrète avec
  les autorisations daccès est validée à titre
  préventif par lorganisme indépendant gérant la
  plateforme de collaboration
• tous les accès font lobjet dune prise de trace
  (logging) électronique au niveau de lutilisateur
  afin de pouvoir vérifier par la suite, en cas de
  plaintes, si laccès était légitime (uniquement
  qui-quoi-quand, pas de contenu)
• laccès aux loggings est protégé de manière
  stricte

27
Gestion des utilisateurs et des accès

• organisation élaborée
• l'authentification de l'identité intervient en
  fonction du niveau de sécurité requis à l'aide de
• la carte didentité électronique
• un numéro utilisateur, un mot de passe et un
  token citoyen
• un numéro utilisateur et un mot de passe
• la vérification des qualités et mandats
  intervient par un accès aux sources authentiques
  validées
• le tout est développé sur base dun modèle
  générique de policy enforcement

28
Policy Enforcement Model
Action
sur
Action
application
Policy
sur
REFUSÉE
application
Utilisateur
Application
Application
AUTORISÉE
(
PEP
)
Action
sur
application
Demande de
Réponse de
décision
décision
Information
Question
/
Policy
Recherche
Réponse
Policies
Décision
(
PDP
)
Information
Question
/
Réponse
Gestion
Policy Administration
Policy Information
Policy Information
de lautorisation
(
PAP
)
(
PIP
)
(
PIP
)
Gestionnaire
Source authentique
Source authentique
Policy
repository
29
Policy Enforcement Point (PEP)

• intercepter la demande dautorisation avec toutes
  les informations disponibles concernant
  lutilisateur, laction demandée, les ressources
  et lenvironnement
• transmettre la demande dautorisation au Policy
  Decision Point (PDP) et exiger une décision
  dautorisation
• donner accès à lapplication et fournir les
  justificatifs pertinents

Action
sur
Action
application
Policy
sur
REFUSÉE
application
Utilisateur
Application
Application
AUTORISÉE
(
PEP
)
Action
sur
application
Demande de
Réponse de
décision
décision
Policy
Décision
(
PDP
)
30
Policy Decision Point (PDP)

• sur la base de la demande dautorisation reçue,
  recher-cher la policy dautorisation adéquate
  dans les Policy Administration Points (PAP)
• évaluer la policy et, au besoin, rechercher les
  informa-tions pertinentes dans les Policy
  Information Points (PIP)
• prendre la décision dautorisation (permit / deny
  / not applicable) et la communiquer au PEP

Policy
Application
(
PEP
)
Réponse de
Demande de
décision
décision
Information
Question
/
Policy
Recherche
Réponse
Policies
Décision
(
PDP
)
Information
Question/
Réponse
Policy Information
Policy Administration
Policy Information
(
PAP
)
(
PIP
)
(
PIP
)
31
Policy Administration Point (PAP)

• environnement de sauvegarde et de gestion des
  policies dautorisation par la (les) personne(s)
  compétente(s) désignée(s) par le responsable de
  lapplication
• mise à la disposition des policies dautorisation
  pour le PDP

Gestion
Recherche
de lautorisation
Policies
PDP
PAP
Gestionnaire
Policy
repository
32
Policy Information Point (PIP)

• mise à la disposition du PDP de linformation
  pour lévaluation des policies dautorisation
  (sources authentiques avec caractéristiques,
  mandats, )

Information
Question/
Réponse
PDP
Information
Question/
Réponse
PIP
1
PIP
2
Source authentique
Source authentique
33
Architecture
SPF hors social (Fedict)
Secteur social (BCSS)
Plateforme eHealth
USER
USER
USER
APPLICATIONS
APPLICATIONS
APPLICATIONS
Authorisation
Authen
-
Authorisation
Authen
-
Authorisation
Authen
-
tication
tication
tication
PEP
PEP
PEP
WebApp
WebApp
Role
Role
Role
XYZ
XYZ
Mapper
Mapper
Mapper
Role
Role
Mapper
Mapper
DB
DB
PDP
Role
PAP
PDP
Role
PAP
PAP
Provider
Role
Provider
Role
Kephas
Kephas
Kephas
DB
Provider
DB
Provider
PIP
PIP
PIP
PIP
PIP
PIP
Attribute
Attribute
Attribute
Attribute
Attribute
Attribute
Provider
Provider
Provider
Provider
Provider
Provider
Provider
Gestion
DB
DB
Gestion
Huissier de justice
DB
DB
DB
DB
UMAF
XYZ
XYZ
XYZ
SAV
Mandats
Mandats
SAV
34
Principe de cercles de confiance

• but
• éviter une centralisation inutile
• éviter des menaces inutiles pour la protection de
  la vie privée
• éviter des contrôles identiques et des
  enregistrements multiples de loggings
• méthode répartition des tâches entre les
  instances concernées par la prestation de
  services électroniques avec des accords précis en
  ce qui concerne
• quelle instance réalise quelles
  authentifications, quelles vérifications et quels
  contrôles à laide de quels moyens et qui en est
  responsable
• la manière selon laquelle les résultats des
  authentifications, des vérifications et des
  contrôles réalisés sont communiqués par la voie
  électronique, d'une manière sécurisée, entre les
  instances concernées
• quelle instance conserve quels loggings
• comment veiller à ce qu'en cas d'investigation, à
  linitiative dun organisme de contrôle ou à
  l'occasion d'une plainte, un traçage complet
  puisse avoir lieu à savoir quelle personne
  physique a utilisé quel service ou quelle
  transaction concernant quel citoyen ou quelle
  entreprise, à quel moment, par le biais de quel
  canal et pour quelles finalités

35
Sources authentiques validées

• cadastre des prestataires de soins
• gestionnaire SPF Santé publique, Sécurité de la
  Chaîne alimentaire et Environnement
• contient des informations relatives au diplôme et
  à la spécialité dun prestataire de soins
  identifié à laide de son numéro didentification
  de la sécurité sociale (NISS)
• banque de données contenant les agréations de
  lINAMI
• gestionnaire INAMI
• contient des informations relatives à lagréation
  par lINAMI dun prestataire de soins identifié à
  laide de son NISS
• banque de données des personnes mandatées à
  intervenir au nom dun établissement de soins
• gestionnaire ONSS (partie gestion des
  utilisateurs entreprises)
• contient les informations suivantes quelles
  personnes identifiées à laide de leur NISS sont
  mandatées à utiliser quelles applications au nom
  de létablissement de soins

36
Services à valeur ajoutée

• en production
• alimentation et consultation du Registre du
  cancer
• Medattest
• en phase de test
• déclaration de naissance électronique (eBirth)
• facturation tiers payant
• en cours de développement
• Medic-e
• appui prescription de soins électronique dans les
  hôpitaux
• appui dépersonnalisation et codification pour
  INAMI et AIM

37
Alimentation et consultation du Registre cancer

• offreur Fondation Registre du cancer
• utilisateurs oncologues au sein des
  établissements de soins et des laboratoires
• fonctionnalité introduire des informations dans
  le Registre du cancer par la voie électronique et
  avoir accès aux informations introduites
• services de base utilisés
• identification et authentification de lidentité
  de lutilisateur (eID)
• vérification de la qualité du médecin avec
  agréation INAMI
• boîte aux lettres électronique (publication de
  documents)
• logging

38
Medattest

• offreur INAMI
• utilisateurs médecins, dentistes,
  kinésithérapeutes, logopédistes, orthopédistes,
  établissements de soins et leurs mandataires
• fonctionnalité commander des prescriptions de
  soins en mode en ligne
• services de base utilisés
• identification et authentification de lidentité
  de lutilisateur (eID ou numéro utilisateur-mot
  de passe-token citoyen)
• vérification de la qualité des utilisateurs
• vérification du mandat
• logging

39
Déclaration de naissance électronique

• offreurs Fedict, Registre national et Banque
  Carrefour de la sécurité sociale
• utilisateurs médecins, sages-femmes et
  infirmiers dans les hôpitaux
• fonctionnalité déclaration électronique de la
  naissance d'un enfant
• services de base utilisés
• portail
• identification et authentification de lidentité
  de lutilisateur (eID ou numéro utilisateur-mot
  de passe-token citoyen)
• vérification de la qualité des utilisateurs
• vérification du mandat
• logging

40
Facturation tiers payant

• offreur Collège intermutualiste national
• utilisateurs infirmiers, leurs groupements et
  mandataires
• fonctionnalité transmettre les factures tiers
  payant par la voie électronique aux mutualités
• services de base utilisés
• identification et authentification de lidentité
  de lutilisateur (eID ou numéro utilisateur-mot
  de passe-token citoyen)
• vérification de la qualité de linfirmier avec
  agréation INAMI
• vérification du mandat
• boîte aux lettres électronique (publication de
  documents)
• logging

41
Medic-e

• offreur SPF sécurité sociale
• utilisateurs médecins évaluant les personnes
  handicapées
• fonctionnalité introduire lévaluation des
  personnes handicapées par la voie électronique
  dans le système informatique du SPF Sécurité
  sociale
• services de base utilisés
• identification et authentification de lidentité
  de lutilisateur (eID ou numéro utilisateur-mot
  de passe-token citoyen)
• vérification de la qualité du médecin avec
  agréation INAMI
• boîte aux lettres électronique (publication de
  documents)
• logging

42
Prescription électronique établissements soins

• examen des fonctionnalités requises
• fonctionnalités avant que la prescription puisse
  être traitée
• authentification de lidentité du prescripteur
• vérification de la qualité du prescripteur
• système garantissant que la prescription ne peut
  plus être modifiée de manière imperceptible après
  application des méthodes garantissant lintégrité
  et la datation électronique
• authentification de lidentité, vérification de
  la qualité du prescripteur, garantie de
  lintégrité et la datation électronique doivent
  avoir lieu pour toute prescription individuelle
• le temps nécessaire à lauthentification de
  lidentité, à la vérification de la qualité et à
  la garantie de lintégrité ne peut être
  supérieure à ¼ seconde par prescription
• un même prescripteur doit pouvoir switcher sans
  frais entre plusieurs endroits à partir desquels
  il souhaite rédiger une prescription
• validation locale selon laquelle la prescription
  na pas été modifiée suite à lapplication de la
  méthode visant à garantir lintégrité

43
Prescription électronique établissements soins

• examen des fonctionnalités requises
• fonctionnalités pendant traitement de la
  prescription
• la datation électronique doit être demandée
  immédiatement après lapplication de la méthode
  visant à garantir lintégrité et avoir lieu dans
  un délai de 30 secondes au maximum après la
  demande
• exigences dordre organisationnel
• rapidité de remplacement dun moyen
  dauthentification si inutilisable
• traçabilité de celui qui a réalisé quelle
  opération et à quel moment concernant la création
  de la prescription (conservée pendant une période
  définie)
• traçabilité du contenu et du moment de chaque
  demande et traitement dune demande de révocation
  dun moyen dauthentification
• point dattention spécifique
• il y a lieu déviter que les établissements de
  soins ne soient confrontés pour divers types de
  processus à différents systèmes
  dauthentification de lidentité, de vérification
  de la qualité, de garantie de lintégrité de
  documents, de datation électronique,

44
Prescription électronique établissements soins

• proposition de solution
• lauthentification de lidentité et la
  vérification de la qualité ont lieu au niveau
  local et interviennent au minimum à laide dun
  user-id, un mot de passe et dun élément en
  possession, à condition que tout prescripteur
  signe un document selon lequel tout ce qui est,
  sur le plan de lidentité et des qualités,
  authentifié à laide de son user-id, son mot de
  passe et lélément en sa possession tombe sous
  sa responsabilité
• les prescriptions font lobjet dun hachage
• les résultats du hachage (donc pas le contenu
  même de la prescription !) font lobjet dun
  timestamp par la plateforme eHealth
• des règles organisationnelles précises en matière
  de gestion des user-ids, des mots de passe et
  des éléments en possession sont versées dans un
  arrêté royal en exécution de larticle 21 de lAR
  n 78 celles-ci sont basées sur les résultats de
  Elodis
• une réglementation fixant les conditions dans
  lesquelles des prescriptions complémentaires sont
  possibles, est en cours délaboration

45
Nouvelles demandes d'appui

• SPF Santé publique, Sécurité de la Chaîne
  alimentaire et Environnement
• révision de l'application en vue de donner son
  consentement pour un don d'organe (Orgadon)
• informations sur des projets thérapeutiques
• traçage du sang
• Agence fédérale des médicaments et des produits
  de santé
• application pour les comités éthiques
• consortium ePrescription (pharmaciens, médecins
  et mutualités)
• prescription électronique dans le secteur
  ambulatoire
• Agence flamande soins et santé
• VESTA plateforme d'échange de données entre
  l'Agence et ses services agréés

46
Législation existante

• article 4 de la loi du 27 décembre 2006 portant
  des dispositions diverses
• Un service de l'Etat à gestion séparée, tel que
  visé à l'article 140 des lois sur la comptabilité
  de l'Etat, coordonnées le 17 juillet 1991,
  dénommé "Be-Health" est créé au sein du Service
  public fédéral Santé publique, Sécurité de la
  Chaîne alimentaire et Environnement en vue de la
  gestion de la plateforme électronique de services
  relative à l'échange de données de soins de
  santé.
• Le Roi détermine, par arrêté délibéré en Conseil
  des ministres, les missions et les modalités de
  gestion et d'exploitation de ce Service de l'Etat
  à gestion séparée.

47
Facteurs de succès critiques

• collaboration entre tous les acteurs des soins de
  santé, basée sur une répartition des tâches
  plutôt que sur une centralisation des tâches
• confiance de tous les gestionnaires en ce qui
  concerne le maintien de lautonomie nécessaire et
  de la sécurité du système
• dabord développement de la plateforme déchange
  et création des organes nécessaires (plateforme
  eHealth en tant qu'organisation, plateforme de
  collaboration, Comité sectoriel, ) et ensuite
  élaboration sur le plan du contenu au sein de ces
  organes
• quick wins en combinaison avec une vision à long
  terme
• cadre légal