How to validate FHIR Resources like a boss (2026 edition)

Are you building invalid resources that produce low quality content, and are your customers seeing issues in their FHIR servers and complaining?

In this blog, we dive into the world of FHIR validation. Our focus here is how FHIR validation is used both for standards development and for real-world FHIR implementations, across the full lifecycle: from blueprinting a specification, to building systems, to runtime operations.

What do we actually mean by “FHIR validation”? 

FHIR validation is about much more than running a single command and looking for a green checkmark. At different moments in a project, you’re validating different things, with different goals:

• When you’re designing a specification, you validate your conformance resources (StructureDefinitions, ValueSets, CodeSystems, ImplementationGuides, etc.)
• When you’re building and testing a system, you validate instance data against those profiles
• When you’re in production, you validate traffic and payloads to ensure safe interoperability over time

A good mental model is to think in layers:

1. Syntactic correctness and schemas
2. Conformance to the FHIR specification (base resources, cardinalities, bindings, invariants)
3. Conformance to your own profiles and terminology
4. Conformance to your business rules and implementation guidelines

Different tools and approaches shine in different layers. The rest of this article walks through those layers and points you to the matching Simplifier.net features and companion tools.

Validating resources for standards development

If you’re defining a FHIR standard or implementation guide, your raw material is conformance resources: StructureDefinitions, SearchParameters, ValueSets, CodeSystems, CapabilityStatements, ImplementationGuides, and so on. Designing these by hand in XML or JSON is possible, but not recommended.

Authoring with live validation 

The first line of defense is to use tooling that prevents many errors at authoring time: 

• Forge, the graphical profile editor, provides live validation as you design profile
• FHIR Shorthand–based workflows can be edited and validated in the Simplifier Resource Editor and in external FSH toolchains

Even with that help, design errors and edge cases inevitably slip in. That’s where project‑level and bulk validation come in. 

Schema and structural checks

For low-level structure and format, you can still use XML/JSON schemas and schema-aware editors. The FHIR specification publishes schemas for each release, and many tools rely on those under the hood. They cover: 

• Basic element structure and order
• Required elements and cardinality
• Primitive types and simple constraints 

In practice, this kind of schema validation is more useful as part of your tooling stack than as a tool you run directly every day. Modern validators (including Firely’s) go well beyond what schemas can express.

Semantic validation with dedicated validators 

The second line of defense is semantic validation with one or more FHIR validators. Most of the FHIR ecosystem relies on: 

• The Firely .NET SDK validator (new generation)
• The HL7 Java validator 

Simplifier.net and Firely Server both use the .NET validator by default, and you can now explicitly choose between multiple validator “flavors” in Quality Control and the Validation Playground: 

• The new Firely .NET SDK validator (“firely”) 
• The legacy .NET validator (“netsdk”) 
• The HL7 Java validator (“java”)

This gives you a way to compare behaviors or align with external toolchains that depend on a specific validator. 

Below are four ways to validate your work on Simplifier.net, updated for today’s feature set. 

A) Copy‑paste validation: the fastest sanity check 

When you have a single resource, you want to sanity‑check—something you just tweaked in an editor, or a payload from a log—copy‑paste validation is still the simplest starting point. 

1. Go to the online FHIR validator (the Validation Playground)
2. Paste your FHIR resource (XML or JSON)
3. Select:
   • The FHIR version
   • The validation scope (core spec, a Simplifier project, or a published package)
   • Optionally, the validator flavor (Firely, legacy .NET, Java)
4. Run validation and inspect the results

By default, the validator checks against the core specification. Scoping the validator to a project or a published FHIR package gives you a stable, well‑defined context — ideal when validating against national or organizational IGs. 

The UI has grown up since the original version of this blog post, but the core ideas remain: 

• Filter by severity (errors, warnings, information)
• See corresponding validator error codes, which link to documentation
• View inline results in your XML or JSON where issues are directly annotated on the resource
• Experiment with different validator engines to see how they behave on tricky edge cases

This is a perfect tool for quick feedback during specification design, debugging odd payloads, or exploratory validation during development. 

B) Snippets: your FHIR sketchpad and shareable test bed 

Snippets are your sketchpad for FHIR resources, but they’ve become more important as validation workflows evolved. 

A snippet lets you: 

• Paste or author any FHIR resource without committing it to a “serious” project
• Render, validate, and revise the resource as often as you like
• Share a direct URL with others, giving them XML, JSON, and rendered views and direct access to validation results

This is particularly handy in collaborative debugging or design sessions: you can point a colleague to a snippet that shows both the problematic resource and the validation outcome, without cluttering your main projects with half‑finished experiments. It’s also a convenient feature to quickly convert your resources from XML to JSON and vice versa. 

In the context of “Mastering FHIR validation,” snippets are an ideal place to play with different validator flavors, to try out FHIRPath‑based constraints, or to reproduce issues seen in production without exposing real patient data.

C) Single-resource validation within projects: keeping your IG clean 

Once you’re serious about a specification, you’ll want validation to be part of the routine workflow on your Simplifier projects. 

For every FHIR resource in a project — public or private, conformance or example — you can: 

• Open the resource detail page
• Run validation in the context of the project and its dependencies
• See issues, severities, and locations directly linked to the resource

The validation context is defined by: 

• All content in the project itself
• Its declared package dependencies (e.g., the FHIR core package, national base packages, or organizational base profiles)

This is where you ensure that: 

• Profiles are well‑formed and correctly derived
• Examples actually conform to the profiles they claim in meta.profile
• Canonical URLs and references resolve as expected

