Onderwerp 3.5 — Leveringslevenscycli

In één zin: Een leveringslevenscyclus is de reeks fasen en beslispoorten — Discovery, Alpha, Beta, Live en uiteindelijk uitfasering — waardoor een digitale dienst zich beweegt, met klinische veiligheid, informatiebeheer en borging in elke fase geweven in plaats van er aan het eind op vastgeschroefd.

Waarom dit ertoe doet in gezondheid en zorg#

Een levenscyclus is hoe een organisatie een idee omzet in een veilige live dienst en haar uiteindelijk verantwoord uitfaseert. In gezondheid en zorg draagt elke overgang wettelijk en klinisch gewicht: u kunt geen systeem inzetten dat patiëntenzorg raakt zonder klinisch veiligheidsdossier, en u kunt geen vertrouwelijke patiëntgegevens verwerken zonder rechtmatige grondslag en een voltooide gegevensbeschermingseffectbeoordeling (DPIA). Een levenscyclus die deze behandelt als papierwerk aan het eind van het project produceert diensten die laat zijn, onveilig, of beide.

De inzet is asymmetrisch. Een consumentenapp die een bug uitlevert ergert gebruikers; een gedeeld zorgdossier dat een bug uitlevert kan een clinicus de allergieën van de verkeerde patiënt tonen. Daarom verankert de NHS het faseringsmodel van GOV.UK en de normen voor klinisch risicobeheer DCB0129 en DCB0160 in dezelfde levenscyclus. De levenscyclus goed krijgen is geen bestuurlijke netheid — het is het mechanisme waarmee veiligheid, billijkheid en waarde voor publiek geld werkelijk worden geleverd in plaats van louter beloofd.

Leiders hebben de levenscyclus ook nodig omdat zij voortgang leesbaar maakt. Benoemde fasen en poorten laten een bestuur zien waar een dienst staat, welk bewijs bestaat en welke beslissing aanstaande is — en vervangen de mist van “het is bijna klaar” door een verdedigbare, gefaseerde toezegging van publiek geld.

Kernbegrippen#

Het faseringsmodel: Discovery → Alpha → Beta → Live. De dienstnormen van de NHS en GOV.UK definiëren vier fasen. Discovery (zie Onderwerp 3.4 — Discoveryfasen) begrijpt het probleem. Alpha bouwt wegwerpprototypes om te toetsen of een oplossing zou kunnen werken en de riskantste aannames weg te werken. Beta bouwt de echte, eerst-besloten-dan-openbare dienst op productie-infrastructuur, doorontwikkelend met echte gebruikers op groeiende schaal. Live runt de dienst in voortdurende werking, nog steeds doorontwikkelend, tot zij wordt uitgefaseerd. De fasen zijn een oprit van risicovermindering: elke legt meer geld vast en stelt meer gebruikers bloot, gerechtvaardigd door bewijs uit de vorige.

Voortdurende iteratie, geen lopende band. De fasen zijn geen eenrichtingswaterval. Een dienst in bèta kan voor een moeilijke functie terugkeren naar alfa; een live dienst itereert voortdurend. De waarde van het model zit in zijn poorten, niet in een belofte dat werk één kant op stroomt.

Agile, waterval en hybride. Waterval legt de reikwijdte vooraf vast en gaat in volgorde — alleen geschikt waar eisen werkelijk stabiel en kenbaar zijn (een datacentrummigratie, een verplichte regelgevende wijziging). Agile levert in kleine increments en inspecteert en past aan — geschikt voor de onzekerheid van gebruikersgerichte diensten. Hybride is de eerlijke werkelijkheid van de meeste grote zorgprogramma’s: agile productteams die opereren binnen een omhulsel van mijlpalen en financiering dat de organisatie en haar toezichthouders vereisen. Stem de methode af op de onzekerheid, niet op de mode.

Service-assessments en normpoorten. Bij de overgangen tussen fasen — vooral van alfa naar bèta en vóór openbare lancering — staan diensten van de NHS en GOV.UK voor een service-assessment: een onafhankelijk panel dat het werk toetst aan de punten van de Service Standard (gebruikersbehoefte, toegankelijkheid, beveiliging, betrouwbaarheid, team, technologiekeuzes). Slagen is de poort om meer uit te geven en meer gebruikers bloot te stellen. Het assessment is peer review op bewijs, geen stempel.

