Praxis Async

Speaker notes · Master architecture

Presenter view

Master architecture speaker notes

Explain the system boundary first, then walk from a source event to trusted patient state. Stop before clinical decisioning.

Opening cue

“Before Praxis can decide what matters, it needs a patient state it can trust. This first architecture layer turns fragmented clinical changes into versioned, source-backed state.”

01 · System boundary

What Praxis owns—and what it does not

“Praxis is an asynchronous clinical operating layer that sits across existing healthcare systems. It converts clinical data and events from multiple sources into an updated patient state, determines when downstream work may be required and provides a durable handoff into clinical reasoning.”

Boundary statement

Source systems remain authoritative.

Praxis owns its operational projection and workflow state.

It does not silently overwrite the medical record.

Every derived fact remains connected to evidence.

Master-view cue

“The full product has four responsibilities: understand, decide, coordinate and learn. I’m intentionally going deep on Understand first because every later safety and ranking decision depends on this foundation.”

02 · Two-speed ingestion

Separate immediacy from heavy computation

How to explain the hot path

“A new message or lab should update the patient in seconds. EventBridge routes it, SQS absorbs bursts, deterministic workers normalize it, PostgreSQL commits the state and an outbox reliably notifies Temporal.”

  1. 01

    Validate intake

    Verify source, tenant, schema and access policy.

  2. 02

    Resolve patient

    Match identity; quarantine uncertain or conflicting matches.

  3. 03

    Deduplicate

    Use event ID, source version and content hashes for idempotency.

  4. 04

    Route by type

    Structured facts use deterministic parsers; documents use text extraction or OCR.

  5. 05

    Normalize & validate

    Map units and terminology while preserving confidence and provenance.

  6. 06

    Update patient state

    Write the current operational projection to PostgreSQL transactionally.

  7. 07

    Publish change

    An outbox emits PatientStateChanged and starts or signals Temporal.

How to explain the intelligence path

“Historical backfills, replay, panel features and evaluations do not belong on the latency-sensitive path. Databricks processes them incrementally from the same immutable source history.”

Bronze · Raw + immutable

Original source records, ingestion metadata and replay history.

Silver · Normalized + linked

Patient-linked, deduplicated clinical events and terminology mappings.

Gold · Derived + decision-ready

Longitudinal features, panel metrics and evaluation datasets.

Databricks publishes a versioned feature update. It does not directly own or execute the clinical workflow.

Event contract

Explain that payloads vary, but the envelope is stable. Large or sensitive content remains in S3; events carry secure references.

event_idtenant_idsource_systemsource_record_idevent_typepatient_identifiersoccurred_atreceived_atschema_versioncontent_hashraw_object_uritrace_id

Failure semantics

Do not promise exactly-once network delivery. Promise at-least-once delivery with exactly-once effects through stable event IDs, idempotent upserts and a transactional outbox.

Schema failures go to quarantine, uncertain patient matches go to manual resolution, transient failures retry and permanent failures enter the dead-letter queue.

03 · Document indexing

Preserve evidence before optimizing retrieval

01

Register

Create a document version and retain the immutable original.

02

Compare hashes

Check binary, canonical-text and per-chunk hashes.

03

Parse or OCR

Use native text first; OCR only scanned pages while preserving layout.

04

Detect structure

Classify the document and identify pages, sections, tables and paragraphs.

05

Chunk hierarchically

Respect semantic boundaries with token limits and minimal overlap.

06

Embed the delta

Reuse unchanged vectors; embed only new or modified chunks.

07

Stage & validate

Test counts, metadata filters, exact search, HNSW retrieval and citations.

08

Activate atomically

Switch the active version, then tombstone obsolete chunks.

Three hashes

Binary hash detects an exact file duplicate. Canonical-text hash avoids re-embedding cosmetic PDF changes. Chunk hashes isolate the actual delta.

Structure-aware chunks

Preserve chapters, sections, paragraphs and tables, but enforce token limits. Add the complete heading breadcrumb to the embedded text.

Atomic publishing

Build and test a candidate version before activation. If validation fails, keep the previous version live and investigate the failed stage.

Retrieval-validation cue

“I validate direct lookup, metadata filters, exact similarity, HNSW recall and citation resolution. I would not rebuild the vector index after every document; PostgreSQL maintains it as rows change.”

04 · Technology choices

Defend the role, not the logo

Connectors

FHIR · HL7 · X12 · APIs

Immediate events

EventBridge + SQS

Raw documents

Amazon S3

OCR

Amazon Textract

Heavy ETL

Databricks Lakeflow + Delta Lake

Operational state

Aurora PostgreSQL

Evidence search

pgvector + PostgreSQL full-text

Durable work

Temporal Cloud

Why not call this a traditional ETL pipeline?

Because the system has two jobs: respond to individual clinical events in seconds and perform heavier historical or population computation in minutes or hours. A single batch pipeline cannot serve both well.

Why Databricks?

It owns backfills, replay, multi-source normalization, quality rules, longitudinal features, panel aggregates and evaluation datasets. It does not own inbox latency, human approvals or application state.

Why PostgreSQL and pgvector?

Patient retrieval is strongly filtered by tenant, patient, time, permissions and document version. Keeping vectors beside relational metadata gives simpler security, transactional activation and citation joins. A dedicated vector engine remains a future scale option.

Why Temporal instead of Celery?

Celery is excellent for independent background tasks. Temporal is used for long-running clinical workflows that must survive failures, wait for approval, receive external signals and resume from the same durable state.

State ownership

Source systems

Authoritative clinical record

S3 + Delta Lake

Immutable, replayable history

Aurora PostgreSQL

Current operational patient state

pgvector

Patient-scoped evidence retrieval

Temporal

Durable workflow progress—not clinical truth

Non-negotiables

At-least-once delivery with idempotent effects

Original evidence and provenance are never discarded

Structured data avoids unnecessary model calls

Uncertain identity or extraction is quarantined—not guessed

New document versions are validated before activation

Audit logs contain references and hashes, not raw PHI

Closing transition

“At this point Praxis has a current, replayable and evidence-backed patient state. The next architecture question is how we decide what matters now without running expensive deep reasoning over every patient and every event.”

Product direction notesNext: Decide what matters now