DEV Community: Monika Sonnad Math

What Working in Healthcare Tech Taught Me About Writing Software That Actually Matters

Monika Sonnad Math — Fri, 12 Jun 2026 15:51:33 +0000

I've worked in two industries as a software developer — telecom and healthcare. Both involve large-scale distributed systems, event-driven architecture, real-time data pipelines. The technical problems are genuinely similar.

But the way I think about writing software is completely different now. And I think healthcare did that to me.

***In Telecom, the Stakes Were Scale*
In Telecom I was building Kafka pipelines that handled hundreds of millions of events a day. The engineering problems were real and interesting — latency, fault tolerance, schema evolution, consumer lag. When something went wrong, throughput dropped, dashboards went red, and the on-call engineer had a bad night.

That's stressful. But the worst case scenario of most failures was: some events got delayed, some metrics were stale, some retry queues backed up. You fixed it, you wrote a post-mortem, you moved on.

The users of the system — the telecom customers — mostly never knew anything had happened.

In Healthcare, the Stakes Are Different
My first week at my Organisation now, I was shown around the clinical operations. I saw the actual documents my code would be processing — patient referrals, discharge summaries, operation notes. Real documents, with real patient names, real diagnoses, real medication lists.

And I realised something that sounds obvious but hadn't fully landed before: the output of my code connects to a real person's care.

A wrong patient URN doesn't just fail a unit test. It means a document gets filed against the wrong patient record. In the best case someone notices and fixes it manually. In a worse case, a clinician makes a decision based on incomplete or incorrect information.

I'm not saying this to be dramatic. I'm saying it because it genuinely changed how I write code.

Three Things That Changed

1. I stopped tolerating silent failures

In a lot of systems, silent failures are acceptable. A job fails, logs an error, moves on. You catch it in the morning during the daily review.

In healthcare I became almost allergic to this pattern. If something goes wrong I want to know immediately and I want to know exactly what went wrong. Not a generic exception. Not a null pointer that bubbles up three layers. The specific thing that failed, why it failed, and what state the data was left in.

This led me to design the OCR service I built at Kingsbridge with explicit failure modes. If the system can't confidently extract a patient URN, it doesn't guess — it flags the document for manual review. That's a deliberate design decision, not a fallback. The uncertainty is surfaced, not hidden.

I've taken this thinking back into every system I build now. Silent failures are technical debt you pay in trust.

2. I started thinking about the person at the end of the pipeline

In telecom I thought about throughput, latency, and uptime. These are the right things to think about.

In healthcare I started asking a different question before designing any feature: who is going to use this, and what will they do with the output?

For the OCR service the answer was: a clinical admin team member, who will take this Excel output and use it to match documents to patient records. That person is not a developer. They don't know what OCR is. They don't care about my architecture. They care about whether the output is correct and whether the errors are clearly labelled so they can handle the exceptions without calling IT.

That shift in perspective — from "does the system work" to "does the system work for this specific person in this specific context" — is something I now apply everywhere.

3. I push back more

This one surprised me.

I always thought I was reasonably good at asking questions about requirements. But healthcare gave me a much lower tolerance for building things I wasn't sure about.

The cost of building the wrong thing in a clinical context is high. Not just wasted engineering time — potentially wrong data in production, potentially a process that introduces errors that are hard to find later. So I started pushing back in planning meetings more. Not aggressively, but persistently. "What happens if the document doesn't have a label in the expected position?" "What should the system do if the confidence score is below threshold?" "Who is responsible for reviewing the exceptions?"

These questions feel slower in the moment. They make planning meetings longer. But they make the actual software much more reliable because you've thought through the edge cases before you've written a single line of code.

The Unexpected Benefit

Something I didn't expect: writing software this way is more satisfying.

When I shipped the OCR service and it went into production, I knew exactly what it did, what it didn't do, how it failed, and who was responsible for each failure mode. I knew the clinical staff using it had been involved in testing it on real documents. I knew the exception handling matched their actual workflow.

That's a different feeling from shipping something that works in the demo but has a bunch of edge cases you're not sure about.

I think most developers want to write software that matters. Healthcare has a way of making that very concrete, very quickly. The feedback loop between what you build and whether it actually helps someone is short and visible.

That's a privilege, honestly.

***What I'd Tell Developers Thinking About Healthcare Tech*
It's not as inaccessible as it looks. You don't need a medical background. You need the same things you need in any domain: curiosity about the actual problem, willingness to ask questions, and the discipline to handle edge cases properly.

What you get in return is a clarity of purpose that's harder to find in other domains. The work matters in a way that's tangible. And that tends to make you a better engineer.

I Work in Healthcare Tech. Here's Why I Built a RAG Tool for Clinical Documents.

Monika Sonnad Math — Wed, 03 Jun 2026 10:24:19 +0000

I didn't set out to build a RAG application. I set out to solve an annoying problem I kept watching happen.
I work as a senior software developer in healthcare technology in Belfast. A big part of that job is understanding what actually slows them down, and figuring out where software can help. Not what's technically impressive what's genuinely useful.
One thing I kept noticing: a lot of time gets spent navigating documents. Not reading them carefully and thoughtfully — just navigating. Ctrl+F for a patient name. Scrolling to find a medication dosage. Hunting for a follow-up instruction buried in paragraph four of page seven of a discharge summary.
It sounds small. Multiply it by every clinical document, every working day, and it adds up fast.
When I started thinking about RAG as a solution, the first thing I did was slow down and think about what "accuracy" means in a clinical setting — because it means something different here than it does in most software contexts.

