Onderwerp 4.1 — Platforms en gedeelde diensten

In gezondheid en zorg is een gedeeld platform geen kostenbesparend gemak maar een manier om veiligheid, billijkheid en vertrouwen herhaalbaar te maken — zodat elk team ze erft in plaats van ze opnieuw uit te vinden, vaak slecht.

Waarom dit ertoe doet in gezondheid en zorg#

Wanneer u digitale levering over een zorgstelsel runt, merkt u al snel dat dezelfde capaciteiten steeds opnieuw worden gebouwd. Elke dienst wil een patiënt authenticeren, een demografisch dossier opzoeken, een melding versturen, een controlespoor vastleggen of de rol van een clinicus controleren. Aan zichzelf overgelaten bouwt elk team zijn eigen versie. U eindigt met een dozijn inlogschermen, een dozijn manieren om de identiteit van een patiënt af te handelen, een dozijn controlelogboeken van wisselende kwaliteit — en een dozijn plekken waar een veiligheidsdefect zich kan verbergen.

Deze duplicatie is duur, maar het diepere probleem is dat zij gevaarlijk en onbillijk is. In gezondheid en zorg draagt het leidingwerk klinisch risico. Als de patiëntmatching van het ene team zwakker is dan die van het andere, kan een patiënt het verkeerde dossier krijgen. Als de toegankelijkheid van de ene dienst slechter is, worden sommige mensen stilletjes uitgesloten. Als controlesporen verschillen, loopt een onderzoek van informatiebeheer vast. Een gedeeld platform laat u een capaciteit eenmaal bouwen, naar hoge norm, met het werk voor klinische veiligheid en toegankelijkheid behoorlijk gedaan, en dan veel teams die norm laten erven in plaats van dat elk erop gokt het alleen goed te krijgen.

Platforms bepalen ook het tempo van het hele stelsel. Een goed platform betekent dat een nieuwe dienst patiënten in weken kan bereiken in plaats van jaren, omdat de moeilijke, generieke delen al bestaan. Een slecht of afwezig platform betekent dat elk team het volle gewicht van infrastructuur draagt en levering vertraagt tot de snelheid van het team met de minste middelen. In een sector onder aanhoudende financiële druk en druk op personeel, waar dezelfde nationale en lokale capaciteiten door honderden organisaties nodig zijn, is platforms goed krijgen een van de beslissingen met de hoogste hefboom die u zult nemen. Dit onderwerp gaat over hoe u ze goed bouwt en runt — als producten met echte gebruikers, niet als verplichte infrastructuur waar niemand van houdt.

Kernbegrippen#

Een platform is in deze context een set capaciteiten waarop andere teams bouwen in plaats van ze zelf te bouwen. De nuttigste moderne kadering is dat een platform een product met interne gebruikers is. Haar klanten zijn uw eigen ontwikkelaars, leveringsteams en partnerorganisaties, en haar succes wordt gemeten zoals dat van elk product: aan adoptie, aan de ervaring van de mensen die haar gebruiken en aan de uitkomsten die zij mogelijk maakt.

Verscheidene verwante ideeën liggen eronder. Gedeelde diensten (shared services) is het oudere organisatiepatroon om een capaciteit eenmaal voor veel delen van een organisatie te bieden in plaats van haar in elk te dupliceren. Digitale publieke infrastructuur breidt dit uit tot het niveau van een hele samenleving — de gedeelde, herbruikbare, interoperabele bouwstenen (identiteit, betalingen, gegevensuitwisseling) waarop publieke en private diensten worden gebouwd. “Government as a platform”, een uitdrukking van Tim O’Reilly die digitale-overheidsteams wereldwijd hebben overgenomen, past dezelfde logica toe op de staat: de overheid biedt gemeenschappelijke componenten, en departementen stellen er diensten uit samen in plaats van elk de volledige stack te bouwen.

Technisch stellen platforms hun capaciteiten vaak beschikbaar via een application programming interface (API) — een omschreven contract waarmee het ene systeem de capaciteit van het andere kan gebruiken zonder haar binnenkant te kennen. Ze putten vaak uit cloudmodellen van platform as a service (PaaS), en gedeelde nationale platforms leunen doorgaans op multitenancy, waarbij één enkele instantie vele organisaties bedient en hun data en configuratie gescheiden houdt.

