Onderwerp 3.3 — Digitale diensten voor patiënten en burgers

Een digitale dienst voor patiënten is een volksgezondheidsinterventie op zich: zij kan toegang en vertrouwen voor miljoenen vergroten, of stilletjes juist de mensen uitsluiten die zorg het meest nodig hebben, en hoe u haar bouwt bepaalt welke van de twee.

Waarom dit ertoe doet in gezondheid en zorg#

Wanneer u een dienst rechtstreeks in de handen van het publiek legt, verandert u de relatie tussen een persoon en het systeem dat voor hem of haar zorgt. Een systeem voor medewerkers wordt gebruikt door opgeleide mensen binnen een beheerste omgeving; een dienst voor patiënten wordt gebruikt door een bange ouder om 02.00 uur, een 84-jarige die een telefoon deelt met een buurman, iemand zonder vast adres, iemand die weinig Engels leest, iemand in crisis. U kiest uw gebruikers niet, leidt ze niet op en staat niet naast hen. De dienst moet veilig, duidelijk en eerlijk werken voor iedereen die het zorgstelsel verplicht is te dienen, niet louter voor de zelfverzekerden en goed verbondenen.

Die verplichting maakt het anders dan consumententechnologie. In de detailhandel kost een verwarrende kassa een verkoop. In gezondheid en zorg kan een verwarrend online triageformulier, een onduidelijke medicatie-instructie of een “boek een afspraak”-stroom die stilletjes faalt leiden tot een gemiste diagnose, een verkeerde dosis of iemand die opgeeft en later en zieker verschijnt. De inzet is klinisch (zie Onderwerp 1.6 — Klinische veiligheid en risicobeheer), juridisch (plichten voor gelijkheid en toegankelijkheid binden publieke organen) en financieel, omdat publiek geld wordt uitgegeven of de dienst nu iemand helpt of niet.

Er is ook een vertrouwensdimensie die consumentenproducten zelden dragen. Mensen brengen hun gezondheidsgegevens, hun angsten en een leven aan ervaring met de NHS mee naar elk scherm dat u hen toont. Als de dienst uitbuitend, ondoorzichtig of onveilig aanvoelt, haken zij niet simpelweg af — zij verliezen vertrouwen in de instelling erachter (zie Onderwerp 1.8 — Data-ethiek, toestemming en publiek vertrouwen). En omdat de mensen die een slechte digitale dienst het minst kunnen navigeren onevenredig vaak ouder, armer, gehandicapt of digitaal uitgesloten zijn, vergroten slecht ontworpen diensten voor patiënten actief gezondheidsongelijkheden. Dit goed doen is geen kwestie van afwerking. Het is een kwestie van billijkheid, veiligheid en publiek vertrouwen.

Kernbegrippen#

Een dienst voor patiënten is de “digitale voordeur”: het online toegangspunt waarlangs iemand informatie vindt, bewijst wie hij of zij is en een taak begint. In Engeland zijn de twee nationale platforms die de meeste mensen tegenkomen de NHS App en NHS login. De NHS App, ontwikkeld door NHS England, laat mensen in Engeland huisartsafspraken boeken en beheren, herhaalrecepten bestellen, hun door de huisarts gehouden dossier inzien, NHS 111 online raadplegen en voorkeuren voor het delen van data en orgaandonatie instellen. NHS login is de afzonderlijke identiteits- en authenticatiedienst die verifieert wie iemand is (op een evenredig niveau van zekerheid) zodat hij of zij veilig bij zijn of haar eigen dossier kan komen over vele NHS- en partnerdiensten — zoals GOV.UK Verify ooit voor de centrale overheid beoogde te doen. Het is belangrijk deze nauwkeurig te beschrijven: de NHS App is een voordeur en een app, terwijl NHS login de identiteitslaag is die veel apps en websites, niet alleen de NHS App, kunnen gebruiken.

