Onderwerp 1.0 — Werkwijzen in digitale gezondheid en zorg

In één zin: Werkwijzen zijn de bewuste, gedeelde gewoonten – hoe u teams organiseert, beslissingen neemt, risico beheert en waarde levert – waarmee een organisatie voor gezondheid en zorg intentie omzet in veilige, billijke, op bewijs gebaseerde uitkomsten voor patiënten en burgers.

Waarom dit ertoe doet in gezondheid en zorg#

Elke organisatie heeft werkwijzen, of ze nu gekozen of geërfd zijn. In digitale gezondheid en zorg zijn de werkwijzen die u erft meestal verkeerd voor de klus: ze zijn gebouwd voor projecten in bouwstijl met vaste reikwijdte, niet voor adaptieve diensten die klinische veiligheid, wettelijke plichten en publiek geld raken. Ze goed krijgen is geen luxe van de backoffice; het is het verschil tussen een gedeeld zorgdossier dat clinici vertrouwen en een dat ongebruikt blijft.

Gezondheid en zorg is onderscheidend op manieren die elke praktijk in dit boek vormen. Veiligheid is niet onderhandelbaar – een gebrek in een digitale dienst kan een patiënt schaden, dus klinisch risicobeheer (zie Onderwerp 1.6 — Klinische veiligheid en risicobeheer) is door de levering geweven en niet achteraf vastgeschroefd. Billijkheid doet ertoe omdat een dienst die alleen werkt voor de digitaal zelfverzekerden gezondheidsongelijkheden vergroot; de Core20PLUS5-populaties en mensen met beperkte digitale toegang moeten worden ontworpen, niet weg-ontworpen. Wettelijke plichten – de NHS-toezegging van uitgebreide zorg, de wetgeving voor gegevensbescherming, de geheimhoudingsplicht – beperken wat u met data mag doen en hoe u moet consulteren. Publiek geld vraagt om evenredige uitgavenbeheersing en aantoonbare waarde. En bijna niets wordt door één orgaan alleen geleverd: partnerschap tussen geïntegreerde zorgsystemen (ICS), lokale overheden, aanbieders van sociale zorg en leveranciers is de standaard bedrijfsomstandigheid.

Deze vier drukken – veiligheid, billijkheid, plicht, geld – zijn waarom u niet simpelweg een draaiboek uit consumententech kunt kopiëren. U hebt werkwijzen nodig die agile en verantwoordingsplichtig zijn, snel en veilig, gebruikersgericht en eerlijk voor de bevolking.

Kernbegrippen#

Werkwijzen opereren op drie niveaus. Op teamniveau zijn het de dagelijkse praktijken: stand-ups, gebruikersonderzoek, iteratieve levering, pair programming. Op organisatieniveau zijn ze het operationele model – hoe strategie waardestromen, capaciteiten, financiering en beslisrechten wordt (zie Onderwerp 1.1 — Het operationele model). Op systeemniveau zijn ze hoe onafhankelijke organisaties zich afstemmen: gedeelde normen, interoperabiliteit en gemeenschappelijk bestuur over een ICS. Dit boek beweegt bewust over alle drie.

Gebruikersgericht ontwerp betekent beginnen bij de behoeften van de mensen die een dienst gebruiken – patiënten, mantelzorgers, clinici, administratieve medewerkers – in plaats van bij een veronderstelde oplossing. De Britse Government Digital Service (GDS) en de NHS hebben dit vastgelegd in servicestandaarden: begrijp gebruikers en hun behoeften voordat u bouwt en blijf gedurende de hele tijd testen met echte gebruikers.

Agile, iteratieve levering betekent vroeg een werkende dienst voor echte gebruikers brengen, leren en bijsturen – in plaats van alles vooraf te specificeren. De NHS digital service manual is expliciet dat agile, gebruikersgerichte werkwijzen het risico verminderen het verkeerde te bouwen. Agile is hier evenzeer een strategie voor risicobeheer als een leveringsmethode.

