Platform Architecture & Integration Addendum

Aimedis applications own different workflows and expose specific interfaces. The architecture is best understood through service ownership and explicit handoffs, rather than a single shared runtime beneath every product.

Common branding, a shared look and a shared account do not establish universal consent, storage or deployment. Current interfaces and their receiving implementations determine what is connected.

One Aimedis account, a shared Supabase identity, serves Care, Pro, Booking, Onboard, Connect, Decision and Support. Since 8 November 2026 they share one session cookie for the aimedis.com domain, which expires after seven days without use. Care, Onboard, Connect, Decision and Booking’s patient side use that session directly. Pro (with its own 12-hour professional session), Booking’s practice side and Support are bridges: each creates its own session only from a shared session verified with the identity service, never stores its refresh token, and ends its session when the shared one ends or belongs to someone else. Signing out in one application signs the person out of all of them on that device. A shared session therefore means a shared identity, not shared permissions.

Rehab has its own account system, which Support accepts as a second sign-in. Wiki requires eligible administrator access and organization approval. Specialist products have their own roles and configuration.

An identity match is only one part of integration. The caller still needs authorization for the target service, requested scope and current session. Connect and Pro have their own professional review mechanisms. A professional credential badge is not a substitute for a patient-record grant.

No central gateway routes clinical traffic. Each application checks access to the data it owns and calls a sibling only through a configured interface. Shared tables in the common database project, such as appointments, are read under that database’s access policies.

An Aimedis Care patient chooses a 6–12 digit sharing PIN, single-use or multi-use, and a duration of one hour, eight hours, one day, seven days, 30 days, 90 days or until revoked. Pro shows an until-revoked grant as such, never as a date. Redemption returns a 15-minute bearer and scope metadata; it does not return the medical records themselves. Protected reads check the current grant and processing-consent state.

The current Pro/Care bridge does not supply a bearer-renewal endpoint. After the 15-minute bearer expires, the supported flow may require re-redeeming an eligible multi-use PIN or obtaining a new single-use share. A longer consent period must not be displayed as continuous professional access.

Pro’s live Care bridge is read-only and does not yet map every record category. In Connect, a direct-message record-share announcement identifies the handoff; the eligible clinician must separately supply the Care PIN. Posting the announcement alone grants no record access.

Revocation is a service-side access decision. Check grant status on subsequent reads, stop using expired access and present denials clearly. Revocation does not undo information already received under a valid permission.

The inspected applications contain combinations of authenticated endpoints, role checks, database policies, input validation, private storage, rate limits and audit records. Their coverage and operational guarantees differ by service.

Hash-linked audit entries support integrity checks within their implementation. They are not evidence of blockchain anchoring, immutable retention or independent protection. Deployment-specific persistence, backup, access review and monitoring remain necessary.

A standard mentioned in source code or a design document is not certification. Healthcare-data processing, hosting, provider agreements and the intended clinical use require their own applicable approvals and operational evidence.

The assistant brand does not imply shared memory or identical tools across the applications. Booking, Pro, Onboard, Connect, Decision and Rehab run copies of one shared engine for planning a turn and gathering its evidence, and Aimedis Care uses its own planner over the same research call. At the time of writing, AVA uses Anthropic’s Claude Sonnet 5 in every application, a model fixed in code rather than chosen by configuration, and ElevenLabs for voice; Rehab adds D-ID for the video face. Available data and role permissions must still be inspected per product.

A fixed, multilingual emergency check runs before any model call in the medical AVAs; its notice comes first and does not depend on budgets, kill switches or the AI service.

For evidence-based workflows, treat retrieved excerpts as untrusted source material rather than instructions. Preserve citations and licence information. Distinguish a supported claim from a suggestion and show when retrieval or a provider fails.

Connect, Decision, Rehab and Support share one LiveKit server that Aimedis hosts at video.aimedis.com, each application with its own key. Relaying for restrictive networks runs over TLS on Aimedis’ own TURN service. The applications issue room access only to authorized participants; in Aimedis Decision rooms are opaque, hold at most two participants, and participants appear under role pseudonyms.

