Onderwerp 4.3 — Interoperabiliteit en datastandaarden

In gezondheid en zorg is interoperabiliteit geen technische netheid maar een eis van klinische veiligheid en billijkheid: wanneer systemen de juiste data, in de juiste vorm, met ondubbelzinnige betekenis, op het zorgmoment niet kunnen delen, worden mensen geschaad en wordt ongelijkheid vergroot.

Waarom dit ertoe doet in gezondheid en zorg#

De zorg van een persoon vindt zelden op één plek plaats. Eén episode kan een huisartsenpraktijk, een ambulancedienst, een spoedeisende hulp, een ziekenhuisafdeling, een wijkverpleegkundige, een apotheek, een team voor sociale zorg en een mantelzorger thuis raken. Elk van deze houdt een deel van het dossier. Als die delen niet veilig en snel kunnen worden samengebracht, nemen clinici beslissingen met ontbrekende informatie: een niet gezien allergie, dubbel voorgeschreven medicatie, een onnodig herhaald onderzoek, een signalering over veiligheid die onzichtbaar is voor het team dat haar nodig heeft.

Interoperabiliteit is wat een verzameling losse systemen omzet in iets wat zich, vanuit het gezichtspunt van de patiënt, gedraagt als een samenhangende dienst. Het is het leidingwerk onder geïntegreerde zorg. Wanneer het werkt, kan een clinicus in de ene organisatie zien wat een andere heeft vastgelegd en erop vertrouwen dat het betekent wat hij of zij denkt dat het betekent. Wanneer het faalt, is het falen vaak stil totdat iemand wordt geschaad.

Dit is ook een kwestie van billijkheid. Mensen met de meest complexe behoeften — kwetsbare ouderen, mensen met meerdere langdurige aandoeningen, mensen die tussen diensten bewegen — zijn precies de mensen wier data het meest gefragmenteerd zijn. Slechte interoperabiliteit schaadt daarom de kwetsbaarsten het meest. En het is een zaak van publiek vertrouwen: mensen nemen redelijkerwijs aan dat de NHS hun informatie al verstandig deelt en zijn ontdaan te horen hoe vaak dat niet zo is.

Ten slotte beschermt interoperabiliteit publiek geld. Bedrijfseigen systemen die geen data kunnen uitwisselen binden organisaties aan dure, moeilijk te vervangen contracten en dwingen kostbare punt-tot-puntintegraties af. Bouwen naar open normen is hoe u opties open houdt, leveranciers eerlijk houdt en voorkomt dat u herhaaldelijk betaalt om hetzelfde probleem op te lossen.

Kernbegrippen#

Interoperabiliteit is het vermogen van verschillende systemen informatie uit te wisselen en te gebruiken. Het is nuttig twee lagen te scheiden. Syntactische of technische interoperabiliteit betekent dat twee systemen een bericht kunnen uitwisselen en elk de structuur ervan kan lezen — de envelop komt aan en kan worden geopend. Semantische interoperabiliteit betekent dat het ontvangende systeem begrijpt wat de inhoud betekent op dezelfde manier als de afzender — dat een code voor “penicillineallergie” aan beide kanten identiek wordt geïnterpreteerd. Technische interoperabiliteit zonder semantische interoperabiliteit is gevaarlijk: data stromen, maar betekenis gaat verloren of wordt vervormd.

Gezondheidsdata worden uitgewisseld met normen. Health Level 7 (HL7) is de familie normen die het meest in de gezondheidszorg wordt gebruikt. De oudere berichtenversie HL7 versie 2 (v2), met tekst gescheiden door verticale streepjes en dakjes, onderbouwt nog steeds een enorme hoeveelheid ziekenhuisberichten en zal dat nog jaren doen. De moderne norm, HL7 Fast Healthcare Interoperability Resources (FHIR), modelleert klinische informatie als “resources” die worden uitgewisseld via application programming interfaces (API’s) in webstijl, wat het veel gemakkelijker maakt voor moderne ontwikkelaars.

