Software for clinical studies
A clinical study collects data from participants, laboratories and other clinical systems, often at several sites. We build the software that captures that data and applies the study rules. It also keeps the workflow running when the protocol changes.
Study data and workflow requirements
The software has to collect structured data from participants at different sites, bring in laboratory results, catch inconsistencies while they can still be fixed, and keep participants on schedule.
The individual pieces are familiar. The engineering work adds up through amendments: a protocol change can mean changing forms, rules, integrations and workflows, and if the questionnaire has to be rebuilt by hand, that work repeats with every amendment. Precision medicine and companion diagnostic programmes bring biomarker data with them. That data may determine enrolment or follow up, so its lineage has to stay clear as it moves through the study.
Questionnaire pipeline
Research teams often define questionnaires in spreadsheets because that is where the protocol gets worked out. The production system still needs versioned and validated forms, so someone copies the questions, response options, and skip logic into a form builder. That copy is engineering work, but it does not add anything to the study.
Each copy is also another chance for an error to get in.
We can have the platform read the questionnaire the research team maintains, so nothing gets copied into another tool. The form is then stored as data, not code, which means it can be versioned and audited and a change to a question needs no software release.
Capture, rules and workflow
Electronic data capture. We take the research team's questionnaire and turn it into a production electronic case report form. The validation rules, conditional logic, and study connections are carried into the generated form.
The rule layer. Study validation checks individual fields, and also consistency between answers, over time and against what is medically possible. Applicability keeps questions that only apply to certain participants out of the wrong forms. Chronology stops a follow up from appearing before the procedure it follows, or an onset date from coming after a resolution date. Calendar rules have to handle leap years and partial dates. Cross form checks catch contradictions between instruments while the participant can still be contacted, and the comparison is detailed enough to tell a real discrepancy from a difference in how a value was entered.
Workflow. A result can decide what happens next. That might be which instrument is raised, which pathway a participant enters or whether another sample is needed. With that logic in the platform, the decision comes off the coordinator's checklist and is applied the same way at every site. Forms and alerts can be generated from the clinical data, with the trigger condition recorded for review, and scheduled email follow up can keep visit windows on track without someone managing them manually.
Validation in the database
Data can arrive by more than one route. Form validation only protects what comes through the form, while a database trigger or constraint applies to every record, whichever client or import created it. A study with laboratory feeds, bulk imports or more than one front end needs that second layer.
Both layers are needed. The form catches errors while the participant is entering the data, and database constraints and triggers protect the dataset once it arrives.
Laboratory and EHR integration
Laboratory results have to reach the participant record, and study data has to move between the study platform and the clinical systems already in use.
We work with HL7 FHIR or the interfaces the EHR exposes. A FHIR result arrives as a structured resource, not an uploaded file, and the source of the result stays with the record. An EHR connection has to follow the health system's scopes, consent model and approvals.
Once a result is attached to the participant record, the study rules can act on it. If the same data also arrives by another route, there is a reconciliation point between the two.
Typical projects
When a study team has a platform that is hard to change, we can put the research team's questionnaire back at the centre of the form pipeline. An amendment then follows the same process, without anyone rebuilding the forms by hand.
For a programme starting from scratch, we build the capture layer, rules and workflow together.
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
Validation logic, conditional branching, laboratory data handling and participant follow up, with enough detail kept in the record to show where a value came from and how it was handled.
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 →Common questions
Can you work from our existing questionnaire spreadsheets?
Usually. We start from the questionnaire the research team already maintains, and the platform reads that definition directly, so nobody types it again into another authoring tool.
What changes once the form pipeline is automated?
A revised questionnaire is deployed from the same definition, which stays under version control, and the generated form follows it. There is no second copy to reconcile.
Do you build a new platform or work on ours?
Both. On an existing platform we can often replace the form pipeline and leave the rest of the system alone. For a new study it is usually better to build the capture layer, rules and workflow together, because rules are harder to add once data is already there.
Where should validation rules live?
In the form and in the database. Form validation gives participants immediate feedback, and database triggers and constraints protect the whole dataset no matter which client or import path the data came through.
Can the platform act on a laboratory result automatically?
Yes. An incoming result can raise a new instrument, move a participant to a different pathway, request another sample or start scheduled follow up. The condition that caused it is recorded with the workflow and applied the same way for every 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 is involved in the build from the start.
Study software that is hard to change
Show us how an amendment moves through the study today, and we can point out which parts could be automated.
Start a conversation