The Problem With Most AI Demonstrations in Healthcare
Most AI demos in healthcare go like this: upload a document, ask a question, get a fluent confident answer. It looks impressive. The problem is that fluent and confident doesn't mean accurate. Language models are optimised to produce coherent text. Left to their own devices they'll fill gaps, make inferences, and sometimes just invent things — in a way that reads exactly like a real answer.
In most contexts that's an acceptable tradeoff. In a clinical context it isn't. A patient's discharge medications, their follow-up appointments, their documented allergies — these things need to come from the actual document, not from a model's best guess based on what usually appears in documents like this.
So before I wrote a single line of code I made two decisions:

Temperature 0. No creativity. Deterministic responses only. The model either finds the answer in the document or it says it doesn't know.
Explicit system prompt. The model is told directly: answer only from the provided context. If the answer isn't there, say so clearly. Do not guess.
These aren't complicated decisions. But they're the right ones for this use case, and I see a lot of healthcare AI demos where nobody made them.

How RAG Actually Works (Without the Hype)
RAG stands for Retrieval-Augmented Generation. The idea is straightforward:
Instead of asking a language model a question and hoping it knows the answer from training, you first retrieve relevant sections from your actual documents, then ask the model to answer based only on what you retrieved.
The pipeline looks like this:
Document (PDF)
↓
Extract text
↓
Split into chunks
↓
Embed each chunk as a vector
↓
Store in a vector database

↓ (at query time)

Question
↓
Embed the question as a vector
↓
Find the most similar chunks (semantic search)
↓
Send those chunks + question to the LLM
↓
Get an answer grounded in the document
The key word is grounded. The LLM doesn't know what's in your documents from training — it only knows what you retrieved and passed to it. If the answer isn't in the retrieved chunks, a well-instructed model will tell you that.

Building It: The Decisions That Mattered
Chunking strategy
How you split documents into chunks matters more than most tutorials acknowledge. Too small and you lose context — a medication dosage split from its drug name is useless. Too large and retrieval gets imprecise.
I landed on 500-character chunks with 50-character overlap. The overlap is important — it means the boundary between two chunks always has context from both sides, so you don't lose meaning at the split point.
splitter = RecursiveCharacterTextSplitter(
chunk_size=500,
chunk_overlap=50,
separators=["\n\n", "\n", ". ", " ", ""],
)
The separator hierarchy matters too. We try to split at paragraph boundaries first, then sentence boundaries, then spaces. Splitting mid-sentence is a last resort.
Embedding model
I used OpenAI's text-embedding-3-small. It's fast, cheap, and good enough for document retrieval. For production clinical systems handling complex medical terminology you'd want to evaluate domain-specific embeddings — but for a general-purpose tool this works well.
The system prompt
This is where clinical RAG lives or dies:
system_prompt = (
"You are a helpful assistant that answers questions about clinical documents. "
"Answer only from the provided context. If the answer is not in the context, "
"say so clearly — do not guess or make up information. "
"In a clinical setting, accuracy matters more than completeness."
)
That last sentence — accuracy matters more than completeness — is doing a lot of work. It gives the model permission to say "I don't know" rather than producing a plausible-sounding answer. In my testing, including it made a real difference to the rate of hallucinations on edge cases.

What I Learned Building This
The messy document problem is real. Most RAG tutorials use clean, well-structured PDFs. Clinical documents are not clean or well-structured. Scanned discharge summaries with inconsistent formatting, referral letters with abbreviations that differ between hospitals, guidelines with tables that don't chunk cleanly — all of these degrade retrieval quality. I've started thinking about pre-processing pipelines to handle this better and may add that to the project.
Confidence matters. I added a simple confidence indicator based on how many relevant chunks were retrieved. It's a rough heuristic — more retrieved chunks suggests a more answerable question — but it gives users a signal about how much to trust the response. In a clinical context, knowing when to verify against the source document is as important as the answer itself.
The UI needs to be dead simple. Clinical staff are not developers. If the interface requires any technical knowledge to operate it won't get used. The Streamlit app has three interactions: upload a file, type a question, read the answer. That's it.

The Code
The project is open source on GitHub: github.com/Monika-Sonnadmath/clinical-rag
It has a Python API for developers who want to embed it in their own pipelines, and a Streamlit web app for anyone who just wants to use it directly.
pip install -r requirements.txt
export OPENAI_API_KEY=sk-...
streamlit run app.py
Upload a PDF, ask a question, get an answer. That's the whole thing.

What's Next
A few things I want to add:
• Local LLM support via Ollama — so it works without an API key and keeps documents entirely on-premises. For clinical use cases, data leaving the building is a concern.
• Multi-document querying — ask a question across a folder of documents at once
• Better pre-processing — handling scanned documents with variable quality, which is very much a solved problem in OCR but needs connecting to the retrieval pipeline
If you work in healthcare tech and have thoughts on what would make this more useful, I'd genuinely like to hear from you.