Two healthcare systems can use the same short record ID without referring to the same record or person. An application that combines their exports must preserve the context that makes each reference meaningful. A database can store every imported row successfully while an integration loses that context and joins information incorrectly.
FHIR distinguishes a resource’s logical ID from its business identifiers. That distinction is useful when evaluating a database foundation for cross-system information: the project needs to preserve locations, identifier scope, and accepted mappings, rather than assume that a familiar-looking number supplies a universal identity.
Keep the logical ID with its resource and server context
The published FHIR R5 resource specification says a logical ID is unique among resources of the same type on the same server. A resource’s location combines the server address, resource type, and logical ID. A copy on another server may or may not keep that logical ID.
Consequently, a bare ID is not a global key for a consolidated estate. In a hypothetical integration, two source servers can each hold a patient resource with the same local ID. The integration should not merge them on that basis. It should retain enough source context to identify which resource an imported reference actually meant, including when a later copy is given a different local ID.
Preserve the scope of a business identifier as well
FHIR also represents business identifiers separately. Its Identifier datatype includes a system field describing the identifier’s namespace and a value field. These supply context beyond a displayed number; the resource’s storage ID and a business identifier answer different identification questions.
A proposed data design should preserve the namespace supplied by the source rather than remove it during normalization. The same value from different identifier systems should not be treated as a proven match merely because the text agrees. If an import lacks the context needed for the intended match, the application needs an explicit handling decision. The database should not silently invent the missing authority or accept a guessed relationship as established fact.
Separate record mapping from a decision about the underlying entity
Linking a copied resource to its original is one task. Deciding whether records from separate organizations concern the same underlying entity can require additional evidence and an approved matching process. Successfully preserving a server reference does not, by itself, settle that second question.
The distinction matters when a consolidation pilot is scored. A project can demonstrate faithful import and reference preservation without claiming that every cross-system identity relationship has been resolved. Reviewers should be able to distinguish a source-provided mapping, an approved matching decision, and an unresolved candidate relationship. These are proposed evidence categories, not a prescribed matching policy or a claim about a particular healthcare organization’s implementation.
| Consolidation task | Context the proposal should preserve | What a short ID alone cannot establish |
|---|---|---|
| Locate an imported resource | Its source server, resource type, and logical ID | A unique location across every source system |
| Retain a business identifier | Its supplied namespace and value | That equal text from different systems means the same identifier |
| Follow a copied resource | The mapping between original and target locations | That a new server necessarily retains the original local ID |
| Connect records across organizations | The accepted evidence for that relationship | That successful storage proves the relationship is correct |
Test reference preservation before presenting a unified view
A proposed pilot should include two sources that reuse a local ID, a copied resource assigned another ID, and a record whose identifier context is incomplete. Use approved synthetic records and examine how the application represents each case. The objective is to expose assumptions before they become part of a convincing combined screen.
Then follow references through an export or downstream consumer. A consolidated database may preserve the full source context while a report or API later drops it. The acceptance boundary should therefore include the selected consumers, not end with a correct-looking import table. No healthcare records or servers were accessed for these exercises in this article.
Evaluate OceanBase on explicit relationships and mappings
OceanBase’s official repository describes its distributed relational database role. That makes it a candidate to assess for structured source references, namespace-qualified identifiers, and the project’s accepted mapping records. The positioning does not establish native FHIR-server conformance or automatic identity resolution.
A PostgreSQL-based design or another shortlisted operational database can be tested with the same source cases. Compare the clarity of the proposed relationships, the behavior of applications using them, and the operating work required to correct an accepted mapping. Do not use a database brand as evidence that two source records refer to the same person.
A useful acceptance result explains which identity context is retained and which relationships remain unresolved. The database decision can then support a faithful consolidated service while leaving entity matching attached to its actual evidence and responsible owners. That is a stronger foundation than a universal key created by discarding the very context that distinguished the source records.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.