Architecture
Designed as a controlled interoperability environment
ImOnFHIR separates the lab registry from external FHIR systems so scenarios stay repeatable, observable, and replaceable.
- 01Synthetic Data RegistryControlled payer and scenario fixtures
- 02Scenario EngineExpected PAS / DTR outcomes
- 03Integration AdaptersRead-first EHR / FHIR access
- 04FHIR EnvironmentDisposable projection target
- 05Clinical ContextBounded packages and completeness
- 06Evidence and TracesRetrieval history when persistence is enabled
Source of truth
PostgreSQL holds the canonical synthetic registry: payers, members, coverage, scenarios, projection metadata, and evidence records. The database remains authoritative even when a FHIR server is wiped or unavailable.
FHIR as projection target
HAPI or another FHIR environment receives projected resources for adapter reads. It is an integration target—not the place where lab fixtures are authored or owned.
Adapter-based integration
An EhrAdapter interface isolates read paths. Local HAPI is the first adapter; future sandboxes can plug in without rewriting scenario or evidence models.
Clinical context and evidence
Context retrieval builds bounded packages, reports completeness, and records provenance. Persistence of traces and evidence packages is independently configurable from retrieval itself.