Reference Data Is the Dependency Nobody Owns

Ask a quality or data leader who owns the company’s product master, and you will get an answer. Ask who owns the MedDRA version in the safety database, and the room usually pauses. Someone in pharmacovigilance operations loads it. Someone in IT schedules the load. A vendor may push it as part of a hosted service. But ownership in the governance sense, meaning a named person who decides when a new version is adopted, what gets assessed before adoption, what gets revalidated, and who gets told, is frequently missing.

That gap exists because reference data does not behave like the rest of the data estate. It is not generated by a business process. It arrives as a subscription, a download, a file drop, or a database patch. It looks like infrastructure. And infrastructure, in most operating models, belongs to whoever installs it rather than to whoever depends on it.

What counts as reference data

It helps to separate three categories that often get discussed as one. Transactional data is what a process produces: a case report, a batch record, a lab result. Master data is the set of core business entities the organization defines for itself: products, sites, suppliers, studies, investigators. Reference data is the set of externally published code lists and hierarchies used to classify and describe both of the others.

The distinction matters because the failure modes are different. Master data fails through duplication and inconsistency across systems, which is a familiar problem with familiar remedies. Reference data fails through version mismatch, which is much quieter. Nothing looks broken. Every record has a valid code. The system does not error. The numbers simply mean something slightly different than they did last year.

Why ownership falls through the gaps

Four structural reasons explain most of it.

  • The publisher is external. There is no internal change control record for a MedDRA release, because the change did not originate inside the quality system. It originated at the MSSO.
  • The consumers are spread out. A single MedDRA version touches case processing, aggregate reporting, signal management, clinical data management, statistical programming, and regulatory submissions. When six functions consume something, none of them owns it.
  • The update is routine. Twice a year, on schedule, forever. Routine work stops getting reviewed. It becomes an operational task with a ticket number rather than a decision with an assessment behind it.
  • The damage is deferred. A version adopted in March causes a question in a periodic report eighteen months later, by which point nobody connects the two.

The working definition we use

Reference data is any externally published, versioned code list or hierarchy that your regulated data depends on for meaning. If your data cannot be interpreted without knowing which release of that list was in force, it is reference data and it needs an owner, a version register, and a change assessment.

The consequence of leaving it unowned is not a compliance finding on day one. It is a slow loss of comparability. Safety tables, cohort counts, product listings, and lab summaries all keep producing plausible numbers. The organization keeps making decisions on them. And when someone finally asks why the incidence of a given event appears to have dropped between two reporting periods, the honest answer turns out to be that the term moved.

The Reference Sets Pharma Actually Depends On

Before you can govern reference data you have to inventory it. Most organizations underestimate how many external vocabularies they are actually running, and almost all of them underestimate how badly the release schedules collide.

2 MedDRA releases per year, on 1 March and 1 September3
12 SNOMED CT International Edition releases per year, on the last day of each month11
4 CDISC Controlled Terminology packages per year, published quarterly13

The table below is the inventory we start from. Read the cadence column first. It is the reason this problem exists.

Reference set What it governs Publisher Release cadence Where drift bites
MedDRA Adverse events, indications, medical history, investigations, social circumstances MedDRA MSSO, on behalf of ICH Twice yearly. X.0 on 1 March with changes possible at all five hierarchy levels; X.1 on 1 September with changes limited to the lower levels3 Aggregate safety tables, SMQ output, periodic reports, signal management
WHODrug Global Medicinal products, active ingredients, ATC classification for suspect and concomitant medications UMC Twice yearly, on 1 March and 1 September10 Drug event pairing, concomitant medication summaries, product level signal work
FDA UNII / GSRS Unique identifiers for substances, from a single chemical to a complex biological material FDA Global Substance Registration System8 Continuous registration. Identifiers can be generated at any point in the regulatory lifecycle7 Electronic listing, structured product labeling, ingredient matching across systems
SNOMED CT Clinical findings, procedures, body structures, substances in health records and real-world data SNOMED International Monthly, on the last day of each month, in Full, Snapshot, and Delta formats11 Real-world data cohorts, EHR-sourced endpoints, external data partnerships
LOINC Laboratory tests, measurements, and clinical observations Regenstrief Institute Twice yearly, in February and August12 Lab data integration, central and local lab harmonization, real-world evidence
ISO IDMP and EMA SPOR Identification of medicinal products, substances, dose forms, routes, units of measurement ISO standards implemented through EMA services15 Rolling. Terms are added and updated through a stewarded change request process rather than a fixed release date17 Product registration data, variations, cross-border product identity
CDISC Controlled Terminology Permitted values in SDTM, SEND, ADaM, CDASH and protocol datasets CDISC, published through NCI Enterprise Vocabulary Services Quarterly, at the end of each quarter, after a public review period1314 Submission conformance, define.xml declarations, pooled analytical datasets

