About Tessara
Making FHIR API conformance visible, continuous, and provable
Our Mission
Tessara exists to answer a question that shouldn't be hard to answer: does this FHIR API still conform to its published specification?
Healthcare payers operating under CMS-0057-F (and its predecessor CMS-9115-F) must deploy five FHIR APIs — four under CMS-0057-F plus the CMS-9115-F Provider Directory — by January 1, 2027. Most will pass initial certification using tools like Inferno. But between certification and the next audit, those APIs will undergo dozens of code deployments, dependency updates, and configuration changes — any of which can introduce specification drift.
Existing conformance testing tools operate at a single point in time. Tessara operates continuously, detecting drift before it becomes an enforcement issue.
What "Tessara" Means
The name Tessara comes from the Latin tessera, which has three historical meanings that map directly to what the product does:
- A mosaic tile. Each tessera is a small, precise piece that contributes to a larger structural pattern. In Tessara, every node in a Merkle hash tree is a small verification unit that composes into a complete structural proof.
- A token of authentication. In Roman commerce, a tessera was a physical token presented as proof of identity or authorization. Tessara generates cryptographic evidence that an API's observed structure matches its published specification.
- A proof of identity. Beyond commerce, tesserae served as identity markers — proof that something is what it claims to be. Tessara answers the same question about FHIR APIs: does this endpoint's actual structure match the identity it claims through its specification?
The Evolution: Silent Drift → DriftGuard → Tessara
The product passed through three names, each reflecting a stage of understanding:
- Silent Drift named the problem: APIs that silently drift from their published specifications without any party detecting the change.
- DriftGuard named the solution category: a tool that guards against specification drift by continuously monitoring.
- Tessara names the identity: cryptographic proof through structural verification. Not the problem, not the category, but the specific thing this product is.
Why We Built This
Healthcare interoperability has been "coming soon" for decades. CMS-0057-F is different — it has an enforcement date (January 1, 2027) and real consequences for non-compliance. Over 5,000 payers must implement five FHIR APIs that weren't required before.
The compliance industry's answer to new regulations is typically: pass the test once, hope nothing breaks. Tessara's answer is: monitor continuously, detect drift early, provide cryptographic proof.
We believe healthcare deserves better than point-in-time certification. Continuous conformance monitoring should be the standard.
Team & Company Stage
Tessara is a pre-revenue startup currently in pilot phase. We're transparent about this stage because honesty builds trust.
Current Stage
We're working with select healthcare payers to validate the product before broader market launch. Our technical implementation is production-grade (88%+ test coverage, zero test failures, live-tested against 146 FHIR resource types), but we're early-stage as a company.
What This Means for You:
- Risk: Vendor stability questions (addressed via on-premises deployment option and source code escrow for Enterprise contracts)
- Benefit: Direct influence on product roadmap and pilot-phase pricing
Leadership
Tessara is built by a small team with deep experience in healthcare interoperability, FHIR standards, and cryptographic systems.
We're hiring. If you're interested in working on healthcare compliance tools at the intersection of FHIR, cryptography, and regulatory enforcement, get in touch.