How a change reaches each system.

Inbound: Options are data share in a data platform, REST API, event subscription and secure file transfer. No matter how the data arrives, it follows the same processing flow: the data is translated, validated, matched and stored along with other systems’ view of the same data concept. A request that arrives through the API carries a request number and an audit trail from the start.

Outbound: Options are direct synchronization through the API, reconciled change files, event notifications, Kafka streaming and replication. The route is chosen per target system. Direct synchronization covers key healthcare systems including Facets, QNXT, EZ-CAP, HealthRules Payer, symplr and Salesforce. Reconciled change files suit proprietary systems, or systems without an API. Replication also feeds the analytics estate: conformed, versioned dimensions with their lineage, so the joins arrive pre-built.

It spans practitioners, organizations, payers, patients, locations, clinical, pharmacy, claims, encounters, and consent and preference, and it maps to FHIR. Governance policies and documentation come with it.

Relationships are mastered objects, not attributes. Membership, ownership, affiliation and contracting each have their own record and history, and each is effective-dated: practitioner to location, to contract, to network, to product. So who was in this network on the date of service? has one answer. So does when did the patient grant marketing consent, and for which brand and which programs?

A query chooses its own depth, from one hop to four. Classification can be scoped: two businesses that classify the same organization differently each keep their own view as an overlay on one shared model. Reference content is shipped, versioned and maintained. Because the ontology carries the meaning and the relationships, an AI model can be pointed at governed data rather than at a schema.

Resolves transactional data against mastered records in real time, cross-domain, at production volume. The transactions give context and define relationships between the mastered domains. Without the transactional data, comparisons between systems become ambiguous, even if you understand what each system holds in a single data field.

It also directs transactions, reference data and stewardship into the ontology, enforcing versioning, history and integrity on every change, whether the change comes from a person, a connected system or an agent. Nothing reaches a consuming system unless it was published under a version, and each domain shows what every contributing source put in, named and counted.

Matching is deterministic where an identifier exists, and probabilistic but explainable where none does. Every match records the rule that made it and its score. Survivorship is decided attribute by attribute by configurable rules that assess source precedence, last update date, data validity or consistency with other data. Every losing value is kept and the deciding rule is recorded.

Cross-references map each contributing system’s identifier to the resolved one, with lineage and history. Gaine keys are permanent and never reused. At cutover, your existing identifiers can seed the registry, so downstream systems keep the numbers they use today. Merges can be undone. An unmerge restores each source’s own identifier and history and notifies the systems that consumed the old one. It is effective-dated, not rewritten.

Merge and unmerge are the most important, yet least understood, MDM capabilities. Make sure you have what you need.