Terminology and patient identity services in healthcare data platforms

Two shared services: terminology and patient identity

A data platform needs two answers that no single source system can give it. Are these two records the same patient? Do these two codes mean the same thing? The first is patient identity, the second terminology. Every count the platform publishes rests on both, and when either answer is wrong nothing fails: the query runs, the dashboard fills, and the number is quietly different from the truth.

Why both arrive last, after storage, pipelines and models, is set out in What a healthcare data platform is made of, which names them as the platform’s two shared services. This piece starts where that one stops: from one pair of records to the whole population of pairs, and from the release calendar to what a release does to a value set.

One CMS measure shows both failures in its own text. For the Hybrid Hospital-Wide Readmission measure, hospitals send the first vital signs and laboratory results of each stay, and CMS joins them to the Medicare claim to adjust for case mix, using four linking variables: the hospital’s CMS Certification Number, the patient’s Medicare Beneficiary Identifier, and the admission and discharge dates. The specification asks hospitals whose laboratory systems use local codes to map them to the LOINC codes in the measure’s value sets. A stay whose identifiers do not join and a result whose code is not in the value set are both simply missing, and CMS replaces a missing value with the median for the patient’s cohort.

From the July 2025 to June 2026 performance period, a hospital has to send linking variables for at least 70% of discharges, and no more than 30% of discharges may lack more than two lab results or more than two vital signs. In CMS’s analysis of the 2024 voluntary reporting, three-quarters of the hospitals that took part missed the earlier thresholds of 90% and 95%. A hospital below the line loses a quarter of its annual payment update.

Not every readmission measure works this way. The Hospital Readmissions Reduction Program is computed by CMS from Medicare claims and Medicare Advantage encounter data, and a readmission counts at any short-term acute care hospital. A hospital’s own record linkage and its local code maps do not enter it. The failures in this piece bite where an organisation computes or submits a number from its own data: its dashboards and registries, an electronic measure, a hybrid one.

Canada shows the two failures pointing opposite ways. CIHI’s Medical Patients Readmitted to Hospital links stays across facilities by encrypted health card number and province, drops records with an invalid number before it builds episodes, and excludes chemotherapy readmissions, coded Z51.1, from the numerator. A platform recomputing it from its own data lowers the rate for every readmission it fails to link, and raises it for every chemotherapy admission whose local code it never mapped to Z51.1. Doidge and Harron call the first kind of error “the merging and splitting of people”.

The FHIR terminology architecture and runtime operations

In FHIR, terminology is a service. Code systems, value sets and maps are resources, CodeSystem, ValueSet and ConceptMap, and the resource model with its first surprises is covered in FHIR implementation: what a project involves beyond the API. What a platform needs from the service is a handful of operations, and each one is a question.

$lookup asks what a code is. $validate-code asks whether a code belongs to a value set, which is the check a profile’s binding implies at ingest. $expand asks what a value set contains, which is how a value set becomes a table for a warehouse query. $subsumes asks whether one concept is an ancestor of another. $translate asks what a code maps to under a given map. All but $translate are normative in FHIR R4.

Two more are the ones most often missing. $closure maintains a client-side table of which codes subsume which, so a warehouse can answer is-a questions with a join, and $find-matches finds a code from its properties. On 17 October 2026, HL7’s reference server answered that $closure has to be turned on by its administrator, and did not recognise $find-matches. HL7’s own test suite for terminology servers does not test $find-matches at all.

Every operation answers under a release, and the answer changes when the release does. Each takes a parameter that pins it: version for $lookup and $subsumes, systemVersion for $validate-code, system-version for $expand, with check-system-version to fail rather than drift. The exchanges below were run against the reference server on the date shown, and each names the release it ran under.

GET /CodeSystem/$lookup?system=http://snomed.info/sct
  &code=73211009
  &version=http://snomed.info/sct/900000000000207008/version/20250201
  &property=parent

{
  "status": 200,
  "name": "SNOMED CT International Edition",
  "version": "http://snomed.info/sct/900000000000207008/version/20250201",
  "display": "Diabetes mellitus",
  "parents": [
    "126877002",
    "362969004"
  ]
}

GET /ValueSet/$validate-code?url=http://snomed.info/sct?fhir_vs=isa/73211009
  &system=http://snomed.info/sct
  &code=44054006
  &systemVersion=http://snomed.info/sct/900000000000207008/version/20250201