Drie begrippen bepalen of een platform helpt of schaadt. Het eerste is cognitieve belasting: een goed platform vermindert wat een leveringsteam in zijn hoofd moet houden, zodat het team zich kan concentreren op het klinische of zorgprobleem waarvoor het bestaat. Het tweede is de “verharde weg” of “golden path” — een goed ondersteunde, eigenzinnige standaardmanier voor een veelvoorkomende taak die gemakkelijker te volgen is dan te vermijden, aangeboden via zelfbediening in plaats van poortwachterschap. Het derde is het vermijden van vendor lock-in, daarom moeten platforms op open normen worden gebouwd zodat organisaties tussen leveranciers kunnen wisselen zonder buitensporige overstapkosten.

Specifiek in de gezondheidszorg maken nationale gedeelde diensten al deel uit van het landschap. Historische programma’s als NHS Connecting for Health richtten de NHS Spine op, een set nationale diensten met kerngegevens als de Personal Demographics Service. Moderne equivalenten zijn nationale API’s, NHS login voor authenticatie van burgers en NHS Notify voor berichten — capaciteiten die worden aangeboden zodat afzonderlijke diensten ze niet hoeven te herbouwen. Waar een platform een gemeenschappelijke manier biedt om te bewijzen wie iemand is, stelt het vaak single sign-on beschikbaar zodat een clinicus eenmaal authenticeert in plaats van herhaaldelijk. Dit onderwerp gaat over hoe u zulke platforms bouwt en runt; de details van wie u bent en wat u mag doen horen bij Onderwerp 4.2 — Identiteits- en toegangsbeheer, en de normen waarmee systemen data uitwisselen horen bij Onderwerp 4.3 — Interoperabiliteit en datastandaarden.

Beste praktijken#

1. Behandel het platform als product, niet als project. Een platform heeft een roadmap, een productmanager, doorlopende financiering en gebruikers wier tevredenheid u meet — geen einddatum en overdracht. Projecten eindigen en vervallen; platforms moeten onbeperkt worden gerund omdat teams ervan afhankelijk raken. Financier en bemens dienovereenkomstig, en zie Onderwerp 5.0 — Productgestuurd werken voor de operationele discipline die dit impliceert.

2. Begin met het dunste levensvatbare platform. Bouw de kleinste set gedeelde capaciteiten die teams werkelijk ontlast en voeg alleen meer toe wanneer echte vraag en echte pijn dat rechtvaardigen. Dit idee van het “dunste levensvatbare platform”, geïntroduceerd in Onderwerp 1.1 — Het operationele model, beschermt tegen het meest voorkomende falen: een ambitieus centraal platform dat alles probeert te doen, te laat arriveert en niemand past. Laat het platform groeien uit bewijs van gebruik, niet uit architecturale aspiratie.

3. Maak de verharde weg de gemakkelijke weg. Een platform verdient adoptie door het ondersteunde pad sneller en eenvoudiger te maken dan er zelf een bouwen — via zelfbediening bij aansluiting, duidelijke documentatie, sandboxes en verstandige standaardwaarden met klinische veiligheid en toegankelijkheid ingebouwd. Als het platform gebruiken langzamer of pijnlijker is dan eromheen gaan, zullen teams eromheen gaan en hebt u geld besteed aan het creëren van een knelpunt. Ontwerp voor het eerste uur van de ontwikkelaar en zijn slechtste dag.

4. Meet succes aan adoptie en gebruikerservaring, niet aan bestaan. De juiste maten zijn hoeveel teams het platform vrijwillig gebruiken, hoe lang aansluiting duurt, hoe vaak het platform beschikbaar is en hoe haar gebruikers de ervaring waarderen. Ijdelheidsmaten als het aantal uitgerolde diensten vertellen u niets over of teams worden geholpen. Instrumenteer het platform, voer regelmatig onderzoek uit met de teams die erop bouwen en behandel een dalende of stagnerende adoptiecurve als productprobleem om te herstellen, niet als nalevingsprobleem om af te dwingen.

5. Bouw op open normen en houd uitstappen goedkoop. Geef de voorkeur aan open, breed aangenomen normen en interfaces zodat noch u noch de teams op uw platform vastzitten. Documenteer hoe een team zou vertrekken en zorg dat het dat ook kan. Paradoxaal genoeg maakt uitstappen gemakkelijk maken dat teams zich comfortabel voelen om aan te sluiten, en het houdt het platform eerlijk omdat het zijn plek moet verdienen in plaats van te leunen op gevangenschap. Dit vermindert rechtstreeks de vendor lock-in over het bredere bestand besproken in Onderwerp 4.0 — Technische architectuur, cloud en legacy.