Achter de voordeur zitten dossiers en hulpmiddelen. Een elektronisch gezondheidsdossier (electronic health record, EHR) is het door clinici bijgehouden dossier van een aanbieder. Een persoonlijk gezondheidsdossier (personal health record, PHR) is een dossier dat de patiënt kan zien, aanvullen en soms beheren, wat hem of haar een vollediger beeld van de eigen zorg geeft. Een patiëntenportaal is de web- of appinterface waarmee mensen uitslagen, berichten, brieven en dossiers bekijken en met hun zorgteam communiceren. “Toegang van patiënten tot dossiers” — het recht uw eigen huisarts- en steeds vaker ziekenhuisdossier te lezen — is nu in Engeland een standaardverwachting, geen gunst.

Verscheidene soorten diensten draaien daarbovenop. Online consultatie en online triage laten iemand een probleem digitaal beschrijven zodat het kan worden gerouteerd en geprioriteerd zonder telefoonrij. Gezamenlijke besluitvorming in de geneeskunde is de praktijk waarin clinicus en patiënt samen zorgbeslissingen nemen, ondersteund door duidelijke informatie en keuzehulpen — vastgelegd in de NHS-uitdrukking “no decision about me, without me”. Hulpmiddelen voor zelfmanagement helpen mensen dagelijks langdurige aandoeningen te beheren. Monitoring van patiënten op afstand en telezorg breiden zorg uit naar huis via apparaten, video en asynchrone berichten.

De begrippen die bepalen of dit alles werkt gaan over mensen, niet over functies. Adoptie is of mensen een dienst beginnen te gebruiken; activatie is of zij het punt bereiken waarop zij er waarde uit halen; en blijvende betrokkenheid is of zij haar blijven gebruiken wanneer het ertoe doet. De Patient Activation Measure (PAM) is een gevalideerd instrument voor een verwant idee — de kennis, vaardigheden en het vertrouwen van een persoon om de eigen gezondheid te beheren. Daartegenover staat de digitale kloof: het gat in toegang, connectiviteit en vertrouwen dat betekent dat een puur digitale gezondheidsdienst sommige mensen achterlaat tenzij begeleide digitale en niet-digitale routes bewust behouden blijven (zie Onderwerp 1.9 — Digitale inclusie en toegankelijkheid).

Beste praktijken#

1. Ontwerp de hele voordeur, niet één app. Besluit bewust welke kanalen iemand kan gebruiken voor elke taak — app, website, telefoon, persoonlijk, via een mantelzorger of gemachtigde — en maak ze consistent in plaats van concurrerend. Een dienst voor patiënten is een set routes naar een behoefte, niet één download. Breng in kaart waar de digitale route overgaat in een menselijke en maak die naad soepel, omdat de meeste echte trajecten haar kruisen. Behandel kanaalkeuze als die van de gebruiker, niet aan u om af te dwingen.

2. Gebruik nationale platforms in plaats van ze opnieuw te bouwen. Waar de NHS App en NHS login al identiteit, toegang tot dossiers, afspraken en recepten bieden, integreer ermee in plaats van een parallelle voordeur te bouwen die de ervaring en het beveiligingsmodel fragmenteert. Dit geeft gebruikers één vertrouwde identiteit en één plek om te kijken, en erft borgingswerk dat u anders zou herhalen. Bewaar maatwerkbouw voor werkelijk lokale behoeften die de nationale platforms niet dekken, en voed die behoeften terug aan de nationale teams (zie Onderwerp 9.0 — Samenwerken met partnerorganisaties).

3. Geef mensen echte toegang tot hun eigen dossiers en maak ze begrijpelijk. Toegang tot dossiers bouwt vertrouwen en ondersteunt zelfmanagement, maar een dossier dat in klinisch steno op het scherm wordt gegooid kan verwarren of beangstigen. Investeer in contentontwerp zodat uitslagen, brieven en gecodeerde items begrijpelijk zijn, en denk zorgvuldig na over gevoelige informatie, safeguarding en hoe een gemachtigde of mantelzorger de data van een ander ziet (zie Onderwerp 1.10 — Bescherming van kwetsbare personen in digitale diensten). Toegang van patiënten is een ontwerpprobleem, niet slechts een schakelaar om om te zetten.