{
  "status": 200,
  "result": true,
  "display": "Type 2 diabetes mellitus",
  "version": "http://snomed.info/sct/900000000000207008/version/20250201"
}

GET /ValueSet/$validate-code?url=http://snomed.info/sct?fhir_vs=isa/73211009
  &system=http://snomed.info/sct
  &code=22298006
  &systemVersion=http://snomed.info/sct/900000000000207008/version/20250201

{
  "status": 200,
  "result": false,
  "message": "The provided code 'http://snomed.info/sct|http://snomed.info/sct/900000000000207008/version/20250201#22298006' was not found in the value set 'http://snomed.info/sct?fhir_vs=isa/73211009'"
}

POST /ValueSet/$expand

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "valueSet",
      "resource": {
        "resourceType": "ValueSet",
        "status": "active",
        "compose": {
          "include": [
            {
              "system": "http://snomed.info/sct",
              "filter": [
                {
                  "property": "concept",
                  "op": "is-a",
                  "value": "73211009"
                }
              ]
            }
          ]
        }
      }
    },
    {
      "name": "system-version",
      "valueCanonical": "http://snomed.info/sct|http://snomed.info/sct/900000000000207008/version/20240201"
    },
    {
      "name": "count",
      "valueInteger": 3
    }
  ]
}

{
  "status": 200,
  "total": 133,
  "used": [
    "http://snomed.info/sct|http://snomed.info/sct/900000000000207008/version/20240201"
  ],
  "first": [
    "73211009 Diabetes mellitus",
    "2751001 Fibrocalculous pancreatic diabetes",
    "4783006 Maternal diabetes mellitus with hypoglycemia affecting fetus OR newborn"
  ]
}

POST /ValueSet/$expand

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "valueSet",
      "resource": {
        "resourceType": "ValueSet",
        "status": "active",
        "compose": {
          "include": [
            {
              "system": "http://snomed.info/sct",
              "filter": [
                {
                  "property": "concept",
                  "op": "is-a",
                  "value": "73211009"
                }
              ]
            }
          ]
        }
      }
    },
    {
      "name": "system-version",
      "valueCanonical": "http://snomed.info/sct|http://snomed.info/sct/900000000000207008/version/20250201"
    },
    {
      "name": "count",
      "valueInteger": 3
    }
  ]
}

{
  "status": 200,
  "total": 124,
  "used": [
    "http://snomed.info/sct|http://snomed.info/sct/900000000000207008/version/20250201"
  ],
  "first": [
    "73211009 Diabetes mellitus",
    "2751001 Fibrocalculous pancreatic diabetes",
    "4783006 Maternal diabetes mellitus with hypoglycemia affecting fetus OR newborn"
  ]
}

GET /CodeSystem/$subsumes?system=http://snomed.info/sct
  &version=http://snomed.info/sct/900000000000207008/version/20250201
  &codeA=73211009
  &codeB=44054006

{
  "status": 200,
  "outcome": "subsumes"
}

GET /CodeSystem/$subsumes?system=http://snomed.info/sct
  &version=http://snomed.info/sct/900000000000207008/version/20250201
  &codeA=22298006
  &codeB=128139000

{
  "status": 200,
  "outcome": "not-subsumed"
}

GET /ConceptMap/$translate?url=http://hl7.org/fhir/ConceptMap/cm-administrative-gender-v2
  &system=http://hl7.org/fhir/administrative-gender
  &code=unknown

{
  "status": 200,
  "result": true,
  "matches": [
    "U  (equal)"
  ],
  "issue": null
}

POST /$closure

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "name",
      "valueString": "dexpra-wp13-1792271775250"
    }
  ]
}

{
  "status": 501,
  "resourceType": "OperationOutcome",
  "issue": "This server does not support $closure (it has to be turned on by the administrator)"
}

POST /CodeSystem/$find-matches

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "system",
      "valueUri": "http://snomed.info/sct"
    },
    {
      "name": "version",
      "valueString": "http://snomed.info/sct/900000000000207008/version/20250201"
    },
    {
      "name": "property",
      "part": [
        {
          "name": "code",
          "valueCode": "363698007"
        },
        {
          "name": "value",
          "valueCode": "39607008"
        }
      ]
    },
    {
      "name": "exact",
      "valueBoolean": false
    }
  ]
}

{
  "status": 404,
  "resourceType": "OperationOutcome",
  "matches": 0,
  "issue": "Unknown operation on this server: POST /r4/CodeSystem/$find-matches"
}

