Å signere en kontrakt for et AI-verktøy kan føles som målstreken i en anskaffelsesprosess, men for fastlegepraksiser er det nærmere startskuddet. Når en kontrakt er signert og et verktøy tas i bruk, hviler de kliniske, juridiske og regulatoriske forpliktelsene som følger med denne implementeringen på praksisen, ikke leverandøren. AI-implementering går raskere enn robust evaluering i den virkelige verden og regulering, noe som skaper reell risiko for praksiser som ikke har gjort grundig due diligence. Denne veiledningen presenterer de spesifikke spørsmålene praksisforvaltere bør stille, og dokumentene de bør gjennomgå, før noen kontrakt signeres.

Er verktøyet klassifisert som medisinsk utstyr, og hva betyr det for deg?

Ikke alle AI-verktøy som brukes i kliniske omgivelser er medisinsk utstyr, men mange er det, og skillet har betydelig regulatorisk betydning. I Storbritannia klassifiserer Medicines and Healthcare products Regulatory Agency (MHRA) programvare som medisinsk utstyr. Hvis et AI-verktøy støtter klinisk diagnostikk, triageringsbeslutninger eller behandlingsanbefalinger, vil det sannsynligvis falle innenfor definisjonen av Software as a Medical Device (SaMD) og kreve UKCA- eller CE-merking under Medical Device Regulation (MDR).

Før signering bør praksisforvaltere:

• Søke i MHRA Product and Registration Database (PARD) for å bekrefte om verktøyet er registrert som medisinsk utstyr

• Spørre leverandøren direkte om deres MHRA-registreringsstatus og utstyrsklasse

• Sjekke om verktøyet har en NICE-evaluering, en Medtech Innovation Briefing (MIB), Diagnostics Guidance (DG) eller Early Value Assessment (EVA)

• Bekrefte om verktøyet har gyldig UKCA- eller CE-merking hvis det er klassifisert som medisinsk utstyr

CQCs GP Mythbuster 109 om AI, publisert i juli 2025, gjør det klart at inspektører vil sjekke om praksiser har verifisert MHRA-registrering der det er aktuelt, og om anskaffelsen ble gjennomført i henhold til DCB0160- og Digital Technology Assessment Criteria (DTAC)-standarder. Verktøy som ikke er klassifisert som medisinsk utstyr er ikke fritatt fra gransking. De har fortsatt forpliktelser knyttet til databeskyttelse, klinisk sikkerhet og styring.

Hvem har klinisk og juridisk ansvar hvis noe går galt?

Dette er et av de mest avgjørende spørsmålene i enhver AI-verktøykontrakt, og leverandøravtaler tilslører det ofte. Den generelle posisjonen i NHS primærhelsetjeneste er at NHS-organisasjoner fortsatt kan være ansvarlige for AI-relaterte krav selv når de bruker tredjepartsverktøy, og at ansvaret for å bruke en ikke-kompatibel AI-løsning ligger hos den implementerende organisasjonen eller den enkelte kliniker.

Leverandører begrenser vanligvis sitt ansvar til at programvaren fungerer som beskrevet i kontrakten. De aksepterer ikke ansvar for kliniske beslutninger tatt på grunnlag av AI-utdata. Dette betyr at hvis et AI-generert klinisk notat inneholder en feil som påvirker pasientbehandlingen, vil praksisen, ikke leverandøren, sannsynligvis bære de kliniske og juridiske konsekvensene.

Ved gjennomgang av kontraktsvilkår bør praksisforvaltere se etter:

• Klare uttalelser om hvor det kliniske ansvaret ligger, og om leverandøren aksepterer noe ansvar for AI-genererte utdata som føres inn i pasientjournalen

• Erstatningsklausuler, og om leverandørens erstatning dekker kliniske hendelser eller kun programvarefeil