Normen voor het bericht zijn niet genoeg; u hebt ook standaardvocabulaires voor de inhoud nodig. SNOMED CT (Systematized Nomenclature of Medicine — Clinical Terms) is de klinische terminologie die in de NHS-zorg verplicht is voor het vastleggen van diagnoses, symptomen, ingrepen en meer. De NHS Dictionary of medicines and devices (dm+d) is het standaardvocabulaire voor geneesmiddelen en medische hulpmiddelen en onderbouwt elektronisch voorschrijven. De International Classification of Diseases, 10e en 11e herziening (ICD-10 en ICD-11), onderhouden door de Wereldgezondheidsorganisatie, worden gebruikt voor classificatie, statistiek en vergoeding eerder dan voor dagelijkse klinische vastlegging. openEHR is een open specificatie voor het structureren van het gezondheidsdossier zelf via gedeelde, klinisch bestuurde “archetypes”, en wordt door sommige organisaties gebruikt om klinische datamodellen onafhankelijk van één leverancier te houden.

Twee verdere ideeën zijn fundamenteel. Het NHS-nummer is de gemeenschappelijke patiëntidentificator waarmee dossiers over dezelfde persoon betrouwbaar over organisaties kunnen worden gekoppeld; zonder gedeelde identificator is matchen gissen. En Integrating the Healthcare Enterprise (IHE) publiceert “profielen” die exact specificeren hoe bestaande normen te combineren om concrete problemen als het delen van documenten op te lossen, zodat verschillende leveranciers ze op dezelfde manier implementeren.

Onder dit alles ligt een strategische keuze. Bouwen naar open normen met gepubliceerde, herbruikbare API’s houdt een markt concurrerend en uw data overdraagbaar. Leunen op bedrijfseigen interfaces creëert vendor lock-in, waar van leverancier wisselen zo kostbaar wordt dat u feitelijk niet kunt. Niets hiervan levert echter waarde zonder datakwaliteit: accurate, volledige, tijdige, consistent gecodeerde data zijn de voorwaarde voor interoperabiliteit, geen bijzaak.

Beste praktijken#

1. Onderscheid semantische van technische interoperabiliteit en ontwerp voor beide. Het is gemakkelijk te vieren dat een bericht nu tussen twee systemen stroomt en te missen dat de ontvangende clinicus niet veilig op de betekenis kan vertrouwen. Vraag altijd: interpreteert de andere kant deze codes, eenheden en ontkenningen precies zoals wij? Investeer in gedeelde terminologieën (SNOMED CT, dm+d) en waardelijsten, niet alleen berichtformaten, want een correct verzonden maar verkeerd begrepen allergie is gevaarlijker dan geen bericht.

2. Bouw naar open normen en hergebruik platforms in plaats van opnieuw uit te vinden. Neem het breed onderschreven beginsel aan: bouw naar open normen en hergebruik bestaande nationale platforms en diensten voordat u uw eigen bouwt. In de NHS betekent dit de voorkeur geven aan HL7 FHIR-API’s, het NHS-nummer als identificator gebruiken en verbinden met nationale diensten als de Spine, GP Connect en gedeelde zorgdossiers in plaats van maatwerk punt-tot-puntkoppelingen te creëren. Hergebruik verlaagt kosten, spreidt de onderhoudslast en betekent dat uw data kunnen reizen.

3. Maak het NHS-nummer onmisbaar in elk dossier en bericht. Betrouwbare koppeling van dossiers hangt af van een betrouwbare gemeenschappelijke identificator. Zorg dat het NHS-nummer wordt vastgelegd, geverifieerd tegen de nationale demografische dienst en meegedragen op elk relevant dossier en elke interface. Waar het ontbreekt of niet is geverifieerd, behandel dat als datakwaliteitsdefect om op te lossen, omdat matchen op alleen naam en geboortedatum zowel gevaarlijke verkeerde matches als gemiste koppelingen produceert.

4. Behandel datakwaliteit als eersteklas oplevering. Interoperabiliteit exporteert uw problemen met datakwaliteit naar iedereen stroomafwaarts. Profileer uw data, meet volledigheid en consistentie van codering en richt rentmeesterschap in zodat fouten bij de bron worden gevonden en hersteld. Coderingsdrift, vrije tekst waar gestructureerde data nodig zijn en inconsistente eenheden zullen stilletjes elke stroomafwaartse analyse en klinische weergave corrumperen, dus financier dit werk expliciet in plaats van aan te nemen dat het vanzelf gebeurt.

