GuideVersion 1.0 — 202616 min read

Aimedis Developer Guide

Integrating with the Aimedis Platform Family

A narrative guide to building on the six connected Aimedis platforms — the shared identity and consent model, the end-to-end consent flow, FHIR R4 records, specialist module integration, and AVA.

Sections

Platform Family for Developers Integration Model Shared Account & Identity The Consent Flow Working with FHIR R4 Cross-Platform Flows

Platform Family for Developers

Aimedis is a family of six connected platforms behaving as one system on a single shared account, plus a set of specialist products built on the same shared core. Every integration starts with understanding how the pieces fit together.

Aimedis Care Pro

The patient’s health record — the identity and consent record-of-truth the consent & access API (Section 04) is built around.

Patients

Aimedis Connect

Chat, communities, and AVA; the platform where a professional verifies their license and earns the credential badge that gates Pro access.

Patients & professionals

Aimedis Appointment

Booking and practice calendars; a booking links into the patient’s Care Pro record automatically.

Patients & practices

Aimedis Pro

The professional workspace: consented record access, structured intake, and practice-wide views.

Doctors, nurses & practice staff

Aimedis Onboarding

A guided account-creation and intake wizard; its structured summary reaches Pro only with the patient’s consent.

New patients

Aimedis Center

The control room: a registry of every platform, their wiring and health, and the contracts between them. It never holds patient data.

Platform operators

Specialist products

Four specialist products extend the shared core: Aimedis Decision Pro (clinical decision support), Aimedis Rehab (neurorehabilitation), Aimedis Insur (insurer engagement), and Aimedis Support (community & feedback) — alongside VR/AR medical education modules. All of them sit behind the same shared identity and consent model described in Sections 03–04; their own integration surface is covered in Section 07.

Integration Model

The family is held together by a hub-and-spoke integration model, not a monolith. Aimedis Center is the hub: a registry and live health map of every platform, plus the documented contracts between them.

Aimedis Center is the hub — a registry and live health map of every platform, plus the documented contracts between them.

Each platform remains independently deployable; cross-platform record access always flows through the consent-checked access API — never through direct database access.

Cross-platform reads and writes happen through documented contracts — the consent & access API (owned by Care Pro), module APIs (Section 07), and the platform registry.

Every platform recognizes the same shared account and the same consent record; a grant issued once is honored everywhere it applies.

Shared Account & Identity

There is one account per person across the family. A patient — or a professional — signs up once, through Onboarding, Care Pro, or Connect, and the same identity works everywhere.

One shared account, usable from Onboarding, Care Pro, or Connect signup

A single, versioned consent record (GDPR Art. 9) stamped identically at signup

Practitioner license verification happens in Connect and produces a visible credential badge — the gate for requesting consented record access in Pro

Record access is never account-wide: it is always scoped by an explicit, patient-issued consent grant (Section 04)

API access uses Bearer tokens scoped to the patient or the practitioner, never an open-ended session

The Consent Flow

Record access is a pull model: a professional requests access, the patient authorizes it. No professional, and no integration, ever sees patient data without an active, valid consent grant.

Generate

The patient chooses which record categories to share — a full record, or a custom scope — and for how long, then the system generates a one-time or session PIN. Sensitive categories (mental health, HIV/sexual health, substance use) are never in a default share; they require a separate, explicit opt-in.

Redeem

The professional enters the patient ID and PIN once. On success, a scoped grant is created and the patient is notified immediately that access was granted.

Scoped access

The redeeming professional can read exactly the record categories in the grant scope — nothing more, and nothing implied by role alone.

Expiry & revocation

The PIN and the granted access run on two independent timers, so a patient can let a PIN lapse without touching an active grant. The patient can also revoke the grant outright at any time; revocation cuts access across every platform that redeemed it.

Break-glass (audited)

An emergency-override path exists for when a patient cannot provide a PIN. It requires multi-step confirmation, grants a strictly time-boxed window, and is always logged — the patient is notified immediately and the audit entry is permanent.