• Om leverandørens vilkår krever at praksisen opprettholder menneskelig tilsyn med alle AI-utdata, og hvilken dokumentasjon av dette tilsynet som forventes

• Om praksisens medisinske forsvarsorganisasjon eller erstatningsleverandør har blitt konsultert om verktøyets bruk

Surrey & Sussex LMCs råder praksiser til å involvere sitt Integrated Care Board (ICB) for sikkerhet og til å sikre at alle AI-genererte utdata sjekkes av en kliniker før de føres inn i pasientjournalen. Dette kravet om menneske-i-løkken er ikke bare god praksis, men også en forutsetning for sikker implementering under gjeldende NHS-retningslinjer.

Hvor blir pasientdata behandlet og lagret?

Datalokalisering er et grunnleggende spørsmål i enhver klinisk AI-anskaffelse, og leverandørsvar er ikke alltid entydige. Under UK General Data Protection Regulation (GDPR) og den sedvanerettslige taushetsplikten er pasientdata en spesiell kategori data, og behandlingen må være lovlig, transparent og proporsjonal. Hvis pasientdata, inkludert lydopptak av konsultasjoner, overføres utenfor Storbritannia eller EU for behandling eller lagring, kreves det ytterligere sikkerhetstiltak.

NHS Englands veiledning om ambient scribing-produkter bekrefter at en Data Protection Impact Assessment (DPIA) med stor sannsynlighet er et lovkrav før implementering, gitt den omfattende behandlingen av spesielle kategorier helsedata som er involvert. NHS Transformation Directorates veiledning om informasjonsstyring understreker dette, og bemerker at DPIAer må adressere hvilke typer data som behandles (inkludert lyd og transkripsjoner), leverandørens gjenbruk av data til AI-modelltrening, og forpliktelser knyttet til pasienttransparens.

Nøkkelspørsmål å stille leverandører før signering:

• Hvor behandles pasientdata? Er det i Storbritannia, EU eller et tredjeland?

• Hvem er leverandørens underprosessorer, og hvor er de lokalisert?

• Bruker leverandøren pasientkonsultasjonsdata til å trene eller forbedre sine AI-modeller, og i så fall på hvilket rettslig grunnlag?

• Er en Data Processing Agreement (DPA) inkludert i kontrakten, og er den i samsvar med UK GDPR artikkel 28?

• Hva er forskjellen mellom anonymiserte og pseudonymiserte data i leverandørens behandling, og hva er den gjenværende re-identifikasjonsrisikoen?

Juridisk kommentar fra Spencer West LLP påpeker at skillet mellom anonymiserte og pseudonymiserte data er spesielt viktig her, ettersom pseudonymiserte data beholder en gjenværende re-identifikasjonsrisiko og ikke kan behandles som utenfor databeskyttelseslovens virkeområde.

Hvilke sikkerhetssertifiseringer bør leverandøren ha?

Sikkerhetssertifiseringer er ingen garanti for sikkerhet, men deres fravær er et tydelig signal om en leverandørs modenhet og investering i databeskyttelse. For kliniske AI-verktøy som brukes i NHS primærhelsetjeneste, finnes det en grunnlinje av sertifiseringer og vurderinger som en troverdig leverandør bør kunne dokumentere.

Praksiser bør forvente at leverandører har eller aktivt arbeider mot:

• ISO 27001 (den internasjonale standarden for informasjonssikkerhetsstyringssystemer)

• NHS Data Security and Protection (DSP) Toolkit-samsvar (NHS sitt eget rammeverk for vurdering av datasikkerhet, som er et kontraktskrav for organisasjoner som får tilgang til NHS-pasientdata)

• Cyber Essentials eller Cyber Essentials Plus (den britiske regjeringens grunnleggende cybersikkerhetssertifisering)

• DTAC-samsvar (NHS Englands rammeverk som dekker databeskyttelse, teknisk sikkerhet, interoperabilitet og klinisk sikkerhet)

