Overview
The Patient App provides a server-driven SDK and API platform for patient booking, communication, telemedicine, and coverage workflows.
Client applications integrate using one of two models.
| Integration Model | Description |
|---|---|
| Air Doctor 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. |
Integration Levels
Integration levels determine how much UI rendering and runtime execution the host application manages.
Lower levels rely on hosted Air Doctor experiences, while higher levels allow deeper customization and full client implementations.
For a complete comparison of integration approaches, see:
Supported Integration Levels
Integration Architecture
Patient-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
▼
┌──────────────────────────────────────────────┐
│ Air Doctor SDK │
│ │
│ Runtime rendering • Action dispatch │
│ State synchronization • UI binding │
└───────────────────────┬──────────────────────┘
│
│ Runtime API
▼
┌──────────────────────────────────────────────┐
│ Air Doctor Platform │
│ │
│ Workflow engine • Permission resolution │
│ Validation rules • Screen definitions │
│ Appointment state transitions │
└──────────────────────────────────────────────┘Runtime Model
The platform controls workflow state, available actions, validation rules, and screen configuration at runtime.
The SDK processes runtime responses and renders the resulting UI 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
- Client 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 session | Authenticated session established |
| Screen request | Request screen definition | Runtime metadata available |
| Screen render | Bind runtime schema | Interface rendered |
| Action submission | Dispatch runtime action | Workflow transition executed |
| Validation response | Map validation errors | Validation state updated |
| Workflow transition | Refresh runtime state | Updated interface rendered |
| Session invalidation | Clear runtime state | Authentication required |
Platform Modules
| Module | Responsibilities |
|---|---|
| Authentication | Session and identity management |
| Booking | Appointment discovery and scheduling |
| Messaging | Patient communication workflows |
| Video | Telemedicine session management |
| Coverage | Insurance eligibility and validation |
Runtime Rules
- Runtime responses determine available actions at execution time.
- Client applications must not cache workflow permissions across sessions.
- Runtime actions may change based on patient eligibility, coverage, or appointment state.
- Screen availability may differ between platforms and integration levels.