Metadata Management for a National Health Service

This strategy treats metadata as national infrastructure

Every national health service depends on information that describes its information. A diagnosis code means something only because a terminology defines it. A waiting-time figure can be compared between hospitals only if both count from the same event, and a dataset made available for research can be used safely only if its origin, coverage and known defects are recorded alongside it. That descriptive layer is metadata. It includes the definitions of data items, the code lists and reference data they draw on, the models and specifications that structure them, the record of where data came from and how it was transformed, statements about its quality and fitness for use, and the catalogues through which it is found.

This document sets out a draft strategy for managing that layer at national scale. It is written to be adapted. The strategy assumes a publicly funded health service operating nationally or through regional and devolved bodies, using a mix of international and local standards, and supplied by several system vendors. Terms in square brackets mark roles or institutions that an adopting country should assign to its own named bodies or organisations. Examples include [national health authority], [registration authority], [registry operator], [catalogue operator], [governance forum] and [domain stewards]. Where the strategy draws on the experience of particular countries, it does so because that experience is published and instructive, not because the arrangements described are the only workable ones.

The strategy has three aims. It makes the case that metadata management is a precondition for most of what a modern health service expects from its data, including exchange between care settings, national analytics, research, and the safe use of artificial intelligence. It explains why that case is repeatedly lost, so that the conditions which cause the loss can be addressed directly. And it proposes principles, capabilities, governance and a phased approach that a national body can fund and deliver without disrupting systems in use.

Its scope covers metadata wherever health data is defined: in exchange specifications, national data dictionaries and statistical returns, clinical record standards, terminology subsets, research datasets, local catalogues compiled by providers, and the documentation of datasets used to train or evaluate AI systems. It does not cover the content of patient records, the management of access rights to them, or the technical operation of individual systems, except where those depend on metadata.

This strategy focuses principally on nationally governed semantic and descriptive metadata: definitions, value domains, reference data, information requirements and the description of datasets. Technical metadata, including physical schemas, pipeline execution metadata and detailed operational lineage, remains the responsibility of individual platforms and organisations, but should reference nationally registered identifiers where appropriate. The strategy is therefore not a complete enterprise metadata management programme covering database design, data pipelines or system observability. It governs the shared meaning on which those activities depend.

The strategy sets firm commitments and leaves local decisions to the adopter

A generic strategy is useful only if it is clear about what adoption would mean. Some elements of this strategy are commitments: an organisation that adopted the strategy while setting them aside would not be implementing it. Other elements depend on the country’s institutions, budgets and timetable, and are deliberately left to the adopting organisation. Table 1 sets out the division.

The commitments describe how metadata is governed and used. They do not prescribe which organisation hosts the registry, what it costs, how quickly coverage grows or which technology is used. Those decisions belong to the adopting organisation, which is better placed to judge them, and the strategy is written so that it remains valid whichever choices are made.

Meaning does not travel with data unless it is managed

Health data is exchanged, aggregated and reused far more than it was designed for. A blood test result recorded in a laboratory system may be displayed in a hospital record, sent to a general practitioner, counted in a national return, included in a research extract and used to evaluate a clinical algorithm. At each step a different organisation interprets it. The value travels easily. What the value means, how it was measured, under what conditions it is reliable and which definition it conforms to does not travel unless someone has recorded it in a form the next user can find and trust.

Interoperability standards have improved the movement of data considerably. HL7 FHIR, openEHR, SNOMED CT and established messaging standards give national health services common ways to structure and code information. They do not, by themselves, ensure that two organisations using them mean the same thing. FHIR is designed to be adapted through profiles, and two profiles that each conform to the standard can bind the same clinical concept to different code lists or apply different constraints. Validation confirms that data conforms to the profile it claims. It cannot confirm that the profile’s commitments match those of another profile, because nothing records which shared definition each was meant to implement. Structural conformance, in other words, does not produce shared meaning.

The consequences are operational. National analytics depend on consistent coding, and data recorded against a divergent definition is silently excluded from a query or counted in the wrong category. Shared and longitudinal records assembled from several sources appear unified while carrying inconsistent meaning underneath. Clinical safety depends on the sender and the receiver of information understanding it in the same way, and every point at which meaning is reconciled by hand is a point at which it can drift. Research reproducibility depends on knowing exactly which definitions and transformations produced a dataset.

Artificial intelligence is exposed to the same weakness. Models trained or evaluated on data drawn from sources with inconsistent definitions can learn differences in recording practice as though they were clinical patterns. The result can be bias between populations or settings whose data was defined differently, or associations that reflect how data was captured rather than what happened to patients. Because such patterns are reproduced automatically and at scale, they are harder to detect than the same inconsistency in a manual analysis.

Metadata management is also the means by which a health service retains control of its own information. Where definitions, mappings and transformation rules are held only inside a supplier’s product or a platform’s configuration, the meaning of the data becomes difficult to move. Changing supplier, or ending a platform contract, then requires the meaning to be reconstructed. A health service that governs its metadata independently of the systems that use it keeps the ability to change those systems.

