SMART on FHIR app reviewers (the people running app-store-style review programs for SMART apps inside EHR vendor marketplaces) have a validation workload that looks nothing like a developer's IDE pass. The review has to check conformance, scope handling, and data-shape behavior across many apps in a repeatable way, then produce a result that both the app developer and the reviewer can defend. The four validators below hold up to that workflow in 2026. The complete guide to FHIR validators sets the broader frame.
For more reviews of this kind, the rest of our FHIR reviews gather the rest of the validator-focused shortlists.
The Four That Suit App-Review Programs
- Inferno Framework. The ONC-blessed conformance harness, with built-in SMART on FHIR scenarios that exercise scopes, launch context, and data-access patterns. The default starting point for any serious SMART app review program.
- HL7 Java Reference Validator. The reference behavior for the data-shape side of the review. Reviewers use it to check that the resources an app reads or writes conform to the declared profiles.
- HAPI FHIR Validator. The library form used inside the reviewer's own test harness, useful when the review pipeline runs many apps in batch and the per-call startup cost of the reference validator becomes the bottleneck.
- Aidbox $validate. Convenient when the reviewer wants a hosted validation endpoint to point an app at during a sandbox session, with profiles pre-loaded for the target IG.
What App-Review Validation Demands
The data-shape check is the part that maps to standard validation, but it is not the whole job. Three things make SMART app review distinct.
The first is scope and launch verification. A SMART app declares the scopes it requires (patient/Observation.read, user/Patient.write, and so on). The review has to verify that the app behaves correctly when granted those scopes, refuses gracefully when denied, and does not silently exceed them. The top 5 FHIR validators for US Core conformance review covers the data-shape side that pairs with the scope check.
The second is the read-path versus write-path asymmetry. A read-only app needs validation only of the resources it reads; a write-capable app needs additional validation of every resource it creates or updates, against the profile the EHR expects. Reviewers who treat read and write as the same workflow miss real differences.
The third is repeatability. The review has to produce a verdict that any other reviewer would reach against the same app. Validators with deterministic output and machine-readable result formats (OperationOutcome with location pointers) make the review defensible; validators with prose-only output do not.
How an App-Review Program Should Set Up Its Validator Stack
The pattern that works is Inferno as the orchestration layer for the SMART-specific scenarios, with one of the data-shape validators (reference, HAPI, or Aidbox $validate) wired in for the resource conformance checks. The top 5 FHIR validators for $validate REST operations review covers the data-shape REST surface that Inferno integrates with most cleanly.
The honest signal of a working review program is that two reviewers running the same app against the same harness reach the same verdict. Anything else is a process problem, not a tool problem. Reviewers running a high-volume app program should plan for the validator stack to evolve as SMART apps grow in complexity; the right early pick is one that can absorb that growth without a rip-and-replace.
Sources
- Inferno SMART App Launch conformance kit - repo, ONC, evergreen
- Inferno conformance test runner - site, ONC, evergreen
- Inferno redesign announcement - blog, ONC, 2024
