The Hospice Solution is the agency workspace for Medicare hospice: referral intake that converts into a patient and an episode in one step, a benefit-period engine that does the 90/90/60 arithmetic, certification and Face-to-Face gating, a 15-day IDG cycle, HOPE windows with iQIES batches, per-diem claims with the Notice of Election gate, an aggregate-cap tracker, and thirteen months of bereavement — all on the same platform and the same patient record as the network portal and the EMR.
Hospice is not ambulatory care with a different diagnosis list. It is an episode: a patient elects the benefit, gives up curative treatment for the terminal condition, and the agency takes responsibility for comfort, for the family, and for a stack of federal obligations with dates attached. A certification that is not signed makes days unbillable. A Notice of Election filed late makes days provider-liable. An interdisciplinary group that misses its fifteen-day window is a Condition-of-Participation finding. The Hospice Solution is built around that shape — one episode record that carries the benefit periods, the certifications, the meetings, the assessments, the visits and the claims, so the deadlines are computed rather than remembered.
The screen map follows the agency's day. A dashboard opens on census, the deadlines that are close, today's visits and the accounts-receivable position. Referrals move through an intake state machine and convert into a patient and an episode in one transaction. The census board shows level of care, length of stay and Notice-of-Election status. Certifications, IDG, HOPE and Compliance are four worklists over the same episodes, each answering a different regulator's question. Billing, the cap tracker, bereavement, volunteers, staff credentials, the fax centre and ten tabs of reports close the loop. The episode chart itself carries nine tabs, and the medications, family contacts and documents tabs read the platform's own tables rather than hospice copies of them.
Two design rules run through all of it. Rules that decide money or compliance are pure functions with their own unit tests — benefit-period arithmetic, the Face-to-Face gate, the NOE deadline, sequential billing, the volunteer share, the cap position — so the worklist, the nightly scan and the claim builder cannot disagree about the same episode. And every dollar figure and every clinical threshold is injected from the deployment's own configuration: per-diem rates, the cap amount, QAPI targets and vital limits are settings, not constants in the code. Signed visit notes are immutable and corrected by addendum, because a hospice chart is a legal record before it is a workflow.
Needs · To know the census, the money and the exposure in one place, and to see a problem while it is still fixable.
Gets · A dashboard with census by level of care, the deadlines closest to breaching, today's visit board and the AR position; the aggregate-cap tracker with headroom and utilisation; ten report tabs computed from live data rather than a monthly export.
Needs · Every active patient reviewed by the IDG in time, visits happening on the ordered frequency, and notes signed.
Gets · The IDG board with the fifteen-day due worklist, meetings with attendance and finalised minutes, plan-of-care versions approved in the meeting, the week-calendar schedule, and the vitals monitor with comfort-oriented thresholds.
Needs · An agenda that is already built, and minutes that survive a survey.
Gets · Meetings that draw the patients due for review, per-patient IDG review records, and finalised minutes that stamp the plan-of-care version the group approved.
Needs · The certification, Face-to-Face, NOE, IDG and HOPE obligations of every open episode, ranked by how much trouble each one is.
Gets · A compliance worklist built from classifiers that separate a critical breach from an approaching deadline, plus a nightly scan that raises the same findings as platform notifications so nobody has to open the page to learn.
Needs · Claims that do not go out before they can be paid, and a cap position that is known before the year ends.
Gets · A claims board for the Notice of Election, notices of termination and the monthly per-diem claim, with the NOE gate and Medicare sequential-billing rule enforced before submission, room-and-board claims where the agency is configured for them, and a continuously computed cap position.
Needs · A thirteen-month programme that starts itself, and a volunteer share that will hold up at survey.
Gets · A bereavement case opened automatically when an episode discharges to death, with default touchpoints scheduled across thirteen months and every contact logged; a volunteer roster with hours and a live gauge against the five-percent Condition of Participation.
| Area | Today | With Hospice Solution |
|---|---|---|
| Benefit periods | Someone works out the third period's start date on a calendar, and the Face-to-Face is remembered late. | The engine computes every period from the election date — two 90-day periods then 60-day periods — with the recertification window opening fifteen days early and the Face-to-Face requirement attached from the third period on. |
| Notice of Election | A note in a diary, and an argument later about which days were provider-liable. | The five-day deadline is computed from the election date; before it the worklist counts down, after it the alert names the date from which days are provider-liable and no monthly claim can be built. |
| Recertification | A period rolls over and the certification catches up afterwards, if it catches up. | Opening the next period is refused until the certification carries both physician signatures and, from the third period, a completed Face-to-Face — and the refusal names the missing item. |
| IDG | A recurring meeting invitation, an attendance sheet, and a scramble to reconstruct minutes before a survey. | A fifteen-day due worklist, meetings with recorded attendance and per-patient reviews, and finalised minutes that stamp the plan-of-care version the group approved. |
| Quality assessments | HOPE records tracked on a spreadsheet, submission batches assembled by hand. | Admission and update windows computed per episode, completion tracked against them, and batches built, manifested and marked submitted from the HOPE board. |
| The cap | A year-end calculation that arrives as a surprise. | A running position — payments against the allowance the beneficiary count earns — with headroom and utilisation visible all year, from a cap amount the agency configures. |
| Bereavement | A thirteen-month obligation that depends on someone remembering to start it. | A case opens when the episode discharges to death, with the default touchpoint plan already scheduled and every contact logged against it. |
12 modules, each describing what is built today.
A real intake state machine that ends in a patient and an episode, not a spreadsheet handed to admissions.
The board the agency runs on: who is on service, at what level of care, and for how long.
The 90/90/60 chain, the recertification window and the Face-to-Face gate, computed per episode.
The fifteen-day interdisciplinary cycle with attendance, per-patient reviews and finalised minutes.
Assessment windows tracked per episode and batched for CMS submission.
Notice of Election, certification, IDG and HOPE obligations classified by what is actually at stake.
Indicators computed from the chart rather than typed into a quality report.
Per-diem claims with the gates that decide whether a day is payable, and a cap position that never surprises anyone.
Planned visits with a real status machine, and comfort-oriented vital thresholds.
The thirteen-month obligation and the five-percent condition, both tracked from the day they start.
Licence and credential expiry as an operational board, and timesheets built from the notes staff already signed.
The agency's paper trail, its numbers and its configuration, in the same workspace.
An election starts a chain of contiguous benefit periods: two of ninety days, then sixty-day periods without limit. Each period starts the day after the previous one ends, and the bounds are inclusive at both ends — the sort of arithmetic that is easy on paper and unreliable across a hundred patients and a staff rota. The engine computes the bounds of any period from the election date alone, tells you which period a given calendar day falls in, opens the recertification window fifteen days before the period it certifies, and knows that a Face-to-Face encounter is required from the third period onwards.
It is deliberately pure date arithmetic with no database session, so exactly one implementation answers the question wherever it is asked: the certification worklist, the nightly compliance scan, the episode chart and the claim builder all call it. That is the difference between a system where the dates are a fact and a system where each screen has its own opinion. It is covered by its own unit tests, and the same discipline is applied to the episode lifecycle beside it — the Notice-of-Election deadline and the recertification guard are pure functions too.
The compliance worklist is not a list of rules an administrator maintains. It is produced by classifiers — one for the Notice of Election, one for the certification window, one for the IDG cycle, one for the HOPE windows — each of which looks at the facts of one episode and returns either an alert or nothing at all. The severity vocabulary is deliberately small and means something specific: critical is money or a Condition of Participation actively being lost, and a warning is a deadline approaching or an open window that still needs work.
The messages are written for the person who has to act. An unaccepted Notice of Election past its deadline does not say 'overdue' — it names the date from which days are provider-liable and cites the regulation. A benefit period that started without a signed certification says that no day of it is billable until it is signed, and adds the Face-to-Face if that is outstanding too. The same classifiers run nightly as a background job on the platform's leader-elected scheduler, raising the findings as ordinary platform notifications with deduplication and a heartbeat, so a quiet page and a job that never ran are distinguishable.
Every active patient must be reviewed by the interdisciplinary group at least every fifteen days. The product treats that as a computed worklist rather than a recurring calendar entry: the board shows who is due and how close, meetings record attendance and carry a per-patient review row, and finalising a meeting produces minutes that are the evidence a surveyor asks for. The clinical rules that govern the cycle sit in the same pure-function layer as the benefit-period arithmetic.
The plan of care is versioned and monotonic, and the IDG approval is stamped onto the version the group actually approved — so the question 'which plan was in force in March, and who agreed it' has an answer that does not depend on anyone's memory. Visit notes by discipline hang off the same episode: nursing, aide, social work, chaplain and volunteer visits are documented in the chart, signed, and thereafter immutable, with addenda as the only route to a correction.
HOPE replaced the older hospice item set, and the windows are unforgiving: the admission record within five days of admission, then update visits in the day six-to-fifteen and day sixteen-to-thirty windows. The product computes those windows per episode, tracks completion against them, and surfaces the ones that are open or missed on the HOPE board and in the compliance worklist. Batches are built from completed records, carry a manifest, and are marked submitted once they have gone.
The export itself is honest about a real constraint. CMS distributes the authoritative HOPE submission layout through the iQIES onboarding kit, which is account-gated, so the serializer emits a self-describing file stamped with its own format version — enough for an agency to review batch content and pre-validate it today, with the change to the certified wire layout confined to one function once the kit is in hand. The export is gated on the agency's CMS certification number so a batch is never produced without the identifier it must carry.
The billing service owns rules, never amounts. It selects the per-diem category for a day, splits routine home care between its high and low rates at the configured day of care, totals a month, and refuses to build a claim that would price at zero because a rate has not been configured. Every figure — the routine, continuous, respite and general-inpatient rates, the day at which the routine rate steps down, the room-and-board rate and the cap amount — is read from the deployment's own settings, so a rate change is a configuration change.
Two gates sit in front of submission. No monthly claim is built until the Notice of Election has been accepted, and Medicare's sequential-billing rule holds a month until the previous month has been remitted. Room-and-board claims for patients in a nursing facility are produced only where the agency has configured that rate. Beside the claims board, the cap tracker keeps a running position: payments against the allowance the beneficiary count earns, with headroom and utilisation, so the cap is something an administrator watches rather than discovers.
Four outside services matter to a hospice agency: a clearinghouse for the Notice of Election and the monthly institutional claim, a state visit-verification aggregator, a fax provider, and a CAHPS survey vendor. Each is reached through a gateway that reads its credentials only from the deployment's configuration, and each behaves the same way when those credentials are absent: the work is held with a message naming the exact settings to fill in, and the same button resubmits it once the account exists.
That is the platform's standing contract for optional integrations, and it has a practical consequence worth stating plainly — an agency can run the clinical and compliance halves of the product from day one and switch the revenue cycle on when its vendor accounts land, without a second implementation project. Inbound faxes are the exception in the useful direction: the provider posts to the webhook, so intake starts working the moment the vendor account points at it.
The election date starts the benefit-period chain and the five-day notice deadline; the compliance worklist counts it down.
Both physician signatures, and a Face-to-Face encounter from the third period on, before the period opens.
Scheduled visits by discipline, signed notes, vitals against comfort thresholds, HOPE at admission and in its update windows.
Built once the Notice of Election is accepted, held until the previous month is remitted, priced from configured rates; the cap position updates.
A referral arrives from a hospital, facility, physician or family and moves through review to accepted — or is declined, with the decision kept.
Conversion creates the patient and the episode in one transaction; the election date starts the benefit-period chain and the Notice-of-Election clock.
The certification collects both physician signatures, and from the third benefit period a Face-to-Face encounter, before the period is allowed to open.
Visits by discipline are scheduled, delivered and signed; vitals are captured against comfort-oriented thresholds; the plan of care is versioned.
The interdisciplinary group reviews every active patient at least every fifteen days and finalises minutes that stamp the approved plan version.
HOPE records batch for iQIES, QAPI indicators compute from the chart, and monthly per-diem claims build once the Notice of Election has been accepted.
A discharge to death opens a bereavement case with thirteen months of touchpoints already scheduled, and the cap position closes the year without a surprise.
Vocabularies, tiers and matrices drawn from the product documentation — the same terms the software uses.
| Period | Length | Requires |
|---|---|---|
| 1 | 90 days | Certification of terminal illness with the attending physician's and the medical director's signatures |
| 2 | 90 days | Recertification, window opening fifteen days before the period starts |
| 3 | 60 days | Recertification plus a Face-to-Face encounter before the period opens |
| 4 and after | 60 days each, without limit | Recertification plus a Face-to-Face encounter, every period |
Computed from the election date; the same functions answer the worklist, the nightly scan and the claim builder.
| Gate | Effect |
|---|---|
| Notice of Election not accepted | No monthly claim is built for the episode until acceptance is recorded |
| Previous month not remitted | The sequential rule holds this month's claim until the prior month has been paid |
| Certification unsigned at period start | Raised as critical — the days are not billable until the certification is signed |
| A per-diem rate not configured | The claim is refused rather than priced at zero |
| Clearinghouse account not configured | The claim is held with a message naming the settings, and resubmits from the same button |
Enforced in the billing service before anything reaches a gateway. Whether a day is ultimately payable is determined by the agency and its Medicare Administrative Contractor.
| Severity | Means | Example |
|---|---|---|
| Critical | Money or a Condition of Participation is actively being lost | A benefit period that started without a signed certification |
| Critical | A deadline has passed and the consequence has begun | A Notice of Election past its five-day deadline — days until acceptance are provider-liable |
| Warning | A deadline is approaching and there is still time | A recertification window open with the period not yet started |
| Warning | An open window still needs work | A HOPE update visit whose window is open and not yet completed |
A deliberately small vocabulary, so a severity means the same thing on every worklist and in every notification.
| Value | Source |
|---|---|
| Per-diem rates and the routine-care step-down day | The deployment's own configuration, read at runtime |
| Aggregate cap amount | Configuration — the tracker computes the allowance from the beneficiary count |
| QAPI targets | Configuration, per indicator |
| Vital thresholds | Configuration, comfort-oriented rather than acute-care limits |
| Clearinghouse, visit-verification, fax and survey credentials | Configuration only; absent credentials hold the work with a named setting |
Nothing clinical or financial is a constant in the code; the settings page shows which of these are configured for the agency.
Every promise on this page maps to something the software actually enforces.
No. It is a separate application on a separate domain, sharing the platform underneath — authentication, the entity graph, the patient record, documents, notifications and the scheduler. Hospice is episode-based comfort care with its own regulatory spine; the chart, the worklists and the billing are structurally different from ambulatory care, so they are built as their own product rather than as a mode of one.
The compliance worklist raises it before the period starts, as a warning while the recertification window is open. If the period starts unsigned, it becomes critical and the message says plainly that no day of it is billable until the certification is signed — and names the Face-to-Face as well if that is also outstanding. Opening the next benefit period is refused until both physician signatures are recorded.
The five-day deadline is computed from the election date. Before it, the worklist counts down the days remaining. After it, the alert names the date from which days are provider-liable and cites the regulation, and the monthly claim is blocked until acceptance is recorded. Filing itself goes through the clearinghouse gateway once that account is configured.
From the deployment's own configuration. The billing service owns the rules — the routine-care high and low split at a configured day of care, per-diem selection, month totals, the room-and-board rate — and takes every amount as an input. A rate left unconfigured causes the claim to be refused rather than priced at zero, and the settings page shows which rates and vendor keys are in place.
Yes, and it is a deliberate design. Referrals, the census, certifications, IDG, HOPE, compliance, QAPI, scheduling, bereavement, volunteers and staff credentials all run without any vendor account. Claims, visit-verification submissions and outbound faxes are held with a message naming the exact settings to configure, and resubmit from the same button afterwards. Inbound faxes work as soon as the provider points at the webhook.
The windows and completion tracking are live, and batches are built, manifested and marked submitted from the HOPE board. CMS distributes the authoritative submission layout through its account-gated iQIES onboarding kit, so the file the export produces is a self-describing pre-validation format stamped with its own version — enough to review and check batch content now, with the switch to the certified layout confined to one function. The export is gated on the agency's CMS certification number.
Not in place. Signing is one-way, and an edit to a signed note is refused with a message pointing to an addendum. A hospice chart is a legal record before it is a workflow, and the difference between a note that was amended and a note that was replaced is exactly what a surveyor is looking for.
Offline field charting as an installable app for areas with poor coverage, automatic posting of remittances from the clearinghouse feed, the certified iQIES wire layout once the CMS kit is available, a family portal, the CAHPS vendor feed, and per-agency configuration of comfort-medication prescribing on the platform's existing e-prescribing and controlled-substance stack.
We walk through it with your data and your team — not a canned demo.
Program and billing eligibility are determined by each practice and its payers. Results and alerts do not constitute a medical diagnosis. Third-party names are trademarks of their respective owners and do not imply endorsement.
