Technology Overview
Air Doctor v3 defines a strict separation of logic, state, and presentation. The server controls application logic and layout definitions. The client backend controls state only. The client frontend controls presentation only. This architecture supports predictable integration, rapid partner onboarding, and stable UI flows across platforms. It also provides a foundation for AI-driven automation across all integrations.
Architectural Overview
Server
The server contains all application logic and defines screen composition. The server remains proprietary and exposes an Open API specification for partner integration.
Client Backend
The client backend implements client-side domain logic, including state control and caching. It excludes presentation and server-side business rules.
The codebase uses Kotlin and transpiles to:
- JavaScript for web
- JVM bytecode for Android
- Native binaries for iOS
This SDK remains proprietary and is available to partners as an SDK.
Client Frontend
The client frontend implements presentation only. The web frontend uses plain JavaScript with no frameworks to support embedding in partner applications without enforcing technology selection. Android uses Kotlin. iOS uses Swift.
The client frontend code is open source and serves as a reference implementation.
Partners customize presentation while keeping domain logic unchanged.
Summary
| Component | Purpose | Ownership |
|---|---|---|
| Air Doctor Server | Application logic and screen control | Proprietary |
| Client Backend | Domain logic and state control | Proprietary |
| Client Frontend | Presentation layer only | Open source |
Server Technologies
Kotlin, Spring Boot, and Hibernate
The server uses Kotlin, Spring Boot, and Hibernate.
- Kotlin provides strong type safety, Java interoperability, and concise syntax.
- Spring Boot provides consistent configuration and predictable deployment behavior
- Hibernate manages Object–Relational Mapping (ORM).
AWS Infrastructure: Elastic Beanstalk, RDS, and S3
Air Doctor runs on Amazon Web Services with Elastic Beanstalk (EBS) for application hosting. EBS manages deployment, scaling, health checks, and abstracts infrastructure management while it still exposes EC2 and load balancer configuration.
The platform uses Amazon Relational Database Service (RDS) for data storage. RDS automates hardware provisioning, patching, and backups and runs a managed version of MySQL. This automation allows developers to focus on business logic while using scalable and cost-efficient database instances.
Large objects such as medical documents, images, and attachments reside in Amazon S3, which provides built-in encryption and fine-grained access control to maintain data security.
Large objects such as medical documents, images, and attachments reside in Amazon S3. S3 provides built-in encryption and fine-grained access control to maintain data security requirements.
Open API
Air Doctor publishes a comprehensive Open API specification. The specification defines each endpoint, request and response schemas, error types, and hypermedia links. Screen-level documentation aligns with each API description.
The Open API exposes behavior and structure while the server implementation remains proprietary.
Hypermedia and HATEOAS
Air Doctor adheres to the HATEOAS constraint.
Under HATEOAS, an API architectural style, the server response includes data, actions, and layout instructions.
Each screen API response includes links and actions objects that define available operations. The client backend contains no application logic. It follows server-defined links to construct screen layouts dynamically.
This design enables the following capabilities
- Declarative screen composition - The server defines the layout, field order, and permitted actions. This approach reduces client complexity.
- Discoverability for partners - Integrators follow links to traverse the API workflow and simplify integration effort.
- Machine readability - Hypermedia enables AI systems to identify available actions without custom client code.
By adopting HATEOAS, the Air Doctor client application is effectively future-proof. Logic changes do not require a client application update.
All logic changes occur on the server. The client does not require updates when the server adjusts screen definitions or workflows.
Model Context Protocol (MCP) Integration
The server provides hypermedia responses that contain links and actions. An MCP wrapper uses these responses to supply screen definitions and action metadata to AI systems.
This integration enables AI agents to navigate healthcare workflows, analyze actions, and identify available actions with minimal integration overhead.