4. Behoud begeleide digitale en niet-digitale routes als blijvende functie. Houd voor elke online taak een ondersteunde en een volledig offline manier om haar te voltooien en voorzie ze behoorlijk van middelen in plaats van ze als legacyoverhead te behandelen. “Digitaal als standaard” mag nooit “alleen digitaal” betekenen, omdat een betekenisvol deel van de bevolking de digitale route niet kan of wil gebruiken, en dat onevenredig degenen met de grootste behoefte zijn. Ontwerp de begeleide route — een telefoonlijn, een baliemedewerker, een helper in de bibliotheek, een gemachtigde in de familie — met dezelfde zorg als de app (zie Onderwerp 1.9 — Digitale inclusie en toegankelijkheid).

5. Maak online triage klinisch veilig door ontwerp. Elk hulpmiddel dat naar symptomen vraagt en mensen routeert moet worden gebouwd en bestuurd als activiteit van klinische veiligheid, met duidelijke escalatie voor alarmsymptomen en een voorkeur voor veilige overtriage. Pas de relevante normen voor klinisch risicobeheer toe, houd een benoemde klinischeveiligheidsfunctionaris betrokken en monitor uitkomsten op gemiste of vertraagde zorg (zie Onderwerp 1.6 — Klinische veiligheid en risicobeheer). Een triagestroom die stilletjes faalt is geen bruikbaarheidsdefect; het is een patiëntveiligheidsincident.

6. Ondersteun gezamenlijke besluitvorming, niet slechts transacties. De hoogste waarde in digitaal voor patiënten is mensen helpen opties te begrijpen en keuzes te maken die bij hun leven passen, niet louter tijdsloten boeken. Bied keuzehulpen, informatie in eenvoudige taal en prompts die uitnodigen tot vragen, en ontwerp zodat iemand kan pauzeren, familie kan betrekken en kan terugkeren. Meet of mensen zich beter geïnformeerd en meer in controle voelen, want dat is het punt van het hulpmiddel. Transacties zijn noodzakelijk; overleg is waar uitkomsten verbeteren.

7. Instrumenteer voor uitkomsten en ervaring, niet voor ijdelheidsmaten. Downloads en registraties vertellen u bijna niets; een dienst kan miljoenen geregistreerde gebruikers hebben en niemands gezondheid veranderen. Meet activatie en blijvend, betekenisvol gebruik, taakvoltooiing en — waar mogelijk — echte klinische uitkomsten en door patiënten gerapporteerde ervarings- en uitkomstmaten (PREM’s en PROM’s). Publiceer deze naast adoptiecijfers zodat de organisatie bereik niet voor waarde kan aanzien (zie Onderwerp 10.0 — Doelstellingen en kernresultaten (OKR’s)).

8. Bouw vertrouwen door duidelijkheid, toestemming en veiligheid. Vertel mensen eenvoudig wat een dienst doet, wat zij niet doet, wie hun data ziet en hoe zij hulp krijgen of een mens bereiken. Maak keuzes over toestemming en het delen van data echt en omkeerbaar, en dwing mensen nooit met dark patterns meer te delen dan zij bedoelen (zie Onderwerp 1.8 — Data-ethiek, toestemming en publiek vertrouwen). In de gezondheidszorg is vertrouwen het platform waarop al het andere draait; één schending ervan kost veel meer dan enige functie oplevert.

9. Ontwerp vanaf het begin voor interoperabiliteit. Een dienst voor patiënten die niet uit de onderliggende dossiers kan lezen en erin kan schrijven is een silo die dubbel invoeren en fouten creëert. Gebruik open normen zodat boekingen, berichten en observaties stromen van en naar de systemen die clinici werkelijk gebruiken, en zodat iemands data hem of haar volgt over een gefragmenteerd zorglandschap (zie Onderwerp 4.3 — Interoperabiliteit en datastandaarden). Het publiek ervaart interoperabiliteit als “ik hoef mezelf niet te herhalen” — en de afwezigheid ervan als gevaar en frustratie.

10. Sluit de lus met voortdurend onderzoek en live operaties. Blijf ook na de lancering onderzoeken met echte, diverse gebruikers, niet alleen ervoor, en voed wat u leert terug in de backlog (zie Onderwerp 3.0 — Gebruikersonderzoek en servicedesign). Run de dienst als live product met behoorlijke ondersteuning, monitoring en incidentrespons, omdat een dienst voor patiënten die uitligt of kapot is vertrouwen onmiddellijk aantast (zie Onderwerp 3.8 — Servicemanagement en live-operatie). Adoptie wordt voortdurend verdiend, niet eenmaal binnengehaald.

