PointClickCare Integration and SNF Billing: Leader Guide
The background check.
Letting a partner into your residents' records is a trust decision. The vetting is the product.
Before Burst could connect to a single facility through PointClickCare, we had to get into the PointClickCare Marketplace. That took four to six months. They reviewed the company. They tested the automations. They pushed on the security, the data handling, the whole operation. It's the closest thing in business to a federal background check, and it happens before you ever let a partner near a resident's chart.
Here's why that matters to you. The hard part belongs before the connection, not after. When the vetting is real and done up front, the day you turn the connection on is boring. And boring is exactly what you want when the data is PHI.
Two things before we start.
- Before you connect any billing partner, ask what they had to pass to get here. Vetting you can't see is vetting that didn't happen.
- Send this to whoever owns HIPAA and whoever owns billing. A data connection is both of their problem.
What we had to survive to get in.
Getting into the PointClickCare Marketplace is not a signup form.
It's a review of the business behind the software. They look at how you handle data, how your automations behave, how you respond when something breaks, and whether your security holds up under pressure. Partners are expected to meet HIPAA and interoperability standards and to connect only through authorized, governed channels.
For Burst, that was four to six months of scrutiny before we could touch a chart.
Once a partner clears that bar, connecting an individual facility is fast, often a couple of days. That order is the whole point. The slow, brutal part is the vetting. The connection is quick because the trust was earned long before you plugged anything in.
Ask what a partner survived to get in. If the answer is "nothing," that's your answer.
What an "integration" actually is.
"Integration" gets used like a magic word. It just means two systems sharing data. There are three ways to do it, and they are not equally safe.
An API integration is a sanctioned door. The platform decides exactly what gets shared, checks credentials on every request, encrypts the data in transit and at rest, writes every access to a log, and lets you shut it off. A billing partner can be scoped to see resident status and billing-relevant records without opening the entire clinical chart.
Screen scraping is a bot logging in with a human's password and copying screens. It shares credentials, breaks the moment a screen changes, and leaves no clean trail of who saw what. Platforms treat it as a security risk for good reason.
Manual export is staff downloading spreadsheets and emailing them around. Now PHI lives in inboxes and on desktops, with no access control and no log.
An API is a locked door with a guard and a logbook. Scraping climbs through the window.
That's why the connection method belongs in the security conversation, not the security-team footnotes. A password you share is a password you've lost.
What a good connection does for billing.
Most Part B review gaps happen because the documentation never gets read next to the billing data.
A supply shows up on an invoice. The clinical record is what tells you why it was needed, when it was used, and whether the chart supports the quantity and frequency. When those live in one view, a reviewer can spot an incomplete file early and hold a weak claim before it's ever submitted.
That's the honest value of a PointClickCare-connected workflow. Not speed for its own sake. Cleaner traceability from resident status and documentation to the final billing decision, and an audit file that builds itself as the decision happens.
The connection organizes the review. The judgment stays human.
Ask these before you hand over a key.
A connection is a key to your residents' records. Interview anyone who wants one.
| Ask before you connect | Why it matters | A good answer sounds like |
|---|---|---|
| Is access read-only or operational? | It defines how much a partner can touch | "Read-only, scoped to billing-relevant records" |
| How is PHI protected? | PHI needs protection in transit and at rest | "Encrypted end to end, TLS in transit, encrypted at rest" |
| Is a BAA in place? | Any partner handling PHI needs one | "Signed before any data moves" |
| Who can access the data, and at what level? | Least privilege limits exposure | "Named users, least-privilege roles, no shared logins" |
| Are there audit logs? | You need to see who accessed what, when | "Immutable logs, retained per HIPAA" |
| How is access removed if we part ways? | Offboarding is where access quietly lingers | "Revoked same day, confirmed in writing" |
Ask the harder version too. Will the partner exclude claims with missing documentation? Will it give you the reason for every exclusion? Will it show you denial trends and documentation-gap trends every month? A partner that answers those plainly is protecting you.
What a good connection refuses to do.
Access is not permission to bill.
A good connection stays in its lane. It surfaces the record, flags the exception, supports the reviewer, and documents the decision. It leaves the billing judgment to a person and the coverage call to your compliance lead. It never treats a connected record as automatic proof, and it never turns incomplete documentation into support.
"Anyone can promise your data is safe. Ask them what they had to survive to earn a key to it. If the answer is nothing, you already know how they'll treat your residents' records."
A connection that bills on its own is a liability wearing a convenience badge.
A connection is a key to your residents' records. Hand it out like one.
Judge any billing partner by a single standard: does the connection make your billing decisions cleaner and easier to defend? If it only moves data faster, that's convenience, and convenience isn't worth your residents' PHI.
Ask what they survived to get in. Ask what they'll refuse to do once they're inside.
The vetting is the product.
Compliance note
This article is for general educational purposes only. It doesn't replace facility-specific billing, compliance, legal, or payer guidance. SNFs should verify coverage, coding, documentation, HIPAA, and integration decisions against applicable CMS guidance, HIPAA rules, payer policies, and their own compliance program.
References
Related

Written by
Eric Hansen
Founder, Burst Billing
Eric Hansen is the founder of Burst Billing. He has spent over a decade helping skilled nursing facilities recover missed Medicare Part B supply reimbursement through cleaner documentation, tighter vendor workflows, and risk-free billing reviews.
More from Eric →Frequently asked questions
- It's a sanctioned connection that lets a billing partner review the resident's status, clinical notes, orders, and supply documentation next to the billing data, so incomplete files get caught before submission. The value is cleaner traceability from documentation to the billing decision, plus an audit trail that builds as you go. It should support the reviewer and keep the billing judgment human.
- Yes. A sanctioned API uses least-privilege access (a billing partner can be limited to status and billing-relevant records), encrypts data in transit and at rest, logs every access, and can be revoked. Screen scraping relies on shared credentials, breaks when screens change, and leaves no clean audit trail. Manual exports scatter PHI across inboxes and desktops with no access control. The connection method is a security decision.
- Yes. Any partner that handles PHI needs a signed Business Associate Agreement in place before data moves. It's one of the first governance questions to confirm, alongside access level, encryption, user permissions, audit logs, and how access is removed if the relationship ends.
- No. Access is not permission to bill. A good connection surfaces the record, flags exceptions, supports the reviewer, and documents the decision, while a person keeps the billing judgment and the compliance lead keeps the coverage call. A connection that bills on its own, or treats a connected record as automatic proof, adds risk instead of control.
- For Burst, the review took about four to six months. It's a review of the business, the data handling, the automations, and the security, not a quick signup. Once a partner clears that bar, connecting an individual facility is usually fast, often a couple of days, because the hard vetting already happened up front.
- Only what the billing work requires, under least-privilege access: resident status, supply and order information, and the documentation that supports a claim, rather than the entire clinical chart by default. Scoped, read-only access with audit logs limits exposure while still letting the reviewer do the job. Confirm the exact scope before connecting.
- Ask what the partner had to pass to be on the Marketplace, whether access is read-only and least-privilege, how PHI is encrypted in transit and at rest, whether a BAA is in place, who has access at what role, whether audit logs are immutable and retained per HIPAA, and how access is revoked at offboarding. Vetting you can't see is vetting that didn't happen.
See what your facility may be missing
A 30-minute reimbursement assessment will surface eligible Part B supply revenue you're not capturing today. No upfront cost. No commitment.
