Master and Reference Data Governance Across GxP Systems

A country code, product identifier, site status or deviation category can change workflow routing, access, report populations, retention and regulatory interpretation across many systems. The value may look simple; its consequences are architectural.

This page addresses the complete operating model for shared controlled data. It is distinct from choosing a system of record for one field. Authority is one decision inside a broader lifecycle of definition, approval, distribution, use, change, monitoring and retirement.

Define master and reference data operationally

Master data describe relatively stable business entities shared by processes: products, materials, sites, organisations, suppliers, studies, instruments, users or markets. Reference data provide controlled sets used to classify or constrain other data: countries, units, reason codes, lifecycle categories, severities or controlled vocabularies.

The boundary is contextual. A list of laboratories may be master data in one architecture and reference data in another. What matters is whether a value is reused, who controls it, how changes propagate and which regulated outcomes depend on it.

Treat a dataset as governed when an incorrect, missing, duplicated, late or retired value could alter a GxP record, decision, workflow, security rule, report or interface. Do not restrict the inventory to a central master-data tool; local application lists and spreadsheet lookups can have the same consequence.

Inventory data domains and consumers

Create a domain inventory covering:

• business definition and scope;
• entities, attributes and value sets;
• authoritative sources and fields;
• owners, stewards and custodians;
• creating and approving processes;
• consumer systems, reports and interfaces;
• workflows, security and calculations driven by the data;
• update frequency and latency tolerance;
• retention and historical interpretation;
• current quality and known exceptions.

Map both direct and indirect consumers. A Vault workflow may use a product attribute replicated from ERP; a report may group records by a local mapping; an integration may filter inactive sites. The central source may not know these downstream dependencies unless they are registered.

Define the data concept before the value

Write a controlled definition that distinguishes the concept from adjacent concepts. “Site”, “product” and “country” are often ambiguous. A manufacturing site, legal entity, clinical site and document-applicability site are not interchangeable.

For each domain specify inclusion and exclusion, granularity, lifecycle, relationships and examples. Identify whether the entity represents a legal, physical, commercial, regulatory or operational thing. Define which attributes make two records the same entity and which create a distinct entity.

Use a glossary with stable concept identifiers. Labels can vary by language or application; the governed concept should remain clear. Preserve definitions historically where a changed meaning affects retained records.

Assign authority at field level

One system rarely owns every attribute of a shared entity. An ERP may own material code and manufacturing status, RIM may own regulatory market status, and a quality platform may own a local risk classification.

For every consequential attribute, define:

• system authorised to originate it;
• role authorised to approve it;
• systems allowed to propose or correct it;
• precedence when values conflict;
• timing and effective-state rules;
• local extension policy;
• reconciliation and escalation.

Distinguish record authority, field authority and decision authority. A central platform can store the record while a business function remains accountable for whether a status is valid.

The existing Navata system-of-record page supplies the bounded authority method. This pillar continues through the complete shared-data lifecycle.

Separate ownership, stewardship and custody

The data owner is accountable for definition, authorised use, quality expectations, access and material change. The steward operates the rules: reviews requests, resolves duplicates, monitors quality and coordinates consumers. The system custodian configures or runs the platform. Process owners determine how the data are used in regulated work.

Avoid assigning every role to “IT” or “the business”. Name roles with exercisable authority. Define deputies and escalation. A steward should be able to reject an invalid request; an owner should understand downstream consequence rather than approve a list abstractly.

Create a responsibility table for definition, creation, approval, distribution, correction, merge, retirement, mapping, monitoring, incident response and periodic review. Where responsibilities cross organisations, include contractual obligations and evidence access.

Use stable identifiers

Assign identifiers that persist through rename, ownership change, reorganisation and system migration. Keep human-readable codes where they support work, but do not make a mutable label the sole integration key.

Define global identifier, source-system identifier and consumer-system identifier. Preserve crosswalks and history. Prevent reuse after retirement when it could confuse old records.

For products and organisations, determine granularity carefully. A product family, marketed product, material and presentation may need distinct identifiers and relationships. One broad “product code” can produce ambiguous reporting and access.

Manage duplicate detection using defined match rules and human judgement. Record why records were merged or kept distinct, and preserve previous identifiers as aliases where safe.