SNOMED CT adds a way to define a value set without listing its members. FHIR’s implicit value sets address everything below a concept, everything in a reference set, or everything an Expression Constraint Language query selects, and ECL is at version 2.3. An implicit value set has no fixed membership. It is whatever the named release says is below the concept today.

Maps changed most between FHIR versions. R5 calls its ConceptMap an “extensive redesign”: the equivalence of each mapping became a relationship with five codes, unmatched rows moved to an element of their own, and a row can now map a whole value set. A map held as R4 is converted, not copied.

A platform consumes terminology in one of two ways. It calls the service as data arrives and as queries run, or it loads a release into tables, often with a closure table of every ancestor pair, and joins against them. Both need to record which release they used. The first gets it back in every response; the second has it only if someone writes it down when the tables are loaded.

Global standards and the US and Canadian code systems

A US platform meets two families of code systems. The HIPAA code sets are the ones claims carry: ICD-10-CM and ICD-10-PCS, HCPCS with CPT, the National Drug Code and the dental code. The clinical vocabularies are the ones US Core binds: SNOMED CT, LOINC and RxNorm, with CVX for vaccines and UCUM for units. Their terms differ. CPT needs a licence from the American Medical Association for every product that contains it, while HCPCS Level II, ICD-10-CM, the NDC directory and CVX are free downloads. SNOMED CT costs nothing in the US, where NLM distributes it under the UMLS licence, which is free and needs an account; RxNorm’s codes are in the public domain, but its full release needs that licence too.

Value sets have a home of their own in the US. The Value Set Authority Center, run by NLM with ONC and CMS, holds the value sets behind CMS’s electronic measures, and each value set has a steward who reviews, approves, publishes and maintains it. Reading one needs a free UMLS account and an API key. US Core’s own terminology page says so, because its medication, immunisation, allergy and vital-sign bindings point at VSAC value sets. The UMLS Metathesaurus links these vocabularies concept by concept: its 2026AA release counts 3,530,466 concepts from 195 sources.

A Canadian platform carries a different set. SNOMED CT’s Canadian Edition comes from Canada Health Infoway, free with an Infoway account after accepting two licence agreements every year, released quarterly in February, May, August and November, with French translations. Infoway also publishes pCLOCD, the pan-Canadian LOINC observation code database, in English and French each March and September. Hospitals report diagnoses and interventions to CIHI in ICD-10-CA and CCI, licensed by category and frozen at the 2022 version while CIHI assesses ICD-11. The Canadian Clinical Drug Data Set is Health Canada’s, under the Open Government Licence. And ATC, which PS-CA lists among its candidate drug code systems, does not allow commercial copying or distribution without the WHO Collaborating Centre.

Outside both countries, ICD-11 is licensed under Creative Commons with no derivatives, and WHO’s terms say mapping or crosswalks between ICD-11 and other terminologies need a separate written agreement, which matters to anyone building a ConceptMap to it. England’s dictionary of medicines and devices, dm+d, is released weekly under the Open Government Licence for TRUD. In a country that is not a SNOMED International member, use has to be registered before it starts, and fees may apply.

Binding strength decides how much a guide’s value set constrains what arrives. US Core binds conditions, procedures, laboratory results, medications and vaccines at extensible strength: a code from the value set when one applies, something else only when none does. Canada’s PS-CA ballot and the CA Core+ draft bind Infoway’s value sets at preferred strength, which encourages them without requiring them, and PS-CA gives pCLOCD for laboratory results only as an example. The release dates of six of these code systems across a year are drawn in WP-11’s release calendar.

Terminology servers and mapping error vulnerabilities

Terminology goes wrong without an error in three ways. A map lives in a spreadsheet with no record of who made it or under which release. A value set is expanded under a release nobody wrote down. And a release changes a value set by itself.

The third is the least visible. On 17 October 2026 the same definition, everything that is a Diabetes mellitus in SNOMED CT, expanded to 133 concepts under the International release of February 2024 and to 124 under February 2025. Nine concepts had been inactivated in between, among them Type 2 diabetes mellitus without complication and Type 1 diabetes mellitus without complication; one had moved out from below Diabetes mellitus; one had arrived. A count built on the newer expansion no longer finds records coded with the retired concepts unless the platform follows the release’s history, and nobody edited anything.

