Emne 1.0 — Arbejdsmåder i digital sundhed og pleje

I én sætning: Arbejdsmåder er de bevidste, fælles vaner – hvordan man organiserer teams, træffer beslutninger, håndterer risiko og leverer værdi – der gør det muligt for en sundheds- og plejeorganisation at omsætte hensigt til sikre, lige og evidensbaserede resultater for patienter og borgere.

Hvorfor det er vigtigt i sundhed og pleje#

Enhver organisation har arbejdsmåder, uanset om de er valgt eller arvet. I digital sundhed og pleje er de arvede som regel forkerte til opgaven: de blev bygget til byggeprojekter med fast omfang, ikke til adaptive tjenester, der berører klinisk sikkerhed, lovbestemte pligter og offentlige midler. At få dem rigtige er ikke en bagkontor-finesse; det er forskellen på en fælles omsorgsjournal, som klinikere har tillid til, og en, der står ubrugt hen.

Sundhed og pleje er særegne på måder, der præger enhver praksis i denne bog. Sikkerhed er ikke til forhandling – en fejl i en digital tjeneste kan skade en patient, så klinisk risikostyring (se emne 1.6 — Klinisk sikkerhed og risikostyring) er vævet ind i leverancen og ikke boltet på bagefter. Lighed er vigtig, fordi en tjeneste, der kun virker for de digitalt selvsikre, øger uligheden i sundhed; Core20PLUS5-befolkningsgrupperne og mennesker med begrænset digital adgang skal designes ind, ikke designes ud. Lovbestemte pligter – NHS’ tilsagn om omfattende behandling, databeskyttelseslovgivningen, tavshedspligten – sætter grænser for, hvad du må gøre med data, og hvordan du skal høre berørte parter. Offentlige midler kræver forholdsmæssig udgiftskontrol og påviselig værdi. Og næsten intet leveres af én aktør alene: partnerskab på tværs af integrerede plejesystemer (ICS), kommuner, socialsektorens udbydere og leverandører er standardvilkåret.

Disse fire pres – sikkerhed, lighed, pligt og penge – er grunden til, at du ikke bare kan kopiere en spillebog fra forbrugerteknologi. Du har brug for arbejdsmåder, der er agile og ansvarlige, hurtige og sikre, brugerorienterede og retfærdige over for befolkningen.

Kernebegreber#

Arbejdsmåder virker på tre niveauer. På team-niveau er de de daglige praksisser: stand-ups, brugerforskning, iterativ leverance, parprogrammering. På organisations-niveau er de driftsmodellen – hvordan strategi bliver til værdistrømme, kapabiliteter, finansiering og beslutningsrettigheder (se emne 1.1 — Driftsmodellen). På system-niveau er de den måde, uafhængige organisationer bringer sig på linje: fælles standarder, interoperabilitet og fælles styring på tværs af et ICS. Denne bog bevæger sig bevidst på tværs af alle tre.

Brugercentreret design betyder at tage udgangspunkt i behovene hos de mennesker, der bruger en tjeneste – patienter, pårørende, klinikere, administratorer – frem for i en forudantaget løsning. Det britiske Government Digital Service (GDS) og NHS har kodificeret dette i servicestandarder: forstå brugerne og deres behov, før du bygger, og bliv ved med at teste med rigtige brugere hele vejen.

Agil, iterativ leverance betyder at få en fungerende tjeneste foran rigtige brugere tidligt, lære og tilpasse sig – frem for at specificere alt på forhånd. NHS’ digitale servicemanual er tydelig på, at agile, brugercentrerede arbejdsmåder mindsker risikoen for at bygge det forkerte. Agil udvikling er her lige så meget en risikostyringsstrategi som en leveringsmetode.

Tværfaglige teams (MDT’er) samler i ét bemyndiget team den blanding af kompetencer, en tjeneste har brug for: produkt- og leveranceledelse, brugerforskning og design, udvikling, klinisk og informationsstyringsmæssig ekspertise samt operationel viden. NHS’ servicestandard kræver teams, der rummer tværfaglige kompetencer og perspektiver – herunder adgang til specialiseret klinisk, juridisk eller politisk input. MDT’et er den digitale leverances atom; de fleste fiaskoer kan spores tilbage til en manglende disciplin ved bordet.

