GuideVersion 1.0 — 202616 min read

Aimedis Developer Guide

Integrating with the Aimedis Platform Family

A narrative overview of clinical platform integration — shared identity and consent, FHIR R4 records, specialist modules, and AVA. Aimedis Wiki reference retrieval follows a separate contract.

Sections

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

Platform Family for Developers

The clinical platform family uses shared identity and patient-consent integration patterns with specialist products. Confirm each deployment’s boundaries. Aimedis Wiki adds a governed reference library whose retrieval does not grant access to patient records.

Aimedis Care Pro

The patient health-record application and the service responsible for the clinical consent and record-access contract illustrated in Section 04.

Patients

Aimedis Connect

Chat, communities, AVA, and professional-verification workflows. Confirm how a verified credential is consumed by Aimedis Pro in the participating deployment.

Patients & professionals

Aimedis Booking

Booking and practice calendars, with patient-record handoffs defined by the participating services.

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 workflow. Sharing its structured summary with Aimedis Pro requires the applicable patient authorization and service contract.

New patients

Aimedis Center

An operator registry of configured platforms, integration contracts, and service-status information. Registry entries and simulated or live probes must be distinguished from verified runtime availability.

Platform operators

Specialist products

Aimedis Decision Pro, Aimedis Rehab, Aimedis Insur, and Aimedis Support cover clinical decision support, neurorehabilitation, insurance engagement, and community feedback. Aimedis XR supports immersive education. Each product’s actual identity, consent, data, and integration contract must be confirmed separately; Section 07 gives illustrative integration areas.

Integration Model

The architecture describes independent services connected through approved integration contracts. Aimedis Center provides an operator registry and service-status information; it is not the runtime controller for clinical data or authorization.

Aimedis Center records configured platforms, integration contracts, and service-status information. The registry does not itself control clinical requests, deployments, or patient consent.

Platforms are independently deployable. Use approved service contracts for cross-platform record access and verify the receiving service’s authorization requirements.

Confirm each cross-platform read or write with the owning service. A registry entry or example endpoint does not establish that an interface is deployed or accessible.

Shared account and consent patterns inform clinical integration, but accepted credentials and enforcement are deployment-specific. Aimedis Wiki has a separate reference-retrieval and authentication contract.

Shared Account & Identity

Clinical integration can connect patient and professional identities across Onboarding, Care Pro, and Connect. Confirm account linking, accepted credentials, and scope enforcement with the service owner; Wiki retrieval has its own authentication contract.

Confirm account linking and accepted identities across Onboarding, Care Pro, and Connect in the participating deployment

Confirm the versioned signup consent record and its propagation across participating services; do not infer shared enforcement from common wording

Confirm professional verification in Connect and the exact credential checks required by Pro before clinical access

Treat account identity and patient authorization as separate checks; confirm the protected operation and permitted record scope in the service contract (Section 04)

The examples use patient- or practitioner-scoped Bearer tokens; the service owner defines accepted credentials, renewal, and expiry

The Consent Flow

The illustrated flow begins with a professional requesting access and the patient authorizing a limited share. Confirm the receiving service’s checks and any separately authorized emergency process.

Generate

In the illustrative flow, the patient selects record categories and an access window before a PIN is generated. Handle sensitive categories such as mental health, HIV/sexual health, and substance use through explicit authorization; confirm the actual scope rules with the service owner.

Redeem

The example exchanges a patient ID and PIN for scoped grant metadata. Confirm notification behavior and the separate protected record-read contract before implementation.

Scoped access

Protected reads must satisfy the service’s accepted credentials, current authorization, and permitted resource scope. Grant metadata alone is not permission to bypass other access controls.

Expiry & revocation

The PIN and the granted access have independent expiry windows. Confirm revocation timing in your service contract and recheck access on every protected request.

Break-glass (audited)

Use emergency access only where the service explicitly supports and authorizes it. Confirm approval steps, a bounded access window, patient notification, and audit retention; never add an unapproved bypass.

Illustrative consent 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}  # revoke access; timing is service-contract specific

Keep the signup consent record separate from an operation-specific clinical access grant. The latter limits the record share for a professional. Confirm PIN generation, storage, expiry, audit coverage, and notification behavior with the service owner; common consent wording does not establish a single enforcement service.

Working with FHIR R4

The table illustrates how record categories can map to FHIR R4 resources. It does not establish that every product exposes these resources or implements the same FHIR operations.

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

The consent examples describe grant metadata, not a record payload. The partner service supplies the protected record-read endpoint, accepted credentials, FHIR resource schema, and error contract. Recheck authentication and active consent on every protected request; a grant does not replace the service’s other access controls.

Cross-Platform Flows

These three integration patterns help explain possible handoffs. Confirm each flow’s deployed contract before building against it.

Booking becomes record

A booking-to-record handoff can connect Aimedis Booking, Care Pro, and the practice schedule. Confirm which updates are delivered, their timing, and failure handling in the participating deployment.

Intake, with consent

A structured intake handoff can connect Aimedis Onboarding, Pro, and Care Pro. Confirm authorization, the transmitted fields, and how the patient reviews the resulting summary.

Verification gates access

Connect provides professional-verification workflows. Confirm which credential or badge Pro checks and whether the required checks are enforced for the protected operation.

Specialist Module Integration

The following examples illustrate integration areas for Decision Pro, Rehab, Insur, and Support. Confirm each module’s actual endpoint, permissions, consent requirements, and audit behavior with its service owner before implementation.

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; confirm the protected record-read contract separately
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 the assistant brand used across several product-specific surfaces. Its capabilities, data access, and provider configuration depend on the application.

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

This guide does not define a general-purpose public AVA integration API. Confirm any programmatic access with the owning product; its internal assistant endpoint is not automatically a supported partner contract.

AVA supports users within the owning application’s permitted scope. Clinical decision support is non-binding and requires review by a licensed clinician.

Internationalization

This website supports 14 UI languages, including right-to-left Arabic and Urdu. Product coverage varies. Verify the languages supported by your target application and test any translated integration UI in its actual layout.

14 languages — website UI30+ AVA languages — product-dependentRTL layout — Arabic, Urdu

The 14 website UI languages and the advertised 30+ conversational languages describe different surfaces. Confirm actual language support with the target application.

Security Expectations

Clinical integrations must preserve encryption, scoped access, and auditability. Confirm the controls provided by the service and enforce the corresponding requirements in your own application, including token handling and protected reads.

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

Confirm audit coverage, integrity checks, retention, and patient visibility for each protected operation

Standards and Controls to Confirm

GDPRHIPAA-InspiredISO 27001 PracticesHL7 FHIR

Error Handling & Operations

Design for explicit authorization failures. These illustrative reasons help explain the flow; the service contract defines the actual status codes and error schema.

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.

Confirm the service’s PIN rate limits and lockout behavior. Surface rejection clearly and use bounded retries instead of silently repeating failed requests.

Confirm revocation timing in your service contract and recheck access on every protected request. A previously valid token does not establish that consent remains active. Treat an access-revoked response as an expected state and stop using the protected data.

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.

Use the approved contract supplied during partner onboarding to implement clinical access. The examples above explain the integration model; roadmap items do not establish availability or a delivery date.

Back to Developer Guides Read Developer Portal