Welke vaardigheden zijn van belang bij de implementatie van een EPD, maar ontbreken vaak bij zorgverleners — en hoe dat leidt tot scope creep, tijd- en budgetoverschrijding

Inleiding

Een nieuw EPD implementeren in een Belgisch ziekenhuis doe je vaak maar één keer in je loopbaan als arts of verpleegkundige. Daar word je tijdens je opleiding en dagelijks werk niet direct op voorbereid. De meeste scope-, tijd- en budgetproblemen in EPD-trajecten ontstaan dan ook niet door onwil, maar door een vaardigheden-kloof tussen klinische expertise en product/IT-discipline. Artsen en verpleegkundigen zijn vanzelfsprekend onmisbaar als domeinexperts, maar missen (logischerwijs) soms vaardigheden die nodig zijn om een complex softwareproject op te zetten en aan te sturen. Hieronder een poging om de belangrijkste hiaten - telkens met het mechanisme waarlangs ze scope creep, tijd- en budgetoverschrijdingen veroorzaken, plus concrete tegenmaatregelen.

1) Product- & prioriteringsvaardigheden

Wat vaak ontbreekt

Denken in uitkomstdoelen (eindresultaat) i.p.v. feature-lijsten (van “wij willen X-knop” naar wij moeten voldoen aan die en die wettelijke eisen” of "wij willen als traumacentrum voldoen aan de eisen van de Deutsche Gesellschaft für Unfallchirurgie (DGU)" of "wij willen zonder overmatige bureaucratisering kunnen voldoen aan accreditering" of "wij willen het rendement van onze operatiezalen met 5% verbeteren" of "wij willen het rendement van ons beddenhuis met 5% verbeteren" of "wij willen het rendement van onze apotheek met 5% verbeteren" of “wij willen 10% minder medicatiefouten” of “10% minder potentieel vermijdbare complicaties” of “10% minder potentieel vermijdbare heropnames” of "10% minder (ernstige) incidenten" of “10% minder never events” of “10% minder sepsis op INZO” of “10% minder decubitus” of “10% minder CAUTI" of “10% minder fouten met infusen” of “10% minder fouten bij bloedtransfusies” of "10% minder ontbrekende ontslagbrieven of "10% minder ontbrekende operatieverslagen" of "10% minder ontbrekende VG-MZG scores" of "10% minder onverantwoorde ligdagen door onvolledige medische dossiers" …).
Denken in tijdsdoelen (resultaat in de tijd): wij willen als organisatie ons doel op die termijn bereiken en hoe kan dit EPD ons daarbij ondersteunen.
Denken in budgetdoelen (resultaat financieel): wij willen als organisatie dat financieel doel bereiken en hoe kan dit EPD ons daarbij ondersteunen (Minimale Ziekenhuis Gegevens, Budget Financiële Middelen).
Van bij de start van het traject prioretiserings-methoden implementeren en begrijpen zoals MoSCoW/RICE/WSJF toepassen met harde trade-offs en expliciete Won’t-have-besluiten.
Formuleren van SMART-acceptatiecriteria (Specifiek, meetbaar, acceptabel/haalbaar, relevant/realistisch , tijdsgebonden) en een Definition of Done die ook training, SOP’s, datamigratie en support dekt.
Bewustzijn van niet-functionele eisen die onderliggend noodzakelijk zijn (blokkerende en niet-blokkerende invoercontroles, data-integriteit, data-volledigheid, data-consistentie, veiligheid, performance, logging, beschikbaarheid, interoperabiliteit, ALCOA+ voor GxP).

Hoe dit tot problemen leidt

