Your data. Your vendor’s permission.

Primitives versus business logic

Third parties want building blocks; platforms ship pre-shaped operations — and the shape of the operation is where the competitive boundary hides.

The clearest place to watch this play out is the difference between primitives and business logic.

Developers — and, increasingly, the AI copilots and agents an operator’s own team wants to point at their data — want primitives: the basic building blocks of the operation. The resident record. The census event. The care-minute. The charge. When their complaints get flattened into “just give us read/write access,” what they’re actually asking for is optionality: give us the underlying data and capabilities, and let us decide what to build.

Platforms prefer abstractions: predefined operations that encode the platform’s own assumptions about how the work is done. Instead of exposing the resident record, the platform exposes “admit this resident.” Instead of the raw charge, “post this transaction.” This lets a third party accomplish a specific job without understanding everything happening underneath — and it often exposes exactly what’s needed for that one job, and no more.

The anticompetitive angle is easy to see. A business-logic API sized precisely to a job can fill a product gap while quietly commoditizing the complement that fills it — making point solutions interchangeable, and keeping them from expanding into the adjacent workflow next door. Primitives give a third party room to innovate at the integration edge. Surgically scoped business logic keeps it undifferentiated.

The case for abstraction is also real

At the scale of a mature system of record, a write is never just a write — which is why raw primitives alone cannot be operated safely.

Here’s what makes this genuinely hard, rather than merely unfair: the platform’s preference for abstraction isn’t only self-serving. It’s often correct.

Exposing an operation like “schedule this assessment” instead of a dozen raw tables means the platform doesn’t have to teach every developer the intricacies of its data model — or force each one to independently reconstruct the rules that turn data into a valid action. And that argument gets stronger the larger the system of record grows.

Consider the scale involved in mature systems of record. Outside our sector, an acute-care EHR’s data model runs to thousands of tables and tens of thousands of individual data elements: Epic publishes an electronic-health-information export specification spanning its entire native schema, table by table.^[1] The federal EHI-export rule that requires such exports is explicit that there is no fixed, predefined data set — the contents “will differ by developer and product.”^[2] Senior housing & care systems are not acute-care EHRs, but the direction of travel is identical: as a platform accretes clinical, financial, workforce, and compliance responsibility, its underlying model becomes something no outside developer can safely operate against directly.

At that scale, a “write” is never just a write. Changing one object correctly requires enforcing user permissions, updating related records, maintaining referential integrity, triggering downstream workflows, satisfying application-specific rules, and documenting the change in an audit trail for compliance. Follow that far enough and you arrive somewhere ironic:

The efficiency argument is self-evident. Educating a thousand vendors on a data model with decades of bespoke logic layered into it, sedimentary rock–style, is a combinatorial tax compared with centralizing that knowledge once, at the source.

The conundrum, and why it can’t be solved from inside the vendor

Legitimate engineering and competitive boundary-drawing are indistinguishable from the outside — and standardized resources do not settle it, because the vendor is still the party deciding.

So we’re left with a knot. A platform sizing an API to a job is simultaneously solving a legitimate engineering problem and drawing a boundary around its competitors — and from the outside, those two motives are nearly indistinguishable. There is no test that separates them. That’s exactly why this is so hard to regulate and so easy to litigate messily.

The tempting compromise is to standardize the primitives, and in healthcare that’s what interoperability standards attempt. But a standardized resource, for most systems, is not the underlying data model — it’s an abstraction papered over the real one, often only loosely correlated with how the software actually thinks. You end up with a building block that has neither the convenience of a true abstraction nor the flexibility of a true primitive: an abstraction moonlighting as a primitive.

The reason this compromise never fully lands is worth stating plainly, because it’s the whole point: the conflict is unsolvable from inside a single vendor’s boundary. Whatever the vendor exposes — raw or abstracted, standardized or proprietary — the vendor is still the party deciding. As long as the authority to decide what you may build with your operation lives inside the system that owns the operation, the operator’s optionality is contingent on a counterparty whose incentives point the other way.