Klinische veiligheid en informatiebeheer als draden door de levenscyclus. DCB0129 (voor de fabrikant/leverancier) en DCB0160 (voor de inzettende gezondheids- of zorgorganisatie) vereisen een systeem voor klinisch risicobeheer, een gevarenlogboek en een rapport van het klinische veiligheidsdossier goedgekeurd door een benoemde, opgeleide klinischeveiligheidsfunctionaris (Clinical Safety Officer, CSO). Informatiebeheer vereist een rechtmatige grondslag, een DPIA en naleving van de Caldicott-beginselen. Beide zijn draden die door discovery, alfa, bèta en live lopen — geen poorten aan het eind.

Uitfasering (decommissioning). Een levenscyclus heeft een einde. Een dienst veilig uitfaseren — data migreren of archiveren onder bewaarwetgeving, gebruikers omleiden, clinici informeren en dossiers bewaren — is een fase op zich, en een van de meest verwaarloosde.

Beste praktijken#

1. Gebruik de fasen als poorten van risicovermindering, niet als kalendermijlpalen. Laat de beslissing van elke fase zijn: “is er genoeg bewijs om de volgende tranche geld en gebruikers te rechtvaardigen?” Een fase die eindigt omdat de datum aanbrak in plaats van omdat het bewijs binnen is, heeft het punt van de poort overgeslagen.

2. Weef klinische veiligheid in vanaf alfa, niet vóór Live. Benoem een klinischeveiligheidsfunctionaris en open het gevarenlogboek zodra een oplossingsvorm bestaat. Gevaren die in alfa worden geïdentificeerd zijn goedkoop weg te ontwerpen; gevaren die bij go-live worden gevonden zijn een lanceringsblokkerende crisis. Het veiligheidsdossier rijpt mee met de dienst, zodat goedkeuring volgens DCB0129/0160 een samenvatting is van reeds verricht werk, geen stormloop.

3. Begin de DPIA en het IB-werk in discovery en houd ze levend. Datastromen, rechtmatige grondslag en Caldicott-overwegingen vormen de architectuur, dus breng ze aan het licht terwijl de architectuur nog zacht is. Een DPIA die na de bouw is geschreven is een documentatieoefening; een die naast het ontwerp is geschreven vermindert risico werkelijk en voorkomt herwerk.

4. Automatiseer het pad naar productie met CI/CD en DevOps. Continue integratie en continue levering — geautomatiseerde pijplijnen voor bouwen, testen en uitrollen — laten een team kleine, omkeerbare wijzigingen veilig en vaak uitleveren. In een veiligheidskritisch domein is het vermogen een oplossing in minuten uit te rollen en schoon terug te draaien zelf een veiligheidsmaatregel. Koppel het aan monitoring, alarmering en infrastructure-as-code zodat de live dienst waarneembaar en reproduceerbaar is.

5. Stem de methode af op de onzekerheid. Gebruik agile waar gebruikersbehoeften onzeker zijn en discovery u nog dingen leert; aanvaard watervalachtige volgorde alleen waar eisen werkelijk vaststaan en het risico van verandering laag is. Wees expliciet over het draaien van een hybride — agile teams binnen een programmaomhulsel — in plaats van te doen alsof één methode alles bestuurt, wat niemand voor de gek houdt en iedereen frustreert.

6. Behandel het service-assessment als ontwerpinstrument, niet als examen. Haal beoordelaars van borging, klinische veiligheid, beveiliging en toegankelijkheid vroeg en vaak erbij, zodat het formele assessment een dienst bevestigt die al naar de norm is gebouwd. Teams die de norm pas de week vóór het assessment ontmoeten falen langzaam en duur; teams die haar internaliseren slagen als bijproduct.

7. Blijf itereren in Live — en voorzie het van middelen. Een dienst houdt niet op een team nodig te hebben wanneer zij live gaat. Live is waar echt gebruik de laatste ongelijkheden, de zeldzame-maar-ernstige klinische randgevallen en de toegankelijkheidsgaten blootlegt. Financier een vast productteam voor het operationele leven van de dienst (zie Onderwerp 5.0 — Productgestuurd werken); een live dienst zonder team is technische schuld die klinisch risico opbouwt.

