Healthcare

Your study's in field, completions are flat, and the fix depends on which problem you have

The short answer

Software for health research and medical communications usually gets bought to fix one of three problems. Clinicians start your study and don't finish, which is an interface problem. The panel behind the study has outgrown the tools holding it, which is a platform problem. Or neither, in which case no amount of software will move the number.

A study's in field, the panel looked big enough on paper, and the completion count isn't moving. What you should spend money on next depends entirely on why, and the three reasons feel identical from where you're sitting. Telling them apart costs you an afternoon. Getting it wrong costs you a build.

What we do for healthcare

Three problems that look the same from the inside

The first is the interface. People click in and don't finish, and the loss isn't spread evenly across the questionnaire. It bunches on a few screens, usually the same few from one study to the next. A clinician who gave you the gap between two appointments and met one of those screens has given you nothing at all, and that's the cheapest of the three problems to fix.

Worth stating plainly, because the money usually goes somewhere else. A study that lands under target gets the same first diagnosis every time, which is that the panel was too small, so the next round of spend goes into recruitment and the study after that finishes in the same place. Clinicians are harder to survey than almost any other professional group, and it's getting harder. Ericson and colleagues, writing in Family Medicine in 2023, note that studies of physicians typically attain response rates lower than surveys of the general population, with notable declines over recent decades. Every completed response you already earned is expensive, and the places you lose them are usually cheap.

The second problem sits behind the study rather than inside it, and it turns up once the panel outlives the questionnaire. The same clinicians come back for study after study. They're owed money they'd like to see. The permission they gave you has to outlast the study it was given for, someone has to know who's allowed to see whom, and your own coordinators spend their working day in an administrative screen. A survey tool runs a questionnaire and hands you the answers. Almost nothing on that list is a questionnaire.

The third is that neither of those is your constraint. The limit is in the research rather than the software: who is reachable at all, what you're asking people to have a view on, and why anyone would answer. No build touches that, and we'd rather say so than sell around it.

How to tell which one you've got

Start with where people stop rather than with how many you invited. Pull drop-off by question across your last three studies rather than your worst one, because one bad study points at that study and three point at your instrument. If plenty of people start, few finish, and the loss keeps landing in the same places, it's the interface, and your existing platform can usually produce that answer in a morning.

If completion is fine and the pain is all on your side of the glass, it's the platform. That signal isn't in the study data at all, it's in how your team spends its week: a question about one participant that takes an export or a developer to answer, and work that has quietly moved out of the system into files sitting beside it. None of that shows up in a completion rate, which is why it runs for years before anyone puts a cost against it.

If few people start at all, while the ones who do begin are finishing, neither page below is your answer. That's a sampling and research design conversation, and it belongs before a build conversation rather than after one.

Most teams have two of these at once, and the order isn't a matter of taste. The interface is the fastest and the cheapest, and it pays back inside the next study, so it's worth doing first even when a larger build is already coming. The platform problem is the one that compounds: it doesn't cost you a study, it costs you a share of everybody's week, permanently. The third costs nothing to rule out and is the only one that can make the other two beside the point, which is why it goes first in any honest conversation.

Where to go from here

Two pages sit under this one, and they answer different problems.

UX and UI design for healthcare research is the one to read if people start and don't finish. It takes the answering side of the screen seriously, along with the fieldwork team's, and it deals with what happens to a half-answered study when a clinician gets pulled away from it.

Web app development for healthcare research is the one to read when the panel is the asset rather than the instrument. It goes through what a research platform is actually made of once you own the participant relationship, and where the cost sits in each part of it.

If you're still deciding whether to build anything, start with the second one. A good part of it argues for not building, which is the right answer more often than it isn't.

The boundary, and what scoping usually concludes

What we work on is the research side of this sector: studies, panels, participants, and the people running fieldwork. Care delivery isn't ours. Nothing we build holds a patient record, runs a course of treatment or falls under medical device regulation, and nobody here carries a clinical certification. If that's what you're looking for, it isn't work we take, and you'll hear that before a scope exists rather than after.

The other thing worth knowing before you get in touch: the honest output of scoping here is often that you should build less than you came in asking for. That's a better conversation to have at the start than three months into a build.

Related work

Further reading

Common questions

For most teams running studies, no, and keeping what you have is the right call. The useful question isn't whether the tool is good. It's what your organisation actually owns. If that's a series of questionnaires, buy one and get on with the research. If it's a standing relationship with a group of clinicians, the web app page under this one goes into what holding that properly involves.

Some of it always does. Whatever else you're holding, you're holding a professional's identity, their consent record and their payment details, and all of that is personal information. Where a study reaches into patient information the picture changes, and that's a question for a privacy lawyer reading your actual study design rather than something to settle from a landing page.

Yes, with a boundary. A model is good at clustering verbatims, translating, transcribing and drafting a first pass. It shouldn't be the last thing that reads an open-ended answer before a finding leaves the building, and it should never be the only thing standing between a respondent's comment and a safety report. What we'd build is a review surface where every generated line sits next to the verbatims it came from, because a review that's expensive to run stops getting run.

The price is fixed before anything gets built, against a scope written with you, so work running long is our problem rather than a second invoice. What moves the figure is how much of the panel side you want the software to own, and how many of your own rules you want it to enforce rather than leaving to process. A scoping conversation gets you a real number instead of a range.

Related

Want to talk through your situation?

A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.