Who Answers for Your Data? Building a Life Sciences Data Mesh

Picture a study lead trying to work out why enrollment has slowed at two sites. Clinical operations have screen-failure counts. Biometrics has a cleaned subject-status file. A vendor has the visit data. Each team can hand over a number, and none of the numbers quite match. By the time someone sorts out the definitions, the window to act has often closed.

We think the root of that problem is ownership more than storage. A data mesh puts the people who understand the data in charge of publishing it, then gives everyone else a shared platform and common rules so they can find and combine results. She named four ideas: domain ownership, data as a product, self-service infrastructure, and federated computational governance.¹ Nobody has to scrap the warehouse or copy every source into a new tool. The point is to make responsibility for analytical data as explicit as it already is for the work behind it.

Why Isn’t Central Storage Enough for Life Sciences Data?

Life sciences data changes hands a lot before anyone decides anything with it. A single trial can pull from electronic data capture, central labs, patient-reported outcomes, imaging, contract research organizations, and a safety database. Manufacturing adds batch records, equipment histories, lab results, and deviations. These systems don’t share a vocabulary, an update schedule, or a regulatory purpose.

Central storage helps. It just can’t decide whether “enrolled” means consented, randomized, or dosed, or who rewrites that definition when a protocol changes. In our view, a central data team asked to settle every question like that ends up interpreting the whole business, and that doesn’t scale. A similar case can be made for pushing the work out to the domains.¹ We’d rather have accountable domain teams define and maintain the data they know, with enterprise teams supplying the standards and tools everyone else uses.

Ownership matters even more when the data could feed a regulated decision. FDA’s current E6(R3) good clinical practice guidance stresses fit-for-purpose systems, data integrity, traceability, and controls in proportion to risk across the clinical-trial data life cycle. A convenient table won’t cut it. Its provenance and intended use have to be clear.

What Does Domain Ownership Actually Require?

Start with the idea that a domain owns the meaning of its data, and the feed is only part of that. Say clinical operations publishes a site-and-subject enrollment product (Table 1). The owner would define status transitions, explain what a protocol amendment does to them, watch for missing or late updates, and name someone who can answer a consumer’s question. Manufacturing science and technology could share responsibility for batch genealogy, with quality in the room wherever release-relevant data appear. Whatever the domain, ownership needs a steward, a change process, and a way to resolve defects.¹

Every product also needs a defined user. Before anything gets published, ask who needs it and what decision it supports. From there, the product spells out its fields and definitions, source systems, permitted uses, refresh cadence, quality checks, lineage, version, and access path. The findable, accessible, interoperable, and reusable (FAIR) principles offer a handy test: can an authorized user find the data, understand it, connect it to other data, and reuse it? “Accessible” doesn’t mean open to everyone, since FAIR explicitly allows authentication and authorization.^1,2

Domain teams shouldn’t have to build identity controls, lineage capture, catalog entries, deployment pipelines, and quality-test harnesses on their own. A common platform can offer approved patterns and produce evidence as products are created or changed. Self-service here means a repeatable, controlled route to publication. Nobody gets to skip validation or review.^1,3

Governance stays shared where it has to be and local everywhere else. A federated group spanning domains, quality, privacy, security, and architecture can set a short list of non-negotiables: classification, identity, access, auditability, retention, and cross-domain semantics. The domains then write the finer rules that only their specialists can judge. Where possible, the platform checks those rules automatically, and every exception gets a named owner and a documented decision.¹

^{The table leans on public guidance: CDISC’s standards, FDA’s process-validation guidance, and EMA’s signal-management module.4-6 None of those sources claims that a mesh on its own improves enrollment, release time, or signal detection. Table 1 lists possible uses. We don’t have proven returns to set beside them.}

Where Should a Life Sciences Data Mesh Start?

We wouldn’t begin by asking which platform to buy. Ask where people keep reconciling data before they can act. Pick a use case with an identifiable owner, a real consumer, and a regulatory boundary you can manage. Enrollment performance, deviation trends, and batch-genealogy analysis are all reasonable candidates, as long as source access and review responsibilities are already understood. Treat what follows as our judgment, as no case study sits behind it.