8. Plan uitfasering voordat u haar nodig hebt. Besluit tijdens het bouwen hoe de dienst uiteindelijk zal worden uitgefaseerd: bewaring en migratie van data onder dossierbeheerwetgeving, omleiding van gebruikers, informeren van clinici en archivering van het klinische veiligheidsdossier en het controlespoor. Een ongeplande uitfasering laat data en gebruikers stranden; een geplande is een beheerste, controleerbare fase.

Vragen om met uw team te bespreken#

1. Worden onze fasepoorten werkelijk door bewijs bestuurd, of zijn ze stilletjes data in een plan geworden? De hele waarde van het model Discovery–Alpha–Beta–Live is dat elke overgang meer geld vastlegt en meer gebruikers blootstelt alleen wanneer het bewijs van de vorige fase dat rechtvaardigt; zodra een poort vuurt omdat het kwartaal eindigde in plaats van omdat het bewijs binnen is, houdt de oprit op risico te verminderen en wordt zij “waterval in agile kostuum”. Deze vraag laat een team eerlijk kijken naar zijn laatste overgangen en vragen wat er zou zijn gebeurd als het bewijs “nog niet” had gezegd — was er ruimte om vast te houden, een bèta voor een moeilijke functie terug te laten keren naar alfa, of was de go-livedatum politiek onverplaatsbaar? De spanning om te bespreken is die tussen de behoefte van de organisatie aan leesbare mijlpalen op het bestuursschema en de werkelijkheid dat veilige diensten zich bewegen op het tempo van bewijs, en hybride levering leeft juist in die wrijving. Concrete invalshoeken zijn de specifieke beslissing en het bewijs noemen dat bij de volgende poort verschuldigd is, controleren of “sprints” werkelijk reikwijdte veranderen of slechts een vast plan volgen en vragen wie bevoegd is een poort uit te stellen zonder carrièrerisico. Een goed antwoord kan wijzen op een echt geval waarin bewijs het plan veranderde en kan verwoorden welk bewijs de volgende toezegging van publiek geld en gebruikers zou rechtvaardigen — of blokkeren.

2. Zijn klinische veiligheid en informatiebeheer levende draden door elke fase, of papierwerk dat wij voor Live denken af te maken? In gezondheid en zorg zijn de DPIA en het klinische risicowerk van DCB0129/0160 geen goedkeuringen aan het eind van het project maar draden die vanaf alfa architectuur en ontwerp moeten vormen, omdat een gevaar dat vroeg weg wordt ontworpen goedkoop is terwijl een gevaar dat bij go-live wordt ontdekt een lanceringsblokkerende crisis is — of erger, druk om het veiligheidsdossier erdoor te wuiven. Deze vraag brengt aan het licht of een benoemde, opgeleide klinischeveiligheidsfunctionaris en een open gevarenlogboek bestaan zodra een oplossingsvorm verschijnt, en of de DPIA en analyse van de rechtmatige grondslag in discovery begonnen toen de datastromen nog zacht genoeg waren om te veranderen. De afweging die het bespreken waard is, is de gevoelde last van dit voortdurend doen versus de veel grotere kosten en het klinische risico van een retrofit, vooral voor kleinere teams of startups waar nog geen toezichthouder meekijkt maar de DCB0129-verplichting de fabrikant sowieso bindt. Overweeg concreet bewijs: toont het gevarenlogboek gevaren gevonden en beperkt in alfa, leest het veiligheidsdossier als samenvatting van reeds verricht werk en herleidt de DPIA naar echte ontwerpbeslissingen? Een eerlijk antwoord onderscheidt een team dat zijn veiligheidsdossier naast de dienst laat rijpen van een dat afstevent op een documentatiestormloop de maand voor de lancering.