You cannot fix a governance problem by asking the party you’re governed by to govern more kindly. The myth of the benevolent system of record is widespread and, in practice, nearly nonexistent — not because vendors are malicious, but because the economics of platform power don’t care about anyone’s good intentions.

The resolution is to move the authority up a layer

The tension doesn’t disappear; the pen changes hands. The operator defines what governs, and every such decision is recorded and reconstructable.

If the problem is who decides, the answer is not a better-behaved vendor. It’s to move the decision.

This is the case for an operator-controlled operating record: a governed layer that sits above the systems of record — the EHR and eMAR, the AR/GL, the workforce and scheduling systems, the CRM and census tools — and holds the operator’s own authority over how their data becomes truth, and how that truth becomes a decision. That architecture is documented at /operating-record.

We should be honest about our own position here, because it sharpens the argument rather than softening it. SeniorCRE clinical record surfaces are built; medication administration and eMAR remain roadmap — not built. In the clinical domain, an operator can choose to run SeniorCRE as the system of record, or retain an incumbent and govern clinical data through the operating record — clinical configuration is an operator choice, not a prerequisite, and it is set out at /ehr-emar. But that is not the category claim, and it is not the point of this piece. The point is the layer above the stack — the one that governs across whatever systems of record an operator already runs. In that cross-system record, SeniorCRE is frequently the third party reaching into an incumbent for a customer’s own data. We are describing the squeeze from inside it.

What changes when the authority moves up a layer is not that the primitives-versus-abstraction tension disappears. It’s that the operator, not the vendor, holds the pen. The operator defines which source governs when systems disagree. The operator sets the reconciliation rules, the survivorship logic, the permissions. The operator decides what its own agents and copilots may read, propose, and act upon — and every one of those decisions is recorded, versioned, and reconstructable, so the authority is auditable rather than assumed. We call that path DATA → TRUTH → DECISION → EXECUTION, and the operator governs every step of it, as set out in the Operator Authority Chain™. When systems disagree, the operator governs.

That is the difference between integrating into a vendor’s boundary and governing above it. In the first, your optionality is whatever the platform chose to expose this quarter. In the second, optionality is a property you own, because the record that defines your operation answers to you.

Why now

Agent demand is outrunning vendor API roadmaps while the access climate tightens — so the question is which record the next decade of tools reasons over.

Three forces are making this move from good idea to necessary one, and they are the same forces reshaping every data-rich industry.

The explosion of AI copilots and agents is creating demand for niche, operator-specific workflows faster than any platform can ship APIs for them. Advances in automation are making interfaces machine-operable whether platforms intend it or not. And the regulatory climate around information blocking and interoperability is steadily constraining how far a platform can go in controlling access to a customer’s own data — though operators should treat the applicability of any specific rule to their setting as a question for counsel, not a settled fact.

The convergence is simple to state. The tools that will define the next decade of senior housing & care operations all need to reason over an operator’s data. The question is whether they reason over a record the operator governs, or one that a vendor exposes to them on terms the operator never set. That is the argument developed at /why-now.

The primitives problem is real, and it does not have a clean answer inside any single system. That is precisely why the authority has to sit somewhere else: with the operator, in a record they control. Not a friendlier landlord. A deed.

Sources and notes

1. Epic Systems, EHI Export Specification (EHI Tables), open.epic.com/EHITables, documentation current as of August 2026. Cited only as external illustration of the scale a mature system of record’s data model reaches; not a statement about any senior housing & care system, and inclusion implies no integration, comparison, endorsement, or affiliation. Epic is the property of Epic Systems Corporation.
2. U.S. Office of the National Coordinator for Health IT, 45 CFR 170.315(b)(10) Electronic Health Information Export, healthit.gov (accessed August 2026): the criterion “does not specify a predefined data set and will differ by developer and product.”

SeniorCRE is the operator-controlled operating infrastructure for senior housing & care. Operator Authority Chain™ is a mark of SeniorCRE, LLC. This article is a perspective on platform dynamics and is not legal advice; operators should consult counsel on the applicability of any regulation to their circumstances.

Frequently asked questions