EHR · CRM · payroll · general ledger
Connecting EHR, CRM, payroll and general-ledger data
Connecting four systems is the easy half. The hard half is deciding which system is authoritative for each fact before you publish a single number. Assign authority per attribute, not per system: the clinical record governs resident identity and assessed level of care, the CRM governs the pipeline up to move-in, payroll and time govern worked and paid hours, and the general ledger governs recognized revenue and posted cost. Physical occupancy of a unit — not an expected move-in date and not a billed day — governs census. Where two systems disagree, the operating record keeps both values with their lineage and reports the exception instead of overwriting one with the other. When systems disagree, the operator governs.
- Unit of governance
- The attribute, not the system
- Default posture
- Read-only ingest with lineage attached at source
- Conflict handling
- Both values retained; exception reported; no silent overwrite
- Reconciliation targets
- Census, acuity, worked hours, agency hours, revenue, cost
Evidence posture. Connector coverage below is stated at its Product Record state — the third-party source-system connector framework is BUILT as a framework and exercised against vendor-documented interfaces and synthetic fixtures. No third-party integration runs in an operator production environment. Read every connector row as scope, not as a deployment. Last reviewed August 30, 2026.
Reconciliation
What happens when two systems disagree
Each rule below is written before the disagreement occurs. That is the difference between reconciliation and improvisation.
- CRM shows a move-in the clinical record has no admission for
- Occupancy is not recognized. The record holds an open exception naming both sources, and the census figure does not silently include the unit.
- Billed level of care exceeds the assessed level of care
- The assessment governs. The variance is surfaced with resident, period and both source values for operator review, and it is not reconciled by adjusting the assessment.
- Posted labor cost does not match payroll worked hours for the period
- Both are retained. The ledger governs cost and payroll governs hours; the difference is reported as a period reconciliation item with its accrual boundary stated.
- Agency invoice hours exceed scheduled agency hours
- Invoice governs cost. The unmatched hours are flagged for review against the schedule rather than accepted as coverage that was demonstrably delivered.
- Two systems disagree and no rule has been declared
- The value is not published. When systems disagree, the operator governs — the record holds the disagreement openly until an authority rule is declared, rather than picking a winner by ingest order.
Architecture
How the four feeds are arranged
Layer 1 — Source systems (unchanged)
Layer 2 — Immutable landing and lineage
Raw payloads retained as received, each field tagged with source system, source identifier, interface and extraction timestamp.
Layer 3 — Canonical entities
Layer 4 — operator-controlled operating record
Accepted value, rejected value, basis of acceptance and restatement history. When systems disagree, the operator governs.
Layer 5 — Consumers
Board and lender reporting, operating reviews, BI tools, and AI workflows that read the governed record rather than the raw sources. Govern the truth before you automate the decision.
Source to operator-controlled operating record
Source field to operator-controlled operating record
| Canonical entity | Typical source fields | Authority rule | Reconciliation test |
|---|---|---|---|
| Resident | EHR resident master, CRM prospect record, billing account, unit roster | Clinical system of record for clinical identity; operator-declared identity key for the governed record | Deterministic match on name, date of birth and admission date; unmatched records surface as an exception, never a silent merge |
| Care Plan | EHR assessments, service plans, MAR, acuity scoring | One authoritative MAR. The clinical system of record governs clinical content | Acuity level and service minutes reconciled to the billed level of care; variance is reported, not resolved by preference |
| Ledger | General ledger, AR sub-ledger, billing system, payroll register, agency invoices | General ledger is authoritative for posted amounts; source systems are authoritative for pre-posting activity | Period totals tie to the GL within a written tolerance before any derived metric is published |
| Shift | Scheduling system, time and attendance, payroll worked hours, agency invoice detail | Payroll worked hours are authoritative for hours paid; the schedule is authoritative for intent | Scheduled, worked and paid hours reconciled to the same period; agency hours cause-coded |
| Property/Unit | Property management system unit table, occupancy roster, CRM move-in pipeline | Property management system is authoritative for the unit inventory | Physical, licensed and available unit counts held as distinct fields so census is never computed from an ambiguous denominator |
| Entity | Chart of accounts, legal entity register, ownership and management agreements | Operator-declared entity structure | Every property maps to exactly one operating entity per effective date, with history retained |
Coverage
Named connector coverage
Coverage describes interface scope. See the integration ecosystem for the full inventory.
Connector scope state: FRAMEWORK
| Source system | Category | Interface class | Feeds |
|---|---|---|---|
| PointClickCare® | EHR / clinical | Vendor API, HL7 v2, FHIR R4 resources | Resident, Care Plan |
| MatrixCare® | EHR / clinical | Vendor API, HL7 v2, flat-file extract | Resident, Care Plan |
| Med e-care | EHR / clinical | Vendor API, flat-file extract | Resident, Care Plan |
| Yardi® Voyager | Property / billing | Vendor API, scheduled extract | Property/Unit, Ledger |
| RealPage® | Property / billing | Vendor API, scheduled extract | Property/Unit, Ledger |
| Sage Intacct® | Accounting / GL | Vendor API, dimension-aware GL read | Ledger, Entity |
| Microsoft® Dynamics 365 | ERP / GL | Vendor API, OData | Ledger, Entity |
| Sherpa CRM | CRM / sales | Vendor API | Resident (prospect), Property/Unit |
| Enquire Solutions | CRM / sales | Vendor API | Resident (prospect), Property/Unit |
| WelcomeHome Software | CRM / sales | Vendor API | Resident (prospect), Property/Unit |
| Power BI® | Analytics / BI | Outbound governed dataset | Reads the record; writes nothing |
| Tableau® | Analytics / BI | Outbound governed dataset | Reads the record; writes nothing |
| DocuSign®, Adobe Sign | Documents / e-signature | Vendor API, event webhook | Resident, Entity |
| Payroll and time systems | Workforce | Scheduled export, SFTP, vendor API where published | Shift, Ledger |
Implementation
Phased implementation
1.Phase 1 — Definitions
Goal. Settle what each number means before anything is connected.
- Write one definition per contested metric: occupancy, census, level of care, worked hours, agency hours, NOI.
- Name an accountable owner for each definition.
- Record which system the operator expects to be authoritative for each field.
- Capture the questions the board asks and the report each answer currently comes from.
Exit test. A written definition set with named owners, signed off by the operator — not by the vendor.
2.Phase 2 — Read-only connection
Goal. Read the source systems without touching them.
- Stand up read-only credentials or scoped extracts per source system.
- Map each source field to a canonical entity and attribute.
- Land raw source payloads immutably, with lineage metadata attached at ingest.
- Leave every source system as the operator’s own system of record for now.
Exit test. Source data lands with full lineage and no write path back into any source system.
3.Phase 3 — Reconciliation
Goal. Make disagreement visible instead of averaging it away.
- Reconcile period totals to the general ledger and to payroll worked hours within a written tolerance.
- Reconcile occupancy against the unit inventory and the billed roster.
- Route every unmatched or out-of-tolerance item to a named owner as an exception.
- Freeze a dated baseline before any derived metric is published.
Exit test. A reconciliation report the operator would hand to an auditor, with open exceptions listed rather than suppressed.
4.Phase 4 — Authority
Goal. Declare who governs each field when systems disagree.
- Set the authority rule per canonical attribute.
- Record the accepted value, the rejected value and the basis of acceptance.
- Publish the governed views the board and lenders read.
- Retain restatement history so a corrected number never silently replaces the number a decision was made on.
Exit test. One Operator-Controlled Operating Record the operator controls, with conflicts resolved by rule and by name.
5.Phase 5 — Coexistence or replacement, by choice
Goal. Decide the future of each source system on the operator’s timetable.
- Keep the incumbent system and continue reading one direction only, or
- Adopt the SeniorCRE clinical record — its own EHR and eMAR — as the clinical system of record,
- Maintain exactly one authoritative MAR at all times during any transition.
- Re-run reconciliation across the change so history stays comparable.
Exit test. A documented decision per system. Govern first; replace only by choice.
Lineage
Lineage across the authority chain
DATA
Where did this value come from?
Every field carries its source system, source identifier, extraction timestamp and interface used. A value with no traceable origin is not admitted to the record.
TRUTH
Which value does the operator accept?
When two systems disagree, both values are retained, the conflict is raised, and the governed record shows the accepted value plus the rule or the named person that accepted it.
DECISION
What was decided on this number?
Decisions reference the record version they were made against, so a later restatement does not quietly rewrite the basis of a past decision.
EXECUTION
What happened next, and who confirmed it?
Actions taken from the record are logged with the confirming human. Nothing writes back into a source system without an explicit, scoped, operator-authorised write.
The chain itself is set out in the Operator Authority Chain and the object it produces in the operating record.
Frequently asked questions
How do I connect EHR, CRM, payroll and accounting data in senior housing & care?
Connect each system read-only through its published interface, define the canonical attributes in the operator’s own words, then declare which single system is authoritative for each attribute. The clinical record governs identity and assessed acuity, the CRM governs the pipeline up to move-in, payroll and time govern hours, and the general ledger governs recognized revenue and posted cost. Reconcile a closed historical period before publishing any attribute.
Which system should be the system of record?
No single system should be. Authority belongs to the attribute, not the platform: each canonical attribute names one authoritative source, and the operating record governs the reconciliation between them. That is why access is not authority — a warehouse that holds all four feeds still has not decided which value the business accepts as true.
What happens when payroll and the general ledger disagree on labor cost?
Both values are retained with their lineage. The ledger governs posted cost and payroll governs worked hours; the difference — usually an accrual boundary or a period-cutoff effect — is reported as a reconciliation item with the accrual boundary stated, rather than resolved by adjusting one source to match the other.
Do I have to replace my clinical system to do this?
No. The default configuration reads the incumbent clinical system one direction only and changes no clinical workflow, with exactly one authoritative medication administration record at all times. SeniorCRE has built clinical record surfaces; medication administration and eMAR remain roadmap — not built. Any future clinical system-of-record function must clear its own Production-Entry Gates and receive operator acceptance.
How is data lineage recorded across four systems?
Every field carries its source system, source identifier, extraction timestamp and the interface it arrived through, and every derived figure carries the definition version used to compute it. A board number can be traced back through each transformation to the source row in the originating system.
Is this integration running in production today?
No. The third-party source-system connector framework is stated at its Product Record maturity state and has been exercised against vendor-documented interfaces and synthetic fixtures. No third-party integration runs in an operator production environment, and connector coverage should be read as scope rather than as a deployment.
Evidence behind the evaluation
These pages carry the governance and clinical evidence a shortlist cannot: source authority rules, escalation controls, data limits, and survey-ready evidence.
- senior housing & care data governance for multi-state portfolios
How differing state definitions and survey regimes are governed in one record.
- human review and escalation controls for clinical AI
Mandatory human review, escalation paths, and what the system may never do.
- clinical AI data sources and limitations
What the signals are computed from, and where the evidence stops.
- how to evaluate senior housing & care software for 10+ locations
Six-criteria, vendor-neutral evaluation frame for multi-state portfolios.
Continue in this cluster
Data integration for senior housing & care
The pillar: canonical entities, connector coverage, lineage and the phased sequence every page here shares.
Combining PointClickCare® with accounting and payroll data
How clinical census and acuity from an EHR reconcile against the general ledger and worked payroll hours in one governed record.
Integration with your EHR retained — replacement optional
Read-one-direction coexistence: govern the operating record above the systems you already run, and replace only by choice.
Acquisition-day integration
What has to be connected, reconciled and owned before the first close-day board number is defensible.
Multi-state data governance
One authoritative source per field across states that define census, acuity, staffing and incidents differently — without forking the record.
Integration implementation checklist
The stage-gated checklist: definitions and entitlement, read-only connection, reconciliation, then authority — each item with an owner and an evidence test.
Data integration platform buyer’s guide
Nine evaluation criteria instead of connector counts, the categories of approach and where each one structurally stops.
Operator-controlled operating record and integration architecture
Six entities with declared grain and identity rules inside a five-layer read-only architecture, from landing and lineage to governed consumers.
- Connector inventory: Integration ecosystem · Integration posture
- Canonical model: One Operator-Controlled Operating Record · The operating record · What is a senior housing & care operating infrastructure?
- Comparisons: SeniorCRE vs PointClickCare® · SeniorCRE vs Yardi® · Hosting versus governing
Bring your own systems to the conversation
The useful version of this discussion is your actual stack, your actual contested numbers, and the reconciliation you cannot currently produce on demand.
PointClickCare® is a registered trademark of PointClickCare Technologies. MatrixCare® is a registered trademark of ResMed. Yardi® is a registered trademark of Yardi Systems, Inc. DocuSign® is a registered trademark of DocuSign, Inc. Salesforce® and Tableau® are registered trademarks of Salesforce, Inc. Power BI® and Microsoft® are registered trademarks of Microsoft Corporation. QuickBooks® is a registered trademark of Intuit Inc. ADP® is a registered trademark of ADP, Inc. Oracle® is a registered trademark of Oracle Corporation. All other product names, logos, and brands are property of their respective owners. SeniorCRE is an independent platform and is not affiliated with, endorsed by, or sponsored by any of the aforementioned companies. Comparisons are based on publicly available information and may not reflect all product capabilities.