KKR-krav til journalsystemer – hvad kræver kommunen?
31. august 2026
Hvad betyder KKR-krav for et journalsystem? Få overblik over kommunernes krav til dokumentation, effekt, GDPR, sporbarhed og dataudveksling.
Når en kommune køber en social indsats hos et privat eller selvejende tilbud, følger der næsten altid krav til dokumentation og opfølgning med.
I udbud, samarbejdsaftaler og dialog med kommunerne bliver disse krav nogle gange omtalt samlet som "KKR-krav". Men begrebet kan være misvisende.
Der findes nemlig ikke én national KKR-standard for journalsystemer, og der findes heller ikke en officiel godkendelsesordning, hvor et journalsystem kan blive "KKR-godkendt".
KKR — Kommunekontaktrådene — er en del af KL's politiske organisation. Der er fem KKR: Nordjylland, Midtjylland, Syddanmark, Sjælland og Hovedstaden. De koordinerer blandt andet kommunernes samarbejde på socialområdet.
Det interessante for et socialt tilbud er derfor ikke, om journalsystemet har et bestemt KKR-stempel. Det interessante er:
Kan tilbuddet dokumentere den indsats, kommunen har bestilt, følge udviklingen hos borgeren og levere den nødvendige dokumentation, når kommunen beder om den?
Nye fælleskommunale krav til dokumentation
Udviklingen går tydeligt i retning af mere ensartet dokumentation.
Et aktuelt eksempel er KKR Sjælland, hvor kommunerne i juni 2026 tilsluttede sig fem fælleskommunale guidelines for socialfaglige indkøb og kontraktstyring på det specialiserede socialområde. En af de fem guidelines handler direkte om dokumentation.
Her fastslår kommunerne, at de vil stille klare og ensartede krav til leverandørernes dokumentation af både:
- de ydelser, der faktisk er leveret
- den ønskede effekt for borgeren
Formålet er blandt andet at skabe et fælles grundlag for opfølgning og for eventuel justering af indsatsen, hvis borgerens behov ændrer sig.
Det er væsentligt for sociale tilbud. Men det er samtidig vigtigt at forstå, hvad der ikke står.
KKR Sjællands guidelines fastlægger ikke, hvilket journalsystem tilbuddet skal bruge. De opstiller heller ikke tekniske krav om bestemte databaser, integrationer, eksportformater eller softwarefunktioner. Kravet handler om resultatet af dokumentationen — ikke om hvilket it-system der producerer den.
Hvad betyder det så for journalsystemet?
Et journalsystem kan gøre det meget lettere — eller meget vanskeligere — at leve op til kommunernes dokumentationskrav.
I praksis bør systemet gøre det muligt at skabe en tydelig sammenhæng mellem kommunens bestilling, borgerens mål, den leverede indsats, udviklingen og opfølgningen.
Hvis den sammenhæng kun kan findes ved at gennemgå journalnotater, mails, Word-dokumenter og regneark manuelt, bliver både statusarbejde og myndighedsopfølgning unødigt tungt. Et moderne journalsystem bør derfor hjælpe tilbuddet med at strukturere dokumentationen omkring det forløb, kommunen faktisk har købt.
1. Kommunens mål skal kunne følges gennem hele forløbet
Når en borger visiteres til et tilbud, vil kommunen normalt have beskrevet et formål med indsatsen og en række mål eller støttebehov. De mål bør kunne genfindes direkte i tilbuddets dokumentation.
Det skal helst være muligt at se:
- hvad kommunen har bestilt
- hvilke mål tilbuddet arbejder med
- hvilke indsatser der er gennemført
- hvordan borgeren udvikler sig
- hvad den faglige vurdering er
- om målet fortsætter, ændres eller afsluttes
Det er netop forbindelsen mellem indsats og effekt, der bliver stadig vigtigere i kommunernes kontraktstyring. KKR Sjællands nye fælleskommunale guidelines er et konkret eksempel på denne udvikling.
2. Dokumentér den leverede ydelse — ikke bare journalnotatet
Et journalnotat fortæller, hvad der skete på en bestemt dag. Men myndighedssagsbehandleren har ofte brug for et andet perspektiv: hvad har tilbuddet samlet set gjort for at nå det aftalte mål?
Et journalsystem bør derfor gøre det muligt at samle relevante observationer, aktiviteter, vurderinger og opfølgninger omkring borgerens mål. Det gør statusarbejdet lettere og reducerer risikoen for, at væsentlige oplysninger forsvinder mellem hundredvis af kronologiske journalnotater.
3. Progression og effekt skal kunne beskrives
Kommunerne køber ikke dokumentation for dokumentationens skyld. De skal kunne følge, om indsatsen gør en forskel.
Det betyder ikke nødvendigvis, at alle sociale indsatser kan reduceres til et tal eller en score. Men systemet bør gøre det muligt systematisk at beskrive:
- udvikling
- stabilitet
- tilbagegang
- ændrede behov
- opnåede delmål
- faglige begrundelser for ændringer
Det bliver særligt relevant, når kommunen skal tage stilling til, om indsatsen skal fortsætte, ændres eller afsluttes. KKR Sjællands 2026-guidelines kobler netop dokumentationen af de leverede ydelser sammen med dokumentationen af den ønskede effekt for borgeren.
4. Versionshistorik er ikke et KKR-krav — men kan være meget vigtig
Her er det vigtigt at skelne mellem forskellige regelsæt.
Der findes ikke et generelt KKR-krav om, at alle sociale journalsystemer skal have versionshistorik. Men versionshistorik kan være afgørende for sporbarheden. Hvis en handleplan eller vurdering ændres, kan det være vigtigt senere at kunne se:
- hvad der stod tidligere
- hvornår det blev ændret
- hvem der ændrede det
- hvad den nye vurdering blev
Og udfører tilbuddet sundhedsfaglig behandling, er der egentlige journalføringsregler. Styrelsen for Patientsikkerhed fastslår, at oplysninger i en patientjournal ikke må slettes. Ved rettelser skal den oprindelige version fortsat være tilgængelig, og det skal fremgå, hvem der foretog ændringen og hvornår.
Versionshistorik er derfor ikke noget, man bør markedsføre som et generelt "KKR-krav". Det er snarere en funktion, der kan understøtte sporbar dokumentation — og på det sundhedsfaglige område være nødvendig for at kunne overholde journalføringsreglerne.
5. Kommunen skal kunne få dokumentationen ud
Et godt journalsystem skal ikke kun kunne gemme oplysninger. Oplysningerne skal også kunne anvendes.
Når kommunen følger op på et forløb, kan der eksempelvis være behov for:
- statusrapport
- opfølgning på mål
- handleplan
- fremmøde
- medicinoplysninger, når det er relevant og lovligt
- faglige vurderinger
- dokumentation for bestemte indsatser
For mange tilbud vil det være tilstrækkeligt at kunne producere veldesignede rapporter eller PDF-udtræk, som kan journaliseres på kommunens egen sag. I andre samarbejder kan der blive stillet krav om strukturerede data eller konkrete integrationer.
Derfor bør man altid tage udgangspunkt i den konkrete kommunes aftale eller udbud frem for at antage, at der findes én teknisk KKR-standard.
Skal journalsystemet integrere direkte med kommunens fagsystem?
Ikke som følge af et generelt KKR-krav.
Der findes ikke et landsdækkende krav om, at private sociale tilbud skal have direkte system-til-system-integration med kommunernes fagsystemer. Kravene kan variere mellem kommuner og konkrete udbud.
Derfor bør tilbuddet spørge: hvilke oplysninger skal vi levere — hvor ofte og i hvilket format? Det er mere præcist end at spørge, om journalsystemet er "KKR-kompatibelt".
Leverandøruafhængighed: vigtigt, men heller ikke et KKR-krav
Et andet område, der ofte blandes sammen med KKR-krav, er leverandøruafhængighed.
Det er god praksis at sikre, at et socialt tilbud kan skifte journalsystem uden at miste adgang til sin dokumentation. Det bør derfor fremgå af aftalen med systemleverandøren:
- hvordan data kan udleveres
- i hvilke formater data kan udleveres
- hvad der sker ved kontraktens ophør
- hvor hurtigt data kan udleveres
- hvordan eventuelle kopier hos databehandleren håndteres efter ophør
Det er imidlertid ikke korrekt at beskrive dette som et generelt KKR-krav. Noget af området følger i stedet af databeskyttelsesreglerne.
Hvis journalsystemleverandøren er databehandler, skal databehandleren som udgangspunkt efter den dataansvarliges valg slette eller tilbagelevere personoplysningerne, når databehandlerens ydelse ophører, og eksisterende kopier skal slettes, medmindre lovgivningen kræver fortsat opbevaring. Det følger af GDPR artikel 28.
Det er derfor en god idé at have exit og dataoverdragelse beskrevet tydeligt i kontrakten, inden man får brug for det. Vi har beskrevet, hvordan en overdragelse konkret foregår, i indlægget om at skifte journalsystem og få data sikkert ud.
Hvem ejer data?
Udtrykket "kunden ejer sine data" bruges ofte af softwareleverandører. Men juridisk er formuleringen ikke særlig præcis, når der er tale om personoplysninger.
Det vigtigste spørgsmål er i stedet: hvem er dataansvarlig for den konkrete behandling af personoplysninger?
Datatilsynet beskriver grundlæggende den dataansvarlige som den part, der bestemmer hvorfor og hvordan personoplysninger skal behandles. En databehandler behandler derimod oplysninger på vegne af den dataansvarlige og efter dennes instruks.
Rollefordelingen kan derfor ikke afgøres alene ved at skrive i en kontrakt, at én part er dataansvarlig og en anden databehandler. Den skal passe til de faktiske forhold.
Kommunen og tilbuddet kan begge være dataansvarlige
Det er heller ikke nødvendigvis korrekt at sige, at kommunen er dataansvarlig for alle oplysninger, fordi kommunen betaler for indsatsen.
Kommunen vil typisk være dataansvarlig for sin myndighedsbehandling. Et selvstændigt behandlingstilbud kan samtidig være dataansvarligt for den behandling af personoplysninger, hvor tilbuddet selv bestemmer formålet og de væsentlige rammer for behandlingen.
Journalsystemleverandøren vil normalt være databehandler, når leverandøren alene opbevarer og behandler oplysninger efter tilbuddets instruks. Den konkrete rollefordeling bør altid vurderes ud fra, hvem der faktisk bestemmer formål og hjælpemidler for behandlingen.
Send ikke mere til kommunen end nødvendigt
At kommunen har købt et behandlings- eller botilbud betyder ikke automatisk, at hele borgerens journal skal sendes til kommunen.
Der bør altid være et lovligt grundlag for videregivelsen, og oplysningerne bør begrænses til det, der er relevant og nødvendigt for det konkrete formål. Ofte har kommunen brug for en målrettet status på den bestilte indsats — ikke samtlige daglige journalnotater.
Derfor er det en fordel, hvis journalsystemet kan generere målrettede statusrapporter frem for kun at kunne eksportere hele journalen.
Adgangsstyring og logning
Et journalsystem med følsomme personoplysninger bør have en klar rolle- og rettighedsstyring. Medarbejdere bør kun have adgang til de oplysninger, de har et arbejdsmæssigt behov for.
Logning er også en central sikkerhedsforanstaltning. Datatilsynet fremhæver blandt andet, at logning kan bruges til efterfølgende at undersøge, hvilke handlinger brugere har foretaget i et system, og kan bidrage til at opdage eller forebygge uberettiget adgang til personoplysninger.
Det præcise behov for logning afhænger af systemets risici og behandlingen af oplysninger — det er derfor heller ikke korrekt at beskrive én bestemt logfunktion som et universelt KKR-krav. Vi har samlet det fulde billede i indlægget om GDPR i journalsystem til rusmiddelbehandling.
Hvad med AI i journalsystemet?
AI ændrer ikke på ansvaret for journalen.
Hvis AI anvendes til eksempelvis at strukturere journalnotater, sammenfatte et forløb, foreslå tekst til en statusrapport eller finde relevante oplysninger i journalen, bør den faglige medarbejder fortsat tage stilling til indholdet, før det bliver en del af den endelige dokumentation.
Derudover skal anvendelsen af personoplysninger til AI-funktionen ske inden for de gældende regler om databeskyttelse og informationssikkerhed.
I Validi markeres AI-assisteret indhold, og princippet er, at AI kan samle og foreslå indhold, mens fagpersonen tager stilling til og godkender det. Det bør dog ikke beskrives som et KKR-krav. Det er et valg om sporbarhed og ansvarlig anvendelse af AI.
Hvad skal et journalsystem så kunne?
Hvis et socialt tilbud vil være godt rustet til kommunernes stigende krav til dokumentation, vil vi især se efter følgende:
- Sammenhæng mellem bestilling, mål, indsats og opfølgning
- Struktureret dokumentation af den leverede indsats
- Mulighed for at beskrive progression og effekt
- Sporbarhed og relevant versionshistorik
- Rollebaseret adgangsstyring
- Relevant logning af adgang og handlinger
- Statusrapporter og brugbare udtræk
- Mulighed for at få data ud ved systemskifte
- En klar databehandleraftale og aftale om underdatabehandlere
- En klar proces for data ved kontraktens ophør
Det er ikke en officiel KKR-tjekliste. Det er de egenskaber, der gør et journalsystem bedre egnet til at understøtte de dokumentations-, sikkerheds- og opfølgningskrav, som sociale tilbud møder fra kommuner og andre myndigheder.
Sådan forbereder I jer på kommunens krav
Når kommunen spørger til dokumentation eller "KKR-krav", er den sikreste fremgangsmåde at starte med det konkrete krav. Bed om den præcise formulering fra:
- kontrakten
- udbudsmaterialet
- kommunens kvalitetskrav
- bestillingen
- den regionale eller fælleskommunale aftale
Undgå at nøjes med formuleringen "systemet overholder KKR-kravene". Bed i stedet leverandøren vise konkret, hvordan systemet håndterer bestilling, mål, indsats, progression, status og eksport. Det siger langt mere om, hvorvidt systemet fungerer i praksis.
Ofte stillede spørgsmål om KKR-krav til journalsystemer
Findes der en KKR-godkendelse af journalsystemer?
Nej. Vi har ikke kunnet identificere en officiel national KKR-godkendelsesordning for journalsystemer. KKR er kommunernes regionale samarbejdsorganer, og de kan fastlægge fælles kommunale linjer og principper på blandt andet socialområdet. Men et journalsystem bliver ikke officielt certificeret som "KKR-godkendt".
Hvis en leverandør bruger formuleringer som "opfylder KKR-kravene", bør man derfor spørge: hvilke konkrete krav henviser I til? Og derefter bede om at få funktionerne demonstreret.
Er KKR-krav ens i hele Danmark?
Nej. Der findes fem KKR, og de regionale samarbejder kan prioritere forskelligt. Derudover kan den enkelte kommune og det enkelte udbud stille yderligere krav.
Et aktuelt eksempel er KKR Sjællands fem fælleskommunale guidelines fra 2026, hvor dokumentation af både den leverede ydelse og den ønskede effekt for borgeren er gjort til et centralt fælles princip. Man bør derfor altid undersøge den konkrete aftale.
Er versionshistorik et KKR-krav?
Ikke generelt. Men versionshistorik kan gøre det væsentligt lettere at dokumentere ændringer og faglige beslutninger.
Og hvis systemet anvendes til sundhedsfaglig journalføring, gælder der særskilte regler om, at den oprindelige journaltekst skal kunne bevares ved efterfølgende rettelser, og at det skal kunne ses, hvem der har foretaget rettelsen og hvornår. Det er altså et godt eksempel på en funktion, der kan være meget vigtig — uden at den dermed er et "KKR-krav".
Skal vi kunne eksportere vores data?
Det er stærkt anbefalelsesværdigt. Dels fordi et tilbud skal kunne anvende sin dokumentation i samarbejdet med kommunen, dels fordi man bør kunne skifte system uden at miste adgangen til sin historiske dokumentation.
Hvis leverandøren fungerer som databehandler, indeholder GDPR desuden regler om tilbagelevering eller sletning af personoplysninger ved databehandlingens ophør. Spørg derfor leverandøren allerede inden kontrakten underskrives: hvad får vi konkret udleveret, hvis vi opsiger jer i morgen?
Det vigtigste spørgsmål er ikke, om systemet er "KKR-godkendt"
Kommunernes fokus bevæger sig mod mere systematisk dokumentation af sammenhængen mellem behov, indsats og effekt. Det stiller større krav til de sociale tilbud — og dermed indirekte også til de journalsystemer, de arbejder i.
Men den afgørende skelnen er denne: kommunen stiller krav til tilbuddet og den dokumentation, tilbuddet leverer. Journalsystemet er værktøjet, der skal gøre det muligt at leve op til kravene.
Det er derfor bedre at vælge et system ud fra, hvad det konkret kan dokumentere, end ud fra et løfte om, at det er "KKR-godkendt".
Vil I se det i praksis?
Vi viser gerne, hvordan mål, journalføring, progression, versionshistorik og statusrapporter kan hænge sammen i ét samlet borgerforløb — på fiktive data. Så kan I selv vurdere, om systemet kan levere den dokumentation, jeres kommunale samarbejdspartnere efterspørger.
Var indlægget nyttigt?