Overview
The Patient App enables partners to integrate patient medical services into their applications.
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. |
Both models use the same platform services and workflow engine. The difference lies in how UI rendering and workflow orchestration are implemented.
Integration Levels
Air Doctor supports several 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, 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 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. |
| Air Doctor 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 customization. |
Client applications should treat runtime responses as the canonical representation of workflow state.
Runtime Model
The Patient App uses a server-driven runtime model.
The platform determines which screens, actions, and validation rules apply to the current patient session.
The SDK processes runtime responses 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 patient 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 | Patient-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 the interface |
| Workflow transition | Refresh runtime state | Updated workflow state renders |
| Session invalidation | Clear runtime state | Host application redirects to authentication |
Platform Characteristics
The Patient 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 booking state are controlled by the platform. |
| Action-based workflows | Patient interactions execute platform-defined runtime actions. |
| Permission-controlled UI | Available screens and actions depend on patient eligibility and permissions. |
Client applications must treat platform responses as the authoritative representation of workflow state.
Functional Domains
Patient-facing integrations operate across several platform domains.
| Domain | Purpose |
|---|---|
| Authentication and Session Management | Patient identity verification and session lifecycle management |
| Appointments and Booking Workflows | Appointment search, scheduling, and lifecycle transitions |
| Communication Modules** | Messaging and telemedicine consultations |
| Permissions and Eligibility | Coverage validation and access control enforcement |
| Localization and Content Delivery | Language selection and localized content presentation |