6. Wees expliciet over wie betaalt en wie beslist. Een gedeeld platform heeft vooraf een financieringsmodel en een bestuursmodel nodig: of het centraal wordt gefinancierd, wordt doorbelast aan gebruikers of een hybride is, en hoe haar roadmap over concurrerende tenants wordt geprioriteerd. Dubbelzinnigheid hier maakt van platforms politieke slagvelden. Publiceer het model, geef gebruikers een echte stem in de roadmap en herzie het naarmate het platform groeit.

7. Run het platformteam met duidelijke verantwoordelijkheden en grenzen. Organiseer rond een toegewijd platformteam wiens taak is stream-aligned leveringsteams mogelijk te maken via zelfbediening, zoals beschreven in de patronen van Team Topologies in Onderwerp 7.0 — Teamstructuren, rollen en verantwoordelijkheden. Houd de interface tussen platform en afnemers expliciet — wat het platform belooft, wat niet en hoe ondersteuning te krijgen — zodat het platform mogelijk maakt in plaats van poortwachter te zijn.

8. Ontwerp vanaf het begin voor multitenancy, isolatie en veiligheid. Als veel organisaties één platform zullen delen, zijn scheiding van hun data, configuratie en faaldomeinen een fundamentele eis, geen latere functie. In gezondheid en zorg is dit ook een eis van informatiebeheer en klinische veiligheid: het incident van de ene tenant mag de patiënten van een andere niet blootstellen of in gevaar brengen. Bouw isolatie, waarneembaarheid per tenant en een klinisch veiligheidsdossier voor het platform zelf onder DCB0129 in.

Vragen om met uw team te bespreken#

1. Wat is het dunste platform dat onze teams werkelijk zou ontlasten, en wat zijn wij verleid te bouwen wat we niet zouden moeten? Het is gemakkelijk een veelomvattend platform op een whiteboard te ontwerpen en moeilijk er een uit te leveren waar teams van houden. Begin bij de echte, herhaalde pijn die uw leveringsteams nu voelen — de capaciteit die drie of meer teams elk opnieuw bouwen — en weersta alles toe te voegen wat slechts één team nodig heeft of waar nog niemand om heeft gevraagd. Vraag welke capaciteiten werkelijk gemeenschappelijk zijn tegenover welke slechts van een afstand op elkaar lijken maar verschillen in de details die klinisch tellen. Overweeg de kosten van het fout doen: een voorbarige gedeelde capaciteit waar teams omheen moeten werken is erger dan geen platform. Spreek een expliciete lijn af tussen wat het platform nu zal bezitten en wat het bewust uitstelt. Herzie die lijn volgens schema en verschuif items alleen wanneer vraag en pijn zijn aangetoond. De discipline is nee zeggen tegen goede ideeën die hun plek nog niet verdienen.

2. Hoe financieren wij het platform en beslissen wij over de roadmap wanneer tenants het oneens zijn? Een platform bedient veel teams met concurrerende prioriteiten, en op het moment dat twee belangrijke tenants onverenigbare dingen willen, wordt uw bestuur getest. Besluit nu of het platform centraal wordt gefinancierd, wordt doorbelast aan gebruikers of hybride is, en wees eerlijk over de prikkels die elk model creëert: doorbelasting kan adoptie onderdrukken, terwijl centrale financiering het platform van gebruikersbehoefte kan losmaken. Besluit wie de roadmap houdt, hoe tenants haar beïnvloeden en hoe u arbitreert tussen de urgente behoefte van een grote organisatie en de basale behoefte van een kleine. Overweeg billijkheid expliciet, omdat een doorbelastingsmodel kleinere of armere organisaties uit gedeelde veiligheidscapaciteiten kan prijzen. Spreek af hoe u omgaat met een tenant die een functie wil financieren die de anderen niet willen. Schrijf het model op en publiceer het, zodat beslissingen als bestuur voelen en niet als vriendjespolitiek. Verbind u er dan aan het te herzien naarmate het platform en haar gebruikersbasis groeien.

