There’s an uncomfortable asymmetry at the center of e…
The system of record decides what everyone else may build with. Primitives preserve optionality; abstractions encode the platform’s assumptions — and interoperability standards do not resolve who holds the pen. Why that authority has to move up a layer, to an operator-controlled operating record where definitions, source authority, reconciliation, and lineage are governed by the operator.
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.
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.
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 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 .
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.
Sources and notes
SeniorCRE® is the 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.
Author
John Hauber — Founder & CEO, SeniorCRE. Founder and CEO of SeniorCRE, LLC. Two decades operating and advising senior housing & care platforms, including HavenCo Senior Investments and Haven Senior Realty.
Reviewed by
SeniorCRE, LLC — internal editorial review — Vendor-published and internally reviewed; not independently reviewed or certified by any third party or standards body (reviewed 2026-01-15T00:00:00Z). Reviewed internally by SeniorCRE, LLC staff before publication. SeniorCRE, LLC is a vendor in the categories described and is not an independent standards body, certification authority, or law firm.
Sources & methodology
SeniorCRE editorial content is drafted by named operators or product leaders, reviewed internally by SeniorCRE, LLC staff (operators, clinicians, and capital-markets contributors) — a vendor-side review, not independent certification — and grounded in publicly available primary sources and the SeniorCRE QoS methodology. Comparative claims about named third-party products use hedged, dated phrasing.
- SeniorCRE Methodology: how we source, review, and cite — SeniorCRE, LLC
- SeniorCRE Trust Center — data, privacy, and clinical governance — SeniorCRE, LLC
- SeniorCRE, LLC — company overview — SeniorCRE, LLC
https://seniorcre.com/articles/who-decides-primitives-problem