iatroX anskaffelsesveiledning for NHS-kjøpere anbefaler at praksiser sikrer at en leverandør har en bestått DTAC-pakke før implementering. NHS Englands ambient scribing-veiledning fremhever også cybersikkerhetsrisikoer spesifikke for store språkmodeller (LLMer), inkludert potensialet for prompt injection-angrep og datalekkasje gjennom modellutdata.

En leverandør som ikke kan fremlegge bevis for disse sertifiseringene, eller som ikke kan gi en gyldig DSP Toolkit-innsending, bør behandles med forsiktighet uavhengig av hvor overbevisende produktdemonstrasjonene deres måtte være.

Hvordan integreres verktøyet med ditt eksisterende journalsystem?

De fleste fastlegepraksiser i England bruker enten EMIS Web eller SystmOne som sitt primære journalsystem. Den praktiske verdien av et AI-verktøy, spesielt en ambient scribe eller dokumentasjonsassistent, avhenger sterkt av hvor godt det integreres med praksisens eksisterende system. Integrasjon som krever manuell kopiering og innliming av AI-generert innhold i journalen øker risikoen for transkriberingsfeil betydelig og fjerner mye av effektivitetsgevinsten.

Før signering bør praksisforvaltere fastslå:

• Om verktøyet har en innfødt, sertifisert integrasjon med EMIS Web eller SystmOne, eller om det er avhengig av en midlertidig løsning

• Hvem som er ansvarlig for å vedlikeholde integrasjonen når journalsystemleverandøren utgir oppdateringer: AI-leverandøren, journalsystemleverandøren eller praksisen

• Om integrasjonen er testet i et live GP-miljø, ikke bare i et utviklings- eller spesialisthelsetjenestemiljø

• Hva reserveprosessen er hvis integrasjonen svikter under en klinisk økt

iatroX-veiledningen til AI-verktøy for britiske fastlegepraksiser fremhever journalsystemintegrasjon som et av de primære evalueringskriteriene for ambient scribes, og bemerker at anskaffelsesbeslutninger bør ta hensyn til total eierkostnad, inkludert arbeidsflytstilpasningen som kreves når integrasjonen er ufullkommen. Integrasjonsfeil er ikke bare en teknisk ulempe. I en klinisk setting kan de skape hull i pasientjournalen eller introdusere feil som har konsekvenser for pasientsikkerheten.

Hva skjer med dataene dine hvis du avslutter kontrakten?

Dataportabilitet og sletting ved kontraktsoppsigelse er områder hvor leverandørkontrakter ofte er vage, og praksiser kan havne i en vanskelig posisjon hvis de ikke har forhandlet klare vilkår på forhånd. Spørsmålene som må avklares før signering er:

• Hvor lenge beholder leverandøren pasientdata etter kontraktsoppsigelse, og på hvilket rettslig grunnlag?

• Kan praksisen eksportere en fullstendig kopi av alle pasientdata som leverandøren har før oppsigelse?

• Hva betyr egentlig "sletting på forespørsel"? Dekker det alle kopier, inkludert sikkerhetskopier og underprosessordata?

• Hva er tidslinjen for bekreftet sletting, og vil leverandøren gi skriftlig bekreftelse?

Under UK GDPR har registrerte rettigheter inkludert retten til sletting, og praksisen, som databehandlingsansvarlig, er ansvarlig for å sikre at disse rettighetene kan utøves selv etter at et leverandørforhold er avsluttet. Personvern og sikkerhet gjennom hele helsedatalivssyklusen er et voksende område for regulatorisk gransking, og praksiser som ikke kan redegjøre for hvor pasientdata ble av etter at en leverandørkontrakt ble avsluttet, kan møte compliance-eksponering.

Kontraktsvilkår som tillater leverandører å beholde data i lengre perioder etter oppsigelse for "produktforbedring" eller "modelltrening" bør flagges for juridisk gjennomgang før signering.

