Skilled Nursing Data Platform: Joining PointClickCare, Sage Intacct and Smartlinx

Updated October 2026

A data platform for a multi-facility skilled nursing operator joins the EHR, the general ledger and the workforce system on one shared grain: one building on one day. With PointClickCare, Sage Intacct and Smartlinx, that join gives leaders census and resident movement, budget against actual, and staffing in one place. Our view is that a permitted route out of each vendor decides your timeline, so settle that before the data model, hard as the definitions are.

This is a planning guide with vendor routes checked on each vendor's own site. It describes a design, and it is not a record of a delivered project. For the engineering scope, see our healthcare data engineering services and PointClickCare integration page.

Nirmitee is a healthcare software engineering firm that builds data platforms for health systems and health tech companies. If you are planning this work, you can start with our fixed-price Healthcare Data Platform Assessment.

What questions should a skilled nursing data platform answer?

A skilled nursing data platform should answer three weekly questions by building: who is here and who is moving, are we on budget for this census, and are we staffed for it. Each question sits in a different system today, so someone rebuilds the answer by hand in a spreadsheet.

The general pattern is in our guide to healthcare data integration.

How do you get data out of PointClickCare, Sage Intacct and Smartlinx?

Each of the three systems has a different route, and only Sage Intacct publishes full technical documentation for what this project needs. Confirm each route in writing before you commit to dates. The table below shows what we could verify on vendor sites, and what we could not.

PointClickCare

PointClickCare offers two developer programs, and the one with a published price does not cover census. The USCDI Connector gives read access to standard FHIR R4 data. PointClickCare's FHIR site lists a flat $65 per app, per facility, per month for customers on its current pricing model, subject to annual revision. Customers enable each app by facility, with a stated minimum of two weeks. Its comparison puts proprietary APIs and webhooks with the Marketplace partner program, whose API documentation sits behind a partner login and whose fees are not published. See our PointClickCare API guide for the detail and sources.

Check the location clause early. The USCDI Connector agreement says the app must not be accessed or supported from outside Canada or the United States. That affects where you host and who can log in to production, and it applies to any vendor you hire, including an offshore team. Ask your counsel how it applies to your own setup and to any other route you choose.

A third route suits this project better if it is still offered. PointClickCare's Data Relay solution sheet describes a regular extract for providers to load into their own reporting systems and combine with other data, delivered hourly as data views. Listed sets include facility, bed, room and unit, patient, payer, census, and stay. The sheet is old, with a June 2015 footer, and we found no current product page. Ask your account team whether it, or a successor, is available under your contract. PointClickCare also sells its own analytics products, such as Advanced Insights, which may answer some census questions with no platform at all. Check that first.

Sage Intacct

Sage Intacct has the clearest route of the three, through its XML Web Services API. You need a Web Services developer license with a sender ID, obtained through your account manager. A company administrator then enables the Web Services subscription, authorizes the sender ID and creates a Web Services user. Sage's budgets API carries location and department on budget details, and its account balances API can filter by location and department. Check with Sage whether a newer REST API suits you better, since third-party sources describe one and the page above covers XML. Users on Sage's developer forum report that pulling budget detail can be slow, so test it early with your real volume.

Smartlinx

Smartlinx covers the staffing data, and we found no public developer documentation for getting it out. Its site describes scheduling, time and attendance and payroll for skilled nursing, and a PBJ tool that formats staffing data into a CMS XML file. Ask Smartlinx in writing whether an API or a scheduled export exists, which fields it holds, and whether contract and agency hours are included. If there is no feed, a scheduled report is the fallback, and it should be treated as fragile until proven otherwise.

What should the data model for multi-facility SNF reporting look like?

The model should use one facility-day as its shared grain, with a crosswalk that gives every building one ID across all three systems. Daily facts can roll up to monthly finance periods. Monthly finance data cannot be broken down to explain a daily staffing decision, so start at the day.

Four definitions need a decision from your people before anyone writes a query:

• Census day. At what time do you count? How do you treat a resident who is out on a hospital bed hold or therapeutic leave? The answer changes both occupancy and hours per resident day.
• Occupancy. Licensed beds or beds in service? Buildings often use both, and the two give different pictures.
• Labor categories. Map each Smartlinx job code to a role, using CMS's Payroll Based Journal categories as the anchor. Decide how agency and paid-not-worked hours count, since PBJ applies its own rules on which paid hours count and your internal labor view may differ.
• Budget basis. Compare actual cost to a budget adjusted for actual census, as well as the fixed budget. A building over budget with a higher census may be doing well. Finance should own the flex rules.

How do you reconcile census, budget and staffing?

Reconcile each view back to the system its owner already trusts, every day, with a roll-forward check on census. Opening census plus arrivals minus departures must equal closing census. A business office does this by hand, and the same rule works for every building automatically.

The query below shows the check and the hours measure. We ran it on a small synthetic data set: a building whose movements add up returned PASS and 3.5 hours per resident day, and a building with a missing discharge returned HOLD. Hours per resident day here uses closing census for simplicity, so match it to your own definition.