Produkt frem for projekt. Et projekt har en start, en afslutning og en overdragelse; et produkt finansieres og forvaltes i hele sin levetid. Skiftet fra projekt- til produkttænkning (se emne 1.1 og emne 5.0 — Produktledet arbejde) ændrer finansiering, teams og ansvar, og det passer langt bedre til sundhedstjenester – som er langlivede og i konstant udvikling – end engangsprojekter gør.

Bedste praksis#

1. Start med brugernes behov, dokumenteret gennem forskning. Før du forpligter dig til at bygge, skal du forstå, hvem brugerne er, hvad de forsøger at gøre, og hvor den nuværende tjeneste svigter dem. Finansiér en afdækning (se emne 3.4 — Afdækningsfaser) og behandl "vi antog" som et rødt flag. Brugernes behov, ikke interne præferencer, er forankringen for alle senere beslutninger.

2. Byg tværfaglige, bemyndigede og stabile teams. Sammensæt den fulde blanding af kompetencer – herunder klinisk sikkerhed og informationsstyring – og giv teamet beføjelse til at beslutte inden for klare rammer. Hold teams samlet om en tjeneste frem for at opløse dem ved hver projektgrænse; stabile teams opbygger den domæne- og sikkerhedsviden, som sundhedstjenester kræver.

3. Arbejd åbent og iterér i små skridt. Lever tynde udsnit, mål og juster. Små, hyppige udgivelser er sikrere end big bang-lanceringer, fordi problemer viser sig, mens de stadig er små, og fordi de lader den kliniske sikkerheds- og informationsstyringsgennemgang følge med forandringerne i stedet for at blive en port til sidst.

4. Gør sikkerhed og lighed til førsteklasses hensyn fra dag ét. Kør klinisk risikostyring (DCB0129/DCB0160) og analyse af lighed og uligheder i sundhed side om side med leverancen, ikke som godkendelser til sidst. Spørg tidligt, hvem der kan blive udelukket eller skadet, og design til de sværeste tilfælde – assisterede digitale veje, tilgængelighed (WCAG) og offline-reserveløsninger.

5. Beslut med evidens, og registrér beslutningen. Skel mellem klinisk evidens (virker det, og er det sikkert?) og leveranceevidens (bygger vi det godt, og bliver det brugt?), og før en let beslutningslog, så begrundelsen overlever personaleudskiftning (se emne 1.3 — Evidensbaserede beslutninger). Evidens slår den bedst betalte persons mening.

6. Design til interoperabilitet og genbrug. Sundheds- og plejedata skal kunne flyde sikkert mellem organisationer; byg efter åbne standarder (HL7 FHIR, SNOMED CT) og genbrug platforme frem for at genopfinde dem (se emne 1.1’s "tyndest mulige platform" og emne 4.3 — Interoperabilitet og datastandarder). En tjeneste, der ikke kan dele data, er en silo, der venter på at blive en risiko.

7. Styr forholdsmæssigt. Afstem tyngden af assurance efter risikoniveauet. Højrisiko-kliniske ændringer fortjener dyb granskning; lavrisiko-indholdsændringer bør ikke vente uger på et udvalg. Forholdsmæssig styring holder dig både sikker og hurtig.

8. Arbejd i åbenhed. Del planer, beslutninger, køreplaner og – hvor det er sikkert – kode, så partnere, klinikere og offentligheden kan se, hvordan og hvorfor valg træffes. Åbenhed skaber tillid, skærer ned på dobbeltarbejde i et fragmenteret system og inviterer til udfordring, før fejl hærder til tjenester i drift. I sundhed og pleje er det i sig selv en tillids- og sikkerhedspraksis at være gennemsigtig om, hvad en tjeneste gør med data, og hvorfor.

9. Design til den lange bane og til overdragelse. Digitale tjenester i sundhedsvæsenet overlever de teams og kontrakter, der bygger dem, så fasthold beslutninger, undgå udokumenteret "helteviden", og design til de mennesker, der skal drive og ændre tjenesten i årevis (se emne 10.3 — Vidensstyring og dokumentation). Behandl bæredygtighed – af teamet, teknologien og finansieringsmodellen – som en førsteklasses begrænsning, ikke en eftertanke.

Spørgsmål at drøfte med dit team#

