Tim Postema (plv. directeur informatiebeleid | ministerie van VWS) doet in editie 4 van ICT&health een oproep om mee te denken over een nationale API-strategie voor de zorg. Hierbij een bijdrage van Melius Health Informatics.
Wat is het doel van een nationale API-strategie?
Ieder plan en iedere strategie begint met een doel. Wat Melius Health Informatics betreft is het doel van een API-strategie:
‘Het wegnemen van belemmeringen voor zorginnovatie die ontstaan door technische beperkingen bij de toegang (lezen en schrijven) tot zorginformatie die is opgeslagen in (digitale) informatiesystemen.’
Een API-strategie is een belangrijk hulpmiddel bij het voorkomen van ‘Information blocking’.
Wat is het doel van een nationale API-Strategie NIET?
Het is ook heel belangrijk om expliciet vast te stellen wat het doel NIET is. Wat ons betreft zijn de volgende doelen geen onderdeel van een (nationale) API-strategie:
Zorginnovatie is op zichzelf geen doel van een (nationale) API-strategie. Zorginnovatie is het domein van zorgbestuurders, zorgprofessionals en zorgondernemers. Een API-strategie neemt voor hen sommige belemmeringen weg die (toekomstige) innovaties in de weg kunnen staan. Ze neemt belemmeringen weg die ‘digitale transformatie van zorg’ in de weg kunnen staan. Het wegnemen van belemmeringen is op zichzelf niet voldoende om innovatie te laten ‘gebeuren’.
Het wegnemen van andere belemmeringen voor zorginnovatie dan ‘technische beperkingen bij de toegang tot zorginformatie’ is geen doel van een (nationale) API-strategie. Denk hierbij aan belemmeringen voortkomend uit de financiering en organisatie van zorg, onvoldoende samenwerking (of zelfs regelrechte tegenwerking) tussen partijen of uit (privacy)wetgeving.
Het verbeteren of uitbreiden van de registratie door zorgprofessionals zodat dit leidt tot beter bruikbare informatie in digitale informatiesystemen is geen doel van een (nationale) API-strategie. Dit kan wel het doel zijn van een (nationale) data-strategie zoals ‘Registratie aan de bron’.
Het standaardiseren van de wijze waarop informatie is vastgelegd in digitale informatiesystemen is geen doel van een (nationale) API-strategie. Dit kan wel het doel zijn van een ‘open platform strategie’ zoals is geprobeerd met Vendor Neutral Archives (VNA’s) en wordt bepleit in bijvoorbeeld ‘Het is tijd voor een nieuw soort EPD’ en ‘The EHR Is Dead. Long Live The EHR Platform’
Gaat een API-strategie alleen over gestandaardiseerde API’s?
In zijn column spreekt Tim Postema expliciet over Open API’s en niet over gestandaardiseerde API’s. Het verschil tussen die twee is belangrijk en beschrijf ik onder andere in ‘Wat zijn API’s? En hoe kan het transformerend vermogen van API’s beter worden benut’.
Een korte samenvatting is:
Open API’s Open API’s zijn bedacht door een leverancier (ze zijn leverancier specifiek) maar voldoen wel aan een aantal eisen, bijvoorbeeld ten aanzien van toegangsbeleid, versiebeleid, documentatie en de beschikbaarheid van een testvoorziening. Open API’s kunnen snel worden ontwikkeld en worden soms in later instantie (al dan niet in aangepaste vorm) gestandaardiseerd. Open API’s kunnen de ontwikkeling van innovaties helpen versnellen.
Standaard API’s Standaard API’s zijn gestandaardiseerd door een daartoe in het leven geroepen instelling, zoals Nictiz of NEN of de Internet Engineering Taskforce (IETF). De ontwikkeling van een standaard is een langdurig proces dat vooral bijdraagt aan opschaling van een innovatie.
Het onderscheid tussen Open API’s en Standaard API’s is in de praktijk wat minder scherp:
Nagenoeg alle Open API’s maken wel degelijk gebruik van standaarden, bijvoorbeeld ten behoeve van transport van gegevens, formattering van gegevens of ten behoeve van authenticatie van personen, organisaties en systemen.
Veel Open API’s zijn gebaseerd op internationale standaarden, bijvoorbeeld een internationaal FHIR profiel, maar door de leverancier aangepast zodat zij bruikbaar is in de Nederlandse situatie. ZorgDomein was bijvoorbeeld voorloper in Nederland bij het toepassen van FHIR en heeft in samenwerking met Firely een Nederlands profiel ontwikkeld.
Een nationale API-strategie gaat zowel over Open API’s als Standaard API’s. Belangrijke strategische vragen hierbij zijn:
Wat is de (verwachte) rol van Open API’s en wat van Standaard API’s? In welke gevallen is een Standaard API vereist en wanneer voldoet een Open API?
Welke eisen worden gesteld aan Open API’s? Denk bijvoorbeeld aan eisen die gesteld worden aan (publieke) beschikbaarheid van documentatie en testomgevingen maar ook aan eisen ten aanzien van het toegangsbeleid (onder welke voorwaarden een leverancier een partij uit mag sluiten van gebruik van haar API’s).
Welke eisen worden gesteld aan Standaard API’s? Denk bijvoorbeeld aan de eisen die gesteld worden ten aanzien van het afwijken van internationale standaarden, zoals ‘comply or explain’, eisen aan documentatie van afwijkingen en eisen ten aanzien van harmonisatie van de verschillende in omloop zijnde standaarden.
Hoe kunnen Open API’s worden ingebracht ter standaardisatie (en hoe wordt die inbreng gestimuleerd)? Voorbeelden zijn de werkwijze van IETF en de procedure van Nationale Technische Afspraken van NEN.
Welk eisen worden gesteld aan prijsbeleid? Dit gaat niet zozeer over de daadwerkelijke prijs die voor een API gerekend wordt maar bijvoorbeeld over de mate van transparantie (dienen prijzen en de wijze waarop ze tot stand komen publiek beschikbaar te zijn?) en voor wie de rekening is.
Welke ingrediënten moet een nationale API-strategie bevatten?
De nationale API-strategie dient een antwoord te bevatten op de in de vorige paragraaf gestelde strategische vragen ten aanzien van het gebruik van Open API’s en Standaard API’s. Daarnaast is het volgende van belang:
Technologie-absorptievermogen / digitale autonomie van zorgpartijen API’s hebben alleen waarde wanneer ze ook daadwerkelijk aangeboden en gebruikt worden. Dit vraagt van bestuurders, managers en digitale leiders dat zij de rol van technologie in het algemeen en van API’s in het bijzonder begrijpen en kunnen (helpen) vertalen in beleid. Dat is nu onvoldoende het geval. Daarnaast vraagt het kunnen absorberen van technologie om (continue investeringen in) voldoende kennis en kunde binnen een organisatie. Samenwerking (tussen zorgaanbieders, met kennisinstituten, met de opensource community, etc.) is een belangrijk instrument om kennis en kunde te vergroten. Een nationale strategie omvat daarom maatregelen om digitale autonomie te vergroten.
Een scope en/of roadmap Hierbij is de vraag voor welke bedrijfsfuncties een API aangeboden dient te worden. Door de National Health Service (NHS) wordt in haar ‘Open API Architecture Policy’ het volgende gesteld: ‘All significant business functionality provided by the host system should be available via an Open API.’ Dit is een zowel zeer ambitieuze als ambivalente vereiste: wat is immers ‘significant business functionality’? Een meer concrete aanpak beschrijft domeinen en concrete ‘business functionalities’ waarbinnen API’s beschikbaar moeten zijn. Dit is de aanpak die gevolgd wordt in de ‘Open banking’ PSD2 regulation van de EU. Vertalen van de PSD2 aanpak naar de zorg zou bijvoorbeeld kunnen zijn dat API’s verplicht worden gesteld voor toegang tot alle zorginformatie die een zorgaanbieder verwerkt van een patiënt, zonder dat specifieke eisen aan de daarbij te gebruiken standaarden worden gesteld en zonder dat daarbij vooraf van bepaalde usecases wordt uitgegaan. Daar waar reeds sprake is van grootschalig gebruik van gestandaardiseerde API’s zou de voorkeur uit moeten gaan naar stimulering en / of verplichting van bredere toepassing van die API’s. Een voorbeeld daarvan is de bredere inzet van MedMij API’s voor de Basis Gegevensset Zorg en PDF/A. Door brede stimulering vanuit Open, VIPP GGZ en VIPP5 wordt ondersteuning van die API’s al door de meeste leveranciers ingebouwd en kunnen zij relatief eenvoudig worden ingezet voor gebruik buiten typische PGO usecases.
Hoe kan een nationale strategie worden afgedwongen?
In ‘De verborgen parels van de Wegiz’ schets ik hoe de Wegiz kan worden ingezet voor het afdwingen van gebruik van zowel Open API’s (via spoor 1) als Standaard API’s (via spoor 2).
De inzet van Open API’s vanuit de Wegiz bestaat uit een aantal stappen:
Het opstellen van een NEN-norm voor eisen aan Open API’s. Deze norm beschrijft in ieder geval eisen aan (publiekelijk toegankelijke) documentatie en testomgeving, eisen aan versiebeheer en eisen aan toegangsbeleid (wie mag op welke gronden worden uitgesloten van gebruik van de API’s).
Eisen ten aanzien van prijsbeleid (zoals transparantie) voor (Open) API’s kunnen worden opgesteld door de ACM.
In een spoor 1 AMvB kan de minister een domein verplichten waarop Open API’s dienen te worden aangeboden door zorgaanbieders (en dus indirect door leveranciers) waarbij de minister vereist dat deze voldoen aan de NEN norm voor Open API’s en de richtlijnen van de ACM.
Is een nationale API-strategie genoeg om zorginnovatie te laten bloeien?
Nee. Een nationale API-strategie neemt bepaalde belemmeringen weg maar zeker niet alle. Innovatie ontstaat wanneer zij lonend is voor stakeholders. Belangrijke stakeholders zijn bijvoorbeeld zorgaanbieders zelf, patiënten, betalers (verzekeraars) en (software) leveranciers. Al deze partijen hebben verschillende belangen. Het is goed Nederlands gebruik om ofwel oeverloos te polderen over belangen, ofwel via achterkamertjes en geheime projecten andere partijen van het eigen belang te overtuigen. De cultuur van geheimzinnigheid en elkaar hinderen die hierdoor is ontstaan zal moeten worden doorbroken. VWS kan hierin een belangrijke rol spelen door voorbeeldgedrag, een duidelijke visie en regelgeving en door partijen consequent te wijzen op spelregels van samenwerking.
Daarnaast moet niet het idee ontstaan dat API’s de oplossing zijn voor alle technische problemen rond data in de zorg. Sommige problemen zijn veel meer gebaat bij een andere organisatie van zorg, bij betere registratie aan de bron of bij een platformstrategie.
Comentários