3. Hoe zal deze dienst in Live worden gerund en uiteindelijk worden uitgefaseerd — en wie is daarvoor gefinancierd? Levenscycli hebben een lange staart die organisaties routinematig onderfinancieren: Live is waar echt gebruik de laatste ongelijkheden, zeldzame-maar-ernstige klinische randgevallen en toegankelijkheidsgaten blootlegt, en het heeft een vast productteam, monitoring en snelle, omkeerbare uitrol nodig in plaats van een team dat bij go-live wordt ontbonden en de dienst laat rotten en stilletjes klinisch risico opbouwt. Even verwaarloosd is uitfasering — een dienst afsluiten onder bewaarwetgeving, data migreren of archiveren, gebruikers omleiden, clinici informeren en het gevarenlogboek en controlespoor bewaren — wat voor een nationaal systeem een groot programma op zich is, geen bijzaak wanneer de vervanging arriveert. De spanning om te bespreken zijn jaarlijkse financieringscycli en de druk een project bij de lancering “af” te verklaren versus het eigenaarschap over de hele levensduur dat een veilige dienst werkelijk vereist. Nuttige invalshoeken zijn of een CI/CD-pijplijn met monitoring en snel terugdraaien als live veiligheidsmaatregel wordt behandeld, of een oproepdienst en iteratiebudget de go-livevieringen overleven en of een uitstapplan is geschreven tijdens het bouwen in plaats van in paniek te worden geïmproviseerd. Een goed antwoord noemt wie de dienst bezit voor haar operationele leven en beschrijft een beheerste, controleerbare uitfasering in plaats van een hoop dat iemand het later regelt.

4. Wanneer liet het falen van een prototype ons voor het laatst stoppen — en bouwen wij nog dingen om weg te gooien? Alfa bestaat om de riskantste aannames goedkoop weg te werken, wat betekent dat een wegwerpprototype dat faalt zijn werk heeft gedaan: het heeft een kostbare les gekocht voordat productiegeld en echte patiënten werden vastgelegd. Deze vraag onderzoekt of een team alfa werkelijk behandelt als wegwerpleren of stilletjes is gaan polijsten van zijn eerste prototype tot het uiteindelijke product omdat code schrappen verspillend voelt — de valkuil van verzonken kosten die een fase van risicovermindering verandert in een dure toezegging die blind wordt gedaan. De spanning die aan het licht moet komen is de druk om “iets te hebben om te tonen” en elke geschreven regel te hergebruiken tegenover de discipline te bewijzen dat een oplossing zou kunnen werken voordat de echte op productie-infrastructuur wordt gebouwd. Concrete invalshoeken zijn vragen welke aannames de laatste alfa werkelijk toetste, of enig prototype ooit op grond van bewijs werd verlaten en of de bèta met privétoegang wegwerpcode hergebruikte die naar productienorm had moeten worden herschreven. Een eerlijk antwoord kan wijzen op een specifieke aanname die een prototype doodde of bevestigde, en kan leerartefacten die het team bereid was weg te gooien onderscheiden van de geborgde code die het nu in Live draait.

5. Draaien wij één eerlijke hybride, of meerdere vermomde methoden die elkaar stilletjes tegenspreken? De meeste grote zorgprogramma’s zijn werkelijk hybride — agile productteams die opereren binnen een omhulsel van mijlpalen en financiering dat de organisatie en haar toezichthouders vereisen — en het falen is niet de hybride zelf maar doen alsof zij puur agile of puur waterval is, zodat de twee logica’s onbeheerd bij elke poort botsen. Deze vraag vraagt een team te noemen waar de vaste, in volgorde gezette toezeggingen werkelijk zitten (financieringstranches, regelgevende mijlpalen, integratiestops) en waar de werkelijke iteratie plaatsvindt, in plaats van “agile” en “het plan” elk het hele programma te laten claimen en iedereen te frustreren. De afweging om te bespreken is de legitieme behoefte van de organisatie aan voorspelbare mijlpalen en controleerbare uitgaven tegenover de behoefte van het leveringsteam om reikwijdte op bewijs te wijzigen, en de eerlijke zet is de naden expliciet te maken zodat beide eromheen kunnen plannen. Nuttige invalshoeken zijn of herprioritering van de backlog het contact met het programmaplan ooit overleeft, of leveranciers voor vaste reikwijdte worden gecontracteerd terwijl hun wordt gevraagd iteratief te werken en of de rapportage die een bestuur ziet overeenkomt met hoe het werk werkelijk wordt gedaan. Een goed antwoord beschrijft een bewust ontworpen hybride met benoemde vaste punten en benoemde flexibele ruimtes, geen warboel waarin methode voor de schijn wordt geclaimd.

