AI-verktøykontrakter: hva fastlegeledere må verifisere først

Å signere en kontrakt for et AI-verktøy er startskuddet i en anskaffelsesprosess, ikke målstreken. Når kontrakten er signert, hviler de kliniske, juridiske og regulatoriske forpliktelsene på praksisen, ikke leverandøren. Denne veiledningen presenterer de konkrete spørsmålene praksisforvaltere må stille, og dokumentene de må gå gjennom, før noen kontrakt signeres.

Er verktøyet klassifisert som medisinsk utstyr?

Ikke alle AI-verktøy som brukes i kliniske omgivelser er medisinsk utstyr, men mange er det. 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 inn under 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, spørre leverandøren direkte om utstyrsklasse, sjekke om det finnes en NICE-evaluering (MIB, DG eller EVA), og bekrefte gyldig UKCA- eller CE-merking der det er aktuelt.

Care Quality Commission (CQC) sin 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 har fortsatt forpliktelser knyttet til databeskyttelse, klinisk sikkerhet og styring.

Hvem bærer det kliniske og juridiske ansvaret?

Dette er det viktigste spørsmålet i enhver AI-verktøykontrakt, og leverandøravtaler tilslører det systematisk. Hovedregelen i NHS primærhelsetjeneste er at NHS-organisasjoner fortsatt kan holdes ansvarlige for AI-relaterte krav selv når de bruker tredjepartsverktøy. Ansvaret for å ta i bruk 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, ikke for kliniske beslutninger som tas på grunnlag av AI-utdata. Det 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.

Når praksisforvaltere går gjennom kontraktsvilkårene, bør de se etter klare uttalelser om hvor det kliniske ansvaret ligger, undersøke hva erstatningsklausulene faktisk dekker (om de gjelder programvarefeil eller kliniske hendelser), og kontrollere om leverandørens vilkår krever dokumentert menneskelig tilsyn med alle AI-utdata. Surrey & Sussex Local Medical Committees (LMCs) råder praksiser til å involvere sitt Integrated Care Board for sikkerhet, sikre at en kliniker sjekker alle AI-genererte utdata før de føres inn i pasientjournalen, og rådføre seg med praksisens medisinske forsvarsorganisasjon eller erstatningsleverandør før implementeringen starter.

Hvor behandles og lagres pasientdata?

Under UK General Data Protection Regulation (GDPR) og den sedvanerettslige taushetsplikten er pasientdata en særlig kategori data. Behandlingen må være lovlig, transparent og proporsjonal. Hvis data overføres utenfor Storbritannia eller EU, 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.

Praksisforvaltere bør stille leverandøren følgende spørsmål: Hvor behandles pasientdata, og hvem er underprosessorene? Bruker leverandøren konsultasjonsdata til å trene AI-modeller, og på hvilket rettslig grunnlag? Er en Data Processing Agreement i samsvar med UK GDPR artikkel 28 inkludert i kontrakten?

Skillet mellom anonymiserte og pseudonymiserte data er særlig viktig her. Ved pseudonymisering erstattes identifiserende opplysninger med en kode, men gjenidentifisering er fortsatt mulig. Slike data innebærer en gjenværende risiko og faller ikke utenfor databeskyttelseslovens virkeområde. Juridisk kommentar fra Spencer West LLP og NHS Transformation Directorates veiledning om informasjonsstyring understreker begge at DPIA-er må ta opp hvilke typer data som behandles, om leverandøren gjenbruker data til modelltrening, og hvilke forpliktelser praksisen har til å informere pasienter.

Hvilke sikkerhetssertifiseringer og integrasjonskrav gjelder?

Sikkerhetssertifiseringer er ingen garanti for sikkerhet, men mangelen på dem er et tydelig tegn på at en leverandør ikke er moden nok. For kliniske AI-verktøy i NHS primærhelsetjeneste bør en seriøs leverandør kunne dokumentere ISO 27001, samsvar med NHS Data Security and Protection (DSP) Toolkit, Cyber Essentials eller Cyber Essentials Plus, og samsvar med DTAC. NHS DSP Toolkit er et kontraktskrav for organisasjoner som får tilgang til NHS-pasientdata. En leverandør som ikke kan fremlegge bevis for dette bør behandles med forsiktighet, uavhengig av hvor imponerende produktdemonstrasjonene er.

De fleste fastlegepraksiser i England bruker enten EMIS Web eller SystmOne som pasientjournalsystem. Den praktiske verdien av et AI-verktøy, særlig en ambient scribe som automatisk dokumenterer konsultasjoner, avhenger i stor grad av hvor godt det integreres med praksisens eksisterende system. Integrasjon som krever manuell kopiering og innliming øker risikoen for transkriberingsfeil og fjerner mye av effektivitetsgevinsten. Praksisforvaltere bør bekrefte om verktøyet har en innebygd, sertifisert integrasjon med EMIS Web eller SystmOne, avklare hvem som er ansvarlig for å vedlikeholde integrasjonen når journalsystemleverandøren slipper oppdateringer, og spørre hva reserveprosessen er hvis integrasjonen svikter under en klinisk økt. Som iatroX sin veiledning til AI-verktøy for britiske fastlegepraksiser påpeker, kan integrasjonsfeil i en klinisk setting skape hull i pasientjournalen med direkte konsekvenser for pasientsikkerheten.

