At the recent OutSystems ONE Conference, Matthijs van Hagen (Product Lead at Cordaan) and I shared the stage to tackle a fundamental problem in the healthcare sector. For those who don't know the organisation: Cordaan is one of the largest care providers in and around Amsterdam. With roughly 6,000 employees, they support more than 20,000 clients across elderly care, disability care, and mental health care.
The operational complexity of an organisation like that is enormous. Matthijs set out a challenge every CTO will recognise: an abundance of fragmented point solutions. Cordaan's care workers were losing themselves in a maze of apps for medication, care plans, and protocols.
With Cordaan Werkt, we used OutSystems to build a central "super-app" to counter that fragmentation. The latest addition to it is an advanced implementation of RAG (Retrieval Augmented Generation).
What is RAG, and why is it crucial in healthcare?
For anyone who doesn't yet use the term daily: RAG is an architectural pattern that couples a large language model (such as GPT-5) to a specific, external information source.
Using generative AI in a clinical or care-related context is risky if you rely solely on public LLMs. The chance of hallucinations is simply too great. At the same time, the digital library of a large care institution is often a graveyard of unused PDF protocols.
RAG bridges these two worlds. Instead of hoping a model "knows" the right information, we force the AI to formulate answers based exclusively on Cordaan's own, validated source documents. This process runs through a tightly defined pipeline: retrieval of relevant chunks, augmentation of the prompt, and finally generation of the answer.
When a care worker asks a question, the system first finds the most relevant fragments in the internal protocols (Retrieval). This factual information is then passed as context to the AI model (Augmented), which formulates an accurate answer on that basis (Generation). This minimises the chance of hallucinations and ensures the output is always directly verifiable against the source.
The architecture: from test phase to evolution
During our presentation at the ONE Conference, we showed the blueprint we used during the initial test phase. It's worth noting that this architecture formed the basis for our proof-of-concept. Since then the architecture has partly shifted as we scale towards broad production, which is telling of the speed of this technology.
The foundations of that phase were:
Azure AI Search as orchestrator. During the test phase we used Azure's indexing capabilities. At that point we relied mainly on BM25 search for lexical precision and complemented it with semantic search to raise contextual relevance, without the overhead of a full vector database.
Intelligent chunking. We developed our own character-based chunking mechanism with a strategic overlap. This ensures the semantic value is not lost when documents are split up, which is essential for accuracy.
OutSystems AI Workbench. This acted as the secure gateway to the LLM, where we kept full control over the data flows and the integrity of the prompts.
Lessons learned: strategic insights for AI in healthcare
Our journey with Matthijs at Cordaan surfaced a number of crucial lessons that are essential for any care institution getting started with AI:
Start with a "human-in-the-loop" mindset. AI should assist, not dictate. The feedback loop where care workers can rate answers as "useful" or "not useful" is not only technical validation, but also an essential part of the adoption process on the ground.
Pragmatism beats complexity. In the test phase, the temptation is strong to go straight for the most expensive vector databases. Our lesson? Start simple with lexical search and expand to semantic search when the use case calls for it. That saves considerable cost in the early stages.
Data hygiene is the bottleneck. The model is only as good as its source. We found that cleaning up old PDF protocols has more impact on the quality of the answer than fine-tuning the AI model itself.
Architectural flexibility is a requirement. As our own shift after the test phase proves: the AI market changes weekly. Build your solution modularly so you can switch provider or model relatively easily, without rewriting your entire application logic.
Guardrails and keeping it human
As Matthijs stressed, at Cordaan AI is an assistant, not a replacement. That translates into hard technical boundaries: the bot is explicitly configured as a non-medical tool, every answer contains direct citations to the source, and privacy filters safeguard anonymity before data leaves the domain.
Looking ahead: from RAG to Self-RAG
Although the architecture around the provider and implementation has since shifted compared with our first presentation, the vision remains unchanged. We are now looking at patterns such as Self-RAG, where the model itself assesses the quality of the retrieved information before the user sees it.
The lesson for the sector is simple: the technology is a means, not an end. By starting pragmatically, learning critically from your test phase, and being willing to adapt your architecture to real-world practice, you can already give care workers back time today for what really matters: the client.
Curious about what our current architecture looks like after the latest shifts, or want to talk through the specific lessons learned, or AI within your own organisation? Do get in touch.