6. Hoe goed weten wij wat een live dienst op dit moment met haar gebruikers doet — en zouden wij schade merken voordat zij werd gemeld? Een live gezondheidsdienst is alleen zo veilig als haar waarneembaarheid: monitoring, alarmering en de klinische veiligheidsinstincten die van een maat een gevaar maken zijn het verschil tussen een defect met verouderde data in minuten vangen en er weken later via een incidentmelding van horen. Deze vraag onderzoekt of het team de dienst in productie kan zien — foutpercentages, integratiefouten, afhaken door toegankelijkheid, de billijkheidskloven die alleen echt gebruik onthult — en of iemand de dashboards bekijkt met klinisch risico in gedachten, niet alleen de beschikbaarheid van infrastructuur. De spanning is de kosten en discipline van degelijke waarneembaarheid en oproepdienst tegenover de stille aanname dat “geen nieuws goed nieuws is” zodra een dienst live is, wat in een veiligheidskritisch domein is hoe stille schade zich opstapelt. Concrete invalshoeken zijn of het gevarenlogboek wordt bijgewerkt uit live incidenten, of alarmen aan klinische impact zijn gekoppeld en niet alleen aan serverstatus en of een slechte release kan worden gedetecteerd en teruggedraaid voordat zij veel patiënten bereikt. Een eerlijk antwoord beschrijft specifieke signalen die het team volgt, een echt incident dat monitoring ving (of miste) en hoe live bewijs in de volgende iteratie terugvloeit.

In de praktijk: een voorbeeld uit gezondheid en zorg#

Een NHS-organisatie voor gemeenschapszorg vervangt een verouderd systeem van papier en spreadsheets voor het plannen van bezoeken van wijkverpleegkundigen. Komend uit discovery (Onderwerp 3.4) treedt het team alfa binnen en bouwt twee wegwerpprototypes om de riskantste aannames te toetsen: dat verpleegkundigen een telefoon in de huizen van patiënten zullen gebruiken en dat het schema kan integreren met het elektronisch patiëntendossier. Op dag één van alfa wordt een klinischeveiligheidsfunctionaris benoemd die een gevarenlogboek opent; een vroeg gevaar — een verouderd schema dat een bezoek toont dat al door een collega is afgerond — drijft een ontwerpbeslissing aan om de synchronisatiestatus in realtime te tonen. De DPIA, begonnen in discovery, markeert dat locatiedata van alleenwerkenden een omschreven rechtmatige grondslag en bewaarlimiet nodig hebben.

Bij het service-assessment van alfa naar bèta onderzoekt een onafhankelijk panel toegankelijkheid (verpleegkundigen met een visuele beperking), beveiliging en de redenering van het team. De dienst slaagt met acties. In bèta met privétoegang gebruiken tien verpleegkundigen het echte systeem op productie-infrastructuur; een CI/CD-pijplijn laat het team dagelijks uitleveren en een slechte release in minder dan tien minuten terugdraaien. Gebruik legt een kwestie van billijkheid bloot — uitzendkrachten zonder apparaten van de organisatie — wat leidt tot een terugvaloptie in de browser. Openbare bèta schaalt naar drie locaties; het rapport van het klinische veiligheidsdossier wordt voltooid en onder DCB0160 goedgekeurd vóór bredere uitrol.

De dienst gaat Live met een vast productteam, monitoringdashboards en een oproeprooster. Achttien maanden later, wanneer de organisatie een regionaal platform overneemt, wordt het schema volgens plan uitgefaseerd: data gemigreerd onder het bewaarschema, verpleegkundigen omgeschoold en omgeleid, en het gevarenlogboek en veiligheidsdossier gearchiveerd voor audit. Elke overgang was een beslissing gesteund door bewijs, geen datum op een Gantt-diagram.

Sectorperspectieven#

Startup#

De levenscyclus van een startup is gecomprimeerd en grotendeels zelfbestuurd: er is geen onafhankelijk assessmentpanel, dus de discipline van de poorten Alfa–Bèta–Live moet zelf worden opgelegd of zij stort in tot “lever continu uit en hoop”. Het voordeel is dat een klein team vanaf dag één echte CI/CD kan draaien en sneller kan itereren dan elk groot orgaan. Het gevaar is de draden van klinische veiligheid en DPIA stilletjes te laten vallen omdat nog geen toezichthouder meekijkt — een fatale fout in de gezondheidszorg, waar DCB0129-verplichtingen de fabrikant ongeacht de bedrijfsgrootte binden, en één onbeheerd gevaar zowel het product als het bedrijf kan beëindigen. Startups moeten de bedoeling van het faseringsmodel overnemen — bewijs vóór blootstelling — ook zonder de ceremonie, en zodra een oplossingsvorm bestaat een klinischeveiligheidsfunctionaris benoemen (vaak deeltijds).

