Is everything on this page actually built?

Yes. This page is written from the product's own feature inventory, which is written from the code rather than from a roadmap. Nothing here is planned, in beta, or coming soon, and there is no section of this site where those words appear next to a feature. If something is missing, it is in the list of what is deliberately not built rather than hidden.

Which features are on the free plan?

Almost all of them. The free plan is capped at 1 provider and 3 users, keeps 12 months of history, and delivers in-app and by email. The paid plan raises those and adds push delivery, the analytics screens, and the activity log. The deadline engine, exclusion screening, the document vault, payer enrollments and reporting are on both, because the free tier exists so you can watch real alerts fire on a real provider before paying.

Can I try the features that matter before paying?

That is what the free tier is for, and it is why it has no time limit. Put one real provider in with a real date on a real credential and watch what happens as that date approaches. One provider will not hold your book, but it will tell you whether the alerting does what this page says it does.

How is this different from a license expiration tracker?

A generic tracker watches dates. It cannot see a payer enrollment, which is roughly 25 separate approvals per provider on their own multi-year cycles, and it has no concept of a client practice, so it cannot roll up across the book a billing firm actually manages. Those two things are most of the job and most of this page.

Does RosterSafe submit applications or contact payers for me?

No. RosterSafe is software, not a credentialing service. It tracks the work, tells you what is due, and gives you the evidence to show a client. It does not fill in payer portals, make calls, or take responsibility for your deadlines. If you want the task done for you rather than tracked, an outsourced credentialing service is the right purchase and I would rather say so now.

Everything RosterSafe does

The complete list, with the specifics rather than the adjectives. If you want the story in order instead, read how it works. Everything below is shipped and running today.

Inventory last checked against the code 8 August 2026

The deadline engine

Everything else on this page is somewhere to put the data this watches. The rules are configurable, they are enforced on the server, and they are the reason the product exists.

Eight credential types: State license, DEA registration, CAQH attestation, malpractice cover, board certification, CPR, CME, and a custom type for whatever your firm tracks that the list does not name. Every one carries an expiry date.
Status is derived, never typed: Active, expiring, and lapsed are calculated by the engine from the date. Nobody can mark a credential green by hand, which is the exact failure mode of the spreadsheet this replaces.
Alert windows you set: Default 90, 60, 30 and 7 days before expiry. Between one and ten windows, each from 1 to 365 days, strictly descending. Each window fires once per expiry date, so entering the 60-day window does not re-send the 90-day warning, and reconfiguring your windows never re-fires ones that already went.
The final window repeats daily: Inside the smallest window the item re-alerts every day, deduplicated per calendar day. Acknowledging silences that daily repeat without silencing the next window down.
A lapse cannot be silenced: A lapsed credential alerts every day until it is resolved, and overrides both snooze and acknowledgment. There is no sequence of clicks that makes a lapsed credential go quiet, deliberately: that moment is the one this product exists to prevent.
Escalation to the owner: An alert nobody acknowledges escalates to the firm owner after a number of days you choose, from 1 to 60, once per expiry date rather than once per day.
Renewal resets the cycle: Moving an expiry date into the future clears all the bookkeeping and fires a completion event, so a renewed credential starts its next cycle clean instead of carrying the last one forward.
Counted on your calendar, not UTC: Days-until is counted on the time zone your firm sets, from Eastern through to Hawaii, Puerto Rico and Guam. Open the work queue at 8pm and a credential expiring tomorrow still reads as expiring tomorrow. Alerts, digests and the daily export limit all follow the same clock, so a coordinator in Los Angeles gets their morning sweep at their morning.

The book

Your roster, across every client practice

Client practices are a core object rather than a tag or a column. Every provider, credential, document and enrollment belongs to one, and the rollup across all of them is the default view.