Govern naming and labels

Names are not merely cosmetic when users select them, reports group them or procedures refer to them. Define official name, short name, synonyms, language variants and display rules.

Separate label changes from concept changes. Correcting spelling may not alter meaning; changing “Critical” to “High” may affect procedure and report interpretation. Preserve code and historical label where needed.

Avoid abbreviations that differ between systems. Use descriptions and context. For multilingual data, identify authoritative translation and effective date.

Design hierarchies and relationships

Master data often form hierarchies: organisation to site, product family to product, study to country to site, material to specification. Define relationship meaning, direction, cardinality, temporal validity and ownership.

Do not assume a permanent tree. A site may serve several organisations; a product may change portfolio; a supplier relationship can be time-bounded. Model many-to-many and effective periods where the process needs them.

Changes to hierarchy can alter inherited security, reporting and workflow. Include descendants and consumers in impact assessment. Preserve historical structure where old records must be interpreted according to the hierarchy valid then.

Govern controlled vocabularies

For each value define stable code, label, description, inclusion criteria, exclusions, hierarchy, synonyms, permitted transitions, effective date and retirement treatment. Identify the standard or organisation from which it originates where applicable.

Require a justified request stating the business need and affected consumers. Check whether an existing value already covers the concept. Assess reporting, workflow, validation, training, interfaces and historical records.

Avoid proliferating values to solve temporary local needs. Use attributes, relationships or local extensions when they preserve the global concept more accurately. Conversely, do not force unlike local concepts into one value merely to claim harmonisation.

Create and approve values through controlled workflow

A request should identify domain, proposed value, definition, source evidence, relationships, effective date, intended consumers, requester and urgency. Stewardship checks completeness, duplicates, naming and standards. Data ownership approves meaning and use; system teams implement only after approval.

Use emergency creation sparingly. Define temporary code, restricted consumers, expiry, retrospective approval and reconciliation. Prevent “temporary” values from becoming permanent without governance.

Retain request, review, approval, implementation, distribution and verification. The audit trail should connect the business decision to technical changes in every authoritative component.

Use effective dates explicitly

Separate approval date, publication date, effective-from date, effective-to date and technical deployment time. They answer different questions.

A value may be approved today for use next month. Consumer systems receiving it early should not allow premature selection. Systems receiving it late may block legitimate work or use an obsolete value.

Define whether historical records display the value label valid at transaction time or the current label. Preserve temporal relationships and mappings where regulatory interpretation depends on historical state.

Coordinate effective dates with procedures, training and releases. Monitor consumers that cannot support future-dated values and define controlled sequencing.

Change data without changing history silently

Classify changes:

• descriptive change with no semantic effect;
• semantic change to definition or inclusion;
• structural change to hierarchy or relationship;
• operational change to status or availability;
• corrective change to inaccurate data;
• merge, split or retirement;
• identifier or mapping change.

Assess existing records, active workflows, reports, security, interfaces, procedures and training. Decide whether to update historical records, preserve the old value, derive a new representation or create a new concept.

Do not overwrite a value when the meaning changed materially. Create a new version or code and preserve the transition. Document the rationale and consumer disposition.

Merge duplicate entities carefully

Choose surviving identity, attribute precedence, relationship transfer, historical display, interface behaviour and redirection. Identify records and workflows referencing each duplicate.

Test reports, security and integrations. A merge can broaden access or combine populations unexpectedly. Preserve retired identifiers as aliases without allowing new use.

Reconcile every consumer and investigate transactions during the merge window. Record why the entities were determined to be the same and who approved the decision.

Split an entity when one identity is no longer adequate

A product, site or organisation may need separation after divestiture, regulatory change or discovery that one record conflated distinct concepts. Define new identities, effective period and allocation rules.

Decide which historical records remain with the original, which relate to new entities and how cross-period reporting works. Avoid retrospective rewriting that implies the new structure existed earlier.

Coordinate security, workflow and interface changes. Provide users with transition guidance and prevent selection of the wrong successor.

Retire values without deleting meaning

Retirement should prevent inappropriate future use while preserving historical records. Define replacement, effective-to date, in-flight record behaviour, open workflow handling, report treatment and interface mapping.