Klein bedrijf#

Een gevestigde kleine aanbieder — een huisartsenpraktijk, gemeenschapsapotheek, verzorgingshuis of kliniek met één vestiging — ontmoet de levenscyclus meestal als inzetter in plaats van bouwer: zij koopt of configureert het systeem van een leverancier, dus de goedkeuring van inzet onder DCB0160 en een lokale DPIA vallen op haar, ook zonder intern digitaal team. De fasen gelden nog steeds, maar gecomprimeerd en uitbesteed: “alfa” is een begeleide pilot op een paar echte patiënten, “bèta” is een gefaseerde uitrol over de praktijk en Live is gewone bedrijfsvoering met updates van de leverancier die continu en grotendeels buiten de controle van de praktijk binnenkomen. De organisatie moet een klinischeveiligheidsfunctionaris benoemen (vaak een klinische maat die de rol naast een dagbaan neemt) en een gevarenlogboek bijhouden voor hoe het systeem lokaal wordt gebruikt, omdat het DCB0129-werk van de fabrikant de specifieke risico’s van de inzet niet dekt. Met krappe kasstroom en zonder toegewijde IT is de realistische discipline te leunen op de borging van de leverancier terwijl zij de weinige beslissingen bezit die alleen lokale kennis kan nemen — wie wordt getraind, wat de terugval is wanneer het systeem uitligt en hoe patiëntgegevens in deze specifieke setting stromen.

Grote onderneming#

Een NHS-ziekenhuis of grote leverancier draait de levenscyclus in zijn volledigste, meest geborgde vorm: formele service-assessments, een benoemde klinischeveiligheidsfunctionaris, goedkeuring van inzet onder DCB0160, change advisory boards en een jaarlijkse financieringscyclus waarbinnen het agile werk moet passen. De kenmerkende uitdaging is de hybride — agile leveringsteams die binnen een omhulsel van programma en mijlpalen opereren dat de organisatie en haar auditors vereisen — en het klassieke falen is “waterval in agile kostuum”, waar poorten stilletjes kalenderdata worden. Ondernemingen hebben de middelen om CI/CD, waarneembaarheid en vaste productteams goed te doen, maar organisatorische traagheid en legacy-integratie vertragen uitrol vaak tot een kruipgang. De verantwoording is breed en de schadestraal groot, dus de gefaseerde oprit van privébèta naar live is geen optionele voorzichtigheid maar essentiële risicobeheersing.

Overheid#

Een nationaal orgaan levert onder de volle Service Standard, gepubliceerde service-assessments, uitgavenbeheersing en parlementaire toetsing, dus elke fasepoort is ook een punt van publieke verantwoording. Levenscycli zijn hier lang en de blootstelling enorm — een live NHS-brede dienst kan miljoenen raken — wat de inzet voor de gefaseerde oprit, borging van klinische veiligheid en de uitfasering van de legacysystemen die worden vervangen verhoogt. Inkoopregels en meerjarige financieringsafspraken bepalen wat “agile” in de praktijk kan betekenen, en een nationaal systeem uitfaseren (met zijn decennia aan dossiers en wettelijke bewaarplichten) is een groot programma op zich. De afweging is borging versus snelheid: levering door de overheid is zwaar gepoort, wat veiligheid en publiek geld beschermt maar bewuste inspanning vraagt om teams te laten itereren in plaats van terug te vallen op groot ontwerp vooraf.

Veelvoorkomende faalpatronen#

• Waterval in agile kostuum. Het team draait “sprints” maar reikwijdte, data en ontwerp waren allemaal vooraf vastgelegd; iteratie is theater. Tegengif: laat bewijs bij elke poort het plan werkelijk veranderen.
• Veiligheid en IB erop geschroefd aan het eind. Het klinische veiligheidsdossier en de DPIA worden de maand voor go-live geschreven, wat de lancering blokkeert of, erger, onder druk erdoorheen wordt gewuifd. Tegengif: open het gevarenlogboek en de DPIA in alfa en laat ze voortdurend rijpen.
• De big-banglancering. De dienst slaat privé-/openbare bèta over en gaat rechtstreeks naar volledige uitrol, en stelt elke gebruiker bloot aan onbewezen software. Tegengif: gebruik de gefaseerde oprit; laat blootstelling groeien met bewijs.
• De verlaten Live-dienst. Het leveringsteam wordt bij go-live ontbonden; de dienst rot en klinisch risico stapelt zich stilletjes op. Tegengif: financier een vast productteam voor het operationele leven.
• Assessment-stampen. Normen worden genegeerd totdat het assessment opdoemt en dan oppervlakkig gehaald. Tegengif: betrek borging en klinische beoordelaars voortdurend.
• Geen uitstapplan. De dienst wordt in paniek uitgefaseerd wanneer haar vervanging arriveert, en laat data en gebruikers stranden. Tegengif: plan uitfasering als eersteklas fase.