Vragen om met uw team te bespreken#

1. Wie kan deze dienst niet gebruiken zoals wij haar hebben ontworpen, en wat gebeurt er met hen? Elke dienst voor patiënten bevat aannames — dat mensen een smartphone, data, een e-mailadres, een vaste identiteit om tegen te verifiëren, de geletterdheid en het vertrouwen om een formulier in te vullen en het zicht, de handvaardigheid en de taal daarvoor hebben. Noem de groepen die uw huidige ontwerp uitsluit of benadeelt en wees specifiek: mensen zonder door de NHS verifieerbare identiteit, mensen die één apparaat delen, mensen die misbruik ontvluchten en geen digitaal spoor kunnen riskeren, mensen met cognitieve beperking. Besluit voor elk wat de begeleide of niet-digitale route werkelijk is, wie haar van middelen voorziet en hoe u weet dat ze werkt. Een goed, eerlijk antwoord beweert niet iedereen via de app te bedienen; het noemt de uitgeslotenen, kwantificeert hen waar mogelijk en toont een gefinancierd, waardig alternatief in plaats van een symbolisch telefoonnummer dat niemand beantwoordt. Hier wordt billijkheid gewonnen of verloren, en het sluit rechtstreeks aan bij Onderwerp 1.9 — Digitale inclusie en toegankelijkheid.

2. Hoe zullen wij weten dat deze dienst de gezondheid werkelijk verbetert, en niet alleen dat mensen zich hebben aangemeld? Het is gemakkelijk registraties en downloads te vieren omdat ze telbaar zijn en stijgen; het is veel moeilijker, en veel belangrijker, aan te tonen dat iemand er beter van wordt. Bespreek welke uitkomst u werkelijk probeert te bewegen — minder gemiste afspraken, beter gereguleerde langdurige aandoeningen, eerdere presentatie, beter geïnformeerde beslissingen — en hoe u een verandering daarin zou detecteren. Debatteer de afweging tussen maten die u nu goedkoop kunt verzamelen en de moeilijkere maten van activatie, blijvend gebruik en klinische uitkomst die de waarheid vertellen. Overweeg wie verantwoordelijk is als adoptie hoog is maar uitkomsten vlak blijven, en of u bereid bent de dienst te wijzigen of te stoppen als het bewijs zegt dat zij niet helpt. Een sterk antwoord koppelt de dienst aan een klein aantal eerlijke uitkomst- en ervaringsmaten, erkent wat u nog niet kunt meten en weigert ijdelheidsmaten voor waarde te laten doorgaan (zie Onderwerp 1.3 — Op bewijs gebaseerde besluitvorming en Onderwerp 10.0 — Doelstellingen en kernresultaten (OKR’s)).

3. Waar wordt digitaal gemak afgewogen tegen klinische veiligheid, en wie beslist? Hulpmiddelen voor patiënten creëren echte spanningen: snellere toegang kan minder klinisch toezicht betekenen; triage via zelfbediening kan de subtiele presentatie missen die een clinicus zou vangen; mensen hun ruwe uitslagen tonen kan informeren of alarmeren; mensen rechtstreeks laten boeken kan prioritering ondermijnen. Werk door waar uw dienst neigt naar gemak en waar zij naar voorzichtigheid moet neigen, en maak die keuzes expliciet in plaats van emergent. Vraag wie het veiligheidsdossier bezit, hoe alarmsymptomen escaleren en hoe u monitort op schade die pas in de loop der tijd in aggregaat zichtbaar wordt. Overweeg ook de invalshoek van safeguarding — een dienst die ervan uitgaat dat de persoon op het scherm is wie hij of zij zegt te zijn, en veilig is, heeft niet altijd gelijk (zie Onderwerp 1.10 — Bescherming van kwetsbare personen in digitale diensten). Een goed antwoord behandelt veiligheid vanaf dag één als ontwerpinput, met een benoemde klinischeveiligheidsfunctionaris en live monitoring, niet als nalevingsgoedkeuring aan het eind.