Per‑resource validation is your bread‑and‑butter during authoring. But as your specification grows beyond a handful of resources, clicking “validate” one by one becomes tedious and error‑prone. That’s exactly why bulk validation and Quality Control were introduced. 

D. Bulk validation with Quality Control: validating full specs in one go 

Bulk validation is here now — and it’s much more than a button that runs validation on all resources. 

Simplifier.net’s Quality Control (QC) engine lets you: 

• Run bulk FHIR validation over your entire project, in one click
• Choose from default rulesets:
  • – Minimal rules (including bulk resource validation and uniqueness of canonicals)
  • – Recommended rules (Firely’s opinionated checklist of quality best practices)
• Define your own custom rule files in YAML, tailored to your organization’s profiling guidelines
• Execute the same rules locally via Firely Terminal, Forge or in CI/CD pipelines 

A QC ruleset can combine: 

• Parsing checks (can all FHIR files be parsed?)
• Validation against the FHIR standard and profiles
• Uniqueness and consistency checks (e.g., canonical URLs, ids, names)
• FHIRPath predicates that encode your business rules (e.g., canonical patterns, publisher and contact policies, naming conventions)
• Optional switches to choose the validator flavor per action (Firely, legacy .NET, Java, and soon, even the IG Publisher)

The result is a unified “publication readiness” view: a structured list of issues that must be addressed before you ship your IG, with the option to store those issues in the project’s issues tab and link them into your review process. 

This is the concrete manifestation of “business rules validation” layer: your organization’s implementation guidelines encoded as executable checks.

Validating at runtime: Firely Server and $validate 

Authoring‑time validation is necessary but not sufficient. In production, you want to protect your systems by validating incoming and outgoing resources at runtime. 

Firely Server includes: 

• A $validate operation at:
  • – System level: POST $validate with a resource or Parameters body
  • – ResourceType level: POST <ResourceType>/$validate
  • – Instance level: GET <ResourceType>/<id>/$validate
• Configurable validation for all incoming resources on create/update:
  • – Off / Core / Full validation levels
  • – Optional profile whitelists via AllowedProfiles
• An evolving set of advanced rules (e.g., for ElementDefinition, StructureDefinition, QuestionnaireResponse) and Advisor Rules for post‑processing validation outcomes

This lets you: 

• Enforce that all data entering your system is at least FHIR‑valid (Core), and often also profile‑conformant (Full)
• Implement stricter validation for specific use cases (e.g. prior authorization, quality measures)
• Shape the validation outcome downstream by overriding or suppressing specific issues when appropriate 

From the perspective of the validation lifecycle, Firely Server sits in the resource validation and integration/end‑to‑end phases: it’s your safety net when real data starts flowing. 

Learn more about validating incoming FHIR resources in the Firely Server documentation.

Other tools in your validation toolbox 

Beyond Simplifier.net and Firely Server, several tools complement your validation workflows. They each target a different niche; the art is knowing when to reach for which. 

Firely Terminal 

Firely Terminal is a cross‑platform command‑line tool that supports validation among many other FHIR tasks. It’s particularly useful when you want to: 

• Run Quality Control rulesets locally, for example on a git working copy
• Integrate validation into build scripts and CI/CD pipelines without manual clicks
• Script bulk validation across folders, packages, or server endpoints. 

It’s “zero‑click” validation that runs every time you change your specification, not just when you remember to open a web UI.

FHIRPath testers 

FHIRPath expressions power a lot of validation behavior in profiles, questionnaires, and Quality Control rules. When those expressions get complex, a dedicated tester is invaluable.

You can: 

• Use web‑based FHIRPath testers to iterate on expressions. The two most valuable FHIRPath testers are:
  • – Simplifier’s FHIRPath Playground which allows you to select or paste a FHIR resource from any project or package and allows you to test your FHIRPath expression against it
  • – Brian Postlethwaite’s fhirpath-lab, which has access to many different FHIRPath engines, so you can test for cross-platform interoperability
• Copy resources from Simplifier or Firely Server and test your predicates on realistic data
• Transplant the final expressions back into invariants, QC rules, or code

Getting FHIRPath right is often the difference between “validation mostly works” and “validation encodes exactly what our domain experts meant”. 

Firely .NET SDK 

While developing code for FHIR data flows, you can use the built-in FHIR validation of your code library. For example, Firely’s .NET SDK and associated tools validate as they generate or transform conformance resources. This ensures that no invalid data will pass through your app to wreak havoc on your beautiful user interfaces. 

Putting it all together

FHIR validation is not a single button you hit at the end of a project. It’s a continuous thread that runs through the entire FHIR lifecycle: 

• In the blueprint phase, you use Forge, the Simplifier editor, per‑resource validation, and Quality Control to design and harden your specification.
• In the development and testing phase, you use copy‑paste validation, snippets, project validation, and Firely Terminal to validate instance data and catch issues early.
• In the integration and runtime phase, you rely on Firely Server’s $validate and incoming validation to protect your systems and your users.
• Throughout, you encode your organizational rules as Quality Control checks and FHIRPath predicates, so that “best practices” become executable, repeatable tests rather than tribal knowledge. 

Hopefully, you now feel equipped with the updated ways to validate your FHIR work on Simplifier.net—copy‑paste, Snippets, Projects, and full‑blown Bulk validation via Quality Control—and with a better mental model for how the broader toolset fits together. 

If you want to go deeper, watch the “Mastering FHIR validation: tools and best practices” session from DevDays 2025 and start mapping its concepts directly onto your own projects.