De reden voor het schrijven van deze Blog is om ten eerste helderheid voor mijzelf te krijgen, daarnaast denk ik dat anderen er hun voordeel mee kunnen doen.
Anno 2021 is er een scala van documenten/specificaties ontstaan met de gehele werking van het MedMij stelsel. Alleen is de logica ver te zoeken, het kost echt veel tijd voor een leverancier om te achterhalen wat de juiste versie is, of er geen zaken ontbreken en wat er precies bedoeld wordt. Tevens helpt het niet dat er overal voor een expliciet jargon gekozen is. Het ene onderdeel moet je kwalificeren, het volgende onderdeel certificeren en weer een ander onderdeel heet acceptatie. Tevens is er een totale willekeur aan nummers en versies en is de communicatie vaak onduidelijk of niet volledig waardoor het veel tijd kost om thuis te raken in de MedMij omgevingen.
Sinds vorige week ben ik onderdeel van een adviescommissie om helderheid in het MedMij stelsel te verkrijgen en tevens verbeteringen uit te werken. Met als enige en gezamenlijke doel om het MedMij stelsel vlot te trekken.
De grootste MedMij uitdaging zit in het feit dat alle onderliggende standaarden aan consequente updates onderhevig zijn en dat aanpassing door alle ketenpartners op andere momenten plaatsvindt. Versies zijn tot op heden niet backwards compatible waardoor bij updates de keten uit elkaar kan vallen en de patiënt geen informatie meer kan opvragen. Het zou de voorkeur hebben als de standaard alleen incidenteel en uiterst minimaal wordt aangepast, tevens moeten deze backward compatible zijn.
Ondanks de huidige complexiteit en uitdagingen zien wij kansen om de gegevensuitwisseling goed van de grond te krijgen hiervoor wil ik samen met de leden van de adviescommissie zorgen voor:
- Meer duidelijkheid en overzicht over alle standaarden en versies zodat met name de verschillen tussen versies eenvoudig zijn te vinden en in te bouwen.
- Geïmplementeerde standaarden moeten backwards compatibel worden met de vorige versies zodat alle partijen in de keten de tijd krijgen om de nieuwe versies in te bouwen en te kwalificeren.
- Samenwerking tussen PGO’s om gezamenlijk de implementatie en kwalificatie van de wijzigingen van diensten door te voeren. Hiermee zorgen dat het gegevens stelsel betaalbaar blijft. MEDrecord neemt hierbij graag het voortouw.
Is de plaat compleet en 100% juist: NEE!
Alle input is meer dan welkom.
Onderstaande afbeelding toont een overzicht van het MedMij stelsel en de uitdagingen die onder de afbeelding worden toegelicht.
Hierbij een uitleg over de nummering (in het paars) in bovenstaande plaat. In haakjes heb ik erachter gezet bij welk loket je voor dat onderdeel aan moet kloppen binnen het MedMij stelsel.
- ZIB’s (Zorg Informatie Bouwstenen) (Nictiz)
Rond 2015/2016 heeft Nictiz ervoor gekozen om aan FHIR zogenaamde ZIB’s toe te voegen. ZIB’s zijn bedoeld om inhoudelijke c.q. functionele – niet technische – afspraken vast te leggen voor het standaardiseren van de informatie die wordt gebruikt in het zorgproces. De focus ligt op klinisch relevante concepten die in verschillende zorgsituaties (use cases) en daardoor in verschillende informatiestandaarden herbruikbaar zijn. Door dit op deze manier te doen lijkt het opeens een beetje op het openEHR model waar ik het in een eerdere Blog over had. Daar maak je eerst archetypes (FHIR profielen) die daarna samen een Template (ZIB) vormen. Alleen is openEHR in essentie bedacht om het op deze manier te doen, FHIR niet.
- Kwalificatie: ieder PGO moet bij de start al zijn GUI’s aan Nictiz tonen om zodoende te kwalificeren. Probleem is dat het (voor een nieuwkomer) totaal onduidelijk is wat er eigenlijk wordt verwacht, terwijl er blijkbaar aan Nictiz kant zeer exacte verwachtingen zijn, zie hier de lijst met PPT Templates. Een zeer frustrerend proces waarbij je na afkeuring moet gaan raden waar de problemen zitten. Een punt of komma kan al genoeg zijn, maar je moet zelf gaan zoeken waar het probleem zit. Het gaat hierbij om PPT’s met soms wel meer dan 100 slides (screenshots).
- In een ZIB worden meerdere FHIR profielen gebruikt, zie hier in Simplifier
- Binnen een ZIB worden verschillende vormen van dezelfde “bouwstenen” of profielen gebruikt. Dus een profiel “patiënt” kan meerdere versies hebben. Dat moet natuurlijk niet mogen…
- De meeste 2017 ZIB’s zijn meer Alpha modellen waar veel werk aan verricht moet worden om het echt werkbaar te krijgen.
- Bijvoorbeeld de bouwsteen PDF-A is verre van klaar voor gebruik. Er zijn nauwelijks instellingen die deze PDF vorm hebben, dus die moeten al hun documenten (per stuk) omzetten.
- Onduidelijkheid wanneer de volgende versie verplicht geïmplementeerd moet zijn. De huidige ZIB versie is nog altijd 2017.
2. Gegevensdiensten (VZVZ)
De ZIB wordt vertaald in een technische gegevensdienst die VZVZ onder zijn hoede heeft.
- Acceptatie; ieder PGO wordt jaarlijks getest op het technisch koppelvlak. Zeker de eerste keer is dit een langdurend proces.
- Sindskort is er een nieuwe nummering aan de diensten toegevoegd. Deze nummering is weer anders dan de versie, niet consistent. Bijvoorbeeld dienst 57 Delen Documenten 3.0 is van versie 2020.01 en dienst 41 Delen Documenten 2.0 is versie 2019.01. Beiden zijn van ZIB 2017 en communiceren via versie 1.3 met het koppelvlak. Kun je het nog volgen?
- Er staat nergens omschreven wat de verschillen zijn in de versies (2019.01 en 2020.01). Als dat wel zou zou zijn is het voor ontwikkelaars stukken eenvoudiger om een nieuwe versie te maken. Nu is dat gokken en/of langdurig uitpluizen.
- Binnen het stelsel is geen maximum van het aantal diensten die tegelijkertijd kunnen bestaan vastgelegd.
- Volgens de huidige opzet zullen er altijd twee (incompatible) versies van de gegevensdiensten aangeboden worden. De communicatie en status hiervan is niet duidelijk.
- Dit betekent dat de patiënt van iedere (dezelfde) dienst twee versies te zien krijgt. Als patiënt heb je geen idee waarom en wat de verschillen zijn. Deze verschillen zijn er niet, maar dat kan de patiënt niet weten.
- Deze diensten zijn niet backward compatible, dus iedereen binnen het hele stelsel zal er altijd twee moeten hebben.
- Op dit moment is het idee om deze diensten tweemaal per jaar aan te passen. Per dienst zal een update voor iedere deelnemer in het stelsel een week in beslag nemen. Op basis van momenteel 10 diensten kost dit gemiddeld per deelnemer tien weken werk.
3. FHIR profielen (Nictiz)
Vanaf 2020/2021 gaat FHIR over van STU modellen (1, 2 en 3) naar nummering met een R, deze start bij R4. De reden hiervoor is omdat STU staat voor “Standard for Trial Use”
- Alle deelnemers zijn gebaseerd op versie STU3
- De eerdere STU1, 2 en 3 versies waren niet backward compatible.
- De aanstaande R4 versie is niet compatible met STU3
- De nieuwe versies vanaf R4 zullen backward compatible zijn, precies zoals dat in een goede standaard hoort te zijn.
4. Het koppelvlak (VZVZ)
Bij het koppelvlak gaat het om de technische koppeling naar alle achterliggende systemen. De “problemen” zitten hem in onderdelen die buiten de MedMij scope vallen:
- De nummering van het koppelvlak loopt gelijk met het totale MedMij afsprakenstelsel, het is onduidelijk waarom. De techniek staat los van het afsprakenstelsel.
- Deze diensten zijn beveiligd met PKI certificaten. Helaas hadden in het afgelopen jaar deze certificaten weer hun eigen problematiek, deze werden massaal afgekeurd en moesten opnieuw aangevraagd worden.
- DigID werkt niet zoals je graag zou willen, het schrikt veel mensen af. Gaat buiten MedMij om, maar wel een cruciaal onderdeel.
- Jaarlijkse audit voor DVZA’s (Dienstverleners in het zorgaanbieders domein) op koppeling DigID of TVS (Toegangsverlenings service).
5. De ZAL (Zorgverleners Adres boek) of Zorg-AB (VZVZ)
Dit is de lijst met deelnemers aan beide kanten van het MedMij stelsel, dus via deze koppeling moeten partijen elkaar kunnen vinden.
- De ZAL of ZORG-AB is in technisch opzicht heel rigide opgebouwd, je kunt er weinig mee
- Je kunt niet binnen de lijst zoeken op bijvoorbeeld postcode of specialisatie, dus je kunt de eindgebruiker niet alle huisartsen in de buurt tonen.
- Eigen zorgverleners zijn voor de klant niet “vast” te zetten.
- De eindgebruiker zal iedere keer opnieuw in die hele lange lijst zijn zorgverlener moeten vinden.
6. Certificering volgens NEN7510 en ISO 27001 (buiten MedMij)
Dit is eigenlijk het meest makkelijke onderdeel (wij leveren dit ook als dienst aan onze PGO klanten). Alles is netjes gedocumenteerd en voor zover ik kan nagaan gaan partijen vlekkeloos door iedere audit, wij in ieder geval wel. Er zijn wel enkele haken en ogen omdat er nog veel inconsistentie met het gehele stelsel is:
- Ieder PGO certificeert volgens dezelfde nummering als het koppelvlak, nu versie 1.3.
- De auditors weten nog niet echt wat er van hun wordt verwacht, wat er wel of niet werkt.
- Volgens deze certificering moet er bij iedere major update en nieuwe PEN test uitgevoerd worden. dat zou beteken dat bij ieder van de eerder genoemde updates een kostbare PEN test moet komen bij iedere deelnemer.
- Onlangs waren er “fouten” in de audit ontdekt voor het onderdeel wetgeving. Daarom bij een groep deelnemers een herkeuring.
- Waarom hebben we binnen het stelsel vastgelegd dat een PGO geen BSN nummer mag voeren. Wij laten zelf artsen toe in ons PGO en dan zou, per definitie, het BSN nummer gewoon gebruikt mogen worden.
- De 24/7 helpdesk is hier een probleem voor ieder PGO; geen inkomsten maar wel zeer hoge kosten.
7. Nederlandse FHIR profielen niet compatible met buitenland
Zolang iedereen netjes binnen Nederland blijft is dit natuurlijk geen probleem.
- Er zijn door Nictiz uitbreiding op de FHIR profielen gedaan die buiten Nederland verder niet bestaan.
Kosten
De eenmalige kosten om een gecertificeerd PGO te maken ramen wij op ongeveer € 200.000, tenminsten als je de juiste expertise in huis hebt. Uiteraard is dat inclusief certificering voor NEN7510, ISO27001 en MedMij label.
Daarnaast ben je als PGO jaarlijks kwijt:
- 5 tot 10 weken ontwikkeltijd om de gegegevensdiensten te updaten
- 1 tot 2 weken om het koppelvlak te updaten
- 1 tot 2 weken om de juiste FHIR versie te gebruiken.
- En dan uiteraard het bemannen van de verplichte 24/7 helpdesk.
Omdat ieder PGO voor 1 augustus 2021 naar versie 2020.01 van de gegevensdiensten moet, willen wij aanbieden dit gezamenlijk op te pakken. Wij denken dat je op deze manier enorm kunt besparen. Mocht je hier interesse in hebben dan hoor ik het graag.
Input voor de plaat is van harte welkom! En als je denkt hulp nodig te hebben bij het bouwen van je eigen PGO of alleen het met minimale inspanning gezamenlijk inbouwen van de nieuwe standaard, dan helpen we je graag! Wij hebben alles voor je klaarstaan.
Alle succes, Jan-Marc en team
jan-marc@medrecord.io