The four canonical endpoints

Consent & Access APIREST

POST   /api/consent/generate            # patient-side: create a scoped, PIN-protected grant
POST   /api/consent/redeem              # practitioner-side: redeem the PIN once, returns scoped access
GET    /api/consent/grants              # patient view: list active grants
DELETE /api/consent/grants/{consentId}  # instant revocation

Two terms matter here: the account-level GDPR Art. 9 consent record is the platform-wide opt-in captured at signup, while a grant is the PIN-protected, scoped share a patient creates for one professional. PINs are generated by the system, never chosen by hand, shown to the patient once, and stored only as salted hashes. Every redemption and every read lands in a hash-chained, tamper-evident audit log the patient can inspect.

Working with FHIR R4

Aimedis’s clinical data backend is FHIR R4-native. Every record category a patient can share maps to one or more FHIR resource types.

demographicsPatient

vitalsObservation (vital-signs)

diagnosesCondition

medicationsMedicationRequest, MedicationDispense

allergiesAllergyIntolerance

labsObservation (laboratory), DiagnosticReport

radiologyImagingStudy, DiagnosticReport

notesDocumentReference

mental_healthCondition, Observation, DocumentReference (tagged)Opt-in only

hiv_sexual_healthTagged resourcesOpt-in only

substance_useTagged resourcesOpt-in only

There is no open, general-purpose FHIR REST surface to browse. Every read is scoped to an active consent grant and to the resource types within it — the grant’s scope is the authorization, not a separate permissions system. The grant itself is stored as a FHIR Consent resource, and every access it permits is logged as a FHIR AuditEvent.

Cross-Platform Flows

Three integration patterns recur across the family — worth knowing before you design your own.

Booking becomes record

An appointment created in Aimedis Appointment appears automatically in the patient’s Care Pro record and in the practice’s schedule.

Intake, with consent

A structured intake collected in Aimedis Onboarding reaches Aimedis Pro only with the patient’s consent; the confirmed summary lands back in Care Pro for the patient to review.

Verification gates access

A professional’s license verification in Aimedis Connect produces a visible credential badge — without it, Pro will not allow a consented-access request to be initiated at all.

Specialist Module Integration

Four specialist products expose their own domain APIs on top of the shared identity and consent core described in Sections 03–04: Aimedis Decision Pro, Aimedis Rehab, Aimedis Insur, and Aimedis Support. Every module endpoint is still consent-checked and audit-logged the same way.

Aimedis Rehab — Neurorehabilitation

Aimedis Rehab APIREST

GET  /api/rehab/assessments/{patientId}   # validated clinical scale scores (FIM, Barthel, Berg Balance, NIHSS, MoCA, GCS) with automatic scoring
POST /api/rehab/xr-sessions               # start an Unreal Engine XR training session with AI-adaptive difficulty
GET  /api/rehab/wearables/{patientId}     # synced wearable and device metrics (Withings, Oura, WHOOP)
GET  /api/rehab/benchmark/{patientId}     # 7-dimension clinician benchmark radar

Aimedis Insur — Insurance Engagement

Aimedis Insur APIREST

GET  /api/insur/members/{memberId}/benchmark-score  # proprietary 7-dimension benchmark score (0-1000)
GET  /api/insur/members/{memberId}/rewards          # premium rewards tier (Bronze to Diamond) and current reduction
GET  /api/insur/members/{memberId}/tasks            # daily AI-recommended health tasks
POST /api/insur/tasks/{taskId}/verify                # submit task completion evidence
POST /api/insur/care-pro/sync                        # bidirectional Care Pro EHR connector sync

Aimedis Decision Pro — Clinical Decision Support

Aimedis Decision Pro APIREST