Do not delete a value from configuration if old records then become blank or unreadable. Preserve code, label and definition for retention. Distinguish inactive from invalid.

Monitor continued new use after retirement and correct distribution failures. Retire mappings and local aliases in a controlled sequence.

Distribute data through defined contracts

For each consumer, specify entity and fields, identifiers, format, timing, change events, effective-date handling, full versus delta load, deletion or retirement semantics, acknowledgement, retry and reconciliation.

Do not make every consumer infer meaning from a generic extract. Publish definitions, schema and value versions. Distinguish technical delivery from business acceptance.

Use idempotent or duplicate-safe processing where possible. Define out-of-order handling. Preserve transaction correlation from authoritative source through middleware to consumer.

Register interfaces so the data owner knows where a change travels. Point-to-point extracts outside the inventory create invisible consumers.

Map values transparently

Mapping may be one-to-one, many-to-one, one-to-many, conditional or unresolved. Record source and target concepts, codes, effective periods, rationale, owner, approval and confidence or exception where relevant.

Do not map labels by string similarity. Confirm business meaning and granularity. A source “Closed” state may correspond to several target states depending on closure type.

Version mappings and retain the version used for each migration or transaction where needed. Test blank, unknown, retired and new values. Define what happens when no mapping exists: reject, hold, use controlled “unknown”, or route to stewardship.

Many-to-one mapping loses distinction. State whether that loss is acceptable and whether provenance must preserve the source detail.

Reconcile source and consumers

Reconciliation asks whether expected data reached each consumer accurately and on time. Compare identities, counts, critical attributes, status, effective periods and relationships. Account for successful, rejected, pending, duplicate and intentionally excluded records.

Use independent source and target queries where practicable. Do not rely solely on middleware success logs. Reconcile by meaningful population, not only global totals.

Define frequency from consequence and change rate. Assign owners for discrepancies and ageing. A late product status can be more serious than a permanently wrong descriptive field; prioritise accordingly.

Retain reconciliation evidence and correction links. Trend repeated failures by interface, domain, value type and root cause.

Monitor data quality

Define rules for completeness, uniqueness, validity, consistency, timeliness and relationship integrity. Connect each rule to a business consequence and owner.

Examples include duplicate global identifiers, inactive values used on new records, missing effective dates, orphan sites, inconsistent product status, unmapped local codes and consumer lag beyond tolerance.

Use thresholds carefully. One invalid critical material can matter more than a thousand missing descriptions. Review exceptions rather than hiding them inside an aggregate score.

Monitor at source and consumer. Clean source data can still be corrupted by mapping or delayed distribution. Preserve rule version and population so trends remain interpretable.

Correct shared data with end-to-end control

Classify whether the defect originated in definition, source entry, mapping, distribution or consumer processing. Contain further use if necessary.

Approve the correction, identify affected systems and records, implement in the right sequence, verify distribution and assess decisions made from the wrong value. Preserve before-and-after values, reason, identity and evidence.

Avoid correcting only the visible consumer while leaving the authoritative source wrong. Conversely, a source correction is not complete until consumers reconcile.

For bulk remediation, version selection and transformation logic, test it, preserve record-level outcomes and resolve exceptions.

Design access and segregation

Restrict who can propose, approve, create, modify, merge and retire data. Separate business approval from technical administration where risk warrants.

Assess privileged and integration routes. A central data steward may need broad view access but not authority to approve every domain. Local stewards should not alter global definitions without process.

Test positive and negative access in relevant lifecycle states. Review assignments and emergency access. Preserve historical role context for consequential changes.

Avoid giving consumer administrators local edit capability for centrally authoritative fields unless reconciliation and conflict rules explicitly support it.

Preserve audit trails and decision evidence

Capture creation, changes, merges, splits, retirements, mapping changes and approvals with identity, time, before-and-after context and reason. Link technical changes to requests and data-owner decisions.

Review events capable of altering regulated meaning or broad downstream behaviour. A change to a country classification or product status can affect many records without editing them directly.

Retain audit history and definitions as long as needed to interpret consumer records. A value code without its historical meaning is insufficient.