-- Daily roll-forward by facility, then hours per resident day. Names are illustrative.
WITH movement AS (
  SELECT facility_id, census_date,
         SUM(CASE WHEN event_type IN ('admit','return') THEN 1 ELSE 0 END) AS arrivals,
         SUM(CASE WHEN event_type IN ('discharge','leave') THEN 1 ELSE 0 END) AS departures
  FROM resident_movement
  GROUP BY facility_id, census_date
)
SELECT c.facility_id, c.census_date, c.opening_census,
       COALESCE(m.arrivals, 0) AS arrivals, COALESCE(m.departures, 0) AS departures,
       c.closing_census,
       CASE WHEN c.opening_census + COALESCE(m.arrivals, 0) - COALESCE(m.departures, 0)
                 = c.closing_census THEN 'PASS' ELSE 'HOLD' END AS roll_forward,
       ROUND(1.0 * h.nursing_hours / NULLIF(c.closing_census, 0), 2) AS hours_per_resident_day
FROM daily_census c
LEFT JOIN movement m ON m.facility_id = c.facility_id AND m.census_date = c.census_date
LEFT JOIN daily_hours h ON h.facility_id = c.facility_id AND h.census_date = c.census_date;

CMS's public data gives you an outside check. Facilities must submit PBJ staffing data by the 45th day after each fiscal quarter ends, and CMS publishes staffing files that include a daily MDS-derived census. Those will lag your internal view and use CMS's own rules, so compare trends and investigate large gaps, and do not expect a perfect tie. CMS announced that PBJ would move into iQIES in August 2026, so confirm your submission path too.

What is a realistic first 90 days?

A realistic first 90 days ends with three reconciled views for a small pilot group of buildings and a leadership meeting that uses them each week. Rolling out to every building, forecasting and predictive models should wait. Those depend on a census number people already trust.

Those dates assume access, usable source data and agreed definitions. The biggest risk to them is PointClickCare access, since facility enablement alone has a two-week minimum, and a partner review can run longer. Start the access request on day one, and run the other two views while you wait. If access has not cleared by day 45, ship budget and staffing using a scheduled census report as a bridge, and label that view clearly.

The test at day 90 is simple. Can your regional leaders stop rebuilding the spreadsheet for those buildings, and do they accept the numbers? We make no promise of an occupancy or margin gain from this phase, because the platform only creates the conditions for better decisions. Measure any gain later, against your own baseline.

Who should own skilled nursing data?

Operations should own census definitions, finance should own budget mapping and HR should own labor roles, with one executive sponsor who can settle disagreements. Without that sponsor, the platform will show two versions of occupancy and a meeting about whose is right.

The wider patterns come from our guides on warehouse, lake and lakehouse choices and data quality at scale. A smaller operator can start with a warehouse and a BI tool. The stack matters far less here than vendor access and definitions.

How to decide who should build a skilled nursing data platform

Hire the team that can show you its controls before it shows you its tools. The six questions below are the ones we would ask in your seat. The answers describe what we would put in your plan, so hold us to them in writing.

Risks and how we control them

Governance and PHI handling

Budget and staffing views need no resident-level detail, so we keep PHI out of them. Only the census and movement layer holds resident data, under its own access rule. We sign BAAs. Your compliance lead decides who sees resident-level movement. Discovery and test design start with synthetic or de-identified examples. Access to production data comes later, in approved environments, under a signed BAA. Nirmitee is ISO 27001:2022 certified, which covers how we run our security management. It does not make your platform compliant, so your privacy and security leads still review the design.

Who owns the code and the data

Once paid, you own the custom code we write for you and all of your data. We keep our reusable tools and open-source parts. Our design keeps your data in accounts your organization controls. The custom work includes the data contracts and mappings, the pipeline and quality tests, the replay and recovery procedures, and the freshness monitoring.

What the team looks like

Expect a data architect, a data engineer, an analytics engineer, and QA, sized once the routes are known. Staffing has to fit each vendor's access terms, so we settle who can touch which environment with you before work starts. Your side supplies a sponsor, a finance owner, an operations owner and an HR owner. Your side supplies a business owner for each published number, a source system owner for each feed, and a privacy or compliance reviewer. A project without those three people on your side will stall, whoever you hire.

What you receive

A build engagement should leave you with running pipelines in your environment, documented grain and definitions, reconciliation reports you can rerun, a runbook, and a handover walkthrough with the people who will operate the platform. Write these into the acceptance criteria.

How to judge a vendor

• Ask them to show the vendor's terms for the route they propose, and how they would comply. A confident answer without the document should worry you.
• Ask whether they have worked with each of these three systems, and ask for evidence. Sandbox access and live operator data are different things.
• Ask how they would define census day, and listen for questions about bed holds and leave.
• Ask what you would still have if the vendor left at day 90.
• Be wary of any promise of a specific occupancy or margin gain before they have seen your data.

Healthcare Data Platform Assessment: $3,500, fixed

The Healthcare Data Platform Assessment costs a fixed $3,500, takes 2 to 3 weeks and is credited against the build. It gives you a build plan you can take to any vendor, including us. It suits an operator whose leaders rebuild census, budget and staffing numbers by hand. The first thing it settles is which vendor routes your contracts permit.

• Source inventory: every source, its owner, access route, refresh behavior and known gaps.
• Target architecture: layers, platform recommendation and the tradeoffs behind it.
• Data model outline: core entities, grain and the definitions that need an owner.
• Risk list: technical, vendor, privacy and operating risks, ranked.
• Costed build plan: phases, acceptance checks and an engineering estimate.

Not included: building pipelines, production PHI access, vendor license or API fees, vendor approvals, legal review and ongoing support. Ask for a Healthcare Data Platform Assessment and bring one decision the data must support.