PROACTIVE WEALTHCAREWealthcare
Proof of concept — not investment advice. Wealthcare is an educational, proof-of-concept demonstration using deterministic, hypothetical modeling. A real deployment offering personalized financial guidance would require an SEC no-action letter, or would have to restrict access to accredited investors. Read the full disclaimer.
Roadmap

Buy vs build

The thesis: build on top of open-source HAPI FHIR first to minimize time-to-market. Then — once it is clear only the minimum sufficient resource subset is actually used — build a lean replacement limited to that subset and migrate off HAPI FHIR onto it. Faster, cheaper, owned.

The phased plan

  1. Phase 0

    Repurpose & prove

    Goal: prove the model with no new infrastructure.

    What gets built: stand up HAPI FHIR; relabel Patient → Client, Observation → behavior/transaction, and the rest; load representative Observations; build the dashboards. This proof-of-concept site is the artifact of Phase 0's thinking.

    Buy vs build: buy (adopt open-source HAPI FHIR as-is).

    Unlocks: a working resource model to ingest real data against.

  2. Phase 1

    Ingest

    Goal: get real time and money signals flowing in.

    What gets built: wire the two data sources — Google Calendar (time) and bank/transactions via a Stripe-style partner (money). AI/LLM agents do the NLP to extract structured Observations from free-text calendar entries and transaction descriptions, mapping them to codes (MCC plus the custom CodeSystem).

    Buy vs build: buy the feeds and LLM models; build the extraction and coding layer.

    Unlocks: a live Observation stream for rolling metrics.

  3. Phase 2

    Objective & baseline

    Goal: anchor the signals to a goal so they mean something.

    What gets built: integrate account.ninja objective-setting and the immunized-baseline report pipeline; attach goals to the Client; render the funding view.

    Buy vs build: reuse account.ninja and its pipeline (build the integration).

    Unlocks: an immunized goal-funding baseline the dashboard can show.

  4. Phase 3

    Risk & syndication

    Goal: turn risk into action with a human in the loop.

    What gets built: add RiskAssessment analytics and the insurer/broker syndication plus human-in-the-loop engagement — pre-approvals syndicated from a partner pipeline and bookable broker Encounter slots.

    Buy vs build: buy partner pipelines (insurer APIs); build the syndication and engagement flow.

    Unlocks: the full behavior → consequence → human loop.

  5. Phase 4

    Lean rebuild & migrate

    Goal: own the stack and shed what is not used.

    What gets built: replace HAPI FHIR with a purpose-built store covering only the minimum sufficient resource set; migrate the data; decommission the HAPI dependency.

    Buy vs build: build (the lean replacement) and retire the bought dependency.

    Unlocks: a faster, cheaper, fully-owned platform.

Data-source integrations

  • Time → Google Calendar: event titles and descriptions → LLM extraction → time Observations (category=time, valueQuantity in minutes).
  • Money → Stripe-style bank/transaction partner: transaction descriptions plus MCC → LLM classification → money Observations (category=money, valueQuantity in dollars).

Design note (not implemented): the system handles sensitive calendar and financial data. A real deployment needs explicit consent and secure handling of that data. This proof of concept flags privacy and consent as a first-class concern but does not implement it.

Governance-team workflow

Approving a new mapping or a new partner app that wants to write to the pipeline follows six steps. This ties back to the governance and terminology resources.

  1. Propose codes.
  2. Governance reviews them against the existing CodeSystem and ValueSet.
  3. Define or extend the StructureDefinition profile.
  4. Validate conformance in a staging HAPI instance.
  5. Approve and publish the ValueSet and profile.
  6. Grant the app write scope.