Hva skjer med dataene hvis kontrakten avsluttes?

Dataportabilitet og sletting ved kontraktsoppsigelse er områder der leverandørkontrakter ofte er vage. Praksiser bør avklare følgende før signering: Hvor lenge beholder leverandøren pasientdata etter oppsigelse, og på hvilket rettslig grunnlag? Er det mulig å eksportere alle pasientdata i sin helhet? Hva innebærer egentlig «sletting på forespørsel», inkludert sikkerhetskopier og data hos underprosessorer?

Under UK GDPR er praksisen som databehandlingsansvarlig forpliktet til å sikre at pasienters rettigheter, inkludert retten til sletting, kan utøves selv etter at et leverandørforhold er avsluttet. Kontraktsvilkår som gir leverandøren rett til å beholde data for «produktforbedring» eller «modelltrening» etter oppsigelse bør flagges for juridisk gjennomgang. Personvern og sikkerhet gjennom hele helsedatalivssyklusen er et område som får stadig mer regulatorisk oppmerksomhet, og det er nettopp i disse klausulene at fremtidig tilsynsrisiko ligger.

Er verktøyet trent og validert på NHS-data?

Treningsdataene som ligger til grunn for et AI-verktøy har direkte betydning for hvor nøyaktig det fungerer i en britisk primærhelsetjenestekontekst. Et verktøy som hovedsakelig er trent på amerikanske kliniske data kan prestere dårlig på NHS-spesifikk klinisk koding ved bruk av SNOMED CT, britiske legemiddelnavn og doseringskonvensjoner, henvisningsveier og den særegne dokumentasjonsstilen i fastlegekonsultasjoner. Bevis fra spesialisthelsetjenesten eller internasjonal primærhelsetjeneste er ikke direkte overførbart. Konsultasjonsstrukturer, dokumentasjonskonvensjoner og regulatoriske krav er vesentlig forskjellige.

Klinikerperspektiver på AI i primærhelsetjenesten reiser gjennomgående bekymringer om skjevheter fra treningsdata, og Laranjo et al. i Lancet Primary Care har påpekt at rask implementering foran grundig evaluering gir grunn til bekymring for utilsiktede konsekvenser for omsorgskvaliteten. Praksisforvaltere bør spørre om modellen er trent og validert på britiske fastlegekonsultasjonsdata, og om leverandøren publiserer et modellkort som beskriver treningsdatakilder, kjente begrensninger og ytelsesmål. Markedsføringspåstander erstatter ikke dokumentert bevis.

Hvem i praksisen er ansvarlig for løpende styring?

Styring av AI-verktøy er et løpende operasjonelt ansvar som begynner ved anskaffelse og fortsetter gjennom hele verktøyets levetid i praksisen. CQC sin GP Mythbuster 109 beskriver hva inspektører vil se etter: at praksisen har utnevnt en navngitt Clinical Safety Officer (CSO) med ansvar for klinisk sikkerhet, at praksisen vedlikeholder en risikovurdering og farelogg, og at menneskelig tilsyn med AI-utdata er innebygd i praksisens arbeidsflyter. CSO trenger ikke å være en heltidsrolle, men praksisen må kunne peke på én navngitt person som har dette ansvaret.

Styringsdokumentasjon praksisen bør opprettholde inkluderer:

• En fullført DCB0160 klinisk sikkerhetscase for implementeringen

• En risikovurdering og farelogg, som gjennomgås regelmessig og oppdateres når verktøyet endres

• Registreringer av klinikeropplæring, inkludert bevissthet om verktøyets begrensninger

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

• Bevis på at en kliniker har gjennomgått alt AI-generert innhold i pasientjournalen

Denne dokumentasjonen er ikke bare relevant for CQC-inspeksjon. Den utgjør bevisgrunnlaget som beskytter praksisen hvis en klinisk hendelse inntreffer og spørsmål reises om hvordan verktøyet ble implementert og fulgt opp, noe som gjør løpende vedlikehold av disse registreringene til en praktisk prioritet, ikke bare en formell forpliktelse.

Hva bør leverandørens støtte og kliniske evidens dekke?

For kliniske AI-verktøy er konsekvensene ved en støttefeil større enn for de fleste andre typer programvare. Service Level Agreement (SLA) bør skille mellom respons- og løsningstider for kliniske sikkerhetshendelser og for generelle tekniske problemer. Leverandøren bør ha en navngitt kontakt for fastlegepraksiser, ikke bare en generell helpdesk. 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 prosess for håndtering av kliniske sikkerhetshendelser, er ikke klar for implementering i en primærhelsetjenestesetting.