Read the cadence column as the finding

Seven vocabularies. Four different release rhythms. Two of them are continuous rather than scheduled at all. There is no month of the year in which nothing changes, and there is no single date on which an organization can say it is current on everything at once.

This is the practical shape of the problem. A company that adopts MedDRA on 1 March, CDISC Controlled Terminology at the end of Q1, LOINC in mid February, and SNOMED CT on a rolling monthly basis is operating four separate adoption clocks. Each clock has its own impact assessment, its own revalidation question, and its own downstream notification list. When those clocks are managed independently by four different teams, the organization loses the ability to say what combination of versions produced any given output.

The sets that behave differently

Two entries in the table deserve separate treatment because they do not follow a release cycle in the normal sense.

FDA UNII is an identifier registry rather than a periodic publication. The identifier itself is designed to be stable: it is a non-proprietary, unambiguous, non-semantic alphanumeric code tied to a substance’s molecular structure or descriptive information, generated by the Global Substance Registration System.7 FDA built the system starting in 2006 because no existing code system met its regulatory needs, and it classifies substances into structural categories drawn from ISO 11238.8 The stability of the identifier is exactly why it is useful, and it is also why teams stop thinking about it. What changes underneath is not usually the code but the descriptive record attached to it, and the relationships between substances. A team that cached a substance record five years ago and never refreshed it may be matching against a definition that has since been refined.

ISO IDMP through EMA SPOR is a rolling master data service rather than a versioned file. Commission Implementing Regulation (EU) No 520/2012 requires the use of the ISO IDMP standards for exchanging medicinal product information across the EU, and EMA is implementing them across four master data domains: substance, product, organization, and referential.15 The referential service holds the controlled term lists that describe product attributes such as dose forms, routes of administration, and units of measurement, and those terms are added and updated through a stewarded change request process rather than a semiannual drop.1617 A rolling model removes the shock of a big release, but it also removes the natural checkpoint. If nothing forces a review, nothing gets reviewed.

What Actually Changes in a Release

Teams that have never sat through a terminology impact assessment tend to picture a release as new terms being added. Additions are the easy part. The changes that create risk are the ones that alter the meaning or placement of terms that are already in your data.

The six change types that matter

  • New terms. A concept that previously had to be coded to something approximate now has its own term. Anything coded before the release will not use it.
  • Terms made non-current. A term that existed is retired. Records already coded to it remain, but the term is no longer selectable and may no longer be retrieved the way it was.
  • Renames. The same underlying code carries a different display name. Outputs generated before and after the change show different text for the same records.
  • Hierarchy movement. In MedDRA, a term may be promoted from a lower level to Preferred Term status, or demoted from Preferred Term to a lower level. Retrieval at the Preferred Term level then returns a different set.
  • Primary system organ class reassignment. A term keeps its identity but changes which system organ class it rolls up to by default. This is the single most disruptive change type for aggregate safety presentation.
  • Query membership changes. Standardized MedDRA Queries (SMQs) gain and lose member terms with each release. The query name stays the same. The population it returns does not.

The MedDRA release model deliberately separates these. The March X.0 release is the one that can change all five levels of the hierarchy, including the structural changes that move terms around. The September X.1 release is restricted to the lower levels.3 That asymmetry is useful to know, because it tells you which of the two annual releases actually needs a structural impact assessment and which one is closer to routine.

