Executive Summary
In most healthcare organizations, the people who know what needs to be built cannot build it — and the people who can are always months away. Every tool that could improve care or close a workflow gap gets stuck between them.
Atomic Workspace closes that gap. It is an AI platform where clinical teams design, build, and deploy healthcare applications — without a traditional development cycle. Clinicians, designers, developers, and AI agents all work in the same space. Clinicians describe what they need and sign off on the result. AI agents do the building. And if something tricky comes up — a complex integration, an edge case — a developer can jump in without losing the thread of what the team has already built. Every project runs inside a digital twin of the production environment, built on a FHIR Server, so teams build and test against real data structures from day one.
Early pilot results:
- Clinical requirement to working prototype: 1–2 days (vs. 3–6 months)
- Validated prototype to production: 2–4 weeks (vs. 6–18 months)
- Clinical teams ship 10x more apps per year without adding engineers
The Problem
Building a clinical tool requires two kinds of knowledge that rarely live in the same person: clinical expertise and software engineering. Bridging them is expensive.
Every requirement needs to be explained, clarified, and interpreted. Every design decision requires a feedback loop. Every iteration means another round of translation — from what the clinician needs, to what the developer understood, to what actually got built. Each step takes time, and each step introduces distortion.
By the time a tool ships, months have passed and significant budget has been spent — not on building, but on communication. And often, what gets delivered still doesn't quite fit.
So teams make do with spreadsheets, workarounds, and paper forms. They stop requesting tools they need because the cost of asking is too high. And the gap between what clinical teams have and what they actually need keeps widening.
What's Already Been Tried
General-purpose AI development tools
General-purpose AI coding platforms — assistants, agent frameworks, and low-code builders not designed for healthcare — offer speed. But they create new problems in a healthcare context.
They have no healthcare domain knowledge built in. They generate code without awareness of FHIR resource semantics, clinical data standards, or the constraints of EHR environments. Every project requires significant adaptation work to produce outputs that meet healthcare interoperability requirements. The integration burden — connecting apps to EHR systems, handling SMART authorization, mapping to FHIR resources — falls on the development team, not the platform.
These tools accelerate developers. They do not remove the dependency on developers.
Healthcare-native app platforms
The closest category to Atomic Workspace. Some platforms let clinical teams build custom healthcare tools with AI assistance — forms, dashboards, portals, workflows. They're fast and built with healthcare compliance in mind.
The core limitation is interoperability. These platforms sit on top of the EHR as a frontend layer — they're not FHIR-native. Every deployment to a new EHR environment requires custom integration work. The data they capture isn't natively FHIR-structured, which creates friction downstream when it needs to flow back into clinical systems.
FHIR-native developer platforms
Some platforms are genuinely FHIR-native — they solve the standards and interoperability problem well. But they're built for developers, not for clinical teams. A clinician still can't describe a workflow need and have it turned into a working app. The dependency on engineering doesn't go away.
The Atomic Workspace Approach
Atomic Workspace is built around four decisions that address the problem directly.
1. FHIR as the operating layer
In Atomic Workspace, FHIR is not an integration layer. It is the core data model the entire platform operates on. AI agents work directly with FHIR resources. The digital twin environment runs a live FHIR Server. Every app produced is a SMART on FHIR application, compatible with any FHIR-compliant EHR via the SMART App Launch Framework — without custom connectors, vendor-specific middleware, or per-deployment integration work.
The platform goes beyond base FHIR: it incorporates the HL7 SDC IG for structured clinical forms and questionnaires, SQL on FHIR for analytics and reporting, FHIR schema validation at every stage, and a built-in Terminology service (SNOMED CT, LOINC, and others) accessible to AI agents as command line tools, so clinical codes are resolved at the point of code generation.
This means every app built on Atomic Workspace is interoperable by construction — not by configuration.
2. A digital twin development environment
Every project in Atomic Workspace runs inside an isolated digital twin of the production clinical environment. The digital twin comprises a Virtual FHIR CDR (Clinical Data Repository with EHR simulation), a Workflow Engine (Temporal), and a Virtual Portal. AI agents and clinical teams build and test against the same data structures and service behavior they will encounter in production.
This eliminates the most common source of post-deployment failures in healthcare software: the gap between what the development environment assumed and what production reality turned out to be. When an app works in the digital twin, it works in the EHR.
3. Spec-driven development
Atomic Workspace inverts the traditional development handoff. Every build begins with a structured specification generated by the AI Analyst from clinical requirements, reviewed and approved by the clinical team before any code is written. The approved spec then configures the digital twin environment, defines the test suite, and governs what AI agents build across the full lifecycle.
Clinical intent is encoded as a verifiable artifact — not interpreted during development, not reconstructed after the fact. This is what makes it possible for clinicians to participate in the build without writing code: they are not approving technical outputs, they are approving a specification written in terms they understand.
4. Collaborative by design
Atomic Workspace is built as a shared environment from the ground up. Clinicians, designers, developers, analysts, and AI agents work in the same workspace simultaneously — seeing the same requirements, the same build state, the same validation results. Developers can step into any active project at any stage to resolve a technical edge case without losing the thread of what the clinical team has already built.
Human-in-the-loop checkpoints are built into the workflow at spec approval, clinical validation, and stakeholder sign-off. AI agents operate between those checkpoints. No project reaches production without clinical and stakeholder sign-off.
How it works
A project in Atomic Workspace moves through a defined lifecycle, with AI agents driving the execution and clinical participants controlling the decisions.
1. Capture A clinician or care team describes a workflow need in their own language. The AI Analyst engages in structured dialogue to surface requirements, edge cases, and constraints. No technical knowledge required.
2. Specify The AI Analyst converts the captured requirements into a structured specification: data model, workflow logic, validation rules, and acceptance criteria. The clinical team reviews and approves the spec before any code is generated.
3. Configure The approved spec configures the project's digital twin environment — instantiating the FHIR resources, workflow definitions, and test fixtures that the app will be built against.
4. Build AI Developer agents generate the application — backend and frontend — targeting the FHIR-native APIs of the digital twin. Built-in Skills (SDC, UI, Analytics, Terminology) act as guardrails, constraining AI output to FHIR-compliant, clinically sound patterns.
5. Test Automated testing agents validate the application against the digital twin, checking FHIR conformance, workflow correctness, and acceptance criteria from the spec.
6. Validate The clinical team interacts with the working application inside the digital twin — the same environment it will run in when deployed. Feedback flows back into the workspace for iteration.
7. Deploy After stakeholder sign-off, the app is deployed as a SMART on FHIR application, launching directly within the organization's FHIR-compliant EHR. No deployment infrastructure to build, no integration work to do.
A single Atomic Workspace instance manages any number of concurrent projects — each running in a fully isolated environment. This means multiple clinical teams can build simultaneously without interference, and each project's data, code, and agent context remain completely separate. Figure 1 illustrates this multi-project architecture.
Each project environment is not a generic sandbox — it is a structured digital twin with three distinct layers working together. Figure 2 shows the internal architecture of a single project: on the left, the production services digital twin (FHIR CDR, Workflow Engine, Virtual Portal); in the center, the application codebase and runtime; on the right, the AI Copilot layer with Coding Agents operating via ACP protocol, guided by a built-in Skills and Knowledge layer that constrains AI output to FHIR-compliant, clinically sound patterns.
Technical Foundation
Infrastructure and stack
Atomic Workspace is built on Aidbox, a FHIR server platform. Each project runs in an isolated Docker container, managed via Multibox — Aidbox's multi-tenant layer — which handles provisioning and data isolation across projects.
| Component | Technology |
|---|---|
| Runtime | Bun |
| Containerization | Docker / Docker Compose |
| FHIR Server | Aidbox (Multibox) |
| Workflow Engine | Temporal |
| AI Agents | Claude Code, Codex via ACP (Agent Communication Protocol) |
| Frontend | TypeScript, browser-based |
| Project Scaffolding | Template-based, FHIR-aligned |
HL7 standards
| Standard | How used |
|---|---|
| FHIR R4 | Core data model, REST APIs, resource validation |
| SMART on FHIR | App output format, EHR launch, authorization |
| HL7 SDC IG | Structured data capture, clinical forms and questionnaires |
| SQL on FHIR | Analytics and reporting layer |
| SNOMED CT / LOINC | Terminology service via CLI tools, resolved at code generation |
Deployment
Atomic Workspace supports cloud, on-premise, and hybrid deployment. Organizations with data residency or network isolation requirements can run the full platform within their own infrastructure. SMART on FHIR apps deploy without per-target integration work across Epic, Cerner, and other FHIR-compliant EHR systems.
Security and Compliance
Data isolation and authorization
Each project runs in an isolated digital twin environment. Development and testing use synthetic or de-identified data by default. Production deployments operate under appropriate BAAs with healthcare organization partners. All platform access uses enterprise-grade authentication with role-based access controls at both the platform and application layers.
All apps produced by the platform use the SMART authorization framework for access control, aligning with CMS interoperability rules and ONC certification requirements for EHR-integrated applications.
Human-in-the-loop by design
Mandatory human validation checkpoints are built into the workflow at spec approval, clinical validation, and stakeholder sign-off. AI agents operate between these checkpoints but cannot advance a project to production without clinical and stakeholder authorization. AI-generated code, specifications, and test results are fully visible and reviewable within the workspace. Clinical and technical participants can inspect, modify, and override AI outputs at every stage.
Regulatory posture
Apps produced by Atomic Workspace that fall within the scope of Software as a Medical Device (SaMD) require separate regulatory review. The platform provides the development and integration infrastructure; it does not replace the clinical validation and regulatory clearance process for tools that make or influence clinical decisions.
The Business Case
The economics
Atomic Workspace is not about replacing developers. It is about changing what developers need to be involved in.
Today, every clinical app requires full engineering engagement — from requirements through design, development, testing, and deployment. The development team is the bottleneck for every project, regardless of complexity. Organizations add headcount to add capacity, but the cost of each additional app stays high.
Atomic Workspace changes this ratio. AI agents handle the execution. Developers step in where genuine technical depth is needed — complex integrations, edge cases, performance tuning. The result is that a team of a given size can support significantly more projects per year.
Cost model
The platform cost is primarily a fixed infrastructure cost that amortizes across projects. Once the platform is deployed and the initial Skills library is established, the marginal cost of each additional app decreases. Organizations that build a library of institutional Skills — encoding their own workflows, clinical rules, and data patterns — see further cost reductions as each new project starts with a richer foundation.
Build vs. buy
For healthcare IT organizations evaluating build vs. buy:
Building a custom AI development platform requires deep FHIR expertise, multi-agent orchestration infrastructure, clinical domain knowledge baked into the toolchain, and ongoing maintenance as standards evolve. This is a multi-year, multi-million dollar investment with significant ongoing operational overhead.
Adapting general-purpose tools for healthcare shifts the integration and compliance burden onto every individual project. Each app becomes a custom integration exercise. The platform does not accumulate clinical knowledge or standards alignment over time.
Atomic Workspace starts with the healthcare-specific foundation already in place — FHIR-native, standards-aligned, EHR-ready. The Skills library grows with each project, so the platform gets more useful over time, not less.
Illustrative Use Cases
Patient-Reported Outcomes (PROMs) Collection
The problem A care team managing post-surgical patients needs to collect standardized outcomes scores (KOOS, HOOS, PROMIS) at defined intervals. Currently, this is done through paper forms or manual phone calls — data ends up in scanned PDFs or unstructured notes, not in the EHR.
The build A clinical analyst describes the requirement to the AI Analyst: collect specific PROMs at 2 weeks, 6 weeks, and 3 months post-surgery, tied to the patient's CarePlan in the EHR. The AI Analyst converts this into a structured specification using HL7 SDC IG Questionnaire resources for each outcomes instrument.
The AI Developer generates a patient-facing SMART on FHIR app that sends patients a secure link at the appropriate interval. Patients complete the form on any device; responses are stored as FHIR QuestionnaireResponse resources, linked to the originating CarePlan and immediately available in the EHR.
For patients who prefer voice interaction, the same workflow supports an AI voice call: an AI agent reads the questionnaire items, captures responses via voice, and maps them to the corresponding FHIR QuestionnaireResponse fields.
The outcome Structured, coded outcomes data flows directly into the FHIR data store — no manual transcription, no unstructured notes. The care team gains a complete longitudinal view of patient-reported outcomes without changing how patients prefer to interact.
Platform capabilities demonstrated: SDC IG Questionnaire/QuestionnaireResponse, SMART on FHIR patient-facing app, Terminology service, AI voice integration, CarePlan linkage.
Clinical Analytics Dashboard via Natural Language
The problem A clinical operations lead wants to track readmission rates, length of stay, and medication adherence across a patient cohort — but has no engineering support available and cannot wait for a BI team to prioritize the request.
The build The analyst opens a new project in Atomic Workspace and describes the dashboard in natural language: which patient population, which metrics, what time windows, and how results should be displayed. No SQL or FHIR query knowledge required.
The AI Analyst produces a specification that maps each metric to the relevant FHIR resources (Encounter, MedicationRequest, Observation) and defines the SQL on FHIR queries that will power the dashboard. After the analyst approves the spec, AI Developer agents generate the dashboard application — a SMART on FHIR app that queries the FHIR Server using SQL on FHIR and renders results in an interactive interface.
The analyst can refine the dashboard through follow-up chat: "add a filter for primary diagnosis," "show trend lines for the last 90 days," "break this down by attending physician." Each request is translated into a spec update and implemented by AI agents.
The outcome A fully functional clinical analytics dashboard, deployed into the EHR, built without engineering involvement — from description to working app in under a day.
Platform capabilities demonstrated: SQL on FHIR, Analytic Skills, natural language spec generation, SMART on FHIR app output, iterative AI-driven refinement.
Prior Authorization Decision-Making Service
The problem Prior authorization is one of the most labor-intensive processes in healthcare. Utilization management (UM) nurses manually check eligibility, coverage rules, and medical necessity criteria for every authorization request — working through large spreadsheets of billing codes, navigating CMS websites for LCD/NCD (Local and National Coverage Determination) criteria, and making multiple calls to providers to collect clinical documentation. The process takes hours per case.
The core problem is that coverage rules exist as unstructured text on CMS websites and internal spreadsheets — not as machine-readable logic. Every payer has slightly different rules. There is no standard way to encode, maintain, or execute them automatically.
The build On Atomic Workspace, a utilization management (UM) specialist — a clinically trained staff member responsible for coverage decisions, typically without a technical background — works with the AI Analyst to define coverage rules for a specific line of business — starting, for example, with Home Oxygen (Medicare LCD L33797). The platform includes a built-in Knowledge Base populated from Medicare LCD/NCD documents: scraped from CMS, structured and indexed, and made available to AI agents via search and similarity lookup.
The AI agent uses this Knowledge Base to extract the relevant medical necessity criteria, generate a FHIR Questionnaire resource that captures the required clinical evidence, and encode the coverage logic as a structured decision rule. The UM specialist reviews and refines the output — no coding required.
The result is a Decision-Making Service: a standards-based component that accepts a CDS Hooks request from the EHR when a prior auth-eligible procedure is ordered, evaluates the applicable coverage rules against the patient's FHIR record, and responds with a decision — approved automatically (for gold-card providers or clearly eligible cases), or a link to the generated FHIR Questionnaire for the clinician to complete.
The entire service is built as a template project in Atomic Workspace, deployable to multiple payer organizations with organization-specific rule sets authored on top of the shared framework.
The outcome Routine prior authorization decisions are processed automatically at the point of order — without UM nurse involvement. Complex or exception cases are routed to human review with the relevant clinical evidence already assembled. Coverage rules are maintained by UM specialists directly, without developer involvement, and updated as LCD/NCD criteria change.
For payers, this replaces a manual, error-prone process with an auditable, standards-based automation built in weeks — not the months and six-figure cost of traditional policy management tools.
Platform capabilities demonstrated: CDS Hooks integration, FHIR Questionnaire generation, Medicare LCD/NCD Knowledge Base, AI-assisted coverage rule authoring by non-technical staff, template-based multi-tenant deployment.
Early Evidence
Atomic Workspace is currently in an active pilot with a clinical team. The digital twin environment is live and operational; real project development and clinical validation are underway.
The following benchmarks are informed by early pilot observations and will be formally validated through the ongoing pilot:
| Metric | Industry baseline | Atomic Workspace target |
|---|---|---|
| Requirement to working prototype | 3–6 months | 1–2 days |
| Validated prototype to production | 6–18 months | 2–4 weeks |
| Clinician satisfaction score | — | 4+ / 5 |
| Apps shipped per year (same team size) | Baseline | 10x |
Getting Started
Atomic Workspace is available for pilot deployment with healthcare IT organizations and their clinical partners.
The platform supports cloud, on-premise, and hybrid deployment. Pilot engagements begin with a defined clinical use case and end with a working app deployed into the EHR.
To discuss a pilot or technical evaluation: Contact: mary@health-samurai.io
Platform resources:
- Sandbox environment available for technical evaluation
- Architecture documentation and integration guides available on request
Atomic Workspace is developed by Health Samurai, the team behind the Aidbox FHIR platform.
