ArchitectureVersion 2.0 — 20269 min read

System Architecture

Platform Family, Four-Layer Architecture & Data Flow

A visual and textual overview of the Aimedis platform family — the hub-and-spoke integration model connecting six platforms and their specialist products, and the four-layer architecture beneath them, from shared core infrastructure to the ecosystem layer.

DIAGRAM

Platform Family Diagram

Hub — Aimedis Center

The control room: a registry of every platform, a live map of their wiring and health, and the documented contracts between them. Center never holds patient data — it monitors integration health, links out to each platform, and never absorbs them.

The Platform Family — one account, one consent record

Aimedis Care ProAimedis ConnectAimedis AppointmentAimedis ProAimedis Onboarding

Specialist Products — built on the shared core

Aimedis Decision ProAimedis RehabAimedis InsurAimedis SupportVR / AR Medical Education

Legend

Control Room (Center)
Platform Family
Specialist Products
DIAGRAM

Four-Layer Architecture

Layer 01Core Infrastructure

Shared account & identityVersioned GDPR Art. 9 consentHealth-record storageAudit logging

Layer 02Interoperability Layer

Consent & access API (owned by Care Pro)FHIR R4-native clinical backendModule, health & registry contractsStructured medical record formats

Layer 03Application Layer

Aimedis Care ProAimedis ConnectAimedis AppointmentAimedis ProAimedis OnboardingAimedis CenterAimedis Decision ProAimedis RehabAimedis InsurAimedis SupportVR / AR Medical Education

Layer 04Ecosystem Layer

Healthcare providers & practicesDevelopersMedical researchersInsurersEducatorsPlatform operators

Legend

Core Infrastructure
Interoperability Layer
Application Layer
Ecosystem Layer
CROSS-CUTTING

Consent, Data & AI — Cross-Cutting Concerns

Consent & Data Plane

Every platform and specialist product reads clinical data through the same consent-checked path — there is no side-channel access to patient records anywhere in the family.

FHIR R4-native clinical data backend
Consent-checked access API owned by the health-record platform (Care Pro)
Hash-chained, tamper-evident audit log
Clinical data stores enforce row-level security

AI Services

AVA is one assistant, not a separate architectural layer — it appears as a product surface inside Care Pro, Connect, Pro, Rehab, Insur, and Support.

AVA as a product-surface assistant, not a standalone platform
Clinical decision support is explicitly non-binding — the licensed clinician always decides
AI processing operates only within the same consent-checked data plane
30+ conversational languages, distinct from the 14-language UI

Security Framework

Encryption of data in transit and at rest
Row-level security on clinical data stores
Role-based access control
Authenticated APIs
Rate limiting
Comprehensive audit logging
LAYERS

Layer Documentation

01

Core Infrastructure

Every family platform builds on the same foundation: one shared account and identity, one versioned GDPR Art. 9 consent record, and the health-record storage and audit-logging services beneath all six platforms.

A developer never re-implements identity or consent — a patient who signs up through Onboarding, Care Pro, or Connect already has the same account and the same consent record on every platform in the family.

Key Capabilities

Shared account & identityVersioned GDPR Art. 9 consentHealth-record storageAudit logging
02

Interoperability Layer

The documented contracts and standards that let family platforms — and outside systems — exchange health data safely. Clinical records are FHIR R4-native throughout.

The consent & access API is owned by the health-record platform (Aimedis Care Pro) and is the single path every other platform and specialist product uses to read a patient’s record — there is no side-channel data path.

Key Capabilities

Consent & access API (owned by Care Pro)FHIR R4-native clinical backendModule, health & registry contractsStructured medical record formats
03

Application Layer

The six family platforms — Care Pro, Connect, Appointment, Pro, Onboarding, and Center — plus the specialist products built on the shared core: clinical decision support, neurorehabilitation, insurance engagement, community support, and immersive education.

Every application-layer product consumes the same core and interoperability services below it; none of them implement their own identity, consent, or clinical data store.

Key Capabilities

Aimedis Care ProAimedis ConnectAimedis AppointmentAimedis ProAimedis OnboardingAimedis CenterAimedis Decision ProAimedis RehabAimedis InsurAimedis SupportVR / AR Medical Education
04

Ecosystem Layer

The broader network of organizations, professionals, and builders interacting through the platform family — practices, healthcare professionals, developers, researchers, educators, insurers, and platform operators.

This is where third-party integration happens: a developer builds against the interoperability layer’s documented contracts, a practice connects through Appointment and Pro, an insurer white-labels Aimedis Insur.

Key Capabilities

Healthcare providers & practicesDevelopersMedical researchersInsurersEducatorsPlatform operators

Why This Architecture Matters

Hub-and-spoke integration keeps platforms modular — Aimedis Center coordinates without absorbing patient data, so no single service becomes a bottleneck for clinical records.

A shared core beneath all six platforms means one account, one consent record, and one audit trail — not six separate identity and privacy systems to reconcile.

FHIR R4-native interoperability at the core layer lets specialist products (Decision Pro, Rehab, Insur, Support) plug into the same consent-checked access API instead of building their own data layer.

Consent-driven access is structural, not just policy: every read is checked against an active grant and written to a hash-chained audit log the patient can inspect.

The four-layer model separates concerns cleanly — infrastructure, interoperability, application, and ecosystem — so a change to one specialist product never touches the shared core.

Every application-layer platform and specialist product — Care Pro, Connect, Appointment, Pro, Onboarding, Center, Decision Pro, Rehab, Insur, and Support — shares the same underlying consent, audit, and FHIR R4 data model.

This architecture enables developers to build innovative healthcare technologies while maintaining the strict privacy and security standards required in the healthcare industry.