The change your system will not flag. None of the six change types above will generate an error in a validated system. Every historical record remains internally valid. The database is not corrupted. What changed is the relationship between a code and its meaning, and no data integrity check is designed to detect that. This is precisely why version drift needs a governance control rather than a technical one.

The same pattern in the other vocabularies

The MedDRA vocabulary makes the pattern most visible because safety reporting is so sensitive to it, but the pattern is general. SNOMED CT distributes Full, Snapshot, and Delta release formats specifically because components are created, inactivated, and changed over time, and the release format includes a history tracking mechanism so that consumers can reconstruct what a component looked like at a point in time.11 LOINC release 2.82, published in February 2026, added close to 1,100 new concepts and updated more than 1,400 existing ones.12 Updates to existing concepts are the ones worth reading.

CDISC handles the same issue by making the version explicit in the submission itself. The published version date is what belongs in the define.xml file to declare which release of Controlled Terminology was used in the data submitted to a regulatory authority.13 That is a good model, and it is worth noticing what it implies: the standards body assumes that version is a property of the dataset, not a property of the system.

The Recoding Decision: Recode, Freeze, or Run Mixed

When a new version arrives, an organization has three broad postures available. Each one is defensible in some circumstances and indefensible in others, and the useful work is in being explicit about which one you are choosing and why.

POSTURE 1

Recode historical data

Bring existing records forward to the new version. Highest data accuracy and best comparability going forward. Highest effort, and it changes frequency distributions in data that has already been reported.

POSTURE 2

Freeze a version

Lock a study, a product, or a submission to a single version for its duration. Internally consistent and easy to explain. Falls behind current terminology and complicates pooling with newer data.

POSTURE 3

Run mixed versions

Code new data in the current version and leave older data where it is. Lowest effort and the most common default. Creates a database whose contents cannot be aggregated cleanly without version-aware handling.

DECISION

The choice is per dataset

There is no single right answer across an organization. A postmarketing safety database, an ongoing pivotal study, and a closed legacy study each justify different postures. The failure is choosing by default instead of by assessment.

The methods the standard actually describes

MedDRA’s own guidance is more granular than the three postures above, and it is worth using its vocabulary because it is the language a reviewer will recognize. The ICH-endorsed term selection guidance describes four methods that increase in both effort and accuracy.1

Method What it involves Effort Effect on data accuracy
Method 1 Use the new version for coding new data only. No recoding of existing data. Lowest Minimal gain. Historical records keep whatever meaning they had.
Method 2 Method 1, plus identify verbatim terms linked to lower level terms that are now non-current and recode those existing records. Moderate Removes the most obvious inconsistency: live records pointing at retired terms.
Method 3 Method 2, plus recode verbatim terms to new lower level terms that are direct or lexical matches. Higher Records now use the term that most literally matches the reported wording.
Method 4 Method 3, plus recode verbatim terms to new terms that represent a more accurate concept. Highest Highest accuracy. Also the largest change to previously reported frequencies.

The guidance is clear that each organization should have a documented versioning strategy, and equally clear that the strategy can legitimately differ between database types. It notes that there may be no need to update clinical trial data from older trials if those data are not currently in use, while a postmarketing safety database is generally expected to be on a current or near-current version.1 That is a sensible distinction and it gives you a defensible basis for treating different holdings differently.

What is defensible in a submission

The question we get asked most often is which posture survives regulatory scrutiny. In our experience the answer is less about which option you chose and more about four things you can demonstrate.

  1. The version in force is stated. Every output declares the terminology version used to produce it. Not the version installed in the system today, but the version used for that specific output.
  2. Consistency within an analytical unit is preserved. A single integrated summary, a single periodic report, a single pooled dataset uses one version throughout. Mixing versions inside one table is where credibility is lost.
  3. The strategy is written down before it is applied. A documented versioning procedure that predates the release is a governance control. A rationale written after a reviewer asks a question is an explanation.
  4. Differences from the previous period are explained. If a term moved and the aggregate table shifted as a result, the report says so. Reviewers are far more comfortable with a disclosed shift than with an undisclosed one they discover themselves.