5. Geef de voorkeur aan API-first, los gekoppelde architecturen boven strakke integraties. Ontwerp zo dat capaciteiten worden blootgesteld via goed gedocumenteerde, versioneerde API’s die anderen zonder maatwerkonderhandeling kunnen gebruiken. Dit is aanvankelijk trager dan een directe databasekoppeling, maar het is wat u een component laat vervangen zonder alles eromheen te herbouwen. Het sluit ook aan bij hoe nationale diensten en moderne leveranciers nu verwachten te integreren, en ondersteunt de leveringsaanpakken in Onderwerp 3.5 — Leveringslevenscycli.

6. Gebruik gepubliceerde profielen en conformiteitstesten, geen lokale interpretaties. Normen zijn flexibel, en twee teams kunnen “dezelfde” FHIR-resource onverenigbaar implementeren. Neem nationale implementatiegidsen en IHE-profielen aan die de details vastpinnen en eis van leveranciers dat zij conformiteit tegen die aantonen vóór go-live. Conformiteitstesten zetten “wij ondersteunen FHIR” — een bewering die op zichzelf zeer weinig betekent — om in verifieerbaar, contractueel feit.

7. Schrijf eisen voor interoperabiliteit en open normen in inkoop en contracten. Het goedkoopste moment om lock-in te vermijden is voordat u tekent. Eis open, gedocumenteerde API’s, het recht uw eigen data in een standaardformaat te exporteren, naleving van benoemde normen en geen kosten voor standaardintegraties. Werk met uw commerciële collega’s (zie Onderwerp 6.3 — Inkoop en commercie) zodat dit verplichte gunningscriteria worden en geen aspiraties die later worden weggeonderhandeld.

8. Bestuur interoperabiliteit met klinische veiligheid en informatiebeheer in de kamer. Elke nieuwe datastroom wijzigt klinisch risico en de behandeling van vertrouwelijke informatie. Betrek klinischeveiligheidsfunctionarissen en leiders informatiebeheer vanaf het begin in ontwerpbeslissingen, niet als laatste goedkeuring, zodat gedeelde dossiers zowel veilig als rechtmatig zijn. Dit sluit rechtstreeks aan bij Onderwerp 1.6 — Klinische veiligheid en risicobeheer en Onderwerp 1.7 — Informatiebeheer, gegevensbescherming en cyberbeveiliging.

Vragen om met uw team te bespreken#

1. Waar in onze zorgtrajecten veroorzaken ontbrekende of verkeerd begrepen data vandaag het grootste klinische risico? Investering in interoperabiliteit moet schade en waarde volgen, niet architecturale mode. Breng de trajecten in kaart die uw meest complexe patiënten werkelijk afleggen en vind de overdrachten waar informatie verloren gaat, vertraagt of zonder betrouwbare betekenis aankomt. Vraag clinici waar zij routinematig blind werken — de overplaatsingen, de gaten buiten kantooruren, de grens tussen gezondheidszorg en sociale zorg. Onderscheid plekken waar data helemaal niet stromen van plekken waar ze stromen maar niet kunnen worden vertrouwd, omdat deze verschillende oplossingen vragen. Overweeg welke populaties het meest worden getroffen, aangezien fragmentatie het hardst valt bij mensen met de meest complexe behoeften. Het antwoord vertelt u waar te beginnen en geeft u een zaak voor klinische veiligheid die zwaarder weegt dan elk technisch argument.

2. Hoe blootgesteld zijn wij aan vendor lock-in, en wat zou het ons werkelijk kosten van onze belangrijkste klinische systemen te wisselen? Veel organisaties ontdekken de ware prijs van een gesloten systeem pas wanneer zij proberen het te verlaten. Werk concreet door wat nodig zou zijn om uw data in bruikbare, standaardvorm te extraheren en naar een andere leverancier te verhuizen. Onderzoek uw contracten op wie de data bezit, welke standaardinterfaces bestaan en of u wordt gerekend voor integraties die routine zouden moeten zijn. Identificeer de bedrijfseigen interfaces en gegevensformaten die zouden moeten worden ontward. Weeg dit af tegen de openheid van alternatieven en nationale platforms die u in plaats daarvan zou kunnen hergebruiken. Dit gaat niet over leveranciers wisselen; het gaat erom uw hefboom te begrijpen en het risico te verminderen dat de roadmap van één leverancier uw enige optie wordt.