The audit-trail pillar provides the complete capture and review method; this article identifies master/reference-data events that belong in scope.

Validate data-management controls

Validation should cover the intended use of authoritative and consumer services, configuration, workflow, access, interfaces, mappings, reconciliation and reports.

Test value creation, duplicate prevention, approval, future effective date, modification, invalid transition, merge, retirement, distribution, missing mapping, retry, duplicate message and reconciliation. Include boundaries and representative consumers.

Verify historical records after label and status changes. Confirm workflows, security and reports respond correctly. Test failure and recovery when the authoritative service is unavailable.

Supplier platform evidence may support standard functions; customer evidence remains necessary for definitions, configurations, mappings and cross-system operation.

Integrate change control

Treat data changes as potential system and process changes. Assess consumers, requirements, configuration, reports, interfaces, procedures, training and validation evidence.

Define change categories and approval levels. An urgent descriptive correction may follow a different path from a new global product hierarchy, but both need traceability.

Use a consumer-impact register and require disposition before effective date. Confirm implementation and reconciliation afterwards. Close the change only when downstream states are known.

Govern local variants

Local values may be legitimate because of jurisdiction, language, process or application need. Define when local extension is permitted, its owner, relationship to global concepts and visibility.

Prevent local values from entering enterprise reports without mapping. Monitor near-duplicates and requests that reveal a missing global concept. Periodically decide whether to promote, retain or retire them.

Avoid forcing local regulatory distinctions into a coarse global value. Harmonisation should preserve meaning, not erase necessary differences.

Govern supplier-managed data

Suppliers may provide drug dictionaries, country codes, safety terminology, product data or hosted master-data services. Assess source authority, update process, versioning, notification, correction, licensing, retention and exit.

Define customer acceptance and effective date. A supplier update may contain many new or changed values; determine which are applicable and how consumer impact is assessed.

Preserve the version used for historical processing. Contract for access to definitions, change information, incident support and data export. Plan continuity if the feed is late or unavailable.

The regulated customer remains responsible for its use and mapping of supplied data.

Manage acquisitions, divestitures and mergers

Compare definitions, identifiers, hierarchies, value sets, ownership and consumer dependencies before consolidation. Do not merge by label alone.

Choose target concepts, mapping, coexistence period and identity strategy. Preserve legal and historical distinctions. Define cutover, interface sequencing, reconciliation and retirement.

Address records created during transition and changes made in both organisations. Establish temporary governance with clear authority. Record unresolved mappings rather than forcing false equivalence.

After consolidation, monitor duplicates, local workarounds, report changes and access consequences.

Govern migration

Profile source domains and values, define target concepts, approve mappings and transformations, execute trial migrations and reconcile by entity, attribute, relationship and effective period.

Preserve source identifiers, definitions and mapping versions. Verify that historical records retain the intended meaning. Handle retired and local values explicitly.

Do not treat successful target validation as proof of semantic correctness. Data owners should approve the target interpretation and exceptions.

Coordinate migration with consumer interfaces and freeze windows. Prevent divergent changes during cutover and reconcile after service resumes.

Design continuity and fallback

Determine how regulated processes operate when the authoritative data source or distribution service is unavailable. Consumers may use cached values, but define currency, permitted duration and prohibited high-risk actions.

Queue changes safely and prevent conflicting local edits. Provide controlled emergency-value procedures where necessary, with temporary identifier, restricted scope, approval, expiry and later reconciliation.

Test recovery, backlog processing, out-of-order changes and duplicate handling. Communicate which data state is valid during degraded operation.

Manage historical interpretation

Records must often be understood using the values and structures valid when they were created or approved. Preserve effective-dated labels, definitions, hierarchy and mappings where they affect meaning.

Reports should state whether they use current or historical classification. Reclassifying old records under a new taxonomy can be useful for trend analysis but should not be confused with the original regulated record.

Maintain translation layers deliberately. A current enterprise dashboard may show harmonised categories while inspectors need the original code and contemporaneous definition.

Establish governance forums

Use domain stewardship forums for routine requests and quality issues. Use a cross-domain governance body for conflicts, shared identifiers, enterprise standards and changes affecting several systems.

