Welkom.
Fijn dat je kijkt naar deze presentatie over de meerwaarde van API's in de zorg.
Ik ga u meenemen in deze presentatie langs de ontwikkelingen...
die er zijn in de gezondheidszorg, op het gebied van API's.
Wat zijn API's?
En ik heb een aantal voorbeelden daarvan.
We kijken naar de API-strategie en we gaan kijken naar...
een aantal dilemma's die daarbij spelen.
Mijn naam is Gerda Meijboom.
Ik ben informatie-architect bij Nictiz.
Nictiz is een kennisorganisatie voor digitale gegevensuitwisseling in de zorg.
De afgelopen jaren heb ik de focus in de zorg voor op het gebied...
van informatie-uitwisseling zien veranderen.
Waar we voorheen vooral keken naar een focus gericht op...
het uitwisselen van verschillende use cases, kijken we nu veel breder.
Voorheen keken we naar verschillende use cases en dan bedoel ik bijvoorbeeld...
die uitwisseling van het recept tussen de huisarts
en de apotheek of het aanleveren van informatie over bijvoorbeeld...
zwangerschappen aan een kwaliteitsregistratie zoals die van PRM.
Tegenwoordig kijken we veel meer generiek, kunnen we niet toe...
...naar een bouwdoos met allerlei verschillende componenten
die we als herbruikbare blokjes voor verschillende uitwisselingen...
kunnen gaan gebruiken.
Dit heeft alles te maken met een omslag die er ook gaande is in de zorg.
Je kunt dan denken, bijvoorbeeld aan een beweging als
de juiste zorg op de juiste plek.
De zorg rond de patiënt wordt nu door veel meer verschillende...
zorgverleners tegelijk verleend.
En dat betekent ook dat de informatiebehoefte van die zorgverleners verandert.
Ook de eerste iteratie van de Doelarchitectuur gaat daarover.
In november is er een rapport aangeboden aan het informatieberaad...
waarin de commissie Doelarchitectuur zegt:
Kijk naar dat nieuwe perspectief.
De zorg wordt niet meer geleverd in ketens.
De zorg wordt geleverd in netwerken.
Hanteer dat netwerkperspectief dan ook als het leidende paradigma...
voor het uitwisselen van informatie.
En de Architectuurboard, heeft eigenlijk datzelfde gezegd.
Die zegt in haar rapport over dat rapport van de commissie Doelarchitectuur:
Hanteer dat netwerkperspectief als leidend.
Ze zeggen daar ook bij:
Gebruik API's, de API-technologie,
om die informatievoorziening te gaan ondersteunen.
En ik wil jullie daarin verder gaan meenemen vandaag.
In diezelfde tijd is er door HL7 Nederland een rapport uitgebracht...
...over het gebruik van CDA en FHIR.
En dat rapport, dat heeft als aanbeveling:
kies nu voor FIHR als de toekomstige standaard.
De FIHR API's hebben de toekomst, gebruik die.
Er is kennis in de markt.
Ze zijn flexibel.
Je kunt ze op allerlei manieren inzetten.
Ga die gebruiken.
Daarnaast zeggen ze in dit rapport ook:
Overweeg het verplichten van een FIHR, van de FIHR API's.
En dat sluit ook goed aan bij een rapport dat ik van de zomer...
heb uitgebracht samen met een collega.
We hebben een verkenning gedaan naar het nut en noodzaak van...
...API's in de zorg en daar hebben we een aantal aanbevelingen bijgeschreven.
En een van die aanbevelingen is:
Formuleer een API-strategie voor de zorg en zorg ook voor standaardisaties van die API's.
Er zijn al verschillende voorbeelden beschikbaar in het buitenland.
Daar kom ik later nog eventjes op terug.
In de rest van deze presentatie wil ik jullie daarin meenemen.
Hoe kunnen we nu met die API's die veranderende informatiebehoefte...
van de zorgverlener op een makkelijkere, flexibelere manier gaan invullen?
Ik heb hier twee voorbeelden meegenomen:
Het ene is een app van ABN Amro.
In die app worden allerlei API's gebruikt.
Met die API's kun je je gegevens van verschillende rekeningen...
in één overzicht zien.
In die app zit ook een API voor bijvoorbeeld het tonen van...
al jouw transacties en een app voor het tonen van het totale...
saldo dat op die verschillende rekeningen staat.
Zo gebruikt die app dus verschillende API's.
En ook een website als Booking.com gebruikt verschillende API's:
Een API om bijvoorbeeld de vluchtinformatie op te halen bij...
verschillende vliegorganisaties.
En API's om hotelinformatie op te halen.
Bijvoorbeeld het aantal kamers dat een hotel heeft.
De prijs van die kamers.
Allemaal verschillende API's die in één systeem, booking.com, bij elkaar komen.
Geonovum heeft hij een hele mooie definitie van de API's:
Een Application Programming Interface.
Het is eigenlijk een Engels woord.
Eigenlijk zou je API moeten zeggen.
Ik gebruik eigenlijk altijd het woord API.
En dat is een gestructureerd en gedocumenteerd koppelvlak...
voor communicatie tussen applicaties.
Je kan een aanbieder zien als een soort digitale stekkerdoos...
die applicaties met elkaar verbindt.
Eigenlijk zijn die API's dus herbruikbare technische bouwsteentjes...
waarmee je gegevens kunt ontsluiten op een eenvoudige manier.
En die veranderende informatiebehoefte waar ik het net over had in de zorg,
doordat er steeds meer zorgverleners betrokken zijn bij de zorg rond een patiënt,
vraagt dus ook om een meer flexibele inrichting van die informatievoorziening.
En API's kunnen daaraan bijdragen.
Doordat zij herbruikbare bouwsteentjes zijn.
Ze passen prima in een concept van een soort bouwdoos,
met allerlei herbruikbare componenten.
Zorginformatie bouwstenen zorgen daarin voor eenheid van taal.
API's zorgen daarin voor de eenheid van techniek.
Dit waren een aantal voorbeelden over ABN Amro en Booking.com.
Ook in de zorg zijn er verschillende voorbeelden te vinden van API's.
Ik heb er hier een aantal genoemd.
Ik hoop niet dat er nu leveranciers zich gepasseerd voelen.
Dan zijn er nog veel meer, kan ik zeggen.
Maar dit, even:
U kent misschien wel MedMij
en het Zorgplatform Epic misschien ook wel.
Al deze partijen gebruiken ook API's binnen hun systemen.
Waarom dan toch een API-strategie?
Een API-strategie is nodig omdat al deze partijen wel API's gebruiken,
maar allemaal verschillende API's.
Als je aansluit op MedMij, dan zijn daar andere API's voor gebruikt...
...dan voor de aansluiting op bijvoorbeeld Zorgplatform of op de Quarant API's.
En om nu te zorgen dat al deze systemen met elkaar kunnen gaan uitwisselen,
is het nodig om te zorgen dat ze ook dezelfde API's gaan gebruiken,
met dezelfde techniek,
zodat ook al die systemen daadwerkelijk op elkaar aan gaan sluiten...
en zorgverleners dus ook met elkaar op een gestructureerde manier...
kunnen gaan communiceren.
Wat willen we gaan bereiken met een API-strategie?
Het zijn een aantal dingen:
Als eerste de goede ondersteuning van het zorgproces.
Dat zou voorop moeten staan.
De juiste zorg op de juiste plek vraagt ook om...
de juiste informatie op het juiste moment.
API's moeten die gegevens bieden die de zorgverlener nodig heeft in zijn proces.
We willen ook het ondersteunen van het netwerkperspectief.
Zoals aan het begin van deze presentatie ook aangegeven,
wordt het netwerkperspectief als leidend beschouwd.
Een toename van samenwerkingen leidt tot een grotere informatiebehoefte...
en het beschikbaar zijn van gegevens wordt steeds belangrijker.
Als derde het verbeteren van het hergebruik van gegevens voor...
meerdere doelen.
Met API's willen we ook eenmalig vastleggen,
meervoudig gebruik nu echt gaan realiseren.
Niet alleen voor de uitwisseling tussen zorgverleners,
maar ook voor kwaliteitsdoeleinden en wetenschappelijk onderzoek.
We willen information blocking voorkomen.
Gegevens moeten niet vastzitten in systemen,
maar beschikbaar zijn voor anderen die dat nodig hebben...
om goede zorg te verlenen aan de patiënten.
We willen de interoperabiliteit verbeteren.
Eenheid van taal en eenheid van techniek, zodat interoperabiliteit verbetert.
Het is eerder genoemd, maar er zijn al heel veel systemen die API's hebben.
Maar om het echt goed werkend te krijgen zijn eenduidige afspraken...
in een API-strategie nodig.
En als laatste: versnelling bij het ontwikkelen...
en de implementatie van een uitwisseling.
API's moeten herbruikbaar zijn zodat verschillende use cases...
bediend kunnen worden.
API's moeten daarbij zorgen voor flexibiliteit en schaalbaarheid,
zodat oplossingen sneller ontwikkeld kunnen worden...
en ook de implementatie kan worden versneld.
In zo'n API-strategie maak je dus een keuze voor taal en techniek.
Je beschrijft de metadata rond de API's, maar ook de governance van API's.
Hoe ga je daarmee om? Wie is daarvoor verantwoordelijk?
Wie is de houder van die API's?
Maar om nu de juiste keuzes te maken binnen zo'n API strategie,
moeten we kijken naar de behoeftes die er zijn bij verschillende belanghebbenden.
Ondertussen komen we dan aan bij het laatste punt in de agenda.
We hebben het gehad over verschillende ontwikkelingen.
We hebben het gehad over wat API's zijn en voorbeelden daarvan,
waarom we eigenlijk een API strategie zouden willen.
En we gaan nu kijken naar welke behoeften er leven...
...bij verschillende belanghebbenden van die API's.
Ik wil jullie daarin meenemen in een aantal dilemma's.
En die belanghebbenden, dat betreft in deze presentatie de zorgverleners, zorgaanbieders,
leveranciers, de zibs en de informatie standaarden en wetgeving en het informatie stelsel.
En ik ga al deze vijf onderwerpen langs.
API's en het gebruik van API's door de zorgverlener.
Stel, een zorgverlener heeft de beschikking over een API voor het opvragen van bloeddrukken.
Met die API kan hij in het systeem allerlei bloeddrukken uit andere systemen opvragen.
Zijn systeem kan daar een mooi overzichtje van maken,
misschien wel weergegeven in een grafiek.
De zorgverlener die ziet dat er een aantal pieken in deze bloeddruk voorkomen.
Hij vraagt zich dan af in welke context deze bloeddruk is vastgelegd.
Voor een zorgverlener is het dus belangrijk om te weten welke context bij de gegevens hoort.
Daar moeten we rekening mee houden in het maken van de API's.
Een ander punt is relevantie van gegevens.
Stel, een patiënt komt binnen met spoed met een hartinfarct.
Dan kan de zorgverlener de BGZ opvragen.
Binnenkort is dat mogelijk en dan krijgt hij een aantal basisgegevens.
Maar als zo'n patiënt al onder behandeling is in een ander ziekenhuis,
dan wil je eigenlijk meer gegevens.
En dan is de vraag: welke gegevens zijn er dan nog meer relevant voor deze zorgverlener?
En hoe maken we dan de vertaalslag van die gegevens naar de verschillende...
...technische API's die daarbij nodig zijn om die informatie te gaan ophalen?
En een laatste punt voor deze zorgverlener gaat over het vastleggen.
Om informatie te kunnen uitwisselen met andere zorgverleners,
is het ook nodig dat voor de andere zorgverleners duidelijk is wat gegevens betekenen.
Daar hebben we eenheid van taal voor.
Maar we willen ook zorgen dat de administratieve lasten niet toenemen.
Daarvoor moeten we er voor zorgen dat deze API's ook geschikt zijn.
Niet alleen voor het uitwisselen tussen zorgverleners, maar ook tussen..
...de zorgverlener en bijvoorbeeld de kwaliteitsregistratie of...
...voor het aanleveren van gegevens voor wetenschappelijk onderzoek.
Het gebruik van API's bij een zorgaanbieder, dat gaat weer over heel andere zaken.
Een zorgaanbieder heeft te maken met heel veel verschillende systemen.
Systemen binnen zijn eigen organisatie, maar ook...
...steeds meer systemen buiten zijn organisatie waar hij mee communiceert.
De vraag is dan: gaan we al deze systemen straks gebruikmaken...
...van dezelfde API's en welke dan?
Die zorgaanbieder heeft te maken met ook allerlei tussenoplossingen.
Je ziet omdat het een complex veld is,
dat zorgaanbieders nu zoeken naar andere oplossingen.
Bijvoorbeeld het maken van een eigen datawarehouse,
of de opkomst van een regionaal platform.
Daar kunnen we natuurlijk ook prima API's voor gebruiken.
Maar welke willen we daarvoor gebruiken?
De vraag is ook of API's misschien kleinere zorgaanbieders ook...
...kunnen helpen om te kiezen voor een ander systeem.
Maakt zo'n API het mogelijk om makkelijk te switchen van leverancier?
De leveranciers hebben te maken met heel veel verschillende standaarden bij het...
...maken van API's. Voor elke use case is er een eigen standaard,
en de vraag is voor de leveranciers: welke standaard moeten we kiezen?
Moeten we daarin het advies van HL7 Nederland volgen om te kiezen voor HL 7FHIR API's?
Of moeten we toch naar iets anders?
En stel nu dat we er voor kiezen om te komen met een FHIR bibliotheek,
een API bibliotheek gebaseerd op FHIR.
Dat betekent dat leveranciers gebruik kunnen maken van zo'n bibliotheek...
...en die bibliotheek voor verschillende use cases kunnen gebruiken.
Op dit moment verdient de leverancier geld voor elke use case die hij bouwt.
Wat wordt nu straks het verdienmodel?
Als die API's universeel worden en op een makkelijke manier hergebruikt kunnen worden?
Of betekent dat dat niet gewoon dat de leverancier meer geld heeft voor innovatie?
De vraag is ook: willen we de leveranciers de mogelijkheid geven...
...om zelf allerlei API's te gaan ontwikkelen?
Of gaan we dat reguleren? In een API strategie moeten we daar keuzes in maken.
Op dit moment maken we voor eenheid van taal gebruik van zorginformatie bouwstenen.
Bij de meeste is dat ondertussen wel een bekend fenomeen denk ik.
Met die zorg informatie bouwstenen bereiken we eenheid van taal.
De vraag is of we voor elke zorg informatie bouwsteen nu...
...ook een API moeten gaan ontwikkelen, zodat we dat blokje informatie...
...dat in een zorg informatie bouwsteen zit ook kunnen uitwisselen met andere systemen.
Een ander dilemma dat hier speelt is de grootte van de API.
Als je een medicatie overzicht wil opvragen, dan kun je zeggen:
het medicatie overzicht is opgebouwd uit verschillende bouwstenen.
Willen we dan al die bouwstenen bij elkaar nemen en aanbieden in één API?
Of blijven de bouwstenen apart beschikbaar?
En is het aan de ontvangende systemen om op basis van die bevraging
van die verschillende API's een nieuw medicatie overzicht te maken?
Dat zijn keuzes die we nog moeten maken hierin.
Als we straks een bibliotheek hebben van API's en...
...een bibliotheek van zorg informatie bouwstenen,
dan wordt het ook makkelijker om informatiestandaarden te gaan...
...ontwikkelen om überhaupt uitwisselingen te ontwikkelen.
En in die API strategie moeten we dan ook afspraken gaan opnemen...
...over hoe we willen omgaan met deze verschillende API's en...
...hoe we die willen gebruiken in uitwisselingen, zodat we dat op dezelfde manier gaan doen.
Het laatste punt gaat over API's en wetgeving en het informatie stelsel in de zorg.
Zoals jullie weten is VWS op dit moment bezig met het ontwikkelen van een wet.
De Wet Elektronische gegevensuitwisseling in de zorg.
Onder die wet worden verschillende normen gehangen.
Deze wet is op dit moment nog vrij use case gericht.
Er zijn een aantal use cases benoemd die als eerste in de wet...
...worden opgenomen en dat zijn het digitaal recepten verkeer,
de BGZ, beeld uitwisseling en verslag en verpleegkundige overdracht.
Naast deze use case gerichte normen komen er ook generieke normen...
...en dat is dan voor functies als adressering, login, toestemming.
Ik denk dat het goed is om de afspraken die we in een API strategie...
...willen vastleggen ook op te nemen bij deze generieke normen,
of in ieder geval een delen daarvan ook op te nemen in deze wet.
En wij willen daar de komende tijd ook met VWS over in gesprek.
Een ander punt van aandacht hierbij is autorisatie en toestemming.
Als je werkt met kleine blokjes gegevens.
Hoe past dat dan in de toestemming die de patiënt heeft gegeven?
Stel, de patiënt heeft toestemming gegeven voor medicatie gegevens.
Welke blokjes, welke API's horen daar dan bij?
Welke mag een zorgverlener dan gebruiken?
En dat geldt eigenlijk ook voor autorisatie.
Stel, een zorgverlener is geautoriseerd voor geboortezorg.
Welke API's mag deze zorgverlener dan gebruiken in zijn systeem om gegevens op te vragen?
En tenslotte moet covenance geregeld worden voor API's,
Stel er komt een bibliotheek,
en dan komen allemaal afspraken in zo'n API strategie.
Dan moet dat ook geborgd worden in het informatie stelsel.
Samenvattend:
Door netwerkzorg verandert de informatiebehoefte, dat hebben we gezien.
API's kunnen deze veranderende informatiebehoefte ondersteunen...
...door de flexibiliteit die ze bieden.
En een API strategie voor de zorg is nodig om eenheid van taal en techniek te bevorderen.
En die strategie moet keuzes maken voor taal en techniek,
gebaseerd op de behoeften van zorgverleners, zorgaanbieders en leveranciers,
rekening houdend met de bestaande situatie zoals de wetgeving en het informatie stelsel.
Nictiz gaat zich de komende tijd verder verdiepen in deze API strategie...
...en gaat daarmee verder.
Ik wil u op dit moment bedanken voor uw aandacht.