POST /api/decision-pro/triage             # non-binding AI triage (5 care levels, 66 specialties, verified ICD-10-GM codes)
POST /api/decision-pro/consent/redeem     # redeem a Patient ID + PIN to pull records (FHIR R4 Consent, pull model)
POST /api/decision-pro/consent/revoke     # revoke an active consent grant
GET  /api/decision-pro/care-plan/{caseId} # forensic care-plan PDF archive
GET  /api/decision-pro/audit-chain/verify # verify the tamper-evident SHA-256 audit hash chain

Aimedis Support — Support & Feedback Command Center

Aimedis Support APIREST

GET  /api/support/surveys                       # polls and multi-page surveys
POST /api/support/surveys/{surveyId}/responses  # submit a survey response
GET  /api/support/nps                           # NPS campaign scores with trend data
POST /api/support/ava/chat                       # query the AVA support assistant
POST /api/support/moderation/{itemId}            # apply a moderation action to a community board item

AVA in Your Integration

AVA is Aimedis’s ecosystem-wide AI assistant — one assistant with several product-specific surfaces, not six separate bots.

1Health-record assistant in Aimedis Care Pro

2Communication assistant in Aimedis Connect

3Clinical-support assistant in Aimedis Pro

4Rehab coach in Aimedis Rehab

5Health coach in Aimedis Insur

6Support assistant in Aimedis Support

There is no public AVA API today — AVA only appears inside its own product surfaces. Programmatic access for integrators is a roadmap item (Section 12); register interest through the partner program.

AVA is an assistant, not a doctor: it never diagnoses. Where a product surface frames a clinical recommendation, it is presented as non-binding decision support — the licensed clinician always decides.

Internationalization

The Aimedis UI ships in 14 languages with full right-to-left support for Arabic and Urdu. If your integration renders any Aimedis-sourced UI or copy, test it in an RTL layout — it needs to mirror cleanly, not just flip text direction.

14 languages — platform UI30+ languages — AVA conversationFull RTL — Arabic, Urdu

These are two distinct figures — the 14-language UI and AVA’s 30+ conversational languages — do not conflate them in your own documentation.

Security Expectations

Every layer of the platform is built around encryption, strict access control, and an immutable audit trail. Your integration inherits these controls — it does not need to reimplement them.

Encryption of data in transit and at rest

Row-level security on clinical data stores

Role-based access control

Authenticated, scoped Bearer-token APIs

Rate limiting on sensitive operations, including PIN redemption attempts

Hash-chained, tamper-evident audit logging of every record-access event in the family core

Standards Alignment

GDPRHIPAA-InspiredISO 27001 PracticesHL7 FHIR

Error Handling & Operations

Consent-gated access fails safely and explicitly. Design your integration around these conditions rather than treating them as edge cases.

invalid_pinThe PIN entered does not match an active grant.

pin_expiredThe PIN’s own expiry window has passed — independent of the grant’s expiry.

patient_not_foundNo matching patient ID.

already_grantedA grant already exists for this patient and professional pair.

PIN redemption is rate-limited with a lockout after repeated failures. Surface this to the user clearly rather than retrying silently.

Revocation is immediate and cuts access on every platform that redeemed the grant. A Bearer token that was valid a moment ago can start failing consent checks as soon as the patient revokes — treat a sudden access-revoked response as expected behavior, not a bug to suppress.

Roadmap

Roadmap — not live today

The following are announced directions, not shipped capabilities — do not build against them yet.

Webhooks

Event notifications for consent-lifecycle changes (grant redeemed, revoked, expired).

Public self-service API keys

An API-key flow that does not require going through the partner program for every credential.

Client libraries

Official SDKs to reduce boilerplate around the consent flow and FHIR resource handling.

Sandbox environment

A self-service environment with synthetic data for integration testing.

Expanded FHIR resource surface

Additional FHIR R4 resource types beyond the current scope categories.

The consent flow, the shared identity model, and the module APIs above are what to build against today — everything else here is a direction, not a promise.

Back to Developer Guides Read Developer Portal