Er AI-verktøyet trent på NHS- eller tilsvarende kliniske data?

Treningsdataene som brukes til å utvikle et AI-verktøy har direkte betydning for dets kliniske nøyaktighet i en britisk primærhelsetjenestekontekst. Et verktøy trent hovedsakelig på amerikanske kliniske data kan for eksempel prestere dårlig på britisk-spesifikk klinisk koding (SNOMED CT som brukes i NHS), legemiddelnavn og doseringskonvensjoner, henvisningsveier eller den særegne dokumentasjonsstilen i fastlegekonsultasjoner.

Klinikerperspektiver på AI i primærhelsetjenesten reiser konsekvent bekymringer om skjevheter introdusert gjennom treningsdata, og Laranjo et al. i Lancet Primary Care har bemerket at rask implementering foran robust evaluering gir grunn til bekymring for utilsiktede konsekvenser for omsorgskvalitet. Dette er ikke abstrakte risikoer. De påvirker direkte nøyaktigheten av kliniske notater, hensiktsmessigheten av foreslåtte kliniske koder og påliteligheten av eventuelle beslutningsstøtteutdata.

Ved evaluering av en leverandørs påstander om treningsdata bør praksisforvaltere spørre:

• Ble modellen trent på NHS- eller britiske primærhelsetjenestedata, og kan leverandøren gi dokumentasjon på dette?

• Har modellen blitt validert på britiske fastlegekonsultasjonsdata spesifikt?

• Publiserer leverandøren et modellkort eller tilsvarende teknisk dokumentasjon som beskriver treningsdatakilder, kjente begrensninger og ytelsesmål?

• Hvordan håndterer modellen britisk-spesifikk klinisk terminologi, legemiddelnavn og henvisningskonvensjoner?

Leverandører bør kunne svare på disse spørsmålene med dokumentert bevis, ikke bare markedsføringspåstander. Når en leverandør ikke kan gi denne informasjonen, er det et betydelig hull i deres kliniske evidensgrunnlag.

Hvem i praksisen er ansvarlig for å overvåke verktøyet?

AI-verktøystyring er ikke en engangs anskaffelsesbeslutning. Det er et løpende operasjonelt ansvar. CQCs GP Mythbuster 109 beskriver hva inspektører vil se etter, inkludert utnevnelse av en Clinical Safety Officer (CSO), vedlikehold av en risikovurdering og farelogg, og bevis på at menneskelig tilsyn med AI-utdata er innebygd i praksisens arbeidsflyter.

Kravet om å utnevne en CSO på praksisnivå er et som Surrey & Sussex LMCs anerkjenner som en praktisk utfordring for mindre praksiser. Det er en regulatorisk forventning, ikke en valgfri forbedring. CSO trenger ikke å være en heltidsrolle, men praksisen må kunne identifisere en navngitt person som har dette ansvaret og kan vise at de oppfyller det.

Styringsdokumentasjon som praksisen bør opprettholde inkluderer:

• En fullført DCB0160 klinisk sikkerhetscase for implementeringen av verktøyet

• En risikovurdering og farelogg, gjennomgått regelmessig og oppdatert når verktøyet endres

• Registreringer av klinikeropplæring på verktøyet, inkludert bevissthet om dets begrensninger

• En logg over eventuelle hendelser eller nesten-hendelser som involverer AI-genererte utdata

• Bevis på at alt AI-generert innhold som føres inn i pasientjournalen har blitt gjennomgått av en kliniker

Denne dokumentasjonen er ikke bare relevant for CQC-inspeksjon. Det er evidensgrunnlaget som beskytter praksisen hvis en klinisk hendelse inntreffer og spørsmål reises om hvordan verktøyet ble implementert og overvåket.

Hvordan ser leverandørens støtte og hendelsesrespons ut?

