Exigences d'implémentation SNOMED CT pour les DPI

• Quoi : un ensemble uniforme d'exigences fonctionnelles et techniques pour la mise en œuvre de SNOMED CT au sein des systèmes d'information de santé, version 1.0 du 25 septembre 2026^[1][1].

• Pour qui : les logiciels de médecine générale et les DPI hospitaliers, considérés comme un tout avec leurs composants terminologiques, leur middleware et leurs modules de tiers^[1].

• Comment : le DPI offre des services de terminologie FHIR sur SNOMED CT, limite la recherche aux concepts que la liaison terminologique d'un champ de données autorise, et stocke le concept ID ; un Description ID ou du texte libre en remplacement est considéré comme une erreur critique^[1][1][1].

• État : le Terminology Portal a publié le PDF le 19/10/2026 ; le chapitre des exigences cliniques est encore vide dans la version 1.0 et prévu pour une version 2 en décembre 2026^[2][1].

• Planning : la feuille de calcul de la roadmap planifie le serveur de terminologie local au Q4/26, la liste de problèmes codée au Q2/27 et le Patient Summary au Q2/28, chaque fois suivis d'une période de test^[3].

• Hôpital : les exigences servent de critères pour l'enregistrement de la « snomedisation » des DPI et vérifient si une application est sémantiquement prête pour le Patient Summary transfrontalier dans le cadre de l'EHDS à partir de mars 2029^[1][1].

• Principale incertitude : le processus soumet la version définitive pour validation au Comité de gestion de la plate-forme eHealth, mais cette validation et le cadre d'enregistrement n'ont pas été trouvés^[1].

Le « Requirements Specification Document SNOMED_CT Implementation » est une spécification du Centre de Terminologie du SPF Santé publique, le National Release Center (NRC) belge pour SNOMED CT, en version 1.0 du 25 septembre 2026^[1][4]. Il vise à établir un ensemble uniforme d'exigences fonctionnelles et techniques pour la mise en œuvre de SNOMED CT au sein des systèmes d'information de santé, comme cadre de référence pour les organismes de santé, les éditeurs de logiciels et les autres parties prenantes^[1]. Un dossier patient informatisé (DPI) qui satisfait aux exigences est dit « snomedisé » dans le document : les exigences constituent la base permettant d'évaluer la maturité et la conformité d'une mise en œuvre et servent de critères objectifs pour l'enregistrement de cette snomedisation^[1].

Selon le document, une évaluation de conformité poursuit deux objectifs : l'enregistrement de la mise en œuvre de SNOMED CT de l'application auprès des autorités belges compétentes^[1], et la confirmation que l'application est sémantiquement prête pour l'échange transfrontalier de données du Patient Summary que le règlement EHDS exige à partir de mars 2029^[1].

Pourquoi SNOMED CT comme seul codage primaire

Le document part d'un choix politique : SNOMED CT a été désigné comme terminologie de référence pour le secteur des soins de santé, et les autres systèmes de codage ne sont pas maintenus en tant qu'alternatives ayant la même valeur normative, mais sont dérivés de SNOMED CT par le biais d'un mappage^[1]. Un modèle hybride, avec un système de codage principal différent par domaine, a été envisagé puis écarté^[1]. Les classifications existantes pour le reporting et le remboursement subsistent, mais comme sortie mappée du dossier codé en SNOMED CT plutôt que comme saisie manuelle distincte^[1].

Cela n'exclut pas une liste de saisie propre. Une terminologie d'interface est une liste de termes qu'un DPI présente à l'utilisateur pour enregistrer rapidement ; une telle liste propre peut continuer à piloter la saisie et l'affichage, à condition que le concept ID SNOMED CT soit conservé et reste l'enregistrement qui fait autorité^[1]. Les terminologies d'interface restent ainsi une aide à la saisie ou une sortie dérivée, liée à un concept ID, et non une norme primaire concurrente^[1].

Trois notions reviennent dans toutes les exigences. Le concept ID est le code numérique d'un concept SNOMED CT ; un Description ID identifie un terme (description) de ce concept dans une langue. Une liaison terminologique (terminology binding) fixe quels concepts un champ de données déterminé d'un modèle d'information peut contenir. Selon le document, une exigence qui n'est pas spécifiée conjointement avec le modèle d'information, la liaison terminologique et les services de terminologie ne peut pas être évaluée objectivement^[1].

De vereisten zijn gegroepeerd onder vier doelstellingen: terminologiediensten en -voorziening, gegevensinvoer, opslag en interoperabiliteit^[1]. In de tabel staat 'shall' voor een verplichte en 'should' voor een aanbevolen vereiste, zoals bij ECL^[1]; de codes TSP, U, S en I volgen de vier doelstellingen.