SNOMED CT is also changing how it records inactivation. Its March 2026 release notes deprecate the Concept Non Current indicators, over 374,000 of them, and remove them from the release files from January 2027. A pipeline that reads that reference set to follow retired concepts has a date to work to.

A map that records only a source code and a target code loses what a reviewer needs: how close the match is, which release the target was chosen in, who made it, when, its status and who checked it. A FHIR ConceptMap element carries all of them.

Mapping errors are real and mostly small. In 2010 Lin, Vreeman, McDonald and Huff reviewed 884 voluntary LOINC mappings at three US institutions: four went to totally unrelated codes, and 36 had an error on at least one of LOINC’s six axes. They named four kinds of systematic error, from human slips to not knowing LOINC’s naming rules, and counted none of them. The sharper finding was that for 562 of the 880 tests the reviewers could not tell the specimen from the local name at all. A 2025 study of research-use codes at seven Korean university hospitals found more than 15% inconsistent, mostly in the analyte and the method.

A server is easier to choose on what can be checked than on what is claimed. HL7 publishes a terminology test suite of 1,209 tests in 38 suites that its validator runs against any endpoint, and approves servers that pass it for the modes they claim. On 17 October 2026 the approved servers were its own reference server, FHIRsmith, and CSIRO’s Ontoserver. HL7 publishes approvals, not per-test results, and no response time for any server was found at a primary source. Snowstorm Lite holds one release at a time, so it cannot compare two, and VSAC’s FHIR server states which version of HL7’s tests it meets.

HL7’s runner checks a server against HL7’s cases. A platform’s own value sets need runs of their own: the operations its pipelines call, at the releases it pins, compared release to release for every value set that feeds a published number.

Patient identity services and the Fellegi–Sunter framework

A patient identity service keeps an index of the people a platform’s records belong to: a master patient index inside one organisation, an enterprise index across several, a registry across a region. Its errors have names. A duplicate is two entries for one person in one facility’s index, and an overlap is one person with entries in two facilities that were never linked; both are missed links. An overlay is one entry holding more than one person, from a wrong selection, an interface or a merge of two people: a false link.

Linking and merging are different decisions. A link keeps both records and relates them; a merge retires one. In FHIR the retired record carries a Patient.link of type replaced-by, HL7 v2 sends an A40 merge event, and IHE’s Patient Master Identity Registry profile sends the merge to every subscriber. Undoing a wrong merge has to travel the same paths. The IHE profiles that cross-reference and query identities, PIXm and PDQm, are introduced in IHE Radiology profiles: how imaging systems work together.

Matching comes in three kinds. Deterministic matching applies rules, such as the same identifier, or the same name, birth date and ZIP code. Probabilistic matching weighs each field by how often it agrees for the same person and how often it agrees by chance, which is the Fellegi–Sunter model; the match weights panel in WP-11 works one pair through it, field by field. Referential matching compares each record against a third party’s reference file of identities, which GAO describes as data from non-health care sources such as credit bureaus. Privacy-preserving linkage is a constraint on any of the three, not a fourth algorithm.

FHIR’s Patient/$match operation asks a server for candidates and, through the draft match-grade extension, gets each one back graded certain, probable, possible or certainly-not. The operation itself “does not specify any particular algorithm, nor a minimum set of information”. HL7’s FAST identity guide adds example input weights and a scoring scale, and says its scoring “has not been widely implemented/tested”.

{
  "resourceType": "Bundle",
  "type": "searchset",
  "entry": [
    {
      "resource": { "resourceType": "Patient", "id": "example-1" },
      "search": {
        "mode": "match",
        "score": 0.97,
        "extension": [
          {
            "url": "http://hl7.org/fhir/StructureDefinition/match-grade",
            "valueCode": "certain"
          }
        ]
      }
    },
    {
      "resource": { "resourceType": "Patient", "id": "example-2" },
      "search": {
        "mode": "match",
        "score": 0.71,
        "extension": [
          {
            "url": "http://hl7.org/fhir/StructureDefinition/match-grade",
            "valueCode": "probable"
          }
        ]
      }
    }
  ]
}

Record matching is not identity proofing. NIST’s Digital Identity Guidelines, SP 800-63-4, final since July 2025, govern how a person proves who they are to a system; a matcher decides whether two records already held describe the same person. The digital health identifier added to Ontario’s PHIPA in 2025, created through validation and verification services, is the first kind of thing, not the second.

