FHIR in One Paragraph
FHIR — Fast Healthcare Interoperability Resources — is the modern standard for exchanging healthcare data, developed by HL7 to replace the cryptic pipe-delimited messages of HL7 v2 with clean, web-friendly JSON (or XML). In FHIR, every piece of clinical information is a resource: a Patient, an Observation, a MedicationRequest, a DiagnosticReport, and so on. Resources reference each other and can be bundled together, and they are exchanged over ordinary RESTful APIs. R4 is the most widely deployed version and the one most integrations target today, which is exactly why this validator checks your resources against R4 structural rules.
Why Validation Matters
A FHIR server will reject a resource that does not conform to the standard, and subtle structural mistakes are easy to make by hand or when transforming data from another format. Validating before you send saves a frustrating round-trip and surfaces problems while the context is fresh. Validation answers a precise question: does this JSON match the rules FHIR defines for its resource type?
What This Validator Checks
- Resource type. Every resource must declare a
resourceType. Without it, nothing else can be checked.
- Required fields. Each resource type defines fields that must be present. An Observation, for instance, requires both
status and code; a Bundle requires type. Missing a required field is a hard error.
- Cardinality. Some fields appear once (0..1), others repeat (0..*). Supplying an array where a single value is expected, or vice versa, is flagged.
- Data types. FHIR primitives have strict formats. A
date must look like YYYY, YYYY-MM, or YYYY-MM-DD; an instant needs a full timestamp with a timezone. A number where a date string is expected is caught immediately.
- Required value sets. Certain coded fields may only contain specific codes. An Observation status of "done" is invalid because the allowed set is registered, preliminary, final, and so on.
Errors vs Warnings
Not every issue is fatal. The validator separates hard errors — a missing required field, a wrong data type, a code outside a required value set — from warnings, which flag things that are suspicious but technically allowed, such as a CodeableConcept with neither a coding nor text. Treat errors as blockers and warnings as prompts to double-check intent.
Bundles and Nested Resources
A Bundle is a container that carries other resources, used for transactions, search results, documents, and message payloads. Validating a Bundle means validating each contained resource too. This tool recurses into every entry and reports issues with their full path, so a missing Observation status inside the third entry of a Bundle is pinpointed precisely rather than hidden in the nesting. Because real-world FHIR traffic is so often wrapped in Bundles, this recursive behavior is what makes the validator useful beyond toy examples.
Common Mistakes the Validator Catches
A few errors come up again and again, especially when resources are built by hand or transformed from another format. Dates are a frequent offender: writing a birthDate as "12/05/1990" instead of "1990-05-12" fails because FHIR dates must be ISO-8601. Status codes are another: typing "done" or "complete" where the value set expects "final" is invalid, and the validator lists the allowed codes so you can correct it. Cardinality slips happen when a field that should be a single value is supplied as an array, or a repeating field is given as a bare object. And the simplest mistake of all — forgetting the resourceType property — stops validation before anything else can be checked. Seeing these flagged with the exact element path turns a vague "the server rejected it" into a precise, fixable problem.
The Limits of a Lightweight Validator
This validator is pragmatic, not exhaustive. It covers the common resource types and the structural rules that catch most real-world mistakes, but it does not implement the full FHIR specification, every profile, terminology server lookups, or custom implementation-guide constraints. For formal conformance testing against a specific implementation guide, use the official HL7 validator. For the everyday question of "is this resource structurally sound before I send it?", a fast browser check is exactly the right tool, and it keeps your data private while doing so.