A practical rule. Freeze within an analytical unit, stay current at the point of entry. New cases and new records get coded in the current version. Any given report, pooled dataset, or submission deliverable is produced under a single declared version, and that version is recorded with the output. This gives you currency where regulators expect it and internal consistency where readers need it.

How Version Drift Damages the Numbers

The abstract case for reference data governance rarely persuades anyone. The concrete case usually does, because once a leader sees how a table moves without anyone touching the data, the problem becomes obvious.

Reassignment and the aggregate safety table

Start with the most common presentation in pharmacovigilance: events summarized by system organ class, with preferred terms nested underneath. Now suppose a term’s primary system organ class assignment changes in a new release. The events themselves have not changed. The number of cases has not changed. But in the new version those events roll up somewhere else.

MedDRA’s data retrieval guidance describes exactly this effect, noting that when primary system organ class assignments change between versions, terms will seem to have disappeared from where they used to sit in aggregate presentations.2 A reader comparing this year’s table to last year’s sees a category that has shrunk and another that has grown. There is no footnote, because nobody generated one. The most likely interpretation, which is that something changed clinically, is wrong.

Queries built in a newer version, run against older data

The second failure is subtler and affects signal work directly. Standardized MedDRA Queries are maintained alongside the dictionary, and their membership changes between releases. The guidance is direct on the requirement: the query version should always correspond to the version of the data being searched, and terms used to build a query should be in the same version as the data being queried.2

The documented example is instructive. A preferred term for hormone receptor positive breast cancer was added to the SMQ for breast malignant tumors in MedDRA Version 23.0. Running the earlier version of that SMQ against data that includes the term fails to identify those cases.2 Nothing errors. The query returns a result. The result is incomplete, and the incompleteness is invisible unless someone was already looking for it.

The same guidance flags what happens when a database holds studies coded in different versions, warning that mixed versions can affect the aggregation of those data, for example in an integrated summary of safety.2 An integrated summary is precisely the deliverable where a subtle undercount is least welcome.

The specific failure to watch for. A signal management team upgrades to the current MedDRA version because that is good practice. The team runs its standing SMQ-based searches. The searches now use current query definitions against a database where most historical cases were coded years ago under earlier versions. The output looks normal. The retrieval is systematically incomplete for the older portion of the database, and the incompleteness is not uniform across queries.

Comparing periodic reports across years

Now put the two effects together over time. A periodic benefit-risk evaluation report is a cumulative document by design. The ICH E2C(R2) guideline moved periodic reporting from an interval safety report toward a cumulative benefit-risk evaluation, which means readers are explicitly invited to compare across periods.20

If the underlying terminology version changed between periods and the earlier data was never brought forward, then the comparison a reader is invited to make is a comparison between two differently coded populations. Counts by system organ class may shift. Preferred term groupings may consolidate or split. Query-derived populations may expand or contract. Each individual change is small. The composite effect across several reporting cycles is a trend line that partly reflects terminology maintenance rather than product behavior.

This is the argument for treating version currency as a reporting disclosure rather than an IT configuration detail. The reader of a periodic report has no way to know which version produced which section unless the report says so.

The damage outside pharmacovigilance

Safety is where the effect is most visible, but it is not the only place it appears.

  • Real-world data cohorts. SNOMED CT publishes monthly, and concepts are inactivated over time. A cohort definition written against one release and rerun against a later one can silently include or exclude patients. Any external data partnership should specify the release used, not just the vocabulary.
  • Laboratory data. LOINC changes both add new codes and update existing concepts.12 Where central and local lab feeds are harmonized to a common code set, a refreshed mapping table can quietly reclassify a subset of results.
  • Product and substance identity. Where UNII codes are used to match ingredients across manufacturing, regulatory, and safety systems, a stale local copy of the substance registry produces match failures that are usually blamed on the receiving system rather than on the reference data.
  • Submission conformance. CDISC Controlled Terminology packages are published quarterly, and the version used has to be declared in define.xml.13 A study that spans several years and never revisits its declared version has a conformance conversation waiting for it.

What Regulators Expect on Version Currency