Regulation is moving in the same direction. Within the European Union, the European Health Data Space Regulation requires health data holders to describe the datasets they make available, provides for national dataset catalogues, and introduces a data quality and utility label for datasets made available for secondary use [1]. Research funders and journals increasingly expect data to be findable, accessible, interoperable and reusable, which in practice means described by rich, machine-readable metadata [2]. National statistical systems have long treated metadata as a condition of publishing official statistics, and have international standards for exchanging it [3, 4]. A health service that cannot describe its own data consistently will find each of these obligations harder and more expensive to meet.

The same meaning is defined many times, by people who cannot see each other’s work

In most national health services, the meaning of a given item of information is defined in several places at once. An exchange specification defines it for messages between systems. A national data dictionary defines it for statistical returns. A clinical record standard defines it for what a patient record should contain. Programme specifications add further definitions as programmes need them. Providers compile their own catalogues to understand what their systems hold, and research platforms define their own variables. Each of these products is usually well maintained within its remit. The difficulty lies between them: they describe overlapping information, yet none can refer to another by a shared, permanent identifier, because no such identifiers exist.

Published specifications in the United Kingdom show the pattern. Ethnic category is carried in a dedicated extension in UK Core, the national FHIR implementation guide [5], and is defined separately in the NHS Data Model and Dictionary for national data collections [6]. Neither publication cites the other by a shared identifier. The Core Information Standard, the national standard for the content of patient records, was revised in April 2026 to change how sex and gender are recorded, in response to an independent review of data and research on sex and gender [7]. The published change applies to that standard alone. Nothing in it identifies the other national products that carry sex or gender, such as exchange specifications and statistical collections, so each has to be found and assessed through its own process. This pattern is not peculiar to the United Kingdom. It follows from defining meaning inside products rather than registering it independently of them, and is likely to be present in any health service with several standards bodies and programmes.

The cost of this arrangement is real but dispersed. National standards teams repeat the work of finding and changing copies each time a definition moves. Suppliers spend effort establishing, for each customer and each release, whether a change affects meaning or only structure. Providers rebuild links to national definitions that other providers have already built, and their results cannot be compared. Analysts reconcile definitions by matching names. None of this effort appears as a line in any budget, which is part of why it persists, and one purpose of the first phase of this strategy is to measure it.

Metadata is overlooked for structural reasons, not through lack of goodwill

The case for metadata management is not new, and most informaticians accept it. It is nonetheless repeatedly deprioritised. The reasons are structural, and a strategy that does not address them is likely to fail in the same way as earlier attempts.

The first reason is visibility. Health services invest readily in things that can be seen and used: electronic records, patient applications, national platforms, analytical dashboards. Metadata is infrastructure that is noticed mainly when it fails, and its successful operation is indistinguishable from nothing happening. A definition that remains consistent across ten products generates no event, while the absence of that consistency appears months later as a failed analysis or a mismatched record, attributed to the system in which it surfaced rather than to its cause.

The second reason is the distribution of costs and benefits. The cost of describing data well falls on the organisation that creates it, at the time it creates it. The benefit falls on other organisations, later, when they reuse it. Programmes are funded and judged on their own delivery, and spending effort on metadata that mainly serves someone else’s future work is hard to justify within a programme’s business case. The rational choice for each programme is to define what it needs locally, and the sum of those rational choices is national duplication.

The third reason is ownership. Metadata sits between disciplines. Clinicians define what information means in practice; terminologists maintain code systems; standards developers write specifications; data managers run dictionaries and catalogues; architects design the systems that use them. Each owns part of the picture and none owns the whole. In many health services no body is responsible for the meaning of health data independently of the product in which it appears, and responsibilities that belong to no one are rarely funded.

The fourth reason is a category error. Metadata is often treated as documentation, something written after a system is built to explain it, rather than as an operational asset that systems and people use at run time and at design time. Documentation is the first thing cut when a deadline approaches. A closely related confusion is between information governance, which concerns who may access data and under what legal basis, and data governance, which concerns what data means, how it is defined, maintained and changed, and whether it is fit for a purpose. Health services typically invest heavily in the first and lightly in the second, and metadata management falls into the gap.

The fifth reason is procurement. Health services buy systems, platforms and services. Contracts specify functions, availability and security in detail and say little about how the meaning of data held in the system is to be described, provided or retained. Where definitions and mappings are created inside a supplier’s product, the health service may not hold them in a form it can reuse, and the cost of that omission becomes visible only at the end of the contract.

The sixth reason is skills. Metadata management requires people who understand clinical meaning, information modelling, terminology and standards together. Such people are scarce, are usually employed on programme delivery, and have few career paths that reward the slow work of stewardship.

These causes reinforce one another. Invisible benefits make metadata hard to fund; lack of funding leaves it without an owner; lack of an owner leaves it to be done as documentation; and documentation done under delivery pressure is incomplete, which confirms the view that metadata is a low-value activity. The strategy that follows is designed to break that cycle at several points at once: by making the cost of duplication measurable, by assigning clear and limited responsibilities, by protecting the time of the people who do the work, by building registration into the processes through which specifications are produced rather than adding it afterwards, and by placing requirements on procurement.

The strategy rests on ten principles