3. Hoe zullen wij weten dat het platform geliefd is in plaats van louter verplicht, en wat doen wij als het dat niet is? Een platform kan technisch deugdelijk, officieel vereist en stilletjes gehaat zijn — en een verplicht maar ongeliefd platform stapelt omwegen, schaduwsystemen en wrok op. Besluit vooraf welke signalen u de waarheid vertellen: vrijwillige adoptie waar teams een keuze hebben, tijd tot eerste succes voor een nieuw team, beschikbaarheid en incidentgeschiedenis, en directe terugkoppeling van de ontwikkelaars die het gebruiken. Praat over hoe u eerlijke terugkoppeling verzamelt wanneer u ook macht over uw gebruikers hebt, omdat mensen terughoudend zijn een platform te bekritiseren dat zij moeten gebruiken. Spreek af hoe een gezonde adoptiecurve eruitziet en welke drempel een serieuze herbezinning zou triggeren. Besluit of u ooit bereid zou zijn het platform uit te faseren of te vervangen als het bewijs dat eiste. Bereid zijn te horen dat uw platform niet werkt is wat het werkend houdt. Het alternatief is de waarheid pas te ontdekken wanneer een grote dienst eromheen routeert.

4. Hoe houden wij uitstappen goedkoop, en zou een team op ons platform werkelijk kunnen vertrekken als het dat nodig had? Het is gemakkelijk te beweren dat u op open normen bent gebouwd en iets heel anders te bewijzen dat een team zonder buitensporige herschrijving kan weglopen. Praat eerlijk over waar lock-in binnensluipt — een bedrijfseigen interface, een ongedocumenteerd gegevensformaat, een nationale afhankelijkheid zonder alternatief — en of de kosten van vertrek stilletjes stijgen. Besluit wie verantwoordelijk is een uitstaproute te documenteren en periodiek te testen, in plaats van aan te nemen dat er een bestaat. Overweeg dat in gezondheid en zorg het lock-inrisico zich opstapelt: een nationaal platform gebouwd op gevangenschap kan een heel stelsel een generatie vastzetten, en de teams die overstapkosten het minst kunnen opvangen zijn gewoonlijk de kleinste aanbieders. Een eerlijk antwoord noemt de specifieke afhankelijkheden die u moeilijk zou kunnen ontwarren, beschrijft een concrete uitstap voor minstens één echte tenant en behandelt overdraagbaarheid als een functie die u onderhoudt en niet als slogan die u herhaalt. Onthoud dat uitstappen gemakkelijk maken vaak is wat teams zich comfortabel laat voelen om aan te sluiten.

5. Draagt het platform zijn eigen klinisch veiligheidsdossier, en hoe voorkomen wij dat het falen van de ene tenant de patiënten van een andere schaadt? Wanneer veel organisaties één platform delen, draagt haar leidingwerk klinisch risico namens elke dienst erop gebouwd, dus een defect in patiëntmatching of een lek tussen tenants is niet het probleem van één team maar van iedereen. Besluit of het platform een eigen DCB0129-veiligheidsdossier heeft waarop afnemende teams werkelijk kunnen vertrouwen, of dat elke dienst stilletjes hetzelfde gedeelde risico opnieuw beoordeelt. Bespreek hoe u data, configuratie en faaldomeinen van tenants isoleert en hoe u zou weten als die isolatie werd doorbroken — waarneembaarheid per tenant is het verschil tussen een incident indammen en het laat ontdekken. Overweeg ook de gevolgen voor informatiebeheer: een onderzoek naar één tenant mag niet vereisen dat dossiers van een andere worden blootgelegd. Een eerlijk antwoord kan wijzen op een onderhouden veiligheidsdossier, een geteste isolatiegrens en een duidelijke verklaring van wat het platform belooft over veiligheid versus wat de verantwoordelijkheid van elke dienst blijft. Veiligheid en isolatie behandelen als fundamenteel en niet als latere functies is wat teams borging laat erven in plaats van erop te gokken.

