From idea to care – fast, responsible, future-ready.
HealthFireKit™ – the agent toolkit on FHIR®
Empowering users: Agentic AI at the Point of Care
Ready today, scalable tomorrow. Usable from day one – extensible at any time.
Designed from the ground up – for what really matters.
It all began with the ambition to build a FHIR® server from the ground up – fully compliant with the
specification, realized with next-generation web technology and edge-first for secure processing and responsive AI at the Point of Care.
More than a platform: a lightweight, plugin-based agent toolkit on FHIR® with SDK and testkit. Development and production environment in one (dual-purpose). Shorter time-to-value and a clear path into care delivery.
Validation and terminologies where they are needed: without breaks – in backend and frontend (for instant feedback, offline capability, and better usability) – compliant with the FHIR® specification and profiles.
FHIR® expertise is built-in – for what’s ahead.
A foundation is only future-ready if it allows change. HealthFireKit™ combines standards fidelity with modular architecture – flexible where needed.
Plugin-first architecture – platform-open and flexible for existing resources and environments: on-device, at the edge, in the cluster, in the cloud, or serverless.
Application development in digital health requires broad expertise. HealthFireKit™ provides the foundation and building blocks to implement requirements quickly, responsibly, and future-ready – agent-friendly in development and optimized for Agentic AI.
Safety & governance by design: zero-trust architecture, RBAC, policies, audit trails, and observability – for secure, compliant data processing and orchestration.
FHIR® + MCP: Interoperability meets orchestration
FHIR® is the open, community-driven specification for interoperability and data exchange in healthcare (resources, profiles, terminologies, and APIs) – HealthFireKit™ implements it consistently, 100 % FHIR®-compliant.
MCP (Model Context Protocol) is an open protocol with clear interface contracts for tool and context access: structured, auditable calls with defined schemas, embedded in roles and permissions.
HealthFireKit™ provides compliant access via mechanisms such as SMART on FHIR® (OAuth/scopes), RBAC and policies; these mechanisms are technically integrated and enforced via the MCP tool service.
Agents work on shared FHIR® context slices with clearly defined access areas (scopes) – fully traceable.
Agentic AI – relieving in everyday work, extensible for the future
Agentic AI stands for context-aware automation: distributed, specialized agents that execute tasks governed by rules and context – traceable and secure.
HealthFireKit™ makes this connectable: integrate and orchestrate your own or external agents via FHIR® and MCP – for analysis, planning, interaction, and integration; LLM-based, rule-driven, or tool-assisted.
Orchestration, logging, and observability are natively integrated and ready to use. This enables Agentic AI to be embedded purposefully and flexibly in hospitals, emergency services, practices, administration, and research.
Ambient AI scribes: less documentation burden, structured FHIR® data – more attractive jobs. Next: audio/visual feedback & hands-free (AR/XR). Ready for what’s next – with HealthFireKit™.
HealthFireKit™ brings AI to where it has impact.
FHIR® & MCP – the key building blocks for digital health.
Note: AI components support professionals and do not replace clinical decision-making.
What does the atollee team make possible?
| Topic | Challenge | HealthFireKit™ delivers |
|---|---|---|
| FHIR®-compliant – ready to use | Heterogeneous profiles/releases, slicing, and terminologies lead to validation drift | Correctly implemented 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 – traceable and compliant |
| From prototype to operations | Friction losses due to ETL/mapping and technology shifts from PoC into operations | TypeScript SDK, testkit & plugin architecture with shared FHIR model/types – edge-first, optionally up to serverless; CI/CD-friendly |
| In-place analytics & observability | Exports/copies increase risk & latency; lack of operational transparency | Database-near analytics on authorized data – without exports/copies; logs, metrics & trace IDs for operations and audit |
| Edge-first & data locality | Latency, connectivity, and data protection at the Point of Care | On-device/edge execution with the same stack & policies; cloud connection if needed; consistent behavior across all layers |
| Governance & safety by design | Consistently enforcing policies; 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, special workflows | Plugin-first with adapter plugins/MCP tool services for systems & devices; FHIR APIs for interop; 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 | Breaks in media and types between FE and BE; duplicate implementations | End-to-end TypeScript, shared packages/monorepo, generated types from StructureDefinition; unified linting/testing – one stack, one team |
| Team enablement & co-creation | FHIR expertise is scarce; long feedback loops until workplace usability | Testkit, SDK/Admin tools, reference flows & local sandbox; co-creation at the Point of Care, rapid iterations with profile checks & tool services |
Platform vs. Atoll – modern digital health logic
| Platform – Vergleich | Atoll(*) | |
|---|---|---|
| Target vision | Ecosystem/marketplace, centrally curated | Open trust space (Atoll) built on standards; decentralized connectivity – technically implemented with HealthFireKit™ |
| Interoperability | Partially FHIR-conformant; interoperability extended according to operator logic | Open, auditable interoperability on community-based specifications and terminologies. 100 % FHIR®-compliant with HealthFireKit™; deviations are treated as bugs and fixed |
| Revenue model | Transaction- and volume-based revenues | SLA-based flat fees, independent of transaction volumes |
| Risk & operations | Dependencies, migration efforts, costs tied to operator and usage | Policy- & audit-by-design; predictable operations |
| Scaling | Growth predominantly centrally prescribed and curated (Top-down) | Specification-conformant, federatable, Community-reactive – modular scalable from PoC to production |
| Federation/Community | Cross-ecosystem networking mostly operator-driven; interoperability and governance vary by platform | Archipelago(**): federated Atolls on open specifications & policies; controlled exchange with roles, scopes & audit trails – technically implemented with HealthFireKit™ |
| From the perspectives of: clinics, providers, investors, patients, software/MedTech | ||
| Perspective: Clinics | Fixed license models, variable additional/usage costs; tenders and switching require higher effort | Framework contracts with fixed budgets; integration & rollout via standards; tenders possible; switching – once the Atoll is established – technically easier to implement (open specifications & interfaces) |
| Perspective: Providers | Scaling possible via transactions, but with trust and tendering hurdles | Plannable services; upsell through modules/service levels |
| Perspective: Investors | Growth potential, but linked with market and regulatory risks | Predictable recurring revenues; lower churn risks |
| Perspective: Users/Patients | Central convenience; partially FHIR®-conformant; but consent often unclear (where granted? for what? how to revoke?) and data only limited portable | Clear consent (viewable, controllable, revocable); consistent, policy-based access control (roles/permissions); data sovereignty & portability without lock-in |
| Perspective: Application developers/MedTech manufacturers | Often proprietary SDKs/APIs, FHIR implementations vary in scope; integrations dependent on operator | Open specifications (FHIR®, MCP), consistent TypeScript SDK & plugin model; Multi-Purpose, Multi-Deployment (Edge/On-Prem/Cloud) |
Services according to the Atoll model lower integration and switching costs, strengthen retention through quality and compliance – and enable predictable revenues without lock-in.