Continuous FHIR Conformance Monitoring
Tessara monitors FHIR APIs for specification drift using cryptographic Merkle hash trees and a 6-category drift taxonomy
Why It Matters
Avoid Enforcement Penalties
CMS enforcement actions can result in significant financial penalties. Early detection helps prevent costly compliance failures.
Reduce Audit Preparation Time
From weeks to hours. Cryptographic evidence chain provides audit-ready proof of continuous conformance.
Maintain Patient Trust
Uninterrupted API access means patients can reliably retrieve their health data when they need it.
The Problem: Silent Specification Drift
Your FHIR API passed Inferno testing. The CMS certification is complete. But between now and the next audit, your API will undergo dozens of code deployments, dependency updates, and configuration changes.
Any one of these changes can remove a mandatory element, alter cardinality constraints, or break authentication mechanisms. Tessara complements your existing testing by continuously validating conformance to the Implementation Guide.
Tessara detects these changes by comparing your API's observed structure against the published Implementation Guide specification on a continuous basis.
How It Works: 5-Stage Pipeline
Ingest Specification
Load the published FHIR Implementation Guide (IG) package and build a specification baseline. Every resource type, data element, cardinality constraint, and ValueSet binding is extracted and canonically serialized using RFC 8785 JSON Canonicalization Scheme (JCS).
Output: SpecBaseline (Merkle hash tree with 4 levels: leaf → resource → endpoint → root)
Probe Target API
Query the target FHIR API's CapabilityStatement to discover supported resource types, search parameters, and authentication mechanisms. Retrieve sample instances of each resource type to observe actual structure.
Output: ProbeResult (observed resource structures, self-reported capabilities)
Compare Structures
Build a parallel Merkle hash tree from the observed API responses using the same canonicalization process. Compare the spec baseline tree to the observed tree structurally, identifying divergences at the leaf, resource, and endpoint levels.
Classify each divergence using the 6-category drift taxonomy:
- Cat-1: Mandatory Element Removal (CRITICAL)
- Cat-2: Type/Cardinality Change (CRITICAL/HIGH)
- Cat-3: Structural Extension (INFO)
- Cat-4: Auth/Authorization Deviation (HIGH)
- Cat-5: Endpoint Behavioral Change (MEDIUM)
- Cat-6: Spec Version Mismatch (HIGH)
Output: CompareResult (list of drift findings with category, severity, and spec reference)
Generate Verdict
Produce a signed ComplianceVerdict that maps each finding to the relevant CMS-0057-F regulatory provision. The verdict is signed using Ed25519 cryptographic signatures to prevent tampering.
Output: ComplianceVerdict (signed, timestamped, with regulatory provision index)
Store Evidence
Write the verdict to a hash-linked evidence chain stored in SQLite. Each verdict references the hash of the previous verdict, creating a tamper-evident audit trail. After writing, the system re-reads the record and byte-compares it to the original to verify write integrity.
Output: EvidenceRecord (audit trail with provable non-repudiation)
Technical Specifications
Language & Runtime
Go 1.25+, single binary, zero-config deployment
Cryptography
SHA-256 (Merkle trees), Ed25519 (signatures), RFC 8785 JCS (canonicalization)
Dependencies
2 external (cobra CLI, modernc.org/sqlite), rest stdlib
Storage
SQLite for evidence chain, no external database required
Patent
Provisional patent filed covering core methodology (4-level Merkle trees, specification-anchored baselines)
Testing
309 tests, 81.2% coverage, race-detector clean
Why Tessara Is Different
| Capability | Inferno / Touchstone | Tessara |
|---|---|---|
| Point-in-time testing | ✅ | ✅ |
| Continuous monitoring | ❌ | ✅ |
| Specification drift detection | ❌ | ✅ |
| Cryptographic evidence chain | ❌ | ✅ |
| Regulatory provision mapping | ❌ | ✅ |
| ONC-ATL certification | ✅ (Inferno) | ❌ |
Important: Tessara complements ONC-certified testing tools — it does not replace them. Use Inferno for initial certification, Tessara for continuous post-deployment monitoring.
CLI Commands
# Generate specification baseline from FHIR IG
tessara baseline spec.tgz
# Probe target API
tessara probe https://api.example.org/fhir
# Run full 5-stage pipeline
tessara check --spec spec.tgz --target https://api.example.org/fhir --key signing.key
# View evidence chain
tessara evidence list
tessara evidence show <verdict-hash>
tessara evidence verify <hash>