CI/CD Quality Gate
Your CI tests code quality. Records tests data quality. Add FHIR validation to your pipeline as a repeatable gate.
For: IG authors, FHIR dev teams, health-tech engineers, AI agent builders
The problem
Your pipeline validates code. Who validates the data?
You have unit tests, integration tests, linting, type checks — all running on every pull request. But the FHIR data your application produces or consumes? No gate. A mapping change silently breaks conformance. A profile update introduces new constraints that your test data doesn't cover. You find out in production.
IG authors face the same gap: profile changes are published without regression tests against real data. Constraint errors only surface in downstream implementations — weeks or months after the IG release.
And increasingly, AI agents generate FHIR resources at scale — automated mapping pipelines, Claude for Healthcare workflows, MCP-based agents. Without a validation gate, AI-generated output reaches production unchecked.
FHIR data without quality gates is untested code.
How Records solves it
A conformance gate in your pipeline — red/green on every PR.
Records treats data quality like code quality. Your CI pipeline already runs unit tests, linting, and type checks. Records adds FHIR conformance as another gate: structural validation, profile conformance, terminology binding checks, reference integrity, invariant evaluation, custom rules, metadata validation, and anomaly detection — the 8 validation aspects — run on every PR. The engine is pure TypeScript — no JVM, no Java cold start, and designed for low startup overhead. It runs anywhere Node.js runs: CI runners, Docker, edge environments.
Every PR triggers a validation run. The run history tracks conformance across all PRs — pass, warn, or fail. Baseline markers show the reference point for delta comparison.
For IG authors: Records validates your implementation guide against a test corpus on every pull request. Profile changes are regression-tested against real data before publication. Constraint errors surface in the PR, not in downstream implementations weeks later. The same validation workflow is planned for an MCP server so AI-assisted FHIR development can get validation feedback without leaving the authoring workflow.
When a check fails, drill into issues grouped by validation aspect — structural, profile, terminology, metadata — to find the root cause.
Select an issue to see affected resources and field-level errors. Create triage actions directly from the investigation view.
Pure TypeScript — no JVM
No Java runtime and no Java cold start. Designed for CI runners, Docker, and edge environments.
8 validation aspects
Structural, profile, terminology, reference, invariant, custom rules, metadata, anomaly — all configurable per project.
PR-level delta
Every PR is compared against the test baseline. New conformance errors block the merge. Resolved errors are tracked.
AI agent integration
Planned MCP server integration gives AI agents that generate FHIR validation feedback in the same workflow.
How to integrate
Add FHIR validation to your CI pipeline as a single CLI step.
GitHub Actions
# .github/workflows/fhir-validation.yml
- name: FHIR Validation Gate
run: npx @records-fhir/cli validate \
--server=$TEST_FHIR \
--ig=<project-IG>IG Author (local corpus)
records validate \
--ig=./ \
--corpus=./test-corpus/ \
--baseline=latestWhat gets pinned
| Pin | Purpose |
|---|---|
ig_packages | Profile versions pinned per branch |
validator_version | Same engine across all PR runs |
thresholds_applied | Pass/fail criteria consistent across PRs |
environment_label | Separates PR test runs from staging/production |
Run via npx — no global installation required. Works with GitHub Actions, GitLab CI, Azure Pipelines, or any CI system that runs Node.js. No server-side deployment required for the CI gate — the CLI connects to your test FHIR server directly.
What you get
PR conformance gate
Red/green check blocks non-conformant changes before merge.
Pure TypeScript — no JVM
No Java runtime and no Java cold start. Runs in CI environments with Node.js.
Root-cause drill-down
From PR check to specific resources and field-level errors.
Per-environment baselines
Delta on every PR against test baseline, on every deploy against target.
MCP server for AI agents
Planned Model Context Protocol integration for AI agents that generate FHIR.
IG regression testing
Validate your IG against a defect corpus on every PR. Catch constraint errors before publication.
Data quality deserves the same rigor as code quality
Your pipeline gates code changes. Why not data changes?
| Without Records | With Records CI gate | |
|---|---|---|
| FHIR conformance testing | Manual, after deployment | Automated, on every PR |
| Regression detection | errors found in production | Delta against baseline on every PR |
| Time to integrate | Days/weeks of custom scripting | One CI step via npx |
| IG authoring feedback | Weeks (downstream implementers report) | Minutes (PR check fails) |
| Evidence trail | Per-PR validation report with reproducibility | |
| AI agent validation | Not supported | Planned MCP integration for AI-generated FHIR |
Frequently asked questions
The CLI workflow is a single CI step: npx @records-fhir/cli validate --server=$TEST_FHIR --ig=<project-IG>. No separate server deployment is required for basic file validation; full baseline and evidence workflows connect to a Records instance.
The CLI can run standalone for basic validation. For delta comparison, baseline tracking, and evidence reports, it connects to a Records instance (SaaS or self-hosted).
Yes. Use --ig=./ to point at your local IG directory and --corpus=./test-corpus/ to validate against a set of test resources. This is how IG authors use Records for regression testing.
The CLI workflow is designed for any CI system that runs Node.js: GitHub Actions, GitLab CI, Azure Pipelines, Jenkins, CircleCI, and Bitbucket Pipelines.
Records produces a pass/fail signal as a CI check result. Whether that check is required to pass before merge is configured in your CI system's branch protection rules — Records does not impose policy.
Talk to us about CI/CD validation.
Share your context, question, or integration idea. We'll help you identify the right next step.