SNOMED CT-implementatievereisten voor EPD's

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].

Een 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].

Waarom SNOMED CT als enige primaire codering

Het 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].

Dat 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].

Drie 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].

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 Belgische SNOMED CT-referentiesets (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].

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.

Een 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].

Alle data hieronder zijn planning, geen vastgestelde feiten.

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].

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].

Voor 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].

Over 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.

Aanbeveling: 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.

• Validatie: het proces legt de definitieve versie ter validatie voor aan het Beheerscomité^[1]; een validatiebeslissing voor versie 1.0 werd niet gevonden.
• Registratiekader: het document spreekt van registratie bij de bevoegde Belgische overheden^[1], zonder dat een regeling of register daarvoor gevonden werd.
• U05 in document en werkblad: het document vraagt een containercode die niet als SNOMED CT-code mag lijken^[1], het werkblad spreekt van vrije tekst^[3]; dit staat in het tegenstrijdighedenregister.
• Onvolledig: de klinische vereisten ontbreken in versie 1.0 en zijn gepland voor december 2026^[1].
• Maps: S05 hangt af van maps die beschikbaar moeten zijn^[1]; een officiële map naar ICD-10-BE werd niet gevonden.
• ECL: ondersteuning van ECL is een 'should', geen 'shall'^[1].
• Planning: de kwartalen in het werkblad zijn een lezing van kolommen, geen besluit^[3].