PortalVersion 1.0 — 202613 min read

Developer Portal

Partner Onboarding for the Aimedis Platform Family

A step-by-step walkthrough for partners — from requesting access through go-live, with the consent flow at the center of every integration.

Sections

Request Access Environments & Credentials Authentication The Consent Walkthrough Reading Records Module Integrations

Request Access

Access to Aimedis APIs is granted through the Aimedis partner program — there is no public self-service signup today. Four steps take you from application to production.

Request access

Apply through the Aimedis partner program with your organization and your integration’s use case.

Receive scoped credentials

Aimedis issues Bearer tokens scoped to what your integration actually needs — patient-facing, practitioner-facing, or both.

Integrate the consent flow

Build against the four consent endpoints (Section 04) — every read your app makes is gated by an active grant.

Go live

Complete the go-live checklist (Section 09) and move to production traffic.

Environments & Credentials

Credentials are scoped Bearer tokens, not general-purpose API keys — a token is issued for either the patient side or the practitioner side of an integration, matching how the consent flow itself is split.

Patient-scoped tokens — for generating PINs, listing grants, and revoking access

Practitioner-scoped tokens — for redeeming PINs and reading consented records

Demo access with representative, non-real data is arranged directly through the partner program — there is no public sandbox to self-provision today

A public self-service API-key flow and a self-service sandbox are on the roadmap (Section 10)

example-request.httpHTTP

Authorization: Bearer {practitioner_token}
# issued by Aimedis via the partner program, scoped to the practitioner side

Authentication

Access is granted through the Aimedis partner program. Consent-gated record access uses Bearer tokens scoped to the patient or the practitioner; every call is consent-checked and written to a tamper-evident audit log. A public self-service API program — API keys, client libraries, sandbox — is on the roadmap, not live today.

Authentication Flow

Partner registers an integration and use case with Aimedis

Aimedis issues a scoped Bearer token — patient-side or practitioner-side

Every API call is checked against active consent grants

The access event is written to the audit log

The Consent Walkthrough

Every Aimedis integration is built around this flow. It maps directly onto four canonical endpoints.

POST/api/consent/generate

Patient-side: create a scoped, PIN-protected grant.

Authorization: Bearer {patient_token}

{
  "scope": ["vitals", "diagnoses", "medications", "allergies"],
  "duration": "30d"
}

→ 200 OK
{
  "patientId": "pat-001",
  "pin": "482917",
  "expiresAt": "2026-04-18T23:59:59Z",
  "pinExpiresAt": "2026-03-19T22:00:00Z"
}

POST/api/consent/redeem

Practitioner-side: redeem the PIN once; the patient is notified immediately.

Authorization: Bearer {practitioner_token}

{
  "patientId": "pat-001",
  "pin": "482917"
}

→ 200 OK
{
  "granted": true,
  "consentId": "consent-xyz",
  "scope": ["vitals", "diagnoses", "medications", "allergies"],
  "expiresAt": "2026-04-18T23:59:59Z"
}

→ failure
{ "granted": false, "reason": "invalid_pin" }

GET/api/consent/grants

Patient view: list active grants.

GET /api/consent/grants?patientId=pat-001&status=active
Authorization: Bearer {patient_token}

DELETE/api/consent/grants/{consentId}

Patient-side: instant revocation — access is cut across every platform that redeemed the grant.

DELETE /api/consent/grants/consent-xyz
Authorization: Bearer {patient_token}

Sensitive categories — mental health, HIV/sexual health, and substance use — are opt-in only and never included by default, even in a "full record" share.

Reading Records

Once a grant is redeemed, your integration can read exactly the record categories in its scope — nothing else. Aimedis models clinical data as FHIR R4 resources; reads are always mediated by the active consent grant, not by a general-purpose open FHIR endpoint.

demographicsPatient

vitalsObservation (vital-signs)

diagnosesCondition

medicationsMedicationRequest, MedicationDispense

allergiesAllergyIntolerance

labsObservation (laboratory), DiagnosticReport

radiologyImagingStudy, DiagnosticReport

notesDocumentReference

There is no separate authorization step for individual resource reads — the scope on the redeemed grant is the authorization.

Module Integrations

Four specialist products — Aimedis Decision Pro, Aimedis Rehab, Aimedis Insur, and Aimedis Support — expose their own domain APIs on top of the same partner-program credentials and consent model described above.

Aimedis Rehab — Neurorehabilitation

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

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

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

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.

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.

Compliance & Audit Expectations

Every access your integration makes inherits the family’s compliance posture.

The patient is notified immediately whenever a grant is redeemed against their record

Revocation is immediate — access is cut across every platform that redeemed the grant

Every record access in the family core is written to a hash-chained, tamper-evident audit log the patient can inspect

Compliance mode (GDPR- or HIPAA-oriented language) is set at the institution level and shapes the consent language your integration should surface

A break-glass emergency-access path exists for when a patient cannot provide a PIN — it is multi-step, time-boxed, and fully audited; never build a silent bypass of the consent flow

Go-Live Checklist

Before requesting production traffic, confirm the following with the partner program.

Your integration only requests the scope categories it actually needs — no default "full record" share unless you need one

Sensitive categories (mental health, HIV/sexual health, substance use) are never assumed — you handle the opt-in explicitly if you need them

Your error handling covers invalid_pin, pin_expired, patient_not_found, and already_granted

Your integration treats a revoked grant as an expected state, not a bug

You have reviewed the compliance-mode implications (GDPR/HIPAA) for your target market with the partner program

You have completed an end-to-end walkthrough of the consent flow with Aimedis before requesting go-live approval

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 and the module APIs above are what to build against today — everything here is a direction, not a promise.

Read Developer Guide Read API Reference