Reviewer salaries are the line that goes into the budget. The costs that decide whether in-house review works, and whether it lasts, sit below the waterline.
When a team decides to build its own clinical review of health data, the business case usually starts with a simple sum: the number of records that need checking, multiplied by the time each one takes, divided into reviewer salaries. It is a reasonable place to start, and it is almost always too small.
We have seen this from both sides. Clinical review is central to how JondaX works, and we have also spoken with many teams who began building it themselves. The pattern is consistent. Salaries are the visible part of the cost. The work that makes review accurate, consistent and scalable sits underneath, and it tends to surface only after the team is live and the volumes start to grow.
None of this means building in-house is the wrong choice. For some organisations it is the right one. The aim of this guide is to help you see the whole cost before you commit, whether you are a digital health startup, a laboratory, a hospital or a pharma or insurer programme. There is an estimator further down so you can put your own numbers against each cost.
The salary line is real. It is just the smallest part of what a review team needs to work well.
Clinical judgement and data skills in the same person
A good reviewer needs to recognise when a value makes no clinical sense and also be comfortable working methodically through structured data, units and code sets. People with both are scarce. Clinicians often prefer clinical roles, and data staff without clinical training can miss errors that look tidy on screen. Finding, interviewing, onboarding and keeping the right people takes far longer than a salary benchmark suggests.
Often missed: Recruitment time, onboarding before a new reviewer is productive, and the cost of turnover when trained reviewers move on.
Ask yourself: How long would it take us to hire and fully train our first three reviewers, and what happens to quality if one leaves?
The rules reviewers follow, kept current
Reviewers need written guidance for each data type and market: how to handle a result with a missing unit, an unfamiliar local test name, a handwritten correction on a discharge summary or a medication list with a brand name from another country. That guidance has to be written by someone clinically senior, tested, and updated whenever a new source, format or language arrives.
Often missed: A clinical lead's time to own the guidance, and the retraining needed every time it changes.
Ask yourself: Who will own our review guidance, and how will we know every reviewer is following the latest version?
The workspace reviewers actually use
Reviewers cannot work efficiently from a spreadsheet and a folder of PDFs. They need a queue that prioritises what matters, a view that puts the source document beside the extracted values, a way to record what they changed and why, and an audit trail behind every decision. Someone has to design, build, secure and maintain all of it.
Often missed: Engineering time to build the tooling, and the ongoing maintenance as formats, data types and workflows change.
Ask yourself: Do we have engineers who can build and maintain a review workspace without slowing down our core product?
Quality assurance for the people doing quality assurance
Two reviewers can make different decisions on the same record, and people checking AI output tend to accept what the system suggests, particularly when queues are long. This is known as automation bias. Keeping review reliable means second-checking a share of decisions, measuring consistency between reviewers and watching workload and override rates.
Often missed: The extra review time for second checks, and someone senior to look at the patterns and act on them.
Ask yourself: How would we know if our reviewers were drifting apart, or approving too much too quickly?
Making each correction count more than once
This is the cost most in-house teams never reach. Without a feedback loop, a reviewer fixes a record and the same local test name or report layout is flagged again the next day. Turning corrections into updated mappings, local test names and ontology, with clinical sign-off, is real engineering and clinical work. Without it, review effort keeps growing in step with volume.
Often missed: The build itself, and the governance needed so that a correction never introduces a new error at scale.
Ask yourself: When a reviewer corrects something today, what will stop the same issue reaching them again tomorrow?
New sources, new languages and the days people are away
A team sized for today's volume is under-sized for tomorrow's. Each new laboratory, clinic or market brings its own formats, units, languages and test names. Turnaround commitments do not pause for annual leave, illness, public holidays or a sudden spike in volume, so in-house teams need spare capacity that sits idle on quiet days.
Often missed: A buffer for leave and peaks, and language or specialty coverage that is only needed some of the time.
Ask yourself: What happens to our turnaround if volume doubles next quarter, or two reviewers are away in the same week?
The quiet costs of handling health data with AI
Every person who sees health data needs access controls, confidentiality obligations and logging, and some markets require data to be processed in country. Teams building quickly sometimes send health data to general-purpose AI models without the right agreements or safeguards in place. Others find their model costs climbing as prompts grow and large models are re-run on every document, often for errors a cheaper check could have caught.
Often missed: Security and privacy work for the review process itself, and token spend that grows faster than volume.
Ask yourself: Could we show a regulator exactly where health data goes during review, and do we know our model cost per usable record?
The cost nobody puts in a spreadsheet. Every hour your clinicians spend writing review guidance, and every sprint your engineers spend on review tooling, is time not spent on the product or service your organisation exists to deliver. For many teams this is the largest cost of all.
Building your own review team can be the right decision, and we would rather you make it with a clear view than avoid it. These are the patterns we see on each side.
Clinical review is the part of our work we are proudest of, because it is the part that is hardest to get right. It is also the part that most often pulls teams away from what they set out to build. Two results from organisations we work with show what changes when that burden moves.
It depends on your volumes, the share of records that need review, review time and local salaries. Reviewer salaries are usually the smaller part of the first-year cost. Recruitment, guidance and training, review tooling, quality checks on reviewers, a feedback loop, capacity for leave and peaks, and compliance and model spend often add more. The estimator in this guide lets you use your own figures.
The most commonly missed costs are hiring people with both clinical and data skills, a clinical lead to own review guidance, engineering time for review tooling, second checks on reviewer decisions, the feedback loop that turns corrections into lasting improvements, spare capacity for leave and volume peaks, and security, compliance and token spend.
Building in-house tends to fit organisations with very high volumes of a narrow, stable set of data types, an existing clinical operations team with spare senior capacity, review as part of the product they sell, and engineering capacity to build and maintain tooling and a feedback loop.
Without a feedback loop, a reviewer fixes one record and the same local test name or report layout is flagged again the next day, so review effort grows with volume. A feedback loop turns each correction, after clinical sign-off, into updated mappings so the same issue is not flagged twice.
AI can do most of the extraction and structuring work, but for health data that informs care, claims or research, clinically trained reviewers are still needed for records the system flags. The goal is a design where AI handles the volume and people focus on the exceptions that matter.
