FHIR R5, op basis van de ballot mogen we hem ergens in het komende jaar wel gaan verwachten. Moeten we nou weer wat anders gaan doen?
Met de komst van iedere nieuwe versie van FHIR laait de discussie op over een overstap. Met het openbaar maken van de FHIR R5 ballot is dat niet anders. De ballot is een opmaat naar de uiteindelijke release, waardoor de discussie weer relevant wordt. Hoewel de fase van ballot tot final release bij de vorige versies altijd minimaal een jaar heeft geduurd, is dit wel de tijd om alvast goed te analyseren wat we hiermee in Nederland moeten.
In deze discussie herken ik vaak de volgende vragen:
- De huidig gebruikte standaard is nu wel echt verouderd. We moeten nu toch zeker wel overstappen?
- Is deze nieuwe versie backward compatible? Dit is wel een must!Lopen we straks hopeloos achter als we toch nog DSTU1, DSTU2, STU3, R4, R4B gebruiken?
- Wat mij betreft zijn de antwoorden op bovenstaande vragen allemaal met “nee” te beantwoorden. Hieronder licht ik toe waarom we daar juist blij mee mogen zijn.
V: De huidig gebruikte standaard is nu wel echt verouderd. We moeten nu toch zeker wel overstappen?
A: Nee, zolang STU3 de juiste informatie op de juiste plek voor de juiste zorg brengt, wie zal dan willen overstappen? Pas als een van die punten in gevaar komt moet daar expliciet actie op worden ondernomen. De bekende projecten die op STU3 draaien zullen daar zeker in de huidige implementatie helemaal geen noodzaak toe hebben.
V: Is deze nieuwe versie backward compatible? Dit is wel een must!
A: Nee, backward compatibility is vaak zowel een vloek als een zege, de wijzigingen komen vaak vanuit commentaar en controle bij het veld (op basis van bijvoorbeeld de ballot versie) waardoor vaak blijkt dat juist die wijziging heel erg gewenst is. Overigens is backward compatibility ergens wel een doel, want een normatieve resourcedefinitie (zoals er in R5 weer meer zijn) zou niet meer op zodanige wijze mogen veranderen dat het breekt.
V: Lopen we straks hopeloos achter als we toch nog DSTU1, DSTU2, STU3, R4, R4B gebruiken?
A: Nee, een berichtstandaard zal zich altijd blijven evolueren en daarmee zal men op een zeker moment in de tijd altijd achter gaan lopen. De vraag is wanneer het ver genoeg ontwikkeld is voor de toepassing die je wil bereiken. Binnen versie 2 van de HL7 standaard zie je bijvoorbeeld ook dat in Nederland 2.2, 2.4 en 2.5 wordt gebruikt, terwijl internationaal gezien ook versie 2.8 wordt gebruikt. Het gaat erom dat goede afspraken worden gemaakt over welke berichtstandaard en welke versie daarvan gebruikt wordt. Voor de BgZ 2017 is en blijft dat STU3 en voor de BgZ van de toekomst moeten we dat nog samen gaan bepalen.
Blijven we dan voor altijd STU3 gebruiken?
Nee, natuurlijk zijn er ook genoeg redenen om WEL na te denken over de stap naar een nieuwe versie, want R4 en R4B zijn er niet voor niks. Er zijn al verbeteringen aangebracht op meerdere vlakken die we in Nederland op basis van profiling toe hebben gevoegd aan onze STU3 implementaties.
Zolang de afspraken onderling op de juiste manier zijn gemaakt op de gebruikte versie gaat niemand er een probleem mee hebben. Vanaf het moment dat er twee versies vereist worden gaan er wel uitdagingen ontstaan.
Wat zien jullie als grootste uitdaging van een nieuwe versie?
Disclaimer: De standpunten in deze blog zijn van mij persoonlijk en staan dus los van eventuele officiële standpunten van mijn werkgever.