Client practices: Each carries a name, organizational NPI and tax id. Every provider belongs to at least one, and a provider can sit in several when a physician works across two of your clients.
Provider records: Name and credential suffix, NPI, SSN, date of birth, email, phone, taxonomy, specialty, active or inactive status, and practice memberships.
Sorted by deadline, not alphabetically: The roster opens ordered by what expires first. An alphabetical list scatters the providers closest to lapsing across every page, so the ones you opened the page to find are rarely on it.
CSV import with column mapping: Up to 500 rows per file, mapped to RosterSafe fields on the way in. Valid rows insert and invalid rows come back with the reason, so one bad date does not reject the file. Re-importing a corrected list adds practice affiliations rather than creating duplicate providers.
NPPES lookup and bulk enrichment: Look a provider up by NPI against the free official CMS registry, one at a time or across a whole imported roster in batches. Enrichment only writes to empty fields, so registry data never overwrites something you typed.
Duplicate detection with merge: Creating a provider who looks like one you already have returns the suspected duplicate rather than silently making a second record, and offers to merge them.
Move, merge, kickoff, and file export: Transfer a provider between client practices, merge two records into one, generate the enrollment set for a new provider in one action, or export a single provider's entire document vault as a zip.
Roster board and Today: The roster board is one row per active provider, banded by its worst credential. Today is the work queue, scoped to your own book: a coordinator assigned to three practices sees those, and an owner with no assignments sees the firm.
Lapse history: Every lapse the engine has ever recorded, kept as its own record rather than inferred later. It is what the value-recap report is computed from.

The invisible half

Payer enrollment tracking

The part a generic license tracker cannot see at all, and most of what a credentialing coordinator actually does. One row per provider, per payer, per client practice.

Five statuses on a fixed graph: Not enrolled, in progress, approved, expiring, and termed. Moves that do not make sense are refused by the server rather than merely hidden in the interface, so the pipeline cannot be talked into a state it should not be in.
Terming is reversible: A payer can be termed from any state and picked back up later, because dropping and re-adding a plan is a normal thing for a practice to do.
Application tracker and follow-up log: A dated record of the chase: what was submitted, when, and every follow-up since. This is the evidence you need when a client asks why an enrollment has taken four months.
Effective date, tracked separately: The billable-from date is its own field, because it is the number a client actually asks about and it is rarely the same day the approval landed.
Automatic chase reminders: A daily job flags payers that have gone quiet past an interval you set, from 1 to 90 days, so a stalled application surfaces instead of ageing quietly in a folder.
A payer library, plus your own: A shared library of payers to enroll against, and firm-private payers for the regional plans your clients use that nobody else has heard of.

Evidence

The document vault

Where the license copies and certificates live, with the expiry dates read off them rather than typed in beside them.

Six document types: License, DEA certificate, malpractice certificate, board certificate, CME certificate, and other. Downloads go through signed links rather than public URLs.
Expiry read off the upload: An upload arrives with a proposed expiry date extracted from the file. It stays a proposal until a person confirms it, and only then does it feed the deadline engine. A machine-read date that silently became an alert would be the wrong kind of automatic.
Version history that keeps the old one: Uploading a replacement chains it to the document it replaces and moves the current marker. Superseded versions stay readable, so last year's certificate is still there when an auditor asks about last year.
Missing-document checklist: Per provider, the four required types (license, DEA certificate, malpractice certificate, board certificate) minus whatever the vault already holds a current document for. What is missing, rather than what is present.
Upload links for providers: Ask a provider for one specific document through a single-use link that expires after a set number of days. They upload it without an account, a login, or a call to your office.

False Claims Act exposure

Exclusion screening

Billing a federal claim for an excluded provider is the kind of mistake that ends firms. Your roster is screened on a schedule rather than when somebody remembers.

Three sources: The OIG List of Excluded Individuals and Entities, SAM.gov, and state Medicaid exclusion lists, which an owner loads as a per-state CSV. All official, all free, and none of them something you should be checking by hand at 40 providers.
Screened daily, alerts on new hits only: The whole roster is re-screened every day, and only genuinely new hits raise an alert. A hit you have already looked at and dispositioned does not page anybody again.
Conservative matching, resolved by a human: Matching errs toward showing you too much rather than too little, and an open hit stays visible until a person confirms or dismisses it with a note. A name-match false positive is an annoyance; a miss is a federal problem.