Klinisk evidens er et eget krav. Det som teller er publiserte fagfellevurderte studier eller dokumenterte pilotresultater fra britiske fastlege- eller primærhelsetjenestemiljøer, med målbare resultater og bevis på at verktøyet er evaluert mot NHS-spesifikke arbeidsflyter. Casestudier fra spesialisthelsetjenesten eller internasjonal primærhelsetjeneste holder ikke. Frontiers in Health Services sin gjennomgang av NHS AI-anskaffelsesrammeverk og forskning på AI-skribenter i primærhelsetjenesten bekrefter begge at evidensgrunnlaget fortsatt er begrenset, noe som gjør det enda viktigere å kreve det som faktisk finnes fremfor å akseptere markedsføringspåstander.

En sjekkliste før signering for fastlegepraksiser

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 fastlegemiljø

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

Spørsmålene og kontrollene i denne artikkelen danner grunnlaget som trygg 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. Som Digital Health sin rapportering om NHS AI-anskaffelse fanger det: praksiser må være «robuste i å sikre at det vi gjør er trygt, sikret og kommer til å levere fordeler.»

Ofte stilte spørsmål

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

Det avhenger av funksjonaliteten. Verktøy som støtter diagnostikk, triagering eller behandlingsanbefalinger vil sannsynligvis falle inn under Software as a Medical Device og kreve UKCA- eller CE-merking. Søk i MHRA Product and Registration Database før signering. Verktøy som ikke klassifiseres som medisinsk utstyr har fortsatt forpliktelser knyttet til databeskyttelse og klinisk sikkerhet.

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

Ansvaret ligger hos praksisen. Leverandørkontrakter dekker programvarefeil, ikke kliniske konsekvenser. Det praktiske rådet er å konsultere din medisinske forsvarsorganisasjon før implementering starter, og sørge for at den dekker AI-relaterte hendelser spesifikt.

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

Bekreft at behandling og lagring skjer i Storbritannia eller EU, og at en Data Processing Agreement i samsvar med UK GDPR artikkel 28 er inkludert i kontrakten. Spør også eksplisitt om leverandøren bruker konsultasjonsdata til modelltrening, og på hvilket rettslig grunnlag dette eventuelt skjer.

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

Be om dokumentasjon for ISO 27001, NHS Data Security and Protection Toolkit, Cyber Essentials eller Cyber Essentials Plus, og Digital Technology Assessment Criteria. NHS DSP Toolkit er et kontraktskrav for tilgang til NHS-pasientdata. En leverandør som ikke kan fremlegge 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?

Krev skriftlig svar på tre punkter før signering: hvor lenge leverandøren beholder data etter oppsigelse, om fullstendig dataeksport er mulig, og om sletting også gjelder sikkerhetskopier og underprosessordata. Klausuler som gir leverandøren rett til å 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. Verktøy trent på amerikanske data kan prestere dårlig på SNOMED CT-koding, britiske legemiddelnavn og fastlegekonsultasjonsdokumentasjon. Be leverandøren om et modellkort som beskriver treningsdatakilder, kjente begrensninger og ytelsesmål. Markedsføringspåstander er ikke dokumentasjon.

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

CQC GP Mythbuster 109 krever at praksisen utnevner en navngitt Clinical Safety Officer. Rollen trenger ikke være heltid, men én person må kunne pekes på. Dokumentasjonen denne personen vedlikeholder, inkludert farelogg og hendelsesregistreringer, er det konkrete bevisgrunnlaget praksisen kan støtte seg på hvis en klage oppstår.

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

Be leverandøren demonstrere integrasjonen i et live britisk fastlegemiljø, ikke i en demo. Avklar hvem som er ansvarlig for å vedlikeholde integrasjonen når EMIS Web eller SystmOne slipper oppdateringer, og hva reserveprosessen er hvis integrasjonen svikter under en klinisk økt.

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

Krev publiserte fagfellevurderte studier eller dokumenterte pilotresultater fra britiske fastlege- eller primærhelsetjenestemiljøer med målbare resultater. Evidens fra spesialisthelsetjenesten eller internasjonal primærhelsetjeneste overføres ikke direkte. Laranjo et al. i Lancet Primary Care har påpekt at implementering går raskere enn robust evaluering, noe som gjør grundig kildegransking særlig viktig.

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

Sjekk at Service Level Agreement skiller mellom responstider for kliniske sikkerhetshendelser og generelle tekniske problemer, og at praksisen får en navngitt kontaktperson. Be leverandøren beskrive sin prosess for rapportering av kliniske sikkerhetshendelser trinn for trinn. En leverandør som ikke kan gjøre det, er ikke klar for en klinisk setting.