Overview
The Doctor App enables partners to integrate doctor-facing workflows from the Air Doctor platform into their applications.
Client applications integrate using one of the following models.
| Integration Model | Description |
|---|---|
| Doctor App SDK | Renders workflow-driven UI inside the host application using platform runtime responses. |
| Open API | The partner application implements its own client and communicates directly with Air Doctor platform endpoints. |
Both models use the same underlying workflow engine. The difference lies in how UI rendering and workflow orchestration are implemented.
Integration Levels
Air Doctor supports multiple integration levels that determine how much responsibility the partner application assumes for UI rendering and workflow orchestration.
Lower levels rely on hosted Air Doctor experiences. Higher levels allow deeper customization and full client implementations.
For a full comparison of integration approaches, see:
Supported Integration Levels
Integration Architecture
Doctor-facing integrations divide responsibilities between the host application, the SDK runtime, and the Air Doctor platform.
┌──────────────────────────────────────────────┐
│ Host Application │
│ │
│ App shell • Authentication bootstrap │
│ Navigation container • Session storage │
│ Analytics • UI configuration │
└───────────────────────┬──────────────────────┘
│
│ SDK integration
▼
┌──────────────────────────────────────────────┐
│ Doctor App SDK │
│ │
│ Runtime interpretation • Action dispatch │
│ State synchronization • UI component binding │
└───────────────────────┬──────────────────────┘
│
│ Runtime API
▼
┌──────────────────────────────────────────────┐
│ Air Doctor Platform │
│ │
│ Workflow engine • Permission resolution │
│ Validation rules • Screen definitions │
│ Appointment state transitions │
└──────────────────────────────────────────────┘Responsibility Model
The platform, SDK, and host application perform distinct roles during runtime execution.
| Component | Responsibilities |
|---|---|
| Air Doctor Platform | Executes workflow logic, resolves permissions, validates input, and determines valid workflow transitions. |
| Doctor App SDK | Processes runtime responses, dispatches workflow actions, synchronizes state, and binds runtime definitions to UI components. |
| Host Application | Provides authentication context, manages session tokens, hosts navigation containers, and supplies configuration such as analytics and UI theming. |
Client applications should treat runtime responses as the canonical representation of workflow state.
Runtime Model
The Doctor App uses a server-driven runtime model.
The platform determines which screens, actions, and validation rules apply to the current doctor session.
The SDK processes the runtime response and renders the interface inside the host application.
- Platform → returns workflow state, screen definitions, available actions, and validation rules
- SDK → processes runtime responses and binds them to UI components
- Host application → mounts SDK screens and provides session and navigation context
Runtime Lifecycle
Runtime execution progresses through several stages.
| Stage | SDK Behavior | Result |
|---|---|---|
| Session bootstrap | Initialize runtime client with doctor session context | Authenticated runtime session established |
| Screen request | Request runtime definition for the active route | Screen metadata becomes available |
| Screen render | Bind runtime schema to UI components | Doctor-visible interface renders |
| Action submission | Dispatch selected action to the platform | Workflow transition request executes |
| Validation response | Map validation errors returned by the platform to UI state | Errors appear in corresponding UI fields |
| Workflow transition | Refresh runtime state | Updated workflow state renders |
| Session invalidation | Clear runtime state | Host application redirects to authentication |
Platform Characteristics
The Doctor App platform has several architectural characteristics that influence integration behavior.
| Characteristic | Description |
|---|---|
| Server-driven UI | Screen structure and available actions are defined by the platform and returned at runtime. |
| Platform-authoritative state | Workflow transitions and appointment state are controlled by the platform. |
| Action-based workflows | Doctor interactions execute platform-defined runtime actions. |
| Permission-controlled UI | Available screens and actions depend on doctor permissions. |
Client applications must treat platform responses as the authoritative representation of workflow state.
Functional Domains
Doctor-facing integrations operate across several platform domains.
| Domain | Purpose |
|---|---|
| Authentication and Session Management | Doctor identity verification, MFA handling, and session lifecycle management |
| Appointments and Workflow State | Appointment lifecycle management and workflow transitions |
| Communication Modules | Chat messaging and video consultation capabilities |
| Permissions and Validation | Platform enforcement of access control and validation rules |
| Localization and Content Delivery | Language selection and localized content presentation |