En Service Level Agreement (SLA) er en standardkomponent i enhver programvarekontrakt, men for kliniske AI-verktøy er konsekvensene ved en støttefeil større enn for de fleste programvarer. Hvis en ambient scribe svikter midt i en konsultasjon, eller hvis et AI-generert notat inneholder en systematisk feil som ikke blir fanget opp umiddelbart, må praksisen vite at leverandøren vil respondere raskt og med klinisk forståelse.

Før signering bør praksisforvaltere gjennomgå:

• Respons- og løsningstider i SLA, og om disse skiller mellom kliniske sikkerhetshendelser og generelle tekniske problemer

• Om leverandøren har en navngitt kontakt for fastlegepraksis, eller om støtte rutes gjennom en generell helpdesk

• Hva leverandørens prosess er for å varsle praksiser om en klinisk sikkerhetshendelse, inkludert hvor raskt de vil kommunisere og hvilken informasjon de vil gi

• Om leverandøren har en dokumentert klinisk sikkerhetshendelsesrapporteringsprosess som oppfyller NHS-standarder

NHS Englands ambient scribing-veiledning krever at kontraktsordninger tydelig definerer roller, ansvar og ansvarsforhold, inkludert hendelsesrespons. En leverandør som ikke kan beskrive en klar klinisk sikkerhetshendelsesprosess er ikke klar for implementering i en primærhelsetjenestesetting.

Har verktøyet blitt evaluert i en reell primærhelsetjenestesetting?

Dette er et spørsmål mange leverandører sliter med å besvare med solid dokumentasjon, og gapet mellom en overbevisende demonstrasjon og en fagfellevurdert evaluering i et faktisk GP-miljø er betydelig. Forskning på AI-skribenter i primærhelsetjenesten har begynt å dokumentere leverandørerfaringer og etiske bekymringer i virkelige settinger, men evidensgrunnlaget er fortsatt begrenset og i stor grad utforskende.

Frontiers in Health Services-gjennomgangen av NHS AI-anskaffelsesrammeverk anbefaler at leverandørens compliance-dokumentasjon bør inkludere klinisk evidens, ikke bare tekniske sertifiseringer. Praksisforvaltere bør be leverandører om å gi:

• Publiserte fagfellevurderte studier eller dokumenterte pilotresultater fra GP- eller primærhelsetjenestemiljøer

• Casestudier fra britiske primærhelsetjenestesettinger med målbare resultater (dokumentasjonstid, klinisk nøyaktighet, klinikertilfredshet)

• Bevis på evaluering mot NHS-spesifikke arbeidsflyter og journalsystemer

• Eventuelle kjente begrensninger eller feilmodi identifisert under reell testing

Bevis fra spesialisthelsetjenesten eller internasjonal primærhelsetjeneste overføres ikke direkte til britisk allmennpraksis. Konsultasjonsstrukturer, dokumentasjonskonvensjoner og regulatoriske krav er vesentlig forskjellige. Et verktøy som presterer godt i en sykehuspoliklinisk setting eller en amerikansk primærhelsetjenestekontekst presterer kanskje ikke tilsvarende i en britisk fastlegepraksis.

Det er også et bredere evidensgap å erkjenne. Som Laranjo et al. i Lancet bemerker, går AI-implementering i primærhelsetjenesten for tiden raskere enn den robuste evalueringen som trengs for å forstå dens virkelige innvirkning. Dette betyr ikke at praksiser bør unngå AI-verktøy, men leverandørpåstander bør granskes nøye og overvåking etter implementering er avgjørende.

En sjekkliste før signering for fastlegepraksiser

Følgende sjekkliste oppsummerer de viktigste verifiseringspunktene som er dekket i denne artikkelen. Bruk den som en praktisk referanse før noen AI-verktøykontrakt signeres.

Regulatorisk og klinisk sikkerhet

• [ ] Bekreftet MHRA-registreringsstatus og utstyrsklasse (søk PARD hvis aktuelt)