The principles below are intended to hold regardless of the institutions or technologies a country uses. They are the tests against which proposals under this strategy should be judged.

Shared definitions should be registered authoritatively and cited where they apply. Each shared definition should have an authoritative, persistent registration, and products should cite that registration where applicable. Where a different definition is justified, it should be registered with its scope and its relationship to existing definitions made explicit. Registration does not require that every concept have a single context-free national definition, nor that all definitions be written by one body. It requires that definitions be findable, uniquely identified and related to one another.

Relationships between definitions should be stated, not inferred. Every registration that is not wholly new should record how it relates to existing registrations, using a governed vocabulary of relationship types. Two definitions may be equivalent, meaning interchangeable for all purposes within their stated scope. One may be broader or narrower than another, or derived from others, as a body mass index is derived from height and weight. A registration may be superseded by a later one. And two definitions may be incompatible, meaning that data recorded against one cannot safely be treated as data recorded against the other. Recording incompatibility is as valuable as recording equivalence, because it tells users where reconciliation would be unsafe. These six types form the minimum national relationship vocabulary, not the complete vocabulary. Experience will show the need for others, such as approximate mappings, composition, implementation of one item by another, and transformation from one item to another. The [governance forum] should be able to add governed relationship types, each with a published definition, rather than forcing every relationship into the initial set.

Models of meaning, models of use and the packaging of data should be kept apart. A model of meaning says what an item denotes: its definition and permitted values within a stated scope. A model of use says how a particular purpose employs that item: which items a record standard or a statistical return requires, and which are mandatory in a given setting. Packaging is how a particular technical standard carries the item. Most data definitions in health services are models of use, and they belong with the bodies that set them. Keeping the three apart allows meaning to be shared while use and packaging vary legitimately.

Registration must support both atomic data elements and composite information requirements. Much clinically meaningful information has internal structure: a blood pressure reading consists of systolic and diastolic values recorded together under shared conditions, and a medication statement combines a medicine, a dose, a route and a timing. Clinically meaningful structures should not be decomposed merely to fit an atomic registry model. The registry should be able to register a composite item as a whole, identify its components, and relate both to existing registrations, so that the meaning carried by the structure is preserved alongside the meaning of its parts.

Stewardship should be federated and registration coordinated centrally. The organisations that create and maintain definitions today should continue to do so as stewards of their own content. A [registration authority] should assign identifiers, check and record registrations, identify overlaps and coordinate their resolution, without writing standards itself or deciding questions of meaning on its own authority.

Specifications should cite fixed versions, and accountability should stay where it lies. Products cite registered items at a stated version and adopt later versions through their own change control and contracts. No system should inherit a change it has not chosen, and no operational system should depend on a live national service for each transaction: approved releases should be usable locally, with updates applied under control. Responsibility for a specification, including its clinical safety assurance and contractual obligations, remains with the body that publishes it and the organisations that deploy systems built on it.

Published versions should be stable and recoverable. Identifiers should never be reused or reassigned. A published version of a registration should never be altered; corrections are made by publishing a new version and recording the relationship between the two. Deprecation, withdrawal and replacement should follow published rules, and earlier releases should remain available so that any past use of a registration can be reproduced.

Metadata should be machine-actionable. Definitions, code lists and dependencies should be published in formats that tools read, through interfaces that implementers already use, so that metadata is consulted in the course of work rather than looked up separately. Machine-readable representations should preserve identity, provenance, relationships and version information, so that software consuming them, including automated and AI-assisted tools, can act on them without losing what makes a registration authoritative.

Semantic metadata should be open by default, and other metadata shared according to its sensitivity. National semantic metadata, identifiers and published specifications should be open by default. Publishing them openly reduces duplication, allows suppliers and researchers to build against them, and makes errors easier to find. Technical, operational and commercial metadata should be published or shared according to security, licensing and commercial-sensitivity requirements, and terminology content under licence remains subject to its licence terms.

Governance should be proportionate to reuse and build on what exists. A definition used across the national health service warrants rigorous review, while a provisional registration for a programme under delivery pressure warrants a quick route with a defined path to approval. Overhead that is not proportionate will be bypassed. ISO/IEC 11179 provides the established model for metadata registries [8], and terminology, exchange and statistical metadata standards already provide most of the connection points required. The strategy should use them rather than invent alternatives, and should begin with content that national bodies already publish.

What registration can assure, and what it cannot

Registration is often described as making information mean the same thing across systems. That claim goes further than registration can support. Registered definitions provide a common reference against which specifications, implementations and data can be assessed. They reduce avoidable differences in interpretation, but do not by themselves ensure correct capture, transformation or use. Implementation assurance and data quality management remain necessary complementary capabilities.

The distinction matters for every benefit this strategy claims. A shared record whose sources cite the same registered definition has removed one cause of inconsistency, but the record is consistent only if each source system captures and transforms the data correctly, which is a matter for conformance testing and clinical safety assurance. An analysis drawing on registered definitions can state exactly what each variable was meant to denote, but whether the data meets that intention is a question for data quality assessment. An AI model whose training data is documented against registered definitions can be evaluated against a known reference, but the documentation does not establish that the data was fit for the purpose. In each case registration makes the necessary assurance possible and cheaper. It does not replace it.