There is a common assumption that no regulator has an opinion on terminology versions. That is not accurate. The expectations are scattered across technical guidance rather than concentrated in a single document, which is part of why they are easy to miss.

The FDA position

FDA sets expectations through its Study Data Technical Conformance Guide and its Data Standards Catalog, which together identify the standards, formats, and terminologies the agency supports for study data submissions, including the dictionary used for adverse events.5 The agency has also issued explicit notices about MedDRA version support, retiring support for early versions and setting transition dates after which studies were expected to use a current version.6 The practical implication is that version currency is a submission attribute the agency tracks, not a matter of internal preference.

The EU position

In the EU, individual case safety reports flow into EudraVigilance in the ICH E2B(R3) format with adverse reactions and indications coded in MedDRA, and EMA runs a formal change management process for the system.1821 National guidance reinforces that a new MedDRA update is released every half year and that the exact implementation date of a new version should be coordinated between the parties in a reporting network so that exchange between them continues to work.19

That coordination point is worth pausing on, because it is the one most companies handle informally. If your partner, licensee, contract research organization, or safety vendor upgrades on a different date than you do, then for the period between the two dates you are exchanging data coded in two versions. Someone has to decide whether that is acceptable and how the gap is handled.

MedDRA’s own term selection guidance provides a useful anchor here: a new reporting version is expected to take effect on the first Monday of the second month after release, synchronized across ICH regions so that data exchange stays consistent.1 That gives you a known window between publication and expected use, and that window is where the impact assessment belongs.

What good looks like in an inspection. A written versioning procedure that names the decision maker. A version register showing which release was in force on which date for each system. An impact assessment record for each adoption. Revalidation evidence scoped to what the assessment identified. Output-level version declarations on aggregate reports and submission datasets. Notification records showing that downstream consumers were told before the change, not after.

The gap between the two

FDA and EMA both expect currency, but they express it through different mechanisms and against different timetables, and the vocabularies themselves publish on their own schedules regardless of either agency. A global organization is therefore reconciling at least three calendars: the publisher’s release calendar, the regional expectation calendar, and its own internal validation calendar. Reference data governance is largely the discipline of keeping those three aligned and documenting the alignment.

A Governance Operating Model for Reference Data

The remedy is not a new committee. It is a small number of named decisions with named owners, attached to a release calendar. Below are the five decisions that have to be owned by someone specific, and what each one actually requires.

Decision 1: Adoption timing

Who decides the date on which each vocabulary version becomes effective in each system, and how far behind publication that date is allowed to sit. This decision has to account for external partners, because unilateral timing breaks data exchange. It should be recorded per vocabulary and per system, not as a single organization-wide policy, because a clinical data management system and a postmarketing safety database have genuinely different constraints.

Decision 2: Impact assessment before adoption

What gets examined between publication and adoption. At minimum this means running the publisher’s change files against your own holdings to answer four questions: which terms in our data became non-current, which terms in our data changed their hierarchy placement, which of our standing queries changed membership, and which outputs currently in production would move if regenerated under the new version. That last question is the one teams skip and the one that predicts the reporting surprise.

Decision 3: Revalidation scope

A terminology load is a change to a validated system, and it needs a scoped revalidation decision rather than either a full requalification or a silent pass. In practice the scope follows the impact assessment. If the release changed hierarchy placement for terms present in your data, the reporting and retrieval functions need verification. If the release only added terms in areas you do not use, the scope is correspondingly narrow. The decision worth documenting is the reasoning, because that is what an auditor will ask for.

Decision 4: Communication to downstream consumers

Every function that consumes coded data needs to know a version changed, ideally before it changes. That list is longer than most organizations assume: case processing, aggregate reporting, signal management, clinical data management, biostatistics and programming, regulatory operations, medical affairs, and any external partner receiving data. The communication should say what changed, what it affects, and what recipients need to do differently, if anything.

Decision 5: Retention and reproducibility

Someone has to decide how long prior versions are retained and how an output produced two years ago can be reproduced. This is the decision most often left implicit, and it is the one that determines whether you can answer a reviewer’s question about a historical table. If prior versions are not retained, the honest answer is that the output cannot be regenerated, which is a poor position to be in.