Before anyone builds a pipeline, agree on a short contract for that first product: purpose, owner, source-of-truth rules, definitions, quality thresholds, refresh expectations, access conditions, and change approval. Capture metadata while you publish, not after the dashboard is finished. E6(R3), for instance, addresses metadata and audit trails, data transfers, corrections, and retention in trial data governance.³

Then hand the next domain the same starting kit: the catalog, access workflow, quality templates, and lineage pattern, changing only what that domain’s work demands. The central team still matters. It just spends its time building shared capabilities and settling shared standards instead of fielding every report request. Interoperability may call for controlled terms or a common identifier at a domain boundary, but domains don’t all need the same internal model.^1-3

Last, measure honestly. Count the time from request to published product, defects that consumers find, access-decision time, active users, and reuse by another domain. Tie each to a business question, like how long it takes to reconcile a site status or prepare a quality trend review. A shorter pipeline that produces numbers nobody can explain isn’t a win. These are measures we’re proposing, and they aren’t industry benchmarks.

Where Could a Data Mesh Help in Clinical, Manufacturing, and Safety?

In clinical development, a study team could bring site activation, screening, visits, and protocol deviations into one consistent view without asking a central group to relearn the study every time. Biometrics could separately publish analysis-ready assets with derivation history. The line between the two matters. An operational enrollment view isn’t automatically fit for a regulatory analysis, and any transformation behind a submission needs appropriate controls. The Clinical Data Interchange Standards Consortium (CDISC) publishes standards for tabulation, analysis, terminology, and data exchange, and the clinical product should line up with the organization’s study-data standards where relevant.⁴

On the manufacturing side, a product that links material lots, equipment settings, in-process results, lab data, deviations, and disposition decisions should, we expect, make continued process verification and investigations less dependent on one-off joins. FDA’s process-validation guidance calls for ongoing collection and evaluation of process and product data,⁵ and the value of a connected product rests on the quality of time stamps, identifiers, and source records. FDA’s drug cGMP data-integrity guidance adds that context has to survive along with the data.⁷

A governed safety product might bring case reports, literature findings, exposure estimates, and review status into one documented workflow. It should make medical judgment easier to apply, not replace it. The European Medicines Agency (EMA) describes signal detection, validation, confirmation, analysis, prioritization, assessment, and action as a managed process, and it expects analyses, decisions, and rationale to be traceable.⁶

Commercial and patient services are where we’d go slowest. Field and support teams may benefit from purpose-specific engagement products, but technical access doesn’t give anyone permission to use patient-level information. Keep clinical, safety, and commercial purposes separate, record the basis for each use, and show consumers only the view they’re allowed to see. Privacy rules depend on the organization’s role, the data, the jurisdiction, and the specific processing activity.^8-10

How Do GxP and Privacy Controls Fit into a Data Product?

A product used for a GxP-relevant purpose needs a documented intended use and controls that match the risk. Keep source-to-output lineage, test the transformations that matter, manage changes, and retain whatever records you’d need to reconstruct a decision. FDA describes drug cGMP data integrity as data that are complete, consistent, and accurate, and also attributable, legible, contemporaneously recorded, and original or a true copy.⁷ If 21 CFR Part 11 applies to an electronic record or signature, requirements include system validation, record copies, access restrictions, and audit trails. Part 11 doesn’t automatically cover every analytical dataset just because it’s digital.¹¹

Privacy needs careful scoping too. Under the Health Insurance Portability and Accountability Act, the minimum-necessary standard generally applies to covered entities’ uses, disclosures, and requests for protected health information, subject to exceptions. It isn’t a universal rule for every life sciences company or every treatment disclosure.⁸ The US Department of Health and Human Services recognizes Expert Determination and Safe Harbor as two routes to de-identification under the Privacy Rule.¹² Under the General Data Protection Regulation, pseudonymized information that can be reidentified remains personal data, and health data gets additional protection.^9,10 A product contract should record the permitted purpose, access conditions, de-identification or pseudonymization status, and any relevant transfer constraints, rather than a single “privacy approved” flag.

