What do KKR requirements mean for a journal system?

When a Danish municipality buys a social care placement from a private or non-profit provider, requirements for documentation and follow-up almost always come with it.

In tenders, framework agreements and everyday dialogue, those requirements are sometimes bundled together under the label "KKR requirements". The label is misleading.

There is no national KKR standard for journal systems, and there is no certification scheme under which a journal system can become "KKR-approved".

KKR — the regional municipal contact councils — are part of the political organisation of Local Government Denmark. There are five of them: North Denmark, Central Denmark, Southern Denmark, Zealand and the Capital Region. Among other things, they coordinate how municipalities work together in the social care sector.

So the interesting question for a provider is not whether the journal system carries some KKR stamp. It is this:

Can the provider document the service the municipality ordered, track how the service user is progressing, and deliver the documentation when the municipality asks for it?

New joint municipal requirements for documentation

The direction of travel is clearly towards more uniform documentation.

A current example is KKR Zealand, where the municipalities signed up in June 2026 to five joint guidelines for social care procurement and contract management in the specialised social care sector. One of the five deals directly with documentation.

In it, the municipalities state that they will set clear and uniform requirements for how providers document both:

• the services actually delivered
• the intended outcome for the service user

The purpose is partly to create a shared basis for follow-up, and for adjusting the service if the person's needs change.

That matters for providers. But it matters just as much to understand what the guidelines do not say.

The KKR Zealand guidelines do not determine which journal system a provider must use. Nor do they set technical requirements for particular databases, integrations, export formats or software features. The requirement concerns the result of the documentation — not which IT system produces it.

So what does this mean for the journal system?

A journal system can make it considerably easier — or considerably harder — to meet municipal documentation requirements.

In practice, the system should make it possible to draw a clear line from the municipality's order, through the service user's goals and the service delivered, to how things developed and how it was followed up.

If that line can only be reconstructed by wading through journal notes, emails, Word documents and spreadsheets, both progress reporting and municipal follow-up become needlessly heavy. A modern journal system should therefore help the provider structure documentation around the pathway the municipality actually bought.

1. The municipality's goals must be traceable throughout

When someone is referred to a provider, the municipality will normally have described a purpose for the placement and a set of goals or support needs. Those goals should be directly findable in the provider's own documentation.

It should be possible to see:

• what the municipality ordered
• which goals the provider is working towards
• which services have been delivered
• how the service user is progressing
• what the professional assessment is
• whether a goal continues, changes or ends

It is precisely this link between service and outcome that is becoming more central to municipal contract management. The new joint guidelines from KKR Zealand are a concrete example.

2. Document the service delivered — not just the journal note

A journal note tells you what happened on a particular day. But the municipal caseworker often needs a different view: what has the provider done, taken as a whole, to reach the agreed goal?

A journal system should therefore make it possible to gather the relevant observations, activities, assessments and follow-ups around the service user's goals. That makes progress reporting easier and reduces the risk of something important disappearing among hundreds of chronological notes.

3. Progress and outcome must be describable

Municipalities are not buying documentation for its own sake. They need to be able to tell whether the service is making a difference.

That does not mean every social care intervention can be reduced to a number or a score. But the system should make it possible to describe, systematically:

• progress
• stability
• decline
• changing needs
• sub-goals achieved
• the professional reasoning behind any change

This becomes particularly relevant when the municipality has to decide whether a placement should continue, change or end. The 2026 KKR Zealand guidelines tie documentation of the services delivered directly to documentation of the intended outcome.

4. Version history is not a KKR requirement — but it can matter a great deal

Here it is worth keeping different sets of rules apart.

There is no general KKR requirement that every social care journal system must have version history. But version history can be decisive for traceability. If a care plan or an assessment is changed, it may later be important to see:

• what it said before
• when it was changed
• who changed it
• what the new assessment was

And where a provider delivers healthcare services, actual clinical record-keeping rules apply. The Danish Patient Safety Authority states that information in a patient record must not be deleted. Where a correction is made, the original version must remain available, and it must be evident who made the change and when.

Version history is therefore not something to market as a general "KKR requirement". It is a feature that supports traceable documentation — and, in a clinical context, one you need in order to comply with record-keeping rules.

5. The municipality has to be able to get the documentation out

A good journal system should not only store information. The information has to be usable.

When a municipality follows up on a placement, it may need:

• a progress report
• follow-up against goals
• the care plan
• attendance
• medication information, where relevant and lawful
• professional assessments
• evidence of particular services delivered

For many providers, being able to produce well-designed reports or PDF extracts that the municipality can file on its own case will be enough. Other agreements may call for structured data or specific integrations.

So always start from the individual municipality's contract or tender rather than assuming there is a single technical KKR standard.

Does the journal system need to integrate directly with the municipality's case system?

Not because of any general KKR requirement.

There is no nationwide requirement that private social care providers must have direct system-to-system integration with municipal case systems. Requirements vary between municipalities and between individual tenders.

So the question to ask is: what information do we need to deliver, how often, and in what format? That is a more useful question than asking whether a journal system is "KKR-compatible".

Vendor independence: important, but also not a KKR requirement

Another area often conflated with KKR requirements is vendor independence.

It is good practice to make sure a provider can change journal system without losing access to its documentation. The agreement with the system vendor should therefore set out:

• how data can be handed over
• in which formats
• what happens when the contract ends
• how quickly data can be handed over
• how any copies held by the processor are dealt with afterwards

It is not accurate, however, to describe this as a general KKR requirement. Part of it follows instead from data protection law.

Where the journal system vendor is a processor, the processor must — at the controller's choice — delete or return the personal data when the service ends, and delete existing copies unless law requires continued storage. That follows from Article 28 of the GDPR.

