Het structureren van de sitemap van een gezondheidsplatform is niet alleen het uitlijnen van pagina’s in een menu. De informatiearchitectuur bepaalt de circulatie van gegevens tussen professionals, patiënten en externe systemen. Met de geleidelijke invoering van de Europese verordening over de Europese gezondheidsdatadomein (EHDS) vanaf maart 2027, en de grensoverschrijdende uitwisselingen die vanaf maart 2029 zijn gepland, wordt het ontwerpen van een geschikte boomstructuur een technische en redactionele vereiste.
Interoperabiliteit en sitemap: waarom de structuur de gegevensuitwisseling bepaalt
De meeste gidsen voor het creëren van medische websites beschouwen de sitemap als een redactionele oefening. Pagina’s worden ingedeeld op specialiteit, er wordt een contactformulier toegevoegd, en dan gaat men over op het ontwerp. Deze benadering negeert een structurerende parameter: interoperabiliteit vereist een functionele organisatie van de inhoud.
Een platform dat documenten uitwisselt met Mijn gezondheidsruimte wordt beoordeeld op verschillende assen, waaronder urbanisatie, veiligheid, ethiek en GDPR-naleving. Dit betekent dat de sitemap duidelijk de openbare ruimtes (algemene informatie, presentatie van zorg), professionele accounts, patiëntenpaden en documentuitwisselingsfuncties moet onderscheiden.
Een concreet voorbeeld van deze logica toegepast op de kaart van een platform is zichtbaar op de website Irist Santé, waar de rubrieken een segmentatie op basis van type gebruiker en functie weerspiegelen in plaats van een eenvoudige redactionele hiërarchie.
Het bouwen van de sitemap rond gestructureerde gegevens (FHIR- en DICOM-standaarden) in plaats van PDF’s of eigen formulieren bereidt het platform ook voor op de verplichtingen van de EHDS. De feedback uit de praktijk verschilt over het werkelijke niveau van volwassenheid van bestaande platforms ten opzichte van deze eisen, maar de regelgevende richting is duidelijk.
MSSanté in de sitemap: een functionele rubriek, geen contactpagina
Het integreren van de beveiligde gezondheidsberichten (MSSanté) in de structuur van een platform vereist specifieke overwegingen. De recente aanbevelingen voorzien in gestandaardiseerde interfaces, het verzenden van gestructureerde gezondheidsdocumenten conform de CI-SIS, de automatische integratie van ontvangen berichten in het patiëntendossier en het gebruik van het Gezondheidsregister om de ontvangers te selecteren.
MSSanté kan niet worden gereduceerd tot een eenvoudige link in de voettekst. De sitemap zou een aparte functionele sectie voor MSSanté moeten hebben, met minimaal:
- Een ruimte voor het verzenden en ontvangen van gestructureerde documenten, toegankelijk vanuit het professionele dashboard
- Een systeem voor het selecteren van ontvangers dat is verbonden met het Gezondheidsregister, om adresseringsfouten te voorkomen
- Een automatisch archiveringssysteem dat de uitwisselingen in het bijbehorende patiëntendossier classificeert
MSSanté behandelen als een geïsoleerde bouwsteen, verborgen in een subpagina “contact”, betekent het verlies van traceerbaarheid van de uitwisselingen en het bemoeilijken van de coördinatie van zorg tussen professionals.
Toegankelijkheid RGAA en informatiearchitectuur in de gezondheidszorg
Een gezondheidsplatform richt zich op gebruikers wiens capaciteiten aanzienlijk variëren: ouderen, patiënten met een handicap, zorgverleners die niet goed bekend zijn met digitale technologie. Het Algemeen Referentiekader voor Toegankelijkheid (RGAA) stelt criteria die rechtstreeks invloed hebben op de structuur van de sitemap.
Toegankelijkheid begint al bij de hiërarchie van de pagina’s, niet pas bij de uiteindelijke audit. Een te diep navigatiemenu (meer dan drie niveaus) benadeelt gebruikers van schermlezers. Onduidelijke rubriektitels (“Mijn diensten”, “Mijn ruimte”) bemoeilijken de navigatie voor mensen met cognitieve stoornissen.
De verplichtingen variëren afhankelijk van de grootte van de organisatie en de status, maar platforms die gezondheidsgegevens verwerken, zijn onderworpen aan een hoog niveau van eisen. Verschillende punten verdienen bijzondere aandacht bij het ontwerpen van de sitemap:
- Elke pagina moet een unieke en beschrijvende titel hebben, leesbaar buiten de context door een ondersteunende technologie
- Patiëntenpaden (afspraak maken, resultaten bekijken, berichten) moeten bereikbaar zijn met een beperkt aantal klikken vanaf de homepage
- Downloadbare documenten (recepten, verslagen) verdienen het om in een specifieke sectie te worden gegroepeerd in plaats van verspreid over verschillende rubrieken
Deze beperkingen al in de ontwerpfase van de sitemap in overweging nemen, voorkomt kostbare herontwerpen zodra het platform in productie is.
Gestructureerde gegevens en FHIR-standaarden: wat de sitemap moet anticiperen
De EHDS-verordening duwt gezondheidsplatforms naar een model waarin gegevens standaard herbruikbaar en interoperabel zijn. Dit betreft niet alleen interne databases: de sitemap zelf moet deze logica weerspiegelen.
Inhoud organiseren rond FHIR-resources (Fast Healthcare Interoperability Resources) betekent bijvoorbeeld dat de rubriek “Patiëntendossier” niet alleen gescande PDF’s bevat. Het moet gestructureerde gegevens bevatten die door andere geautoriseerde systemen kunnen worden geraadpleegd. De sitemap moet daarom stabiele URL’s voorzien voor elk type resource, in plaats van dynamische paden die bij elke software-update veranderen.
Een stabiele URL per type resource vergemakkelijkt de indexering en interoperabiliteit. De zorgpaden, coördinatiedocumenten, onderzoeksresultaten: elk van deze elementen verdient een herkenbare plaats in de structuur.
Beheer van toegangsrechten in de structuur
De sitemap van een gezondheidsplatform is niet volledig openbaar. Sommige secties zijn alleen zichtbaar voor geauthenticeerde professionals, andere voor ingelogde patiënten. Deze segmentatie van toegangsrechten moet al bij het ontwerp van de structuur worden overwogen, en niet achteraf worden toegevoegd via technische filters.
Het voorzien van een aparte XML-sitemap voor zoekmachines (alleen openbare pagina’s) en een volledige interne kaart voor procesbeheer is een goede praktijk. Het verwarren van de openbare sitemap met de interne functionele kaart genereert beveiligingslekken en indexeringsproblemen.
De architectuur van een gezondheidsplatform wordt gebouwd op het snijpunt van zelden elders samengebrachte beperkingen: regelgeving rond persoonsgegevens, eisen voor toegankelijkheid, technische interoperabiliteit tussen systemen, coördinatie tussen professionals met verschillende profielen. De sitemap is geen secundaire deliverable die aan het einde van het project moet worden geproduceerd. Het is de basis waarop het vermogen van het platform rust om zijn primaire functie te vervullen: de juiste informatie naar de juiste gebruiker, op het juiste moment, te laten circuleren.
