Clinical pathways as governed infrastructure
Define a pathway once as a state machine over FHIR resources. Version it, review it, sign it, run it, and keep the evidence that it ran.
A lifecycle with real states
A pathway version moves draft, review, active, deprecated, retired. Only one version is active at a time, enforced at the database. Retiring a pathway with runs still in flight fails closed instead of stranding them.
- Every version is immutable and checksummed
- Roll forward or back without touching backend code
Sign-off is the publish
Recording a sign-off is what promotes a version to live. The immutable version is written, the registry flips and configuration is republished in one transaction, in that order.
- The signer is a named person, with full history
- Approval is the mechanism inside the system, not a process around it
Evidence, not log archaeology
Every run assembles into a timeline from FHIR AuditEvents. Export any run as a JSON evidence bundle, and any pathway as a QMS export.
- Timelines show what changed and what caused it
- Shaped the way quality and regulatory teams already work
Run it anywhere, read it by anyone
Runs on any FHIR system
One pathway executes against any FHIR R4 server, alongside legacy sources and external APIs, without a bespoke integration per site.
Readable by clinicians
Each pathway renders as a state diagram and a plain-language description, with no YAML. The people who sign off can see what they are signing.
Built for review
Versioned execution and QMS export give quality and regulatory teams a record they can review without a translator.
Ready to stop rebuilding clinical logic you have already written?
Walk through your integration surface with us and see what a versioned, signed-off pipeline would look like in your environment.