Clinical Data for Secondary Use and Research: Architecture for a Second Life of Data
Secondary use refers to applying clinical data collected during routine care to purposes beyond the immediate treatment of the patient. The classic AMIA definition frames it as applying personal health information to uses outside direct healthcare delivery — including analysis, research, quality and safety measurement, public health, and payment [1]; today's list extends naturally to pharmacovigilance, health technology assessment, and AI model training. The regulatory world has caught up with the architecture question: the EU's European Health Data Space Regulation (EU 2025/327), in force since March 2025, establishes a dedicated legal framework for the secondary use of electronic health data — permit-based access through health data access bodies, patient opt-out rights, and mandatory secure processing environments from which personal data cannot be downloaded — with most secondary-use rules applying from March 2029 [3]. For architects, the message is blunt: a CDR designed only for the care workflow will meet secondary-use requirements the way most systems meet requirements they were never designed for — late, expensively, and partially. Completeness and representativeness, consent and privacy governance, de-identification, and reliable cohort construction must be designed in from the start.
Separate the Primary Record from the Research Environment
The foundational design principle — and the shape that frameworks like the EHDS institutionalize with its secure processing environments [3] — is architectural separation between the primary clinical record and the secondary-use environment. The CDR remains the authoritative, identified, versioned record serving care; a distinct environment — a warehouse, research data mart, or federated analytics node — receives a governed extract: de-identified, enriched with derived variables, and organized for analytical query patterns rather than clinical workflow patterns. The two environments differ in almost every architectural dimension, which is precisely why merging them fails:
Primary vs. Secondary Environment at a Glance
| Concern | Primary CDR | Secondary-Use Environment |
|---|---|---|
| Identity | Fully identified, MPI-linked subject | De-identified or pseudonymized; re-identification controlled and auditable |
| Data shape | Versioned compositions/documents per clinical model | Flattened, derived, cohort-oriented structures for analytics |
| Query pattern | Per-patient retrieval, workflow-driven | Population-level aggregation, cohort inclusion/exclusion logic |
| Governance gate | Treatment relationship, role-based access | Consent/opt-out filtering, permits, ethics approval, purpose limitation |
| Failure mode if conflated | Research load degrades clinical performance | Identified data leaks into analyses; consent violations; irreproducible studies |
The transformation pipeline between the two is a first-class integration point, not an ETL afterthought. In our experience it must handle three responsibilities as explicit, testable stages: consent and opt-out filtering (which records may flow at all, per purpose); de-identification rule application; and vocabulary standardization — mapping local codes to SNOMED CT, ICD, LOINC, and ATC as the research context requires, since cohort definitions are only as reliable as the coding beneath them. On de-identification specifically, the U.S. HIPAA Privacy Rule provides the canonical reference frame: two recognized methods — Expert Determination (a qualified expert formally determines that re-identification risk is very small) and Safe Harbor (removal of the enumerated identifiers) — with the important official caveat that both, even properly applied, retain some residual re-identification risk [2]. Architecturally, that means de-identification is a managed risk process with documented rules and periodic review, not a checkbox transformation.
Federated Analytics: Move the Question, Not the Data
For multi-site research, federated analytics is gaining ground as the privacy-preserving alternative to centralized pooling: each participating site executes approved analyses against its locally held data and returns only aggregated or privacy-protected results to the coordinating researcher. The pattern has mature ecosystems behind it. The i2b2 platform, used at over 200 sites worldwide, takes an ontology-driven approach to cohort discovery over a star-schema warehouse, while the OMOP Common Data Model, stewarded by the OHDSI community, was designed from the beginning as a shared analytics model so the same analysis code can run identically at every site [4]. An openEHR-native estate brings its own instrument: because AQL queries are written against archetypes rather than physical schemas, the same query is designed to be shareable across conformant systems and enterprise boundaries [5] — which is exactly the property federated execution requires.
Architects evaluating federation should assess three things beyond the tooling: query standardization across heterogeneous implementations (a query that means subtly different things at different sites produces confident nonsense); operational characteristics like network latency, site availability, and result-set size limits; and — hardest — the governance model for approving, executing, and auditing remote queries: who reviews a proposed analysis, what aggregation thresholds protect against re-identification by small cell counts, and how every remote execution is logged. In our experience the governance design, not the technology, determines whether a federated network survives its first incident.
Design Consequences for the CDR
Working backwards, a CDR intended to feed secondary use well needs four properties from day one: standards-based, terminology-bound data capture, because retrospective coding cleanup is the most expensive data quality work there is; consent and opt-out represented as structured, queryable data, not scanned forms, so the extraction pipeline can filter mechanically; versioned, temporally faithful records, so cohorts can be reconstructed as of a study cutoff date and studies reproduced; and a clean separation between the identified subject and the clinical content, so pseudonymization is a key-management exercise rather than a data surgery. None of these is exotic — all four are natural properties of a well-designed openEHR repository — but in our experience each is nearly impossible to retrofit onto a store that conflated them.
Where CaboLabs Fits
CaboLabs designs clinical data platforms with the second life of data in mind. Our openEHR-native clinical data repository, Atomik, provides the properties this article argues for at the source: template-validated, terminology-bound data capture, versioned records with full temporal fidelity, architectural separation of demographics from clinical content, and archetype-based AQL querying that makes cohort logic portable across conformant systems. Around the repository, our consulting practice covers secondary-use pipeline design — consent filtering, de-identification workflows, vocabulary mapping to SNOMED CT, LOINC, and ICD — and research data architecture across openEHR, FHIR, and HL7 ecosystems.
If you are building a research data environment on top of clinical operations, preparing for frameworks like the EHDS, or want a CDR whose data is worth reusing in the first place, talk to us at cabolabs.com — good research data isn't extracted, it's designed upstream.