Multidisciplinaire teams (MDT’s) brengen in één bevoegd team de mix van vaardigheden samen die een dienst nodig heeft: product- en leveringsmanagement, gebruikersonderzoek en ontwerp, engineering, klinische en informatiebeheerexpertise en operationele kennis. De servicestandaard van de NHS vereist teams die multidisciplinaire vaardigheden en perspectieven omvatten – inclusief toegang tot specialistische klinische, juridische of beleidsinbreng. Het MDT is het atoom van digitale levering; de meeste mislukkingen zijn terug te voeren op een ontbrekende discipline aan tafel.

Product boven project. Een project heeft een begin, een einde en een overdracht; een product wordt gefinancierd en beheerd voor zijn hele leven. De verschuiving van project- naar productdenken (zie Onderwerp 1.1 en Onderwerp 5.0 — Productgestuurd werken) verandert financiering, teams en verantwoordelijkheid, en past veel beter bij zorgdiensten – die langlevend zijn en voortdurend evolueren – dan eenmalige projecten.

Beste praktijken#

1. Begin bij gebruikersbehoeften, onderbouwd door onderzoek. Begrijp vóór het vastleggen van een bouw wie de gebruikers zijn, wat zij proberen te doen en waar de huidige dienst hen tekortdoet. Financier een discovery (zie Onderwerp 3.4 — Discoveryfasen) en behandel “wij namen aan” als rode vlag. Gebruikersbehoeften, geen interne voorkeuren, zijn het anker voor elke latere beslissing.

2. Bouw multidisciplinaire, bevoegde en stabiele teams. Stel de volledige mix van vaardigheden samen – inclusief klinische veiligheid en informatiebeheer – en geef het team het gezag binnen duidelijke vangrails te beslissen. Houd teams bij elkaar rond een dienst in plaats van ze bij elke projectgrens te ontbinden; stabiele teams verzamelen de domein- en veiligheidskennis die zorgdiensten eisen.

3. Werk in de openbaarheid en itereer in kleine stappen. Lever dunne plakken, meet en stel bij. Kleine, frequente releases zijn veiliger dan big-banglanceringen omdat problemen aan het licht komen terwijl ze nog klein zijn, en ze laten toetsing van klinische veiligheid en informatiebeheer gelijke tred houden met verandering in plaats van een poort aan het einde te worden.

4. Maak veiligheid en billijkheid vanaf dag één eersteklas. Voer klinisch risicobeheer (DCB0129/DCB0160) en analyse van gelijkheid en gezondheidsongelijkheden naast de levering uit, niet als goedkeuringen aan het eind. Vraag vroeg wie kan worden buitengesloten of geschaad en ontwerp voor de moeilijkste gevallen – begeleide digitale routes (assisted digital), toegankelijkheid (WCAG) en offline terugvalopties.

5. Beslis op bewijs en leg de beslissing vast. Onderscheid klinisch bewijs (werkt het en is het veilig?) van leveringsbewijs (bouwen wij het goed en wordt het gebruikt?) en houd een lichtgewicht beslislogboek bij zodat de redenering personeelsverloop overleeft (zie Onderwerp 1.3 — Op bewijs gebaseerde besluitvorming). Bewijs verslaat de mening van de best betaalde persoon.

6. Ontwerp voor interoperabiliteit en hergebruik. Data uit gezondheid en zorg moet veilig tussen organisaties stromen; bouw op open normen (HL7 FHIR, SNOMED CT) en hergebruik platforms in plaats van ze opnieuw uit te vinden (zie het “dunste levensvatbare platform” van Onderwerp 1.1 en Onderwerp 4.3 — Interoperabiliteit en datastandaarden). Een dienst die geen data kan delen is een silo dat wacht om een risico te worden.

7. Bestuur evenredig. Stem het gewicht van de borging af op het risicoriveau. Klinische wijzigingen met hoog risico verdienen diepe toetsing; contentwijzigingen met laag risico moeten niet weken op een bestuur wachten. Evenredig bestuur houdt u zowel veilig als snel.

8. Werk in de openbaarheid. Deel plannen, beslissingen, roadmaps en – waar veilig – code, zodat partners, clinici en het publiek kunnen zien hoe en waarom keuzes worden gemaakt. Openheid bouwt vertrouwen, snoeit duplicatie in een gefragmenteerd stelsel en nodigt uit tot uitdaging voordat fouten in live diensten verharden. In gezondheid en zorg is transparant zijn over wat een dienst met data doet, en waarom, zelf een praktijk van vertrouwen en veiligheid.

