FHIR without migration: making an existing database speak FHIR.
How Fhirlace serves a hospital's current database as a FHIR R4 API, using AI to draft the mapping once and a deterministic engine to run it.
Why migrations stall
Most interoperability projects start by copying everything into a new store. That means months of extraction, a second copy of sensitive data to secure, and two systems drifting apart from the day they go live. Many hospitals, especially mid-sized ones, never finish.
AI at design time
Fhirlace connects to the existing database (PostgreSQL, MySQL, SQL Server, Oracle and others) and profiles its schema and sample values. An AI mapper proposes how tables and columns map to FHIR resources such as Patient, Encounter and Observation, with a confidence score for each field. The result is a readable mapping file, not generated code.
A human approves before anything is live
Low-confidence fields are flagged for review, and nothing serves live data until a person approves the mapping. Published research on LLM-based FHIR mapping shows meaningful error rates, so treating the AI's output as a draft is a requirement, not a nicety.
Determinism at runtime
In production, no model is in the request path. A deterministic engine interprets the approved mapping in both directions: database rows become FHIR resources, and FHIR writes become database updates. The same request always produces the same response, which is what auditors and integrators need. Schema drift detection warns when the source database changes underneath the mapping.
Key takeaways
- 1Translate in place instead of copying data into a second store.
- 2Use AI where it is cheap to check (a mapping file) and keep it out of the request path.
- 3Bidirectional mapping lets FHIR apps write back, not just read.