4. Wanneer de digitale route iemand overdraagt aan een menselijke, hoe soepel is die naad — en wie vangt op wat erdoorheen valt? Bijna elk echt patiënttraject gaat van de app naar een persoon en soms terug: een online triage die naar een terugbelverzoek routeert, een boeking waarvoor een baliemedewerker nodig is, een verzoek van een gemachtigde dat geverifieerd moet worden, een uitslag die een bezorgd bericht uitlokt. Deze overdrachten zijn waar diensten stilletjes falen, omdat elke kant aanneemt dat de ander de persoon en de context heeft. Breng de specifieke overgangen in kaart die uw dienst schept en vraag welke informatie ze oversteekt, hoe lang de persoon wacht en wat er gebeurt als geen van beide kanten hem of haar oppakt. Debatteer of de digitale route werkelijk de belasting voor medewerkers vermindert of die slechts naar een minder zichtbare plek verplaatst, en of teams in de frontlinie samen met u de nieuwe stroom hebben ontworpen en haar niet slechts kregen overhandigd (zie Onderwerp 3.0 — Gebruikersonderzoek en servicedesign). Een eerlijk antwoord kan een persoon van begin tot eind over elke naad volgen, noemt wie de overdracht bezit en toont de terugvaloptie voor wanneer de geautomatiseerde route de klus niet kan afmaken — in plaats van aan te nemen dat de digitale voordeur de lus zelf sluit.

5. Wat zijn de totale kosten om dit jarenlang goed te runnen, en zijn wij daar eerlijk voor van middelen voorzien? Diensten voor patiënten worden vaak gefinancierd als projecten — een bouw, een lancering, een kop — terwijl het in werkelijkheid live producten zijn die onbeperkt moeten worden ondersteund, gemonitord, onderzocht en verbeterd, naast de begeleide digitale en niet-digitale routes die zij nooit volledig kunnen vervangen. Bespreek wat het werkelijk kost de telefoonlijn bemand te houden, de inhoud actueel, de toegankelijkheid onderhouden, het veiligheidsdossier levend en de integraties werkend naarmate nationale platforms onder u veranderen. Breng de ongemakkelijke afweging aan het licht dat een werkelijk inclusieve dienst duurder is dan een alleen-digitale, en besluit of de businesscase is gebouwd op echte terugkerende financiering of op optimistische besparingen die ervan uitgaan dat iedereen van kanaal wisselt. Overweeg waarmee u zult stoppen om dit te betalen en wie verantwoordelijk is wanneer de financiering in jaar twee verdampt maar de dienst en haar gebruikers blijven. Een sterk antwoord behandelt duurzaamheid en ondersteuning vanaf het begin als eersteklas kosten (zie Onderwerp 3.8 — Servicemanagement en live-operatie en Onderwerp 6.1 — Gezondheidseconomie), niet als bijzaak zodra het lanceringsbudget is besteed.

6. Wie bezit deze dienst nadat de lancering voorbij is, en hebben zij het mandaat haar te blijven veranderen? Een dienst voor patiënten die niemand als levend product bezit drijft weg: inhoud veroudert, toegankelijkheid gaat achteruit, de integratie breekt stilletjes en onderzoek stopt de dag dat het projectteam wordt ontbonden. Bespreek wie de dienst na go-live houdt, of zij een echt productteam zijn met het gezag om functies te prioriteren, te wijzigen en zelfs uit te schakelen, of slechts een onderhoudsfunctie die de lichten aan kan houden. Onderzoek hoe beslissingen worden genomen wanneer klinische, operationele, informatiebeheer- en communicatiebelanghebbenden allemaal een belang en een veto hebben, en of dat beslispad snel genoeg is om een veiligheidsprobleem op te lossen of traag genoeg om er een te beschermen. Overweeg hoe terugkoppeling van gebruikers en medewerkers in de frontlinie de mensen bereikt die kunnen handelen, en of de organisatie een team zal blijven financieren om iets te verbeteren dat al lijkt te werken. Een eerlijk antwoord noemt de verantwoordelijke eigenaar, beschrijft zijn of haar echte mandaat en hoe live leren de backlog voedt, en erkent waar bestuur de dienst beschermt of verlamt (zie Onderwerp 5.0 — Productgestuurd werken).