The three activities can be set out as a sequence, shown in Figure 1. Registration records intent: what an item of data is meant to denote and which values it may take. Conformance testing establishes whether a specification and the systems built on it implement that intent. Data quality assessment establishes what actually happened in the data those systems produced. Each stage depends on the one before it, because conformance cannot be tested without a stated intent and data quality cannot be judged without knowing what the data was meant to be. Every stage also needs its own capability and its own owner. The registry tells the health service what was meant; it does not tell it whether that meaning was implemented or achieved.

Five capabilities are required, operated by several organisations

A national health service needs five related capabilities to manage metadata. Few countries will need to build all of them from nothing; most will find partial versions in existing teams and services. These capabilities may be operated by different organisations. Shared identifiers, agreed interfaces and coordinated change processes connect them. The [registration authority] governs registration; each service owner remains accountable for operating and maintaining its service. Figure 2 shows that division, and Table 2 sets out, for each capability, the role responsible, its principal outputs and its dependencies on the others.

These capabilities support a single information architecture, shown in Figure 3. Registered meaning and value domains sit at its base, with reference data and terminology services alongside the registry as the authoritative sources of permitted values. Models of use, including national information requirements, record standards, data dictionary entries and the information requirements of pathway steps, cite registered meaning and add the obligations of their purpose. Packaging, such as FHIR profiles, openEHR templates and statistical submission formats, expresses those models of use in a particular technical standard. Systems and datasets implement the packaging. Dataset catalogue entries describe the resulting datasets and cite the registered meaning of their variables. Each layer cites the one beneath it at a stated version, and none restates it.

The national data dictionary has a specific place in this architecture. It becomes a governed national model of use that cites registered meanings, rather than remaining another independent source of semantic definitions. Its entries continue to define what a national collection requires and the rules that apply to it, but the reusable meaning on which each entry depends is registered once and cited. This is one of the most important consequences of the strategy, because in many health services the data dictionary is currently the most widely used source of national definitions.

The central capability is a metadata registry. ISO/IEC 11179 sets out the structure of such registries and the lifecycle of registered items, including provisional status. Australia’s Metadata Online Registry, operated by the Australian Institute of Health and Welfare, has applied the model to national health metadata for many years [9], and the country’s National Healthcare Interoperability Plan identifies it as the national repository for metadata standards [10]. Table 3 specifies the minimum content of a registration. A provisional registration can be made quickly, so that registration does not delay delivery; an approved registration requires the full content and evidence of review.

The registry can record only the dependencies that are declared to it. A record of which specifications, requirements and datasets cite each registration is complete only if those who cite it are required to declare their references. National specifications, nationally funded programmes and national dataset catalogues should be required to declare their citations as a condition of publication or funding. Other users should be encouraged to declare theirs, and the registry should state clearly that its dependency record covers declared references only.

The registry should hold models of use as well as models of meaning. Record standards, programme specifications, statistical returns, research data specifications and provider catalogues all state which items a purpose requires and with what obligations: which are mandatory, what must be supported and how strictly each value set is enforced. Registering each of these as a requirement that cites registered data elements at stated versions allows a health service to see, for any definition, the declared purposes that depend on it, and allows providers to cite national requirements rather than rebuilding them. The bodies that set each requirement remain its owners; the registry records it. This is established practice rather than a new idea. METEOR registers data set specifications, including national minimum data sets, alongside the data elements they cite [9], and openEHR separates reusable archetypes from the templates that constrain and combine them for a particular use [11]. What is less common, and what this strategy adds, is a single registry in which models of use from every source, whatever standard they are expressed in, cite the same registered definitions.

Clinical pathway descriptions connect to the registry through models of use. A pathway catalogue describes sequences of care: the steps, decisions, actors and transitions through which a patient passes. That is a different subject from information requirements, with different owners and a different rate of change, and the two should not be merged. They meet at the pathway step. Each step consumes information it needs to be performed safely and produces information for the steps that follow, and that information need is a model of use. A pathway catalogue should therefore cite, for each step, the registered requirement for the information it consumes and produces, rather than define data items itself. The pathway supplies the context; the registered requirement supplies the information contract for that context. Expectations about fitness for use, such as how recent an observation must be or which sources are acceptable, depend on the step in which data is used, and can be attached to the requirement that the step cites.

The second capability is reference data management. Organisation codes, practitioner registers, location hierarchies, and national code lists for administrative categories are used across every part of the health service. They are frequently published through separate routes, sometimes by more than one body for the same list. Each reference data set should have one [authoritative publisher] for each defined scope, jurisdiction and version, and should be registered, with its versions, so that products cite the authoritative source. This accommodates jurisdiction-specific variants, such as a list maintained separately by each devolved administration, without leaving any single list with competing publishers. The publisher continues to operate the list; the registry records which publisher is authoritative for which scope and which version is current.