• [ ] Leverandøren har DCB0129 klinisk sikkerhetscase-dokumentasjon

• [ ] Praksisen har fullført eller påbegynt DCB0160 klinisk sikkerhetscase for implementering

• [ ] DTAC-vurdering fullført og bestått av leverandør

• [ ] NICE-evaluering sjekket (MIB, DG eller EVA) hvis aktuelt

Databeskyttelse og informasjonsstyring

• [ ] DPIA fullført før implementering

• [ ] Data Processing Agreement inkludert i kontrakt, UK GDPR artikkel 28-kompatibel

• [ ] Datalokalisering bekreftet (britisk eller EU-behandling og lagring)

• [ ] Underprosessorer identifisert og vurdert

• [ ] Leverandørens policy om bruk av pasientdata til modelltrening gjennomgått og avtalt

• [ ] Datasletting og portabilitetsvilkår bekreftet ved kontraktsoppsigelse

Sikkerhet

• [ ] ISO 27001-sertifisering bekreftet

• [ ] NHS DSP Toolkit-samsvar bekreftet

• [ ] Cyber Essentials eller Cyber Essentials Plus bekreftet

• [ ] DTAC cybersikkerhetsseksjon bestått

Ansvar og kontrakt

• [ ] Ansvarsfordeling tydelig definert i kontrakt

• [ ] Erstatningsklausuler gjennomgått (omfang bekreftet)

• [ ] Medisinsk forsvarsorganisasjon eller erstatningsleverandør konsultert

• [ ] Roller, ansvar og hendelsesrespons definert i kontrakt

Journalsystemintegrasjon

• [ ] Innfødt integrasjon med EMIS Web eller SystmOne bekreftet

• [ ] Integrasjonsvedlikeholdsansvar definert

• [ ] Testet i live britisk GP-miljø

Styring

• [ ] Clinical Safety Officer utnevnt på praksisnivå

• [ ] Risikovurdering og farelogg initiert

• [ ] Klinikeropplæringsplan på plass

• [ ] Menneskelig gjennomgang av alle AI-utdata bekreftet som arbeidsflytkrav

Evidens og støtte

• [ ] Klinisk evidens fra britiske primærhelsetjenestesettinger gjennomgått

• [ ] SLA gjennomgått (klinisk sikkerhetshendelsesrespons bekreftet)

• [ ] Navngitt leverandørkontakt for fastlegepraksis bekreftet

• [ ] Treningsdataopprinnelse dokumentert av leverandør

Signere med tillit, ikke bare hastverk

AI-anskaffelse i allmennpraksis er en klinisk styringsbeslutning like mye som en operasjonell. Verktøyene som er tilgjengelige i 2025 og 2026 tilbyr genuint potensial til å redusere dokumentasjonsbyrden og støtte klinikere, men dette potensialet realiseres bare trygt når praksisen har verifisert regulatorisk samsvar, databeskyttelsesforpliktelser, ansvarsfordeling og klinisk evidens før implementering starter.

Digital Health-rapportering om NHS AI-anskaffelse fanger den nåværende regulatoriske virkeligheten tydelig: eksisterende standarder ble ikke designet for lærende AI-systemer, og tempoet i leverandøraktivitet i primærhelsetjenesten betyr at praksiser må være, i ordene til NHS Englands nasjonale Chief Clinical Information Officer, «robuste i å sikre at det vi gjør er trygt, sikret og kommer til å levere fordeler.»

Spørsmålene og kontrollene i denne artikkelen er ikke hindringer for adopsjon. De er grunnlaget som trygg, effektiv og forsvarlig adopsjon bygges på. En leverandør som ikke kan svare på dem tydelig og med dokumentert bevis, er ikke klar til å bli implementert i en klinisk setting. En praksis som ikke har stilt dem, bærer en risiko den kanskje ikke er klar over ennå.

Ofte stilte spørsmål

