System Architecture
Platform Family, Four-Layer Architecture & Data Flow
An overview of the clinical platform family and its shared services. Aimedis Wiki adds a separate governed reference library for research, education, and AI retrieval.
Platform Family Diagram
Hub — Aimedis Center
An operator registry of configured platforms, integration contracts, and service-status information. Simulated probes and configured live probes have different meanings. Center links to applications; it does not store clinical records or enforce their authorization.
Platform Family — confirm shared account and consent contracts
Specialist Products — service-specific integration
Legend
Aimedis Wiki — governed reference library
Wiki supplies reference content to readers and connected AI applications through its own retrieval and authentication contract. Retrieved references support an application’s answers; they do not provide patient records or grant clinical consent.
Read the Wiki API integration guideFour-Layer Architecture
Layer 01 — Core Infrastructure
Layer 02 — Interoperability Layer
Layer 03 — Application Layer
Layer 04 — Ecosystem Layer
Legend
Consent, Data & AI — Cross-Cutting Concerns
Consent & Data Plane
Protected clinical reads require valid credentials, current patient consent, and the service’s permitted resource scope. Confirm the record-read interface and revocation timing in the partner contract; recheck access on every protected request.
AI Services
AVA is the assistant brand used in several product-specific surfaces. Capabilities, provider configuration, and data access are determined by the owning application.
Security Framework
Layer Documentation
Core Infrastructure
The clinical integration model combines shared identity, patient consent, health-record storage, and audit services. Confirm the precise service boundaries during partner onboarding.
Clinical applications must validate accepted credentials and current consent. Wiki reference retrieval is governed separately and does not authorize access to patient records.
Key Capabilities
Interoperability Layer
Approved service contracts define how participating platforms and external systems exchange data. FHIR R4 provides resource patterns, but supported operations and coverage are service-specific.
Care Pro owns the clinical consent and record-access contract. The partner service supplies the actual origin, scopes, protected record-read interface, and revocation behavior.
Key Capabilities
Application Layer
The family includes Care Pro, Connect, Booking, Pro, Onboarding, and Center, alongside specialist products for clinical decision support, neurorehabilitation, insurance engagement, community support, and immersive education. Shared-service adoption is deployment-specific.
Clinical applications integrate with the shared services through their approved contracts. Aimedis Wiki is a separate governed reference library with its own retrieval and authentication contract.
Key Capabilities
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 Booking and Pro, an insurer white-labels Aimedis Insur.
Key Capabilities
Why This Architecture Matters
Independent services connect through approved contracts. Aimedis Center supplies registry and service-status information; it does not control clinical requests, deployment, or patient consent.
Shared account and consent patterns can reduce duplicate workflows, but participating services must confirm account linking, consent propagation, and enforcement. Common documentation is not proof of one shared runtime.
FHIR R4 provides a common vocabulary for clinical resource interfaces. Confirm each specialist product’s supported resources, read/write operations, and authorization contract.
Protected clinical operations need explicit authorization checks and auditable outcomes. Confirm coverage, revocation timing, and audit guarantees with the owning service.
The four-layer model separates infrastructure, interoperability, applications, and ecosystem participants. Changes still require review of affected shared contracts and dependencies.
Clinical record access and Wiki reference retrieval have distinct authorization boundaries: a Wiki API credential never grants access to a patient’s record.
Use this architecture as an integration map. The approved service contract and verified deployment behavior determine the interface and the privacy and security controls your application must preserve.