The third capability is terminology services. Clinical terminologies such as SNOMED CT and classifications such as ICD are usually already managed by a national release centre or equivalent. The strategy does not replace that function. It connects it to the registry, so that the value sets bound to registered items are published through the terminology service, each binding identifies the terminology release on which it depends, and the registry records which items depend on which subsets. Bindings must be reproducible: a user of an archived registration should be able to obtain the value set as it stood when that version was published.

The fourth capability is a catalogue of datasets with their provenance and quality. Analysts, researchers and AI developers need to know what data exists, where it came from, what transformations it has undergone, what it covers and what is known about its quality. Dataset descriptions should use established vocabularies such as DCAT, which is widely used by public-sector data catalogues [12], and should cite registered items for the variables they contain. Quality statements should be attributable to whoever made them and dated, so that users can judge whether they are current. Where dataset catalogues and quality labels are required by regulation, as under the European Health Data Space Regulation, this capability is how the obligation is met.

The fifth capability is integration with the tools that produce and check specifications, together with the service commitments that make the registry dependable. A registry that implementers must consult separately will be bypassed. Exchange standards provide connection points. The FHIR specification, for example, publishes a formal mapping from its element definitions to ISO/IEC 11179, so that each element of a profile can carry the identifier of a registered data element and draw its code list from a registered value domain [13]. That mapping is a connection point, not an operating method: using it consistently requires agreed national conventions for how identifiers and versions are recorded, and tooling in the publishing process that applies them. Similar connections exist for archetype-based models and statistical metadata. The publishing processes for national specifications should check that each new or changed item either cites a registered meaning or is declared purely technical, with provisional registration available so that the check does not delay delivery.

The services that make up the registry must also meet published commitments, because specifications and contracts will come to depend on them. Table 4 sets out the minimum. These commitments are what allow a supplier or programme to cite a registration with confidence that it will still be available, unchanged, when the citation is checked years later.

Metadata must be consumable by machines, including AI agents

A growing share of the use of metadata will be by software rather than people. Specification publishing tools, validation services, analytical pipelines and AI-assisted tools for architecture, analytics and standards development all need to read definitions, follow relationships and check versions without human mediation. A registry designed only for people to browse will not serve them.

The registry should therefore provide stable programmatic interfaces, bulk export of complete releases, and identifiers that resolve to machine-readable descriptions of what they identify. Its representations should be suitable for automated reasoning, in the sense that a consuming system can determine what an item means, what it relates to, who is responsible for it and which version it is reading, without interpreting free text. The strategy does not prescribe particular technologies for this. Linked-data representations such as RDF and JSON-LD are one option among several. What matters is that any representation preserves identity, provenance, relationships and version information, so that a statement derived automatically from the registry can be traced back to the registration on which it rests.

Governance must make authority explicit, limited and accountable

A registry introduces a new authority between those who define what information means and those who write technical specifications. If that authority is not explicit, several bodies will claim responsibility for meaning and none will be accountable for it. An authority with too broad a remit will be seen as a competing standards body, and the organisations whose content it needs will not engage. An authority with too narrow a remit will leave difficult decisions without an owner.

The strategy therefore recommends a [registration authority] with a deliberately limited remit. It assigns identifiers, checks that registrations are complete, maintains the record of declared dependencies, publishes the registry, and identifies overlaps between registrations. Authoring standards is outside its remit. [domain stewards], drawn from the bodies and teams that already define content, propose and maintain items in their areas: clinical record standards bodies, the teams responsible for national data dictionaries and statistical returns, exchange specification editors, terminology release centres, programme teams and, for research, the bodies that curate national research datasets. Existing approval routes for information standards continue to approve standards; they would come to require that new standards cite registered items. Technical standards bodies keep their authority over technical specifications.

Disputes about meaning need an explicit route to decision. When the [registration authority] identifies an overlap, a conflict or a proposed registration that duplicates an existing one, it records the issue and coordinates its resolution, but it does not decide it. Substantive decisions about meaning are proposed by the [domain stewards] concerned. Where stewards within one domain agree, their decision is registered. Disputes that cross domains or jurisdictions, or on which stewards cannot agree, are decided by a designated [governance forum], such as [national data standards board], whose membership represents the stewarding bodies and, in federated systems, each jurisdiction. Some differences will not be resolved, because they reflect legitimate differences of purpose or policy. These remain visible: both definitions are registered, related to one another as incompatible or as broader and narrower, and the implications of the difference for users are recorded. Decisions of the forum should be published with their reasons, and a published appeal route should allow a steward or jurisdiction to challenge a decision through a defined process within a defined period.

Where the health service is organised across several nations, regions or devolved administrations, the [registration authority] and the [governance forum] should be governed jointly by them from the outset, with jurisdictional variants recorded as a normal feature of the register. A registry run by the largest jurisdiction alone risks the opposite of its purpose: if other jurisdictions do not accept its authority, they will continue to create their own definitions, and duplication will increase. In unitary systems, governance should still include representation from the stewarding bodies, so that the registry is seen as shared infrastructure rather than as one organisation’s product.

The [registration authority]’s own accountability should be limited to the integrity of the registry: that each identifier denotes what its registration says, that its status is correct, that published versions are preserved unaltered, and that its record of declared dependencies is accurate. It should not acquire responsibility for the clinical safety or contractual performance of systems that cite registered items. Those responsibilities remain with the bodies that publish specifications and the organisations that deploy systems.