Volwassenheidsmodel#

Checklist#

• De dienst heeft een expliciete huidige fase (Discovery / Alpha / Beta / Live) en een benoemde volgende beslissing.
• Faseovergangen worden op bewijs gepoort, niet op data.
• Een klinischeveiligheidsfunctionaris is benoemd en een gevarenlogboek is open (DCB0129/0160) vanaf alfa.
• Een DPIA en beoordeling van de rechtmatige grondslag (Caldicott, UK GDPR) begonnen in discovery en worden actueel gehouden.
• De leveringsmethode is afgestemd op het niveau van onzekerheid, en elke hybride regeling is expliciet.
• Service-assessments zijn gepland, en beoordelaars van borging/beveiliging/toegankelijkheid worden vroeg betrokken.
• Een CI/CD-pijplijn met monitoring en snel terugdraaien is aanwezig vóór openbare bèta.
• De dienst wordt in een gefaseerde oprit aan gebruikers blootgesteld (privébèta → openbare bèta → live), niet big-bang.
• Een vast productteam is gefinancierd voor het operationele leven van de dienst (zie Onderwerp 5.0).
• Een uitfaseringsplan dekt bewaring/migratie van data, omleiding van gebruikers en archivering van veiligheids- en auditdossiers.

Belangrijkste bronnen#

• GOV.UK Service Manual — de fasen van een agile project (Discovery, Alpha, Beta, Live) en de Government Service Standard.
• NHS England — NHS Service Standard en NHS Digital Service Manual; service-assessments van de NHS.
• NHS England Digital — DCB0129 (Clinical Risk Management: its Application in the Manufacture of Health IT Systems) en DCB0160 (its Application in the Deployment and Use of Health IT Systems).
• NHS England — digitale borging van klinische veiligheid; de rol van klinischeveiligheidsfunctionaris, gevarenlogboek en rapport van het klinische veiligheidsdossier.
• NHS England — Digital Technology Assessment Criteria (DTAC).
• Britse Caldicott-beginselen; Data Protection Act 2018 / UK GDPR en gegevensbeschermingseffectbeoordelingen.
• NICE — Evidence Standards Framework for Digital Health Technologies.
• DevOps- en continue-leveringspraktijk (bijv. de DORA-capaciteiten: continue integratie, automatisering van uitrol, monitoring); richtlijnen van de GOV.UK Service Manual over continue levering en het runnen van een dienst.

Referenties#

1. Systems development life cycle — Wikipedia — https://en.wikipedia.org/wiki/Systems_development_life_cycle
2. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
3. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
4. Software prototyping — Wikipedia — https://en.wikipedia.org/wiki/Software_prototyping
5. CI/CD — Wikipedia — https://en.wikipedia.org/wiki/CI/CD
6. Continuous integration — Wikipedia — https://en.wikipedia.org/wiki/Continuous_integration
7. Continuous delivery — Wikipedia — https://en.wikipedia.org/wiki/Continuous_delivery
8. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
9. Infrastructure as Code — Wikipedia — https://en.wikipedia.org/wiki/Infrastructure_as_code
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. Privacy impact assessment (data protection impact assessment) — Wikipedia — https://en.wikipedia.org/wiki/Privacy_impact_assessment
12. Agile delivery: the phases of an agile project — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/agile-delivery
13. NHS service standard and NHS digital service manual — NHS England — https://service-manual.nhs.uk/
14. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
15. DevOps Research and Assessment (DORA) capabilities — Google Cloud / DORA — https://dora.dev/
16. Continuous delivery — Jez Humble and David Farley — https://continuousdelivery.com/
17. Data protection impact assessments (DPIAs) — Information Commissioner's Office (ICO) — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/
18. Evidence standards framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health