Skip to main content

Technology Overview

Air Doctor v3 defines a strict separation of logic, state, and presentation. The server controls all logic and layout definitions. The client backend controls state only. The client frontend controls presentation only. This structure supports predictable integration, rapid partner onboarding, and stable UI flows across platforms. and provides a foundation for AI-driven automation across all integrations..

System architecture showing how both the Doctor App and Patient App connect through the SDK and API layers to the Air Doctor backend.

Architectural Overview​

  • Server - Contains all application logic and defines screens composition. The server is proprietary and exposes an Open API specification for partner integration.

  • Client Backend - Implements domain logic on the client side, such as state control and caching. It excludes presentation and business rules. The codebase uses Kotlin and transpiles to JavaScript for web, to JVM bytecode for Android, and to native binaries for iOS. This SDK is proprietary and available to partners as an SDK.

  • Client Frontend - Implements presentation only. The web frontend uses plain JavaScript with no frameworks so it embeds into partner applications without enforcing technology selection. Android uses Kotlin, and iOS uses Swift. The client frontend code is open source as a reference implementation. Partners modify the presentation while they keep domain logic intact.

    Summary Table

    ComponentPurposeOwnership
    Air Doctor ServerApplication logic and screen controlProprietary
    Client BackendDomain logic and state controlProprietary
    Client FrontendPresentation layer onlyOpen source

Server Technologies​

Kotlin, Spring Boot, and Hibernate​

The server uses Kotlin, Spring Boot, and Hibernate.

  • Kotlin provides strong type safety and interoperability with Java and enables concise code.
  • Spring Boot provides stability and predictability for configuration and deployment.
  • 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 controls deployment, scaling, and 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 with 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.

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.

note

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 does not contain application logic. It follows these link definitions 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.

important

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.