Provide decision-ready evidence: definition, alternatives, consumer impact, risks, implementation sequence and owner recommendation. Record decisions and dissent where material.

Avoid making the forum a bottleneck for every minor correction. Define delegated authority and service expectations. Measure overdue decisions and emergency requests.

Operate a data issue process

Users need a route to report missing, duplicate, inaccurate or ambiguous values. Capture domain, record, consequence, affected consumers, urgency and supporting evidence.

Stewardship triages, contains and investigates. Data owners decide semantic questions. System teams implement controlled corrections. Quality assesses affected GxP records and decisions.

Communicate status to reporters and consumers. Close only after reconciliation. Trend root causes including unclear definition, training, interface failure and inadequate ownership.

Review the service periodically

Review domain definitions, ownership, value growth, duplicate and retirement trends, quality exceptions, interface failures, reconciliation, emergency changes, access, supplier changes, audit findings and consumer inventory.

Confirm every active consumer remains registered and every authoritative source remains appropriate. Assess whether organisational or regulatory change altered concepts.

Test archive retrieval and historical interpretation. Review unresolved local variants and mappings. Produce owned actions and a service disposition.

Measure governance without rewarding volume

Useful indicators include time to approve critical changes, distribution latency, unreconciled discrepancies, invalid new use of retired values, duplicate rate, unmapped transactions, emergency creations, overdue corrections and consumers without current contracts.

Do not reward stewards for number of new values created. High throughput can indicate taxonomy fragmentation. Pair quantitative measures with review of business consequence.

Use leading indicators such as pending effective-date coordination and consumers that cannot accept a planned change. Monitor whether corrections repeatedly affect prior decisions.

Maintain the governance artefact set

Proportionate records include:

• domain and concept catalogue;
• data dictionary and controlled vocabulary;
• authority matrix;
• owner/steward register;
• global identifier and crosswalk register;
• relationship and hierarchy model;
• consumer and interface register;
• mapping specifications;
• request, approval and change records;
• quality rules and issue register;
• reconciliation evidence;
• access model and audit trails;
• validation and periodic-review evidence;
• merger, migration, continuity and retirement plans.

Keep them connected. A controlled vocabulary should identify consumers; a change should identify impacted mappings; an issue should link correction and reconciliation.

A lifecycle control model

This is a Navata Library operating model, not a regulatory framework.

Worked example: a site closes while records remain active

A manufacturing site is marked inactive in the enterprise master. QMS has open deviations, QualityDocs has effective procedures classified to the site and a reporting warehouse receives a nightly feed.

The change cannot be treated as one status update. The data owner defines the effective date and meaning of inactive. Process owners decide how open records continue. Security owners assess access. Document owners determine whether procedures remain retrievable. Interfaces distribute the change in sequence. Reports distinguish historic site activity from new selectable sites.

Reconciliation confirms every consumer received the status. Monitoring prevents new records from selecting the site after effect while permitting authorised completion of existing work. Historical records retain the site name and identifier valid when created.

Worked example: two deviation categories are merged

Two categories appear similar and management wants one global dashboard value. Review shows that one category triggers a regulatory timeline in one country while the other does not.

A simple many-to-one mapping would erase a material distinction. The governance body retains separate source concepts, creates a higher-level reporting group and documents when the aggregate may be used. Interfaces preserve source codes; the warehouse derives the reporting group with versioned logic.

The outcome delivers harmonised reporting without rewriting regulated meaning. This is the difference between controlled equivalence and cosmetic standardisation.

Boundaries and regulatory precision

EU GMP Annex 11 contains relevant expectations for lifecycle risk management, data accuracy, security, change control and periodic evaluation. MHRA data-integrity guidance addresses data lifecycle and governance concepts. ICH Q9(R1) supports proportionate quality-risk decisions.

ISO 8000-61 provides a general reference-data-quality-management model; it is not pharmaceutical regulation and the linked ISO page is descriptive rather than free full text. This article does not claim that regulations prescribe the terms data owner, steward, consumer register or the lifecycle table above. Those are practical governance structures.

Define requirements for the shared-data service

