// the find
spencerwozniak/clirc
FHIR R4 JSON parser in C
A C99 FHIR R4 parser/serializer targeting embedded medical devices — think surgical robots and gateway firmware that need to talk to EHRs without pulling in a JVM or Python runtime. It covers three resource types (Observation, Device, Patient) with fixed-buffer, malloc-free operation. Niche audience, but that niche has essentially no good options right now.
Zero-heap-on-hot-path design is the right call for RTOS targets where malloc is either forbidden or unpredictable. Bidirectional round-trip from the same struct definitions avoids the dual-schema problem that plagues most embedded protocol libraries. The codebase is genuinely small (~2K lines across lexer/parser/serializer/validator) — auditable by a single engineer, which matters in regulated medical device contexts. Test fixtures cover the tricky cases like component arrays in blood pressure observations.
Three resource types is a proof of concept, not a library you can ship. The moment you need MedicationRequest, DiagnosticReport, or AllergyIntolerance — all common in actual EHR integrations — you're writing your own parser on top of this. Fixed-size structs for FHIR is a real design tension: FHIR bundles can have arbitrarily deep contained resources and extensions, and static buffers will silently truncate or reject valid data unless you're very careful about limits. One star and no external contributors means no real-world battle testing yet; the parser has almost certainly not seen the malformed JSON that actual EHRs emit. No FHIR profile validation — this parses the base R4 resources but won't catch profile-level constraints that implementation guides require.