Products · Connector · patient data
Medicare eligibility at intake, for hospice and home health.
For intake teams at the care companies, once patient data is switched on.
Each company connects its own NPI and Stedi account. CultureAI checks a patient's coverage and answers the questions intake actually asks: which hospice benefit period a new election would start, and whether another agency has the patient now.
StatusBuilt and tested with synthetic patients only. Mock and sandbox modes; no live mode. Real patients wait on the Netlify and Anthropic BAAs and Steven's yes.
What a check keeps
- CoverageActive or not, from the payer's answer
- Hospice benefit periodThe period a new election would start
- Another agencyWhether another hospice or home health agency has the patient now
- Medicare AdvantageWhether a plan is on file
- Unreadable answerSaid plainly; never read as eligible
What it does.
The problem
Intake calls the payer, reads a long eligibility answer and still has to work out the benefit period and whether another hospice or home health agency is already caring for the patient. A wrong guess costs the admission.
What Eligibility on Stedi does
It reads the eligibility answer and keeps a short summary: coverage, the hospice benefit period a new election would start, another agency's episode, a Medicare Advantage plan. When it cannot read an answer, it says so. It never guesses eligible.
How it works.
Each step, in order. Steps outlined in blue run in the CultureAI core, the same for every product.
- Intake
A check
From a patient record, by someone whose role allows eligibility.
- The core
The patient-data door
Name, birth date and Medicare ID are read through the one access module, and the read is logged.
- Stedi
The payer's answer
Under the company's own NPI and Stedi account. Mock or sandbox only in this build.
- The core
Sealed and summed up
The answer is sealed in the patient-data schema; a summary is kept beside it.
- The core
The AI sees less
The AI gets the summary with every date taken out, never the identifiers.
Real screens, not mockups.
Taken from the product running in its local test world, with a sample company and made-up people.
No screens yet. Eligibility has no screen of its own: it runs through the API, behind a switch that is off everywhere it could reach a real patient. When it gets one, the picture goes here.
What it does, in plain words.
Per company
Each company adds its own NPI (its check digit verified), its organization name, and its Stedi account and key.
Keys sealed
The Stedi key is sealed in the vault before anything is written and never comes back to a screen.
Synthetic Medicare cases
Tested with synthetic hospice and home health cases: benefit periods, and other agencies' episodes.
Fails closed
An answer it cannot read is reported as unreadable, never as eligible.
Minimum necessary
Each role sees only the fields its purpose needs. Billing adds the Medicare ID for eligibility; clinical sees name, birth date and sex.
On the connector framework
The same framework as every other connector: credentials, health checks, settings.
Trust and security.
What it keeps apart, what it writes down, and what it never reads. The whole picture is on Security.
- The switchPHI_ENABLED is off by default, and the code keeps it off in production whatever the setting says. Every patient-data path is blocked while it is off.
- Encrypted per companyIdentifiers sealed with AES-256-GCM under a data key per company, wrapped by a master key; a new data key every 90 days.
- Every read loggedAn append-only access log of every read, write, export and eligibility check, with fields and purpose, never values.
- Each company its ownEach HealthView company is its own covered entity. Cross-company reads are tested on every build and refused.
- Agreements firstNeon's BAA is signed and Stedi's is in place under HealthView's NPI. Netlify's and Anthropic's come before any real patient.
How it fits the platform.
Eligibility on Stedi is a thin layer on the CultureAI platform. It builds none of these itself; it uses the ones marked Uses.
- Identity and tenancyUses
Sign-in, companies under a parent, roles, the wall each company keeps
- Data and patient dataUses
One record in Neon; patient data only through its own module
- Events and jobsNot used
What happened, in one log; long work as durable jobs
- ConnectorsUses
Outside systems plugged in one way, per company
- The AI layerUses
One gateway to the model, de-identification, shared tools, cost per company
- Audit and observabilityUses
Who did what; alerts; the daily live check
- NotificationsNot used
Teams, written down, never twice, quiet hours
- Developer surfaceNot used
Keys, versions, webhooks, request logs, the kit
Connectors. Stedi's JSON eligibility API, under each company's NPI. Neon holds the sealed answers, under its BAA.
How to get it.
CultureAI is not for sale. It is installed in every company we build or back, and The Culture Group's companies come first. Each company gets it inside its own walls, set up with the rest of the platform.
Say aloha- A company is set up under its parent, with its people and owner, in one step from the Console.
- Its connectors are switched on one at a time, each with its own credentials and its admin's yes.
- Its people sign in with one CultureAI account, and the product is there.
Questions.
Can we use it with real patients today?
No. It is built and tested with synthetic patients. Real patients wait on the Netlify and Anthropic BAAs, the open items in the HIPAA safeguards document, and Steven's yes.
Does the AI see patient information?
The AI gets a de-identified summary: a token for the person, age, sex, state, the first three ZIP digits, and the eligibility summary with every date taken out.
Whose Stedi account does it use?
Each company's own, under its own NPI. Nothing is shared between companies.
Why only hospice and home health?
That is the care the Culture companies give, so those are the questions it was built to answer first.