Architecture Discipline: Building a Healthcare Platform From Zero
Healthcare software rarely fails at the demo. It fails in the eighteen months after, when a compliance review surfaces a data path nobody wrote down, when two dashboards disagree about the same denominator and the field team stops trusting either, when the infrastructure bill arrives with a large number attached to a feature that was never priced. The teams that avoid this are not always the largest ones. A small engineering group can ship and operate a regulated analytics platform that other firms would staff at ten times the size, but only if the hard decisions are made before the first product line rather than renegotiated during the third.
What separates the two outcomes is rarely tooling or raw velocity. It is architecture discipline: a short list of decisions made early, written into the build, and defended by automation instead of by memory. PracticeVantage built the platform behind Ariv Health on that principle, designing the architecture, building every product, and running the system in production. Four constraints carried most of the load.
Decide the architecture early, then stop deciding
Most rebuilds are not caused by bad code. They are caused by a second product that does not fit the first product’s assumptions. The defense is a platform core defined by a single schema that every product line consumes through generated APIs and client SDKs. When consumers are generated rather than hand-written, adding a product means extending the core and regenerating against it. It does not mean a parallel stack with its own authentication, its own entitlements, and its own private opinion about what a provider record is.
For Ariv Health, that core carries authentication, entitlements, data lake APIs, ingest pipelines, and metering, and it is shared by every product line: market, referral, and financial intelligence for post-acute and value-based care organizations, spanning home health, hospice, skilled nursing, ACO and value-based care, and specialty network benchmarking, alongside a healthcare CRM and a native iOS application. Each of those is a generated consumer of the same core rather than a separate ground-up build.
The second early decision is where computation happens. Analytics products that compute on read are pleasant in a demo with one tenant and expensive in production with many. Ariv’s reads are precomputed into per-tenant artifacts and served from the edge, which makes sub-second response a property of the architecture rather than a permanent tuning exercise. Every number traces back to verified CMS claims data; the public and restricted files are ingested, normalized, and published as precomputed read models.
The third decision is tenant isolation, and it is the one worth enforcing as a release gate. Row-level tenancy at runtime is table stakes. What actually prevents the bad day is a build-time check that fails the release if any tenant’s data has been baked into a shared build artifact. A runtime policy is a promise. A failing build is a fact.
Treat regulatory correctness as code
In regulated analytics, the risk is not that the math is wrong on day one. Subject-matter experts usually get it right on day one. The risk is drift: a refactor a year later that quietly changes a rounding rule, a benchmark year, or an attribution boundary, and nobody notices because the output still looks plausible. Plausible is the dangerous state, because it survives review.
The counter is to freeze the formulas and let the test suite hold them. Ariv’s actuarial and shared-savings formulas for ACO strategy modeling were fixed in collaboration with subject-matter experts and are enforced by byte-identical regression tests. Not approximately equal, not within tolerance: byte-identical. A refactor either reproduces the agreed math exactly or it does not ship. That converts a recurring governance conversation into a build status.
The same discipline applies to privacy. A masking layer strips protected health information and suppresses small cells before any model, internal or external, sees the data, and that layer carries its own regression pins so the guarantee cannot weaken by degrees. This matters more as analytics move toward assistants. Ariv runs nine production MCP servers that expose governed analytics to AI assistants, including one remote server live and registered in claude.ai, answering healthcare-analyst questions under policy and persona controls. What makes that safe to operate is not the interface. It is the governing layer underneath it, tested like every other correctness requirement in the system.
Govern cost by design, not by invoice
Cost overruns in data and AI products are usually not caused by inefficiency. They are caused by unbounded surfaces. A query interface without a quota, a model call without a ceiling: each is fine until one tenant finds it. The remedy is structural rather than behavioral. Daily quotas per user and per tenant, built into the platform itself, mean the worst-case bill is a known number before a feature ships instead of a discovery afterward. Ariv’s LLM service enforces hard per-tenant spend ceilings for precisely this reason.
The point is less about frugality than about predictability. A platform whose maximum cost can be stated in advance can be priced, sold, and extended with confidence. A platform whose cost is observed monthly and explained retroactively cannot, and the commercial team learns to fear the features that matter most.
Keep the builders on the platform
The three constraints above all decay on handoff. Correctness pins, isolation gates, and spend ceilings look like friction to a team that inherited them without the reasoning behind them, and the quiet failure mode of large delivery programs is an operations group that removes a check because it blocked a release on a Friday afternoon. Guarantees survive when the people who understand why they exist are still the ones on call.
PracticeVantage designed the architecture for Ariv Health, built every product, and operates the platform in production today, serving home health, hospice, ACO, and specialty network customers. It runs serverless-first on AWS, is written entirely in Go, and is managed as code. New CMS data releases become refreshed intelligence through automated ingest pipelines without manual intervention. That last property is what architecture discipline actually buys a small team: routine work stops consuming people, so people stay available for the decisions that genuinely require them.
Where the bar sits now
Most organizations still attach AI to a platform the way they would attach a chat widget: an assistant that sits outside the controls the rest of the system answers to, with no permissioning model of its own, no masking between it and the raw data, no spend ceiling, and nothing that would fail a release the way a broken migration would. It is treated as a feature, and features get exceptions.
Ariv’s nine production MCP servers, one of them live and registered in claude.ai, run under the same masking layer, the same policy and persona controls, and the same per-tenant spend ceilings as every other interface into the platform. They answer real analyst questions inside the governed boundary rather than alongside it. An AI surface is either production infrastructure or it is an exception waiting to be found. That distinction is what will separate the systems still trusted in three years from the ones quietly disconnected after an incident, when someone asks which controls applied to the assistant and the honest answer is none of them.
None of this is specific to one platform. The same four constraints hold on every engagement PracticeVantage takes: architecture decided early, correctness enforced as code, cost governed by design, and the people who built the system still operating it. That is the standard the firm holds itself to first, not a showcase reserved for its most visible platform. A gate a firm will not run on its own work is advice rather than engineering.
The general case
Healthcare makes these constraints legible because the regulator states them out loud, but nothing here is specific to claims data. Any high-stakes system, whether it produces financial reports, underwriting decisions, or operational safety limits, contains a small set of properties that must not drift and a much larger set that should stay flexible for years. The common mistake is treating both categories identically. Freeze everything and the platform becomes impossible to extend; freeze nothing and it becomes impossible to trust. The work is deciding which is which, early, while the list is still short enough to write on one page.
So write it. Name the numbers that must be reproducible exactly. Name the boundaries that should fail a build rather than a policy review. Name the maximum monthly cost the business is willing to underwrite. Encode each one where a machine enforces it without asking, and keep the people who wrote them close to production. Frameworks, vendors, and org charts can all change later without much cost. These cannot.
Set the constraints first. The headcount question tends to answer itself.