3. Zijn onze data goed genoeg om veilig te delen, en hoe zouden wij dat weten? Slechte data delen brengt u niet alleen in verlegenheid — het plant fouten voort in de beslissingen van andere clinici. Vraag of u de volledigheid, juistheid, tijdigheid en consistente codering van de data die u wilt blootstellen werkelijk meet. Bespreek wie datakwaliteit in uw organisatie bezit en of zij de tijd en het mandaat hebben problemen bij de bron te herstellen. Overweeg welk deel van de dossiers een geverifieerd NHS-nummer draagt en hoeveel klinisch belangrijke informatie nog in vrije tekst staat in plaats van gecodeerde velden. Denk na hoe u een systematische codeerfout zou detecteren voordat zij een gedeeld zorgdossier bereikte. Als u deze vragen niet met bewijs kunt beantwoorden, behandel dat dan als bevinding op zich en financier het werk aan datakwaliteit voordat u de leiding verbreedt.

4. Wanneer een leverancier zegt “wij ondersteunen FHIR”, hoe zouden wij dat vóór go-live werkelijk verifiëren? Een normenlabel is een marketingbewering totdat het is getest tegen een specifieke implementatiegids. Bespreek of uw organisatie enig eigen vermogen voor conformiteitstesten heeft, of dat u leveranciers simpelweg op hun woord gelooft. Twee systemen kunnen elk “FHIR-conform” zijn en toch geen bruikbaar bericht kunnen uitwisselen, omdat de norm bewust flexibel is en de betekenis leeft in de profielen en waardelijsten die haar vastpinnen. Vraag welke nationale implementatiegidsen en IHE-profielen voor de betreffende interface gelden en wie aan uw kant bekwaam is ze te lezen. Overweeg of conformiteit in het contract is vastgelegd als voorwaarde om te verbinden, of pijnlijk tijdens integratie wordt ontdekt. Een eerlijk antwoord noemt het specifieke profiel waartegen u zou testen, de persoon of functie die de test zou uitvoeren en het punt in het tijdschema waarop een falende leverancier wordt afgewezen in plaats van doorgewuifd.

5. Wie bezit normen, terminologie en conformiteit in onze organisatie, en hebben zij het mandaat nee te zeggen? Interoperabiliteit vervalt zonder rentmeesterschap: waardelijsten driften, lokale gidsen lopen uiteen en elk nieuw project vindt stilletjes zijn eigen interpretatie uit. Vraag of er een benoemde functie is die verantwoordelijk is voor normen, subsets van SNOMED CT en dm+d en conformiteit, of dat deze kennis in het hoofd van enkele individuen zit. Overweeg de spanning tussen centrale consistentie en lokale leveringssnelheid — teams onder druk zullen het snelste ding bouwen tenzij een functie voor normen werkelijk gezag heeft hergebruik te eisen. Bespreek hoe onderhoud van terminologie wordt gefinancierd, gegeven dat het onglamoureus en doorlopend is en iedereen ten goede komt en geen enkel afzonderlijk project. Kijk hoe u implementaties op één lijn houdt naarmate FHIR, SNOMED CT en nationale gidsen evolueren, in plaats van te bevriezen op de versie die u eerst aannam. Een eerlijk antwoord identificeert de verantwoordelijke eigenaar, zijn of haar financiering en een recent voorbeeld waarin zij een norm ofwel afdwongen ofwel daarin faalden.

6. Zijn de mensen wier dossiers wij samenvoegen geïnformeerd en tevreden over hoe hun data stromen? Interoperabiliteit is niet alleen een technische en klinische kwestie maar een vraag van publiek vertrouwen en rechtmatige grondslag. Mensen nemen redelijkerwijs aan dat de NHS hun informatie al verstandig deelt en zijn ontdaan wanneer dat niet zo is en ook wanneer het gebeurt op manieren die zij niet verwachtten. Bespreek of patiënten begrijpen welke organisaties hun gedeelde dossier kunnen zien, hoe een nationale data-opt-out of lokaal toestemmingsmodel over de stroom heen wordt gerespecteerd en hoe toegang wordt vastgelegd en controleerbaar is. Overweeg de dimensie van billijkheid: de mensen wier data het meest gefragmenteerd zijn — die met complexe behoeften — zijn ook degenen die opt-outs en informatieverklaringen het minst kunnen navigeren. Breng informatiebeheer en, waar relevant, patiënten of hun vertegenwoordigers in het ontwerp in plaats van toestemming te behandelen als vakje dat aan het eind wordt afgevinkt. Een eerlijk antwoord kan de rechtmatige grondslag voor elke stroom beschrijven, hoe iemand zou ontdekken wie zijn of haar dossier heeft gezien en hoe hun keuzes van begin tot eind worden gerespecteerd.

