The governance layer for healthcare data.
quovana helps healthcare organisations control how their data is defined, changed and used, and keeps trustworthy evidence of what happened. Built for the clinical and quality teams who own the meaning of the data, not only the engineers who move it.
Tested live against public FHIR terminology servers (R4 and R5) · IHE ATNA-aligned audit model · Self-contained, runs on-premises
Governed capabilities, not standalone tools.
Terminology governs what your data means. Audit proves what happened to it. They are one application and one isolated deployment per customer: one sign-in, one licence that decides what you see, and one evidence store. Every change Terminology records becomes an event Audit seals into its tamper-evident chain. These are the first two.
Terminology Live
Govern what your data means. Author, map and publish code systems, value sets and concept maps, with a managed FHIR terminology server built in. Every version keeps its history, published versions stay fixed, and where you require it, nothing publishes without an approval on the record.
Audit Early access
Prove what happened. Search, monitor and retain your organisation's FHIR audit trail across the whole estate, as a sealed record you can hand to an assessor, where a change to the record can be detected.
Your systems send back the record of who accessed what.
Regulation is forcing the timeline, starting in Europe.
The EU's EHDS Regulation (2025/327) mandates the EEHRxF for EHR systems placed on the EU market. Its technical specifications, adopted via implementing acts, are HL7 FHIR-based and use standardised terminologies such as SNOMED CT, LOINC and ICD. Conformity is a condition of market access. The same pressure is building beyond the EU, from the US 21st Century Cures Act and ONC HTI-1 rule to national FHIR mandates elsewhere.
EHDS Regulation enters into force
EHDS applies; EEHRxF specs expected
First categories: patient summaries, e-prescriptions
Imaging, lab results, discharge reports
Governments give away terminology servers, but leave map ownership, quality and lifecycle open. quovana is that layer.
Terminology your team owns, reviews and publishes.
Create, review, approve and publish your local code systems, value sets and mappings, with a full version history. Built for the clinical, quality and terminology teams who own the meaning of the data, and for the EHR and LIS vendors who have to answer for it.
Your maps live in a spreadsheet nobody approved.
Local lab and diagnosis codes get mapped to SNOMED CT, LOINC and ICD in a spreadsheet with no version history, no reviewer, and no record of who changed what. When a code shifts, results flow on a mapping no one owns. And when an accreditation body asks who approved it and when, assembling that by hand is slow and rarely provable.
Where you require review, a mapping goes live only once an independent reviewer has approved that version. Published versions stay fixed; editing later starts a new version, which goes back through the same route. Every create, submit, approve and publish is recorded as a FHIR AuditEvent, and a governance report gives you the full review trail per published version, with the independent-review indicator and any self-approval exceptions, exportable for an auditor.
The people who know the codes can't touch the system.
The staff closest to the local codes, the lab lead, the quality manager, work in Excel, not FHIR. Authoring bottlenecks on a handful of engineers while the domain experts are reduced to sending spreadsheets.
A spreadsheet becomes a governed draft in one paste, with every row classed new, duplicate or invalid before anything is created. A restricted Contributor role lets partner sites and non-FHIR staff author codes without the power to publish them; their work goes to a named reviewer. Authorship is recorded as FHIR Provenance, so every contribution carries who made it.
You have to report in SNOMED CT. Your results come out in local codes.
EHDS drives EU reporting toward FHIR specifications built on standardised terminologies such as SNOMED CT, LOINC and ICD. The work that lands on you is the mapping: which local code means which SNOMED concept, who approved it, and whether it still holds. And hosting licensed editions across every silo is a burden most teams cannot carry.
quovana is where that mapping is governed. Connect your own terminology server and map straight against the live SNOMED edition, storing only the chosen code. Bring in just the slice your reporting needs as a governed, versioned value set. A managed FHIR terminology server is built in, so published content is ready for machines and registries to consume under the same governance. It is evidence toward your reporting obligations, not a substitute for them. Your affiliate relationship, and your certification, remain yours.
From spreadsheets nobody signed off to terminology that is reviewed, versioned and ready for your systems to use.
See it on one of your own mappings →
See who accessed what, and when.
The FHIR-native evidence layer for your whole health-data estate. One place for compliance leads, quality managers, DPOs and CISOs to search, monitor, retain and prove who did what to which record, and whether that proof can itself be trusted. Audit is in early access and available for design-partner pilots.
"We have logs, so we're covered."
A system log tells you what happened inside one system. It scatters across servers, rotates after 30 days, and was never built to answer what a regulator asks: who accessed which patient or specimen, when, and whether it was authorised.
quovana Audit reads the FHIR AuditEvent and Provenance records across your estate into one org-wide Explorer. Every access becomes attributable evidence you can filter by actor, patient, object, action and outcome, and follow as a single record's chain of custody, read from the source of truth rather than reconstructed from raw logs.
Could an administrator erase the evidence without you knowing?
That is the real test of an audit trail, and most fail it. If a privileged operator can rotate, overwrite or quietly edit the record, you have a log, not defensible evidence. An auditor's threat model includes the insider with database access.
Every event is cryptographically sealed into an append-only hash chain, and altering a sealed event breaks the seal. An administrator with database access cannot quietly rewrite an event. The chain head can additionally be signed with a key held outside the application, and committed to write-once storage, where a deployment requires it. We proved it live: with chain-head signing and write-once anchoring enabled, a database-privileged tamper of the sealed chain was caught by verification, and the anchored record could not be deleted or shortened.
An algorithm screened the slide. Nobody recorded who checked it.
When an algorithm screens a slide before a report is signed, accountability gets hard. Which model and version ran, on which object, and did a human assess the result before it reached the report? Existing audit standards were built for data access, not the AI-inference trail, so generic access-audit and SIEM tools can't model it.
The AI Inference Trace reconstructs each AI episode as evidence: the model, its version and device, the object it ran on, and the human assessment, or a flagged gap where none exists, before sign-out. Unassessed results and failed inferences surface as findings. This supports EU AI Act record-keeping (Art 12) and human-oversight (Art 26) duties. An early capability: the trail's completeness depends on models being registered, and it describes what the trail captures today, not a compliance guarantee.
Proving it shouldn't take three weeks of screenshots.
When a regulator, accreditation body or data-subject request arrives, evidence assembled by hand is slow, contestable, and only as trustworthy as whoever compiled it. Most teams have no defensible answer for how long evidence is kept, or how it is disposed of.
Findings for break-glass, denied access, bulk export and unassessed AI open automatically for triage. Integrity-verified reports freeze a self-hashed snapshot of the period: who accessed what, broken down by actor and by subject, with the tamper-evidence verdict stated rather than assumed. One report is produced, framed to the standard you report against (EHDS, ISO 15189, GDPR or HIPAA), exportable as PDF or CSV. Retention posture and legal hold are built in, and disposal is designed to be provable: a purged record verifies as retention-expired rather than silently vanishing.
A record you can hand to an assessor, built from your own FHIR data, where a change to the record can be detected.
See it on your own audit trail →
Why the record holds up.
You can tell if a record was changed
Every event is sealed into an append-only hash chain, with optional external-key signing and write-once anchoring where a deployment requires it. Even disposal is designed to be provable: a purged record verifies as expired by policy rather than silently vanishing.
Runs as a self-contained stack on your own network
No hard dependency on external cloud. Your data, your terminology licences, your estate.
- FHIR-native end to end
- Existing FHIR sources normalised at the boundary
- Evidence targets: EHDS, ISO 15189 and GDPR
- AI Inference Trace: EU AI Act record-keeping
- Certification always remains yours
Start with one real use case.
We’ll walk you through quovana on one real mapping or audit need of yours. If it fits, the next step is a fixed-fee pilot, governed end to end, with the trail to show for it.
Rather just write to us? [email protected]