Governance must also reach procurement. Contracts for systems and platforms that create, transform or hold health data should secure for the health service sufficient rights to use, retain, modify and transfer the definitions, mappings and transformation rules produced under the contract, in open and machine-readable form, during the contract and after it ends. Those rights should be distinguished from a supplier’s pre-existing intellectual property, which may be licensed rather than transferred, and from licensed terminology content, which remains subject to its own licence. Contracts should also require that contract-produced definitions are recorded against registered items where these exist. Provision of metadata to the health service is a separate matter from its public publication: the health service decides what to publish, having regard to licensing, commercial confidentiality and security. These provisions are the most direct way to stop meaning accumulating inside products where it cannot be reused or moved.

The benefits are broad, measurable and largely cumulative

The benefits of metadata management fall to different groups, and they grow as coverage grows, because each approved registration becomes reusable by every subsequent product that cites it. Table 5 sets out the principal benefits by group. Each should be read with the limits set out earlier: registration provides a common reference and reduces avoidable differences of interpretation, while implementation assurance and data quality management establish whether data actually conforms to it.

Several benefits deserve emphasis because they are often understated. The first is the effect on change. Without a registry, the owner of a national definition has no reliable way to find the products that depend on it, and a change is discovered by others late or not at all. With a registry, declared dependants are identified when a change is proposed, its impact can be assessed before it is approved, and each owner records a decision about whether and when to adopt it. Dependent specifications will still need review and sometimes revision. What changes is that the review is prompted, complete for declared dependants, and recorded.

The second is the effect on analytics and AI. Understanding and reconciling data before it can be analysed can be a substantial cost in analytical and AI projects using health data; the size of that cost should be measured during the first phase rather than assumed. Registered definitions, recorded provenance and attributable quality information reduce the effort and, more importantly, reduce the risk that reconciliation is done wrongly and silently. They also make it possible to state precisely which definitions an AI model’s training and evaluation data were recorded against, which is a precondition of assessing whether the model is fit for use and of meeting emerging expectations about the documentation of training data.

The third is the effect on control. A health service that holds sufficient rights to its definitions, mappings and reference data, and governs them in a registry, can change suppliers and platforms without reconstructing the meaning of its data. That reduces the switching costs which otherwise grow with each year of a contract, and strengthens the health service’s position at each renewal.

Measures must show benefit, not activity

The benefits above should be demonstrated, not asserted. Counting registrations or products shows activity; it does not show that duplication or reconciliation effort has fallen. The measures in Table 6 are chosen to show actual benefit. Each requires a baseline, a denominator where relevant, an owner, a collection method and a review interval before it is used. Baselines are rarely available at the outset, because the effort they measure is currently invisible, so establishing them is one of the first products of the strategy. Targets should be set by the adopting organisation once baselines are known, not in advance.

The capability also needs indicators that it is functioning, which are distinct from measures of benefit. A registry can be operating well and still fail to deliver benefit, and benefits will not appear if the service is not working. Table 7 sets out operating indicators. They are not evidence of benefit, but they show whether the conditions for benefit are in place, and they should be reported alongside the measures in Table 6. One indicator deserves particular attention. The registry knows only the dependencies that are declared to it, so a dependency record can be accurate and still incomplete. Reconciling declared dependencies against a known list of in-scope national specifications turns completeness from an assumption into something that can be checked.

Delivery should begin with one bounded pilot

The strategy should be delivered incrementally. A comprehensive registry attempted at once would take years to show value and would compete with systems already in use. Each phase below produces something useful in itself and the evidence on which the next can be judged. Table 8 summarises them.

The first phase establishes the minimum governance, a persistent identifier scheme, the registration rules in Table 3 and the service commitments in Table 4, and then tests them on one bounded pilot. Patient demographics, organisations and locations, encounters, observations, diagnoses, medicines and allergies are candidate domains, but they are candidates, not the expected scope of the first phase. The adopting organisation should choose one pilot using a scored selection matrix, so that the choice is auditable and not made primarily on grounds of convenience. Table 9 sets out the criteria. Each candidate domain should be scored against each criterion on a simple scale, with the evidence for each score recorded, and the adopting organisation should publish the weights it applies before scoring begins. Reference data used within the pilot should be assigned an [authoritative publisher] for each scope and jurisdiction as part of it.

The pilot also has an evaluative purpose. The evidence that metadata registries work is well established; METEOR and comparable registries have operated for many years. The less tested proposition is the one at the centre of this strategy: that registering meaning across exchange specifications, record standards, statistical collections and research metadata, and citing it from all of them, delivers measurable national benefit. The pilot should be designed explicitly as a test of that hypothesis, with baselines measured before it starts, the measures in Table 6 collected during it, and an independent evaluation of whether the benefit justifies the effort.

