FHIR Resource Validator

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.

Three Practical Validation Workflows

The most common workflow follows a v2-to-FHIR conversion: after mapping a synthetic ADT^A01 message into a Patient and Encounter with the v2-to-FHIR Mapper, paste the resulting JSON straight into this validator to confirm the mapper's output is structurally sound — required fields present, dates in ISO-8601 form, status codes drawn from the right value set — before it ever reaches a sandbox FHIR server.

A second workflow is debugging a server rejection. When a FHIR endpoint returns a generic 400 error for a synthetic Observation resource, pasting the same JSON here usually pinpoints the cause in seconds — commonly a missing code element, a status value like "done" instead of the required "final", or an effectiveDateTime written in a non-ISO format.

A third is validating a batch import before it runs. A transaction Bundle assembled by hand from several synthetic Patient and Observation entries can be pasted whole; the validator recurses into every entry and reports a bad one — say, entry 3 missing its Observation.status — at its exact path, so the one broken record in a batch of twenty does not need to be found by trial and error.

Fully Validated Resource Types at a Glance

Structural, cardinality, data-type, and value-set checks are implemented for eight resource types. Anything outside this list still parses, but only receives a basic resourceType presence check:

Only JSON input is accepted, matching how most current FHIR R4 integrations exchange data; XML resources are not parsed.

Local Processing and HIPAA-Regulated Workflows

A Patient or Observation resource routinely carries a name, a medical record number, and clinical detail — protected health information under HIPAA. Uploading that JSON to a server-based validator, even a well-intentioned one, creates the kind of data-sharing risk that typically needs a business associate agreement to cover. Because this validator runs entirely in the browser's JavaScript engine, an integration engineer can paste a real (not just a synthetic) resource while debugging a live interface and know the PHI in it never left their machine — no fetch call, no logging, nothing to disclose in a security review.

Working Alongside Other FHIR and HL7 Tools

This validator is one stage of a larger v2-to-FHIR migration workflow. Convert a raw HL7 v2 message with the HL7 v2 to FHIR Mapper, then validate the resulting resource here before it reaches a server. If the original v2 message needs closer inspection first — for example to confirm which segments and fields the mapper actually read — the HL7 Viewer renders the same message as a structured, named tree. Chaining the three tools turns "does my mapped FHIR resource work?" into a fast, private, three-step check.