6. Waar ligt de lijn tussen het platformteam en de teams die het bedient, en hoe voorkomen wij dat het platform een knelpunt wordt? Een gedeeld platform kan elk team versnellen of ze allemaal vertragen tot de snelheid van één centrale wachtrij, en het verschil zit in hoe scherp u de interface tussen platform en afnemers hebt getrokken. Besluit wat het platform bezit en belooft, wat het uitdrukkelijk niet doet en hoe een team ondersteuning krijgt zonder voor routinewerk op een ticket te wachten. Praat over zelfbediening als standaard: als aansluiting, inrichting of een veelvoorkomende wijziging het platformteam met de hand laten handelen, hebt u een poort gebouwd en geen verharde weg. Overweeg de afspraak over cognitieve belasting in het hart van een goed platform — het moet verminderen wat een leveringsteam in zijn hoofd moet houden zodat het zich kan concentreren op het klinische probleem, niet een nieuwe laag toevoegen om mee te onderhandelen. Een eerlijk antwoord noemt de taken die nog als knelpunt via het platformteam lopen, stelt een richting om ze zelfbediening te maken en is openhartig over waar het platform mogelijk maakt versus waar het poortwachter speelt.

In de praktijk: een voorbeeld uit gezondheid en zorg#

Een Integrated Care System (ICS) dat verscheidene NHS-ziekenhuizen, gemeenschapsaanbieders en de volwassenensociale zorg van een lokale overheid (county council) omvat loopt steeds tegen dezelfde muur. Elke nieuwe digitale dienst — een virtuele afdeling, een formulier voor zelfverwijzing naar fysiotherapie in de gemeenschap, een instrument voor toezicht op verzorgingshuizen — besteedt haar eerste drie maanden aan het herbouwen van dezelfde fundamenten: bewijzen wie de patiënt is, de rol van de professional controleren, sms-herinneringen versturen en een controlespoor schrijven. De patiëntmatching van het team van de virtuele afdeling blijkt zwakker dan die van het fysiotherapieteam, en een bijna-ongeval doet zich voor wanneer een herinnering naar de verkeerde persoon wordt gestuurd. Het digitale leiderschap van het ICS herkent het patroon: zij betalen vele malen voor capaciteiten die eenmaal zouden moeten bestaan, en de variatie is een veiligheidsrisico.

In plaats van een groots ICS-platform in opdracht te geven beginnen zij dun. Zij zetten één enkele gedeelde dienst op die één ding goed doet: zij wikkelt NHS login en de nationale Personal Demographics Service achter een schone, gedocumenteerde API met een sandbox, zodat elk team via één ondersteund pad de identiteit van een burger kan verifiëren en een bevestigd demografisch dossier kan opvragen. Een klein platformteam van vijf behandelt haar als product. Zij publiceren een gids voor de verharde weg, bieden zelfbediening bij aansluiting en stellen als doel dat een nieuw team binnen een dag zijn eerste succesvolle aanroep doet. Cruciaal is dat zij haar niet verplichten. Zij maken haar de gemakkelijkste optie en laten het team van de virtuele afdeling de eerste bereidwillige gebruiker zijn.

Het financieringsmodel wordt openlijk afgesproken: het ICS financiert de kern van het platform de eerste twee jaar centraal zodat adoptie niet wordt onderdrukt door doorbelasting, met een toetsing na achttien maanden. Een groep over aanbieders heen, inclusief de lokale overheid, houdt de roadmap en komt maandelijks bijeen. Wanneer het fysiotherapieteam daarna om een capaciteit voor meldingen vraagt, voegt het platformteam een dunne wrapper rond NHS Notify toe in plaats van berichten vanaf nul te bouwen — eenmaal bouwen, vele malen gebruiken. Binnen een jaar hebben zes teams de identiteitsdienst vrijwillig overgenomen, is aansluiting teruggegaan van maanden naar dagen en publiceert het platformteam haar beschikbaarheid en adoptiecijfers openlijk. Wanneer het maatwerksysteem van één ziekenhuis om het platform heen routeert, behandelt het team dat als onderzoek en niet als weerspannigheid, leert de wrijving die tot de beslissing leidde en herstelt die. Het platform groeit omdat teams het kiezen, en het ICS erft één enkele, goed geteste, toegankelijke manier om de riskante, gemeenschappelijke dingen te doen.

Sectorperspectieven#

Startup#