1. Hvor er vores nuværende arbejdsmåder arvet frem for valgt, og hvilken arvet vane koster os mest i sikkerhed, lighed eller spildte udgifter? Dette spørgsmål tvinger til en ærlig gennemgang af de praksisser, ingen har besluttet, men alle følger – programfinansiering med fast omfang, projektteams der opløses og genopbygges, styring der først høres ved idriftsættelsen. Det er vigtigt, fordi arvede vaner som regel er usynlige, indtil de bliver navngivet, og i sundhed og pleje har de en reel pris: en fælles journal, klinikerne ikke har tillid til, en tjeneste der udelukker Core20PLUS5-grupper, eller en genopbygning af den samme login-infrastruktur for offentlige midler. Spændingen, der skal drøftes, er, at arvede måder ofte føles sikre netop fordi de er velkendte og kan revideres, så det ligner at påtage sig risiko, når man afvikler dem, frem for at fjerne den. Forankr drøftelsen i konkrete artefakter – se på dine tre seneste business cases, dit teamudskiftning mellem projekter, og hvornår klinisk sikkerhed først blev inddraget – frem for at udveksle meninger. Et godt svar nævner en eller to specifikke vaner med dokumentation for deres pris, skelner mellem dem, der er værd at beholde, og dem, der aktivt skader resultaterne, og forpligter sig til en ændring, som en seniorleder vil stå til ansvar for.

2. Har vores teams reelt den fulde tværfaglige kompetenceblanding – herunder klinisk sikkerhed og informationsstyring – siddende inde i teamet, eller er disse discipliner stadig boltet på som porte til sidst? Emnet argumenterer for, at MDT’et er den digitale leverances atom, og at de fleste fiaskoer kan spores til en manglende disciplin ved bordet, så spørgsmålet afprøver, om princippet er virkeligt i din organisation eller blot et ønske. Det er vigtigt, fordi en klinisk sikkerhedsansvarlig eller Caldicott Guardian, der først inddrages ved idriftsættelsen, tvinger til enten omarbejde eller usikre genveje, mens en, der er indlejret fra uge ét, fører en levende farelog, der sætter tempoet for leverancen. Den afvejning, der er værd at få frem, er pris og knaphed: specialiseret klinisk, juridisk og IG-tid er reelt begrænset, så "indlejr alle i alle teams" støder sammen med reelle ressourcebegrænsninger, og teamet må beslutte, hvor delvise eller delte roller er acceptable, og hvor de ikke er. Se på en nuværende tjeneste og kortlæg, hvem der faktisk er i det faste team, versus hvem der høres som ekstern godkender, og tjek, om teamet har beføjelse til at beslutte inden for rammerne eller konstant må eskalere. Et ærligt og godt svar er konkret om, hvilke discipliner der mangler eller er lånt, anerkender ressourcespændingen åbent og foreslår en konkret model – fuldtid, deltid eller på kald – til at lukke hullet uden at vifte knapheden væk.

3. Hvornår har vi behandlet en digital tjeneste som et projekt med en overdragelse frem for et produkt, der forvaltes i hele sin levetid, og hvad kostede det os i tabt domæne- og sikkerhedsviden? Produkt frem for projekt er et af emnets bærende skift, og dette spørgsmål får teamet til at se på, hvor de stadig finansierer og bemander med henblik på afslutning frem for kontinuitet. Det er vigtigt, fordi sundhedstjenester er langlivede og i konstant udvikling; et team, der opløses ved projektgrænsen, tager netop den akkumulerede kliniske og operationelle viden med sig, som holder en tjeneste sikker, og "pilotpurgatorium" er det tilbagevendende symptom. Den reelle spænding er økonomisk og strukturel: produktfinansiering kræver stående budgetter og udfordrer den model med årlige ansøgninger og tidsbegrænsning, som økonomi og styring er bygget op omkring, så det er lige så meget en samtale om penge og ansvar som om leverance. Overvej en specifik tjeneste, der gennemgik en overdragelse – følg, hvad der skete med dens farelog, dens brugerforskning og dens team – og afvej det mod den disciplin, produktfinansiering kræver. Et godt svar peger på et konkret tilfælde, kvantificerer eller i det mindste karakteriserer den tabte viden og er åben om, hvilke organisatoriske barrierer (finansieringscyklusser, ressourceregler, styringsstrukturer) der ville skulle rykkes, for at vedvarende produktteams kan blive normen.

