The FHIR specification puts the scale of the problem in its own text: around 2% of patient registrations are in error, mostly duplicates. A hospital that has been through one merger holds patients carrying two or three valid MRNs, none of them wrong.
Patient.identifier is where the resource holds all of them at once, as a repeatable list rather than a single field. Patient.id exists too, and it names one record on one server rather than the person that record describes. A status flag and a set of links to other records fill in the rest of what the resource treats as identity.
That shape is not a gap in the resource. It is what FHIR gives to a problem every multi-system deployment already has. The same person shows up under different numbers in different places, and nothing forces those numbers to agree on their own.
FHIR in Plain Terms: How the Standard Models Clinical Data covers how a resource is built in general and how resources reference each other. This article stays inside Patient and asks a narrower question: what does the specification say identity is, and what happens when a study built around one identifier space meets a record built around another.
The release cited throughout is FHIR R4, version 4.0.1, in which Patient is a normative resource. R4 is not the newest release; the R4 pages themselves carry the notice “The current version which supercedes this version is 5.0.0.” It stays the release that matters here because US Core, the national base guide the parent article references, is still published against R4, currently at STU 9.
Why the FHIR Patient Resource Treats identifier as a List
Patient.identifier carries a cardinality of 0..*, zero, one, or many. The specification’s own description of the element is short: “An identifier for this patient.” Nothing in that phrase says which of a patient’s several possible numbers is the right one, and a list is the honest answer to a question that does not have a single number.
The reasoning shows up in the resource’s own notes on identity. A Patient record’s resource id can never change once assigned, so the specification is explicit that identifiers people actually work with should not double as that id, because those numbers can change. It gives an institutional reason directly: “This is also useful for the case of institutions that have acquired multiple numbers because of mergers of patient record systems over time.”
A hospital that has been through even one merger already has patients carrying two, three, or more valid MRNs, none of them wrong. Modeling identifier as a repeatable list is how the resource holds all of them at once, instead of forcing a choice the data does not support.
System and Value: What Makes an Identifier Namespace Meaningful
Each entry in that list is an Identifier, not a bare string. Two of its fields do the real work: system, described as “The namespace for the identifier value”, and value, described as “The value that is unique”. The same page states the rule that binds the two: “The value SHALL be unique within the defined system and have a consistent meaning wherever it appears.”
That is where the scope sits: a value is only unique inside the namespace system names. The number 4521 issued by one hospital’s registration system and the number 4521 issued by a different hospital’s system are not the same identifier because the digits match. Strip system away, and value is a string with no way to know what it was drawn from.
That is also why an identifier quoted on its own, with no source attached, does little for reconciliation. Two systems confirming they mean the same patient need to agree on system before value can tell them anything.
Use and Assigner: What Ranks One Identifier Above Another
Patient.identifier.use narrows further, bound to a required set of five codes: usual, official, temp, secondary, and old. usual is “The identifier recommended for display and use in real-world interactions.” official is “The identifier considered to be most trusted for the identification of this item.” That same definition then says the determination of official is subjective, and that implementation guides often supply additional guidelines for its use.
Read that qualifier carefully, because it sets the ceiling on what use can do for a receiving system. A superseded or temporary identifier keeps its own code instead of being deleted, so an identifier list with use populated still shows which entry is current. What use does not give you is a determination two parties are obliged to agree on.
assigner, a reference to an Organization, answers a different question: who issued this number. The field’s own description is plain: “Organization that issued id (may be just text).” Pairing use with assigner is what lets a receiving system rank several identifiers on one patient, but that ranking is only as reliable as the implementation guide both sides work to.
The active Flag Describes the Record, Not the Person
Patient.active is a boolean, and a modifier element, meaning it changes how the rest of the resource should be read. Its definition: “Whether this patient record is in active use. Many systems use this property to mark as non-current patients, such as those that have not been seen for a period of time based on an organization’s business rules.”
active says whether this record is the one to use, not whether the patient is alive or currently receiving care. A deceased patient’s record can stay active for some time after death, and an inactive record can still belong to someone alive who simply has not been seen recently.
Patient.link: Four Ways Two Records Can Describe the Same Person
Even with identifier, use, and active in place, a system can still end up holding two separate Patient resources for one person. link is where the FHIR Patient resource names that situation instead of assuming it away, with a required type code carrying exactly four values.
The specification frames the underlying problem directly: “Managing Patient registration is a well-known difficult problem. Around 2% of registrations are in error, mostly duplicate records.” Each link type answers a different shape of that problem, in the specification’s own words:
replaced-by: “The patient resource containing this link must no longer be used. The link points forward to another patient resource that must be used in lieu of the patient resource that contains this link.”replaces: “The patient resource containing this link is the current active patient record. The link points back to an inactive patient resource that has been merged into this resource, and should be consulted to retrieve additional referenced information.”refer: “The patient resource containing this link is in use and valid but not considered the main source of information about a patient. The link points forward to another patient resource that should be consulted to retrieve additional patient information.”seealso: “The patient resource containing this link is in use and valid, but points to another patient resource that is known to contain data about the same person. Data in this resource might overlap or contradict information found in the other patient resource. This link does not indicate any relative importance of the resources concerned, and both should be regarded as equally valid.”
Two details matter for anyone building against link. A refer relationship runs one direction only: “The record referred to does not point back to the referring record.” A seealso relationship does not have to be mutual either: “It is not a requirement that such links are bilateral.”
The FHIR Patient resource is not describing a tidy graph where every edge resolves cleanly. It is naming the actual shapes duplicate registrations, indexes, and distributed records take, rather than offering one generic related-record pointer.
Why Patient.id Is Not the Patient’s Identity
Resource.id is worth being precise about, because the temptation to treat it as an identifier runs deep. The specification defines it plainly: “The logical id of the resource, as used in the URL for the resource. Once assigned, this value never changes.” That stability is real, but it is server-local: “The logical id is unique within the space of all resources of the same type on the same server.”
The specification draws the distinction explicitly: “Although the logical id of a resource changes as it moves from server to server, all copies of the resource refer to the same underlying concept, and this concept may also be represented in other formats (variously, HL7 v2, CDA, XDS, and many more).” What identifies that underlying concept consistently, across every system and every format, is what the specification names directly: “This is known as the business identifier, and is found in the identifier element, which has the type Identifier.”
Resource.id answers which record this is, on this server. Patient.identifier answers who this person is. FHIR keeps those two questions in different fields on purpose.
When a DICOM Study Meets a FHIR Patient Record
All of it becomes concrete the moment a DICOM study has to be matched to a FHIR-facing record. A DICOM object carries its own patient identity independently, a Patient ID paired with Patient’s Name inside the object’s own data set, in a namespace a FHIR server never sees.
The .dcm File: What Is Inside a DICOM Object documents the same asymmetry on the DICOM side: the UIDs tying an object to its study and series are globally unique by construction. Patient ID is not, which is why the standard carries an issuer alongside it too.
A study arriving with one facility’s Patient ID and a FHIR Patient resource carrying a different assigner’s identifier are two separate identity claims about, presumably, one person. Nothing in either standard reconciles them automatically. On the imaging side, that reconciliation across departmental and organizational boundaries is the problem IHE’s Patient Identifier Cross-referencing profile addresses, covered in PACS Integration: Connecting Modalities, RIS, and the EHR. Something, a PIX manager, a master patient index, or a narrower point-to-point mapping, has to sit between the two identity spaces and do the matching neither standard does by itself.
Scoping the Work Before Promising Patient Matching
Scoping FHIR Patient work honestly starts with naming which identifier space a counterparty actually uses. That means asking which system URI backs their assigner, whether they distinguish official from usual, and whether their link usage assumes one resolved record or an unresolved set. A Capability Statement says which elements a server supports. It does not say whether their identifier list is clean.
For imaging specifically, the practical question is where identity gets reconciled, not whether it will need to be. The published native DICOM surface for EBM mAIn PACS® is C-STORE, Query/Retrieve, Modality Worklist, and Storage Commitment. That surface moves and stores a study using whatever Patient ID and issuer the sending modality already carries.
FHIR is not part of what EBM offers in this market today. Matching a study’s DICOM patient identity against a FHIR Patient resource’s identifier list happens outside that DICOM surface, through whichever mechanism a deployment already has in place.
Getting identifier, use, assigner, and link right before a project promises “patient matching” is what keeps that reconciliation work scoped instead of assumed.