Een startup in gezondheidstechnologie bouwt zelden platforms voor anderen; zij bouwt erop. Uw hefboom komt van het gebruik van nationale en cloudplatforms — NHS login, nationale API’s, de beheerde diensten van een cloudaanbieder — zodat uw kleine team zijn energie besteedt aan het klinische probleem en niet aan het opnieuw uitvinden van identiteit of berichten. Let toch op lock-in: kies open normen en houd uw data overdraagbaar, omdat de capaciteit die u vandaag goedkoop huurt morgen de afhankelijkheid kan worden die u beperkt. Houd intern uw eigen “platform” dun tot bijna onzichtbaar; een team van twee heeft geen abstractie van een golden path nodig, het moet uitleveren. De discipline is weten wanneer u genoeg bent gegroeid dat een gedeelde interne capaciteit het waard is te worden onttrokken.

Klein bedrijf#

Een gevestigde kleine aanbieder — een huisartsenpraktijk, een gemeenschapsapotheek, een verzorgingshuis of een kliniek met één vestiging — is vrijwel altijd een afnemer van platforms met weinig of geen eigen digitale capaciteit, dus de platforms waarvan zij afhangt stellen feitelijk haar vloer voor veiligheid en billijkheid. Uw praktische taak is te kiezen voor ondersteunde gedeelde diensten boven maatwerkbouw die u niet kunt bemensen of onderhouden, met de voorkeur voor nationale capaciteiten als NHS login, opvraag van demografische gegevens en NHS Notify die al het werk voor toegankelijkheid en klinische veiligheid dragen dat u nooit alleen zou kunnen financieren. Sta erop dat aansluiting werkelijk zelfbediening is en dat de documentatie duidelijk is, omdat u geen platformteam hebt om naar te escaleren en zich geen lang integratieproject kunt veroorloven. Let goed op het financieringsmodel: een doorbelast platform kan een kleine aanbieder prijzen uit juist de veiligheidscapaciteiten die zij het meest nodig heeft, dus dring aan op billijke toegang en breng het ter sprake in elk bestuur van de roadmap dat u kunt bereiken. Houd ook de uitstap in het oog, omdat lock-in bij een bedrijfseigen leverancier het moeilijkst te ontvluchten is wanneer u geen eigen technisch personeel hebt om u te laten migreren. De winst is dat een goed gedeeld platform u normen laat erven die u niet zou kunnen bouwen, en u aan dezelfde plichten laat voldoen als grote organisaties zonder hun middelen.

Grote onderneming#

Een groot ziekenhuis of nationaal orgaan heeft de schaal om echte platforms te rechtvaardigen en de bureaucratie om ze te verpesten. Het risico is een centraal platformteam dat een ivoren toren wordt — architecturaal elegant, traag in reactie en losgekoppeld van de leveringsteams die het zogenaamd dient. Ga hier tegenin door platforms te financieren als langlevende producten met hun eigen roadmaps en gebruikersonderzoek, en door ze te meten aan adoptie en ontwikkelaarservaring in plaats van naleving van het mandaat. Multitenancy, isolatie en een klinisch veiligheidsdossier voor het platform zelf worden op deze schaal essentieel. De prijs is enorm: een capaciteit eenmaal naar hoge norm gebouwd en door tientallen diensten geërfd, die de vloer voor de hele organisatie verhoogt.

Overheid#

Op nationaal en stelselniveau is de kadering digitale publieke infrastructuur en government as a platform: bouw gemeenschappelijke componenten — identiteit, meldingen, opvraag van demografische gegevens, gegevensuitwisseling — waaruit honderden organisaties diensten samenstellen. De inzet voor openheid is hier het hoogst, omdat een nationaal platform gebouwd op bedrijfseigen lock-in een heel zorgstelsel een generatie kan vastzetten. Bestuur en financiering moeten openlijk worden uitgewerkt, met echte invloed voor de kleinere en armere organisaties die gedeelde platforms mede bestaan om te beschermen. De verleiding om te verplichten is op dit niveau het sterkst en het gevaarlijkst; een nationaal platform dat vereist maar ongeliefd is kweekt schaduwsystemen over het hele land. Verdien adoptie door kwaliteit en ondersteuning en behandel elke omweg als signaal om te verbeteren.

Veelvoorkomende faalpatronen#