In de praktijk: een voorbeeld uit gezondheid en zorg#

Een geïntegreerd zorgsysteem in het noorden van Engeland stelt zich ten doel clinici één enkel beeld te geven van gedeelde medicatie over huisartsenzorg, ziekenhuis en gemeenschapsapotheek, nadat een evaluatie van een ernstig incident vond dat een patiënt twee op elkaar inwerkende geneesmiddelen had gekregen voorgeschreven door teams die elkaars dossiers niet konden zien.

De verleiding is een “medicatiedashboard” bij één leverancier te kopen en het rechtstreeks in de database van elk systeem te bedraden. De interoperabiliteitsleider verzet zich. In plaats daarvan neemt het programma een aanpak van bouwen naar open normen over. Elk bronsysteem stelt medicatiedata bloot als HL7 FHIR-resources; elk geneesmiddel wordt gecodeerd met de dm+d zodat “hetzelfde geneesmiddel” overal hetzelfde betekent; en elk dossier wordt gesleuteld op een geverifieerd NHS-nummer zodat de juiste medicatie aan de juiste persoon wordt gekoppeld. Huisartsdata worden getrokken via GP Connect in plaats van een maatwerkfeed, en hergebruiken een nationale capaciteit in plaats van een lokale uit te vinden.

Vroege dataprofilering bewijst onmiddellijk haar waarde. Het systeem van één praktijk had bepaalde geneesmiddelen in vrije tekst vastgelegd in plaats van als gecodeerde dm+d-items, wat betekent dat ze onzichtbaar zouden zijn geweest voor elke geautomatiseerde interactiecontrole. Dit wordt vóór go-live bij de bron hersteld. Het team vindt ook een cluster dossiers met niet-geverifieerde NHS-nummers en leidt ze via de nationale demografische dienst voor matching.

De klinischeveiligheidsfunctionaris en de leider informatiebeheer zijn gedurende de hele tijd deel van de ontwerpgroep. Samen definiëren zij precies welke data worden gedeeld, met wie, onder welke rechtmatige grondslag en hoe de toegang van een clinicus wordt vastgelegd — de zorgen van Onderwerp 1.7 — Informatiebeheer, gegevensbescherming en cyberbeveiliging. Leveranciers moeten conformiteitstesten tegen de nationale FHIR-implementatiegids doorstaan voordat zij verbinden. Twaalf maanden later is het samengevoegde medicatiebeeld live, is een interactie die voorheen was gemist al gevangen en — omdat alles naar open interfaces is gebouwd — hergebruikt een tweede toepassing, gedeelde allergie-informatie, het grootste deel van hetzelfde leidingwerk tegen een fractie van de oorspronkelijke kosten.

Sectorperspectieven#

Startup#

Een startup in digitale gezondheid leeft of sterft bij hoe gemakkelijk zij op bestaande systemen aansluit, dus behandel interoperabiliteit als kernfunctie, niet als nalevingsklus. FHIR-API’s bouwen en vanaf het begin SNOMED CT en dm+d gebruiken maakt u veel gemakkelijker te kopen en te integreren en signaleert volwassenheid aan voorzichtige NHS-kopers. Weersta de drang een eigen datamodel te bedenken wanneer een norm bestaat; uw onderscheidend vermogen moet uw product zijn, niet een bedrijfseigen formaat dat een aansprakelijkheid wordt. Het NHS-nummer en informatiebeheer vroeg goed regelen is wat u van pilot naar inkoop laat gaan. Ontwerp zo dat een klant in beginsel zijn data kan exporteren en vertrekken — paradoxaal is die openheid wat het vertrouwen verdient om hem te behouden.

Klein bedrijf#