In de praktijk: een voorbeeld uit gezondheid en zorg#

Een geïntegreerd zorgsysteem (ICS) dat een gemengde stedelijke en kustbevolking beslaat wil de druk op huisartsentelefoonlijnen verminderen en toegang verbeteren, en stelt voor een online consultatie- en triagehulpmiddel uit te rollen dat is geïntegreerd met de NHS App en NHS login. De verleiding is succes te meten aan het aantal registraties en de daling van het belvolume en binnen een kwartaal de overwinning uit te roepen.

De leveringsleider staat erop het anders te kaderen. In discovery onderzoekt het team met een bewust brede groep: zelfverzekerde appgebruikers, maar ook een oudere vrouw aan de kust met haperend breedband, een man met lage geletterdheid die nooit e-mail heeft gebruikt, een mantelzorger die als gemachtigde afspraken voor haar moeder beheert en een vrouw in een opvanghuis die niet kan riskeren dat haar verblijfplaats wordt gelogd. Zij vinden dat de afhandeling van alarmsymptomen in het triageformulier deugdelijk is maar dat de taal de gebruiker met lage geletterdheid verslaat, dat het traject voor gemachtigden verwarrend is en dat de identiteitsverificatie in NHS login mensen zonder paspoort of rijbewijs uitsluit. Cruciaal is dat zij vinden dat wanneer de telefoonlijn minder prioriteit krijgt ten gunste van de app, de gebruikers aan de kust en de kwetsbare gebruikers eenvoudig uit contact verdwijnen in plaats van van kanaal te wisselen.

Dus herziet het ICS zijn plan. Het houdt de telefoonlijn volledig bemand als begeleide digitale route, niet als legacykost, en financiert een gemeenschapsregeling van “digitale gezondheidshelpers” via bibliotheken en apotheken. Het werkt met het nationale team van de NHS App aan het traject voor gemachtigden in plaats van een omweg te bouwen, en benoemt een klinischeveiligheidsfunctionaris om het triagerisicodossier te bezitten, met monitoring op gevallen waarin digitale triage een patiënt te laag routeerde die later acuut verscheen. Het verandert ook zijn maten: naast adoptie volgt het taakvoltooiing per gebruikersgroep, blijvend gebruik, door patiënten gerapporteerde ervaring en een klein aantal klinische uitkomsten. Zes maanden later zijn de downloads lager dan een pure app-eerst-aanpak zou hebben opgeleverd, maar de toegang is verbeterd over elke groep, ook de meest uitgeslotenen, en het triagehulpmiddel heeft verscheidene ernstige presentaties veilig geëscaleerd. Het bestuur aanvaardt de tragere adoptie omdat de dienst aantoonbaar eerlijker en veiliger is.

Sectorperspectieven#

Startup#

Een klein bedrijf voor digitale gezondheid leeft of sterft bij adoptie en behoud, dus zal het betrokkenheid obsessief instrumenteren en snel itereren — een echte sterkte waarvan het bredere stelsel kan leren. Het gevaar is te optimaliseren voor de maten die investeerders imponeren (downloads, maandelijks actieve gebruikers) in plaats van gezondheidsuitkomsten, en te ontwerpen voor de zelfverzekerde early adopters die het goedkoopst te winnen zijn. Een startup die aan de NHS verkoopt moet tonen dat zij voldoet aan de Digital Technology Assessment Criteria (DTAC), integreert met NHS login en open normen in plaats van gebruikers in een silo te vangen en een geloofwaardig veiligheidsdossier heeft. De oprichters die langlopende contracten winnen zijn degenen die inclusie en veiligheid behandelen als productvereisten, niet als nalevingsballast.

Klein bedrijf#