A probabilistic matcher produces a score, and two thresholds turn it into a decision: link above the upper one, no link below the lower one, and a person decides in between. Where the two sit trades merging strangers against splitting one patient in two, and the band between them is a queue that somebody staffs. No instrument found sets them. HL7’s FAST guide gives example input weights, TEFCA’s technical framework says matching algorithms vary today, and AHIMA puts thresholds with the organisation’s information governance.

The model behind the score assumes that fields agree or disagree independently. Twins, families at one address and a newborn sharing a parent’s details break that assumption, and they are part of why the review band exists. The panel below scores a month of candidate pairs exactly under the model, for inputs you set, and puts its estimate beside the one measurement a third party has published.

Privacy-preserving record linkage and cryptanalysis

Some records have to be linked by organisations that may not share identifiers. Two designs exist. In separated linkage, identifiers go to a linkage unit and content to the analyst, with a key between them: ICES converts each Ontario health number into one anonymous ICES identifier, and at Statistics Canada linkage staff see identifiers while file builders see data without them. In token linkage, each source turns identifiers into tokens and the tokens are compared. Why matching has to happen while identifiers are still inside the building is set out in the on-premises and hybrid clinical AI framework.

The best-known token method encodes names as Bloom filters. Schnell, Bachteler and Reiher’s 2009 method splits a name into pairs of letters, sets bits in a filter for each pair, and compares filters by the Dice coefficient, so Smith and Smyth still look alike without either side seeing the name. In 2014 Niedermeyer and colleagues showed a manual attack on Bloom-filter-encoded surnames that needed nothing more than a public list of common surnames.

The US rules on tokens are specific. HHS’s de-identification guidance says codes derived from protected health information, cryptographic hashes included, may be disclosed under expert determination as long as the keys are not, including to the recipients, and that a hash made without a secret key counts as an identifying element. NIST SP 800-188 describes keyed hashing with a 256-bit random key, warns that organisations sharing one pseudonymisation scheme can re-identify each other’s data, and does not recommend hashing direct identifiers. It sets out no technique for strengthening Bloom filters.

Strengthening a filter costs links. A 2021 evaluation by Franke and colleagues tested nine techniques on two US voter files with real errors between snapshots. Several “drastically reduce linkage quality”, while salting and XOR-folding flattened the bit frequencies an attack needs and kept quality high. The authors had not yet tested them against modern attacks.

Identity ecosystems and privacy rules in the US, Canada and Europe

The United States has no national patient identifier, and Congress keeps renewing the bar. The 2026 appropriations act again forbids spending federal funds on adopting a unique health identifier “until legislation is enacted specifically approving the standard”, as every such act has since 1999. US matching therefore rests on demographics. USCDI v6’s patient elements are names, previous name, birth date, sex, current and previous address, phone and email, with addresses to the Project US@ specification, and include no Social Security number. TEFCA’s technical framework requires every available demographic in a query and leaves the algorithm to each network. Inside its own programmes, Medicare links by its own identifier, the MBI, which is why the hybrid measure can join EHR data to claims at all.

Canada shows the other case. A provincial health number, ten digits for life in Ontario with a version code on the card, settles most matches inside a province. CIHI’s data quality documentation puts the share of hospital abstracts with a missing or invalid number at 1.40% for acute care and 1.41% for emergency and ambulatory care in 2025–26, counting a number shared by a child and its mother as invalid. What a number leaves out is specific: newborns before their own number arrives, people who have just moved between provinces, refugee claimants on federal coverage, people treated outside their province. None of them is what US reference data was built to cover, and no referential vendor found documents Canadian reference data.

Ontario’s PHIPA s. 34 governs who other than a custodian may collect, use or disclose a health number, and since 2020 it lets a custodian providing care use the number, with consent, to identify the person’s records, verify their identity or link their records. Ontario’s Provincial Client Registry, which its operator says covers 98% of Ontarians, offers a probabilistic match that returns a score and refuses queries below its minimum criteria. Whether a particular use complies is not this article’s to say.

Europe sets its linkage rules around the dataset. GDPR’s research article says safeguards “may include pseudonymisation”, a listed safeguard rather than a requirement. The European Health Data Space regulation, whose secondary-use rules apply from March 2029, releases data anonymised where that serves the purpose and pseudonymised otherwise, keeps the key that reverses it with the health data access body or a trusted third party, and gives people a right to opt out of secondary use. England makes recording the NHS number mandatory, with exceptions, records whether it was traced and verified, and makes secure data environments the default route to NHS data for research.