4. Hvem er mest sandsynligt at blive udelukket eller skadet af de tjenester, vi bygger, og kan vi pege på, hvor vi har designet til dem først frem for sidst? Emnet insisterer på, at lighed ikke er til forhandling, og at en tjeneste, der kun virker for de digitalt selvsikre, øger uligheden i sundhed, så spørgsmålet afprøver, om "design til de sværeste tilfælde" er en levende praksis eller et slagord. Det er vigtigt, fordi udelukkelse i sundhed og pleje ikke er en ulejlighed, men en sikkerheds- og adgangsskade: Core20PLUS5-grupperne, mennesker med begrænset digital adgang, lav sundhedskompetence eller uden smartphone er netop dem, hvis behov er størst, og en tjeneste, der designer dem ud, koncentrerer skaden, hvor den er mindst til at bære. Spændingen, der er værd at få frem, er, at design til kanterne koster tid og penge på forhånd – assisterede digitale veje, tilgængelighed efter WCAG, offline- og ikke-digitale reserveløsninger, oversættelse – og de omkostninger er lette at udskyde, når en leveringsdato nærmer sig, og det selvsikre flertal allerede kan bruge løsningen. Se på en reel tjeneste og spørg, hvem der er i dens brugerforskningsstikprøve, om en lighedsanalyse og en analyse af uligheder i sundhed faktisk formede en designbeslutning, og hvad der sker med en, der ikke kan eller vil gå online. Et ærligt svar nævner de specifikke grupper i risiko for denne tjeneste, viser mindst ét konkret designvalg truffet for dem og er åbent om, hvor teamet under pres byttede inklusion væk, og hvordan det ville forsvare det valg næste gang.

5. Hvor genopfinder vi infrastruktur, der allerede findes, og hvor ville bygning efter åbne standarder og genbrug af fælles platforme faktisk ændre det, vi leverer? At designe til interoperabilitet og genbrug er en af emnets bedste praksisser, og dette spørgsmål får teamet til at se på trangen til at bygge skræddersyet frem for at genbruge – login, notifikationer, journalintegrationen, som et dusin andre teams også har bygget. Det er vigtigt, fordi enhver genopfundet komponent i et fragmenteret system er offentlige midler brugt to gange og en ny silo, der ikke sikkert kan udveksle data; omvendt er det at bygge efter HL7 FHIR og SNOMED CT og genbruge den tyndest mulige platform det, der overhovedet gør det muligt for en tjeneste at komme igennem indkøb og dele data på tværs af et ICS. Den reelle afvejning er, at genbrug betyder afhængighed: en fælles platform kan være langsommere, mindre tilpasset eller styret af en andens køreplan, så teamet må afveje den fælles komponents træghed mod de langsigtede omkostninger og risici ved en skræddersyet silo. Gennemgå en nuværende udvikling og opstil, hvad der er reelt nyt, versus hvad der duplikerer en eksisterende platform, standard eller åben komponent, og tjek, om "det kan vi ikke genbruge" er en dokumenteret begrænsning eller en uafprøvet antagelse. Et godt svar skelner mellem de dele, der er værd at bygge, og de dele, der er værd at genbruge, er ærligt om modenheden og styringen af de tilbudte platforme og forpligter sig til åbne standarder for alt, der skal udveksle data.

6. Hvordan afstemmer vi tyngden af vores styring efter risikoniveauet, og hvor er assurance i dag enten for tung til lavrisikoændringer eller for let til højrisikoændringer? Forholdsmæssig styring er en bærende idé i dette emne – højrisiko-kliniske ændringer fortjener dyb granskning, mens lavrisiko-indholdsændringer ikke bør vente uger på et udvalg – og dette spørgsmål afprøver, om organisationen kalibrerer assurance efter risiko eller anvender én sløv proces på alt. Det er vigtigt, fordi fejlindstillet styring skader begge veje: en tung port, der passer til alle, får teams til at samle ændringer i bunker og bremser netop den iteration, der holder tjenester sikre, mens en ensartet let berøring lader en reelt højrisiko-klinisk ændring slippe igennem uden den kliniske sikkerheds- og informationsstyringsgranskning, den har brug for. Spændingen er, at forholdsmæssighed kræver skøn, og skøn er ubehageligt for bestyrelser og revisorer, der finder en enkelt obligatorisk tjekliste lettere at forsvare end en risikodelt rute. Se på, hvordan dine seneste tolv ændringer blev kvalitetssikret, sortér dem efter faktisk klinisk og datamæssig risiko, og se, om indsatsen fulgte risikoen eller kalenderen. Et ærligt svar peger på konkrete eksempler på både over- og understyring, foreslår klare kriterier for at inddele ændringer efter risiko og nævner, hvem der har beføjelsen til at afgøre niveauet og står til ansvar for det.