Requirements should describe the business service, not only the master-data application. State the domains, authoritative attributes, users, consumers, approval, effective dating, distribution, reconciliation, access, audit, continuity and retention.

For a product status, for example, require that an approved future-dated change becomes selectable in authorised consumers on the effective date, does not rewrite historical records, reaches registered systems within the accepted interval, creates an exception where mapping is absent and remains reconstructable with actor, reason and prior value.

Trace requirements to source configuration, workflow, interface contracts, consumer behaviour, reports and procedures. Include manual and emergency routes. Reassess whenever a new consumer or use relies on the data.

Classify domain criticality

Assess consequence of an inaccurate, missing, duplicated, late or unavailable value. Consider workflow routing, access, calculations, report populations, record identity, retention, regulatory commitments and patient or product decisions.

Classify at attribute and use level, not only domain. A supplier phone number and qualification status may live on the same record but have different control needs.

Use classification to set approval, verification, distribution timing, reconciliation, review, continuity and change evidence. Document why lower-control fields cannot alter the regulated outcome.

Review criticality when new consumers or derived uses appear. A field can become consequential without changing in the source.

Create a canonical domain model

Define entities, attributes, relationships, identifiers, lifecycle and temporal rules independent of any application. Include examples and counterexamples. Show where concepts overlap or differ.

Do not confuse canonical model with one huge physical database. It is a shared semantic contract. Systems may implement different subsets and structures while mapping visibly to the governed concepts.

Version the model. Preserve which version applied to historical transactions. Changes should identify consumers and migration needs.

Use the model to resolve requests, mappings and merger decisions. If two teams cannot agree whether records represent the same concept, do not proceed directly to technical integration.

Govern global and local identifiers

Define how identifiers are created, reserved, validated, distributed and retired. Prevent collision across regions, acquired companies and offline operations.

Use immutable identifiers for integration and retain display codes for human work. Document when a business code may change. Preserve aliases and previous identifiers without permitting ambiguous new use.

For supplier-provided identifiers, assess stability, licensing and exit. For compound identifiers, define component semantics and what happens if an organisational element changes.

Test duplicates, invalid format, concurrent creation and restoration. Reconcile identifier crosswalks and restrict manual alteration.

Govern units of measure

Units are reference data with calculation and reporting consequence. Define code, symbol, dimension, precision, conversion basis, allowed contexts and effective period.

Avoid free-text units. Preserve original measured value and unit when converting. Version conversion rules and test rounding and boundary conditions. Distinguish mass, concentration, potency and presentation concepts rather than mapping by label.

Determine the authoritative standards source and local regulatory variants. Control additions and synonyms. Reconcile interfaces that use different codes.

Historical records should remain interpretable if a preferred unit changes. Reports should state whether values are displayed in original or normalised units.

Govern country, language and jurisdiction data

Country codes can drive reporting, product applicability, privacy, security, retention and submission. Define whether the concept is sovereign state, market, regulatory jurisdiction, shipping destination or site location.

Use stable codes from an authorised standard where appropriate, but govern local business extensions. Preserve historical states and effective dates. Do not overwrite records when geopolitical or regulatory structures change.

Manage language and locale separately. A language code does not by itself establish approved translation or market applicability.

Assess every downstream rule when country or jurisdiction mapping changes.

Govern product and material data

Separate product family, medicinal product, presentation, pack, material, substance, batch and regulatory application. Define relationships and authoritative attributes.

Status may differ by process: commercially active, manufacturable, approved in a market, quality-active or selectable in a Vault. Name each state precisely.

Control identifiers, composition, site relationships, effective dates and changes. Prevent local duplicate products created because the authoritative record arrived late.

For divestiture or acquisition, preserve historical ownership and product identity. Reconcile reports and records across transition.

Govern organisation, supplier and site data

Distinguish legal entity, operating organisation, physical site, department, supplier and service relationship. A single supplier may have several legal entities and qualified sites.

Qualification status belongs to a relationship and scope, not necessarily the organisation universally. Model product, service, site and effective period. Avoid a global “approved supplier” flag used beyond its meaning.

Control addresses, regulatory identifiers, names, ownership and mergers. Preserve aliases for historical retrieval. Define who can create temporary organisations during urgent work.

