Operator-controlled operating record
The Operator-Controlled Operating Record and integration architecture
Senior housing and care data is integrated into six canonical entities — Resident, Care Plan, Ledger, Shift, Property/Unit and Entity — each with one declared grain, one identity rule and one definition per attribute, however many systems supply it. Those entities sit inside a five-layer architecture: source systems stay unchanged and are read one direction; raw payloads land immutably with lineage attached at the boundary; fields are mapped to canonical entities; totals are reconciled to the general ledger, payroll and the unit inventory and conflicts are resolved by an authority rule that retains the rejected value; and only then do reporting, BI and AI consumers read the governed record. The model’s purpose is not tidiness — it is to make one number defensible when two systems disagree about it.
- Entities
- Resident · Care Plan · Ledger · Shift · Property/Unit · Entity
- Layers
- Sources · Landing & lineage · Canonical · Reconciliation & authority · Consumers
- Default direction
- Read one direction; sources unchanged
- Retained on conflict
- Accepted value, rejected value, basis of acceptance
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 of travel
Read the diagram top to bottom. Each arrow is a boundary where something is added — lineage, canonical meaning, reconciliation, authority — and never a boundary where something is quietly overwritten.
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.
| Layer | Responsibility | Invariant |
|---|---|---|
| Layer 1 — Source systems | Continue to run care, sales, payroll, accounting and property operations exactly as they do today. | Unchanged. Read one direction. No write path unless an operator authorises specific fields in writing. |
| Layer 2 — Immutable landing and lineage | Retain raw payloads as received and tag every field with source system, source identifier, interface and extraction timestamp. | Nothing is transformed before it is recorded. Lineage is attached at the boundary, never reconstructed later. |
| Layer 3 — Canonical entities | Map admitted fields to six entities with one declared grain and identity rule each. | Unmapped fields are listed, not silently dropped. One canonical attribute may have many sources but only one definition. |
| Layer 4 — Reconciliation and authority | Tie to the general ledger, payroll and unit inventory, then resolve conflicts by rule. | Accepted value, rejected value and basis of acceptance are retained together. Restatements appear as restatements. |
| Layer 5 — Governed consumers | Board and lender reporting, operating reviews, BI tools and AI workflows. | Consumers read the governed record, not the raw sources. Govern the truth before you automate the decision. |
Canonical entities
Six entities, with grain and identity declared
A model is only governable if its grain is stated. The last column is where integration projects actually fail: attributes two systems both believe they own.
| Entity | Grain | Identity rule | Most contested attributes |
|---|---|---|---|
| Resident | One governed representation per person per stay, not per system record | Deterministic match across clinical, billing and unit records; unmatched records go to an exception queue rather than being merged | Level of care, move-in and move-out effective dates, payer status at a point in time |
| Care Plan | One governed representation per plan version, with the version retained rather than overwritten | Keyed to Resident plus effective period | Assessed acuity versus billed acuity; the date a change took effect versus the date it was documented |
| Ledger | One governed representation per posted transaction, in the period it belongs to | Keyed to Entity and Property/Unit, with the source journal identifier retained | Accrual versus cash timing, intercompany allocations, management-fee treatment |
| Shift | One governed representation per scheduled or worked shift segment | Keyed to worker, Property/Unit and period | Scheduled versus worked versus paid hours; agency hours; overtime attribution across midnight and across pay periods |
| Property/Unit | One governed representation per unit, with a status history | Stable unit identifier independent of any single source system | Physical versus licensed versus available unit counts; out-of-service and model units |
| Entity | One governed representation per legal or reporting entity, with an ownership and period history | Keyed to the legal entity, not to a portfolio label | Reporting rollups, joint ventures, mid-period acquisitions and dispositions |
Source to destination
Source fields mapped to canonical attributes
One canonical attribute may have many sources and exactly one definition. The authority rule and the reconciliation test travel with it.
| 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 |
Flows
System combinations, join keys and required reconciliations
Each row states what is read together, on what interface class, on what join key, and what must reconcile 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.
Connector matrix
Named source systems the model is written against
Vendor names are used nominatively; coverage is scope, not a deployment claim.
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 |
Ownership of the record
The model belongs to the operator
A governed model controlled by a vendor is still vendor-controlled governance for your business. The definitions, authority rules and lineage are the operator’s, and they leave with the operator.
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.
Definition, authority, reconciliation, lineage — the four that make data governable. The doctrine sits in the operating record, the decision rights in the Operator Authority Chain, and the wider system context in what a senior housing & care operating infrastructure is.
Frequently asked questions
What is an Operator-Controlled Operating Record in senior housing & care software?
A small, fixed set of entities that every source system is mapped into, so a resident, a shift or a ledger posting means the same thing regardless of which system reported it. In senior housing & care those entities are Resident, Care Plan, Ledger, Shift, Property/Unit and Entity. The value is not the schema — it is that one attribute has exactly one definition and one authority rule even when four systems supply it.
Why six entities rather than a full enterprise data model?
Because the contested numbers in this sector resolve inside those six. Occupancy needs Resident and Property/Unit. Labor needs Shift and Entity. Margin needs Ledger and Entity. Acuity needs Resident and Care Plan. A larger model adds mapping surface without adding governability, and every unnecessary entity is another place where two systems can disagree unobserved.
What is the grain of each entity?
Resident is one governed representation per person per stay, not per system record. Care Plan is one governed representation per plan version, versions retained. Ledger is one governed representation per posted transaction in the period it belongs to. Shift is one governed representation per scheduled or worked segment. Property/Unit is one governed representation per unit with status history. Entity is one governed representation per legal or reporting entity with ownership and period history.
How is data lineage recorded?
At ingest, not on request. Every admitted field carries its source system, source identifier, interface and extraction timestamp, retained alongside the raw payload as received. That is what allows a published figure to be traced backwards, and what allows a restatement to appear as a restatement instead of quietly replacing history.
Does the architecture write back into source systems?
Not by default. Reads are one direction so that source systems remain the operator’s own systems of record and there is never a second competing writer. Where a write-back is genuinely useful, it is scoped to named fields and a named direction and requires written operator authorisation.
Where does AI sit in this architecture?
Above the governed record and after reconciliation, never before it. AI can propose; the operator governs. Consequential clinical and regulatory pathways are deliberately not automated, and model outputs read the governed record rather than the raw sources so that a proposal inherits definitions and lineage rather than inventing them.
Is this architecture running in an operator production environment today?
No. The connector framework is stated at its published maturity state and has been exercised against synthetic fixtures. No third-party integration runs in operator production, and no operator runs the platform in production. Capability and evidence are kept separate on the Trust Center and the Evidence Record.
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.
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.
- 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.