Data integration
Data integration for senior housing & care
The business outcome is a number leaders can use without erasing the authority of the systems that produced it. Integrating senior housing & care systems takes five steps in a fixed order: settle the definition of every contested number, connect each source system read-only with lineage attached at ingest, map every source field to one of six canonical entities — Resident, Care Plan, Ledger, Shift, Property/Unit, Entity — reconcile period totals to the general ledger and to payroll worked hours within a written tolerance, and then declare which system holds authority for each field when they disagree. Integration alone gets data into one place; it does not settle which number governs a decision. That last step is what turns connected data into an Operator-Controlled Operating Record.
- Canonical entities
- Resident · Care Plan · Ledger · Shift · Property/Unit · Entity
- Direction
- Read-only by default; scoped writes only when the operator authorises them
- Interfaces
- Vendor APIs, HL7 v2, FHIR R4, scheduled and SFTP extracts
- Governing rule
- When systems disagree, the operator governs
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.
Architecture
Five layers, one direction
The architecture is deliberately boring at the edges and strict in the middle. Sources stay as they are. Governance happens above them.
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
Where each source field lands, and who governs it
Mapping is not the hard part. Authority is. Each row below states the reconciliation test that has to pass before anything derived from that entity is published. See one Operator-Controlled Operating Record for the entity definitions themselves.
| 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 |
Connector coverage
Named systems and the interfaces they are read on
Coverage is stated as scope, not as deployment. The full inventory, including categories not listed here, is on the integration ecosystem page.
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 |
Compatibility
Which system combinations are read together
Each combination below names the interface class it is read on, the key that joins the two systems, and the reconciliation that must pass before a blended figure is published.
Connector scope state: FRAMEWORK
| System combination | Read on | Join key | Must reconcile first |
|---|---|---|---|
| EHR / eMAR + accounting or ERP general ledger | Vendor API, HL7 v2, FHIR R4 · GL read | Resident identity key · Property/entity key · Closed period | Clinical census against billed census; posted revenue against the billing sub-ledger |
| EHR / eMAR + payroll and time | Vendor API or extract · payroll register, SFTP | Property/entity key · Shift date · Closed period | Documented care minutes against worked hours; agency hours cause-coded to the open shift |
| CRM + property management unit inventory | Vendor API · scheduled extract | Prospect identity key · Unit key | Move-in pipeline against physical, licensed and available unit counts held as distinct fields |
| Property management + general ledger | Vendor API · dimension-aware GL read | Property/entity key · Closed period | Billed rent roll against posted revenue within a written tolerance |
| Payroll and time + general ledger | Scheduled export, SFTP · GL read | Entity key · Pay period mapped to accounting period | Payroll cost against GL labor expense, including accrual timing differences |
| Governed record + BI (Power BI®, Tableau®) | Outbound governed dataset | Record version identifier | Nothing is exposed to BI before the period baseline is frozen; BI reads, and writes nothing back |
| Multi-entity portfolio across states | Per-instance reads, one governed record | Property → operating entity, per effective date | State-specific definitions held as attributes of one field, never as competing fields |
Every row is read one direction by default. A combination being in scope is not a claim that it runs in an operator production environment today.
Decision
Keep it or replace it — the operator decides, per system
Governance does not require displacement. This table is the decision an operator actually faces, system class by system class, with the governance requirement that holds either way.
| System class | Keep it when | Replace it when | True either way |
|---|---|---|---|
| EHR / eMAR | Clinical staff are fluent in it, survey history lives in it, and the interface exposes census, acuity and documentation reliably. | The operator chooses the SeniorCRE clinical record — its own EHR and eMAR — as the clinical system of record, typically to remove a documentation seam it is tired of reconciling. | Exactly one authoritative MAR at all times, before, during and after any transition. |
| CRM / sales | Pipeline discipline is already good and the sales team will not adopt a second surface. | Prospect records cannot be tied to the unit that was actually sold, so move-in forecasting is guesswork. | Prospect identity resolves to the same Resident entity as the admitted resident. |
| Payroll and time | It is the system of record for hours paid and the operator has no appetite to move payroll. | Rarely. Payroll replacement is a finance decision, not an integration one. | Payroll is authoritative for hours paid; the schedule is authoritative for intent. Both reconcile to one period. |
| Accounting / ERP general ledger | Almost always. The GL is the audited record and should stay where the auditors expect it. | Only on a finance-led ERP program with its own governance. | The GL stays authoritative for posted amounts; no derived metric publishes before the GL tie passes. |
| Property management | The unit inventory is accurate and licensure detail is maintained there. | Unit counts cannot be separated into physical, licensed and available, so occupancy has no stable denominator. | The property management system stays authoritative for unit inventory until the operator moves it. |
| Reporting spreadsheets | For modelling and scenario work that is explicitly not the record. | When a spreadsheet has become the de facto source of the board number — the one case where replacement is the point. | Nothing published is computed outside the governed record without lineage back to it. |
Implementation
The phased sequence
Each phase has an exit test an operator can apply without taking a vendor’s word for it. Skipping Phase 1 is the single most common reason integration projects produce dashboards nobody trusts.
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 along the Operator Authority Chain™
Evidence → Disagreement → Authority → Operator-Controlled Operating Record → Intelligence → Execution. Lineage is what makes each arrow auditable. Read the authority chain for the full argument.
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.
Coexistence
Integration is access. Governance is authority.
Connect what exists. Govern what matters. Replace only by choice. If you are still selecting systems, the shortlists for operators with 10+ locations and for senior housing & care business intelligence software apply the same rubric to named products. Start with the plain-language senior housing & care software category guide if the buying category itself is still unsettled.
Govern first. Replace only by choice.
SeniorCRE has built clinical record surfaces; medication administration and eMAR remain roadmap — not built. It can run alongside an incumbent clinical system, reading one direction only, with that system’s MAR authoritative. Any future SeniorCRE clinical system-of-record function must clear its own Production-Entry Gates and operator acceptance.
Access is not authority. A vendor that can read your data has access; the operator who decides which value the business accepts has authority. Integration delivers the first. Only a governed record delivers the second.
Cluster
The five questions operators actually ask
Each page below answers one question end to end, in isolation.
How do I combine PointClickCare and accounting/payroll data?
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.
How do I connect EHR, CRM, payroll and accounting data in senior housing & care?
Connecting EHR, CRM, payroll and general-ledger data
The four-system join: which system is authoritative for which field, and how conflicts are resolved rather than averaged.
Can I integrate senior housing & care systems without replacing my EHR?
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.
How do I integrate an acquired community’s systems on day one?
Acquisition-day integration
What has to be connected, reconciled and owned before the first close-day board number is defensible.
How do I govern senior housing & care data across multiple states?
Multi-state data governance
One authoritative source per field across states that define census, acuity, staffing and incidents differently — without forking the record.
How do I integrate senior housing & care software systems?
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.
How do I evaluate a senior housing & care data integration platform?
Data integration platform buyer’s guide
Nine evaluation criteria instead of connector counts, the categories of approach and where each one structurally stops.
What operator-controlled operating record and architecture does senior housing & care integration use?
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.
Frequently asked questions
What is a senior housing & care data integration platform?
It is the layer that reads the systems an operator already runs — EHR and eMAR, CRM, payroll and time, accounting or ERP, and property management — normalizes each source field into a shared set of canonical entities, and reconciles the results so a single governed figure can be published. The distinction that matters is between moving data and governing it: a platform that only consolidates leaves conflicting values side by side, while an Operator-Controlled Operating Record records which value the operator accepts, which value was rejected, and on what basis.
How do I integrate senior housing & care software systems?
Define the contested metrics and name an owner for each; obtain read-only credentials or scheduled extracts from each source system; land raw payloads immutably with source system, source identifier, interface and timestamp attached; map every field to a canonical entity; reconcile period totals against the general ledger and payroll worked hours within a written tolerance; route exceptions to named owners; freeze a dated baseline; then set the authority rule per attribute so conflicts resolve by rule rather than by whoever built the spreadsheet.
Which senior housing systems does SeniorCRE connect to?
The connector framework is written against PointClickCare®, MatrixCare®, Med e-care, Yardi® Voyager, RealPage®, Sage Intacct®, Microsoft® Dynamics 365, Sherpa CRM, Enquire Solutions, WelcomeHome Software, Power BI®, Tableau®, DocuSign® and Adobe Sign, plus payroll and time systems via scheduled export, SFTP or published vendor API. That coverage is scope at a FRAMEWORK maturity state. No third-party integration currently runs in an operator production environment, and no operator runs the platform in production today.
Do I have to replace my EHR to integrate?
No. Clinical scope is a configuration choice. 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. Govern first; replace only by choice.
How is data lineage maintained?
Every admitted field carries its source system, source identifier, extraction timestamp and the interface it arrived on. When two systems disagree, both values are retained and the governed record shows the accepted value alongside the rule or named person that accepted it. Decisions reference the record version they were made against, so a later restatement never silently rewrites the basis of a past decision.
Does integration write back into my source systems?
Not by default. The default posture is read-one-direction: source systems are left untouched and remain the operator’s systems of record until the operator decides otherwise. Any write path is explicit, scoped to named fields, and authorised by the operator.
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
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.
Connecting EHR, CRM, payroll and general-ledger data
The four-system join: which system is authoritative for which field, and how conflicts are resolved rather than averaged.
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.