PortalVersion 1.0 — 202613 min read

Partner Onboarding

Partner Onboarding for the Aimedis Platform Family

A clinical partner-onboarding walkthrough — from requesting access through go-live. Wiki reference retrieval follows its own documented API and authentication contract.

Sections

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

Request Access

Request clinical integration access through the Aimedis partner program. This page explains onboarding; it does not issue credentials. Confirm service availability and the production contract with your partner contact.

Request access

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

Receive scoped credentials

Confirm credential issuance and supported patient or practitioner scopes with the service owner. The examples below use scoped Bearer tokens.

Integrate the consent flow

Confirm the clinical service contract, then implement the grant and protected record-read flow illustrated in Section 04.

Go live

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

Environments & Credentials

The examples distinguish patient-scoped and practitioner-scoped Bearer credentials. The partner service defines the actual credential type, permitted operations, expiry, and renewal process.

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

Clinical access is arranged through the partner program. The examples use patient- or practitioner-scoped Bearer credentials; confirm token issuance, renewal, expiry, and supported scopes with the service owner. Wiki retrieval uses its separate authentication contract.

Authentication Flow

Partner registers an integration and use case with Aimedis

The service owner confirms accepted credentials and patient or practitioner scopes

Protected clinical record requests require valid credentials and active consent

Confirm how the service records and exposes the access audit event

The Consent Walkthrough

This illustrates a clinical consent flow with four example operations. Confirm their service origin and request/response contract during onboarding; Wiki reference retrieval does not use patient PIN grants.

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: revoke a grant. Confirm timing in your service contract and recheck access on every protected request.

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

Handle sensitive categories such as mental health, HIV/sexual health, and substance use through explicit authorization. Confirm the service’s actual scope rules and default-share behavior.

Reading Records

The consent examples return grant metadata, not clinical records. The partner service supplies the protected record-read endpoint, accepted credentials, resource schema, and error contract. A read must satisfy both the service’s access controls and the current grant scope.

demographicsPatient

vitalsObservation (vital-signs)

diagnosesCondition

medicationsMedicationRequest, MedicationDispense

allergiesAllergyIntolerance

labsObservation (laboratory), DiagnosticReport

radiologyImagingStudy, DiagnosticReport

notesDocumentReference

A grant is one part of authorization. Recheck the service credentials, current consent, and permitted resource scope on every protected read using the partner service’s contract.

Module Integrations

These examples cover Decision Pro, Rehab, Insur, and Support. Each service owner confirms endpoint availability, accepted credentials, and the permissions or patient consent required for an operation.

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; 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

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

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.

Compliance & Audit Expectations

Confirm the clinical service’s consent, audit, and data-handling requirements during onboarding, then apply them to your own integration.

Confirm patient notification behavior and delivery guarantees when a grant is redeemed

Confirm revocation timing in your service contract and recheck access on every protected request

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

Confirm the applicable consent language, institutional policy, and data-handling requirements; interface wording alone does not establish compliance

Emergency access requires an explicitly supported and authorized service process. Confirm approval, time limits, notifications, and audit retention; never add a silent consent bypass

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.

Build clinical integrations against the approved contract supplied during partner onboarding. The examples explain the model; roadmap items do not establish availability or a delivery date.

Read Developer Guide Read API Reference