Algorithmic bias in patient identity

Linkage error does not fall evenly. A 2010 review of 33 studies that compared matched and unmatched records found incomplete linkage associated with age, gender, race, setting, and socioeconomic and health status. The 2018 GUILD guidance on linked data says linkage error “disproportionately affects disadvantaged groups”.

Two studies put numbers on it. At ICES, Ontario’s permanent resident records from 1985 to 2012 linked to the provincial registry at 86.4% overall, 78.0% for people born in Eastern Asia and 61.4% for people aged 85 or over. In Indiana in 2026, a probabilistic matcher’s sensitivity ran from 0.70 to 0.97 across age groups, lowest where fields were missing or disagreed. When linkage misses more people in one group, every rate computed over linked records is biased for that group, and nothing raises an error.

Newborns show the mechanism. The Joint Commission has required distinct newborn identification since 2019, and its safety notice on the subject still describes temporary names such as Babyboy Smith, record numbers assigned in sequence to babies born close together, and names changed before discharge. The remedy is the same as for any linkage error: measure it by group on your own data, and report it.

Comparing products and testing them on your own data

Identity services come in kinds: matching built into the EHR, enterprise index products, referential services, open-source indexes, linkage libraries and, in Canada, provincial registries. What can be checked about each is its licence, how it is deployed, which standards it documents and what it says it covers. What cannot be checked from outside is accuracy.

Published matching accuracy is almost all vendor-reported. One third-party evaluation of a commercial matcher exists. In 2022 Grannis and colleagues measured a referential and a probabilistic algorithm against 30,000 hand-reviewed pairs from the Indiana Network for Patient Care, and found sensitivity of 0.94 and 0.64 at almost identical precision. Its funder, the California HealthCare Foundation, holds a minority stake in the referential vendor, Verato, and the paper says so. No comparison of identity products against each other published since 2020 was found, and every referential vendor that states its coverage states US identities.

The figures most often repeated about patient matching do not survive being traced. Match rates “as low as 50%” was one organisation’s self-reported rate between separate EHR instances, from a 2014 interview. Eight per cent of records being duplicates comes from an EMPI vendor’s white paper about indexes from 2000 to 2003. Eighteen per cent comes from a crowdsourced poll in a press release that also ranked vendors. On the terminology side, 6% to 19% of laboratory tests that cannot be mapped to LOINC is a 2006 study of five Indian Health Service facilities.

So the honest evaluation is local. For terminology, run the operations your pipelines call against your own value sets at pinned releases, and compare them release to release. For identity, have two people review a sample of your own candidate pairs, with a third settling disagreements, and include pairs the system did not link, because those are where missed links hide. Measure precision and recall at several thresholds and cost the queue at your own minutes per pair. In the Indiana evaluation the two reviewers agreed on 96.1% of pairs inside the blocking schemes and 86.8% outside them, so the review needs its tie-breaker.

Platform governance and the RECORD statement

Both services are governed as releases. A value set’s content, a map, the adoption of a new release, each threshold, a merge and an unmerge are decisions with an owner, a date and a record. For a VSAC value set the owner is its steward. For thresholds, AHIMA puts the decision with information governance, and no instrument found sets them. For the rest the owner is the organisation, and what matters is that someone is named.

The test of governance is whether a published number can say what it was computed under: which release each value set was expanded in, which version of each map, which thresholds were in force when its links were made. A number that cannot say that is a number nobody can reproduce.

Researchers meet the same requirement from the other side. The RECORD statement, a reporting guideline for studies that use routinely collected health data, asks authors to say whether databases were linked, to list the codes and algorithms that select the population and define its variables, and to describe “the methods of linkage and methods of linkage quality evaluation”. RECORD is a guideline for authors and grades nothing. It is, in effect, a list of what an analyst has to be able to get from the platform.

What governs each part of the two services is uneven. The core terminology operations are normative in FHIR R4; maps, closure and the identity operations are trial use; IHE’s identity profiles are trial implementations; and the FAST guide, a standard for trial use, leaves the matching method out of scope. Where the two thresholds sit, which release a value set was expanded under and who approved a map are set by nothing outside the organisation.

That is where a platform’s own decisions go, and the case for owning them. Both services are built from settled parts. The decisions that move a published number are local, and the only evidence that they were made well is measured on the organisation’s own data and written down beside the number.