▶ Må et AI-verktøy som brukes i en fastlegepraksis være registrert som medisinsk utstyr?

Det avhenger av hva verktøyet gjør. Hvis det støtter klinisk diagnostikk, triageringsbeslutninger eller behandlingsanbefalinger, vil det sannsynligvis bli klassifisert som Software as a Medical Device av Medicines and Healthcare products Regulatory Agency og kreve UKCA- eller CE-merking under Medical Device Regulation. Praksisforvaltere bør søke i MHRA Product and Registration Database for å bekrefte et verktøys registreringsstatus før de signerer noen kontrakt. Verktøy som ikke er klassifisert som medisinsk utstyr har fortsatt forpliktelser knyttet til databeskyttelse, klinisk sikkerhet og styring.

▶ Hvem er ansvarlig hvis et AI-generert klinisk notat inneholder en feil som påvirker pasientbehandlingen?

I NHS primærhelsetjeneste ligger ansvaret for AI-relaterte kliniske hendelser vanligvis hos den implementerende organisasjonen eller den enkelte kliniker, ikke leverandøren. Leverandører begrenser generelt sitt ansvar til at programvaren fungerer som beskrevet i kontrakten og aksepterer ikke ansvar for kliniske beslutninger tatt på grunnlag av AI-utdata. Praksisforvaltere bør gjennomgå erstatningsklausuler nøye, bekrefte om deres medisinske forsvarsorganisasjon har blitt konsultert, og sikre at alt AI-generert innhold gjennomgås av en kliniker før det føres inn i pasientjournalen.

▶ Hvor bør pasientdata behandles og lagres når man bruker et klinisk AI-verktøy?

Pasientdata er en spesiell kategori data under UK General Data Protection Regulation og må behandles lovlig, transparent og proporsjonalt. Hvis data overføres utenfor Storbritannia eller EU, kreves det ytterligere sikkerhetstiltak. Før signering bør praksiser bekrefte hvor leverandøren behandler og lagrer data, hvem deres underprosessorer er, og om en Data Processing Agreement i samsvar med UK GDPR artikkel 28 er inkludert i kontrakten. NHS England bekrefter at en Data Protection Impact Assessment med stor sannsynlighet er et lovkrav før implementering.

▶ Hvilke sikkerhetssertifiseringer bør en klinisk AI-leverandør ha?

Troverdige leverandører bør ha eller aktivt arbeide mot ISO 27001 (den internasjonale standarden for informasjonssikkerhetsstyring), NHS Data Security and Protection Toolkit-samsvar, Cyber Essentials eller Cyber Essentials Plus, og Digital Technology Assessment Criteria-samsvar. NHS DSP Toolkit er et kontraktskrav for organisasjoner som får tilgang til NHS-pasientdata. En leverandør som ikke kan fremlegge bevis for disse sertifiseringene, eller som ikke kan gi en gyldig DSP Toolkit-innsending, bør behandles med forsiktighet.

▶ Hva skjer med pasientdata hvis en praksis avslutter sin kontrakt med en AI-leverandør?

Dette er et område hvor leverandørkontrakter ofte er vage. Praksiser bør bekrefte før signering hvor lenge leverandøren beholder pasientdata etter oppsigelse, om en fullstendig eksport av alle pasientdata er mulig, og hva "sletting på forespørsel" faktisk innebærer, inkludert sikkerhetskopier og underprosessordata. Under UK GDPR er praksisen som databehandlingsansvarlig ansvarlig for å sikre at pasienters rettigheter, inkludert retten til sletting, kan utøves selv etter at et leverandørforhold er avsluttet. Kontraktsvilkår som tillater leverandører å beholde data for modelltrening etter oppsigelse bør flagges for juridisk gjennomgang.

▶ Spiller det noen rolle om et AI-verktøy ble trent på NHS- eller britiske primærhelsetjenestedata?

