Guide · BridgeLab
Validate FHIR resources offline, and know exactly what is checked
Open a FHIR resource or a Bundle in BridgeLab, in JSON or XML, and get a per-element report on your own machine. The resources you open are never uploaded: validation runs entirely locally, on Windows, macOS and Linux.
Most tools answer with a green check. This page tells you, before you download anything, what that check covers and what it does not.
What is checked
- Always
- The file is well-formed JSON, resourceType is present and known, and meta.profile is syntactically valid.
- Against profiles
- Cardinality, element types, choice elements, fixed values, unknown elements, primitive formats and Bundle references — against the FHIR R4 core shipped inside the binary and any installed FHIR NPM package, for every profile declared in meta.profile.
- Inside Bundles
- Every entry[].resource is traversed and reported under its own path, not just the Bundle wrapper.
- Rules you define yourself
- JSON plugin packs add your own FHIR checks — a FHIRPath invariant, or a FHIRPath selector plus a check — without running any code. Every pack kind works in the free core; up to three can be active at once.
- When a profile is missing
- A profile declared but not installed produces an explicit warning — never a clean result.
What is not checked
- Terminology
- Code systems and value sets are out of scope by design. A code that is syntactically valid but semantically wrong will pass.
- Dependencies of other packages
- The FHIR R4 core ships inside the binary, so profiles deriving from it work on a fresh install with nothing to download. Packages beyond the core must be installed, and the dependencies they declare are not fetched for you.
- Versioned canonicals
- They resolve by ignoring the |version suffix. If two installed packages declare the same canonical URL, the last one loaded wins.
- Conversion
- BridgeLab does not transform v2 into FHIR. It is a workbench, not a mapper.
Why a product page lists its own limits
Because a validator that overstates what it checks is worse than no validator at all.
We ran into a real case: in a public corpus of integration test fixtures, a Bundle with 33 entries reported zero errors and zero warnings — because the check stopped at the Bundle wrapper and never went inside the entries. It was our bug. We fixed it, and we said so publicly in the thread where the corpus lives.
Read what that green check was actually hiding →Run it on your own messages
Free core under the MIT licence. Windows as installer or MSI, macOS for both Intel and Apple Silicon, Linux as .deb, .rpm or AppImage. BridgeLab also ships a fully supported command-line build, so the same validation runs in a pipeline.
The app reaches the network to activate a licence and pick up its renewal and, if you allow it, to check GitHub for a new version; telemetry is opt-in and off by default. IT can switch off both the update check and telemetry for a whole machine with a policy file.