A repeatable WeInfuse connector for a hub-services platform
A hub-services company wanted to offer benefits verification and prior-authorization support to infusion centers that run WeInfuse. Every new customer meant re-keying orders, patients, insurances, and authorizations. Greyfield built a containerized Python connector that pulls nine entity feeds per center through the Looker API, plus a runbook the client’s engineers use to add new centers.
entity feeds pulled for each infusion center
date-windowed pulls with stored watermarks
handed over so the client adds centers without us
At a glance
The challenge
Each infusion center customer kept its orders, patients, insurances, authorizations, physicians, appointments, and locations in its own WeInfuse tenant. In this engagement the data path was the embedded Looker, reached through the Looker API with credentials issued per center. The data had to arrive automatically and incrementally, and onboarding a new center had to be repeatable without Greyfield.
What Greyfield did
Pull nine entity feeds per center
Built a Python ETL that reads each center’s configuration, pulls patients, insurances, orders, authorizations, authorization items, authorization tasks, physicians, appointments, and locations through the Looker API, and upserts them into a database for that center.
Window every pull and keep change history
Windowed transactional feeds by created or updated date and stored a watermark per feed, with wider windows for slow-changing physician and location lists. A first run with no watermark loads those lists in full. Transactional entities keep a history of changes the pipeline observes.
Fix a connection leak on a shared database
Database connections that were opened and never closed piled up and starved the client’s other integrations. Every connection now opens in a context manager that closes it.
Pin down completeness and provider rules
Added a check that every order resolves to a physician, and agreed a rule for enrollment work: the ordering provider lives on the order and the rendering provider on the appointment, so nobody says just “provider.”
Write the onboarding runbook
Documented each step for a new center, from confirming Looker access and requesting API credentials through vendor support to creating the database, storing credentials, running the task, and confirming rows land.
What changed for the client
The connector went live for the first infusion center, and the onboarding runbook went to the client’s engineering team so it can add centers without Greyfield. What we’d do differently: build order-driven completeness checks from the start instead of adding them later. WeInfuse is a trademark of its owner; Greyfield Data is independent.
entity feeds pulled for each infusion center
date-windowed pulls with stored watermarks
handed over so the client adds centers without us
Have a report or data workflow like this?
Discuss a similar project