Elke (goede) suggestie die opkomt tijdens het traject en die op voorhand niet (contractueel) was vastgelegd of doorgepraat wordt “Must-have”, backlog zwelt aan, planning en budget worden elastiek ("scope creep", "everything but the kitchen sink").
"Bikeshedding", waarbij overmatig belang wordt gehecht aan kleinigheden, omdat de grote strategische, tactische en wettelijke items/gevolgen niet worden begrepen (law of triviality).
“Penny wise, pound foolish” of “Op de kleintjes letten en de grootjes vergeten", waarbij men erg zuinig of oplettend is met kleine uitgaven (beslissingen), maar uiteindelijk veel meer verliest doordat men ondoordacht handelt met grotere bedragen of beslissingen (groter kader uit het oog verloren).
“The Three Blind Men and the Elephant”, waarbij iedereen slechts een gedeeltelijke waarheid ervaart en het groter plaatje (context) uit het oog verliest.
“Kleine” verzoeken verstoppen teams omdat impact op (klinische) veiligheid, interfaces of rapporteringen (analyses) niet is meegewogen. De nieuwe features zijn niet meer in overeenstemming met de funderingen (concepten, principes), medicolegale vereisten en de (veiligheids)-architectuur waarop het systeem is gebouwd.

Tegenmaatregelen

Vertrek vanuit de klinische/verpleegkundige (outcome, kwaliteit, medicolegaal, ...) en de zakelijke doelstellingen die je als organisatie/team dient te bereiken.
Laat klinische product owners prioriteren op (klinische) waarde/risico; publiceer een Won’t-have-this-release-lijst.
Gebruik acceptatiecriteria-sjablonen (Given/When/Then) en koppel ze aan meetbare klinische outcome-KPI’s, zodat hun belang voor de werkvloer zichtbaar wordt. SMART-acceptatiecriteria maken “klaar” objectief aantoonbaar - en dat is dé remedie tegen ambiguïteit, scope creep en latere rework. Een Definition of Done (DoD) is een expliciete checklist die bepaalt wanneer werk écht “af” is. Niet alleen “de code werkt”, maar ook: getest, beveiligd, gedocumenteerd, inzetbaar, compliant en bruikbaar in de praktijk. Pas als alle punten zijn behaald, mag een item de status Done krijgen. De DoD voorkomt grijze zones—dé voedingsbodem voor scope creep, rework, tijd- en budgetverlies.
Samen gebruikt geven MoSCoW/RICE/WSJF je een gemeenschappelijke taal: MoSCoW (Must / Should / Could / Won’t) voor grenzen, RICE (Reach × Impact × Confidence ÷ Effort) voor waarde per inspanning, WSJF (Weighted Shortest Job First) voor volgorde. Dat helpt scope creep, tijd- en budgetoverschrijdingen te voorkomen.

2) Requirements-engineering & procesmodellering

Wat is het

Requirements engineering (RE) is het gestructureerd verzamelen, analyseren, vastleggen en beheren van eisen en wensen voor een softwaresysteem - in dit geval een Elektronisch Patiënten Dossier (EPD). Het gaat om het systematisch bepalen wat het EPD moet kunnen, voor wie, en onder welke voorwaarden, voordat het ontworpen of aangepast wordt. RE bij een EPD dient ervoor te zorgen dat het systeem echt aansluit bij de dagelijkse praktijk van zorgverleners en patiënten, én tegelijkertijd voldoet aan wetgeving en kwaliteitsnormen.
Procesmodellering betekent het in kaart brengen, analyseren en eventueel verbeteren van werkprocessen, vaak met behulp van schema’s of modellen (zoals BPMN-diagrammen, flowcharts of swimlanes). In de context van een Elektronisch Patiënten Dossier (EPD) gaat procesmodellering over het visualiseren van hoe zorgverleners het EPD (echt gaan) gebruiken binnen hun dagelijkse zorgprocessen, zodat duidelijk wordt:

wie welke taken uitvoert en (procesmatig, wettelijk) dient uit te voeren,
welke informatie waar wordt ingevoerd,
hoe gegevens door het systeem stromen,
en waar knelpunten of inefficiënties ontstaan.

Wat vaak ontbreekt