The client conversation

Reporting, exports, and analytics

What you send to a client, what you keep for an audit, and what tells you whether the last quarter went well.

Three report kinds: Client health for the conversation where a client asks how their roster is doing, compliance readiness for an audit, and a value recap computed from your own lapse history for the conversation where a client asks what they are paying you for.
Branded PDF output: Reports render to CSV or to PDF carrying your firm's logo, colour and footer, because a report you forward to a client is your firm's document, not mine.
Exports on six surfaces: Providers, credentials, enrollments, documents, screenings and lapses, as CSV or PDF. An export respects the filters already applied to the surface it came from, so what you see is what you send.
Saved views and saved dashboards: A saved view is a surface plus its filters, kept so the query you rebuild every Monday is built once. Dashboards assemble from eight widgets: roster health, at risk, exposure, expiring soon, enrollment pipeline, payer performance, productivity, and lapse trend.
Scheduled reports: Weekly or monthly, rendered and emailed without anyone remembering to run them. The schedule advances before the render is attempted, so a report that fails to build does not re-fire forever.
Analytics on your own history: Roster health over time, payer approval performance drawn from your firm's own enrollment record, and coordinator productivity. Turnaround is reported as a median rather than a mean, so one stalled enrollment does not wreck the number you quote a client.
Never benchmarked against other firms: Every number is derived from your own data. RosterSafe does not compare your firm to anyone else's, and your data is not aggregated into a figure sold back to the market. That is a scope decision, not a missing feature.
A dashboard that admits what it does not know: Book-wide totals, an at-risk count, a per-practice leaderboard worst-first, and a revenue-at-risk-per-day estimate. If you have not set a per-provider rate, the exposure tile says the rate is not set and points at settings, rather than showing a confident $0 next to four lapsed providers.

Delivery

Alerts, and proof they arrived

An alerting product that goes quiet without telling you is worse than no alerting product, because you have stopped checking manually. So delivery is observable.

Ten event types: Credential expiring, credential lapsed, enrollment status change, enrollment chase, exclusion hit, document expiring, completion, digest, task assigned, and system.
Three channels, per person, per type: In-app, email, and push. Every user holds their own matrix of which event types reach them on which channels, so the owner can take escalations by email while a coordinator takes everything in-app.
A per-channel delivery record: Every send is recorded per channel, with its status and the reason when it fails, attached to the notification it belongs to. Whether a given alert actually went out is answerable rather than assumed.
Real-time in the app: Screens update over a live connection as the engine works, so a sweep that changes twenty statuses does not leave an open dashboard quietly stale.
At-risk digests: A per-client summary of what is coming, weekly on Monday morning or monthly on the 1st, or off. Set once for the firm.

The multi-client shape

What your clients see

The wedge is that you serve many practices at once. These are the surfaces that let you show a client their roster without showing them anybody else's.

Read-only client logins: A client user is pinned to exactly one client practice and can read, never write. The pin is derived from their role on the server and enforced by the database, so a client editing the practice id in a URL still sees only their own roster.
A shareable status page: A PII-free health summary for one practice, behind a signed link you mint that expires after 30 days. Whoever holds it can read that one practice's health and cannot act on anything. For the client who wants reassurance without wanting an account.
Per-client health reports: A client can pull their own practice's health report and nobody else's. Value recap and compliance readiness stay staff-only.
Filter down, or roll up: Every surface works across the whole book or narrowed to one practice, and the rollup is the default rather than the special case.

Access and accountability

Team, security, and the audit trail

What is actually in place. The security page states this in full, including what is not in place, and it is worth reading before you commit a roster to anyone.