Een gevestigde kleine aanbieder — een huisartsenpraktijk, een gemeenschapsapotheek, een verzorgingshuis of een kliniek met één vestiging — draagt dezelfde plichten om data veilig te delen als het grootste ziekenhuis, maar met een fractie van het technische vermogen. Hier is interoperabiliteit vooral een discipline van inkoop en configuratie in plaats van engineering: kies systemen die al FHIR spreken, verbind met nationale diensten als GP Connect en de Spine en codeer standaard met SNOMED CT en dm+d zodat u normen erft in plaats van ze te bouwen. Maak vastlegging van een geverifieerd NHS-nummer onderdeel van de dagelijkse praktijk, omdat het goed vastleggen van de identificator bij registratie uw goedkoopste waarborg is wanneer u geen integratieteam hebt om later afwijkingen te verzoenen. Leun op programma’s voor gedeelde zorgdossiers en de gedeelde infrastructuur van uw geïntegreerd zorgsysteem in plaats van maatwerkkoppelingen in opdracht te geven die u niet kunt onderhouden. Sta er bij het tekenen of verlengen van een systeemcontract in eenvoudige bewoordingen op dat rechten op data-export en open interfaces worden vastgelegd, omdat een kleine organisatie vendor lock-in het scherpst voelt en de minste hefboom heeft om achteraf te ontsnappen.

Grote onderneming#

Een grote aanbieder of leverancier draagt doorgaans decennia aan legacy: HL7 v2-interfaces, meerdere elektronische dossiersystemen en integratiemotoren die het geheel bijeenhouden. De realistische strategie is niet alles eruit te rukken maar een op API gebaseerde, op normen gebaseerde laag voor het bestand te zetten, stromen stapsgewijs naar FHIR te migreren en v2 te laten draaien waar het moet. Waak bij elke verlenging hard tegen lock-in en sta op conformiteitstesten zodat “conform de normen” wordt geverifieerd in plaats van beweerd. Richt een interne functie voor normen en conformiteit in zodat afzonderlijke projecten niet elk hun eigen interpretatie uitvinden. Dit is nauw verwant aan hoe u operationele kernplatforms beheert in Onderwerp 5.4 — Enterprise resource planning (ERP), waar dezelfde discipline van hergebruik en open interfaces geldt.

Overheid#

Nationale en regionale organen stellen de regels van de markt, dus hun keuzes over normen rimpelen door elke organisatie. Het waardevolste wat de overheid kan doen is open normen verplicht stellen, duidelijke implementatiegidsen en conformiteitseisen publiceren en herbruikbare nationale platforms bieden — de Spine, GP Connect, kaders voor gedeelde zorgdossiers, de dienst van het NHS-nummer — zodat lokale organisaties eenmaal bouwen en hergebruiken. Consistentie telt meer dan perfectie: een strikt gehandhaafde, goed-genoege norm verslaat een theoretisch superieure die iedereen anders implementeert. De overheid moet ook het onglamoureuze werk van onderhoud van terminologie en verbetering van datakwaliteit financieren, omdat dit publieke goederen zijn die geen enkele organisatie alleen zal financieren. Deze rentmeesterrol sluit aan bij Onderwerp 9.1 — Werken met lokale en nationale overheden en bij hoe partners samenwerken in Onderwerp 9.0 — Samenwerken met partnerorganisaties.

Veelvoorkomende faalpatronen#

• Technische verbinding verwarren met semantisch begrip. De overwinning uitroepen wanneer een bericht stroomt, zonder te bevestigen dat beide kanten de codes, eenheden en ontkenningen identiek interpreteren. Het resultaat is data die geïntegreerd lijkt maar stilletjes verkeerd wordt gelezen.
• Slechte data sneller delen. De leiding verbreden voordat datakwaliteit is hersteld, zodat coderingsfouten, vrije tekst en ontbrekende NHS-nummers zich voortplanten in de beslissingen van andere clinici en elke stroomafwaartse analyse.
• “Wij ondersteunen FHIR” als lege bewering. Een normenlabel aanvaarden zonder conformiteitstesten tegen een specifieke implementatiegids, zodat twee “conforme” systemen elkaar toch niet kunnen verstaan.
• Maatwerk punt-tot-puntintegraties. Directe koppelingen tussen elk paar systemen bouwen, wat een broos web oplevert dat exponentieel moeilijker en duurder te onderhouden wordt naarmate het groeit.
• Vastzetten bij verstek. Contracten tekenen met bedrijfseigen interfaces en zonder rechten op data-export, en de kosten van de val pas ontdekken wanneer u van leverancier probeert te wisselen.
• Bestuur behandelen als laatste poort. Klinische veiligheid en informatiebeheer alleen betrekken voor goedkeuring, zodat problemen laat en duur aan het licht komen of onder leveringsdruk worden doorgewuifd.
• Normen zonder rentmeesterschap. Terminologieën en profielen aannemen maar niemand financieren om waardelijsten te onderhouden, conformiteit te monitoren of implementaties op één lijn te houden naarmate normen evolueren.

