API’s hebben een groot transformerend vermogen dat binnen de zorg weinig wordt benut. Wat zijn daarvan de oorzaken en welke oplossingen zijn voorhanden?
Soms heeft een relatief eenvoudig technisch idee op langere termijn onvermoede grote maatschappelijke impact. Denk aan hoe de uitvinding van het kompas reizen naar eerder onbereikbare delen van de wereld vereenvoudigde. Of hoe de drukpers het op grote schaal verspreiden van ideeën mogelijk maakte. Of hoe door telefonie de communicatie tussen mensen niet meer gebonden is aan plaats en tijd. Dit soort uitvindingen leiden tot een exponentiele toename van kennis, tot nog meer uitvindingen en toepassingen. Ze zijn transformerend.
API’s (Application Programming Interfaces) zijn de manier waarop (delen van) computerprogramma’s met elkaar communiceren. API’s zijn minder tastbaar dan een kompas, drukpers of telefoon, waardoor hun impact voor veel mensen minder direct zichtbaar of voorstelbaar is. Toch wordt er inmiddels gesproken van ‘de API economy’ en communiceren computersystemen over de hele wereld continu met elkaar, ongeacht tijd en plaats. API’s doen dus voor computersystemen wat de telefonie en whatsapp voor mensen doen; altijd met alles en iedereen in realtime kunnen communiceren. Voorbeelden van dagelijks gebruik geven inzicht in de transformerende impact van API’s:
Zonder API’s zouden de meeste apps op mobiele telefoons niet werken. De app op je telefoon communiceert continu met de ‘cloudbased’ systemen van hun makers . Apps als Whatsapp, Facebook, Google Maps, Office en vele anderen zijn dus afhankelijk van communicatie via API’s.
Zonder API’s zouden veel financiële transacties niet mogelijk zijn of in ieder geval veel langer duren. Tikkie is afhankelijk van API’s voor communicatie tussen de Tikkie app en de Tikkie servers van ABN Amro. Ze gebruikt de API’s van whatsapp om berichten te sturen en de iDeal API’s om geld over te maken.
Zonder API’s zou het boeken van reizen ingewikkelder zijn. Online-diensten als Booking.com en Expedia.com zijn afhankelijk van de API’s van vliegmaatschappijen, autoverhuurbedrijven, hotels en vele anderen om hun diensten te kunnen bieden.
Zonder API’s zouden retailers als Amazon en Bol.com niet bestaan. De afstemming met toeleveranciers en pakketbezorgers is volledig geautomatiseerd en berust op communicatie via de API’s van systemen in de keten.
Zonder API’s is het gebruik van bijvoorbeeld je Facebook, Google of Microsoft-account als inlogmiddel op verschillende websites en apps niet mogelijk.
Steeds meer apparaten in de persoonlijke levenssfeer communiceren via API’s met de servers van hun leveranciers (Internet of Things, IoT). Tesla auto’s sturen data naar Tesla voor analyse van rijgedrag en prestaties. Veel apps sturen locatiegegevens en wearables sturen continu metingen naar ‘Quantified Self Platforms’. Slimme lampen, thermostaten, deurbellen en sloten communiceren via API’s van hun leveranciers.
Veel diensten op het gebied van kustmatige intelligentie, zoals spraak naar tekst, beeldherkenning en patroonherkenning werken op basis van API’s. Amazon Echo en Google home devices sturen geluidsbestanden via de API’s naar hun cloudbased slimme assistenten voor interpretatie van spraak.
API’s zijn transformerend voor veel industrieën omdat ze afstemming binnen een keten op zeer grote schaal en met enorme snelheden mogelijk maken. Ze zijn ook transformerend omdat ze het schaalbaar inzetten van dure en complexe technologieën mogelijk maken, zoals vormen van kunstmatige intelligentie. Toch lijkt de impact van API’s op zorg achter te blijven bij veel andere industrieën. Twee oorzaken daarvan, en een mogelijke remedie, zal ik verder toelichten.
Grote nadruk op gestandaardiseerde API’s
Er wordt wel eens beweerd dat iedere keer dat je ‘Application Programming Interface’ kunt zeggen er ergens op de wereld een nieuwe API beschikbaar komt. Binnen Amazon is het beleid dat ieder ontwikkeld stukje software van een API moet worden voorzien, zodat deze in de toekomst ook door andere (al dan niet Amazon) systemen en toepassingen kunnen worden gebruikt. Al dit soort API’s zijn bedrijfseigen API’s. Ze zijn wel gebaseerd op technische standaarden, zoals standaarden op het gebied van beveiliging of communicatie, maar de API zelf is niet gestandaardiseerd. De Google Maps ‘Places API’, die informatie geeft over plaatsen in de buurt van een locatie of op basis van zoek-criteria, is bijvoorbeeld gebaseerd op technische standaarden zoals HTTP (de technische standaard die ook door webbrowsers wordt gebruikt om gegevens uit te wisselen met webservers). De functionaliteit van de ‘Places API’ en (de vorm van) de data die wordt uitgewisseld is echter bedacht door Google en is niet gestandaardiseerd.
Vergelijk dit met de kamerbrief van minister van Ark over ‘Open standaarden en ICT-markt in de zorg’, waarin standaardisatie als belangrijke voorwaarde voor interoperabiliteit en versnelling van de gegevensuitwisseling wordt gepositioneerd. In de (Nederlandse) zorg wordt grote nadruk gelegd op standaardisatie van gegevensuitwisseling en dus van API’s. Standaardisatie is echter een moeizaam en langdurig proces. Het standaardisatieproces sluit ook niet makkelijk aan bij de meer ‘agile’ aanpak van de IT-industrie, waarin oplossingen in kleine maar snel opvolgende iteratieve stappen worden doorgevoerd, opdat zoveel mogelijk leermomenten ontstaan en continu bijsturen en verbeteren mogelijk is.
Door de NHS wordt de nadruk gelegd op Open API’s in plaats van op gestandaardiseerde API’s. De ‘Open API Architecture Policy’ van de NHS vereist van leveranciers dat zij open API’s beschikbaar stellen voor alle belangrijke functionaliteiten (zoals Amazon dat doet). Waar mogelijk zijn dat ook gestandaardiseerde API’s. Een ‘Open API’ is wel bedrijfseigen maar het gebruik ervan wordt door de leverancier ondersteund:
Open API’s zijn volledig gedocumenteerd en documentatie is kosteloos beschikbaar.
Er is een publieke testomgeving beschikbaar.
Er is versiebeheer. Wijzigingen in de API voldoen aan vooraf gemaakte afspraken.
Er is support, door de leverancier zelf of via partners van de leverancier.
Er mogen geen partijen (zoals concurrenten) worden uitgesloten van gebruik van de API’s.
De aanpak van de NHS is zeker niet zonder nadelen maar wel meer in lijn met de aanpak binnen andere industrieën. Een aanpak die aantoonbaar tot meer interoperabiliteit en versnelling leidt, zoals blijkt uit de eerder genoemde voorbeelden uit andere industrieën, en langzaam maar zeker ook navolging krijgt binnen de zorg-ICT. Epic biedt bijvoorbeeld kosteloos documentatie en testtools voor al haar API’s via https://open.epic.com. Initiatieven als de Taskforce Samen Vooruit (TSV) en NUTS staan voor een meer bottom-up model waarbij door de industrie ontwikkelde oplossingen worden ingebracht bij de NEN ter verdere normalisatie. Snelle ontwikkeling van bedrijfseigen API’s wordt zo gecombineerd met de voordelen van standaardisatie.
Inkopers en beleidsmakers zouden in hun beleid uit moeten gaan van een combinatie van het vereisen van open API’s (conform de NHS) en het stimuleren van standaardisatie. De door TSV voorgestelde aanpak kan wel eens tot meer versnelling leiden dan de top-down standaardisatie aanpak die we in de Nederlandse zorg gewend zijn.
Grote nadruk op complexe gegevensuitwisseling
De complexiteit van API’s wisselt sterk en is niet recht evenredig met de meerwaarde. Veel van de meest eenvoudige API’s leveren zeer veel meerwaarde terwijl de meerwaarde van veel complexe API’s twijfelachtig is.
De complexiteit van API’s wordt vooral bepaald door twee factoren:
De veelvormigheid van te verwerken gegevens. Een API die het mogelijk maakt om geld over te boeken (bronrekening, doelrekening, bedrag) is eenvoudiger dan een API die 28 verschillende typen gegevens in een medisch dossier doorzoekbaar maakt op basis van verschillende zoek-criteria.
De mate waarin gegevens door machines geïnterpreteerd moeten worden (machine interpretatie). Een API die een tekstuele verpleegkundige overdracht opslaat in een dossiersysteem is eenvoudiger dan een API die de opgestuurde gegevens moet interpreteren en de verschillende onderdelen van de overdracht afzonderlijk moet verwerken.
In de (Nederlandse) zorg wordt veel nadruk gelegd op zeer complexe API’s. Een voorbeeld is de eOverdracht standaard voor verpleegkundige overdracht, die bestaat uit meer dan 50 verschillende soorten gegevens (veelvormigheid) die in hoge mate door het ontvangende systeem moeten worden geïnterpreteerd en afzonderlijk moeten worden verwerkt. De vereiste van machine-interpretatie betekent ook nogal wat voor de kwaliteit van de bronverslaglegging. Deze moet tenminste compatibel zijn met vooraf vastgelegde specificaties (in de zogenaamde ZIB’s), hetgeen grote verandering in de registratie door verpleegkundigen ten gevolge kan hebben. En in de werking van de gebruikte dossiersystemen.
Eenvoudiger API’s met ten minste zoveel transformerend vermogen mogen zich merkwaardig genoeg op minder aandacht verheugen. API’s om thuismonitoringsystemen te integreren met EPD’s (en dus met de zorg), om portalen (en andere aanbieder gebonden dienstverlening) visueel te integreren met PGO’s of om chat apps als BeterDichtbij te integreren met EPD’s, staan niet op de agenda van het Informatieberaad, terwijl hun meerwaarde eenvoudiger kan worden bepaald dan van veel andere prioritaire gegevensuitwisselingen. En ze bovendien veel eenvoudiger kunnen worden gerealiseerd.
Beleidsmakers en Enterprise Architecten doen er goed aan om de meerwaarde van API’s (of gegevensuitwisselingen) af te wegen tegen hun complexiteit of uitvoerbaarheid. Hierbij moeten zij er van uitgaan dat de meerwaarde alleen goed door de zorg zelf, management en professionals, kan worden bepaald en niet door IT-specialisten. De afweging van meerwaarde tegen uitvoerbaarheid wordt nu maar weinig gemaakt.