Co-designing AI for the Danish emergency medical helpline Akuttelefonen 1813
2026
project overview
In Denmark's Capital Region, the emergency medical helpline Akuttelefonen 1813 answers close to 900,000 calls a year, roughly a third of them non-acute, and on the busiest days callers wait hours to get through. Together with Amalie Caramés Slot Larsen and Caroline Caramés Slot Larsen, I explored how AI could support this system and reduce non-acute calls without failing people who genuinely need help.
The project started as a question of how to minimize the queue at Akuttelefonen 1813, and developed into a question of how to make citizens more confident and certain about their own situation.
We discovered that a reason for many non-acute calls is uncertainty about what actually defines an "acute" situation. Some call to be on the safe side, while others do not call at all because they do not want to bother the system, even when their situation might be acute.
Through a co-design process with citizens who had called Akuttelefonen 1813 before, we developed a set of interaction design policies for an AI self-help system meant to guide people and increase their certainty. We worked with themes such as uncertainty, trust, and self-evaluation, and how these differ across personas. We hoped this would not necessarily only make the queue shorter, but lower the percentage of non-acute callers and make sure the people who need help get it.
Our findings were presented to relevant stakeholders in August 2026.
design process
Designing healthcare technology means designing for high risk situations, where small mistakes have big consequences.
A survey or a set of simple interviews would therefore not do. We needed a thorough understanding of the problem area and therefore included ten citizens who had called Akuttelefonen 1813 before as co-designers.
Involving them this early meant the design was shaped by real needs before anything was built, which matters most when a wrong assumption can cost someone their health.
We would have included Akuttelefonen 1813 nurses in the co-design events, since they bring another perspective, but they were busy answering the calls.
We conducted:
- Three one-on-one interviews with former callers
- One focus group with three parent couples
- Two workshops where the real design happened, with a mix of the citizens from the interviews and the focus group plus a few new ones
More specifically, we worked through a Tell-Make-Enact framework, where the phases melted together as a story, a response to it, and a test of that response often happened in the same moment.
The main benefit of co-designing the AI in this project was mutual learning: the citizens were the experts on the experience of calling Akuttelefonen 1813, on their needs and vulnerabilities, and on the mental models they held of it. We were the experts on design tools and processes, and could notice patterns the citizens were not consciously aware of.


design events
focus groups
The initial interviews informed what to look for in the focus group. There we mapped the participants' user journeys with Akuttelefonen 1813. To provoke them to reflect on how they had felt along the way, we made the discussion concrete with a timeline and a set of smileys.
Later we placed an AI sticker on certain points of their journeys and discussed what AI could mean and look like there. This showed us their motivations, their pains, their understanding of AI, and what the frame of AI could be in this project.
workshops
The centerpiece of the workshops was an exercise called "the perfect conversation". Participants were asked to imagine they were an AI chat: a fictional user, Søren, had hurt his foot, and it was up to them to respond to his messages and guide him through it.
At each step we handed them a set of pre-written responses, one per tone, from clinical to highly empathetic. We never said which was which, because we wanted their instinct, not a reasoned case for a style.
After each choice we asked why they picked it and what they would rather have heard. That was often more revealing than the choice itself, since it surfaced the gap between an answer that sounds reassuring and one people actually trust.
By the end we could lay the cards chosen most often across participants side by side and map the perfect conversation. The most informative part, however, was never which response was chosen, but what was said around the choice. The hesitation, the reasoning, and the wording participants reached for instead were what told us how the AI should actually speak.


results
The result is a set of Interaction Design Policies (a framework adapted from Google's PAIR), covering the seven critical moments we identified in the focus group and workshops. For each moment we defined what the AI should do, what it should never do, what it does not yet know, and where the user is most at risk.
We investigated whether the AI should triage live calls in the queue. The focus group pointed elsewhere, since the bigger stake was the caller's uncertainty. We agreed on a self-service tool to turn to before calling, showing whether the situation is acute or nudging them to call. The idea came from the citizens who already google their symptoms or ask ChatGPT first.
Across both workshops, the perfect conversation converged on a clear pattern. Every participant, without knowing the categories existed, picked the same tone: neutral, professional, and action-oriented. Empathy was actively rejected. Several said a warm or caring tone from an AI felt fake, precisely because they knew it was not a person saying it.
The deeper theme connecting all findings is trust. Trust in health AI is not one fixed thing, it depends on who is asking. The same person who wants a blunt answer about a sprained ankle wants something else when it is their child running a fever at 2am. Some people hesitate to reach out at all, worried about bothering anyone. Others would rather call one time too many. An AI that only spoke in one register would fail one of these groups by design.
| Acceptable actions | Unacceptable actions |
|---|---|
|
|
| Uncertainty thresholds | Vulnerabilities |
|
|
reflections and learnings
Most interaction design deals with something you can pin down. A button does the same thing every time. A screen looks the same to every user. You can build a prototype, hand it to someone, and know exactly what you are testing. AI does not offer that certainty. Funnily enough, the question I found myself asking most throughout this project was "what am I even designing?"
Designing for something that behaves differently every time means you cannot predict exactly what will happen. In a sense I like to think of it as I was designing a stage where the interaction plays out. Through the co-design process we shaped that stage, its boundaries and how the AI should behave on it, so citizens would feel comfortable stepping onto it.
Another counterintuitive thing I learned is that too much trust in a system can be just as dangerous as too little. Overtrust means people act on an AI's suggestion even when their own judgment says something is off. Undertrust means people ignore a system that could actually help them, or abandon it altogether. Going in, I expected undertrust to be the bigger risk in healthcare. It turned out overtrust was the harder one to design against.
Part of that is because trust here is borrowed. Citizens said they would trust an AI far more coming from Akuttelefonen 1813 than from a private app, which makes them willing to use it, and at the same time makes its answers sound more certain than they are.
The question I could not answer is who carries the responsibility. If a citizen follows the AI and comes to harm, is it the developers, the region, Akuttelefonen 1813, or the citizen? Saying the final call is always the citizen's is easier in theory than in practice, since the relationship is never equal.
What we could do was design for that asymmetry rather than pretend it away. In a domain where one kind of mistake is survivable and the other is not, it is better for the AI to send ten citizens too many than one too few.