De technische vereisten vragen dus een terminologieserver in of naast het EPD die met FHIR-operaties werkt; hoe SNOMED CT in FHIR gecodeerd en bevraagd wordt, staat op SNOMED CT in FHIR (URI's, impliciete waardesets en operaties) en de taal voor conceptverzamelingen op SNOMED CT Expression Constraint Language (ECL)^[1][1]. De refsets en hun binding aan FHIR-ValueSets staan op Ensembles de référence SNOMED CT belges (refsets)^[1].

Scope: de Patient Summary-velden

De bindingen waarnaar het document verwijst, zitten in de CareSets en de daarvan afgeleide Belgische FHIR-profielen voor probleemlijst, observaties, allergie en intolerantie, vaccinatie en verrichtingen, binnen de scope van de Patient Summary (lezing van de tabel in sectie 2.1)^[1]. Die profielen staan in de Belgische FHIR-implementatiegidsen.

Beheer, versies en status

Volgens het beschreven governanceproces werkt het NRC de vereisten in een co-creatiefase uit met de EPD-leveranciers voor huisartsen en voor ziekenhuizen^[1]. Dat volgt op een aankondiging van juni 2026: na de FHIR-A-THON van 2-3 juni zouden nog overlegmomenten met de grote EPD-leveranciers volgen om de 'implementation requirements' te overlopen, zodat ze toen nog niet definitief waren^[5]. Het implementatieprogramma van het Terminologiecentrum verzamelde daarvoor feedback van EPD-leveranciers die moest uitmonden in geconsolideerde vereisten^[6]. De definitieve versie wordt volgens het proces ter formele validatie voorgelegd aan het eHealth-platform, in het bijzonder het Beheerscomité^[1].

Het Terminology Portal publiceerde de PDF 'SCT Implementation Requirements eHR_V1.0 - 092026', gedateerd 19/10/2026^[2]. Daarnaast verzamelt een publieke GitHub-repository vragen, implementatieproblemen, verbetervoorstellen en feedback over de implementatie van SNOMED CT in België^[7]. In die repository staat een roadmapwerkblad dat elke vereiste ook koppelt aan de Ierse vereisten, bijvoorbeeld U02 aan de Ierse vereiste SCT-017 over zoeken op Concept ID en Description ID^[3]. Werkblad en document lopen niet overal gelijk: het werkblad beschrijft U05 als invoer via vrije tekst, het document als een tijdelijke of containercode^[3].

Les exigences techniques s'appliquent aux systèmes de DPI dans les soins directs aux patients, aux logiciels de médecine générale et aux DPI hospitaliers, ainsi qu'au DPI dans son ensemble, y compris les composants terminologiques, le middleware ou les modules de tiers^[1]. Elles sont destinées à l'enregistrement de la mise en œuvre de SNOMED CT d'une application auprès des autorités belges compétentes^[1]. La roadmap d'implémentation que le SPF a présentée en août 2026 planifiait l'enregistrement et la certification de 2026 à 2028 (lecture d'un graphique chronologique)^[8]. Quelle autorité enregistre, en vertu de quelle réglementation, et quels DPI ont déjà été évalués n'a pas été trouvé ; la question de savoir si l'enregistrement SNOMED CT est légalement obligatoire est traitée sur Obligation ou planification ? Base légale pour SNOMED CT, CareSets et FHIR.

Une licence est une condition préalable à toute implémentation : quiconque développe ou distribue des produits contenant SNOMED CT doit être Affiliate de SNOMED International ; voir Licence SNOMED CT et affichage public^[9].

Toutes les dates ci-dessous relèvent de la planification, non de faits établis.

Le phasage de la feuille de calcul (version 1, septembre 2026) est une lecture des colonnes par exigence^[3]. Il correspond en grande partie à la roadmap d'août 2026, qui situait la liste de problèmes codée vers le Q3 2027 et le codage des procédures, des observations, de l'allergie et de la vaccination vers le Q3 2028^[8]. Une figure chronologique antérieure de mars 2026 situait la publication des exigences pour les DPI vers le Q3 2026 (lecture visuelle)^[10] ; la publication a suivi le 19/10/2026^[2].

Les DPI hospitaliers entrent expressément dans le périmètre, et ce pour le DPI dans son ensemble : un composant terminologique ou un module d'un tiers compte aussi^[1]. Ce que les exigences demandent d'un DPI relève donc en premier lieu du travail du fournisseur : un serveur de terminologie avec des opérations FHIR, une recherche limitée à la liaison de chaque champ et le stockage du concept ID^[1][1][1]. Pour l'utilisateur, une liste de saisie familière peut subsister, pour autant que le concept ID soit conservé derrière chaque choix^[1].

Pour le codage et le reporting, le travail se déplace : les classifications pour le reporting et le remboursement deviennent une sortie mappée du dossier codé^[1]. L'exigence S05 mentionne ICD-10 et pas expressément ICD-10-BE, et ne vaut que pour les maps qui font partie de l'édition belge ou sont officiellement disponibles^[1].

Quant à l'obligation : les exigences sont des critères d'enregistrement^[1], mais aucune réglementation liant cet enregistrement à une obligation ou à un financement n'a été trouvée. La distinction entre obligation, condition de financement et planification figure sur Obligation ou planification ? Base légale pour SNOMED CT, CareSets et FHIR.

Recommandation : demandez à un fournisseur de DPI, pour chaque exigence du tableau, quelle phase de la feuille de calcul il suit, et vérifiez si le dossier conserve déjà aujourd'hui le concept ID ou seulement un terme ou un code propre ; cette question est utile pour la planification EHDS, même sans cadre d'enregistrement.

• Validation : le processus soumet la version définitive pour validation au Comité de gestion^[1] ; aucune décision de validation pour la version 1.0 n'a été trouvée.

• Cadre d'enregistrement : le document parle d'un enregistrement auprès des autorités belges compétentes^[1], sans qu'une réglementation ou un registre à cet effet ait été trouvé.

• U05 dans le document et la feuille de calcul : le document demande un code conteneur qui ne peut pas ressembler à un code SNOMED CT^[1], la feuille de calcul parle de texte libre^[3] ; ce point figure dans le registre des contradictions.

• Incomplet : les exigences cliniques manquent dans la version 1.0 et sont prévues pour décembre 2026^[1].

• Maps : S05 dépend de maps qui doivent être disponibles^[1] ; une map officielle vers ICD-10-BE n'a pas été trouvée.

• ECL : la prise en charge d'ECL est un « should », pas un « shall »^[1].

• Planning : les trimestres de la feuille de calcul sont une lecture de colonnes, pas une décision^[3].