Wat weerhoudt zorg-ICT-aanbieders ervan om open koppelingen te maken? Johan Krijgsman, manager Monitoring & TrendITion bij Nictiz, betoogt dat open API’s zouden helpen om systemen in de zorg met elkaar te laten praten.
Elk jaar klagen artsen erover in de eHealth-monitor: ze kunnen moeilijk medische gegevens uitwisselen over hun patiënten, terwijl ze die gegevens wel nodig hebben. Dat komt volgens hen voor een belangrijk deel doordat informatiesystemen in de zorg niet of slecht aan elkaar gekoppeld kunnen worden. Daarin staan Nederlandse artsen niet alleen. In de Verenigde Staten speelt hetzelfde probleem. Eén van de oplossingen waarop de Amerikanen inzetten? Open API’s in de zorg.
Makkelijk aan de slag met Google Maps dankzij een API
Waarom kom je landkaarten van Google Maps op zo’n beetje elke website tegen? Simpel... omdat Google een ‘open API’ heeft. API staat voor application programming interface. Dat is een duidelijk beschreven ‘koppelvlak’ voor een softwareprogramma. Je kunt een API eigenlijk vergelijken met de nopjes waarmee de ene legosteen op de andere past.
Een API beschrijft hoe je in programmacode een programma precies de dingen kunt laten doen die je wilt. Bijvoorbeeld een kaart laten zien van een bepaalde plek ter wereld, ingezoomd tot een bepaald detailniveau. Je hoeft daarvoor niet alle broncode van Google Maps te kennen. Je hoeft alleen de commando’s te kennen van de dingen die je met Google Maps wilt doen. In principe kan iedere programmeur die redelijk javascript (een programmeertaal) beheerst vrij snel met de Google Maps API een landkaart op zijn website laten verschijnen. Je hoeft daar dus geen gespecialiseerd bedrijf voor in te huren.
Een grafiek van je stappenteller dankzij een API
Google doet bepaald niet geheimzinnig over zijn API’s. Je gaat als programmeur simpelweg naar https://developers.google.com/maps/ en je kunt er alles over lezen. Compleet met voorbeeldcode. En Google staat daar niet alleen in. Als we bijvoorbeeld kijken naar de producenten van wearables op het gebied van fitness en zelfmeetapparatuur, dan bieden ook zij vaak een duidelijke API aan voor programmeurs. Withings bijvoorbeeld is een producent van weegschalen, bloeddrukmeters en stappentellers. De API van Withings staat gewoon op hun website. Je kunt daarmee als programmeur bijvoorbeeld een website bouwen waarin je data van Withings-apparaten kunt gebruiken, bijvoorbeeld om grafieken te laten zien. Of je zou de data kunnen combineren in een mobiele app met gegevens van andere apparaten. Ook andere producenten zoals Fitbit, Garmin en Apple hebben gepubliceerde API’s.
Applicaties koppelen dankzij een API
Goed gedocumenteerde API’s maken het makkelijk voor programmeurs om code te schrijven die gebruik maakt van de functies en gegevens van de softwareleverancier die de API aanbiedt, in de voorbeelden van zonet dus Google Maps of de apparaten van Withings. Je kan dus ook makkelijk de gegevens van het ene programma ophalen en gebruiken in het andere. Applicaties aan elkaar koppelen dus.
Dat is precies de reden dat de Amerikaanse overheid inzet op open API’s in de zorg. Sylvia Mathews Burwell, de Amerikaanse minister van gezondheidszorg, kondigde recent tijdens de HIMSS-conferentie in Las Vegas aan dat grote leveranciers van medische informatiesystemen hebben beloofd zich in te zetten voor open API’s. Dankzij deze API’s moet het makkelijker worden om informatiesystemen in de zorg aan elkaar te koppelen.
De voordelen van API’s
Een goed gedocumenteerde API maakt het makkelijk om een koppeling te programmeren met een informatiesysteem zonder dat daar elke keer speciaal de hulp van de leverancier voor nodig is. Ook voorkomt het dat je precies moet weten hoe de software van de leverancier precies van binnen in elkaar zit. Als de software in een toekomstige versie intern verandert, hoef je niet per se opnieuw aan de slag, omdat de API vaak stabiel blijft. En als de API toch verandert, dan is dat, als het goed is, grondig gedocumenteerd. Of de oude code wordt nog even ondersteund tot in een volgende update, zodat je rustig tijd hebt om de code van de koppeling aan te passen.
De facto standaarden
Natuurlijk lost een API niet alles op. Als verschillende systeemleveranciers totaal verschillende API’s hebben, dan moet je nog steeds verschillende code schrijven voor koppelingen met verschillende leveranciers. Maar in ieder geval worden die verschillen wel heel duidelijk, en dat kan dan aanleiding geven om over die verschillen in debat te gaan en een keuze te maken voor standaardisatie. In ieder geval een stap in de goede richting dus. Bovendien zijn niet alle aanbieders even belangrijk. Wanneer een leverancier met een groot marktaandeel, zoals Google, een API aanbiedt, dan is dat de facto een standaard die zwaarder telt dan de API’s van kleinere aanbieders.
Waar zijn de open API’s in de Nederlandse zorg?
Wie echter denkt op de websites van belangrijke softwareleveranciers voor de Nederlandse zorg heldere documentatie te vinden van de API’s, komt echter vooralsnog bedrogen uit. Nergens is te lezen hoe je bijvoorbeeld de code moet schrijven om een verwijsbrief van een patiënt op te halen uit een systeem of een afspraak in een systeem aan te maken. Waarom eigenlijk niet, zou je je kunnen afvragen. Het zou de integratie met deze systemen zoveel makkelijker kunnen maken. Zodat artsen makkelijker gegevens kunnen uitwisselen. En allerlei eHealth-toepassingen makkelijker gekoppeld zouden kunnen worden aan het centrale systeem van de zorgverlener.
Nergens is te lezen hoe je code moet schrijven om een verwijsbrief van een patiënt op te halen uit een systeem
Zijn de investeringen in een API voor leveranciers te hoog? Is het teveel werk om de documentatie te maken en bij te houden? Gaan de veranderingen daarvoor te snel? Of is de softwareleverancier bang dat door het openstellen van data hippere concurrenten aantrekkelijker of goedkopere toepassingen gaan maken op basis van de opengestelde functies en data? Moeten we eerst wachten of de Amerikaanse initiatieven vrucht afwerpen? Of is het misschien tijd om ook in Nederland eens werk te maken van open API’s in de zorg? In ieder geval zou het interessant zijn om te weten waarom de Nederlandse marktleiders hier nog niet mee zijn gekomen.
Plaats een Reactie
Meepraten?Draag gerust bij!