Data infrastructure for restorative reproductive medicine (RRM) networks
Pool your evidence.
Keep your data.
Every practice in your network contributes consented, de-identified extracts to a shared research pool. The records themselves never leave a practice's own systems or its control.
Made for the work you already do
Data Commons is built for RRM: IRB-reviewed research, multi-site outcome studies, and the independent practices producing the data both need. Three kinds of work shaped it. None of that work changes. Its impact does.
Made for IRB-reviewed research
Consent capture, de-identification, isolation, and access logging are enforced in the pipeline and documented for review. The controls your protocol promises are controls that actually run, and the audit trail to prove it writes itself.
Made for multi-site studies like STORRM
Multi-site RRM outcome studies need pooled, consented, de-identified data with provenance intact. That is exactly the shape of what the commons produces, from enrollment through publishable aggregate.
Made for busy practices and clinics
Guided forms and a spreadsheet template are built for practices that run without an IT department, and built so no one at the practice has to be a data person. The pipeline does the data work; you do medicine. Participation is designed to be light enough for one person to carry alongside a full clinic day.
The evidence your network produces every day disappears by default
Every encounter at every site produces an outcome. Nearly all of it ends where it started, inside one chart, in one system, at one site. When a journal, a payer, or a funder asks what your results look like across the network, the answer today is a manual chart review and a long wait.
The field cannot cite what was never pooled, and networks that cannot show pooled outcomes keep ceding the evidence conversation to whoever can. Data Commons closes that gap. It turns the restorative care your practices already deliver into a structured, consented, de-identified evidence base, ready for aggregate analysis and built to support publication.
The questions every practice asks before saying yes
Invite ten practices into a shared registry and you will hear the same three questions ten times. Where does our data live? Who else can see it? What do we give up by joining?
Data Commons gives each question an answer that holds up in front of a board: your data lives where it lives today, your site alone sees it, and joining costs you none of your control.
The commons receives a consented, de-identified extract. You keep everything else.
How a site joins, in four steps
Every path into the commons is designed around the same constraint: a busy practice with no technical staff.
Keep your system of record
Data Commons is designed as a layer over whatever a practice already runs. Records stay in the practice's own systems, and the commons works only from consented extracts.
Contribute the way that fits
Three intake paths meet practices where they are: guided entry forms, a spreadsheet template for batch upload, and a direct feed for systems that can already export data. Each network starts on the path that fits its sites.
The pipeline enforces consent and de-identification
Consent is opt-in and checked on every run; revoke it and that participant's data stays home, even the same day. Every data item carries a rule for what may leave: applied automatically at export.
Analyze the pool
De-identified records land in a separate pooled layer that remembers which site each record came from, never who it is about. Analysis runs through a scoped read-only role against that layer, and nothing else.
Ownership, written into the architecture
Most governance lives in documents. These controls run in the pipeline itself, so a site's ownership survives staff turnover, new leadership, and time.
Only a de-identified extract ever leaves
Each site retains ownership and control of its records. The extract that leaves is structured, consented, and de-identified, produced by an automated export step with a fail-closed sweep that halts if a disallowed identifying field appears.
The hub never holds the key to re-identify
Identifiers are replaced with one-way cryptographic tokens, and the key that makes them stays at the site. The hub never holds what it would need to map a pooled record back to a person.
Consent is computed, on every run
Enrollment consent defaults to off. Latest status wins, and the check is fail-closed: a participant whose consent is off, revoked, or unclear on a given day is excluded from that day's extract by construction.
Every access leaves a record
The hub logs every access as an auditable event, reads included, and checks access rules automatically before they ever take effect.
Isolation is structural
Each site operates in its own isolated environment on the hub, separated at the infrastructure level rather than by permissions inside one shared database. One site is never visible to another; the pooled, de-identified layer sits apart under its own rules.
What your data team gets
One shared data dictionary drives the whole system. Everything below exists to hold each site's burden near zero.
Forms that maintain themselves
Data-collection forms are generated from the shared dictionary. When the dictionary changes, every site's forms follow, and nothing drifts out of sync.
A spreadsheet path that respects your staff
Sites that live in spreadsheets stay in spreadsheets. A template matches the shared model, submissions are checked automatically, and imperfect files get help instead of rejection.
Provenance without identity
The pool remembers where every record came from, never who it is about. Quality problems trace back to their source without a name ever entering the commons.
An open, inspectable data model
Built on published health-data standards (FHIR R4) and open-source foundations. What the commons collects, and how, stays inspectable by anyone you answer to.
Proven before it touches real data
Every pipeline change is exercised end to end against synthetic records before it goes anywhere near a real one. The consent gate, the de-identification rules, and the export sweep are all under automated test.
Consent for new uses, by design
The pool is built to ask again. When a new research question needs new permission, participants grant or revoke it in one step, with a full audit trail.
Due diligence
Questions a careful evaluator asks
What is a data commons?
A data commons is shared infrastructure that lets independent organizations pool data for aggregate analysis while each keeps control of its own records. The participating sites agree on a common data model and a common set of rules. The infrastructure enforces those rules mechanically: what leaves a site, how it is de-identified, whose consent covers it, and who can read the pooled result.
How is this different from contributing to an existing registry?
A conventional central registry asks your staff to enter or duplicate data into someone else's database. Here, each site keeps its own system of record, and what reaches the pool is a consent-gated, mechanically de-identified extract. Isolation between sites is structural, at the infrastructure level, and none of it depends on being a customer of any particular EHR vendor.
Do our sites have to replace or migrate their existing systems?
No. The commons is designed as a layer, with each site keeping its own system of record. Baseline participation runs on guided entry forms or a spreadsheet template rather than a systems-integration project, and sites whose systems can already export data have an optional direct path.
How much staff effort does participation take?
The design target is one person at the site, working from guided entry forms or a spreadsheet template that matches the shared data model. Uploads validate automatically, with a lenient mode for incomplete submissions. The one per-participant prerequisite is a captured, revocable consent record before that participant's data can appear in any extract.
Who can see our site's data on the hub?
Only your site. Each site operates in its own isolated environment, separated at the infrastructure level, so one site's users and data are never visible to another. Aggregate analysis runs against a separate pooled, de-identified layer through a scoped read-only role. Every access is logged as an auditable event, and access rules are checked automatically before they take effect.
Can anyone at the hub re-identify our patients?
By design, the hub never receives what it would need to re-identify a pooled record. Identifiers are replaced with one-way cryptographic tokens whose key stays at the site. The export step also runs a fail-closed sweep that halts if a disallowed identifying field appears, and provenance references in the pool are pruned so they cannot point back to a person.
What happens when a participant revokes consent?
Their data stays home. Consent is opt-in, checked on every extract run, with latest status winning. The check is fail-closed: if consent is revoked the same day an extract runs, that participant is excluded from that run.
If our site leaves, what happens to our data?
Your records never left your own systems, so leaving strands nothing. Contribution simply stops. What the pool retains from past extracts is set in the data-use agreement.
Are we locked into a proprietary data model?
The data model compiles to FHIR R4, a published health-data interoperability standard. Forms and data definitions all generate from one versioned dictionary, and the platform it runs on is open source under Apache-2.0, so the structure of what is collected stays inspectable.
What will our IRB or compliance team want to see?
The consent model, the de-identification pipeline, and the data-use agreement. The written technical overview from the briefing is built for exactly that review: it describes what leaves a site, what never does, and the controls that enforce the difference.
Will our data be sold or shared with third parties?
No. Data is never sold or brokered, and that commitment is written into your data-use agreement, where it is enforceable. Sharing beyond the pool is governed by applicable privacy law and independent research-ethics oversight, and the technical controls described above, consent gating, de-identification, tenant isolation, and access logging, are what the system enforces on its own.
What determines the cost of participation?
Network size and deployment model. Commercial terms are worked through in the briefing, and the figure that matters lands in your data-use agreement, where it is enforceable.
What is the path from a briefing to our first contributed record?
A briefing is a working session of under an hour. From there, your network reviews the written technical overview, the data dictionary, and the governance model, and tailors them to the questions it wants answered. A data-use agreement and participant consent capture come next; an independent security review gates the system before participant data flows. Once a site is in, it starts on the intake path that fits it: guided forms or the spreadsheet template.
The next step
See the architecture before you commit anything
Everything on this page is a control that runs in the pipeline, and the briefing walks through all of it end to end: the data dictionary, the consent gate, the de-identification pipeline, and the governance model.
A briefing is a working session of under an hour. You leave with the written technical overview, your compliance team gets what it needs for review, and you commit nothing and hand over nothing.
Bring your practices, your systems, and the questions you want the pooled data to answer.