How a multi-site provider could engineer trusted patient, practitioner, and facility records while retaining human control over identity decisions.
| Sector U.S. healthcare delivery | Technology Claude Code-assisted engineering | Design & Development |
Executive story
A regional healthcare provider had accumulated overlapping records as clinical, scheduling, laboratory, billing, and acquired-practice systems grew independently. One patient could have several identifiers; a practitioner could appear under different names or affiliations; and the same facility could be represented by inconsistent addresses and organizational codes. Teams used manual spreadsheets and point-to-point reconciliation to resolve discrepancies. The organization wanted a governed Master Data Management (MDM) capability that could establish trustworthy identities, preserve source evidence, and support interoperability without replacing the underlying clinical systems.
The proposed response was to build the platform with Claude Code as an engineering collaborator. Software engineers would use Claude to interpret source schemas, draft mapping and validation logic, scaffold matching and stewardship services, generate regression tests, and document interfaces. Approved software—not free-form model output—would execute record matching and maintain the master identifiers. Stewards would adjudicate uncertain or high-risk links, particularly patient identities.
Business problem: three forms of fragmentation
| Domain | Operational difficulty | What a trusted master enables |
| Patient | Different IDs, name variants, outdated contact details, possible duplicates or overlays. | Cross-system identity links, exception review, traceable record provenance. |
| Practitioner | Due to merger and acquisition of Payer organization, Provider exists in multiple payer systems. Provider names, identifiers, affiliations and specialties diverge among HR, directories and contracts. | A governed practitioner directory with verified identifiers and effective dates. |
| Facility | Location names, addresses and hierarchies differ between scheduling, finance and care systems. | An authoritative location hierarchy and consistent facility identifiers. |
The safety concern is asymmetric: overlooking a possible duplicate can fragment a record, but incorrectly merging different patients can commingle sensitive clinical information. The design therefore favors explainable evidence, conservative thresholds, and steward review over aggressive auto-merging.
The intended solution
The team defined a master identity layer that generates a stable enterprise identifier and a reversible crosswalk to each source record. Source systems remain the operational systems of record; the MDM service publishes approved identity associations and canonical attributes through controlled APIs and data products. Every surviving value retains its source, approval rule, and effective date.
Architecture and the role of Claude
The reference design uses six connected components. It is platform-neutral: a relational service, cloud lakehouse, and FHIR-compatible interfaces can be selected to match the organization’s approved stack.
| Layer | Purpose | Claude Code contribution |
| 1. Ingest | Receive versioned extracts or events from EHR, patient administration, scheduling, provider directory, billing and facility systems. | Draft adapters, schema checks and synthetic integration fixtures. |
| 2. Standardize | Apply deterministic field validation, identifier formatting, controlled terminology, address rules and source-quality metadata. | Implement reviewable transformation code and unit tests. |
| 3. Match and link | Generate candidate pairs, apply approved exact and probabilistic rules, manage confidence and non-match evidence. | Implement configurable matching services and red-team edge tests. |
| 4. Steward | Route uncertain candidates and proposed merges to authorized reviewers with reason codes and evidence. | Build work queues, approvals and audit events. |
| 5. Master and crosswalk | Maintain enterprise IDs, approved attributes, source crosswalks, version history, merge/unmerge capabilities. | Build APIs, data models, migration scripts and lineage tests. |
| 6. Publish and observe | Serve approved master views to downstream systems; monitor data quality and integration health. | Generate interface contracts, monitoring checks and support documentation. |
How the engineering team uses Claude Code
Engineers would work in a controlled repository with architecture decisions and approved schemas. Claude Code reads the codebase, edits files and can execute development commands, making it suitable for bounded engineering tasks such as the following:
Translate a source-to-target mapping into version-controlled transformation code, then inspect the change against the reviewed mapping contract.
Implement a patient candidate-generation module and a configuration-driven scoring service, then generate tests for twins, similar names, date-of-birth errors, changed surnames, shared addresses and conflicting identifiers.
Create a steward review screen that displays compared attributes and source evidence, with explicit approve, reject and defer decisions.
Generate FHIR-aligned mapping and API validation cases for Patient, Practitioner, PractitionerRole, Organization and Location where relevant, without claiming full FHIR conformance until conformance testing passes.
Draft operational runbooks for threshold changes, source onboarding, merge reversal, access reviews and incident handling.
Claude-generated code is reviewed, tested and approved through the organization’s normal software delivery process. It cannot independently change matching thresholds, write to production master tables, or approve identity merges.
A representative patient-matching decision
Consider three entirely synthetic registration records. The first and second share a verified identifier and agree on supporting demographics; they can qualify for a proposed link if the approved rules allow it. A third record has a similar name and the same household address but a conflicting date of birth and no shared verified identifier. It is held for stewardship rather than merged by inference.
| Source record | Evidence observed | Expected disposition |
| EHR: P-1042 | Verified source identifier and supporting demographics agree with appointment record. | Candidate link under an approved match policy. |
| Scheduling: S-8821 | Same verified identity credential, consistent demographics. | Link or submit for required approval according to policy. |
| Billing: B-7723 | Similar name and household; conflicting date of birth and no verified shared ID. | Do not auto-merge; open review case. |
This demonstrates the control boundary: matching evidence and policy determine the decision. Claude assists developers in producing the implementation, tests and explainable reviewer experience; it is not the final identity authority.
Implementation sequence
The program would begin with the least clinically sensitive source fixtures, using synthetic data to validate architecture before connecting protected production information. A staged rollout helps separate software engineering progress from the clinical safety decision to permit live identity linking.
| Stage | Engineering deliverable | Acceptance evidence |
| Design and source contracts | Canonical entity definitions, FHIR mappings where appropriate, source authority rules and governance model. | Approved schemas, metadata owners, field-level provenance and privacy assessment. |
| Synthetic working prototype | Ingestion, standardization, candidate matching, steward workflow and enterprise-ID crosswalk. | Reproducible test set with true matches, nonmatches, ambiguous cases and adversarial cases. |
| Controlled pilot | Read-only integration with approved sources; human-review-first matching. | Safety review of false merges/false splits, latency, lineage, authorization and recovery. |
| Controlled expansion | Authoritative publish APIs, stewardship SLAs, operational controls and versioned policies. | Change approvals, regression evidence, rollback rehearsal and incident runbooks. |
Privacy, safety and governance
Patient identity data and cross-system links can be sensitive even without diagnoses attached. The default engineering path keeps patient data out of prompts and uses synthetic or appropriately de-identified fixtures. Any processing of PHI through Claude products would require confirmation that the exact product surface, configuration, model, integrations and organization are covered by an effective Business Associate Agreement, plus the provider’s own HIPAA risk analysis. A general subscription or generic “enterprise” label is insufficient.
Restrict development agents to approved repositories and non-production environments; prohibit uncontrolled secrets or PHI in code, logs, prompts and test files.
Apply role-based access, audit trails, segregation of duties and reversible merge histories; review access to crosswalk links as carefully as access to other identifying data.
Require stewardship review for ambiguous patient candidates and clinical-safety sign-off before enabling any automatic patient linking.
Business outcomes and evidence required
The intended outcome is an engineering foundation for trustworthy identity services: fewer manual handoffs, clearer ownership of conflicting data, reusable source mappings, and a consistent way to serve approved identifiers to downstream systems. These are expected benefits of the design—not measured results from a completed customer deployment.
A credible external customer story should eventually report verified measures, with baselines and time windows, for:
Patient match precision and recall separately, including false-positive link rates and false-negative missed-link rates; report performance by relevant populations and source pairs.
Steward review volumes, reversal rates, case aging, and time to resolve ambiguous identities.
Provider and facility record completeness, attribute provenance and propagation latency.
Engineering delivery evidence, such as completed test coverage, integration milestones and reviewed Claude-assisted changes—not speculative development-time savings.
What makes the Claude approach distinctive
Traditional MDM initiatives often lose momentum in the engineering work between architectural design and a governed production service: translating inconsistent schemas, developing record-linkage code, handling edge cases, building interfaces, and keeping tests current. Claude Code offers a way for a small team to iterate across those connected tasks within an existing software repository. The differentiator here is traceable engineering assistance with human oversight, not an assertion that a language model can infer a safe golden patient record without evidence.
The same pattern can later extend to medication catalogues, vendors, payer contracts and organizational hierarchies. Expansion is subject to the same source contracts, data ownership, safety boundaries and regression gates.