User stories met duidelijke persona, context, trigger, outcome zoals in de dagelijkse cross-departementele realiteit op de werkvloer en acceptatiecriteria.
Procesmodellering (swimlanes/ Business Process Model and Notation (BPMN)), inclusief frequentie en impact van uitzonderingen, deadlines, en wie wat doet. Swimlanes zijn de horizontale (of verticale) “banen” in een BPMN diagram die laten zien wie (rol/systeem/organisatie) welke stap doet. Wat is (echt) een standaard zorg-en bijhorend administratief proces en wat is uitzondering op de werkvloer.
Prototyping & usability-testen vóór bouwen; onderscheid tussen configuratie vs. maatwerk.

Hoe dit tot problemen leidt

Ambigue eisen → verschillende interpretaties → rework en vertraging.
Weigeren om “vastgeroeste” (papieren) werkwijzen te veranderen en aan te passen zonder dat klinisch en/of medicolegaal te kunnen verantwoorden. Maatwerk eisen in plaats van standaardoplossingen te aanvaarden (“hier werken wij anders dan anderen en daar willen wij niet van afwijken”) → technische schuld, onderhoudslast en vendor-afhankelijkheid. Verhogen van het risico op fouten tijdens het dagelijks werk door afwijkende werkwijzen in de architectuur van het systeem te introduceren.

Technische schuld (technical debt) is een begrip uit de softwareontwikkeling. Het beschrijft de “schuld” die ontstaat als je in een systeem of code bewust (of onbewust) kiest voor een snelle, makkelijke oplossing in plaats van een betere, robuuste oplossing. Die snelle oplossing werkt nu misschien prima en kost minder tijd of moeite, maar later kan het leiden tot extra werk, hogere (operationele) kosten of (klinische, medicolegale) risico’s wanneer je het moet uitbreiden, onderhouden of repareren.

Ontstaan van olifantenpaadjes na go-live. Een ongepland, informeel pad dat ontstaat doordat mensen niet het officiële zorgproces volgen, maar een korter of praktischer traject nemen (zoals in een park waar mensen door het gras lopen in plaats van het verharde pad te nemen). Het maakt het werk sneller, flexibeler en vaak beter afgestemd op de dagelijkse praktijk, dan via het officiële zorgproces in het EPD. Het kan leiden tot verlies van data, minder betrouwbare informatie-uitwisseling tussen zorgverleners, risico’s voor de patiëntveiligheid en zorgplanning of zelfs medicolegale problemen, als belangrijke klinische informatie niet op de juiste plek staat:

Een veelvoorkomend olifantenpaadje is het gebruik van vrije tekstvelden in plaats van gestructureerde velden. Zorgverleners kiezen hiervoor omdat het sneller gaat en minder klikken kost. Het risico is echter dat cruciale informatie moeilijk vindbaar wordt of niet meegenomen kan worden in (strategische, tactische, operationele) besluitvorming en analyses.
Daarnaast maken veel professionals notities buiten het EPD, bijvoorbeeld in Word-bestanden, op papier of via WhatsApp. Dit gebeurt meestal omdat het EPD te traag of onhandig aanvoelt, terwijl er behoefte is aan snelle communicatie in een klinische situatie. Het brengt echter aanzienlijke risico’s met zich mee, zoals datalekken, verlies van context of onveilige overdracht van gegevens.
Ook kopieer- en plakwerk tussen systemen komt vaak voor. Dit is een gevolg van het ontbreken van goede koppelingen en interoperabiliteit. Helaas vergroot dit de kans op fouten en inconsistenties in de gegevens.
Soms wordt de registratie helemaal overgeslagen of geminimaliseerd, vooral door tijdgebrek of omdat zorgverleners registratie ervaren als administratieve last. Dit kan leiden tot onvolledige dossiers, met risico’s voor patiëntveiligheid en kwaliteitsbewaking.
Een ander bekend fenomeen is het gebruik van ‘dummy’-waarden of snelcodes. Omdat het systeem bepaalde velden verplicht stelt, vullen zorgverleners soms onjuiste of irrelevante informatie in om verder te kunnen (werkdruk).
Tot slot zijn er workarounds in de workflow, zoals het registreren in een verkeerde categorie omdat de standaard workflow niet past bij de praktijk. Hoewel dit efficiënt kan lijken, tast het de betrouwbaarheid van data aan en vermindert het de bruikbaarheid voor onderzoek en kwaliteitsverbetering.

