A study in field, a payment queue and a question somebody wants reworded: web app development for healthcare research

Four products sharing one login

A research platform for healthcare professionals gets talked about as one thing, because it arrives in one sentence. Usually "we need to rebuild our survey tool." Then it gets estimated as one thing, and that's where the number goes wrong.

The instrument is the part everyone pictures, and the part that behaves most like solved software. Render a question, branch on an answer, save progress, handle a phone. Worth doing properly, because it decides whether anyone finishes. Not where a build gets into trouble.

Trouble sits in the three surfaces behind it. The money a participant is owed. The record of who they are and who's allowed to see it. And the administrative view your own team lives in, specified last and used most.

An instrument in field is a schema, not content

The most expensive assumption in this category is that a questionnaire is content. It behaves like content right up until the first response lands, and after that it behaves like a schema with a publishing interface attached.

Change a question once people have answered it and you've created two groups who answered different questions, plus one column that pretends they didn't. Reword a scale label, drop an option, make an optional item required, and the data either side of that edit stops being comparable. Nobody notices at the time. The platform accepted the edit and the chart still renders.

So the requirement isn't "don't edit a live study." That rule gets broken, and it should be, because real studies need corrections: a typo, a broken skip pattern, an option nobody can select. The requirement is that every stored response carries the version it was collected under, and that analysis can separate versions without a developer.

In practice the instrument is a versioned object, a response points at a version rather than at a study, and the interface makes the consequence visible at the moment somebody clicks edit. Not in a warning nobody reads. In the screen: this study is in field, this change creates version three, here are the responses that stay on version two.

Translation is a version too, and it's the one that drifts. A study running in English and French is two instruments that have to stay in step, and a correction reaching one and not the other produces exactly the split you were trying to prevent.

The payment ledger and the response ledger are two systems

This is the part underestimated at scoping in nearly every build here, because it looks like a feature. Pay the participant. One row, one status field, done.

It isn't one row, because paid and responded are independent facts. Someone can be paid and not respond, which happens by design on an unconditional incentive and by accident on every other kind. Someone can respond and not be payable: screened out, at an institution that doesn't permit personal payments to staff, took the charity option, or sitting in a failed payment waiting on a retry. Force all of that through one status column and it grows values until nobody can say what any of them mean.

A second force pulls the other way. Responses often want to be unlinked from the person who gave them, while a payment record is the most identified thing in your system: a legal name, a payment method, a tax status, an address. The shape that satisfies both is a participation record in the middle, holding the fact that this person was invited and reached this outcome, with the responses on one side of it and the money on the other. What you're avoiding is a direct join from a bank detail to a verbatim.

The money side also outlives the research side by years. In Canada a payer reporting fees for services issues a T4A once total payments to a recipient pass five hundred dollars in a calendar year, non-residents run on a different slip with withholding attached, and the records behind all of it are kept six years from the end of the last tax year they relate to. That's a retention requirement on the payment ledger specifically, and it doesn't care that the study closed eighteen months ago.

1. 1. Model paid and completed separately, then write the reconciliation first

   Two ledgers, one participation record joining them, and a query listing every case where the two disagree. Write that query before the payment screens exist, because it forces the states into the open while they're still cheap to name.

2. 2. Define completion precisely enough to pay against

   Screened out at question three, dropped at question forty, quota full after answering everything, submitted twice from two devices. Each is a different payment outcome with a participant who believes they finished. Write the definitions down and show the resulting status in words, or your support inbox arbitrates it one email at a time.

3. 3. Give the participant the same ledger finance sees

   A running balance, a transaction history with dates, a visible pending state and a plain reason for it. Most support load in a panel is one question in different tones, which is where is my money, and it's a trust problem rather than a bug.

4. 4. Decide now what leaving the panel does to the payment record

   Someone who wants out of your panel is entitled to be out of it. Your tax and reconciliation trail isn't theirs to erase, and you've just seen how long it has to live. That makes withdrawal a field-level operation rather than a row deletion. Designed in, it's an afternoon. Retrofitted, it's a migration nobody wants to run.

Permissions are the shape of the product, not a settings page

Ask how many roles a research platform needs and you'll be told a small number. Build one and you'll find more, and most of the difference isn't seniority. It's which study somebody is attached to and what state that study is in.

Some roles are study-scoped: whoever wrote the instrument, the field team, the client who commissioned it, an observer watching a session, a finance user who never sees a response but needs the whole payment side. Others are panel-scoped: recruiters working across studies, support staff, administrators. Almost none of them want the same slice of the same record.

The line carrying most of the weight is between the identity layer and the response layer. Who someone is, their specialty, their licence and their contact details is one thing. What they said is another. Plenty of roles need exactly one of the two, and the join between them is the thing to be deliberate about, because it's the join a commercial team should never have. When that goes wrong it's almost never a decision. It's a CRM sync that mapped the panel record into a view a sales-facing user can read.

Most market research with clinicians collects no personal health information at all, because the participant is the professional and their own opinions aren't a patient's record. Where a study does touch patient information, the rules are provincial. In Ontario that's the Personal Health Information Protection Act, 2004, whose section 44 governs disclosure to a researcher and requires a written research plan and a research ethics board approval. Approvals expire, and they get renewed late. In PHIPA Decision 243, published in 2024, Ontario's Information and Privacy Commissioner found that a university had collected personal health information without authorization during two periods when its research ethics board approval had lapsed, contrary to section 44(1)(a).

