For research, academic medicine and life sciences
Digital Scientists builds clinical trial and research software for academic medical centers, research teams and life sciences companies. We don't replace a CTMS or an EDC; buy a validated one. We build what sits around them: participant matching, research data platforms, evidence extraction and the integrations that tie them together. For Duke, we built one platform that maps community programs against social drivers of health data and connects to Duke single sign-on and the Scholars@Duke directory. Most teams start with a Blueprint: 4 to 6 weeks to agree scope, architecture and a build plan.
Updated
Mapping, matching, grant management and analytics on Duke's platform
Duke systems connected: single sign-on, Scholars@Duke and Galaxy Digital
Apps on Intent Solutions' adherence platform, with trial data export
Patients on NeverAlone, a platform we built and still run
Should we buy clinical trial software or build it?
Buy the system of record. Build the parts that make your research different. A CTMS, an EDC and eConsent are mature, validated products, and rebuilding them rarely pays off. The work that sets a research program apart sits around them, and that's what we build.
Most people searching for clinical trial software want a product to license. That's the right call for study management and data capture. Where teams get stuck is everything the product doesn't do: finding eligible participants in the EHR, combining study data with the rest of the institution's data, pulling structured evidence out of documents, and connecting systems that were never meant to talk. We answer the build, buy or partner question with you before anyone writes code, the way we did for Duke.
What to buy and what to build
| Need | Our advice | What we do |
|---|---|---|
| Study management (CTMS) | Buy | Integrate it with your EHR, data warehouse and reporting |
| Electronic data capture (EDC) | Buy a validated system | Feed it, extract from it and build the reporting around it |
| eConsent and participant portals | Buy, unless the study design is unusual | Build participant-facing apps when off-the-shelf won't fit the protocol |
| Participant matching and feasibility | Usually build | Screen EHR data against eligibility criteria for coordinator review |
| Research data platforms | Build | Data models, APIs, dashboards and maps across siloed sources |
| Evidence extraction | Build | Pull structured findings out of labels, papers and clinical notes |
Common patterns, not rules. The Blueprint settles it for your program.
What does a research data platform look like in practice?
At Duke, it was one platform for research and community partnerships. Partner program data sat in different places and formats across Duke University and Duke Health, so nobody could measure community impact. We built one place for students, researchers, faculty and community members.
We started with an alignment workshop on the product vision, the users and the priorities. A landscape analysis of mapping and data visualization tools gave Duke a build, buy or partner recommendation and a good, better, best path to an MVP. The solution architecture became the roadmap Duke's own technical team worked from. Then we designed, prototyped and built it in React and Ruby on Rails.
The platform maps Duke's initiatives against social drivers of health data from the US Census Bureau and public health sources, down to county and census tract. It matches organizations and people to events, causes and volunteer work, runs a grant portal for grant managers and applicants, and gives administrators one source of truth for the partner community. It connects to Duke single sign-on, the Scholars@Duke directory and Galaxy Digital volunteer management. Read the Duke case study.
Mapping, matching, grant management and analytics on one platform
Social drivers of health data mapped to county and census-tract level
Single sign-on and the Scholars@Duke directory connected
What research software do academic and life sciences teams need built?
Usually one of five things, and none of them is a new CTMS. Each one fills a gap between the products you license and the way your research actually runs.
Participant matching
Coordinators screen clinic schedules and problem lists by hand and miss eligible patients in other departments. Software screens EHR data against trial criteria and puts candidates in front of a coordinator to confirm.
Research data platforms
Study, registry, community and operational data sit in different systems and formats. A deliberate data model, an API and the right dashboards turn them into one source of truth, as we did for Duke.
Evidence extraction
Findings live in drug labels, papers and clinical notes. Extraction pulls them into structured, reviewable data your team can query and compare.
Trial data capture outside the EDC
Devices, apps and home measurements produce data your EDC never sees. For Intent Solutions we built the apps and the admin portal where research teams set up trial programs, regimens and participants, then export adherence data for analysis.
Grant-funded tools that outlive the grant
Software built for an award still needs an owner, support and a plan when the funding period ends.
How does software find eligible trial participants in EHR data?
It screens your patient population against each trial's eligibility criteria and hands coordinators a short list to verify. Coordinators move from chart hunting to match review. The AI suggests; a person decides who gets approached.
Matching is a data problem first. Inclusion and exclusion criteria have to be turned into structured rules, the EHR data has to be reachable, and the answers often sit in free-text notes rather than coded fields. We pick the method per criterion: rules where the data is coded, language models where it's in notes, and human review for every match. Our clinical trial patient matching guide lays out the full framework, including when manual screening is still enough.
Matching only works if coordinators trust it. Every candidate comes with the evidence behind the match, and every rejection teaches the rules something.
How we build participant matching
| Step | What happens | Who's involved |
|---|---|---|
| Criteria | Turn each trial's inclusion and exclusion criteria into structured, testable rules | PI, research coordinators, our team |
| Data | Reach the EHR data through APIs, a standard interface or a reliable export, under your data governance | Research informatics, IT, our team |
| Screening | Rules for coded fields; language models for criteria buried in notes | Our team |
| Review | Coordinators confirm or reject each candidate, with the evidence shown | Research coordinators |
| Measure | Track matches found, confirmed and enrolled, and tune the rules | Research operations, our team |
We integrate with any system that has an API, a standard interface or a reliable export.
Can software pull structured evidence out of research documents?
Yes, when a person stays in the loop. Extraction turns tables and findings buried in documents into structured data your team can search, compare and cite. Every extracted value links back to its source so a reviewer can check it.
Take drug efficacy. FDA structured product labels carry clinical study tables, but every label formats them differently. An extraction pipeline parses the label, pulls the study tables, and normalizes outcomes and conditions against RxNorm, SNOMED CT and UMLS so drugs for the same condition can be compared side by side. The same approach works for published papers, protocols and clinical notes. We run language models inside your own cloud account, test extraction against documents your experts have already reviewed, and keep the reviewer's corrections as the record.
Regulatory documents
FDA structured product labels, clinical study tables
Terminologies
RxNorm and RxClass, SNOMED CT, UMLS, ICD-10
Literature and protocols
Published studies, trial protocols, eligibility criteria
Clinical data
EHR records and clinical notes, under your data governance
Output
Structured, source-linked data for review, search and comparison
Where should a research team start with us?
Most start with a Blueprint. In 4 to 6 weeks we agree what gets built, what gets bought, the architecture and the plan, and you own the result whether or not we build it.
For Duke, that first phase was an alignment workshop, a landscape analysis, a build or buy recommendation and a solution architecture. Then we designed and built. If one piece is risky, like matching against criteria hidden in notes, we test it on real data before you fund the full build.
After launch, we support the platforms we build with L2 and L3 support, alongside your IT and research computing teams, or hand them to your own people on a build-operate-transfer plan.
Common starting points
| Starting point | Time | You get |
|---|---|---|
| Blueprint | 4 to 6 weeks | Users, workflows, build or buy decisions, architecture, data plan and a build plan |
| MVP | 8 to 16 weeks | A working first release with real users, such as a matching pilot for one study |
| Full build | 3 to 12 months | The production platform, integrations and reporting |
| Production support | Ongoing | L2 and L3 support for platforms we built, or a build-operate-transfer plan to your team |
Common starting points, not rules. See ways to start.
Research work we've delivered
Duke Health
One platform for community impact
Social drivers of health mapping, partner matching, grant management and analytics for Duke's students, researchers, faculty and community members, connected to Duke single sign-on and Scholars@Duke.
See the work
Intent Solutions
Adherence data for clinical trials
A biometric, Bluetooth-connected medication dispenser with patient, pharmacist and admin apps. Research teams set up trial programs and participants and export adherence data.
See the workTrusted by healthcare leaders.
“The team at Digital Scientists was a huge help in not only developing our analytics platform, but understanding the competitive space and defining our true value proposition for our customers.”
Justin Davis
CEO, Congruity Health
“I have worked with many technology teams during my career, and Digital Scientists is one of the best. They take the time to understand the customers' needs, deliver innovative solutions, are always professional, and work with your team as a true partner to achieve success.”
Amy Severino
Chief Innovation Officer, NeverAlone
Related work
Clinical trial patient matching AI guide
The framework for screening EHR data against trial criteria.
Clinical trial patient matching AI guide →Health systems
Research, community and virtual care platforms for health systems and academic medicine.
Health systems →Data engineering and analytics
Data models, pipelines and dashboards across siloed clinical and research data.
Data engineering and analytics →AI development
AI with rules attached, run inside your own cloud account.
AI development →EHR integration
How we connect new software to the EHR and the systems around it.
EHR integration →Ways to start
Blueprints, MVPs and the other common first steps.
Ways to start →Latest thinking for research teams
Questions research teams ask
Can you work with our IRB requirements?
Yes. We build to the approved protocol and your IRB's conditions: minimum necessary data, de-identified or limited data sets where the protocol allows, role-based access and audit logs. We provide the data flow diagrams and security documentation your IRB and security office ask for. Your investigators own the submission; we make sure the software matches what was approved.
Do you build EDC systems?
No. Electronic data capture is a mature, validated product category, and we'd tell you to license one. We build the software around it: participant-facing apps, data feeds into and out of the EDC, participant matching, research data platforms and the reporting your team needs.
Can you support NIH-funded projects?
Yes. We scope the build to the award's aims and milestones, document the work for progress reporting, and plan who runs the software when the funding period ends: our team with L2 and L3 support, or your own team on a build-operate-transfer plan.
Will you replace our CTMS?
No. Keep the CTMS you have. We connect it to your EHR, data warehouse and reporting, and build the tools it doesn't include, such as participant matching or a research data platform.
How do you handle PHI and research data security?
We sign a BAA before we touch PHI and follow your data use agreements. Our security plan is mapped to NIST CSF 2.0, each client gets a security addendum, and AI runs inside your own cloud account. See security and PHI.
Who owns the code and the data?
You do. You own the code, the IP and the data. Repositories and cloud accounts sit in your name or are ready to transfer.
Talk it over
Tell us what you are trying to do. A senior person from our Atlanta team replies within one business day, and you can book a 30-minute call right after you send this.
- We tell you if we're the right fit, and if we're not, who is.
- Most work starts small, so you see how we work before you commit to more.
- We sign a BAA before we touch patient data.