Infusion center data for manufacturers and hubs
Status, dispense, and inventory feeds from infusion centers, in your contract’s format, checked before each send.
What gets in the way
Most feed problems are grain and access problems, not file format problems.
- Each infusion center keeps its data in its own tenant, and every one needs its own access and setup.
- Status and dispense counts never match, and nobody can explain the difference.
- Required fields arrive blank: diagnosis, prescriber details, payer.
- A scheduled export fails without retrying, and you find out when a file is missing.
- Your team re-keys orders, patients, insurance, and authorizations by hand for every new center.
- Onboarding a new site means hunting for credentials and setup steps someone wrote down once.
Our strongest infusion work
Two engagements, one on each side of the feed. Client and partner names stay private.
Multi-site ambulatory infusion provider
Built four manufacturer data-contract feeds in an infusion provider’s embedded Looker, with status and dispense reconciled and QA before every upload.
Read the case study
Hub-services and patient-access company
Built a Python connector that pulls nine WeInfuse entity feeds per infusion center through the Looker API, with a runbook for onboarding new centers.
Read the case studyWhat we build
For a manufacturer receiving feeds, a hub pulling data into its platform, or the center sending them.
- 01Data-contract feedsStatus, dispense, inventory, and patient master feeds in the column order and format the contract names.
- 02Checks before every deliveryUniqueness at the business grain, the right date window, required fields filled, and the exact column set.
- 03Looker API connectorsA scheduled pull for each center through the embedded Looker API, upserted into your database.
- 04Completeness and reconciliationA list of orders that don’t resolve to a patient, prescriber, and location, and feeds compared with each other.
- 05Periodic full refreshScheduled sends don’t retry or send deletes, so a regular full pull catches what the deltas missed.
- 06Onboarding runbookStep-by-step setup for a new center, so your engineers can add one without us.
The four feeds and their grains
Write the grain down before you build; most rejected files fail here.
| Metric | What it measures | Watch for |
|---|---|---|
| Status | One row per order or per status change. Check which one your contract version asks for. | Status and dispense counts are not supposed to match. Reconcile them, don’t force them equal. |
| Dispense | One row per completed administration. In infusion, a dispense is a dose given, not a fill shipped. | Every active order should appear. Pending and denied orders should not, and have no ship date. |
| Inventory | One row per location, NDC, and date, with received, removed, and balances. | Lot numbers create rows that look like duplicates. Decide whether lot belongs in the grain. |
| Patient master | One row per patient, with the identifiers the partner needs. | This is PHI. Agree on the patient key first. Internal IDs and user-facing patient numbers differ. |
How a feed project runs
- 1
Read the agreement and the data
We find where each required field lives, flag the ones often blank, and agree what one line of each file means.
- 2
Build and check
We build the files or the connection, check them against real data, and fix what fails before the first delivery.
- 3
Handoff
You get the pre-delivery checklist, the field map, and a runbook, and we can stay on for changes and new centers.
Free guides
Feeds and manufacturer programs
- Manufacturer Programs Without the Manual ReportingFree white paper (PDF): what manufacturer and hub programs ask for, why files get sent back, and how to automate them.
- Manufacturer program reporting guideWhat programs ask for, why files get sent back, and how to automate the weekly reports.
- Scheduling WeInfuse reports to SFTPRolling date filters, one backfill, and a plan for sends that fail.
Working with WeInfuse data
- WeInfuse reporting field guideHow the embedded Looker works, which Explore to use, and how to get data out.
- Why WeInfuse reports show duplicate rowsHow to tell real duplicates from expected repeats, and how to fix them.
- Orders or appointments Explore?Pick the Explore whose rows match your question before you add a field.
More in the infusion analytics guides and free tools.
Common questions
Can you get data out of WeInfuse without database access?
In our engagements, yes. We used the embedded Looker, either as scheduled reports or through the Looker API with credentials issued for each center. Access paths vary by customer, so we confirm yours before scoping.
Who has to approve access to an infusion center’s data?
The infusion center. It owns the data, signs the business associate agreement, and asks its EHR vendor for any API or reporting access. Plan for that request early, because it is often the slowest step.
Why don’t status and dispense counts match?
They have different grains. Status is usually one row per order, and one order has many appointments. Dispense is one row per completed administration. Every active order should show up in dispense, but the counts will differ by design.
What happens when a scheduled send fails?
Scheduled sends from the embedded Looker don’t retry, and they don’t send deletes. We add a check that each expected file arrived and a periodic full refresh to catch anything the regular sends missed.
Can our engineers run the connector after you leave?
Yes. In our hub integration the client’s engineers add new centers from the runbook we wrote. Credentials and watermarks live in a cloud parameter store, not in the code.
Bring the feed that keeps getting rejected
Or the center you can’t onboard. Send us the contract or the spec and we’ll tell you where the data will fight you.
WeInfuse is a trademark of its owner. Greyfield Data is independent and not affiliated with WeInfuse.