Software and data platforms for healthcare research
For university research groups, academic medical centres, colleges and corporate R&D teams.
Research software is usually built by whoever was available
A study platform starts as a spreadsheet, becomes a database somebody wrote during a doctorate, then has to satisfy an ethics committee and a successor who has never seen it. The fix is deciding early which parts must be built properly and which can stay disposable.
What we build
Study and trial platforms
Participant management, visit scheduling, protocol logic, site access and the audit trail an ethics committee and a monitor will ask for.
Electronic data capture
Structured forms with validation at the point of entry, so queries are resolved as data is collected rather than at the end of the study.
Recruitment and electronic consent
Screening, eligibility, versioned consent forms, withdrawal handled properly, and a record of exactly what each participant agreed to and when.
Research data pipelines
Bringing data together from clinical systems, devices, laboratories and questionnaires into one structure, with provenance kept from source to analysis.
De-identification and safe access
Documented de-identification, linkage keys held separately, and controlled access environments so data can be shared without being copied around.
Device and wearable data for studies
Continuous data from research-grade and consumer devices, reduced to the measures the protocol actually requires.
Reproducible analysis environments
Containerised environments, versioned code and data, and outputs that can be regenerated years later by someone else.
R&D prototyping and feasibility
Short pieces of work that establish whether an idea is technically viable, what it would need, and what it would cost to run at scale.
Research into product
Taking something that works in a study and rebuilding the parts that will not survive real use: security, permissions, data model, integration and support.
Research systems in practice
Screens from research and R&D work, with participant data regenerated as synthetic records.
Who we work with
| Organisation | What they usually need |
|---|---|
| University research groups | A study platform, data capture, and a data pipeline that a successor can pick up after the grant ends |
| Academic medical centres | Linking research data to clinical systems safely, and controlled access environments for collaborators |
| Colleges running health technology programmes | Teaching and project infrastructure, and engineering support for student and faculty builds |
| Corporate R&D teams in healthcare and MedTech | Prototyping, technical feasibility, and moving a working prototype towards a product |
| Public health and population health teams | Data platforms, surveillance reporting and analysis environments |
| Contract research organisations | Data capture, device data handling and integration between study systems |
Research and development work
Some engagements are not a product at all. They establish whether something is possible before anyone commits a budget to it.
Technical feasibility
Can this be built, with the data that exists, at a cost the organisation can carry? A short answer, in writing, with the assumptions stated.
AI and model feasibility
Whether the data supports the idea, what would need collecting, and an honest view when the answer is that it does not.
Prototype to product
What has to be rebuilt before a prototype meets real users, and what can be carried across unchanged.
Technical partner on a bid
Acting as the engineering partner on a grant or tender, including the technical sections and the costings.
Ethics, consent and governance
Research data carries obligations that ordinary healthcare software does not, and they shape the design rather than sitting on top of it.
Approvals you hold
Ethics approval, sponsorship and protocol ownership stay with your institution. We supply the technical documentation your committee asks for.
Consent as a system requirement
Versioned consent, withdrawal, and re-consent when a protocol changes, all recorded so the position for any participant can be reconstructed.
Data sharing agreements
Access controlled by role and institution, every access logged, and the design built around what the agreement actually permits.
Frequently asked questions
Usually, and it helps to talk before the bid is written rather than after. We can scope the technical work, give a costing that survives review, and tell you if the budget will not cover what the protocol needs.
That is the question worth asking at the start. We build documentation, sensible structure and a handover into the work, so the platform can be maintained by your own team or a successor rather than quietly dying with the funding.
Often, through the same FHIR and HL7 routes used for clinical integration, subject to approvals. The technical part is usually easier than the governance part, so both are planned together.
No. We build the software, data pipelines and analysis environments. Study design, statistical analysis and regulatory sponsorship stay with your team or your CRO.
Yes, and it is a common engagement. We start with a review of what exists, then set out what has to be rebuilt for real use and what can be carried across, before anyone commits to a full build.
[CLIENT INPUT REQUIRED: confirm whether you offer this, and on what terms. It is a different commercial arrangement from a research build and should only appear here if it is genuinely available.]
Talk to us about a research or R&D project
Bring the protocol, the data you already hold and the deadline you are working to. We will tell you what is realistic before anyone writes a proposal.