Provider integration
Provider migration and ongoing integration.
Current work · C# / .NET · Data mapping · APIs · State management
A healthcare customer needed to migrate provider and credentialing data into a new management platform and keep it updated. The integration maps data for 100,000 practitioners and associated practice and facility locations across roughly 60 destination entity types. It also handles approximately 4.5 million relationships linking practitioners to locations and networks/products.
My contribution
I designed and built the C# integration plugins and shared publishing layer on Gaine’s Integration Hub. A single provider profile can require dozens of related API writes. The integration applies customer-specific selection and mapping rules, then sequences writes when one resource depends on another.
It records destination IDs and publishing outcomes so the team can trace individual records, distinguish failures from intentional exclusions, and investigate the results of each batch.
Delivery and current operation
The migration is complete, and batch publishing is in production. Real-time publishing has been implemented; activation is pending joint validation of data and publishing policies by Gaine and the customer.
Case study / Provider data
Mapping, publishing, and tracking provider data
Keeping complex mappings manageable
A master profile can hold several addresses while the destination accepts one mailing address. I built profile managers that turn Gaine’s generic data entities into typed business objects, selection rules that filter and rank the records, and focused converters that map the chosen data.
This keeps source priority, eligibility checks, and other customer policies separate from field mapping and API execution. Those policies can change without spreading conditional logic through every converter.
Coordinating dependent API writes
One master profile can expand into dozens of API resources. A child resource often needs the ID returned when its parent is created. I built reusable publish plans to describe those dependencies, with a shared executor sequencing dependent writes and running independent work within configured concurrency limits.
Controls for each resource type determine which records can be created or updated, including publishing child records against an existing parent. Follow-up work can run when a resource or batch completes—for example, retrieving updated destination data after publishing a product batch—without changing the shared executor.
Recovering after partial success
I store each resource’s destination ID and a fingerprint of its last successful request. If a practitioner is created but its email fails, the next run can recognize the existing practitioner, skip its unchanged write, and retry the email.
That recognition also works before the new destination ID has returned to Gaine: an alias links the Gaine record to its saved destination state. The protection depends on a confirmed response and a successful state save; lost responses or unsaved state still require investigation.
Accounting for publishing results
I built batch reports that distinguish successful writes, failures, and intentional exclusions. Each result connects to its source record, destination ID, publishing decision, and error details.
Summaries show counts and failure rates by domain and resource type, with historical versions preserving changes to recorded outcomes. The team can move from an overall batch result to the individual records behind it.