Three roles: Owner sees and does everything including staff, billing and firm settings. Credentialer does the work but not the admin. Read-only client sees one practice and writes nothing.
Assignments and workload: Assign a coordinator to specific providers or whole practices. Assignments scope their Today queue and feed a workload view, so you can see who is carrying what before you hand out the next client.
Two-factor and connected accounts: App-based 2FA, Google sign-in, and email sign-in, linked and unlinked from settings. You cannot unlink your last sign-in method and lock yourself out.
Sessions you can see and end: Every active session listed, revocable individually, plus a force-logout that ends them all. Revoking takes effect on the other browser's next request, not whenever its token happens to expire.
IP allowlist: Owners can restrict access to specific IPv4 or IPv6 addresses, or IPv4 ranges, up to 50 entries. An empty list means unrestricted, deliberately, so clearing it can never lock a firm out of its own account.
Encrypted SSN and DEA numbers: Both are encrypted with AES-256-GCM at the application layer, excluded from lists, exports and logs, and readable only through a deliberate reveal that writes an audit event naming who looked.
A full activity trail: Every change, every export, and every reveal of a sensitive field, with who and when. Exports and report pulls are audited too, because those are the moments data leaves the system.
Tenant isolation in the database: Firm separation is enforced by Postgres row-level security rather than by application code remembering to filter. A query naming no firm returns nothing at all. Read the security page for how that is built.

The edges

What is deliberately not built

A features page that lists only what a product has is the one page on a site you cannot check. These are decisions rather than gaps, so each one comes with the reason, and the about page makes the same argument at length.

Clinical privileging, OPPE and FPPE, committee voting: These belong to the hospital buyer I am not serving.
A credentialing service: I do not submit applications or chase payers for you. That is a different business with different liabilities, and several competitors already do it well.
NPDB continuous query: Enterprise scope.
HRIS and payroll sync: You are tracking other firms' rosters, not employing the clinicians.
Payer-side network adequacy reporting: That is a product for health plans.

And what is simply missing

Different thing, kept separate on purpose. These are not positions, they are capabilities competitors have and RosterSafe does not.

Automated primary source verification
A CAQH integration that populates provider profiles for you
A public API
SOC 2 certification, a BAA, or an external penetration test

If one of those decides it for you, the comparison pages name which product has it, and the security page leads with the certifications RosterSafe does not hold rather than burying them.

Questions about what is built

Is everything on this page actually built?: Yes. This page is written from the product's own feature inventory, which is written from the code rather than from a roadmap. Nothing here is planned, in beta, or coming soon, and there is no section of this site where those words appear next to a feature. If something is missing, it is in the list of what is deliberately not built rather than hidden.
Which features are on the free plan?: Almost all of them. The free plan is capped at 1 provider and 3 users, keeps 12 months of history, and delivers in-app and by email. The paid plan raises those and adds push delivery, the analytics screens, and the activity log. The deadline engine, exclusion screening, the document vault, payer enrollments and reporting are on both, because the free tier exists so you can watch real alerts fire on a real provider before paying.
Can I try the features that matter before paying?: That is what the free tier is for, and it is why it has no time limit. Put one real provider in with a real date on a real credential and watch what happens as that date approaches. One provider will not hold your book, but it will tell you whether the alerting does what this page says it does.
How is this different from a license expiration tracker?: A generic tracker watches dates. It cannot see a payer enrollment, which is roughly 25 separate approvals per provider on their own multi-year cycles, and it has no concept of a client practice, so it cannot roll up across the book a billing firm actually manages. Those two things are most of the job and most of this page.
Does RosterSafe submit applications or contact payers for me?: No. RosterSafe is software, not a credentialing service. It tracks the work, tells you what is due, and gives you the evidence to show a client. It does not fill in payer portals, make calls, or take responsibility for your deadlines. If you want the task done for you rather than tracked, an outsourced credentialing service is the right purchase and I would rather say so now.

Judge it on one real provider

Free forever on 1 provider, no card and no trial clock. Paid is $25 per active provider per month with a $100 monthly floor, published on the pricing page like everything else here.

Get Started Free