I praksis: et eksempel fra sundhed og pleje#

Et integreret plejesystem vil give klinikere på tværs af tre akuthospitaler, kommunale sundhedstjenester og kommunal socialpleje en fælles omsorgsjournal. Den gamle måde ville bestille et program med fast omfang, specificere hver skærm på forhånd og integrere sent.

I stedet danner ICS’et et tværfagligt team: en produktchef, en leveranceleder, en brugerforsker, en interaktionsdesigner, to udviklere, en klinisk sikkerhedsansvarlig og en informationsstyringsansvarlig, med adgang til en Caldicott Guardian og en socialfaglig medarbejder. De gennemfører en otte ugers afdækning, hvor de observerer, hvordan en distriktssygeplejerske, en overlæge på skadestuen og en socialrådgiver i dag faktisk forsøger at finde oplysninger. De opdager, at den virkelige smerte ikke er "ingen data", men "data, de ikke kan stole på aktualiteten af".

Teamet lancerer en snæver alfa: skrivebeskyttet adgang til allergier, medicin og aktuel status for plejeplanen for ét klinisk forløb, med et synligt "senest opdateret"-stempel. Klinisk sikkerhed kører parallelt; en farelog føres fra uge ét. De måler, om klinikere holder op med at ringe til andre teams for at bekræfte oplysninger. Først når det tynde udsnit har vist sig værdifuldt og sikkert, udvider de journalen – finansieret som et løbende produkt, ikke et afsluttet projekt.

Sektorperspektiver#

De samme fire pres – sikkerhed, lighed, pligt og penge – påvirker enhver organisation, men de arbejdsmåder, der svarer på dem, skifter med størrelse, finansiering og ansvar.

Startup#

En lille digital sundhedsvirksomhed lever og dør af fokus, så dens arbejdsmåder er slanke af nødvendighed: ét tværfagligt team, flad beslutningstagning og daglig kontakt med brugerne. Begrænsningen er den resterende likviditet, ikke regler om bemanding, så afdækning måles i uger, og evidens indsamles billigt – en håndfuld kliniske interviews, en klikbar prototype, en ærlig farelog ført af en deltids klinisk sikkerhedsansvarlig. Faren er at springe sikkerheds- og informationsstyringsstringens over for at nå en investormilepæl; den disciplin, der overlever granskning, er at behandle DCB0129 og en konsekvensanalyse vedrørende databeskyttelse som adgangskriterier til en pilot, ikke som papirarbejde, der udskydes, til et hospital spørger. Interoperabilitet fra dag ét (FHIR, SNOMED CT) er også et kommercielt aktiv, for en startup, der ikke kan udveksle data, kommer aldrig igennem NHS’ indkøb.

Lille virksomhed#

En etableret lille udbyder – en lægepraksis, et lokalt apotek, et plejehjem eller et hjemmeplejefirma, en enkelt klinik eller en beskeden sundhedsteknologileverandør forbi fasen uden omsætning – bærer de samme pres fra sikkerhed, lighed, pligt og penge som et stort hospital, men med en brøkdel af evnen til at imødekomme dem. Arbejdsmåderne her må være radikalt forholdsmæssige: der er sjældent et dedikeret digitalt eller IG-team, så det "tværfaglige team" er ofte en håndfuld mennesker med flere hatte plus en delt eller udliciteret ressource til klinisk sikkerhed og databeskyttelse. Fælden er at antage, at de lovbestemte pligter skalerer ned med organisationen – det gør de ikke, så klinisk sikkerhed efter DCB0129/DCB0160, en konsekvensanalyse vedrørende databeskyttelse og tilgængelighed gælder stadig fuldt ud, selv når én praksisleder er ansvarlig for dem alle. Den praktiske disciplin er at læne sig kraftigt op ad genbrug frem for at bygge: tag akkrediterede standardsystemer i brug, kræv at leverandører opfylder DTAC og åbne standarder (FHIR, SNOMED CT), og brug nationale og ICS-leverede platforme, så sikkerhed, interoperabilitet og informationsstyring bliver nedarvet frem for genopfundet på et minimalt budget.

Stor virksomhed#