Een gevestigde kleine aanbieder — een huisartsenpraktijk, een gemeenschapsapotheek, een verzorgingshuis of thuiszorgorganisatie, een kliniek met één vestiging — heeft echte patiënten en een zorgplicht maar vrijwel geen toegewijde digitale of IT-capaciteit, dus haar realistische zet is nationale platforms en leveranciershulpmiddelen over te nemen in plaats van een eigen voordeur te bouwen. Zij moet zwaar leunen op de NHS App, NHS login en de online-consultatiesystemen die al voor haar setting zijn geborgd, en haar schaarse inspanning besteden aan de menselijke naad: zorgen dat de balie, clinici en mantelzorgers kunnen omgaan met wat de digitale route hun stuurt en dat de telefoon- en inloopwegen werkelijk open blijven voor haar vaak oudere of kwetsbaardere patiënten. Dezelfde plichten voor toegankelijkheid, klinische veiligheid en toestemming binden haar als een groot ziekenhuis, maar zonder bestuursteam, dus zij moet weten welke leverancier het veiligheidsdossier draagt en welke verplichtingen de hare blijven. Een kleine aanbieder die haar gekozen systeem behandelt als een live dienst om te configureren en te monitoren, niet een vakje afgevinkt bij aankoop, zal haar gemeenschap veel beter dienen dan een die de standaardinstellingen aanzet en wegkijkt.

Grote onderneming#

Een groot NHS-ziekenhuis of ICS runt diensten voor patiënten op schaal over een gefragmenteerd bestand, dus zijn centrale probleem is samenhang: meerdere portalen, brieven en apps die elk één taak oplossen en samen de patiënt verbijsteren. Zijn voordeel is bereik en het vermogen begeleide digitale en niet-digitale routes behoorlijk te financieren; zijn risico is traagheid, gesiloede inkoop en de neiging nog een portaal te kopen in plaats van met nationale platforms te integreren. Bestuur is zwaarder en trager, wat veiligheid beschermt maar iteratie kan uithongeren, dus de onderneming heeft productteams nodig met een echt mandaat om live diensten te blijven verbeteren (zie Onderwerp 5.0 — Productgestuurd werken). De maat van volwassenheid is of een patiënt één samenhangende voordeur ervaart of een dozijn losse.

Overheid#

Een nationaal orgaan zoals NHS England bouwt de platforms — de NHS App, NHS login, toegang tot dossiers — waarop iedereen anders bouwt, dus zijn beslissingen stellen het plafond voor billijkheid en interoperabiliteit over het hele stelsel. Zijn verantwoording is aan het Parlement en het publiek voor uitgaven, veiligheid en eerlijkheid, wat de lat voor toegankelijkheid, transparantie en het behoud van niet-digitale routes terecht verhoogt. De moeilijke taak is een enkele, consistente nationale ervaring af te wegen tegen echte lokale variatie, en de politieke aantrekkingskracht te weerstaan kopcijfers van registraties te vieren boven echte uitkomsten. De unieke hefboom van de overheid zijn normen en standaardinstellingen: wat zij verplicht stelt voor identiteit, interoperabiliteit en toegankelijkheid vormt miljoenen interacties die zij nooit rechtstreeks zal ontwerpen.

Veelvoorkomende faalpatronen#

• Registratietheater. Downloads en aanmeldingen rapporteren als succes terwijl niemand controleert of iemand waarde of betere gezondheid krijgt. Herstel het door activatie, blijvend gebruik en uitkomsten vanaf het begin te meten.
• Sluipende alleen-digitaal. Telefoon- en persoonlijke routes stilletjes terugtrekken of onderfinancieren zodra de app bestaat, wat de meest kwetsbaren uitsluit. Herstel het door begeleide digitale en niet-digitale routes te behandelen als blijvende, gefinancierde functies.
• Portaalwildgroei. Elke dienst koopt een eigen patiëntenportaal, zodat het publiek een doolhof van logins tegenkomt. Herstel het door te integreren met nationale platforms en open normen.
• Triage als functie, niet als veiligheidsdossier. Symptoomroutering uitleveren zonder bestuur van klinische veiligheid of monitoring op schade. Herstel het door normen voor klinisch risico toe te passen en een klinischeveiligheidsfunctionaris te benoemen.
• Dossiers zonder begrip. Ruwe klinische data blootleggen zonder contentontwerp, wat patiënten alarmeert of verwart. Herstel het met inhoud in eenvoudige taal en zorgvuldige omgang met gevoelige en gemachtigde toegang.
• Toestemming via dark patterns. Mensen aansporen tot het delen van data die zij niet begrijpen, wat vertrouwen aantast. Herstel het met echte, eenvoudige, omkeerbare toestemming.
• Lanceren en weglopen. De dienst behandelen als project dat bij go-live eindigt in plaats van een live product dat moet worden onderzocht, ondersteund en verbeterd.