Decision Natural owner Consulted Evidence produced
Adoption timing Data governance lead, with the process owner for the affected system Partners and vendors exchanging coded data Version register entry with effective date per system
Impact assessment Terminology or coding lead Signal management, biostatistics, regulatory operations Assessment record listing affected terms, queries, and outputs
Revalidation scope Quality assurance, with system validation lead IT, application owner Scoped test evidence and a documented rationale for the scope
Downstream communication Data governance lead All consuming functions Distributed change notice with acknowledgment
Retention and reproducibility Records or archiving owner Regulatory, IT infrastructure Retention rule per vocabulary plus a demonstrated regeneration path

The artifact that makes this work

A version register. One table, maintained centrally, with a row per vocabulary per system: vocabulary, publisher, current version in force, effective date in this system, previous version, date of the impact assessment, revalidation reference, and the named owner. It is unglamorous and it answers most of the questions an inspector or a reviewer will ask. Organizations that have one rarely have a reference data problem. Organizations that do not almost always do.

Where to Start

Most organizations do not need a transformation program for this. They need a short, sequenced effort that produces a register, an owner, and a repeatable assessment. The following sequence works for a mid-size pharma or biotech organization and can generally be completed within a quarter.

1

Inventory what you are actually running

List every externally published vocabulary in use, every system that holds a copy, and the version each system currently has loaded. Include vendor-hosted systems, because a hosted safety platform still has a version and you still depend on it. Expect the list to be longer than anyone predicted, and expect at least one system to be materially behind.

2

Build the release calendar

Put every publisher’s cadence on one calendar for the next twenty-four months. MedDRA on 1 March and 1 September. WHODrug on the same two dates. CDISC Controlled Terminology at each quarter end. LOINC in February and August. SNOMED CT monthly. This single view usually changes the conversation, because it makes visible how often something is changing underneath the data.

3

Name owners and write the versioning procedure

One named owner per vocabulary, with the five decisions from the previous section written into a short procedure. Keep it short deliberately. A two-page procedure that is followed is worth more than a twenty-page standard that is referenced once a year.

4

Run one real impact assessment end to end

Take the next scheduled release and work it through the full process, including the question of which production outputs would move. The first pass will be slow and will surface gaps in tooling and access. That is the point. Fix those before the process becomes routine rather than after.

5

Add version declarations to outputs

Change report templates so that aggregate safety tables, pooled datasets, and submission deliverables state the terminology version used to produce them. This is a small change with a large effect on defensibility, and it is usually the easiest item on the list to complete.

6

Close the partner gap

Confirm adoption timing with every external party you exchange coded data with, and write it into the relevant agreement or exchange specification. Where timing cannot be aligned, agree in advance how the overlap period is handled.

Two additions are worth considering once the basics are in place. The first is a periodic reconciliation that confirms the version actually loaded in each system matches the version the register says is in force, because drift between the register and reality is common. The second is a retrospective comparability check on any long-running trend that leadership relies on, to establish whether a visible change in the data corresponds to a terminology change rather than a real one.

Conclusion

Reference data is the least visible dependency in a regulated data estate and one of the most consequential. It arrives from outside, it changes on a schedule nobody inside the company set, and it changes the meaning of data that is already recorded without breaking anything a validation test would catch. The organizations that handle this well are not the ones with the most sophisticated tooling. They are the ones that treat each terminology release as a change with an owner, an assessment, a scoped revalidation, and a notification, rather than as a file to be loaded.

The single most useful shift in thinking is to stop treating the version as a property of the system and start treating it as a property of the data and of every output derived from it. Once a report declares the version that produced it, and once a register records which version was in force where and when, most of the hard questions become answerable. Comparability across periods becomes something you can demonstrate rather than something you hope holds. And version drift stops being a hidden variable in the numbers your leadership team is using to make decisions.

Sakara Digital works with pharma and biotech organizations building the data governance foundations that regulated analytical work depends on. If you are looking at your own reference data, whether that means naming an owner for the first time or tightening a process that already exists, and you want an independent perspective on where to start, we are happy to have that conversation.

For Further Reading

For Further Reading