It is therefore worth having exit and data handover described clearly in the contract, before you need them. We have described how a handover works in practice in our post on switching journal systems and getting your data out safely.

Who owns the data?

"The customer owns their data" is a phrase software vendors reach for often. Legally, it is not very precise when personal data is involved.

The question that matters is a different one: who is the controller for this particular processing of personal data?

The Danish Data Protection Agency describes the controller as the party that determines why and how personal data is processed. A processor, by contrast, processes data on behalf of the controller and on the controller's instructions.

The division of roles cannot be settled simply by writing in a contract that one party is controller and the other processor. It has to match how things actually work.

The municipality and the provider can both be controllers

Nor is it necessarily right to say the municipality is controller for everything because the municipality pays for the placement.

The municipality will typically be controller for its own casework as a public authority. An independent care provider can at the same time be controller for the processing where the provider itself determines the purpose and the essential means.

The journal system vendor will normally be a processor, where it only stores and processes data on the provider's instructions. The actual division of roles should always be assessed on the basis of who genuinely determines the purpose and means of the processing.

Do not send the municipality more than it needs

The fact that a municipality has bought a treatment or residential placement does not automatically mean the service user's entire record should be sent to the municipality.

There should always be a lawful basis for disclosure, and the information should be limited to what is relevant and necessary for the specific purpose. Often the municipality needs a targeted status on the service it ordered — not every daily journal note.

It is therefore an advantage if the journal system can generate targeted progress reports rather than only export the whole record.

Access control and logging

A journal system holding sensitive personal data should have clear role and permission management. Staff should only have access to the information they need for their work.

Logging is another central safeguard. The Danish Data Protection Agency notes, among other things, that logging can be used afterwards to establish what actions users took in a system, and can help detect or prevent unauthorised access to personal data.

Exactly what logging is needed depends on the system's risks and the processing involved — which is why it is also inaccurate to describe one particular logging feature as a universal KKR requirement. We have set out the full picture in our post on GDPR in a journal system for addiction treatment.

What about AI in the journal system?

AI does not change who is responsible for the record.

Where AI is used to structure journal notes, summarise a pathway, draft text for a progress report or find relevant information in the record, the professional must still take a view on the content before it becomes part of the final documentation.

Beyond that, using personal data for an AI feature has to stay within the applicable rules on data protection and information security.

In Validi, AI-assisted content is marked, and the principle is that AI can gather and propose content while the professional decides and approves. That should not be described as a KKR requirement either. It is a choice about traceability and responsible use of AI.

So what should a journal system be able to do?

If a provider wants to be well placed for municipalities' growing documentation requirements, these are the things we would look for:

1. A clear line from order to goals to service delivered to follow-up
2. Structured documentation of the service actually delivered
3. The ability to describe progress and outcome
4. Traceability and meaningful version history
5. Role-based access control
6. Relevant logging of access and actions
7. Progress reports and usable extracts
8. The ability to get data out when changing systems
9. A clear data processing agreement, including sub-processors
10. A clear process for data when the contract ends

This is not an official KKR checklist. These are the characteristics that make a journal system better suited to supporting the documentation, security and follow-up requirements providers meet from municipalities and other authorities.

How to prepare for the municipality's requirements

When a municipality asks about documentation or "KKR requirements", the safest approach is to start from the specific requirement. Ask for the exact wording from:

• the contract
• the tender documents
• the municipality's quality requirements
• the placement order
• the regional or joint municipal agreement

Do not settle for "the system complies with the KKR requirements". Ask the vendor to show you concretely how the system handles order, goals, service, progress, status and export. That tells you far more about whether it works in practice.

Frequently asked questions about KKR requirements for journal systems

Is there a KKR approval scheme for journal systems?

No. We have not been able to identify any official national KKR approval scheme for journal systems. KKR are the municipalities' regional cooperation bodies, and they can set shared municipal positions and principles in areas including social care. But a journal system does not get formally certified as "KKR-approved".

So if a vendor uses phrases like "meets the KKR requirements", ask which specific requirements they are referring to — and then ask to see the features demonstrated.

Are KKR requirements the same across Denmark?

No. There are five KKR, and the regional partnerships can prioritise differently. On top of that, individual municipalities and individual tenders can add requirements of their own.

A current example is the five joint guidelines from KKR Zealand in 2026, which make documentation of both the service delivered and the intended outcome a shared central principle. So always check the specific agreement.

Is version history a KKR requirement?

Not as a general rule. But version history can make it considerably easier to document changes and professional decisions.

And where the system is used for clinical record-keeping, separate rules apply: the original text must be preserved when a correction is made, and it must be possible to see who made the correction and when. It is a good example of a feature that can matter a great deal — without therefore being a "KKR requirement".

Do we need to be able to export our data?

It is strongly advisable. Partly because a provider has to be able to use its documentation in working with the municipality, and partly because you should be able to change systems without losing access to your historical records.

Where the vendor acts as a processor, the GDPR also contains rules on returning or deleting personal data when the processing ends. So ask the vendor before signing: what exactly do we get handed over if we terminate you tomorrow?

The important question is not whether the system is "KKR-approved"

Municipalities are moving towards more systematic documentation of the link between need, service and outcome. That places greater demands on providers — and therefore, indirectly, on the journal systems they work in.

But here is the distinction that matters: the municipality sets requirements for the provider and the documentation the provider delivers. The journal system is the tool that makes it possible to meet them.

So it is better to choose a system on the basis of what it can actually document than on a promise that it is "KKR-approved".

Would you like to see it in practice?

We are happy to show how goals, record-keeping, progress, version history and progress reports fit together across a single service user pathway — on fictional data. Then you can judge for yourself whether the system delivers the documentation your municipal partners are asking for.

Book a no-obligation walkthrough of Validi.