Assess access and confidentiality when organisational relationships change.

Govern user and role reference data

User identities may be mastered in HR or identity systems while business roles, training and regulated assignments reside elsewhere. Define authority for employment status, manager, location, professional role, application role and delegation.

Do not use current user attributes to rewrite historical attribution. Preserve immutable identity and assignment periods. Reconcile joiner, mover and leaver events.

Where workflow routing depends on user master data, test absence, conflicting roles, delegation and delayed updates. Monitor unassigned tasks and excessive privilege.

Privacy and minimisation apply; distribute only attributes consumers need.

Govern study, protocol and clinical reference data

Define study identity, protocol version, country, site, product and status relationships. Separate planned, active, closed and archived states by intended use.

Preserve protocol-version and effective-date context. A site can be active for one study and closed for another. Avoid broad site status reused incorrectly.

Control imports from clinical systems and mappings into quality, safety or document platforms. Reconcile identity and status. Protect blinding and restricted information.

Govern quality classifications

Deviation categories, severity, root-cause taxonomies, CAPA types and effectiveness statuses influence routing, reporting and trending. Define inclusion, examples, exclusions and decision authority.

Avoid changing labels to improve dashboards without assessing procedures and historical interpretation. Use hierarchical groupings for analysis while preserving original classifications.

Monitor “Other” and free-text use; high use may show a missing concept or poor training. Review reclassification patterns and their effect on prior decisions.

Control local regulatory categories and mappings to enterprise groups.

Control reference data embedded in configuration

Some values live in application picklists, workflow rules, code, report formulas or middleware tables rather than a master-data platform. Inventory them as part of the domain.

Assign ownership and change control. Version and compare across environments. Prevent developers or administrators from changing business meaning without data-owner approval.

Include embedded values in consumer impact and reconciliation. Automated discovery can help but must cover external scripts, spreadsheets and procedures.

Move high-consequence duplicated tables to a more governed pattern where feasible; until then, use controlled distribution and comparison.

Govern denormalised and copied attributes

Consumers may copy names, statuses or classifications for performance, historical snapshot or usability. Define why the copy exists and whether it is current, point-in-time or informational.

Specify update trigger, direction, latency, conflict and reconciliation. Label historical snapshots distinctly. Prevent user editing if the source remains authoritative.

When a copied value drives a decision, treat synchronisation as a regulated control. Monitor stale values and define fallback during source outage.

At retirement, preserve the copy needed to interpret historical records even if live synchronisation ends.

Design publication and subscription patterns

Consumers may receive full extracts, deltas, events, APIs or scheduled files. Choose based on volume, latency, recoverability and consumer capability.

Define version, schema, sequence, acknowledgement and replay. Full loads simplify recovery but can overwrite local state; deltas require reliable ordering and gap detection. Event streams require idempotency and durable consumer offsets.

Provide a consumer onboarding contract and test pack. Register endpoints and owners. Monitor subscription health and deactivate obsolete consumers deliberately.

Handle out-of-order and concurrent changes

Use version numbers, effective times or sequence identifiers. Define how consumers reject stale updates and request missing versions. Do not rely only on arrival time.

Where two authorised sources change different attributes concurrently, preserve field-level authority. Where both propose the same attribute, use conflict workflow rather than last-write-wins unless explicitly justified.

Test delayed, duplicated and reversed messages. Reconcile after network or consumer outage. Preserve the final disposition and affected records.

Validate reconciliation logic

Specify population, fields, normalisation, timing and tolerance. Test known matches and mismatches, blank and null differences, time-zone and precision, retired values, duplicates and missing records.

Ensure security does not hide records from the reconciliation identity. Version queries and code. Independently verify logic before production reliance.

Preserve evidence of execution and exceptions. Monitor when source or consumer schema change. A reconciliation report can pass while omitting a new attribute unless its scope is governed.

Design exception queues

Unmapped, invalid, duplicate or conflicting data should enter a controlled queue with record identity, source, reason, time, attempted value, affected consumers and owner.

Define service expectations based on consequence. Prevent repeated automatic retries from hiding aged failures. Provide authorised correction and replay.

Preserve original message and resolution. Reconcile queue closure to final consumer state. Trend by cause and domain.

