We are FHIR experts.
Billing analytics you can trust starts with clinical data handled properly. 21st Care builds and runs its own FHIR infrastructure — a server, a cleaning pipeline, and a document converter — engineered in Rust with one shared discipline: deterministic output, full provenance, and nothing guessed. This page is the registry.
- FHIR R4 · US Core
- A full R4 surface — 146 resource types served, US Core profiles checked against the official HL7 validator.
- C-CDA R2.1 → FHIR
- 40 section types and 35 resource types converted, every field traceable to its byte range in the source XML.
- Nine terminologies
- LOINC, SNOMED CT, ICD-10-CM, RxNorm, NDC, ATC, CPT/HCPCS, CVX, UCUM — crosswalked with provenance, never guessed.
- Deterministic by design
- Rust end to end. Same input, byte-identical output — no black-box AI anywhere in the data path.
Three products, one discipline.
Every layer of the clinical-data stack — storing FHIR, cleaning FHIR, and getting legacy documents into FHIR — built as its own product, tested against the official conformance suites, and run in production under our analytics.
fhir-server
Server & datastoreA high-performance FHIR R4 server in Rust. Postgres holds the patient graph, ClickHouse holds the time series, and a natural-language planner compiles English questions into the same validated query plan the REST API uses — model output never touches SQL.
- Standard
- FHIR R4 · US Core
- API
- FHIR REST · GraphQL · Bulk $export
- Storage
- PostgreSQL + ClickHouse
- Auth
- SMART on FHIR · OAuth 2.0 · OIDC
- All 146 R4 resource types, served byte-for-byte as stored
- Semantic search over embeddings that never leave the box
- Mirror mode syncs continuously from Epic and Cerner
- Benchmarked head-to-head against HAPI and Medplum
fhir-clean
Cleaning pipelineA serverless cleaning layer that turns messy real-world FHIR into a canonical, analytics-ready record — without ever destroying the source. Every fix is additive and provenanced; stripping the added layers returns the exact original, byte for byte.
- Standard
- FHIR R4
- Transforms
- Terminology · Identity · References · Addresses
- Runtime
- Serverless — S3 → SQS → Lambda
- Guarantee
- strip(clean(x)) == x
- Crosswalks nine ontologies in one precomputed lookup
- Dedupes providers on NPI, organizations by deterministic fuzzy match
- Prefers under-merging — a wrong merge is treated as a safety event
- Milliseconds per bundle warm, scales to zero idle
cda-converter
C-CDA → FHIRConverts C-CDA R2.1 clinical documents into FHIR R4 bundles with a feature most converters skip: every FHIR element points back to the exact byte range in the source XML. Built for real-world documents — malformed XML is recovered and diagnosed, never modified.
- Input
- CDA / C-CDA R2.1
- Output
- FHIR R4 · US Core profiles
- Coverage
- 40 section types · 35 resource types
- Ships as
- Rust crate · CLI · HTTP service
- Byte-level source maps behind every converted field
- Zero conversion errors across the official HL7 example corpus
- Sandboxed core — no network, no filesystem, XXE-safe
- Deterministic output: same document, byte-identical bundle
What clinical and billing data can do together.
The payoff of owning the FHIR stack: our analytics see the clinical record and the billing record as one. Ask about a single patient or a whole population — the answer draws on both, live.
One patient, both sides of the record.
Every claim line in Clarity joins to its clinical events in FHIR on the same account spine. So when a payer denies an echocardiogram for “no prior authorization,” the answer doesn’t stop at the denial code — it finds the authorization sitting in the clinical record, and the appeal writes itself.
21st Care
The payer denied the echo for missing prior auth (CO-197). But the clinical record shows auth PA-2210 attached two days before the study — the denial contradicts the record, and $6,180 is appealable.
Encounter A-4821 — clinical events over claim events
Clinical events from FHIR, claim events from Clarity — one account spine.
Billed
$0
4-day CHF admission
Denied
$0
CO-197 · no prior auth
Appealable
$0
auth PA-2210 · in the FHIR record
Analysis
- Claim lines come from Clarity; encounters, orders, and documents from FHIR — joined on one account spine.
- Auth PA-2210 was attached to the echo order on day 2, two days before the study was performed.
- The appeal cites the FHIR DocumentReference as evidence — drafted and ready to file.
From one patient to the whole population.
The same join, run across a cohort: clinical patterns from FHIR — discharges, documentation, readmissions — correlated with denial and payment patterns from your billing data, so the operational habits that quietly cost money finally have names and dollar amounts.
21st Care
Three patterns explain 81% of denied CHF dollars. The largest — imaging billed before the auth is linked — is a workflow failure, not a clinical one: the auth already exists in 84% of those charts.
Denied dollars by clinical pattern — CHF cohort
Cohort built from FHIR conditions and encounters · dollars from Clarity claim lines.
Patients in cohort
0
heart failure · 12 months
Denied across cohort
$0.00M
8.7% of CHF charges
Recoverable now
$0K
84% of pattern #1 has auth on file
Analysis
- Patterns mined by joining FHIR encounters, conditions, and documents to Clarity claim lines per account.
- Pattern #1 is a linking failure, not a documentation gap — fixing the workflow projects to +$346K a year.
- The med-rec timing pattern concentrates in two discharge units; both are named in the full report.
Put this stack to work on your data.
The same infrastructure behind these products powers every answer in 21st Care. Bring a hard clinical-data problem — a conversion, a cleanup, a query — and we’ll show you how we’d solve it.