Tegenmaatregelen

Combineer story mapping met low-fidelity prototypes; test met 5–7 eindgebruikers per domein.

Een story map zet de gebruikersreis horizontaal uit (van links naar rechts) en breekt die op in lagen:

Backbone (activiteiten): grote stappen die een rol zet (“Patiënt selecteren”, “Voorschrift aanmaken”, “Versturen”).
Taken (onder elke activiteit): concrete handelingen (“Zoek middel”, “Kies dosis”, “Check interacties”).
User stories (per taak): “Als arts wil ik … zodat …” met acceptatiecriteria.
Slices / releases: dunne, end-to-end sneden die echte waarde leveren (Must/Should/Could).

Low-fidelity prototyping gaat over supersimpele schetsen/wireframes (papier, whiteboard) om flow en inhoud te valideren - géén pixelperfect design. Het doel is om samen te zien wat waar komt, waar waarschuwingen verschijnen, welke velden nodig zijn, hoe foutmeldingen werken.

Voor de olifantenpaadjes:

Gebruiksvriendelijkere invoerschermen en slimme sjablonen die structuur combineren met flexibiliteit.
Koppelingen met veilige berichtenapps of snellere invoermogelijkheden in het EPD.
Betere integratie en gegevensuitwisseling tussen de verschillende systemen waarmee het EPD moet samenwerken.
Verminderen van administratieve lasten en het beperken van verplichte registratie tot alleen echt relevante gegevens (klinisch zorgproces, medicolegaal, Minimale Ziekenhuis Gegevens (MZG), Budget Financiële Middelen (BFM)).
Slimmere validatie en contextafhankelijke invoervelden.
Herontwerpen van processen en systemen in nauwe samenwerking met eindgebruikers, met aandacht voor de onderliggende architectuur (digitale workflow) van het systeem.

Stel een “maatwerk-poort” in: alleen als configuratie/standaard klinisch niet volstaat én de Total Cost of Ownership (TCO) en (klinische) risicoanalyse (o.a. FMEA) is doorgerekend voor de gevraagde afwijking van de standaard implementatie.

Bij de Total Cost of Ownership (TCO) kijk je niet alleen kijkt naar wat iets kost om te kopen/maken, maar ook naar wat het (operationeel) kost om het te gebruiken, onderhouden en uiteindelijk te vervangen of af te voeren (extra ontwikkel-, beheer- en updatekosten).
In de risicoanalyse analyseer en benoem je de klinische, medicolegale, technische, financiële en veiligheidsrisico's die het maatwerk met zich meebrengt.

3) Data- en interoperabiliteitsgeletterdheid

Wat vaak ontbreekt

Basiskennis van datamodellen, data-standaarden en klinische terminologieën (SNOMED CT, LOINC, ICD, ATC, SAM v2 (Source Authentique des Médicaments), nomenclatuur, MZG, ...).
Inzicht in belang van interoperabiliteit (HL7 v2/FHIR), master data (patiënt/medewerker/afdeling) en datakwaliteit.
Vaardigheden voor datamigratie-validatie en mapping.

Hoe dit tot problemen leidt

“Eenvoudige” velden blijken niet eenduidig gedefinieerd en zijn dubbelzinnig te interpreteren → interface-issues, fouten in rapportages.
Migratie wordt onderschat → go-live uitstel of dure nabehandeling.

Tegenmaatregelen

Train key users in basis FHIR & terminologie-mapping; definieer datakwaliteitsregels per veld.
Plan migratie als apart werkpakket met klinische validatie-scripts. Geen migratie zonder verificatie en validatie voor go-live, omwille van de medicolegale en klinische risico’s.

4) Regelgeving, veiligheid en risico

Wat vaak ontbreekt