Read that as a build instruction rather than a policy. The approval window is a date on the study and the collection endpoint checks it. It's the same state machine that governs invitations, instrument edits and payment release, which is the argument for building one state machine instead of three.

The free-text box is one field with a workflow attached

Nearly everything useful in a study with clinicians comes out of the long open-ended questions. The scaled items give you the shape. The verbatims tell you why, and they're what gets quoted in the readout.

They're also the only field a participant can put anything into, and in this category anything includes sentences that start a process on the sponsor's side. A respondent explaining why they moved someone off a therapy can name a side effect. If the company that commissioned the study holds the marketing authorisation for that product, that sentence can be an adverse event, and adverse event reporting runs on short deadlines that reach you through your client agreement.

Defining the obligation is the research team's job. The build question is narrower and far more answerable: what does your platform do between the moment somebody types that sentence and the moment a human reads it?

If the honest answer is nothing until analysis three weeks from now, that's a decision. It's just one nobody made on purpose. The alternatives are cheap to build and expensive to retrofit. Free text lands in a queue on submission. A screening pass flags a subset for a person to clear. A per-study switch turns the path on only where a product is in scope. What matters is that the design names a moment, because the moment exists whether or not anyone named it.

Two more things follow from free text being unbounded input. In a Canadian panel it arrives in more than one language, so translation belongs in the pipeline rather than in analysis. And it occasionally contains something that has to come out: a patient identifier a clinician typed without thinking, a name, a site. Redaction has to be possible without destroying the response, which means a verbatim needs revision history rather than being a text column somebody overwrites.

The admin dashboard is where your operating cost lives

Every scope for a platform like this puts the participant experience first and the admin dashboard last, often as a single line near the bottom reading "admin panel." Then it ships, and your research and support teams spend their working day inside that line. Every hour a coordinator spends exporting a list or answering an email about a balance is cost the platform was supposed to remove, and none of it shows up in the participant screens everybody reviewed.

1. 1. Build the study lifecycle, not a study form

   Draft, approved, in field, paused, closed, archived. For each state write down what it permits: editing the instrument, sending invitations, accepting submissions, releasing payment, exporting. Most of what gets called compliance behaviour turns out to be a state check.

2. 2. Make the participant record answerable

   Support gets asked three questions: was I invited to that, why was I screened out, and where is my payment. A view that answers all three without a developer running a query is worth more than most of the features above it in the scope.

3. 3. Treat a referral as a payable event with an attribution rule

   Referrals pay one person for something a second person did, so they need an attribution window, a definition of what qualifies, and a cap. An incentive to bring colleagues in is also an incentive to bring in colleagues who don't exist. A professional panel has a check the consumer world doesn't, since specialty and licence are verifiable, so put that check before the payout.

4. 4. Design the export before the dashboard

   The output that leaves the platform is a file, and it goes to a client who reads it for a year. It should carry the instrument version, the field dates and the question base beside every count. Charts inside your admin panel get looked at once.

When a survey product is the right answer and a build isn't

Most organisations running research with healthcare professionals should not build this, and that's worth saying on a page that exists to sell the build.

If what you need is to field a questionnaire, a general survey product does it, and does it better than a first custom build will. Question types, branching, accessibility, export formats and a decade of edge cases are somebody else's finished work. Add a specialist panel provider for recruitment and you've covered most study-shaped work without writing anything. Choosing that isn't a lack of ambition.

Building starts to make sense when the asset is the panel rather than the instrument. Three situations, and they share a shape.

1. 1. The relationship recurs and has to persist

   The same clinicians across many studies, balances that carry over, consent that survives from one project to the next, a profile that gets richer every time somebody answers. Survey tools model a response. You need to model a member, and that difference reaches every table in the system.

2. 2. The money surface is part of the product

   Balances, withdrawals, referral payouts, statements, and a finance trail that holds up years later. This is the piece nobody bolts onto a survey tool successfully. If your incentive handling currently lives in a spreadsheet next to the survey product, the spreadsheet is the product you need.

3. 3. You're selling access rather than running your own studies

   Multiple clients, each seeing only their own studies, each with their own observers and their own export. That's multi-tenancy, and it's an architecture decision made at the beginning rather than a permission setting added later.

What the field has learned, and what we don't build

Two findings from the published literature shape how this gets built. The Cochrane methodology review of questionnaire response, covering 670 postal and 88 electronic trials, finds unconditional incentives ahead of conditional ones at an odds ratio of 1.53. That means paying before somebody answers rather than after, which is a ledger requirement before it's a policy: you're issuing money to people who may never respond, so your payment records and your response records have to be able to disagree.

The second is that the same review finds administering an electronic questionnaire by computer rather than smartphone raises the odds of response, at an odds ratio of 1.62. Read it as directional rather than as proof that mobile can't work. It's general questionnaire methodology rather than physician-specific, and it says a small screen costs you something you have to design back.

The instrument, the incentive ledger, the permissions model and the admin dashboard are the four surfaces we build.

What we don't build, plainly: clinical software. Not electronic medical records, not patient care systems, not regulated medical devices, and we hold no clinical certifications. If what you need sits inside care delivery, we're the wrong firm for it.

We quote a fixed cost against a scope defined together, so an overrun is ours rather than yours. Which is exactly why we'd tell you during scoping that half of what you asked for should wait.