9. Ontwerp voor de lange termijn en voor overdracht. Digitale diensten in de zorg overleven de teams en contracten die ze bouwen, dus leg beslissingen vast, vermijd ongedocumenteerde “held”-kennis en ontwerp voor de mensen die de dienst jarenlang zullen beheren en wijzigen (zie Onderwerp 10.3 — Kennismanagement en documentatie). Behandel duurzaamheid – van het team, de technologie en het financieringsmodel – als eersteklas beperking en niet als bijzaak.

Vragen om met uw team te bespreken#

1. Waar zijn onze huidige werkwijzen geërfd in plaats van gekozen, en welke geërfde gewoonte kost ons het meest aan veiligheid, billijkheid of verspild geld? Deze vraag dwingt een eerlijke audit af van de praktijken die niemand besliste maar iedereen volgt – programmafinanciering met vaste reikwijdte, projectteams die worden ontbonden en herbouwd, bestuur dat pas bij go-live wordt geraadpleegd. Het doet ertoe omdat geërfde gewoonten gewoonlijk onzichtbaar zijn totdat ze worden benoemd, en in gezondheid en zorg echte kosten dragen: een gedeeld dossier dat clinici niet vertrouwen, een dienst die Core20PLUS5-populaties uitsluit of een herbouw van dezelfde inlogleidingen op publiek geld. De spanning om te bespreken is dat geërfde werkwijzen vaak veilig voelen juist omdat ze vertrouwd en controleerbaar zijn, zodat het afschaffen ervan eruitziet als risico nemen in plaats van risico wegnemen. Grond de discussie in concrete artefacten – kijk naar uw laatste drie businesscases, uw teamverloop tussen projecten en wanneer klinische veiligheid voor het eerst werd betrokken – in plaats van meningen uit te wisselen. Een goed antwoord noemt een of twee specifieke gewoonten met bewijs van hun kosten, onderscheidt die welke het waard zijn te behouden van die welke de uitkomsten actief schaden en verbindt zich aan een verandering waarvoor een senior leider verantwoordelijk is.

2. Hebben onze teams werkelijk de volledige multidisciplinaire mix aan vaardigheden – inclusief klinische veiligheid en informatiebeheer – binnen het team zitten, of zijn die disciplines nog steeds als poorten aan het eind vastgeschroefd? Het onderwerp betoogt dat het MDT het atoom van digitale levering is en dat de meeste mislukkingen te herleiden zijn tot een ontbrekende discipline aan tafel, dus deze vraag toetst of dat beginsel in uw organisatie echt is of louter aspiratie. Het doet ertoe omdat een klinisch veiligheidsfunctionaris of Caldicott Guardian die pas bij go-live wordt betrokken ofwel herwerk ofwel onveilige sluipwegen afdwingt, terwijl een van week één ingebedde een levend gevarenlogboek bijhoudt dat de levering tempo geeft. De afweging die het waard is aan de oppervlakte te brengen is kosten en schaarste: specialistische klinische, juridische en IG-tijd is werkelijk beperkt, dus “bed iedereen in elk team in” botst met echte beperkingen in middelen, en het team moet beslissen waar fractionele of gedeelde rollen aanvaardbaar zijn en waar niet. Kijk naar een huidige dienst en breng in kaart wie werkelijk in het vaste team zit tegenover wie als externe goedkeuring wordt geraadpleegd, en controleer of het team het gezag heeft binnen vangrails te beslissen of voortdurend moet escaleren. Een eerlijk, goed antwoord is specifiek over welke disciplines ontbreken of geleend zijn, erkent de spanning in middelen openhartig en stelt een concreet model voor – voltijds, fractioneel of op afroep – om de kloof te dichten zonder de schaarste weg te veinzen.