Kennis van (al) de wettelijke vereisten waaraan (werken met) een EPD dient te voldoen in België. Rondvragen aan collega's die het ook niet echt weten, verhelpt hier niet aan.
Werkbare kennis wetgeving, van privacy-by-design (GDPR), logging, toestemming en least privilege.
Begrip wanneer functies medische software worden (Medical Device Regulation (MDR), Verordening voor medische hulpmiddelen) en wat dat betekent voor traceability, verificatie/validatie.
Klinisch risicomanagement (FMEA, hazard analysis) en usability-risico’s.

Usability-risico’s in software zijn risico’s die te maken hebben met de bruikbaarheid van een systeem: hoe makkelijk, efficiënt en foutloos eindgebruikers er dagdagelijks daadwerkelijk mee kunnen werken. Als de usability slecht is, kan de software technisch perfect werken, maar toch mislukken omdat gebruikers het niet begrijpen, verkeerd gebruiken of omzeilen (onduidelijke interface, complexe workflows, onvoldoende foutafhandeling, gebrek aan consistentie, slechte performance of laadtijden, onvoldoende toegankelijkheid, leercurve te hoog, mismatch met werkpraktijk)

Besef van het risico van onvoldoende datakwaliteit aan de bron voor medische aansprakelijkheid, CoZo, Minimale Ziekenhuis Gegevens (MZG), Tarificatie/Facturatie, Budget Financiële Middelen (BFM) (Garbage In, Garbage Out, GIGO)

Hoe dit tot problemen leidt

“Kleine” wijzigingen hebben verborgen impact op audit, veiligheid of toezicht → herbouw/vertraging.
Usability-risico’s zijn de risico’s dat software moeilijk bruikbaar is voor eindgebruikers, wat kan leiden tot hogere kosten, lagere efficiëntie en verminderde acceptatie van het systeem:

Hogere kosten voor training, support en change management.

Lagere productiviteit doordat gebruikers meer tijd kwijt zijn.

Grotere kans op (medische) fouten, dataverlies of incorrecte invoer.

Adoptierisico: gebruikers accepteren het systeem niet en vallen terug op Excel, mail of andere eigen oplossingen.

Late compliance-bevindingen veroorzaken scope-sprongen en dure correcties laat in het traject of na go-live.
Medicolegale (aansprakelijkheid) en financiële gevolgen (Tarificatie/Facturatie, Minimale Ziekenhuis Gegevens (MZG), Budget Financiële Middelen (BFM)) indien niet is voldaan aan de wettelijke vereisten.

Tegenmaatregelen

Wettelijke vereisten expliciet vermelden (GDPR, wetteksten, KB’s, rechtspraak, deontologie, must have) en voor de aanvang de verantwoordelijkheid van het ziekenhuis en de leverancier contractueel vastleggen, zodat daaraan wordt voldaan voor de go-live.
Wettelijke vereisten begrijpen en consistent (laten) toepassen tijdens het project (en daarna).
De wettelijke vereisten op een rijtje zetten van bij de start en centraal en duidelijk beschikbaar stellen voor het hele projectteam. Vanuit het juridisch departement ondersteuning bieden tijdens het hele traject (SPOC).
Integreer risico- en privacy-checklists in de Change Control Board (CCB) die de wetgeving kent en begrijpt; koppel elke user story aan risk & audit requirements. Werk met een juridisch competente/ondersteunde Change Control Board (CCB).
Voorzie een Clinical Safety Officer (CSO) die een (klinisch) risicolog en safety case bijhoudt.

Een Clinical Safety Officer (CSO) is een arts of andere klinisch gekwalificeerde professional die verantwoordelijk is voor de patiëntveiligheid bij het ontwerpen, implementeren en gebruiken van digitale systemen zoals elektronische patiëntendossiers (EPD’s), beslissingsondersteuning of medische applicaties.
Een risicolog is een up-tot-date register van alle geïdentificeerde risico’s en gevaren die met een systeem of (zorg-)proces te maken hebben. Het risicolog is een werkdocument, het is een lijst met risico’s en de status daarvan.
Een safety case is een gestructureerd argument (met bewijs) dat een systeem veilig genoeg is voor gebruik in de beoogde context. De safety case is een eindproduct/argumentatie dat laat zien dat de risico’s voldoende zijn beheerst en dat het systeem veilig kan worden ingezet.
De CSO waakt over klinische veiligheid en patiëntveilig gebruik van technologie.

