Define meaning once and reuse it across standards
UK Core gives health and care systems a shared way to carry information using FHIR. The paper proposes a governed metadata registry beneath it, so that definitions, permitted values and information requirements can be reused by FHIR profiles, openEHR models, national reporting and local catalogues.
The first investment would establish shared governance, stable identifiers and links to existing definitions. Existing FHIR addresses and contracts would be preserved while those links are added. Later restructuring would require its own business case, testing and funding decision.
Present arrangement
The paper identifies overlapping definitions and locally reconstructed links.
People interpret correspondences between products. The paper does not establish that all existing mappings are absent.
Proposed arrangement
Each product references registered items and maintains its own representation and release controls.
What the register would hold
It would hold metadata about information, rather than patient records. A stable identifier would identify a governed item; its version, status, context and relationships would explain how it can be used. Matching identifiers would support traceability, but would not alone establish that two implementations are clinically equivalent.
This web report adapts Dr Tito Castillo’s October 2026 paper. Current-state descriptions and source access dates are those reported in the paper. The proposed registry is not an approved NHS programme.
In brief: the NHS pays repeatedly to define the same meaning, and a shared register would stop that
When health and care computer systems in the UK exchange information, they increasingly use an international standard called FHIR. UK Core is the national rulebook for using FHIR in the UK. It sets out how information about patients, medicines, test results and other aspects of care should be packaged, so that one system can read what another sends. It is valuable national infrastructure, and a great deal of careful work has gone into it.
Over time, UK Core has taken on a second job for which it was not designed. Besides defining how information is packaged, it has become one of the places where the meaning of that information is decided: what counts as an ethnic category, which codes may be used to record it, and which list of NHS organisations is the official one. The same meanings are defined again, separately, in the NHS Data Dictionary used for national reporting, in the Core Information Standard that sets out what a patient record should contain, in programme-specific specifications for England, in the shared record systems some regions use, and in the catalogues that individual hospitals compile. Nothing links these definitions to one another. When a meaning changes, every copy has to be found and changed separately, by different teams, on different timetables.
This paper proposes that the meaning of health data, the official code lists that go with it, and reusable statements of what information care requires, should be defined once, in a single authoritative register that sits beneath UK Core. UK Core and the other national products would then refer to that register instead of each defining meaning for themselves. The approach is not new. It follows an established international standard for such registers, ISO/IEC 11179, and Australia has run a national register on this model for many years. FHIR already contains the connection points needed, so no change to the international standard is required.
Four arguments support investment. The present arrangement creates duplicated effort and rework at every level, from national standards teams to individual hospitals; in one draft hospital catalogue examined for this paper, all 189 information requirements had to be linked to national standards by hand, and none of those links could be made exact because no shared reference numbers exist. Inconsistent meaning is also a source of clinical and analytical risk, and the 10 Year Health Plan’s commitment to a single patient record depends on information meaning the same thing wherever it comes from. Delay raises the eventual cost, because every system built against today’s arrangements becomes something that must later be changed. And a decision point is imminent: NHS England is about to commission the technical specifications for the Core Information Standard, which will either reuse governed meaning or create yet another separate copy.
The proposal is staged so that the first phase is low in risk and disrupts no existing system. It begins by giving every existing national definition a permanent reference number and recording where each is used. Later phases, each subject to its own funding decision, make that reference the required source for new work. This paper asks NHS England to fund the first phase, to establish governance for it jointly with Scotland, Wales and Northern Ireland, and to commission a costed outline business case for the phases that follow.
The problem is clearest in a single example
Ethnic category is recorded across the NHS for direct care, for national reporting and for monitoring health inequalities. When it is sent between systems using FHIR, UK Core defines how it is carried and which codes may be used. When it is reported in national data collections, the NHS Data Model and Dictionary defines it separately. The Core Information Standard, which describes what a patient record should contain, includes it again. A hospital writing its own catalogue of information requirements has to consult all of these and decide for itself whether they mean the same thing. They are intended to, but no shared reference number says so, and no system can list every place that would be affected if the definition changed.
A recent change shows the consequence. In April 2026 the Core Information Standard updated how sex and gender are recorded, in response to the independent review of data, statistics and research on sex and gender [8]. That change was made once, in the Core Information Standard. Every other national product carrying the same information then has to be identified and updated through its own process: UK Core through its development cycle and formal ballot, England’s programme specifications on their own schedules, and the Data Dictionary through its release cycle. Nowhere can anyone see, from the change itself, every product it touches. This effort is repeated each time a meaning changes, and the gaps between the copies are where errors enter.
Meaning is currently defined in at least five places, with no shared reference numbers
UK Core, published by HL7 UK, contains the FHIR packaging rules for the UK together with code lists and UK-specific additions, and aims to provide guidance that applies “across jurisdictions and care settings” [1]. It was developed by NHS Digital, HL7 UK and INTEROPen with the four nations [7], and each release passes through clinical and technical review and a formal vote of the HL7 UK community before publication. At the time of writing, the current release dates from July 2024, and the next is in development with changes that will require existing systems to be updated [3][4].
England’s programme specifications add further content on top of UK Core. The NHS England Implementation Guide “provides additional guidance, rules and constraints which extends the FHIR UK Core Implementation Guide”, including England-only code lists and additions for the Organisation Data Service, Female Genital Mutilation flags and Child Protection Information Sharing [5]. The NHS Data Model and Dictionary defines the items reported in national data collections, on its own release cycle [9]. The Core Information Standard, developed by the Professional Record Standards Body and managed by NHS England since 1 January 2026, describes what a patient record should contain without prescribing any technology; NHS England has stated that FHIR specifications to support it “will be commissioned” [8]. openEHR, a different standard used in several NHS shared record systems, has been linked to UK Core only through an initial hand-made mapping [10].
Each of these products is well maintained within its own remit. The difficulty lies between them. They describe overlapping information, yet none can refer to another by a shared reference number, because no such numbering exists. Linking them depends on matching names and on the knowledge of individuals who understand more than one product.
Governance shows the same gap. UK Core is intended for use across all four UK nations, but its published governance standard names NHS England as sponsor and senior responsible owner, the Data Alliance Partnership Board as its technical committee, and defines its scope as “health and care organisations in England” [2]. The Data Dictionary and the Core Information Standard are likewise England products. This is not a failure by any of the organisations involved. It reflects a gap in the national arrangements: no body is responsible for the meaning of health data independently of the product in which it appears, across the whole of the UK.
Keeping meaning inside technical specifications creates rework
UK Core is well suited to its main purpose, which is to specify how information is packaged for exchange. It is much less suited to being the official home of what information means, for three reasons that matter to anyone funding the work.
Meaning kept in a technical specification changes whenever the specification changes. Each new UK Core release obliges every supplier and programme that depends on it to work out whether a given change affects only the packaging or also the meaning, and nothing persists from one release to the next to tell them. Several products are already built on different releases: the draft UK Core Access specification, published in June 2026, is based on the first UK Core release rather than the current one [6][3], and the NHS England Implementation Guide was built on a pre-release version of the next [5]. With a permanent reference number for each meaning, suppliers could confirm automatically that an item still means what it meant before, and concentrate their effort on genuine changes.
Nor is meaning kept in a FHIR specification available to anything that does not use FHIR. National data collections, the Core Information Standard and openEHR shared records all need the same meanings, but they cannot draw them from a FHIR rulebook, so each defines its own copy. The openEHR mapping work records exactly the technical mismatches that arise when meaning and FHIR packaging are defined together [10].
Additions made above UK Core are invisible to everyone else. England’s programme specifications add new items as programmes need them [5]. Each addition is reasonable, but it is not visible to the other nations, to openEHR systems or to national data collections, and whether something applies across the UK or only in England is settled by which document it happens to appear in rather than by a deliberate decision.
None of this reflects poor work on UK Core. These are the predictable consequences of asking a technical specification to serve as the national authority on meaning.
Hospitals and suppliers carry much of the hidden cost
The cost of the present arrangement falls heavily on organisations at the point of implementation. This paper draws on one worked example: a draft catalogue of 189 clinical information requirements for an acute hospital trust, each written in plain terms and then linked to UK Core, to the Data Dictionary, to the Core Information Standard and to clinical terminology [20]. The catalogue’s own approach is sound: decide what must be recorded before deciding how. Its links to national standards show what happens next.
FHIR packages information in standard containers. Some are specific, such as the container for a patient’s details. Others are general-purpose: a container called Observation can hold almost any clinical measurement or finding, and what it actually records depends entirely on the code attached to it. In the hospital catalogue, 94 of the 189 requirements could be placed in more than one container, and 90 could be placed only in general-purpose containers such as Observation, with no more specific location. Twenty were distinguished from one another solely by their codes. For this large share of the catalogue, the FHIR packaging says nothing about meaning. The meaning is carried entirely by the codes and code lists, which is precisely what the proposed register would govern.
The catalogue also shows the burden on local teams. Every one of its links to national standards was entered by hand and marked as provisional. Ten requirements were expected to correspond directly to Data Dictionary items and 75 were judged highly relevant to Core Information Standard content, yet none could cite a shared reference number, because none exists. In effect the hospital has built its own small register because the national one is missing. Every trust that does similar work will repeat the same effort independently, and the results will not be comparable between trusts. System suppliers face the same task for each customer and each release.
The remedy is a shared register of meaning beneath UK Core
A register of meaning, known technically as a metadata registry, records for each item of health information a plain definition, the permitted values or code list, the person or body responsible for it, its approval status, the nations to which it applies, and a permanent reference number. Products such as UK Core, the Data Dictionary and the Core Information Standard then cite that number rather than restating the definition, much as an engineering drawing cites a British Standard by its number instead of reproducing it. The register also records where each item is used, so that the effect of any proposed change can be seen before it is approved.
The international standard for such registers, ISO/IEC 11179, is long established [12]. Australia’s Metadata Online Registry (METEOR), run by the Australian Institute of Health and Welfare, is “the registry for Australian metadata standards for statistics and information” across health and related sectors [16]. The FHIR standard itself already includes a formal link to ISO/IEC 11179: each element of a FHIR specification has a place to record the reference number of a registered meaning and a place to link it to a registered code list [11]. Building a UK register therefore requires no change to FHIR, only consistent use of features it already provides. The register’s content can also be published in the formats that FHIR tools already read, through the national terminology service, so that suppliers and developers meet it in the tools they already use. That matters, because registers elsewhere have struggled where they were technically sophisticated but awkward to use.
Not everything in UK Core should move. Table 1 classifies nine kinds of content: three move, three split and three stay. This is a classification of content types, not a measurement of how much of UK Core would change. An item-by-item inventory is required in phase 1.
| Kind of content | Decision | What happens |
|---|---|---|
| Plain definitions of each item | Move | Defined in the register; UK Core keeps a short label and the reference number |
| Code lists saying which values are allowed | Move | Held in the register and published through the national terminology service |
| Official reference lists, such as the list of NHS organisations | Move | Held in the register, each list with one named publisher |
| UK-specific items that international FHIR does not provide, such as ethnic category | Split | The meaning is registered; UK Core keeps the technical container that carries it, unchanged |
| Rules about meaning, such as a diagnosis needing a confirmation status | Split | The rule is stated in the register; UK Core keeps the technical test that enforces it |
| Whether an item is mandatory | Split | Depends on the type of care, so recorded against requirements; UK Core stays permissive |
| Technical packaging rules | Stay | UK Core |
| Rules for how systems request data | Stay | UK Core Access and programme specifications |
| Worked examples and technical guidance | Stay | UK Core |
What remains in UK Core afterwards is what every UK FHIR system genuinely shares: the packaging rules, the obligations that apply everywhere, and references to registered meaning. UK Core would be smaller, change less often and serve all four nations more evenly.
Other countries already separate what information means from how it is sent
The United States and Australia both define their national data requirements separately from their FHIR rulebooks, and link the two. In the United States, the Office of the National Coordinator maintains the United States Core Data for Interoperability (USCDI), a list of the categories of data that must be exchangeable, and the US Core rulebook specifies how. In Australia, the Australian Clinical Data for Interoperability (AUCDI) is developed by clinicians through the CSIRO Sparked programme and sets out data items with their clinical terminology, while AU Core specifies how they are exchanged and publishes a mapping between the two [14][15]. Australia’s National Healthcare Interoperability Plan identifies METEOR as the national repository for metadata standards and calls for standards that are “technology agnostic” [17]. Table 2 compares these arrangements with the UK’s.
| Dimension | United States | Australia | UK today | UK proposed |
|---|---|---|---|---|
| Where meaning is defined | USCDI, a national list of data categories | AUCDI, a clinician-led set of data items | No single place: spread across UK Core, England specifications, the Data Dictionary and the Core Information Standard | A national register of meaning beneath UK Core |
| Who defines it | Office of the National Coordinator (government) | Sparked, a CSIRO programme, through clinical design groups | HL7 UK and NHS England programmes for FHIR; NHS England for the Data Dictionary and Core Information Standard | A registration authority governed by the four nations |
| Level of detail | Broad categories, which the US Core rulebook has to interpret | Data items with clinical terminology | Detailed, but held inside the FHIR rulebooks | Individual definitions and code lists |
| Technical rulebook | US Core | AU Core | UK Core | UK Core, reduced to packaging and references |
| How the two are linked | A mapping, updated annually | A mapping from AUCDI items to AU Core | Linked by hand by each user | Permanent reference numbers, checked when UK Core is produced |
| Lesson for the UK | Too broad a list leaves the real meaning in the rulebook | Clinical design first keeps clinicians in charge of meaning | Not applicable | Work at the level of definitions and code lists |
The American experience carries a lesson about level of detail. USCDI describes broad categories, and the US Core rulebook states plainly that “an interpretation of USCDI is necessary” to make it usable, and that many items in US Core do not correspond to anything in USCDI [13]. The detailed meaning has therefore ended up back in the technical rulebook. A UK register pitched at the level of broad categories would repeat that outcome and change little. To be worth funding, the UK register must work at the level of individual definitions and code lists.
The investment would reduce duplication, lower risk and speed up change
The benefits fall to several groups. National standards teams would make each change of meaning once and see in advance every product it affects, instead of searching for copies. Suppliers would build against permanent reference numbers that survive from one UK Core release to the next, reducing the effort spent establishing what has changed. Hospitals and other providers would cite national definitions instead of reconstructing links by hand, and their catalogues would become comparable with one another. Analysts and national data collections would be able to connect information sent between care systems with information reported nationally through a shared reference rather than by matching names. Scotland, Wales and Northern Ireland would record their own variations as registered variants of a shared definition, leaving UK Core identical across the four nations instead of accumulating separate national additions.
Two wider benefits deserve particular weight. Clinical safety depends on information meaning the same thing to the system that sends it and the system that receives it; every manual link between national products is a point at which meaning can drift. And national ambitions such as the single patient record, which the 10 Year Health Plan describes as giving patients “a single, secure and authoritative account of their data” [18], depend on consistent meaning across sources. The same is true of any large-scale analysis, including the use of AI on NHS data: automated methods applied to inconsistently defined data reproduce the inconsistency at scale rather than correcting it.
These benefits should be measured. Table 3 proposes measures for a benefits realisation plan. Baselines have not yet been established and would be among the first products of the initial phase.
| Measure | Who benefits | Direction sought |
|---|---|---|
| Number of national items with a permanent reference number | All users of national standards | Rising towards complete coverage |
| Share of UK Core items that refer to a registered meaning | Suppliers, standards teams | Rising towards all non-technical items |
| Number of separate products to update when a national meaning changes | National standards teams | Falling to one, the register |
| Time from an approved change of meaning to all national products reflecting it | Clinicians, analysts, suppliers | Falling |
| Number of new nation-specific or programme-specific additions to UK Core | Devolved nations, programmes | Falling, replaced by registered variants |
| Effort for a trust to link a local catalogue to national standards | Hospitals and other providers | Falling |
| National data items that can be linked to FHIR data by reference rather than by name | Analysts, national data collections | Rising |
A phased register offers the best value of the options considered
Four options were considered, summarised in Table 4. Continuing as now carries no new cost but leaves the duplication in place and allows it to grow with every new system and programme. Improving coordination between the existing teams, without shared reference numbers, is inexpensive but depends on individuals, cannot show the effect of a change automatically, and does not survive staff turnover. A high-level national list of data categories on the American model would be relatively quick to agree, but, as the American experience shows, the detailed meaning would remain in the technical rulebooks. A phased register working at the level of individual definitions and code lists, governed by the four nations and built into how UK Core is produced, costs more, but it is the only option that addresses the cause of the duplication rather than its symptoms, and its phasing limits the commitment required at each stage.
| Option | Relative cost | What it achieves | Why it falls short or succeeds |
|---|---|---|---|
| 1. Continue as now | None additional | Nothing new | Duplication continues and grows with each new system; the Core Information Standard specifications become another copy |
| 2. Better coordination between existing teams | Low | Some reduction in inconsistency | Depends on individuals; cannot list the effects of a change; does not survive staff turnover |
| 3. A high-level national list of data categories | Low to moderate | A shared vocabulary of broad categories | The detailed meaning stays in the technical rulebooks, as the American experience shows |
| 4. A phased register at the level of definitions and code lists (recommended) | Moderate, mainly people | Meaning defined once, referenced everywhere, with the effects of change visible | Addresses the cause; phasing limits the commitment at each stage |
The money would pay mainly for people and process, not new technology
No cost model has been prepared for this paper, and none should be inferred from it. The main cost drivers are nonetheless clear. Most of the expense lies in people: a small team to run the register and act as its registration authority, and domain stewards, clinical and data experts who take responsibility for defining and maintaining items in their area. Some of these roles exist already in the teams that maintain UK Core, the Data Dictionary and the Core Information Standard, and could be redirected rather than created. Further effort goes into recording the meaning already published in UK Core and the England specifications, and into adapting the UK Core production process so that it checks each item against the register. Technology costs should be comparatively modest, because the register can publish through the existing national terminology service and the established FHIR publishing channels.
The first phase should therefore produce a costed outline business case for the later phases, prepared on the HM Treasury Green Book five-case model, with baselines for the measures in Table 3. Funding the first phase is a bounded decision: it creates the governance, the numbering scheme and the register of existing content, which are useful in themselves, and it provides the evidence on which a larger commitment can be judged.
Delivery should proceed in three phases, each with its own funding decision
Systems already in use refer to UK Core by fixed web addresses. Changing those addresses, or restructuring what they point to, would break working systems. The programme must therefore add reference numbers before it moves anything. Table 5 sets out the three phases.
The first phase, register and label, sets up four-nation governance and the numbering scheme, names a single publisher for each official reference list, and records the meaning already published in UK Core and the England specifications, starting with the UK-specific additions where the case is clearest. UK Core is then labelled with the new reference numbers without altering anything existing systems depend on. Nothing breaks, and for the first time every national meaning carried in FHIR has a number that persists from one release to the next.
In the second phase, use and check, the register is published in formats that FHIR tools read, and the UK Core production process begins to check that every new or changed item refers to a registered meaning. The Core Information Standard is broken down into registered items, the Data Dictionary records links to the same reference numbers, and one clinical area, such as vital signs or allergies, is linked in both openEHR and UK Core to test the approach across standards. This phase also tests how the register handles information with several parts, such as a blood pressure reading with its two values; if it cannot, that meaning will remain in the technical specifications.
By the third phase, the register becomes the norm. Programmes register new meanings before adding anything to their specifications, and add to the FHIR packaging only where the packaging itself requires it. UK Core becomes a lean shared rulebook for the whole of the UK, with meaning governed in the register and shared across FHIR, openEHR and national data collections.
| Phase | What is done | What changes for system users | Decision before the next phase |
|---|---|---|---|
| 1. Register and label | Four-nation governance agreed; numbering scheme and reference list publishers set; existing UK Core and England content recorded in the register; UK Core labelled with reference numbers | Nothing breaks; reference numbers become available | Costed outline business case; baselines for the benefit measures |
| 2. Use and check | Register published in formats tools read; UK Core production checks references; Core Information Standard and Data Dictionary linked; openEHR pilot in one clinical area | New and changed items carry permanent references | Evidence from the pilot and from the production check |
| 3. Make it the norm | Programmes register new meanings before adding to specifications; UK Core reduced to packaging and references | Fewer separate additions; one source for meaning | Ongoing operation |
The register must belong to all four nations and be built into everyday work
A register introduces a new authority between clinical need and the technical specification. If its authority is not explicit, both the register and the UK Core editors will claim responsibility for meaning, and neither will be accountable. Responsibilities therefore need to be set out precisely. A registration authority runs the register, approves the status of items and resolves differences between nations. Domain stewards propose and maintain items in their area. UK Core editors continue to write and assure the FHIR specifications, citing registered items. Teams responsible for programme specifications, openEHR models and national data collections link their products to the same items. Publishers of official reference lists issue them under register numbers. HL7 UK keeps its formal vote on the FHIR specifications: the register governs meaning, and HL7 UK governs packaging. In England, the Data Alliance Partnership Board would need to accept registered items as information standards, and equivalent approval routes in the other nations would need to do likewise.
Where the registration authority sits is the most important decision in this paper. NHS England is the natural operator, since it sponsors UK Core governance, owns the Data Dictionary and now manages the Core Information Standard. UK Core, however, was developed with all four nations [7] and is meant to serve them all. A register run by NHS England alone risks producing the opposite of what is intended. Should Scotland, Wales and Northern Ireland decline to accept its authority, they will go on creating their own additions, and UK Core will become more English rather than more shared. The register should therefore be governed jointly by the four nations from the start, with national variations recorded as a normal feature of the register rather than a concession. None of the sources reviewed for this paper describes an existing UK-wide body of this kind, and the willingness of the devolved administrations to share in one needs to be tested early.
Authority must also be practical. A register that the tools and processes used to produce UK Core do not consult will become a reference document that people stop reading, and the specifications will drift away from it. The decisive control is a check built into the production of UK Core: every item must either refer to a registered meaning or be marked as purely technical, and an item that does neither does not pass review. Without that check, editors under deadline pressure will reasonably define new items directly in the specification, and the register will be bypassed. To prevent the check from slowing work down, items can be registered quickly with provisional status, as the international standard allows, and confirmed later.
The main risks are organisational, and each has a mitigation
The technical elements of the proposal are modest. FHIR provides the connection points, ISO/IEC 11179 provides the design, and the national terminology service provides the channel for publication. The risks that could stop the register becoming the recognised authority are organisational, and Table 6 sets them out with the measures that address them.
| Risk | What could happen | Mitigation |
|---|---|---|
| Unclear authority | Register and UK Core editors both claim responsibility for meaning | Responsibilities set out at the start of phase 1 |
| A register nobody’s tools read | It becomes documentation and the specifications drift from it | Publish in formats tools read; check references when UK Core is produced |
| Some meaning has several parts | Items such as a blood pressure reading do not fit simple definitions | Test grouped items during the phase 2 pilot |
| Other nations do not accept the register | They continue creating their own additions | Four-nation governance from the outset |
| Disruption to systems in use | Changing what existing systems refer to breaks them | Label before restructuring; keep existing web addresses |
| Reference lists keep several publishers | The register records confusion rather than resolving it | Name one publisher for each list in phase 1 |
| The register is pitched too broadly | Meaning stays in the technical rulebooks | Register definitions and code lists, not only categories |
| Registration becomes a bottleneck | UK Core development slows | Provisional status and a purely technical category |
Two risks deserve emphasis. Official reference lists are where today’s arrangements are most fragmented: organisation codes, Data Dictionary national codes and clinical terminology subsets each have their own publication route, and a register that records them without naming one publisher for each would document the confusion without resolving it. The pull towards a high-level list is also easy to underestimate, because broad categories are quicker to agree than detailed definitions. That speed would be bought at the cost of leaving the meaning where it is now.
The Core Information Standard decision makes the timing urgent
Management of the Core Information Standard passed from the Professional Record Standards Body to NHS England on 1 January 2026, and its FHIR specifications are still to be commissioned [8]. Those specifications will either refer to registered meaning or define it again within FHIR. If they define it again, the Core Information Standard, its FHIR specifications, UK Core and the Data Dictionary will hold four overlapping versions of much the same meaning, maintained on four timetables, with no shared reference numbers. If they refer to a register, the Core Information Standard becomes the register’s first substantial content and demonstrates the approach at national scale. The commissioning decision is the point at which the cost of the present arrangement can be avoided rather than incurred again.
The wider policy direction reinforces the point. A single patient record assembled from sources that agree on packaging but not on meaning would appear unified while remaining inconsistent underneath, and would invite the verdict that has followed many integration programmes. The data moved exactly as designed. The meaning did not.
Eight decisions would set the programme in motion
This paper makes eight recommendations to NHS England, set out in Table 7 with proposed owners, timing and funding implications. The first is time-critical. The second to fourth together form the first phase for which funding is sought.
| No. | Recommendation | Proposed owner | Timing and funding |
|---|---|---|---|
| 1 | Commission the Core Information Standard FHIR specifications to refer to registered meaning rather than define it again | NHS England | Immediate; shapes commissioning already planned |
| 2 | Establish a registration authority governed jointly with Scotland, Wales and Northern Ireland, and appoint domain stewards | NHS England with the devolved administrations | Phase 1 funding |
| 3 | Create a permanent numbering scheme and name one publisher for each official reference list | NHS England | Phase 1 funding |
| 4 | Record existing UK Core and England specification content in the register and label UK Core without changing existing web addresses; prepare a costed outline business case | NHS England with HL7 UK | Phase 1 funding |
| 5 | Publish the register through the national terminology service in formats FHIR tools read | NHS England | Phase 2, subject to business case |
| 6 | Build a reference check into UK Core production, with provisional status to avoid delay | HL7 UK with the registration authority | Phase 2, subject to business case |
| 7 | Link the Data Dictionary to the register and pilot openEHR linkage in one clinical area | NHS England with the openEHR community | Phase 2, subject to business case |
| 8 | Require programmes to register new meanings before adding to their specifications | NHS England national programmes | Phase 3 |
A smaller UK Core would be a stronger one
UK Core has done what it was asked to do. It gives systems across the UK a common way to exchange information, and the work behind it is substantial. It has also been asked to do something a technical rulebook is poorly placed to do: to act as the national authority on what health information means. That role belongs in a register beneath it, governed by the four nations, published in forms that existing tools already read, and built into the way UK Core is produced.
A UK Core relieved of that role would be smaller and more widely useful. It would change when the packaging needed to change, not every time a national definition was revised. Its references would point to meaning that openEHR systems, national data collections, record standards and hospital catalogues could use equally. National differences would be recorded once, in the register, instead of accumulating as separate additions. Interoperability was only ever the first mile. Governing the meaning that travels along it is the rest of the journey, and the first phase can begin with infrastructure that largely exists today.
This analysis separates evidence from proposal
This paper is an options analysis rather than a costed business case. It is supported by an architecture model of the current and proposed arrangements in which every element is classified by its evidential basis: stated in a cited source, inferred from cited sources, drawn from general knowledge of FHIR, proposed by this analysis, or uncertain. Statements about current arrangements rest on public specifications and NHS Standards Directory entries consulted in October 2026, and on the draft hospital catalogue described above, whose links to national standards are marked by its authors as provisional. Its figures illustrate a pattern rather than the national position.
Three limitations apply. UK Core was not analysed item by item, so the three-way division in Table 1 describes kinds of content rather than quantities; measuring the quantities is part of the first phase. The governance arrangements of Scotland, Wales and Northern Ireland, and the release management of the UK edition of SNOMED CT, were not examined in depth. No costs or timescales have been modelled, and no organisation has committed to any part of the proposal.
Annex A: Glossary
| Term | Meaning |
|---|---|
| FHIR | An international standard, published by HL7, for exchanging health information between computer systems |
| UK Core | The UK’s national rulebook for using FHIR, published by HL7 UK |
| Specification or profile | A technical document setting out exactly how a type of information must be packaged in FHIR |
| Code list | The set of permitted values for an item, such as the categories that may be recorded for ethnicity |
| Reference data | Official lists used across the NHS, such as the list of NHS organisations and their codes |
| Register of meaning (metadata registry) | A managed catalogue recording what each item of information means, its permitted values, who is responsible for it and where it is used |
| ISO/IEC 11179 | The international standard for registers of meaning |
| NHS Data Model and Dictionary | NHS England’s reference for the items reported in national data collections |
| Core Information Standard | A standard describing what a patient record should contain, independent of technology |
| openEHR | An alternative standard for structuring health records, used in several NHS shared record systems |
| SNOMED CT | The clinical terminology used across the NHS to record diagnoses, findings and procedures |
| Registration authority | The body that runs the register and approves the status of its items |
| Domain steward | A clinical or data expert responsible for the items in a particular area of care |
Annex B: Technical note for architects and standards specialists
The FHIR R4 specification publishes formal mappings from its ElementDefinition structure to ISO/IEC 11179. ElementDefinition maps to a data element; ElementDefinition.code maps to the identifier of the data element concept; ElementDefinition.binding maps to the value domain; ElementDefinition.definition maps to the registered definition; and ElementDefinition.mapping maps to a registered mapping specification [11]. The DataElement resource of earlier FHIR versions was removed in R4, with data elements represented as logical models or references to elements [19]. A registry beneath UK Core can therefore be implemented by populating ElementDefinition.code with registry identifiers, drawing bindings from registered value domains published as ValueSets, publishing data element definitions as logical models, and adding a traceability check to the Implementation Guide build that fails any element neither registered nor declared technical. Binding strength remains in the profile, since it is an exchange obligation rather than a statement of meaning. Table 9 gives the detailed classification on which Table 1 is based.
| Kind of content | FHIR mechanism | Verdict | Target home |
|---|---|---|---|
| Element definitions and descriptions | ElementDefinition.definition, short, comment | Move | Registered data element concept definition; profile keeps a short label and cites the registry |
| Value set bindings for coded elements | ElementDefinition.binding, ValueSet, CodeSystem | Move | Registered value domain, published as a ValueSet expansion; binding strength stays in the profile |
| Identifier systems and organisational reference data | Identifier.system, NamingSystem, ODS extensions | Move | Reference data set with a named publisher |
| UK concepts carried as extensions | Extension StructureDefinition (for example Ethnic Category) | Split | Concept registered; extension stays as the FHIR carrier with a fixed canonical URL |
| Business rules about clinical meaning | Invariants (FHIRPath) | Split | Rule stated against registered items; FHIRPath stays as its FHIR expression |
| Obligations: cardinality and must-support | min, max, mustSupport | Split | Obligation recorded per use case against requirements; permissive FHIR cardinality stays in the core profile |
| Structural constraints and slicing | Slicing, choice type restriction, type profiles | Stay | UK Core |
| Search and API capability | SearchParameter, CapabilityStatement | Stay | UK Core Access and programme guides |
| Examples and implementation guidance | Example instances, narrative guidance | Stay | UK Core |
References
[1] HL7 UK. UK Standards: UK Core Implementation Guide. Available at: https://www.hl7.org.uk/standards/hl7-standards/uk-standards/ (Accessed: 4 October 2026).
[2] NHS England. UK Core FHIR Release 4 Governance. NHS Standards Directory. Approved 2 March 2022. Available at: https://standards.nhs.uk/published-standards/uk-core-fhir-release-4-governance (Accessed: 4 October 2026).
[3] HL7 UK. UK Core Publication (Version) History. Simplifier. Available at: https://simplifier.net/guide/UKCoreVersionHistory/Home (Accessed: 4 October 2026).
[4] HL7 UK. UK Core Implementation Guide STU3 Sequence, version 0.11.0 (development). Simplifier. Available at: https://simplifier.net/guide/uk-core-implementation-guide-stu3-sequence (Accessed: 4 October 2026).
[5] NHS England. NHS England Implementation Guide STU1, version 1.4.0, 7 December 2023. Simplifier. Available at: https://simplifier.net/guide/nhs-england-implementation-guide-stu1 (Accessed: 4 October 2026).
[6] HL7 UK. UK Core Access Implementation Guide, version 0.1.0 (continuous build), 26 June 2026. Available at: https://build.fhir.org/ig/HL7-UK/UK-Core-Access/ (Accessed: 4 October 2026).
[7] NHS Digital. FHIR UK Core. UK Government Web Archive. Available at: https://digital.nhs.uk/services/fhir-uk-core (Accessed: 4 October 2026).
[8] NHS England. Core Information Standard. NHS Standards Directory. Available at: https://standards.nhs.uk/published-standards/core-information-standard (Accessed: 4 October 2026).
[9] 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).
[10] openEHR International. FHIR UK Core and openEHR mappings. openEHR Specifications Wiki. Available at: https://openehr.atlassian.net/wiki/spaces/stds/pages/1997963265 (Accessed: 4 October 2026).
[11] HL7 International. FHIR R4 (4.0.1): ElementDefinition Mappings, ISO 11179. Available at: https://hl7.org/fhir/R4/elementdefinition-de-mappings.html (Accessed: 4 October 2026).
[12] ISO/IEC. ISO/IEC 11179, Information technology: Metadata registries (MDR), multi-part standard. Geneva: International Organization for Standardization.
[13] HL7 International. US Core Implementation Guide STU7: USCDI. Available at: https://hl7.org/fhir/us/core/STU7/uscdi.html (Accessed: 4 October 2026).
[14] HL7 Australia. AU Core: AUCDI. Available at: https://hl7.org.au/fhir/core/aucdi.html (Accessed: 4 October 2026).
[15] CSIRO Sparked. AUCDI, FHIR and AU Core. Available at: https://sparked.csiro.au/?p=5563 (Accessed: 4 October 2026).
[16] Australian Institute of Health and Welfare. METEOR: Metadata Online Registry. Available at: https://meteor.aihw.gov.au/ (Accessed: 4 October 2026).
[17] Australian Digital Health Agency (2023). National Healthcare Interoperability Plan 2023 to 2028. Sydney: Australian Digital Health Agency.
[18] Department of Health and Social Care (2025). Fit for the Future: 10 Year Health Plan for England. Executive Summary. London: DHSC.
[19] HL7 FHIR Community. Rationale for removing the DataElement resource. FHIR Chat Archive, Implementers stream. Available at: https://chat-archive.fhir.org/stream/179166-implementers/ (Accessed: 4 October 2026).
[20] NHS Acute Trust Master Healthcare Clinical Information Requirements Catalogue. Draft worked example, 2 October 2026. Unpublished.
Dr Tito Castillo FBCS CITP CDMP CHCIO 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.