3. Wanneer hebben wij een digitale dienst behandeld als project met een overdracht in plaats van als product dat voor zijn hele leven wordt beheerd, en wat kostte dat ons aan verloren domein- en veiligheidskennis? Product boven project is een van de dragende verschuivingen van het onderwerp, en deze vraag laat het team confronteren waar zij nog financieren en bemensen voor afsluiting in plaats van continuïteit. Het doet ertoe omdat zorgdiensten langlevend zijn en voortdurend evolueren; een team dat bij de projectgrens wordt ontbonden neemt precies de opgebouwde klinische en operationele kennis mee die een dienst veilig houdt, en “pilotpurgatorium (pilot purgatory)” is het terugkerende symptoom. De werkelijke spanning is financieel en structureel: productfinanciering vereist vaste budgetten en daagt het model van jaarlijkse biedingen binnen een vast tijdsbestek uit waaromheen financiën en bestuur zijn gebouwd, dus dit is evenzeer een gesprek over geld en verantwoording als over levering. Overweeg een specifieke dienst die een overdracht onderging – volg wat er met haar gevarenlogboek, haar gebruikersonderzoek en haar team gebeurde – en weeg dat tegen de discipline die productfinanciering vraagt. Een goed antwoord identificeert een concreet geval, kwantificeert of karakteriseert ten minste de verloren kennis en is open over welke organisatorische barrières (financieringscycli, regels voor middelen, bestuursstructuren) zouden moeten bewegen opdat blijvende productteams de norm worden.

4. Wie wordt het meest waarschijnlijk uitgesloten of geschaad door de diensten die wij bouwen, en kunnen wij aanwijzen waar wij voor hen eerst hebben ontworpen in plaats van laatst? Het onderwerp staat erop dat billijkheid niet onderhandelbaar is en dat een dienst die alleen werkt voor de digitaal zelfverzekerden gezondheidsongelijkheden vergroot, dus deze vraag toetst of “ontwerp voor de moeilijkste gevallen” een levende praktijk of een slogan is. Het doet ertoe omdat uitsluiting in gezondheid en zorg geen ongemak is maar een veiligheids- en toegangsschade: de Core20PLUS5-populaties, mensen met beperkte digitale toegang, lage gezondheidsvaardigheden of geen smartphone zijn precies de mensen wier behoeften het grootst zijn, en een dienst die hen weg-ontwerpt concentreert schade waar die het minst kan worden gedragen. De spanning die het waard is aan de oppervlakte te brengen is dat ontwerpen voor de marges vooraf tijd en geld kost – begeleide digitale routes, toegankelijkheid volgens WCAG, offline en niet-digitale terugvalopties, vertaling – en die kosten gemakkelijk worden uitgesteld wanneer een leveringsdatum dreigt en de zelfverzekerde meerderheid het ding al kan gebruiken. Kijk naar een echte dienst en vraag wie in haar steekproef voor gebruikersonderzoek zit, of een analyse van gelijkheid en gezondheidsongelijkheden werkelijk een ontwerpbeslissing vormde en wat er gebeurt met iemand die niet online kan of wil gaan. Een eerlijk antwoord noemt de specifieke groepen die voor deze dienst risico lopen, toont ten minste één concrete ontwerpkeuze die voor hen is gemaakt en is open over waar het team inclusie onder druk inruilde en hoe het die ruil de volgende keer zou verdedigen.

5. Waar vinden wij leidingen opnieuw uit die al bestaan, en waar zou bouwen op open normen en hergebruiken van gedeelde platforms werkelijk veranderen wat wij opleveren? Ontwerpen voor interoperabiliteit en hergebruik is een van de beste praktijken van het onderwerp, en deze vraag laat het team de trek confronteren om op maat te bouwen in plaats van te hergebruiken – de inlog, de notificaties, de dossierintegratie die een dozijn andere teams ook hebben gebouwd. Het doet ertoe omdat in een gefragmenteerd stelsel elk opnieuw uitgevonden onderdeel publiek geld is dat tweemaal wordt besteed en een nieuw silo dat veilig geen data kan uitwisselen; omgekeerd is bouwen op HL7 FHIR en SNOMED CT en het dunste levensvatbare platform hergebruiken wat een dienst überhaupt door inkoop laat komen en data over een ICS laat delen. De werkelijke afweging is dat hergebruik afhankelijkheid betekent: een gedeeld platform kan trager zijn, minder op maat of bestuurd door de roadmap van een ander, dus het team moet de trek van een gedeeld onderdeel afwegen tegen de langetermijnkosten en het risico van een silo op maat. Onderzoek een huidige bouw en lijst op wat werkelijk nieuw is tegenover wat een bestaand platform, norm of open onderdeel dupliceert, en controleer of “dat kunnen wij niet hergebruiken” een onderbouwde beperking of een ongetoetste aanname is. Een goed antwoord onderscheidt de delen die het waard zijn te bouwen van de delen die het waard zijn te hergebruiken, is eerlijk over de volwassenheid en het bestuur van de aangeboden platforms en verbindt zich aan open normen voor alles wat data moet uitwisselen.