The pilot should include at least one grouped item, such as a blood pressure reading with its systolic and diastolic values, because simple data element models describe such items less directly and the approach must be shown to handle them before it is extended. It should also include at least one legitimate contextual difference, so that the relationship types are tested on real content. Completion of the first phase is a formal go or no-go decision, against the exit criteria in Table 10. The criteria test operation, not only initial loading: a registry that has been populated but has never processed a change or been recovered from export has not shown that it can do what later phases will depend on. If any criterion is not met, the adopting organisation should either remedy the gap within the first phase or decide, on the evidence, not to proceed.

The second phase, integration, extends registration to further domains chosen on the same criteria, publishes the registry through interfaces that tools already use, introduces the registration check into the production of national specifications for new and changed items, and establishes the national data dictionary as a governed national model of use, citing registered meanings for the reusable definitions on which its entries depend, with record standards linked to the same identifiers in the same way. The third phase, embedding, makes registration the norm. National programmes register new meanings before adding them to specifications, procurement requirements on metadata apply to new contracts, dataset catalogues and AI training data documentation cite registered items, and providers cite national requirements in their own catalogues rather than reconstructing them. Throughout all three phases, products continue to cite fixed versions and adopt changes through their own change control.

Funding must cover people, protected time and continuing operation

Metadata management is often presented as cheap because the technology is modest. Technology may well be a smaller cost than content work and organisational change, but that should be tested locally rather than assumed, and the business case should include every element on which the strategy depends.

The largest element is people. The assumption that existing content teams can absorb stewardship alongside their current work should not be made. Stewards need protected time, recognised in their organisations’ plans, to register and maintain content, take part in impact assessments and contribute to dispute resolution. They also need training and onboarding support, particularly in registration rules and relationship types, which are new to most content teams. The business case should therefore include protected steward time, a training and onboarding programme, the [registration authority] team and the [governance forum]’s secretariat.

The business case should also include the continuing cost of operating the services in Table 4, including availability, archiving, recovery and urgent correction, and the continuing maintenance of registered content, which does not end when content is first registered. A registry funded only for its build, or content registered only once, will decay. Each phase should have its own funding decision, informed by the measured effort and benefit of the previous phase.

The main risks are organisational

The technical elements of the strategy are well understood. Registries based on ISO/IEC 11179 have operated for many years, and the necessary connection points exist in current exchange and statistical standards. What is less well evidenced is the national benefit of registration across products and standards, which is why the pilot is framed as a test of that proposition. The risks that could prevent the registry becoming the recognised authority are mainly organisational. Table 11 sets them out with mitigations.

Two risks deserve particular attention. The first concerns the connection between high-level information requirements and detailed specifications. The United States Core Data for Interoperability defines categories of data that must be exchangeable, and the US Core implementation guide specifies how they are exchanged in FHIR, stating that USCDI must be interpreted in order to be implemented [14]. That experience illustrates the need to connect information requirements to the detailed definitions and specifications that implement them, and to record the connection explicitly. A registry that held only broad categories would leave that connection to each implementer. The strategy therefore registers individual definitions and value domains, and records models of use separately, so that each level can be traced to the other.

The second risk is that a registry is built but not consulted. The decisive control is integration into the processes through which specifications, contracts and datasets are produced. Without it, people working to deadlines will reasonably define what they need locally, and the registry will become reference documentation.

Each country will need to adapt the strategy to its institutions

The strategy is deliberately generic. Several features of a country’s health system will determine how it should be adapted, within the commitments set out in Table 1.

The structure of the health system matters most. In federated or devolved systems, joint governance of the [registration authority] and the [governance forum] is a precondition; in unitary systems, the emphasis falls on including the stewarding bodies. The existing institutional landscape determines which bodies become stewards and where the [registration authority] sits. In some countries a national statistical agency, a health information institute or a standards body will be the natural host, and in others a health ministry agency.

Maturity varies. A country with an established national data dictionary and terminology release centre can begin by registering existing content in its pilot domain. A country without them will need to establish those functions alongside the registry, and should resist building an elaborate registry before there is content to register. Countries within the European Union should align the dataset catalogue and quality capabilities with the obligations of the European Health Data Space Regulation, which provide both a timetable and a source of funding justification. Where a country has more than one official language, multilingual definitions are needed from the outset, and ISO/IEC 11179 supports them.

The choice of exchange standard affects the integration capability but not the strategy. The same registry can serve FHIR profiles, openEHR archetypes and templates, statistical returns and research data specifications. A country that uses several of these is likely to gain most from a registry, because duplication between standards is where the largest savings are likely to lie; the pilot should test whether that holds.

Finally, the strategy should be aligned with national digital health strategies and with international guidance. The World Health Organization’s global strategy on digital health, whose timeframe has been extended to 2027, identifies interoperability and data governance among the foundations of national digital health programmes [15]. Metadata management is one of the means by which those commitments are made operational.

Metadata management is a foundational condition for the wider data strategy

National health services are investing in shared records, national data platforms, research environments and artificial intelligence. Each of these depends on definitions that are explicit, shared where sharing is justified and related to one another where they differ; on knowing where data came from and what was done to it; and on being able to change systems without losing the meaning held in them. Moving data more efficiently meets none of those conditions. Managing metadata as infrastructure meets the first and supports the others, provided it is accompanied by implementation assurance and data quality management that test whether data actually conforms to the definitions it cites.

