Repurposing the healthcare stack

Wealthcare proposes to run personal financial wellness on the same resource-based interoperability model that healthcare uses — the HL7 FHIR standard and the open-source HAPI FHIR server. The back end speaks real FHIR; the front end relabels those resources for the wealth domain.

A short lineage

Four milestones that lead to the model Wealthcare repurposes.

1. Reference model ISO 13606 An EHR reference-model standard for communicating electronic health records. It frames every resource needed to fill out a full profile. Wealthcare treats it as the conceptual reference model for what a complete record of a person should hold.
2. 1960s–70s Larry Weed — POMR The Problem-Oriented Medical Record organized health data around a patient's problems rather than around providers. It is the intellectual ancestor of structuring a person's record around problems and goals — which is exactly how Wealthcare anchors signals to an objective.
3. Modern standard HL7 FHIR A resource-based interoperability standard: discrete resources, references between them, coded data, and search on codes and combination-codes. This is the data model Wealthcare adopts wholesale for time and money.
4. Open-source server HAPI FHIR The open-source Java reference server implementing FHIR. It stores resources, exposes a search API over codes and parameters, and explodes JSON resources into relational tables. This is the concrete thing Wealthcare proposes to repurpose first.

Front end ↔ back end mapping

The back end uses real FHIR resource names; the front end relabels them for the wealth domain. The person is always the Client in the UI (it maps to FHIR Patient); we never say "patient" in the product.

The Observation model and rolling metrics

Every time or money event is an Observation. Its shape is small and fixed:

• code — a coded behavior (see the governance section on coding systems).
• subject — a reference to the Client (FHIR Patient).
• category — the top-level axis: time vs money, extensible to sub-categories like "discretionary" or "health-adjacent".
• effectiveDateTime — when it happened, tying money events to the transaction feed and time events to the calendar feed.
• valueQuantity — the magnitude: dollars for money, minutes or hours for time.
• component[] — used for rolling summaries.

The system stresses two derived signals: a rolling average and a rolling deviation from that average. These are derived Observations — a summary Observation whose component[] carry the rolling average and rolling standard deviation over a trailing window (for example 30 or 90 days), computed over the stream of raw Observations. This is what powers the "we noticed a large expenditure" trigger in the syndication flow.

RiskAssessment: behavior → financial consequence

A concrete, clearly hypothetical example (the Client "Jim"):

• Behavior Observations accumulate: coded tobacco-purchase events for Jim.
• A RiskAssessment references those Observations as its basis and expresses a prediction with a modeled probability band of 0.25%–0.4% modeled lung-cancer likelihood (illustrative modeling — not a medical or actuarial determination). Treat this as a rule-of-thumb figure, not a clinical claim.
• That health risk flows to a financial consequence: a modeled treatment cost and insurance-premium impact, surfaced as the RiskAssessment card on the dashboard and as the trigger for the insurance-broker syndication flow.

This is illustrative modeling — not a medical or actuarial determination. The 0.25%–0.4% band is the narrative's own illustrative figure and does not describe any real individual.

Syndication and the human in the loop

Observations plus rolling metrics detect a signal; a RiskAssessment or a threshold fires; Wealthcare syndicates the relevant slice of data to a partner pipeline (for example an insurer) over APIs; the partner returns an offer (pre-approval, premium); and Wealthcare surfaces it to the Client with a human Practitioner (a broker) and bookable Encounter slots that drop onto the calendar. It cannot all be behind the scenes — human engagement is a first-class requirement, not a footnote. The dashboards mock this exact flow.

Governance and terminology

The terminology and conformance trio is how a governance team controls what may be written into the pipeline — not just data plumbing.

• CodeSystem — defines coded behaviors. Do financial coding standards already exist? For money, yes: MCC (Merchant Category Codes, ISO 18245) classify merchants on card transactions, and bank feeds often carry them, so MCC is a reasonable seed vocabulary for money Observations. For time and behavior there is no universal standard, so Wealthcare defines a custom CodeSystem (also for finer financial intent than MCC captures).
• ValueSet — the approved subset of codes usable in a given Observation category (for example the ValueSet of money-behavior codes drawn from MCC plus custom codes).
• StructureDefinition (profiles) — constrains what a valid Wealthcare Observation or RiskAssessment must contain. This is the contract a new partner app must conform to.

A governance team approves new CodeSystem entries, ValueSet membership, and profiles before any new app or data source may write to the pipeline. The step-by-step workflow is detailed on the roadmap.

The minimum sufficient resource set

The smallest set of resources that makes the system work, with one line of justification each:

• Patient → the Client; everything references them. Without it there is no subject.
• Observation → the atomic time and money event and the rolling-metric summaries; the raw signal of the whole system.
• RiskAssessment → turns accumulated behavior into a modeled financial or health consequence; the analytic payoff and the riskrunners.com anchor.
• Practitioner → the human specialists (advisor, attorney, accountant, broker) required for the human-in-the-loop engagement model.
• Encounter → scheduled meetings and appointments that connect Client and Practitioner (the broker slots).
• CodeSystem, ValueSet, StructureDefinition → make the coded data governable and enforce conformance so new apps can be approved safely.

This subset is the basis for the lean replacement migration target on the roadmap: once proven, Wealthcare only needs these resources, not all of HAPI FHIR.