Et NHS-hospital eller et ICS har det modsatte problem: rigelige processer og fragmenteret ejerskab. Arbejdsmåder her handler lige så meget om at aflære – at afvikle programvaner med fast omfang og stoppe projektteams, der opløses og genopbygges – som om at tage nye praksisser i brug. Ansvaret er formelt og personligt (en senior ansvarlig ejer, en Caldicott Guardian, godkendelse af klinisk sikkerhed på bestyrelsesniveau), så gevinsten ligger i at indlejre disse roller i leveranceteamet frem for at bolte dem på som porte. En stor sundhedsteknologi- eller medicinalleverandør står over for det modsatte spejlbillede: stærk teknisk modenhed, men afstand til den kliniske virkelighed ved frontlinjen, som tværfaglige teams med reel tid fra klinikere er til for at lukke.

Myndighed#

Et nationalt eller lokalt offentligt organ – NHS England, DHSC, UKHSA, en kommune – fastsætter de standarder, alle andre arbejder efter, så dets arbejdsmåder breder sig udad som ringe i vandet. Dets ansvar er over for parlamentet og offentligheden, hvilket hæver barren for gennemsigtighed, udgiftskontrol og lighed: en servicestandard, en offentliggjort assurance-rute og Core20PLUS5-pligter er redskaber for dette ansvar, ikke valgfrie ekstraer. Risikoen på denne skala er at designe centralt til en gennemsnitsborger, der ikke findes, og at pålægge en løsning, før man forstår det lokale behov. Modgiften er den samme brugercentrerede, iterative disciplin som alle andre steder, anvendt med en tilbøjelighed til at fastsætte åbne standarder og genbrugelige platforme, som føderale organisationer kan bygge videre på – at styre systemet, ikke blot levere en tjeneste.

Typiske fejlmønstre#

• Løsning først-leverance. At forpligte sig til et navngivet produkt, før behovet er forstået. Modgift: finansiér afdækning og gør brugernes behov til adgangskriteriet for udvikling.
• Styring som sen port. Klinisk sikkerhed og informationsstyring høres først ved idriftsættelsen, hvilket tvinger til omarbejde eller usikre genveje. Modgift: indlejr begge i teamet fra dag ét.
• Projektomsætning. Teams oprettes og nedlægges, og hårdt tilkæmpet domæne- og sikkerhedsviden går tabt. Modgift: produktfinansiering og vedvarende teams.
• Pilotpurgatorium. Endeløse piloter, der aldrig skaleres, fordi adoption, oplæring og forretningsforandring aldrig blev ressourcesat (se emne 8.1 — Forandringsledelse). Modgift: planlæg vejen til skalering før piloten.
• Lighed som eftertanke. At designe til det selvsikre flertal og udelukke dem, der har mest brug for pleje. Modgift: design først til de sværeste tilfælde.

Modenhedsmodel#

Tjekliste#

• Hver tjeneste har et navngivet, stabilt tværfagligt team med kompetencer inden for klinisk sikkerhed og informationsstyring.
• Ingen udvikling starter uden dokumenterede brugerbehov fra afdækning.
• Klinisk risikostyring (DCB0129/DCB0160) kører fra dag ét med en levende farelog.
• En analyse af lighed og uligheder i sundhed er gennemført, og assisterede digitale veje findes.
• Leverancen forløber i små, hyppige, målbare udsnit.
• Beslutninger registreres, med skelnen mellem klinisk evidens og leveranceevidens.
• Tjenester bygges efter åbne interoperabilitetsstandarder og genbruger fælles platforme.
• Styringens tyngde er afstemt efter risiko og kendt af teamet.
• Der er en finansieret vej fra pilot til skalering, inklusive oplæring og forandring.

Centrale kilder#

• NHS digital servicemanual — NHS service standard og dens punkter, herunder "Use agile ways of working" og "Create a team that includes multidisciplinary skills and perspectives" (service-manual.nhs.uk).
• GOV.UK Service Manual og Government Service Standard — Government Digital Service (gov.uk/service-manual).
• NHS England / NHSX — Digital Technology Assessment Criteria (DTAC).
• Standarder for klinisk sikkerhed DCB0129 og DCB0160 (NHS England / tidligere NHS Digital).
• NICE — Evidence Standards Framework for digital health technologies (nice.org.uk).
• NHS England — Core20PLUS5-tilgangen til at reducere uligheder i sundhed.

Referencer#

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/