Volwassenheidsmodel#

Checklist#

• Voor elke taak bestaan en worden gefinancierd: een digitale, een begeleide digitale en een niet-digitale route
• De dienst integreert met de NHS App en NHS login in plaats van identiteit of de voordeur te dupliceren
• Patiënten hebben toegang tot hun eigen dossiers in taal die zij begrijpen, met veilige omgang met gemachtigden en gevoelige data
• Elke triage of symptoomroutering heeft een veiligheidsdossier, een benoemde veiligheidsfunctionaris en escalatie van alarmsymptomen
• Succesmaten omvatten activatie, blijvend gebruik, taakvoltooiing en echte uitkomsten — niet alleen downloads
• Keuzes over toestemming en het delen van data zijn eenvoudig, echt en omkeerbaar, zonder dark patterns
• Toegankelijkheid voldoet aan WCAG en wordt getest met hulptechnologie en echte uitgesloten gebruikers
• Boekingen, berichten en observaties stromen via open normen van en naar klinische systemen
• De dienst wordt gerund als live product met ondersteuning, monitoring en incidentrespons
• Onderzoek met een diverse populatie gaat na de lancering door en voedt de backlog

Belangrijkste bronnen#

• NHS England — richtlijnen en ontwikkelaarsdocumentatie voor de NHS App en NHS login
• NHS Service Standard en NHS Digital Service Manual — ontwerpen van toegankelijke, inclusieve publieke diensten
• GOV.UK Service Manual (Government Digital Service) — begeleid digitaal, kanaalkeuze en servicedesign
• NHS England — normen DCB0129 en DCB0160 voor klinisch risicobeheer voor IT in de gezondheidszorg
• Digital Technology Assessment Criteria (DTAC) — basislijn van NHS England voor digitale gezondheidstechnologieën
• NICE Evidence Standards Framework for Digital Health Technologies
• Web Content Accessibility Guidelines (WCAG) — W3C
• NHS RightCare Shared Decision-Making Programme
• Insignia Health / Judith Hibbard — Patient Activation Measure (PAM)

Referenties#

1. NHS app — Wikipedia — https://en.wikipedia.org/wiki/NHS_app
2. Personal health record — Wikipedia — https://en.wikipedia.org/wiki/Personal_health_record
3. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
4. Patient portal — Wikipedia — https://en.wikipedia.org/wiki/Patient_portal
5. Shared decision-making in medicine — Wikipedia — https://en.wikipedia.org/wiki/Shared_decision-making_in_medicine
6. Remote patient monitoring — Wikipedia — https://en.wikipedia.org/wiki/Remote_patient_monitoring
7. Telehealth — Wikipedia — https://en.wikipedia.org/wiki/Telehealth
8. Patient Activation Measure — Wikipedia — https://en.wikipedia.org/wiki/Patient_Activation_Measure
9. Digital divide — Wikipedia — https://en.wikipedia.org/wiki/Digital_divide
10. Digital health — Wikipedia — https://en.wikipedia.org/wiki/Digital_health
11. GOV.UK Verify — Wikipedia — https://en.wikipedia.org/wiki/GOV.UK_Verify
12. NHS App — NHS England — https://www.nhs.uk/nhs-app/
13. NHS login — NHS England — https://www.nhs.uk/nhs-services/online-services/nhs-login/
14. NHS Service Manual and Service Standard — NHS England — https://service-manual.nhs.uk/
15. GOV.UK Service Manual: Assisted digital and channel choice — Government Digital Service — https://www.gov.uk/service-manual/helping-people-to-use-your-service
16. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
17. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/about-us/digital-technology-assessment-criteria-dtac/
18. Evidence Standards Framework for Digital Health Technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health
19. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C — https://www.w3.org/TR/WCAG22/