• Het knelpunt. Elk team moet wachten op het centrale platformteam om iets te doen, zodat het platform levering vertraagt in plaats van versnelt. De remedie is zelfbediening: teams moeten kunnen aansluiten en handelen zonder ticket.
• De ivoren toren. Het platform is ontworpen door mensen ver van levering, is technisch bewonderenswaardig en past geen enkel echt team. De remedie is het platform runnen als product met voortdurend gebruikersonderzoek.
• Verplicht maar ongeliefd. Het platform wordt bij beleid vereist maar in de praktijk omzeild en stapelt schaduwsystemen en wrok op. De remedie is adoptie te verdienen door kwaliteit en te luisteren wanneer teams eromheen routeren.
• Het alles-platform. Een te ambitieuze reikwijdte betekent dat het platform te laat arriveert, te veel doet en niets goed. De remedie is het dunste levensvatbare platform, gegroeid uit bewijs van vraag.
• Sluipende lock-in. Het platform bindt teams stilletjes aan een bedrijfseigen leverancier of interface, en de kosten van vertrek worden buitensporig. De remedie is open normen en een gedocumenteerde, geteste uitstaproute.
• Financieringsdubbelzinnigheid. Niemand heeft afgesproken wie betaalt of beslist, dus het platform verhongert of wordt een politiek slagveld. De remedie is een expliciet, gepubliceerd model voor financiering en bestuur.
• Veiligheid als bijzaak. Het platform heeft geen eigen klinisch veiligheidsdossier, zodat elke afnemende dienst niet-beoordeeld risico erft. De remedie is het DCB0129-veiligheidsdossier van het platform als fundamenteel te behandelen.

Volwassenheidsmodel#

Checklist#

• Het platform heeft een benoemde productmanager, een roadmap en doorlopende (geen project)financiering.
• U bent begonnen bij het dunste levensvatbare platform en kunt noemen wat u bewust hebt uitgesteld.
• Het ondersteunde pad is werkelijk sneller en gemakkelijker dan teams die er zelf een bouwen.
• Nieuwe teams kunnen via zelfbediening aansluiten, met een sandbox en duidelijke documentatie.
• U meet adoptie, tijd tot eerste succes, beschikbaarheid en ontwikkelaarservaring.
• Het financieringsmodel (centraal, doorbelast of hybride) is afgesproken en gepubliceerd.
• Bestuur van de roadmap geeft tenants, ook kleinere organisaties, een echte stem.
• Het platform is op open normen gebouwd en er bestaat een gedocumenteerde uitstaproute.
• Multitenant isolatie van data en falen is ingebouwd, niet erop geschroefd.
• Het platform heeft een eigen klinisch veiligheidsdossier (DCB0129) waarop afnemende teams kunnen vertrouwen.
• U behandelt teams die om het platform heen routeren als onderzoek, niet als weerspannigheid.

Belangrijkste bronnen#

• GOV.UK Service Manual en het schrijven van de Government Digital Service over government as a platform en gemeenschappelijke componenten.
• Matthew Skelton en Manuel Pais, Team Topologies — platformteams, dunste levensvatbare platform en cognitieve belasting.
• Ontwikkelaars- en API-richtlijnen van NHS England (NHS login, NHS Notify, nationale API’s en de Spine-diensten).
• Normen DCB0129 en DCB0160 voor klinisch risicobeheer voor IT in de gezondheidszorg.
• De Wereldbank en de Verenigde Naties over digitale publieke infrastructuur en herbruikbare publieke bouwstenen.
• Tim O’Reilly, “Government as a Platform”, in Open Government (O’Reilly Media).

Referenties#

1. Digital public infrastructure — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_infrastructure
2. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
3. API (application programming interface) — Wikipedia — https://en.wikipedia.org/wiki/API
4. Platform as a service — Wikipedia — https://en.wikipedia.org/wiki/Platform_as_a_service
5. Multitenancy — Wikipedia — https://en.wikipedia.org/wiki/Multitenancy
6. Cognitive load — Wikipedia — https://en.wikipedia.org/wiki/Cognitive_load
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
9. NHS Connecting for Health (including the NHS Spine and Personal Demographics Service) — Wikipedia — https://en.wikipedia.org/wiki/NHS_Connecting_for_Health
10. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
11. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton and Manuel Pais (IT Revolution Press) — https://teamtopologies.com/book
12. Government as a Platform — Tim O'Reilly, in Open Government (O'Reilly Media) — https://www.oreilly.com/library/view/open-government/9781449381936/ch02.html
13. GOV.UK Service Manual — Government Digital Service — https://www.gov.uk/service-manual
14. NHS login and NHS England developer/API guidance — NHS England — https://digital.nhs.uk/services/nhs-login
15. Clinical risk management: its application in the manufacture of health IT systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation