Sylva Health Oliver Backend, HIPAA-compliant clinical-trial recruitment platform

Project Overview

Sylva Health needed a backend that could run clinical-trial recruitment under HIPAA. We built the core service that handles patient intake, consent, and trial matching as one platform. FastAPI and PostgreSQL hold the data and logic, GPT-4 reads free-text patient history, and Dropbox Sign captures legal consent.

Client Background

Sylva Health is a HealthTech company working with clinical-trial sponsors. Their team coordinates patient intake and enrollment for trials that have strict eligibility rules. Before this project, much of the work lived in spreadsheets and email threads. That setup carried real HIPAA risk and made it hard to scale beyond a small number of trials.

The Problem

Clinical-trial recruitment is not just an admin task. It is a regulated workflow with high stakes. The team needed to take in patient information, ask the right follow-up questions, capture consent in a legally valid way, and then match each patient to the right trials. Doing this across spreadsheets meant slow handoffs, duplicate data entry, and a constant risk of mishandling protected health information. The medical team wanted to spend their time on patients, not on chasing paperwork.

Challenges

• HIPAA compliance had to be designed in from the start, not patched on later.
• Intake questions vary by trial and by prior answers, so a static form was not enough.
• Consent had to be collected with a real e-signature workflow and a clean audit trail.
• Matching had to work against structured criteria and against free-text medical history.
• The system had to fit into the team's existing process without forcing a full retraining.

Our Approach

We started by mapping the recruitment workflow with the Sylva Health team. We identified where data entered the system, where consent was needed, and where the matching logic had to make a decision. From there we picked a small, focused stack: FastAPI for the API layer, PostgreSQL as the source of truth, Dropbox Sign for consent, and GPT-4 for the parts of matching that needed to read prose. Everything ran inside Docker so the environment was reproducible from day one.

What We Built

User Experience

A dynamic patient intake engine that adapts question flow based on prior answers. Coordinators do not have to manage separate intake forms per trial. The same engine serves multiple studies and asks only what is relevant for each patient.

Automation

An intelligent matching engine that pairs patients to trials. Structured criteria handle the hard rules, such as age, condition, and prior treatments. GPT-4 reads free-text history where the rules cannot capture nuance. The two layers run together so reviewers see a ranked list of candidates instead of a raw filter result.

Integrations

Dropbox Sign handles the e-signature flow for consent. The backend creates the signature request, stores metadata in PostgreSQL, and updates the patient record when the document is signed. Coordinators get a single status to look at instead of an inbox full of PDFs.

Security

The platform was built around HIPAA from the first commit. Protected health information lives in PostgreSQL with controlled access paths through the API. Consent records carry the audit trail needed to prove who agreed to what and when.

Technical Architecture

The backend is a FastAPI service that sits between the team's tooling, the data store, and the external services that handle consent and language understanding. PostgreSQL is the source of truth for patients, trials, criteria, and consent events. GPT-4 is called only for the parts of matching that need to read prose. Dropbox Sign handles the legal artifact of consent.

Key Decisions

• FastAPI over a heavier framework. We chose FastAPI for its type safety, async support, and clean OpenAPI output. We gave up some of the batteries-included features of larger frameworks, but the team did not need them.
• Structured criteria plus GPT-4, not GPT-4 alone. Hard rules stay in code where they can be audited. GPT-4 is used only on free-text history so the matching engine stays explainable. We gave up the simplicity of a single model call in exchange for a result the medical team can trust.
• Dropbox Sign for consent instead of a custom signature flow. We get a known legal artifact and a webhook to listen to. We gave up the option of a fully custom UX, but we did not need it.
• PostgreSQL as the single source of truth. We kept the data layer simple and well understood. We gave up the option of a separate document store, which we did not need at this stage.

Results

• A production backend that handles intake, consent, and matching in one place.
• Less manual work for the medical team, who now spend more of their time on patients.
• Better visibility into where each patient sits in the recruitment funnel.
• A more scalable foundation for adding new trials and sponsors over time.
• A consent process with a clean audit trail that fits the HIPAA expectations of the business.

Project Highlights

• HIPAA-aware design baked in from the first version of the API.
• Dynamic intake engine that serves multiple trials from a single flow.
• Matching engine that combines hard criteria with GPT-4 reasoning on free text.
• Dropbox Sign integration that turns consent from a paper trail into a tracked event.
• Dockerized service that runs the same way locally and in production.

Screens and User Flows

The core flow runs from first patient contact to a ranked list of candidate trials and then to signed consent. Coordinators stay in the loop at the review step so a human approves who moves forward.

Future Growth Opportunities

• A coordinator dashboard on top of the existing API for richer review and triage.
• Sponsor-facing reporting that pulls from the same PostgreSQL data model.
• Additional integrations with EHR systems to reduce manual data entry at intake.
• A secondary matching pass that learns from accepted and rejected candidates over time.
• Role-based access for larger medical teams as the number of trials grows.