Betrek van bij de aanvang de Data Protection Officer (DPO), de onafhankelijke toezichthouder binnen de organisatie die erop let dat persoonsgegevens correct en veilig worden verwerkt.

De DPO waakt over privacy en wettelijke bescherming van persoonsgegevens.

5) Testdesign, UAT en release-discipline

Wat vaak ontbreekt

Schrijven van kwalitatieve en realistische taakgerichte testscenario’s (happy/edge/error paths) en het organiseren van representatieve User Acceptance Testing (UAT)-data:

Happy path: de normale, succesvolle flow.
Edge path(s): grensgevallen en uitzonderingen (maxima/minima, zeldzame combinaties, timing).
Error path(s): foutcondities en afhandeling (invalid input, autorisatie, uitval van koppelingen).

Inzicht in release-management (freeze-vensters, rollback, hypercare, bekendmaking).

Freeze-venster (freeze window) is een vooraf afgesproken periode (dagen/weken) waarin geen nieuwe scope meer wordt toegevoegd en geen wijzigingen meer worden doorgevoerd behalve blocker-fixes.
Rollback is het gecontroleerd terugdraaien naar de vorige stabiele versie als de release problemen veroorzaakt.
Hypercare is een verhoogde supportperiode na go-live (bv. 1–4 weken) met uitgebreide bezetting, snelle triage, langere openingstijden en dagelijkse monitoring/stand-ups.
Bekendmaking (communicatie) is het planmatige informeren van alle doelgroepen (artsen, verpleegkundigen, apotheek, administratie, IT, soms patiënten) over wat er verandert, wanneer, impact, downtime, wat te doen bij issues, waar handleidingen staan.

Freeze geeft rust om goed te testen, rollback is je vangnet, hypercare je airbag na de start, en bekendmaking zorgt dat iedereen klaarstaat. Samen beperken ze risico, rework en dus scope-, tijd- en budgetschade.

Hoe dit tot problemen leidt

User Acceptance Testing (gebruikersacceptatietesten, UAT) vindt “even tussendoor” plaats → defecten worden pas vastgesteld in productie, noodpatches en budgetlekken.
Geen rollback-pad → lange verstoringen of kostbare “hot fixes”.

Tegenmaatregelen

Maak realistische, goede en effectieve testcharters per workflow; definieer entry/exit criteria voor UAT. Let op voor interdomein afhankelijkheden, voorkom testen in silo’s die niet representatief zijn voor de werking in productie (klinische paden, ADT).
Besteed aandacht aan regressietesten die nagaan of bestaande, eerder werkende functionaliteit nog steeds correct werkt nadat er (ergens) iets is gewijzigd - code, configuratie, interfaces, regels, of infrastructuur. Ze vangen “oude” bugs die terugkeren (“regressies”) door nieuwe wijzigingen. In EPD-projecten voorkomen regressietesten duur rework, incidenten na go-live en dus tijd- en budgetoverschrijding.
Plan een of meerdere dress rehearsals, go/no-go-criteria en hypercare-rooster vooraf.

Een dress rehearsal is een volledige, realistische generale repetitie van de go-live in een veilige (niet-productie) omgeving. Je voert het héle cut-over-scenario van begin tot eind uit - met alle teams, datamigraties, interfaces, communicatie, checks en besluitpunten - alsof het de echte livegang is. Het doel is om tijd, risico en gaten in het zorgproces bloot te leggen vóór het menens is met echte patiënten.
Een hypercare-rooster is het dienst- en bereikbaarheidsplan voor de extra-intensieve supportperiode direct na go-live. Het legt vast wie, wanneer, waar en hoe incidenten wordt oppakt - zowel klinisch (op de werkvloer) als IT (applicatie, integraties, infrastructuur) - met duidelijke escalaties en responstijden. Zo voorkom je chaos, dubbelle werk en lange onderbrekingen.