Media in Connect, Decision and Rehab is end-to-end encrypted with keys that the server does not hold. Aimedis Decision makes a fresh key for each meeting. In Connect the key is made on a participant’s device and shared through the end-to-end encrypted Matrix conversation; the server stores only a key epoch, and a guest receives the key in the fragment of a one-time link. The call’s data channel is encrypted as well. Rehab uses the call kit taken from Connect for its calls, group sessions and events.

The Zoom fallback is a separate path. It is offered per call and needs the patient’s consent in Aimedis Decision and every participant’s consent in Connect and Rehab; each consent is recorded. In Connect it uses the professional’s own Zoom host or a pool managed by an administrator.

The contract described here is the one served at wiki.aimedis.com at the time of writing, by the Wiki build of 10 November 2026. Since 8 November 2026 the AVAs of Care, Pro, Booking, Onboard, Connect, Decision and Rehab gather their evidence through the research interface, each with its own key.

Wiki separates source administration from reference retrieval. Applications retrieve through the reference API with an administrator-issued key (Authorization: Bearer awr_…), bound to one application, valid for 1–365 days or without expiry, and revocable at any time. Administrators can also retrieve through the workspace API with their own short-lived session, subject to organization checks and, where enrolled, MFA. A chosen AI model can use the retrieved passages through an authorized application server.

Wiki retrieval returns hits, insufficientEvidence and a retrieval mode; the research interface reports each stage as available, empty or unavailable. The calling application must keep each excerpt’s source, version, licence and available page or timestamp locator with the answer. An empty result is a valid outcome.

The reference API has its own contract: queries are 3–300 characters and results are limited to 1–6 excerpts. Keys can be issued for any Aimedis application or a custom application ID. Complete an acceptance test for each integration before describing it as operational. Legacy awk_ keys are disabled.

The exchange runs on one library, the same in Care, Pro, Decision and Rehab, for FHIR R4 (4.0.1), HL7 v2 and GDT 2.1, 3.0 and 3.5; each platform exchanges only the data it owns. GDT, a practice-software format, is one example of many. The library claims no national profile and no International Patient Summary conformance.

In their FHIR output, Care, Pro and Rehab code a diagnosis with the WHO’s ICD-10, used in a wide range of countries, or with a national edition such as ICD-10-GM, and only when the Wiki confirms the code in that edition. A five-character code that both editions hold, or a code the Wiki cannot confirm, keeps only its text. A stored code does not yet record the edition it came from, so a code printed by a third edition can still be read as a national one. ICD-11 codes keep their own coding.

Planned, not built: an Aimedis interface gateway that gives hospitals and practice software one address for HL7 v2 over MLLP, FHIR with SMART Backend Services and national e-health profiles that need certification. It will be built only with a concrete partner.

These distinctions describe implementation boundaries. They do not certify current uptime, production configuration, medical-device status or delivery to a particular customer.

Aimedis sells through Stripe. A professional is one Stripe customer with one monthly subscription per plan in Pro; a patient buys AVA Plus in Aimedis Care. The plan card shows a list price, and the amount charged is the one held in Stripe for the customer’s currency; if a currency has no amount in Stripe, nothing is sold in it.

Professionals’ own fees in Connect are destination charges to the professional’s own Stripe Express account. At the time of writing Aimedis sets no platform fee on them. A professional needs a payouts account and a billing profile before charging.

Organizations agree product access, user roles, external-provider costs, integration support and the included workflows in the deployment’s commercial arrangement. An implemented payment screen or an estimated benefit does not prove a current contract or financial outcome.

These documents explain product purpose, implemented workflows and material integration limits. They replace blanket claims about universal access, instant synchronization, a family-wide FHIR backend and identical AI behavior with product-specific descriptions.

They do not establish comparative clinical performance, certified compliance, validated cost savings or an addressable-market forecast. Assess those questions using evidence for the specific product, intended use and deployment.

Planned work includes storage of data in the region the law requires (EU data in the EU, US data in the US, UAE data in the UAE), an interface gateway for hospitals and practice software, further code systems in the Wiki once licensed, and the cross-application handoffs that are prepared but not in use, such as Aimedis Onboard intakes handed to Booking. Each proposed capability needs a defined owner, authorization model, implementation and acceptance evidence.

When an application or integration changes, update its public description and these documents together. Keep the distinction between available workflows and planned capabilities visible to patients, professionals and integration teams.