6. Hoe stemmen wij het gewicht van ons bestuur af op het risicoriveau, en waar is borging nu ofwel te zwaar voor wijziging met laag risico ofwel te licht voor wijziging met hoog risico? Evenredig bestuur is een dragend idee in dit onderwerp – klinische wijzigingen met hoog risico verdienen diepe toetsing terwijl contentwijzigingen met laag risico niet weken op een bestuur moeten wachten – en deze vraag toetst of de organisatie borging op risico afstemt of één botte procedure op alles toepast. Het doet ertoe omdat verkeerd afgesteld bestuur beide kanten op schaadt: een zware poort voor alles laat teams wijzigingen opstapelen en vertraagt juist de iteratie die diensten veilig houdt, terwijl een uniform lichte aanpak een werkelijk klinische wijziging met hoog risico doorlaat zonder de toetsing van klinische veiligheid en informatiebeheer die zij nodig heeft. De spanning is dat evenredigheid oordeel vereist, en oordeel ongemakkelijk is voor besturen en auditors die één verplichte checklist gemakkelijker te verdedigen vinden dan een traject in risicolagen. Kijk hoe uw laatste dozijn wijzigingen werd geborgd, sorteer ze naar het werkelijke klinische en datarisico en zie of de inspanning het risico of de kalender volgde. Een eerlijk antwoord identificeert concrete voorbeelden van zowel te veel als te weinig bestuur, stelt duidelijke criteria voor om wijziging naar risico in lagen in te delen en noemt wie het gezag heeft de laag te bepalen en daarvoor verantwoordelijk te zijn.

In de praktijk: een voorbeeld uit gezondheid en zorg#

Een geïntegreerd zorgsysteem wil clinici bij drie ziekenhuizen voor acute zorg, gemeenschapsdiensten en sociale zorg van lokale overheden een gedeeld zorgdossier geven. De oude manier zou een programma met vaste reikwijdte opdragen, elk scherm vooraf specificeren en laat integreren.

In plaats daarvan vormt het ICS een multidisciplinair team: een productmanager, leveringsmanager, gebruikersonderzoeker, interactieontwerper, twee engineers, een klinisch veiligheidsfunctionaris en een leider informatiebeheer, met toegang tot een Caldicott Guardian en een praktijkwerker uit de sociale zorg. Zij voeren een discovery van acht weken uit, observerend hoe een wijkverpleegkundige, een consultant op de spoedeisende hulp en een maatschappelijk werker vandaag werkelijk proberen informatie te vinden. Ze ontdekken dat de echte pijn niet “geen data” is maar “data waarvan zij de actualiteit niet kunnen vertrouwen”.

Het team levert een smalle alpha op: alleen-lezen toegang tot allergieën, medicatie en de status van het huidige zorgplan voor één klinisch zorgpad, met een zichtbare stempel “laatst bijgewerkt”. Klinische veiligheid loopt parallel; vanaf week één wordt een gevarenlogboek bijgehouden. Ze meten of clinici ophouden andere teams te bellen om informatie te bevestigen. Pas wanneer die dunne plak waardevol en veilig blijkt, verbreden ze het dossier – gefinancierd als voortdurend product, niet als afgesloten project.

Sectorperspectieven#

Dezelfde vier drukken – veiligheid, billijkheid, plicht, geld – drukken op elke organisatie, maar de werkwijzen die ze beantwoorden verschuiven met schaal, financiering en verantwoording.

