Engineering·FHIR R4 Data Flow

FHIR R4 Data Flow

How clinical data moves from the hospital EHR through Travi's validation pipeline to patients and clinicians. The architecture is read-mostly by design: Travi never writes discrete orders, medications, or clinical impressions into the EHR, the only planned export is a CCD summary to the media tab, deferred past the MVP (INT-008, ADR-010).

TRAVI AI AGENT: FHIR R4 DATA FLOWREAD-MOSTLY BY DESIGN: NO DISCRETE EHR WRITE-BACK IN THE MVPHOSPITAL EHR · EPIC / ANY FHIR R4ADT A03 discharge eventHL7v2 over site VPNdisposition = home filterFHIR R4 readsPatient · EncounterMedicationRequest / MedicationStatementDocumentReference (AVS, DC summary)SMART backend-servicesOAuth2 client-credentialsregistered scopes onlyPoll fallback (ADR-007)Encounter poll q5 minif ADT is declinedDocument drop / SFTPfirst-line integration pathworks without an IT projectCCD summary exportpost-MVP (INT-008 · ADR-010)media tab only: never ordersTRAVI PIPELINE · TOP TO BOTTOM, EVERY STEP AUDITEDIngest & parseehr_adapter boundary · fingerprint + supersessionPDF / CDA / HL7 parsers · OCR only for scansLLM extractionAWS Bedrock · Claude · version-pinnedtemp 0 · zero-retention BAASeven validation gatesschema · RxNorm/LOINC · clinical checksverbatim span proof · semantic passReview queueuncertain goes toclinical reviewnever auto-publishedcompiler.publish()gate-passing facts only · one transactionidempotent · rerun-safeEpisode engine: single writer of statefive-element transition contract · transactional outbox ≤5 sthe only path that changes any task or episodeSchedulingrequirement vs apptmatch · assisted requestsNotificationsSMS-first laddersquiet hours · ≤60 s stopClinician briefT−24 h snapshotstaleness · post-visitAnalytics: honest numbersfrozen denominators · coverage flags · n<11 suppression1234567after clinical decisionPEOPLE & CHANNELSPatient & caregiverToday via SMS linkno app · no password≤3 actions · 4 honest answersPCP60-second brief · secure linkno account neededstep-up before confirmationsClinical reviewworks the review queueapproves patient-facing textOps (contracted)scripted med-access flowsevidence in · engine decidesHospital adminreports · kill switcheszero routine work queueImmutable audit ledger: every PHI read, state transition, agent action, and config changeINSERT-only role · monthly partitions · 6-year WORM archive · any instruction reproducible to its source span in ≤5 minutesTLS 1.2+ / AES-256 at restBAA: AWS · Bedrock · Twilio · SESNo PHI in notificationsRxNorm / LOINC normalizeddata flowvalidated pathreview & deliveryfallback / post-MVP

Inbound: triggers and reads

The episode trigger is an HL7v2 ADT A03 (discharge, disposition=home) delivered over the site interface engine/VPN, verified against the FHIR Encounter before a candidate episode is created (≤15 min, ENR-001). If a hospital declines the ADT feed, an Encounter poll every 5 minutes is the contracted fallback (ADR-007), and the first-line integration for any partner is a plain document drop, which needs no IT project at all. FHIR R4 reads are limited to the registered SMART backend-services scopes: Patient, Encounter, MedicationRequest/MedicationStatement, and DocumentReference for the discharge summary and AVS. Every read crosses one boundary, core/ehr_adapter, so swapping the FakeEHR fixture for a live Epic connection is configuration, not a rewrite.

Through the pipeline

Documents are fingerprinted on ingest (duplicates are no-ops; amended versions chain by supersession), parsed and segmented deterministically, then extracted by AWS Bedrock (Claude, version-pinned, temperature 0, zero-retention BAA), one section per call, JSON-schema tool outputs. Nothing an LLM produces is patient-visible until it passes all seven validation gates, including RxNorm/LOINC normalization, deterministic clinical checks, the verbatim source-span proof, and a pinned-embedding semantic pass (DQS-011). Uncertain or conflicting material routes to the clinical review queue, never to a patient. Published facts become tasks through the episode engine, the single writer of state, whose transactional outbox drives every 60-second SLA downstream (notification suppression, brief staleness, caregiver revocation). Two clarifications the diagram compresses: the numbered spine is seven pipeline stages, a different seven from the validation gates that live inside stage 3; and failure paths are explicit, malformed or unparseable documents land in a dead-letter queue with ops alerting (DPC-001) rather than silently dropping, while gate failures route to the review queue with per-gate metrics so a drifting extractor is visible within a day.

PHI handling

TLS 1.2+ in transit, AES-256 at rest under KMS across RDS, S3, Redis, and backups; BAAs with every PHI-touching vendor (AWS/Bedrock, Twilio, SES; error telemetry is PHI-scrubbed by configuration). Notifications carry no PHI, "you have a new task" plus a link is the entire message. Every PHI read, state transition, automation action, and config change lands in the append-only audit ledger (INSERT-only role, 6-year WORM archive); any instruction a patient sees is reproducible to its source span and gate trail in under five minutes.

Integration timeline

Sequenced so development and the pilot never wait on hospital IT, each step is independently useful, and the ADT/FHIR steps can proceed in parallel with paperwork.

StepTypical windowWhat happensUnblocks
0 · FakeEHR (no hospital)Day oneAll development and demos run against the synthetic hospital-in-a-box with the same adapter interface.Every development phase
1 · Document drop~1 weekDischarge packets arrive via secure SFTP/upload; full pipeline runs on real documents. No EHR project required.Pilot ingestion on day one of the partnership
2 · App registration1–2 weeksSMART backend-services client registered in the partner's Epic environment; scopes approved; sandbox keys issued.Steps 3–4
3 · ADT trigger1–2 weeksA03 feed over the site VPN (or the ADR-007 poll fallback if declined); trigger verified against Encounter reads.Automatic episode creation ≤15 min
4 · FHIR reads + UAT2–3 weeksDemographics, med orders, and documents read live; sandbox scenarios replayed with hospital IT; stage soak.Full go-live
5 · Production cutover~1 weekProduction keys, monitoring dashboards, runbook rehearsal, kill-switch drill with the partner.Live episodes

End-to-end: roughly 6–9 weeks of hospital-side elapsed time, most of it paperwork, engineering is never blocked because steps 0–1 carry the build and the pilot's first ingestion path.

See also

The 30-Day Episode, the product-level timeline view of the same system · API specification, the full endpoint catalog · ingestion module, the contract behind this page.