Dit vereistendocument van het Terminologiecentrum legt vast hoe een elektronisch patiëntendossier (EPD) SNOMED CT moet inbouwen. Het geldt voor huisartsenpakketten en ziekenhuis-EPD's en vraagt onder meer FHIR-terminologiediensten in het EPD, zoeken binnen de toegelaten concepten van elk gegevensveld, opslag van de concept-ID en uitwisseling via FHIR. Versie 1.0 bevat de technische vereisten; de klinische vereisten zijn gepland voor een versie 2. De vereisten dienen als criteria voor de registratie van de 'snomedisering' van EPD's, en een werkblad plant de invoering in fasen tot 2028.
", "last_verified": "2026-11-05", "verification_outdated": false, "sections": [ { "id": "in-het-kort", "title": "In het kort", "kind": "in-het-kort", "html": "Het 'Requirements Specification Document SNOMED_CT Implementation' is een specificatie van het Terminologiecentrum van de FOD Volksgezondheid, het Belgische National Release Center (NRC) voor SNOMED CT, in versie 1.0 van 25 september 2026[1][4]. Het wil een uniforme set functionele en technische vereisten vastleggen voor de implementatie van SNOMED CT in zorginformatiesystemen, als referentiekader voor zorgorganisaties, softwareleveranciers en andere belanghebbenden[1]. Een elektronisch patiëntendossier (EPD) dat aan de vereisten voldoet, heet in het document 'gesnomediseerd': de vereisten zijn de basis om de maturiteit en conformiteit van een implementatie te beoordelen en dienen als objectieve criteria voor de registratie van die snomedisering[1].
\nEen conforme beoordeling heeft volgens het document twee doelen: de registratie van de SNOMED CT-implementatie van de toepassing bij de bevoegde Belgische overheden[1], en de bevestiging dat de toepassing semantisch klaar is voor de grensoverschrijdende uitwisseling van Patient Summary-gegevens die de EHDS-verordening vanaf maart 2029 vereist[1].
\nHet document vertrekt van een beleidskeuze: SNOMED CT is aangewezen als referentieterminologie voor de zorgsector, en andere codesystemen worden niet als gelijkwaardige alternatieven onderhouden maar via mapping uit SNOMED CT afgeleid[1]. Een hybride model met per domein een ander primair codesysteem werd overwogen en verworpen[1]. Bestaande classificaties voor rapportering en terugbetaling blijven bestaan, maar als gemapte uitvoer van het in SNOMED CT gecodeerde dossier in plaats van als afzonderlijke manuele invoer[1].
\nDat sluit een eigen invoerlijst niet uit. Een interfaceterminologie is een lijst van termen die een EPD aan de gebruiker toont om snel te registreren; zo'n eigen lijst mag de invoer en weergave blijven sturen, op voorwaarde dat de SNOMED CT-concept-ID bewaard wordt en de gezaghebbende registratie blijft[1]. Interfaceterminologieën blijven zo invoerhulp of afgeleide uitvoer, gebonden aan een concept-ID, en geen concurrerende primaire standaard[1].
\nDrie begrippen keren in alle vereisten terug. De concept-ID is de numerieke code van een SNOMED CT-concept; een Description ID identificeert één term (beschrijving) van dat concept in één taal. Een terminologiebinding legt vast welke concepten een bepaald gegevensveld in een informatiemodel mag bevatten. Het document stelt dat een vereiste die niet samen met het informatiemodel, de terminologiebinding en de terminologiediensten is gespecificeerd, niet objectief beoordeeld kan worden[1].
" }, { "id": "hoe-is-het-opgebouwd", "title": "Hoe is het opgebouwd?", "kind": "tekst", "html": "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.
\n| Code | \nWat het EPD moet of zou moeten | \nSterkte | \nBewijs | \n
|---|---|---|---|
| TSP1 | \nTerminologiediensten volgens de HL7 FHIR Terminology Service-specificatie op het SNOMED CT-codesysteem, met minstens $lookup, $validate-code en $expand (lezing van de opsomming) | \nshall | \n[1] | \n
| TSP1 | \nDie diensten werken op de refsets voor problemen, observaties, allergie en intolerantie, vaccinatie en verrichtingen (lezing van de opsomming) | \nshall | \n[1] | \n
| TSP2 | \nExpression Constraint Language (ECL) als standaardmechanisme om conceptverzamelingen te definiëren | \nshould | \n[1] | \n
| TSP3 | \nDe recentste Belgische editie inladen in een van de omgevingen; de syndicatiefeed van de nationale terminologieserver mag daarvoor dienen | \nshall | \n[1] | \n
| Voorziening | \nNiet elke maandelijkse release hoeft in productie, maar de gebruikte versie blijft binnen de toegestane versieachterstand | \nshall | \n[1] | \n
| TSP6 | \nSNOMED CT-inhoud tonen in de juiste taal via de language refsets van de Belgische editie (Nederlands, Frans, Duits) | \nshall | \n[1] | \n
| U01 | \nZoekresultaat voor minstens 95% van de zoekopdrachten binnen 1 seconde | \nshall | \n[1] | \n
| U04 | \nZoeken en selecteren beperken tot de concepten die de terminologiebinding van het gegevenselement toelaat | \nshall | \n[1] | \n
| Invoer | \nBinding, refset of subset van de klinische context gebruiken om zoekresultaten voorrang te geven of te beperken | \nshall | \n[1] | \n
| U05 | \nEen tijdelijke of containercode voor een niet gevonden concept is duidelijk te onderscheiden van SNOMED CT-gecodeerde gegevens en draagt geen concept-ID of placeholder | \nshall | \n[1] | \n
| S01 | \nGeen Description ID of vrije tekst bewaren als vervanging van de concept-ID; dat is een kritieke fout | \nshall | \n[1] | \n
| S05 | \nMaps van SNOMED CT naar ICD-10, ICPC-2, ICHI, de RIZIV-nomenclatuur, LOINC en Orphanet kunnen gebruiken, voor zover ze deel uitmaken van de Belgische editie of officieel voor Belgisch gebruik beschikbaar zijn (lezing van de opsomming) | \nshall | \n[1] | \n
| I01 | \nSNOMED CT-gecodeerde gegevens delen via de nationale uitwisselingsstandaard FHIR | \nshall | \n[1] | \n
| Hoofdstuk 3 | \nKlinische vereisten (klinische workstream, business rules): nog niet ingevuld, voorzien voor versie 2 in december 2026 | \ngepland | \n[1] | \n
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 Belgische SNOMED CT-referentiesets (refsets)[1].
\nDe 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.
\nVolgens 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].
\nHet 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].
" }, { "id": "waar-wordt-het-gebruikt", "title": "Waar wordt het gebruikt?", "kind": "tekst", "html": "De technische vereisten gelden voor EPD-systemen in de directe patiëntenzorg, huisartsenpakketten en ziekenhuis-EPD's, en voor het EPD als geheel, inclusief terminologiecomponenten, middleware of modules van derden[1]. Ze zijn bedoeld voor de registratie van de SNOMED CT-implementatie van een toepassing bij de bevoegde Belgische overheden[1]. De implementatieroadmap die de FOD in augustus 2026 toonde, plande registratie en certificering van 2026 tot 2028 (aflezing van een tijdlijngrafiek)[8]. Welke overheid registreert, onder welke regeling, en welke EPD's al getoetst zijn, werd niet gevonden; de vraag of SNOMED CT-registratie wettelijk verplicht is, staat op Verplichting of planning? Rechtsgrond voor SNOMED CT, CareSets en FHIR.
\nEen licentie is een voorwaarde vóór elke implementatie: wie producten met SNOMED CT ontwikkelt of verdeelt, moet Affiliate van SNOMED International zijn; zie SNOMED CT-licentie en publieke weergave[9].
" }, { "id": "planning", "title": "Planning", "kind": "tekst", "html": "Alle data hieronder zijn planning, geen vastgestelde feiten.
\n| Wanneer | \nWat | \nBewijs | \n
|---|---|---|
| december 2026 | \nVersie 2 met de klinische vereisten | \n[1] | \n
| Q4/26 (testen Q3/27) | \nFase 1: lokale terminologieserver (o.a. TSP1-TSP4) | \n[3] | \n
| Q2/27 (testen Q3/27) | \nFase 2a: gecodeerde probleemlijst | \n[3] | \n
| Q2/28 (testen Q3/28) | \nFase 2b: Patient Summary | \n[3] | \n
| maart 2029 | \nGrensoverschrijdende uitwisseling van Patient Summary-gegevens onder de EHDS | \n[1] | \n
De fasering in het werkblad (versie 1, september 2026) is een lezing van de kolommen per vereiste[3]. Ze sluit grotendeels aan bij de roadmap van augustus 2026, die de gecodeerde probleemlijst rond Q3 2027 en de codering van verrichtingen, observaties, allergie en vaccinatie rond Q3 2028 plaatste[8]. Een eerdere tijdlijnfiguur van maart 2026 plaatste de publicatie van de EPD-vereisten rond Q3 2026 (visuele lezing)[10]; de publicatie volgde op 19/10/2026[2].
" }, { "id": "wat-betekent-het-voor-een-ziekenhuis", "title": "Wat betekent het voor een ziekenhuis?", "kind": "tekst", "html": "Ziekenhuis-EPD's vallen uitdrukkelijk binnen de scope, en dan het EPD als geheel: ook een terminologiecomponent of module van een derde partij telt mee[1]. Wat de vereisten van een EPD vragen, is daarmee in de eerste plaats leverancierswerk: een terminologieserver met FHIR-operaties, zoeken binnen de binding van elk veld en opslag van de concept-ID[1][1][1]. Voor de gebruiker kan een vertrouwde invoerlijst blijven bestaan, zolang achter elke keuze de concept-ID wordt bewaard[1].
\nVoor codering en rapportering verschuift het werk: classificaties voor rapportering en terugbetaling worden een gemapte uitvoer van het gecodeerde dossier[1]. Vereiste S05 noemt ICD-10 en niet uitdrukkelijk ICD-10-BE, en geldt enkel voor maps die deel zijn van de Belgische editie of officieel beschikbaar zijn[1].
\nOver de verplichting: de vereisten zijn criteria voor registratie[1], maar een regeling die die registratie aan een verplichting of financiering koppelt, werd niet gevonden. Het onderscheid tussen verplichting, financieringsvoorwaarde en planning staat op Verplichting of planning? Rechtsgrond voor SNOMED CT, CareSets en FHIR.
\nAanbeveling: vraag een EPD-leverancier per vereiste uit de tabel welke fase van het werkblad hij volgt, en ga na of het dossier nu al de concept-ID bewaart of enkel een term of eigen code; die vraag is ook zonder registratiekader zinvol voor de EHDS-planning.
" }, { "id": "onzekerheden-en-tegenstrijdige-informatie", "title": "Onzekerheden en tegenstrijdige informatie", "kind": "tekst", "html": "