Startup#

Een klein bedrijf voor digitale gezondheid leeft of sterft bij focus, dus zijn werkwijzen zijn uit noodzaak slank: één multidisciplinair team, vlakke besluitvorming en dagelijks contact met gebruikers. De beperking is looptijd, niet regels over personeelsomvang, dus discovery wordt in weken gemeten en bewijs wordt goedkoop verzameld – een handvol klinische interviews, een klikbaar prototype, een eerlijk gevarenlogboek bijgehouden door een fractionele klinisch veiligheidsfunctionaris. Het gevaar is de rigueur van veiligheid en informatiebeheer overslaan om een mijlpaal van investeerders te halen; de discipline die toetsing overleeft is DCB0129 en een gegevensbeschermingseffectbeoordeling (DPIA) te behandelen als toelatingscriteria voor een pilot en niet als papierwerk dat wordt uitgesteld totdat een ziekenhuis erom vraagt. Interoperabiliteit vanaf dag één (FHIR, SNOMED CT) is ook een commercieel activum, omdat een startup die geen data kan uitwisselen nooit door de NHS-inkoop komt.

Klein bedrijf#

Een gevestigde kleine aanbieder – een huisartsenpraktijk, een gemeenschapsapotheek, een verzorgingshuis of thuiszorgbureau, een kliniek met één vestiging of een bescheiden leverancier van gezondheidstechnologie voorbij het stadium zonder omzet – draagt dezelfde drukken van veiligheid, billijkheid, plicht en geld als een groot ziekenhuis maar met een fractie van het vermogen ze te beantwoorden. Werkwijzen moeten hier radicaal evenredig zijn: er is zelden een toegewijd digitaal team of IG-team, dus het “multidisciplinaire team” is vaak een handvol mensen met meerdere petten plus een gedeelde of uitbestede capaciteit voor klinische veiligheid en gegevensbescherming. De valkuil is aannemen dat de wettelijke plichten met de organisatie meeschalen – dat doen ze niet, dus klinische veiligheid volgens DCB0129/DCB0160, een gegevensbeschermingseffectbeoordeling en toegankelijkheid gelden onverminderd ook wanneer één praktijkmanager voor alles verantwoordelijk is. De praktische discipline is zwaar leunen op hergebruik in plaats van bouwen: neem geaccrediteerde kant-en-klare systemen aan, sta erop dat leveranciers aan DTAC en open normen (FHIR, SNOMED CT) voldoen en gebruik nationale en door het ICS geleverde platforms zodat veiligheid, interoperabiliteit en informatiebeheer worden geërfd en niet met een kleine beurs opnieuw uitgevonden.

Grote onderneming#

Een NHS-ziekenhuis of ICS heeft het omgekeerde probleem: overvloed aan proces en gefragmenteerd eigenaarschap. Werkwijzen gaan hier even zeer over afleren – gewoonten van programma’s met vaste reikwijdte uitfaseren, teams die worden ontbonden en herbouwd stilzetten – als over nieuwe praktijken aannemen. Verantwoording is formeel en persoonlijk (een senior verantwoordelijke (senior responsible owner), een Caldicott Guardian, goedkeuring van klinische veiligheid op bestuursniveau), dus de winst is die rollen in het leveringsteam in te bedden in plaats van ze als poorten vast te schroeven. Een grote leverancier van gezondheidstechnologie of farmacie staat voor het spiegelbeeld: sterke engineeringvolwassenheid maar afstand tot de klinische werkelijkheid in de frontlinie, die multidisciplinaire teams met echte tijd van clinici bestaan om te dichten.

Overheid#

Een nationaal of lokaal publiek orgaan – NHS England, DHSC, UKHSA, een lokale overheid – stelt de normen vast waarnaar iedereen anders werkt, dus zijn werkwijzen rimpelen naar buiten. Zijn verantwoording is aan het Parlement en het publiek, wat de lat voor transparantie, uitgavenbeheersing en billijkheid verhoogt: een servicestandaard, een gepubliceerde borgingsroute en plichten rond Core20PLUS5 zijn instrumenten van die verantwoording, geen optionele extra’s. Het risico op deze schaal is centraal ontwerpen voor een gemiddelde burger die niet bestaat en een oplossing verplichten voordat de lokale behoefte wordt begrepen. Het tegengif is dezelfde gebruikersgerichte, iteratieve discipline als overal, toegepast met een voorkeur voor het vaststellen van open normen en herbruikbare platforms waarop gefedereerde organisaties kunnen bouwen – het stelsel besturen, niet louter een dienst leveren.

