HealthShare record deduplication should keep clinical disagreement visible

Deduplication should reduce repetition without manufacturing certainty

InterSystems currently describes HealthShare Unified Care Record as aggregated, normalized, and deduplicated from patient data across multiple sources. Those functions address three related but different infrastructure problems: gathering available records, mapping them into usable representations, and reducing repeated representations of the same underlying fact or document. None automatically resolves a material disagreement among sources.

Two records can refer to the same person and still disagree about an allergy, medication, diagnosis status, laboratory value, procedure date, name, address, or responsible organization. Even identical coded values may carry different effective times, authors, methods, certainty, encounter context, or correction status. A shared record should show the conflict and provenance until an authorized workflow establishes what can be reconciled for the intended use.

Retain the source assertion beneath the normalized view

Every shared assertion should remain linked to the originating organization, system, resource or document, author where available, patient and encounter identity context, source identifier, creation and effective times, receipt time, terminology and version, units, status, amendments, security or sensitivity labels, transformation steps, matching result, and current availability. A normalized display value should never be the only surviving representation.

Deduplication also needs a declared object boundary. A retransmitted document, a corrected result, a copied problem-list item, and a newly authored observation may look similar while representing different events. The platform should preserve why records were linked, which representation is displayed, what was suppressed from routine view, and how a reviewer can inspect and reverse the decision without losing audit history.

Make unresolved conflict an operable exchange state

An interoperability layer can identify candidate conflicts and route them, but the appropriate resolver depends on the data and exchange purpose. A source organization may need to correct its record; a receiving clinician may document a new assessment; a health information exchange may correct identity or routing metadata without changing clinical content. The record should name the issue, owner, permissible action, notification path, downstream consumers, and status.

Consumers also need to know whether they are seeing raw source assertions, a normalized view, a locally reconciled record, or a derived summary. APIs and exports should carry enough provenance and status to preserve that boundary. If a source later retracts or corrects content, the system should update availability and alert affected uses while keeping the history needed to explain earlier decisions.

Test duplicate, corrected, and contradictory records together

An implementation test should exchange the same document twice, a corrected laboratory result, equivalent codes with different units, conflicting allergy assertions, and one record initially matched to the wrong patient. Reviewers should identify what was deduplicated, what remained separate, which normalized value appeared, how conflict was labeled, who could correct each layer, and what downstream API consumers received before and after resolution.

InterSystems' official page supports the described interoperability, aggregation, normalization, deduplication, and unified-record positioning, but no patient identity, source record, mapping, terminology, match, duplicate, conflict, reconciliation, disclosure, configuration, implementation, or clinical outcome was independently tested here. Healthcare organizations and their clinical, exchange, privacy, security, data-governance, compliance, and legal owners retain their decisions.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.