Ja. Treningsdata har direkte betydning for klinisk nøyaktighet i en britisk primærhelsetjenestekontekst. Et verktøy trent hovedsakelig på amerikanske kliniske data kan prestere dårlig på NHS-spesifikk klinisk koding ved bruk av SNOMED CT, britiske legemiddelnavn og doseringskonvensjoner, henvisningsveier og fastlegekonsultasjonsdokumentasjonsstiler. Praksiser bør spørre leverandører om modellen ble trent og validert på britiske fastlegekonsultasjonsdata, og om leverandøren publiserer et modellkort som beskriver treningsdatakilder, kjente begrensninger og ytelsesmål. Markedsføringspåstander er ikke en erstatning for dokumentert bevis.

▶ Hvem i praksisen er ansvarlig for å overvåke et AI-verktøy når det er implementert?

Care Quality Commissions GP Mythbuster 109 om kunstig intelligens fastslår at praksiser må utnevne en navngitt Clinical Safety Officer, opprettholde en risikovurdering og farelogg, og innlemme menneskelig tilsyn med AI-utdata i kliniske arbeidsflyter. Dette er en regulatorisk forventning, ikke et valgfritt trinn. Praksiser bør også opprettholde en fullført DCB0160 klinisk sikkerhetscase, registreringer av klinikeropplæring og en logg over eventuelle hendelser som involverer AI-genererte utdata. Denne dokumentasjonen beskytter praksisen hvis en klinisk hendelse inntreffer og spørsmål reises om hvordan verktøyet ble implementert.

▶ Hvordan bør en praksis evaluere om et AI-verktøy integreres riktig med sitt journalsystem?

De fleste fastlegepraksiser i England bruker enten EMIS Web eller SystmOne. Praksiser bør bekrefte om verktøyet har en innfødt, sertifisert integrasjon med deres system i stedet for en midlertidig løsning, hvem som er ansvarlig for å vedlikeholde integrasjonen når journalsystemleverandøren utgir oppdateringer, og om integrasjonen er testet i et live GP-miljø. Integrasjon som krever manuell kopiering og innliming av AI-generert innhold i journalen øker risikoen for transkriberingsfeil og fjerner mye av effektivitetsgevinsten. Integrasjonsfeil kan skape hull i pasientjournalen med direkte konsekvenser for pasientsikkerheten.

▶ Hvilken klinisk evidens bør en leverandør kunne gi før en praksis signerer en kontrakt?

Leverandører bør gi publiserte fagfellevurderte studier eller dokumenterte pilotresultater fra GP- eller primærhelsetjenestemiljøer, casestudier fra britiske primærhelsetjenestesettinger med målbare resultater, og bevis på evaluering mot NHS-spesifikke arbeidsflyter og journalsystemer. Bevis fra spesialisthelsetjenesten eller internasjonal primærhelsetjeneste overføres ikke direkte til britisk allmennpraksis. Som forskere som skriver i Lancet har bemerket, går AI-implementering i primærhelsetjenesten for tiden raskere enn robust evaluering, noe som betyr at leverandørpåstander bør granskes nøye og overvåking etter implementering er avgjørende.

▶ Hva bør en praksis se etter i en leverandørs støtte- og hendelsesresponsordninger?

Service Level Agreement bør skille respons- og løsningstider mellom kliniske sikkerhetshendelser og generelle tekniske problemer. Praksiser bør bekrefte om leverandøren har en navngitt kontakt for fastlegepraksis eller ruter støtte gjennom en generell helpdesk, og om leverandøren har en dokumentert klinisk sikkerhetshendelsesrapporteringsprosess som oppfyller NHS-standarder. NHS Englands ambient scribing-veiledning krever at kontraktsordninger tydelig definerer roller, ansvar og ansvarsforhold, inkludert hendelsesrespons. En leverandør som ikke kan beskrive en klar klinisk sikkerhetshendelsesprosess er ikke klar for implementering i en primærhelsetjenestesetting.