Veelvoorkomende faalpatronen#

• Oplossing eerst bij levering. Zich vastleggen op een benoemd product voordat de behoefte wordt begrepen. Tegengif: financier discovery en maak gebruikersbehoeften het toelatingscriterium voor bouwen.
• Bestuur als late poort. Klinische veiligheid en informatiebeheer pas bij go-live geraadpleegd, wat herwerk of onveilige sluipwegen afdwingt. Tegengif: bed beide vanaf dag één in het team in.
• Projectverloop. Teams opzetten en afbreken, waarbij hard verworven domein- en veiligheidskennis verloren gaat. Tegengif: productfinanciering en blijvende teams.
• Pilotpurgatorium. Eindeloze pilots die nooit opschalen omdat adoptie, opleiding en bedrijfsverandering nooit van middelen werden voorzien (zie Onderwerp 8.1 — Verandermanagement). Tegengif: plan het pad naar opschaling vóór de pilot.
• Billijkheid als bijzaak. Ontwerpen voor de zelfverzekerde meerderheid en de mensen uitsluiten die zorg het meest nodig hebben. Tegengif: ontwerp eerst voor de moeilijkste gevallen.

Volwassenheidsmodel#

Checklist#

• Elke dienst heeft een benoemd, stabiel multidisciplinair team met vaardigheden in klinische veiligheid en informatiebeheer.
• Geen bouw begint zonder onderbouwde gebruikersbehoeften uit discovery.
• Klinisch risicobeheer (DCB0129/DCB0160) loopt vanaf dag één, met een levend gevarenlogboek.
• Een analyse van billijkheid en gezondheidsongelijkheden is gedaan en begeleide digitale routes bestaan.
• Levering verloopt in kleine, frequente, meetbare plakken.
• Beslissingen worden vastgelegd, met onderscheid tussen klinisch en leveringsbewijs.
• Diensten zijn gebouwd op open interoperabiliteitsnormen en hergebruiken gedeelde platforms.
• Het gewicht van bestuur is afgestemd op risico en bekend bij het team.
• Er is een gefinancierd pad van pilot naar opschaling, inclusief opleiding en verandering.

Belangrijkste bronnen#

• NHS digital service manual — NHS service standard en zijn punten, waaronder “Use agile ways of working” en “Create a team that includes multidisciplinary skills and perspectives” (service-manual.nhs.uk).
• GOV.UK Service Manual en de Government Service Standard — Government Digital Service (gov.uk/service-manual).
• NHS England / NHSX — Digital Technology Assessment Criteria (DTAC).
• Normen voor klinische veiligheid DCB0129 en DCB0160 (NHS England / voormalig NHS Digital).
• NICE — Evidence Standards Framework for digital health technologies (nice.org.uk).
• NHS England — de aanpak Core20PLUS5 om gezondheidsongelijkheden te verminderen.

Referenties#

1. User-centered design — Wikipedia — https://en.wikipedia.org/wiki/User-centered_design
2. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
3. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
4. Iterative and incremental development — Wikipedia — https://en.wikipedia.org/wiki/Iterative_and_incremental_development
5. Interdisciplinarity — Wikipedia — https://en.wikipedia.org/wiki/Interdisciplinarity
6. Product management — Wikipedia — https://en.wikipedia.org/wiki/Product_management
7. Health equity — Wikipedia — https://en.wikipedia.org/wiki/Health_equity
8. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
9. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
10. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Government Service Standard — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/service-standard
13. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
14. Clinical Risk Management: DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
15. Evidence Standards Framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health
16. Core20PLUS5 — NHS England — https://www.england.nhs.uk/about/equality/equality-hub/national-healthcare-inequalities-improvement-programme/core20plus5/