Time for what matters
Agentic AI at the Point of Care
Real-time, Structure and Intelligence
When AI lightens everyday life and makes expertise tangible.
Designed from the ground up – for real-world care.
Health Runtime emerged from a clear idea: digital health data should have impact where it originates — and strengthen people in everyday life. That’s why a FHIR® server was developed from the ground up — fully compliant with the
specification. Implemented with next-generation web technology and edge-first — for secure processing and responsive AI at the point of care and in patient-facing applications.
More than a platform: a lightweight agent context runtime on FHIR® with SDK and test kit. Development and operations interlock seamlessly — shortening the path from idea to clinical use.
Validation and terminologies where they matter: without breaks — in backend and frontend (direct feedback, offline capability, better usability) — compliant with the FHIR® specification and profiles.
FHIR® expertise is built-in — ready for what’s next.
A foundation is future-proof when it allows change. HealthRuntime combines standards fidelity with modular architecture — flexible where needed.
Plugin-first architecture — platform-open for existing resources and environments: on-device, at the edge, in clusters, in the cloud or serverless.
Digital health requires breadth and depth. HealthRuntime provides building blocks to implement requirements quickly and responsibly — agent-friendly in development and optimized for agentic AI. Teams gain time — and patients receive reliable, everyday support.
Safety & governance by design: zero-trust architecture, RBAC, policies, audit trails and observability — so automated recommendations remain traceable and accountability is clearly defined.
FHIR® + MCP: interoperability meets orchestration.
FHIR® is the open, community-driven specification for interoperability and data exchange in healthcare — HealthRuntime implements it rigorously, 100 % FHIR®-compliant.
MCP (Model Context Protocol) provides clear interface contracts for tool and context access: structured, auditable calls with defined schemas — embedded in roles and permissions.
Policy-compliant access via SMART on FHIR® (OAuth/scopes), RBAC and policies; technically integrated and enforced via the MCP tool service.
Agents operate only on released FHIR® context subsets with clear scopes — fully traceable. This creates transparency for teams and patients.
Agentic AI — easing everyday work, empowering people.
Agentic AI stands for context-aware automation: specialized agents support tasks in a rule- and context-guided way — transparent, safe, and in dialogue with users.
Own or external agents can be orchestrated via FHIR® and MCP — for analysis, planning, interaction and integration; LLM-based, rule-driven or tool-assisted. Result: teams gain time; patients receive clear, explainable support in everyday life.
Concrete examples: structured appointment preparation, medication checks with rationale, therapy-plan guidance, personalized reminders, symptom diaries — all based on approved data and fully auditable.
Ambient AI scribes reduce documentation burden and generate structured FHIR® data. Next steps: audio/visual feedback and hands-free (AR/XR). Goal: informed shared decisions — with clear clinical responsibility.
HealthRuntime brings AI where it has impact — turning information into practical, everyday support.
Real-time. Structure. Intelligence. — for care teams and for self-determined patients.
Note: AI components support professionals and do not replace clinical decision-making. Recommendations are explainable, consent-based and revocable.
What the atollee team makes possible
| Topic | Challenge | HealthRuntime delivers |
|---|---|---|
| FHIR®-compliant — ready to use | Heterogeneous profiles/releases, slicing and terminologies cause validation drift | Consistently correct resource/profile layer with continuous validation against specification and profiles; shared StructureDefinition → TS type tree for stable interoperability |
| Agentic-AI-ready | Secure, auditable tool access and clean context (least-privilege) are hard to implement consistently | MCP tool service for standardized tool/context discovery, SMART on FHIR® scopes, RBAC & policies — transparent and compliant |
| From prototype to operations | Friction from ETL/mapping and technology shifts from PoC to production | TypeScript SDK, test kit & plugin architecture with a shared FHIR model/types — edge-first up to serverless; CI/CD-friendly |
| In-place analytics & observability | Exports/copies increase risk & latency; lack of operational transparency | Database-proximate analytics on authorized data — without exports/copies; logs, metrics & trace IDs for operations and audit |
| Edge-first & data locality | Latency, connectivity and privacy at the point of care | On-device/edge execution with the same stack & policies; optional cloud connection; consistent behavior across all layers |
| Governance & safety by design | Enforcing policies consistently; ensuring explainability & accountability | Policy checks before tool calls, guardrails, consent/scopes, full auditability; role-based control along the flow |
| Integration & extensibility | Heterogeneous systems, lock-in risks, specialized workflows | Plugin-first with adapter plugins/MCP tool services for systems & devices; FHIR APIs for interoperability; no vendor lock-in, targeted extensibility |
| Deployment & CI/CD | Environment drift, manual deployments, compliance evidence | Reproducible builds/artifacts, infrastructure as code, pipeline gates (dev→test→prod) with audit trails; automated tests & policy checks |
| One codebase — frontend & backend | Media/type breaks between FE and BE; duplicate implementations | End-to-end TypeScript, shared packages/monorepo, types generated from StructureDefinition; unified linting/testing — one stack, one team |
| Team enablement & co-creation | FHIR expertise is scarce; long feedback loops until usable at the workplace | Test kit, SDK/admin tools, reference flows & local sandbox; co-creation at the point of care, rapid iterations with profile checks & tool services |
Platform vs. HealthRuntime — modern digital-health logic
| Platform – Vergleich | HealthRuntime(*) | |
|---|---|---|
| Target vision | Ecosystem/marketplace, centrally curated | Trust space on open standards; decentralized connectivity — technically implemented with HealthRuntime. |
| Interoperability | Partly FHIR®-compliant; interoperability extendable along operator logic | Open, auditable interoperability based on community specifications and terminologies. 100 % FHIR®-compliant with HealthRuntime; deviations are treated and fixed as bugs |
| Revenue model | Transaction- and volume-based revenues | SLA-based flat fees, independent of transaction volumes |
| Risk & operations | Dependencies, migration effort, costs tied to usage and operator | Policy- & audit-by-design; predictable operations |
| Scaling | Growth largely specified and curated centrally (top-down) | Specification-compliant, federatable, community-responsive — modularly scalable from PoC to production care |
| Federation/community | Cross-platform networking mostly operator-driven; interoperability and governance vary by platform | Atolls(**): federated trust spaces on open specifications & policies; controlled exchange with roles, scopes & audit trails — technically implemented with HealthRuntime |
| Perspectives: hospitals, providers, investors, patients, software/MedTech | ||
| Perspective: hospitals | Fixed license models, variable add-on/usage costs; tenders and switching with higher effort | Framework contracts with fixed budgets; integration & rollout via standards; tenders possible; once the atoll is established, switching becomes technically easier (open specifications & interfaces) |
| Perspective: providers | Scaling via transactions is possible, yet trust and tender hurdles remain | Plannable services; upsell via modules/service levels |
| Perspective: investors | Growth potential present, coupled with market and regulatory risks | Predictable recurring revenue; lower churn risk |
| Perspective: users/patients | Central convenience; partly FHIR®-compliant; consents often unclear (where granted? for what? how revoked?) and limited data portability | Clear consents (visible, controllable, revocable); consistent, policy-based access control (roles/permissions); data sovereignty & portability without lock-in |
| Perspective: app developers/MedTech manufacturers | Proprietary SDKs/APIs, uneven FHIR implementations; integrations depend on the operator | Open specifications (FHIR®, MCP), end-to-end TypeScript SDK & plugin model; multi-purpose, multi-deployment (edge/on-prem/cloud) |
Services based on the Atoll model reduce integration and switching costs, create trust and reliability through quality and compliance, and enable predictable revenues without lock-in.