Avoid letting administrators choose arbitrary replacement values without data stewardship and business approval.

Manage emergency data changes

Define when an emergency path is justified, who approves it, minimum evidence, temporary restrictions and retrospective review. Use stable temporary identifiers and clear expiry.

Assess consumers and sequencing. A rapid central change that arrives only in some systems can create greater risk. Communicate limitations.

After the event, complete full documentation, reconcile every consumer, review use during the temporary state and decide whether the value becomes permanent or is retired.

Monitor emergency frequency; repeated urgent requests indicate planning, ownership or service-level failure.

Govern data freezes and cutovers

For migration, merger or release, define freeze scope, start, authorised exceptions, delta capture and end. Communicate to creators and consumers.

Prevent changes in uncontrolled side files. If urgent business updates occur, record and replay them in sequence. Reconcile source baseline, migration extract and post-freeze deltas.

Approve exit from freeze only after target and consumers are verified. Preserve the exact domain and mapping versions used.

Preserve evidence during supplier change

Before replacing a provider, export current and historical data, definitions, identifiers, versions, mappings, audit trails, issues and contractually required evidence.

Map new supplier concepts explicitly. Do not assume identical standard terminology. Run parallel comparison where justified and reconcile differences.

Control cutover, rollback and consumer updates. Preserve old versions for historical interpretation and meet licence constraints.

Validate the new end-to-end service and update ownership, continuity and inspection procedures.

Prepare for inspection and audit

Be able to show definition, owner, authoritative source, creation and approval, change history, consumers, distribution, reconciliation, exceptions and historical interpretation for a consequential value.

Select examples that crossed systems and changed over time. Retrieve evidence without relying on a single expert. Explain local variants and known issues.

Demonstrate that data changes are assessed for workflow, report, security and record consequences. Show correction and consumer reconciliation.

Avoid claiming one “golden record” eliminates all local responsibility. Explain field authority and controlled copies precisely.

Common failure patterns

Look for:

• domain definitions that differ by team;
• mutable labels used as identifiers;
• record-level ownership where field authority differs;
• qualification status stored on the organisation instead of scoped relationship;
• future-dated changes selectable too early;
• retired values deleted from historical records;
• local emergency values never reconciled;
• unregistered spreadsheet or warehouse consumers;
• mappings approved by technical teams without semantic ownership;
• reconciliation based only on counts;
• source corrections not propagated;
• copied attributes with no currency rule;
• supplier feeds with unknown version;
• mergers that collapse unlike concepts;
• data-quality scores hiding one critical error.

Each pattern points to a specific definition, authority, lifecycle or distribution weakness.

Implement governance in stages

Use a practical sequence:

1. inventory domains, values and consumers;
2. define high-consequence concepts and attributes;
3. assign owners, stewards and authority;
4. stabilise identifiers and mappings;
5. control creation, change, effective dating and retirement;
6. register and govern distribution;
7. implement reconciliation and exception handling;
8. validate consequential paths;
9. monitor quality and service performance;
10. address local variants, legacy data and supplier exit.

Do not wait for enterprise-wide perfection. Begin with domains whose failures change regulated decisions and expand with explicit scope.

Judge whether the data service is controlled

For one value, the organisation should answer:

• what concept it represents and excludes;
• which identifier persists;
• who owns meaning and approves change;
• which source and fields are authoritative;
• when the value became effective and ceased use;
• which consumers received it and under which mapping;
• how discrepancies are detected and resolved;
• which records and decisions used it;
• how historical meaning is retained;
• how outage, merger, migration and retirement are handled.

If the answer stops at the central source, shared-data governance is incomplete.

Sources

• European Commission, EU GMP Annex 11: Computerised Systems — lifecycle risk, data accuracy, security, change and periodic evaluation.
• MHRA, GxP Data Integrity Guidance and Definitions — data lifecycle and integrity expectations.
• EMA, ICH Q9 Quality Risk Management — official guideline page for science-based, proportionate quality-risk decisions.
• ISO 8000-61:2016, Data quality — Part 61: Data quality management: Process reference model — general data-quality-management process reference material used as supporting context; not a pharmaceutical or GxP requirement.