The reasons this work is overlooked are structural and predictable. Its benefits are diffuse and deferred, its costs are local and immediate, it belongs to no single discipline, and its success is invisible. A strategy that addresses those causes, by assigning clear and limited responsibility with an explicit route for disputes, protecting the time of the people who do the work, building registration into existing processes, securing rights through procurement and measuring what was previously unseen, can begin with a single bounded pilot using standards and content that most health services already have. Interoperability was only ever the first mile. Governing the meaning that travels along it is the rest of the journey.

Annex A: Glossary

Several terms used in this strategy are often used interchangeably, although they describe different layers of the same arrangement. Three of them name repositories, distinguished by what each describes. A data dictionary defines the data items used within a particular system or collection. Existing dictionaries commonly combine reusable meaning with collection-specific rules; under this strategy, reusable meanings are progressively registered independently, and dictionary entries cite them and add the rules of their own scope. A data catalogue describes whole datasets, so that people can find them and judge whether they can use them. A metadata registry holds the governed definitions themselves, independently of any one system or collection, and records what depends on them. Dictionary entries and catalogue variables should cite registered data elements rather than define meaning for themselves.

Three further terms name sources of permitted values, distinguished by who maintains them and why. Reference data consists of controlled, mainly administrative lists, such as organisation codes, maintained by a named publisher as the things they describe change. A reference set is a SNOMED CT distribution artefact that packages a subset of the terminology with its release. A value set selects the codes permitted for a particular data element in a particular context, and may be defined by citing a reference set or a reference data set. Read from the bottom up, terminologies and reference data supply codes; reference sets package subsets of SNOMED CT; value sets select the codes permitted for a purpose; the metadata registry binds a value set, at a stated version, to each data element; data dictionaries cite those elements and add the rules of a particular collection; and data catalogues describe datasets whose variables cite them. Each layer has a different owner and a different rate of change, and the layers should be connected by versioned reference rather than by copying. Table 12 defines these and the other terms used in this strategy.

Annex B: Indicators of readiness

The indicators in Table 13 can be used by a national body to assess its starting position and to choose its pilot domain. They describe observable arrangements rather than aspirations.

References

[1] European Parliament and Council of the European Union (2025) Regulation (EU) 2025/327 of 11 February 2025 on the European Health Data Space. Official Journal of the European Union.

[2] Wilkinson, M.D. et al. (2016) ‘The FAIR Guiding Principles for scientific data management and stewardship’, Scientific Data, 3, 160018.

[3] ISO (2013) ISO 17369:2013, Statistical data and metadata exchange (SDMX). Geneva: International Organization for Standardization.

[4] UNECE High-Level Group for the Modernisation of Official Statistics. Generic Statistical Information Model (GSIM). Geneva: United Nations Economic Commission for Europe.

[5] HL7 UK. UK Standards: UK Core Implementation Guide. Available at: https://www.hl7.org.uk/standards/hl7-standards/uk-standards/ (Accessed: 4 October 2026).

[6] NHS England. NHS Data Model and Dictionary, July 2026 release: Help and Guidance. Available at: https://archive.datadictionary.nhs.uk/DD%20Release%20July%202026/help/help_and_guidance.html (Accessed: 4 October 2026).

[7] NHS England. Core Information Standard. NHS Standards Directory. Available at: https://standards.nhs.uk/published-standards/core-information-standard (Accessed: 4 October 2026).

[8] ISO/IEC. ISO/IEC 11179, Information technology: Metadata registries (MDR), multi-part standard. Geneva: International Organization for Standardization.

[9] Australian Institute of Health and Welfare. METEOR: Metadata Online Registry. Available at: https://meteor.aihw.gov.au/ (Accessed: 5 October 2026).

[10] Australian Digital Health Agency (2023) National Healthcare Interoperability Plan 2023 to 2028. Sydney: Australian Digital Health Agency.

[11] openEHR International. Archetype Technology Overview. Available at: https://specifications.openehr.org/releases/AM/latest/Overview.html (Accessed: 5 October 2026).

[12] W3C (2024) Data Catalog Vocabulary (DCAT), Version 3. W3C Recommendation. Available at: https://www.w3.org/TR/vocab-dcat-3/ (Accessed: 5 October 2026).

[13] HL7 International. FHIR R4 (4.0.1): ElementDefinition Mappings, ISO 11179. Available at: https://hl7.org/fhir/R4/elementdefinition-de-mappings.html (Accessed: 5 October 2026).

[14] HL7 International. US Core Implementation Guide STU7: USCDI. Available at: https://hl7.org/fhir/us/core/STU7/uscdi.html (Accessed: 5 October 2026).

[15] World Health Organization (2021) Global strategy on digital health 2020-2025. Geneva: WHO. Timeframe extended to 2027 by the Seventy-eighth World Health Assembly, May 2025.

Dr Tito Castillo FBCS CITP is the Founder of Agile Health Informatics Ltd and works on health data governance, semantic interoperability and enterprise architecture in the NHS and wider UK public sector. He is the author of Data as Foundation: Building Healthcare’s Invisible Infrastructure and The Argument Advantage: Reasoning in the Age of AI.