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 reviewed reference library and terminology server for research, education and AI retrieval.
Platform Family Diagram
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.
- Aimedis Care
- Aimedis Connect
- Aimedis Booking
- Aimedis Pro
- Aimedis Onboard
- Aimedis Decision
- Aimedis Rehab
- Aimedis Support
- Aimedis XR
Aimedis Wiki — governed reference library
Wiki supplies reviewed reference content and terminology (ICD-10 WHO, ICD-10-GM, ICD-11) to readers and connected AI applications through its own API and keys. 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
- Shared account & identity
- Versioned GDPR Art. 9 consent
- Health-record storage
- Audit logging
- Record-share API (Aimedis Care, FHIR R4)
- Service-specific FHIR R4 resource interfaces
- Practice-software interface (Pro: FHIR R4, HL7 v2.5.1)
- Wiki terminology (ICD-10 WHO, ICD-10-GM, ICD-11)
- Aimedis Care
- Aimedis Connect
- Aimedis Booking
- Aimedis Pro
- Aimedis Onboard
- Aimedis Center
- Aimedis Decision
- Aimedis Rehab
- Aimedis Support
- Aimedis XR
- Healthcare providers & practices
- Developers
- Medical researchers
- Educators
- Platform operators
Consent, Data & AI — Cross-Cutting Concerns
Consent & Data Plane
A protected clinical read needs a valid token, the patient's active share and current consent, and a shared category; Aimedis Care checks all of them on every read.
- Service-specific FHIR R4 resource interfaces
- Consent-checked access API owned by the health-record platform (Aimedis Care)
- Append-only audit log in Aimedis Care, entries linked by SHA-256 hashes
- Confirm database authorization and row-level security where applicable
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.
- AVA as a product-surface assistant, not a standalone platform
- Clinical decision support is explicitly non-binding — the licensed clinician always decides
- AI processing of patient records requires clinical authorization; Wiki reference retrieval follows its separate contract
- AVA’s conversation languages vary by product; verify them separately from the 18 interface languages
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
Layer Documentation
Core Infrastructure
The family shares one account (except Rehab and Wiki), patient consent with record shares in Aimedis Care, and audit logs. Each product keeps its own data; another system reads it only through the interfaces these guides document.
Clinical applications must validate accepted credentials and current consent. Wiki reference retrieval is governed separately and does not authorize access to patient records.
- Shared account & identity
- Versioned GDPR Art. 9 consent
- Health-record storage
- Audit logging
Interoperability Layer
Aimedis apps exchange data through the shared family database and signed server-to-server requests (partner-hmac-v1). Outside systems use the documented interfaces: Aimedis Care's patient-granted FHIR R4 access, Aimedis Pro's practice-software interface (FHIR R4, HL7 v2.5.1) and the Wiki API, which also serves ICD-10 WHO, ICD-10-GM and ICD-11 terminology.
Aimedis Care owns the patient's record shares: the patient creates and revokes them in the app, and a recipient reads the shared categories as FHIR R4 with a token valid for 15 minutes.
- Record-share API (Aimedis Care, FHIR R4)
- Service-specific FHIR R4 resource interfaces
- Practice-software interface (Pro: FHIR R4, HL7 v2.5.1)
- Wiki terminology (ICD-10 WHO, ICD-10-GM, ICD-11)
Application Layer
The family includes Care, Connect, Booking, Pro, Onboard, and Center, alongside specialist products for clinical decision support, neurorehabilitation, community support, and immersive education. Shared-service adoption is deployment-specific.
The applications connect to each other through the shared family database and signed server-to-server requests. Aimedis Wiki is a separate reference library and terminology server with its own API and keys.
- Aimedis Care
- Aimedis Connect
- Aimedis Booking
- Aimedis Pro
- Aimedis Onboard
- Aimedis Center
- Aimedis Decision
- Aimedis Rehab
- Aimedis Support
- Aimedis XR
Ecosystem Layer
The broader network of organizations, professionals, and builders interacting through the platform family — practices, healthcare professionals, developers, researchers, educators, and platform operators.
This is where third-party integration happens: a practice connects its practice software to Aimedis Pro, an application reads a record a patient shares in Aimedis Care, an AI application calls the Wiki API.
- Healthcare providers & practices
- Developers
- Medical researchers
- Educators
- Platform operators
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.
- One account for seven apps and one record-share model in Aimedis Care spare people duplicate sign-ups and consents; each app still runs and deploys on its own.
- FHIR R4 is the common format: Care, Pro, Rehab and Decision build their FHIR output on one shared library, and diagnoses carry an ICD-10 coding only when the Wiki terminology server confirms it.
- 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.