Volwassenheidsmodel#

Checklist#

• Elk relevant dossier en elke interface draagt een geverifieerd NHS-nummer, met een proces om ontbrekende of niet-gematchte op te lossen.
• Nieuwe interfaces gebruiken HL7 FHIR en benoemde nationale implementatiegidsen, met HL7 v2 alleen behouden waar migratie nog niet gerechtvaardigd is.
• Klinische inhoud wordt gecodeerd met SNOMED CT en geneesmiddelen met dm+d, tegen afgesproken waardelijsten.
• Datakwaliteit voor alles wat u wilt delen wordt geprofileerd, gemeten, bezeten en bij de bron verbeterd voordat de leiding wordt verbreed.
• Leveranciers moeten conformiteitstesten tegen een specifiek profiel doorstaan voordat zij verbinden — “ondersteunt FHIR” wordt nooit zonder meer aanvaard.
• Nationale platforms (Spine, GP Connect, gedeelde zorgdossiers) worden hergebruikt voordat enige maatwerkintegratie wordt gebouwd.
• Contracten eisen open, gedocumenteerde API’s, rechten op data-export in een standaardformaat en geen kosten voor standaardintegraties.
• Leiders van klinische veiligheid en informatiebeheer zitten vanaf het begin in de ontwerpgroep, niet alleen bij goedkeuring.
• Architectuur is API-first en los gekoppeld, zodat een component kan worden vervangen zonder alles eromheen te herbouwen.
• Een benoemde functie bezit normen, conformiteit en onderhoud van terminologie in de hele organisatie.

Belangrijkste bronnen#

• NHS England — interoperabiliteitsnormen, de Spine, GP Connect en programma’s voor gedeelde zorgdossiers.
• HL7 International — de FHIR-norm en HL7 v2-specificaties.
• SNOMED International — SNOMED CT-terminologie en implementatierichtlijnen.
• NHS Business Services Authority — de Dictionary of medicines and devices (dm+d).
• Integrating the Healthcare Enterprise (IHE) — interoperabiliteitsprofielen.
• openEHR International — open specificaties voor het structureren van het gezondheidsdossier.
• Wereldgezondheidsorganisatie — de International Classification of Diseases (ICD-10 en ICD-11).

Referenties#

1. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
2. Semantic interoperability — Wikipedia — https://en.wikipedia.org/wiki/Semantic_interoperability
3. Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
4. Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
5. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
6. ICD-11 — Wikipedia — https://en.wikipedia.org/wiki/ICD-11
7. ICD-10 — Wikipedia — https://en.wikipedia.org/wiki/ICD-10
8. openEHR — Wikipedia — https://en.wikipedia.org/wiki/OpenEHR
9. NHS number — Wikipedia — https://en.wikipedia.org/wiki/NHS_number
10. Integrating the Healthcare Enterprise — Wikipedia — https://en.wikipedia.org/wiki/Integrating_the_Healthcare_Enterprise
11. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. API — Wikipedia — https://en.wikipedia.org/wiki/API
14. Data quality — Wikipedia — https://en.wikipedia.org/wiki/Data_quality
15. FHIR standard — HL7 International — https://www.hl7.org/fhir/
16. SNOMED CT — SNOMED International — https://www.snomed.org/
17. Dictionary of medicines and devices (dm+d) — NHS Business Services Authority — https://www.nhsbsa.nhs.uk/pharmacies-gp-practices-and-appliance-contractors/dictionary-medicines-and-devices-dmd
18. GP Connect — NHS England Digital — https://digital.nhs.uk/services/gp-connect
19. Spine — NHS England Digital — https://digital.nhs.uk/services/spine
20. International Classification of Diseases (ICD) — World Health Organization — https://www.who.int/standards/classifications/classification-of-diseases