The software behind a clinical study
A study collects structured data from participants across sites and geographies, pulls in results from laboratories, applies rules to catch inconsistencies, and follows up with people on a schedule. We build the systems that do that work, and the automation that keeps them maintainable as a protocol changes.
What does a study platform actually have to do?
A study has to do several things at once. It has to collect structured data from participants across sites and geographies, bring in laboratory results, catch inconsistencies while they can still be fixed, and keep participants on schedule.
None of those pieces is especially difficult on its own. The difficulty is that a protocol changes. Every amendment eventually reaches the software. If changing a questionnaire takes a week of rebuilding forms, the study team starts working around the software instead of improving the protocol. Precision medicine and companion diagnostic programmes add another layer because biomarker data can sit at the centre of enrolment and follow up, so the data needs to remain both usable and traceable.
Where does the time actually go?
A lot of the time goes into transcription. Research teams often define questionnaires in spreadsheets because that is where the protocol gets worked out. Production needs versioned, validated, renderable forms, so someone ends up copying the questions, response options, and skip logic into a form builder.
That manual step takes time and creates another place for errors to creep in. The problem gets worse with every amendment because the same work has to be repeated.
The way out is to stop re keying it. If the research team's own definition is treated as the source of truth and read by the platform rather than copied into it, transcription stops being a step at all. What follows from that is a form the platform holds as data rather than as code, which means it can be versioned, compared between revisions, and audited, and it means adding or changing a question does not require a release.
What do we build?
Data capture and the pipeline behind it. Getting a questionnaire from the form the research team authored it in to a production electronic case report form, with the validation rules, conditional logic, and connections to the rest of the study intact, and without a manual rebuild each time the protocol moves.
The rule layer. Study validation is not just checking individual fields. It is also about consistency across answers, across time, and against what is medically possible. Applicability keeps questions that only apply to certain participants out of the wrong forms. Chronology prevents a follow up from appearing before the procedure it follows, or an onset date from coming after a resolution date. Calendar rules need to handle leap years and partial dates. Cross form checks catch contradictions between instruments while the participant can still be contacted.
Workflow. A result can determine what happens next: which instrument is raised, which pathway a participant enters, or whether another sample is needed. Putting that logic in the platform instead of a coordinator's checklist makes it consistent across sites. Forms and alerts can be generated from the clinical data, with the trigger condition recorded for review. Scheduled email follow up can also keep visit windows on track without someone managing them manually.
Why do the rules belong in the database?
Because data can arrive through more than one path. Form validation protects the data coming through that form. A database trigger or constraint applies regardless of which client or import route created the record. That matters once a study has laboratory feeds, bulk imports, or more than one front end.
Both layers have a role. Form validation gives the participant immediate feedback, where many errors are easiest to fix. The database layer protects the dataset regardless of where the data came from.
What about laboratory data and clinical systems?
A study rarely operates on its own. Laboratory results need to reach participant records, and study data often has to move between the study platform and the clinical systems already in use.
That usually means two kinds of integration. HL7 FHIR for exchange with modern systems, where a result can arrive as a structured resource rather than a file someone uploads. And EHR integration when the study needs to work with a health system's own record, including its scopes, consent model, and approvals.
Getting the result into the platform is only part of the job. The useful part is what happens next. The result is attached to the participant record, the rules run, and the next instrument or alert is raised without someone having to make that decision manually.
What does an engagement usually look like?
A study team has a platform that is difficult to change. We rebuild the form pipeline around the research team's definition as the source of truth, so an amendment can go through a short automated process.
A programme is being built from the start. We build the capture layer, rules, and workflow together because adding those rules later is much harder once the platform already contains study data.
A study needs to exchange data with clinical systems. We build the integration over FHIR or the EHR's own interfaces so laboratory and clinical data can reach participant records without a manual step.
Electronic data capture and eCRF automation
Turning a research team's questionnaire design into production electronic case report forms without a manual rebuild every time the protocol moves.
Study rules and workflow automation
The validation logic, conditional branching, laboratory data handling, and participant follow up that make study data usable rather than just collected.
HL7 v2, CCDA and report exports from an oncology EHR parsed, keyed to one master patient index and loaded into PostgreSQL on a schedule, for a healthcare data company.
Read the case study →Questions people ask
Can you work from our existing questionnaire spreadsheets?
Usually yes, and that is the preferred route. Whatever the research team already authors in becomes the source of truth and is read by the platform rather than re entered by hand, so the study team does not have to learn another authoring tool.
What changes once the form pipeline is automated?
Deploying a revised questionnaire becomes a much smaller task. The bigger benefit is consistency. The generated form follows its definition, and the definition is what stays under version control, so manual transcription is no longer part of the process.
Do you build a new platform or work on ours?
Both are possible. The form pipeline can often be rebuilt underneath an existing platform, which is usually the less disruptive option. For a new study, building the capture layer, rules, and workflow together is usually better because those rules are harder to add once data is already there.
Where should validation rules live?
In both. Form validation gives participants immediate feedback. Database triggers and constraints apply regardless of which client or import path the data came through, which protects the dataset rather than only the form.
Can the platform act on a laboratory result automatically?
Yes. This is often where the workflow becomes useful. An incoming result can raise a new instrument, move a participant into a different pathway, request another sample, or trigger scheduled follow up. The condition is recorded and applied the same way for each participant.
Does this fall under validation?
It can, depending on the study and how the system is being used. Where validation is required, our regulatory and validation team works alongside the build rather than leaving validation until the end.
Running a study on software that is difficult to change?
Tell us what the amendment process looks like today and we can tell you what can be automated.
Start a conversation