Vitalink est le coffre-fort santé flamand : une plate-forme ancrée dans un décret où les prestataires de soins partagent le schéma de médication, le Sumehr et les vaccinations et où des sources authentiques livrent les dépistages du cancer et le dossier de l'enfant. Elle n'a pas d'écran propre : le logiciel du prestataire de soins y lit et y écrit via la plate-forme eHealth, après que le Departement Zorg a notamment vérifié le consentement éclairé ; si un hub agréé demande les données, c'est ce hub qui effectue lui-même ce contrôle. À côté de l'environnement KMEHR plus ancien, Vitalink 2.0 tourne depuis 2024 sur FHIR ; les vaccinations et les dépistages du cancer ont migré, le schéma de médication pas encore selon le serveur de production. Pour les logiciels hospitaliers, la liste Vitalink des progiciels pour FHIR ne mentionne que des immunisations.
", "last_verified": "2026-10-29", "verification_outdated": false, "sections": [ { "id": "en-bref", "title": "En bref", "kind": "tekst", "html": "Vitalink est une plate-forme partagée organisée par l'Autorité flamande : le décret du 8 juillet 2022 (articles en vigueur à partir du 1er janvier 2023) prévoit qu'une instance désignée par le Gouvernement flamand organise Vitalink comme plate-forme partagée sécurisée[1], dans le but de consulter, de conserver et de partager des données de santé en toute sécurité[1]. Il s'agit d'un coffre-fort santé : un lieu de conservation où les prestataires de soins déposent les données d'un patient pour que d'autres prestataires de soins puissent les lire, contrairement à un hub comme CoZo, qui va chercher les documents à la source. Domus Medica qualifie dès lors Vitalink de « coffre-fort santé de première ligne » flamand[15]. Vitalink a été le premier coffre-fort santé doté d'un Schéma de médication partagé partagé multidisciplinaire[15]. Le Vitalink d'origine date de 2011 et était destiné à la première ligne ; la plate-forme FHIR renouvelée est conçue pour la communication transmurale et l'échange au sein de l'EHDS[16].
\nVitalink n'a pas d'écran propre. Les prestataires de soins l'utilisent depuis leur logiciel professionnel[2], les citoyens via des canaux comme Masanté[17]. L'accès passe par la plate-forme eHealth, qui héberge les composants de Vitalink 1.0[18], et suppose un consentement éclairé et une Relation thérapeutique.
" }, { "id": "quels-services", "title": "Quels services ?", "kind": "tekst", "html": "| Service | \nQuoi | \nEnvironnement | \nPage | \n
|---|---|---|---|
| Schéma de médication | \nschéma partagé de la médication actuelle[19] | \nKMEHR, cookbook 5.8[4] ; aucune ressource de médication en FHIR au 27/10/2026[6] | \nSchéma de médication partagé | \n
| Sumehr | \ndossier résumé du médecin généraliste[19] | \nKMEHR, cookbook 6.0[3][4] | \nSumehr | \n
| Vaccinations | \ndonnées de vaccination, également issues de Vaccinnet[20][21] | \nFHIR depuis le 15/01/2026[5] | \nVaccinnet | \n
| Dépistages du cancer | \nsuivi des dépistages organisés[19] | \nFHIR depuis le 15/11/2024, exclusivement FHIR depuis le 1/7/2025[22][23] | \nDépistage organisé et prévention : systèmes numériques et échanges | \n
| Dossier de l'enfant | \nKindrapport de Kind en Gezin[19] | \nKMEHR, cookbook 3.1 ; FHIR prévu fin 2026[4][5] | \n\n |
| Éléments de journal | \nbrèves notes entre prestataires de soins[19] | \nKMEHR, cookbook 3.1[3][4] | \n\n |
| Données de grossesse | \njeu de données minimal dans un projet[24] | \nFHIR ; projet Pregnancy Status prévu dans la release 2026.11 (acceptation 28/10, production 11/11/2026)[7] ; production non confirmée | \neBirth (notification électronique de naissance) | \n
| Caractéristique | \nVitalink 1.0 (KMEHR) | \nVitalink 2.0 (FHIR) | \n
|---|---|---|
| Statut | \nutilisé, accès par liste blanche[3] ; major releases prévues les 8/11 et 6/12/2026[8] | \nen production depuis le 22 mars 2024[25] ; socle présent, fonctions en cours d'extension[5] | \n
| Données | \nschéma de médication, Sumehr, Kindrapport, éléments de journal[3][4] | \ntreize types de ressources, sans ressource de médication[6] ; dépistages[22], vaccinations, Kindrapporten prévus[5] ; principalement les immunisations[10] | \n
| Sécurité | \ndouble chiffrement[5] | \npseudonymisation via la plate-forme eHealth[25][5] ; les deux sources décrivent la portée différemment (voir Incertitudes) | \n
| Technique | \nKMEHR, comme les hubs et les autres coffres-forts[26] | \nREST, I.AM Connect[25] | \n
| Interrégional | \ncoffres-forts interconnectés[18] | \nen développement au début de 2026[5] ; intervault prévu à partir du 16/4/2026[27], en septembre 2026 une officine ne voyait que son propre coffre-fort[28], ce qui indique un échange pas encore opérationnel (déduction) | \n
Les autorités, les prestataires de soins et l'industrie ont décidé de remplacer progressivement les types de données KMEHR par des CareSets FHIR[29]. En mars 2024, Vitalink a annoncé les CareSets interfédéraux AllergyIntolerance, Problem, Risks, Treatment et PatientWill, qui remplaceront le Sumehr[25] ; en pratique, les immunisations sont arrivées les premières[30]. La pseudonymisation remplace le double chiffrement, mais les deux sources officielles en décrivent la portée différemment. Le message de Vitalink du 22 mars 2024 relatif à la mise en service de l'environnement FHIR indique que toutes les données à caractère personnel y sont pseudonymisées, de sorte que les données de soins conservées ne sont pas rattachables à des personnes individuelles[25]. La réponse à la question écrite n° 327, publiée le 2 mars 2026, le décrit autrement : le numéro de registre national est remplacé par un pseudonyme tandis que les données de santé restent lisibles[5], seuls le prestataire de soins et le citoyen peuvent ramener ce pseudonyme au numéro de registre national[5], et c'est précisément ce qui rend possible l'utilisation secondaire des données, dont le population health management[5]. Aucune des deux sources ne développe quels champs sont pseudonymisés ni sur quelle base repose cette utilisation secondaire. La migration progresse par type de données et non selon un objectif final publié : au 27 octobre 2026, la page de documentation KMEHR donnait encore une version de cookbook actuelle par type de données, sans mention d'abandon ni renvoi à un successeur FHIR du schéma de médication[4]. Voir Guides d'implémentation FHIR belges pour les profils et Migration de Vitalink vers FHIR (de KMEHR vers Vitalink 2.0) pour les releases.
\nLes logiciels s'intègrent au moyen de deux parcours documentaires parallèles, un par environnement[2], avec une major release par trimestre[2]. Pour l'environnement KMEHR, une demande d'inscription sur liste blanche est nécessaire[3] et le logiciel parcourt une procédure d'accès[2] ; les conditions d'accès (sécurité de l'information, interopérabilité, confidentialité, intégrité) figurent dans une convention écrite avec le département[31], voir Homologation des logiciels pour Vitalink FHIR. Depuis avril 2026, l'en-tête Vitalink-Software-Identifier est obligatoire pour toutes les requêtes M2M, sauf pour les hubs[32]. Pour l'environnement FHIR, un onboarding auprès de Vitalink est nécessaire pour publier ou lire des données de vaccination ; la procédure d'onboarding v2.1 de mars 2026 s'applique expressément aux seuls clients logiciels[33] et prescrit, lors de l'enregistrement de chaque client, les scopes web-origins, profile, iam:authz, basic et pseudo:api:pseudonymize[33].
\nPour Vitalink 2.0, la ministre a annoncé une évaluation de l'interopérabilité dans laquelle les fournisseurs testent de manière autonome[5] ; la liste Vitalink des progiciels ayant parcouru toutes les étapes du processus d'accès pour FHIR[10][9] compte sept progiciels pour les médecins généralistes, tous dotés de la fonction « Immunisaties »[10], et était, au 27 octobre 2026, inchangée par rapport au 8 octobre[9]. Pour accéder à l'environnement de production, un test d'interopérabilité est obligatoire par type de données, en lecture et en écriture ; auparavant, cela ne valait que pour le schéma de médication[34]. Ce test est autre chose que l'homologation : celle-ci est un système d'évaluation de la plate-forme eHealth sur lequel l'INAMI se fonde pour d'éventuelles primes télématiques et qui, selon Vitalink, n'intervient pas dans le processus d'admission propre à Vitalink[34] ; l'en-tête du tableau de la liste Vitalink qualifie bien les progiciels de « gehomologeerd voor Vitalink FHIR » alors que l'introduction de la même page parle de progiciels ayant parcouru le processus d'accès pour FHIR[9], ce qui, sur cette page, correspond à la seconde signification ; RAMIT réalise les tests du schéma de médication pour les progiciels suivant un parcours d'homologation et l'Imec InteropLab les tests pour les autres types de données[34], et Vitalink accepte les tests de RAMIT, la plate-forme eHealth ceux de l'InteropLab[34]. Dans le cycle d'enregistrement VIDIS 2023-2026, Vitalink organise en outre son propre cycle d'audit, parallèlement à la période de test de l'INAMI[11]. Voir Homologation des logiciels pour Vitalink FHIR.
\nSelon le cookbook 1.17, un progiciel doit être onboardé auprès de la plate-forme eHealth pour pseudonymiser avec le service pseudo[35], les jetons dotés de scopes tels que pseudo:profile, pseudo:api:pseudonymize, pseudo:api:identify et pseudo:api:convert sont bloqués par Vitalink[35], et aucun jeton ayant Vitalink comme audience explicite n'est encore possible pour les intégrations dans le realm M2M[35]. La release 2026.11 rend l'en-tête Intervault-Enduser-HcPartyType obligatoire (planification : production à partir du 11/11/2026)[36]. L'ancien connecteur Vitalink, par lequel des sources authentiques telles que Vaccinnet, le Centrum voor Kankeropsporing et Opgroeien communiquaient directement[18], n'est plus proposé aux nouveaux partenaires[18].
" }, { "id": "ou-en-est-on-qui-est-oblige", "title": "Où en est-on, qui est obligé ?", "kind": "tekst", "html": "Le Departement Zorg est responsable du traitement[1] ; lors d'un échange, le département et le destinataire sont responsables conjoints du traitement (art. 26 RGPD)[1], avec des accords écrits[1]. L'arrêté d'exécution du 20 octobre 2023 (en vigueur le 26/11/2023) désigne le département pour les missions prévues à l'article 3 du décret[31]. Le département vérifie préalablement l'identité, la qualité et le consentement[31] ; si un hub agréé demande des données, c'est le hub qui effectue lui-même ces vérifications[31], pour le consentement sur la base d'une délégation inscrite dans une convention avec le département[31].
\nLe comité de concertation Vitalink (arrêté du Gouvernement flamand du 18 janvier 2019) se compose de dix représentants des acteurs des soins, de trois représentants des usagers de soins, de cinq représentants des partenaires stratégiques, de six représentants de l'administration et de deux représentants des producteurs de logiciels[37], agit comme groupe de pilotage[37] et crée le Comité voor Sleutelbeheerders, qui gère une des deux clés de déchiffrement de Vitalink 1.0[37]. Tant que ce comité fonctionne au sein de VASGAZ, le décret ne prévoit pas d'organe d'administration distinct[1] ; le décret VASGAZ date de 2014[38]. La note de politique 2024-2029 annonce la suppression de VASGAZ, sans nouvelle structure[39], mais dans les réponses aux questions écrites n° 748 du 30 mars 2026 et n° 1077 du 18 juin 2026, la ministre traitait encore VASGAZ comme une entité du domaine politique[40][41]. La composition actuelle des deux comités n'a pas été trouvée.
\nDans Vitalink 1.0, les composants sont hébergés chez la plate-forme eHealth, à l'exception du décrypteur 2[18], qui se trouve chez un partenaire privé sous le contrôle de VASGAZ[18] ; la release KMEHR de juin 2026 comportait encore des interventions sur « Decryptor2 Arxus »[42]. Les trois coffres-forts santé de première ligne (Vitalink, RSW, Réseau Santé Bruxellois) sont reliés entre eux dans Vitalink 1.0, de sorte que le schéma de médication et le Sumehr suivent lors d'un déménagement vers une autre région[18] ; les deux cookbooks KMEHR « operations » et « medicatieschema » valent pour les trois coffres-forts ensemble[4].
\n| Utilisateur | \nAccès et obligation | \n
|---|---|
| Organisations de soins | \naccès après agrément, enregistrement Cobrha, certificat eHealth et Circle of Trust[3] ; le COT compte 13 critères, approuvés par le Comité de gestion et le Comité de sécurité de l'information[43] | \n
| Vaccinateurs, y compris les hôpitaux | \nenregistrer les vaccinations du schéma flamand[44], via un progiciel prenant en charge l'échange avec Vitalink ou, à défaut, via l'application web Vaccinnet[10] ; celles-ci aboutissent aussi dans Vitalink[21] | \n
| Médecins généralistes | \nsept progiciels FHIR pour les immunisations sur la liste Vitalink[10] | \n
| Hôpitaux | \ndébut 2025, uniquement la consultation[16] ; la liste FHIR comporte quatre progiciels hospitaliers, chacun uniquement pour les immunisations — Workflower[10], HiX, PrimUZ et CWS[45], et la liste était inchangée au 27/10/2026[9][10] ; une mention sur la liste Vitalink n'équivaut pas à un déploiement chez le client[10] | \n
| Hubs | \nliste blanche et en-tête Vitalink-Enduser-Info depuis mars 2026[46] ; droits de hub avec délai d'expiration depuis août 2026[47] | \n
| Médecins du travail | \nselon la ministre, l'absence d'accès à Vitalink constitue un obstacle pour le suivi des dépistages organisés du cancer (QE 935 du 22 mai 2026)[48] ; la liste Vitalink mentionne toutefois trois progiciels pour les services de médecine du travail, chacun avec les immunisations[9] | \n
| Citoyens | \nlecture via Masanté[17] | \n
Toute personne qui a des données dans Vitalink figure aussi dans la métahub[18]. CoZo est intégré à Vitalink depuis janvier 2015[49] et peut demander des schémas de médication et des Sumehrs[50]. Cette image est incomplète : depuis le 1er juillet 2025, les dépistages ne sont pas consultables via CoZo et les autres hubs[12], parce que cet échange passe encore par KMEHR alors que le CvKO livre en FHIR[51] ; depuis le 15 janvier 2026, cela vaut aussi pour les vaccinations[13]. Selon CoZo, le Departement Zorg a décidé unilatéralement d'arrêter ce flux[13] ; CoZo s'attendait à un rétablissement au Q2 2026[13].
\nAu 27 octobre 2026, ce rétablissement n'est ni constaté ni annoncé : le message de CoZo du 15 janvier 2026 est toujours en ligne, inchangé, avec la même attente pour un trimestre entre-temps écoulé[13] ; l'aperçu des actualités de CoZo ne contient aucun message de rétablissement[14] et l'actualité la plus récente de Vitalink date du 12 juin 2026[23]. Le rétablissement attendu au Q2 2026 a ainsi plus de quatre mois de retard[13]. L'interruption ne concerne toutefois que ces deux types de données : la page de statut de CoZo signale dans son historique une panne du 16 octobre 2026 pendant laquelle des données de Vitalink n'étaient pas disponibles[52], ce qui confirme que d'autres flux Vitalink passent par CoZo (déduction). Pour FHIR, Vitalink a construit une route interhub : le protocole est passé en acceptation au début de 2026[53], les composants sont en production depuis mars 2026, mais l'utilisation par un hub n'est pas confirmée[46].
\nSelon la ministre, tous les hôpitaux avaient accès à Vitalink KMEHR au début de 2025, même si ce flux passait parfois par un détour via la métahub[16] et que la qualité des données était parfois insuffisante[16]. En cas de panne sur les deux zones de l'infrastructure eHealth, CoZo, RSW, Abrumet, BruSafe et Intermed continuent de fonctionner, mais pas Vitalink[54], parce que Vitalink n'a pas intégré la procédure d'urgence[54] — le tout sous la réserve que la page de statut formule elle-même[54]. En cas d'interruption des seuls services de base, la procédure d'urgence existe précisément pour maintenir consultables les documents du système Hub&Metahub[54].
" }, { "id": "planification", "title": "Planification", "kind": "tekst", "html": "| Quand | \nQuoi | \nNature | \n
|---|---|---|
| 2011 | \nVitalink d'origine[16] | \nhistorique | \n
| 1/1/2023 | \ndécret en vigueur[1] ; arrêté d'exécution 26/11/2023[31] | \nréglementation | \n
| 22/3/2024 | \nenvironnement FHIR en production[25] | \nréalisé | \n
| 15/11/2024 → 1/7/2025 | \ndépistages en FHIR, après six mois de transition uniquement FHIR[22][23] | \nréalisé | \n
| 15/1/2026 | \nvaccinations dans Vitalink 2.0[5][55] ; fin de l'accès KMEHR pour les vaccinations prévue le même jour[56] | \nréalisé / planification | \n
| 3/2026 | \ncomposants interhub en production[46] | \nréalisé | \n
| 16/4/2026 | \nintervault entre les coffres-forts FHIR[27] | \nplanification ; en septembre 2026, une officine ne voyait que son propre coffre-fort[28], ce qui indique une date non tenue (déduction) | \n
| 15/7/2026 | \nCareSet Medication dans les coffres-forts régionaux (feuille de route EHDS)[57] | \nplanification, non confirmée ; aucune ressource de médication sur le serveur[6] | \n
| 6/2026, 8/2026 | \nreleases KMEHR[42][58] | \nréalisé | \n
| 21/10/2026 | \nrelease 2026.10 : guides d'implémentation public-health 1.0.4, allergy 1.2.1 et core 2.2.0[59] | \npartiellement réalisé : le serveur déclare 1.0.4 et 1.2.1, mais encore BE Core 2.1.2[6] | \n
| 28/10 → 11/11/2026 | \nrelease 2026.11 (acceptation → production) : projet Pregnancy Status, en-tête Intervault-Enduser-HcPartyType obligatoire, dépréciation de public-health 1.0.3 et allergy 1.2.0 pour create/update[7][36] | \nplanification | \n
| 8/11 et 6/12/2026 | \nmajor releases de l'environnement KMEHR[8] | \nplanification | \n
| fin 2026 | \nKindrapporten en FHIR[5] | \nplanification | \n
| 2027 | \nVIDIS : gestion du changement, cycles d'audit et transition vers un fonctionnement courant, sans date pour un schéma de médication FHIR chez les coffres-forts[60] | \nplanification | \n
| à partir de 2028 | \nnouveaux échanges via FHIR, KMEHR en lecture seule (BIHR)[61] | \nplanification | \n
La note de politique 2024-2029 donne la priorité à un jeu de données de base conforme à l'EU Patient Summary, au transfert de médication et aux soins de santé mentale[39]. Aucune date générale d'abandon de l'environnement KMEHR n'a été trouvée[8] ; au contraire, le calendrier des releases y prévoit encore des major releases pour novembre et décembre 2026[8]. Dans le programme périnatal, les DMI et les DPI transmettent déjà des données à Vitalink[24].
\nBIHR et VIDIS. Au sein du BIHR, les coffres-forts régionaux sont des sources authentiques centralisées[61] et les CareSets sont stockés dans Vitalink et dans les coffres-forts bruxellois et wallon[16] : Vitalink n'est pas remplacé, il conserve des composants du BIHR. À la mi-2026, Vitalink travaillait à la prise en compte de la pseudonymisation pour le routage vers le bon coffre-fort[62] ; l'échange entre les coffres-forts serait réglé par l'accord de coopération eHealth/BelRAI[63], pas encore finalisé en mars 2026[63]. Pour la médication, VIDIS remplace à terme le schéma de médication de Vitalink selon la ministre[16], tandis que, selon l'INAMI, il s'appuie sur le schéma de médication partagé[64] et accompagne les coffres-forts dans la mise en œuvre de FHIR[64]. La phase 1 de VIDIS visualise le schéma via ProSanté[64], mais pas pour les prestataires de soins travaillant dans une institution[65] ; depuis août 2026, un trajet de test FHIR relatif aux lignes de médication est en cours[66], et la planification de l'INAMI pour 2027 mentionne bien des cycles d'audit mais aucune date pour un schéma de médication en FHIR chez les coffres-forts[60].
" }, { "id": "qu-est-ce-que-cela-signifie-pour-un-hopital", "title": "Qu'est-ce que cela signifie pour un hôpital ?", "kind": "tekst", "html": "Les déductions tirées des métadonnées du serveur et des release notes sont enregistrées comme interprétation ; ne pas avoir trouvé n'est pas une preuve d'absence.
\n