If a team uses a product to train or operate an artificial intelligence (AI) model, it should also record the data version, provenance, exclusions, known limitations, and who reviews the output. FDA’s January 2025 draft guidance proposes a risk-based credibility framework for AI used to support regulatory decisions about drug or biological-product safety, effectiveness, or quality. It’s a draft, and it doesn’t impose a blanket requirement on every internal model.¹³

Where Does a Data Mesh Go Wrong?

The commonest slip, in our view, is calling a dataset a product while nobody answers for its definitions or defects. Close behind: letting every domain pick its own identifiers and access conventions, or bolting on privacy and quality review after consumers have built on the output. All of it rebuilds the old handoffs under a new name.¹

A mesh changes roles as well as tools. We feel domain experts need time and authority to maintain their products, platform teams have to treat those experts as customers, and quality and privacy colleagues should help design the approved paths instead of only signing off on exceptions at the end. Begin narrowly, learn from the first consumers, and retire a product nobody trusts or uses.

Skip product treatment for the one-off investigation. A controlled analysis with a clear record of its sources usually serves it better. The extra effort pays off when a dataset has recurring consumers and definitions worth maintaining. Even then, controls should follow intended use: a working view for exploratory planning and an asset behind a regulated decision carry different evidence burdens.^1,2

Which Two Questions Does a Data Mesh Settle?

We see a life sciences data mesh as a practical way to settle two questions that keep coming up: who can explain this data, and what can someone else safely do with it? The evidence behind those answers should travel with the product instead of living in a chain of meetings. That’s our bet, anyway. Teams that get it right can reuse data without losing the context that makes it trustworthy. We wouldn’t call it a shortcut around regulation, or a guarantee of faster decisions.

References

1. Dehghani Z. Data mesh principles and logical architecture. MartinFowler.com. Published December 3, 2020. https://martinfowler.com/articles/data-mesh-principles.html

2. Wilkinson MD, Dumontier M, Aalbersberg IJ, et al. The FAIR guiding principles for scientific data management and stewardship. Sci Data. 2016;3:160018. doi:10.1038/sdata.2016.18

3. US Food and Drug Administration. E6(R3) good clinical practice (GCP): guidance for industry. FDA.gov. Published September 2025. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/e6r3-good-clinical-practice-gcp

4. Clinical Data Interchange Standards Consortium. Standards. CDISC.org. Accessed September 29, 2026. https://www.cdisc.org/standards

5. US Food and Drug Administration. Process validation: general principles and practices: guidance for industry. FDA.gov. Published January 2011. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/process-validation-general-principles-and-practices

6. European Medicines Agency. Guideline on good pharmacovigilance practices (GVP): module IX—signal management, rev 1. EMA.europa.eu. Published 2017. https://www.ema.europa.eu/en/documents/scientific-guideline/guideline-good-pharmacovigilance-practices-gvp-module-ix-signal-management-rev-1_en.pdf

7. US Food and Drug Administration. Data integrity and compliance with drug CGMP: questions and answers: guidance for industry. FDA.gov. Published December 2018. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/data-integrity-and-compliance-drug-cgmp-questions-and-answers

8. US Department of Health and Human Services. Minimum necessary requirement. HHS.gov. Reviewed July 26, 2013. https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html

9. European Commission. Data protection explained. Accessed September 29, 2026. https://commission.europa.eu/law/law-topic/data-protection/data-protection-explained_en

10. European Commission. Legal grounds for processing data. Accessed September 29, 2026. https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/legal-grounds-processing-data_en

11. Electronic records; electronic signatures. 21 CFR §11. Accessed September 29, 2026. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11

12. US Department of Health and Human Services. Guidance regarding methods for de-identification of protected health information in accordance with the HIPAA Privacy Rule. HHS.gov. Accessed September 29, 2026. https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html

13. US Food and Drug Administration. Considerations for the use of artificial intelligence to support regulatory decision-making for drug and biological products: draft guidance for industry and other interested parties. FDA.gov. Published January 2025. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/considerations-use-artificial-intelligence-support-regulatory-decision-making-drug-and-biological

Disclaimer: The views expressed in this article are the authors’ and not necessarily those of organizations with which they are affiliated.