SimpliFed, a Series A virtual lactation company, just published a clinical outcomes study with UMass showing improved outcomes from its virtual care model — while serving a meaningful share of US pregnancies. For an early-stage virtual-care company, that’s about the best growth asset there is: it converts payers, disarms skeptical clinicians, and gives investors evidence instead of narrative.
Here’s what nobody writes about: the engineering that makes a study like that possible has to exist long before anyone designs the study. Published outcomes are the visible tip of a data architecture decision made a year and a half earlier — or the painful, expensive absence of one.
We build virtual-care platforms, so this is a post about that architecture. But first, a reframe that matters.
The study is a side effect of good care
The instinct is to treat outcomes data as a research feature you bolt on when a study is in view. That’s backwards. The data that powers a publication comes from the same feedback loops that power good care.
A patient comes to you with a care concern. A treatment plan is your proposed solution. The feedback loop is what tells you whether the plan is working: self-reported check-ins, labs, wearable data. We can collect more of this than ever. Having systems that collect it — and that encode what you expect to see given the treatment plan in place — is how you help a patient see their own progress and how you catch it early when the plan isn’t delivering. And when the outcome isn’t what anyone wanted, that same loop is what lets you go back to the patient’s original concern with something better.
A published study asks the aggregate version of the same question the feedback loop asks per-patient: which treatment plans are most effective, for which patients, in which scenarios? Same data. Same engineering. Build the feedback loop because it makes the care better, and the study becomes possible as a byproduct. Build neither, and you have a subscription funnel with a clinical costume on.
The two primitives that matter most
If a seed-stage founder asked us what to build now so a study is possible in 18 months, the list is shorter than you’d expect. Two things carry most of the weight:
A data ingestion interface that assumes change. Your data sources will not hold still. Different lab partners send the same test in different formats with different units. The wearable you integrate next year doesn’t exist in your schema today. The biomarker you capture today may not be the biomarker you capture tomorrow. The ingestion layer has to normalize this chaos into something analyzable — without losing the audit record. Cleaning data is necessary; cleaning it in a way that destroys the source of truth is how you end up unable to answer “where did this number come from?” when a reviewer, a partner, or a regulator asks. Normalize forward, preserve backward.
A longitudinal, flexible data model. Most early product databases are transaction-shaped: orders, subscriptions, messages. A study needs patient-journey-shaped data — this measure, for this patient, at these intervals, under this treatment plan, over time. Retrofitting longitudinal structure onto a transactional schema is some of the least fun engineering there is. Designing for it up front is mostly a matter of knowing to.
Everything else — consistent capture intervals, cohort definitions, clean export — gets dramatically easier once those two exist, and stays roughly impossible until they do.
What the failure mode looks like
We can describe it precisely, because it’s common: hundreds of scattered data stores, and an analytics team spending long hours sifting through them to answer each question. Every analysis re-pays the cleaning cost separately. The workload shifts to the end of the process, where it’s most expensive and most repeated.
The company in that state doesn’t lack data — it usually has plenty. It lacks a model. So the “outcomes study” project stalls in month one, not on statistics, but on archaeology. A clean, consistent data model moves that effort to the front of the process, once, and frees your data and analytics people to study instead of clean. That sentence is the entire business case.
The honest cost question
A founder reading this will ask: is this a week of schema decisions or a quarter of infrastructure?
Closer to the former than you’d fear. Done up front, this is not an expensive problem — it’s a thinking problem. The cost is knowing what this data will need to look like at scale and applying that knowledge to decisions you’re making anyway: what the ingestion layer normalizes, what the patient record is keyed on, what gets timestamped and sourced. Once that knowledge is in the room, doing it right costs about the same as doing it wrong.
Doing it wrong just costs a lot more downstream, over and over, for years — paid in analyst hours, delayed studies, and growth channels you can’t open. The expensive version of this architecture is the one you build second.
The 18-month clock
SimpliFed’s study didn’t start when the paper was drafted. It started when someone made sure the check-in data, the outcomes measures, and the patient timeline were being captured in a shape that could be studied. If a publication, a payer conversation, or an evidence-hungry Series B is anywhere in your future, that clock is running now — and the feedback loop it forces you to build will be making your care better the whole time.
Fanzoo builds virtual-care platforms end to end, including the data capture and longitudinal models that make outcomes work possible. If you’re deciding what your patient data should look like before it’s too expensive to change, that’s exactly the kind of question a Launch Path is built to answer.