6) Leveranciers- en contractvaardigheden

Wat vaak ontbreekt

Lezen van statement of work en SLA’s, herkennen van aannames en verborgen kosten.
Change-request-discipline en impactinschatting (tijd/kost/risico).

Hoe dit tot problemen leidt

Scope schuift via interpretatieverschillen → meerwerk zonder budget.
Vendor-lead times en afhankelijkheden worden verkeerd ingeschat → kettingvertragingen.

Tegenmaatregelen

Begrijp de Statement of Work (SoW), een contractuele bijlage die precies vastlegt wat er geleverd wordt, tegen welke kwaliteit, door wie, wanneer, onder welke voorwaarden, en hoe acceptatie gebeurt. Het is de “single source of truth” tussen ziekenhuis en leverancier/implementatiepartner. Een goede SoW is hét antidotum tegen scope creep, misverstanden, tijd- en budgetoverschrijding.
Train product owners in contract-basics; hanteer een change-matrix (standaard doorlooptijd/kost).
Houd een beslissingslog en interfacecatalogus bij die contractueel verankerd is.

7) Project- en agile-basiskennis

Wat vaak ontbreekt

Inzicht in capaciteit versus vraag, critical path, afhankelijkheden en realistische sizing.
Rolzuiverheid bij een iteratieve project-aanpak (agile) (product owner is niet dezelfde als de lijnmanager; stakeholder is niet dezelfde als de beslisser).

Hoe dit tot problemen leidt

Overvol getrokken sprints bij een agile projectaanpak, te veel parallel werk → context-switching en slip.

Context-switching betekent vaak moeten wisselen tussen taken/onderwerpen/teams, waardoor je telkens mentaal moet “opstarten” en werk versnipperd raakt.
Slip bij planningsoverdracht is een taak of mijlpaal die schuift voorbij de afgesproken datum (schedule slip).

Besluiten blijven hangen → wachttijden en planning loopt in het honderd.

Tegenmaatregelen

Visualiseer werk-in-uitvoering-limieten; plan slechts X initiatieven per domein.
Stel een competente, effectieve en efficiënte Change Control Board (CCB) in met vaste cadans en SLA’s voor besluitvorming.

8) Communicatie, besluitvorming en gedrag

Wat vaak ontbreekt

Onderhandelings- en “nee-zeg”-vaardigheden; verwachtingen managen over wat nu/later/nooit komt. Dit geldt zeker voor de medewerkers aan de kant van de leverancier in het belang van de consistentie van de architectuur van het systeem (performantie, kwaliteit, veiligheid).
Strakke notulering en besluitvastlegging (besluit, rationale, alternatieven).
Cross-functionele vertaling (klinische taal verstaanbaar, effectief en efficiënt vertalen naar/van IT/architectuur).

Hoe dit tot problemen leidt

Informele (vage) afspraken worden later “verplichtingen” → ongecontroleerde scope.
Misverstanden over definities en workflows tussen kliniek en IT/architectuur → rework.

Tegenmaatregelen

Werk met een open beslislog en roadmap die ook “nee’s” expliciet toont van bij de start van het traject (o. a. vanwege basisarchitectuur). Een open beslislog is een publiek, doorzoekbaar register van (project)beslissingen - wat is besloten, waarom, met welke alternatieven en gevolgen - zodat iedereen dezelfde waarheid ziet. Het voorkomt “mondelinge afspraken” die later tot scope creep, misverstanden, tijd- en budgetoverschrijding leiden.
Train “structured communication” (Situation – Background – Assessment – Recommendation, SBAR) voor requirements en escalaties. Het is een gestructureerde manier van communiceren (oorspronkelijk uit de kliniek) die je één helder verhaal laat vertellen: wat is er aan de hand, wat is de context, wat is je analyse, en wat wil je dat er gebeurt. In EPD-/medische-softwareprojecten voorkomt dit ruis, misverstanden en eindeloos heen-en-weer — dus minder scope creep, minder context-switching, minder slip.

