FHIR R4 · No migration

Your database
already speaks
FHIR.

Fhirlace laces an existing healthcare database into the FHIR fabric — without moving a single row. Connect it, review the mapping, and serve a full FHIR API from the data you already have.

0rows migrated
5SQL engines
1reviewable file
patients → Patient
SQL ROW
mrn MRN001
sex 'M'
dob 1988-04-12
org_id 1
deterministic engine
FHIR PATIENT
"identifier":"MRN001"
"gender":"male"
"birthDate":"1988-04-12"
"managingOrg":"Org/1"
BOUND sex 'M' → administrative-gender male · validated, reversible
How it works

AI drafts the mapping.
A human approves it. The engine never guesses.

Fhirlace runs the model once, at setup — never at request time. What serves your data is a deterministic engine reading one reviewed file, so the same row always produces the same resource.

PHASE 01 · DESIGN TIME

Read & understand

Fhirlace introspects the schema, profiles every column for data-quality caveats, and infers relationships. The AI proposes a FHIR mapping — with a confidence score on each field.

tables · views · types · caveats · inferred keys
PHASE 02 · REVIEW GATE

Human sign-off

Low-confidence fields are flagged. Nothing serves live data until a reviewer approves it. Automated mapping isn't accurate enough to trust blindly — so we don't.

◈ clinical review required
PHASE 03 · RUNTIME

Serve FHIR, both ways

A stateless engine answers FHIR REST calls straight from your database, and writes FHIR back into the existing schema. No copy, no drift, fully auditable.

read · search · write · Bundle · deterministic
Capabilities

Everything a FHIR façade needs
to stand in front of a real database.

Built from the ground up as bidirectional, terminology-aware, and auditable — the parts a naïve converter skips.

Any SQL database

PostgreSQL, MySQL/MariaDB, SQL Server, Oracle, SQLite — introspected through one universal connector.

Bidirectional by design

Read as FHIR, write FHIR back. Every transform carries an inverse, and non-reversible fields are read-only by construction.

Real terminology

Bare codes become validated CodeableConcepts — LOINC, ICD-10, SNOMED — with locale-aware display and cross-system translation.

Full FHIR REST

Read, search, create, update, delete, Bundle transactions, _include and CapabilityStatement.

Safe writes

Dialect-aware upserts into the existing schema, with read-before-write conflict detection so concurrent edits never silently clobber.

Drift detection

Fhirlace fingerprints the schema and tells you the moment it changes — so the FHIR surface never silently falls out of sync.

What sets it apart

The two things naïve converters get wrong.

Terminology, both directions

A code isn't a string.

Storing J06.9 and emitting "J06.9" is structurally valid and clinically useless. Fhirlace resolves codes to full CodeableConcepts — and can serve them in the system an Implementation Guide demands, losslessly translating back on write.

stored (ICD-10) J06.9
served (SNOMED) 54150009 · "Upper respiratory infection"
written back J06.9 ✓ lossless
Human in the loop

The review gate is the point.

Automated schema-to-FHIR mapping tops out around 70% accuracy and hallucinates plausible-but-wrong mappings. So Fhirlace treats human review as a first-class stage — not a formality — with a promotion gate no mapping can skip.

draftneeds reviewapproved

low-confidence field detected → blocked until sign-off

Get started

Point Fhirlace at a database.
Watch it speak FHIR.

A connection string is all it needs to introspect, profile, and draft a mapping. You review; it serves.