Vroege waarschuwingssignalen (die op een skills-kloof duiden)

“Dit is vast een kleine aanpassing.” (geen impactbesef)
“We bouwen het wel even op maat.” (configuratie vs. maatwerk onduidelijk)
“We testen in productie; tijd ontbreekt.” (testdiscipline ontbreekt)
“Alles is Must-have.” (prioritering onvolwassen)
“Dat veld betekent voor iedereen hetzelfde.” (datageletterdheid ontbreekt)

Praktische interventies: een compact curriculum voor klinische key users

Outcome & prioritering (2u) - van features naar doelen, MoSCoW met harde Won’t-have.
User stories & acceptatie (2u) - sjablonen, Definition of Done, non-functionele eisen.
Procesmodellering (3u) - swimlanes/BPMN, uitzonderingen, service-levels.
Datageletterdheid (3u) - terminologie, datakwaliteit, basis FHIR/SNOMED CT/LOINC/ICD, master data.
Risico & privacy (3u) - FMEA-light, privacy-by-design, audit & logging.
Testdesign & UAT (3u) - testcharters, representatieve testdata, entry/exit-criteria.
Release & hypercare (2u) - freeze, rollback, communicatieplan.
Vendor & contract (2u) - wettelijk kader, SoW lezen, change-matrix, SLA’s, afhankelijkheden.
Agile basics (2u) - rollen, cadans, WIP-limieten, refinement.
Communicatie & besluitvorming (2u) - SBAR voor requirements, beslislog, “nee-zeggen”.

Organiseer dit niet als losse workshops, maar als onderdeel van rollen:

Clinical Product Owner (per domein): modules 1 - 10 (volledig).
Super users: modules 2 - 7, 10.
Klinisch sponsor/safety officer: modules 1, 4, 5, 7, 10.

Tot slot

Scope creep, tijd- en budgetoverschrijding ontstaan wanneer klinisch leiderschap zonder product-, data-, risico- en leveringsdiscipline beslissingen neemt. De remedie is geen “meer IT”, maar gerichte skill-ontwikkeling bij artsen en verpleegkundigen: prioriteren op uitkomsten, scherp requirements formuleren, data & interoperabiliteit begrijpen, risico/compliance vroeg adresseren, streng testen en leveren, en helder communiceren en besluiten. Met een compact curriculum, duidelijke rollen en een zichtbaar beslislog verandert klinische betrokkenheid van scope-motor in scope-beschermer.

Besteed ook aandacht aan ergonomie en het Quintuple Aim Model.

Bronnen:

Project Management Body of Knowledge (PMBOK)

IEC 62304:2006 Medical device software - Software life cycle processes

Koninklijk besluit betreffende het Algemeen Medisch Dossier. BS 17-07-1999.

Koninklijk besluit houdende bepaling van de algemene minimumvoorwaarden waarvan het medisch dossier, bedoeld in artikel 15 van de wet op de ziekenhuizen, gecoördineerd op 7 augustus 1987, moet voldoen. BS 30-07-1999.

Wet inzake de kwaliteitsvolle praktijkvoering in de gezondheidszorg. BS 14-05-2019 (Inwerkingtreding: 1 juli 2021)

Adviezen over informatica van de Orde der Artsen (België)

European Electronic Health Record exchange Format (EHRxF)

Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (Text with EEA relevance)

Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC (Text with EEA relevance. )

General Data Protection Regulation (GDPR)

European Health Data Space Regulation (EHDS)

The interoperability of EHR systems and health apps in the European Health Data Space

NIS2 Directive implementation in Belgium

Minimale Ziekenhuis Gegevens (MZG)

Budget Financiële Middelen (BFM)

Terminologiecentrum (FOD VVVL)

Welcome to FHIR®

eHealthBox

CoZo: het Collaboratief Zorgplatform

Eisenkaders voor de algemene, universitaire en revalidatieziekenhuizen (Vlaanderen)

Belgian Meaningful Use Criteria (BMUC)