Aimedis Developer Guide

The platforms share one Aimedis account (except Rehab and Wiki) and open a patient's record to others only through the patient's share. Aimedis Wiki adds a reviewed reference library and a terminology server whose API never grants access to patient records.

• Aimedis Care

  The patient's health record. The patient shares chosen record categories with a PIN, and the recipient reads them as FHIR R4 (Sections 04 and 05).

  Patients

• Aimedis Connect

  Secure messaging, end-to-end encrypted video calls, groups, information events and AVA. A clinician registered in Aimedis Pro counts as verified here and can open a record a patient shares in a chat.

  Patients & professionals

• Aimedis Booking

  Online booking and practice calendars. Aimedis Pro reads the bookings, and practice software sees them through Pro's interface (Section 07). Practitioners can subscribe to a private calendar feed.

  Patients & practices

• Aimedis Pro

  The professional workspace: consented record access, structured intake, practice-wide views and the practice-software interface (FHIR R4, HL7 v2.5.1, GDT export).

  Doctors, nurses & practice staff

• Aimedis Onboard

  Patient intake before a visit, by AVA interview or forms. Aimedis Pro opens the intake with the patient's AIM-ID and intake PIN or through a visit grant; with an account, the answers also reach Aimedis Care, where the patient confirms them item by item.

  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

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.
• Aimedis apps exchange data through the shared family database or through signed server-to-server requests (partner-hmac-v1). Outside systems cannot use either path; they use the interfaces in Sections 04 to 07.
• Record access always starts with the patient's share in Aimedis Care. Aimedis Wiki has a separate API and keys, which never open patient records.

One Aimedis account serves patients and professionals across the family apps. Outside systems never receive an Aimedis sign-in; they use the credential of the interface they call.

• One Aimedis account signs in to seven apps: Care, Connect, Onboard, Decision, Booking, Pro and Support. Rehab and Wiki keep their own sign-in, and no sign-in token is offered to outside systems
• Aimedis Care issues a record token only while the patient's consent to processing is current, and every read checks it again
• Professional status comes from Aimedis Pro's practitioner registry; Connect reads it, and Aimedis Care checks it before a professional opens a record through Connect
• Treat account identity and patient authorization as separate checks; confirm the protected operation and permitted record scope in the service contract (Section 04)
• Record access uses a Bearer token that Aimedis Care issues for the patient's AIM-ID and PIN. It lasts 15 minutes, carries the shared categories and is checked against the share on every read

The patient decides. The patient creates a share in Aimedis Care and gives the AIM-ID and PIN to the professional or service that should read it; nothing outside Aimedis Care can create, list or revoke a share.

Record-access endpoints (Aimedis Care)

# Base URL: https://care.aimedis.com · the patient creates and revokes shares in the app, never through the API
POST /api/access/redeem              # AIM-ID + PIN → Bearer token for 15 minutes (no record data)
GET  /api/access/records             # every shared category as one FHIR R4 collection Bundle
GET  /api/fhir/metadata              # CapabilityStatement, FHIR 4.0.1 (no token needed)
GET  /api/fhir/{type}                # search: _id, _count (1-200, default 100), _offset
GET  /api/fhir/{type}/{id}           # read one resource
GET  /api/fhir/Patient/{id}/$summary # patient summary document (IPS structure, not profile-validated)

Each shared category maps to FHIR R4 (4.0.1) resource types. The endpoint is read-only: read and search with _id, _count (1–200, default 100) and _offset. It implements no SMART authorization, writes, history or transactions, and claims no profile conformance.

profile

Patient

vitals

Observation (vital-signs)

laboratory

Observation (laboratory)

diagnoses

Condition, AllergyIntolerance

medications

MedicationStatement

documents

DocumentReference

diary

DocumentReference (diary summary, only in GET /api/access/records)

Three hand-offs between Aimedis apps that matter for integrators. They run inside the family; outside systems take part only through the interfaces in Section 07.

1. 01

   Booking reaches the practice

   Bookings made in Aimedis Booking appear in Aimedis Pro's practice schedule. Practice software reads them through Pro's FHIR Appointment search or HL7 SIU feed and can block busy times there (Section 07).

2. 02

   Intake, with consent

   Aimedis Pro opens an intake with the patient's AIM-ID and intake PIN, or through a visit grant the patient gives for one appointment (at most 3 days). With an account, the answers are also sent to Aimedis Care, where the patient confirms them item by item.

3. 03

   Verification gates access

   Professional status comes from Aimedis Pro. Connect treats a clinician registered in Pro (not a Pro administrator account) as verified and lets that professional open a record a patient shares in a chat; Aimedis Care checks the professional status again before it issues a token.

These are the interfaces Aimedis Pro, Aimedis Rehab and Aimedis Decision offer other systems today. Only Pro's practice-software endpoints are for unattended server-to-server use; the Rehab and Decision endpoints serve signed-in patients and clinicians who download or upload a file. Aimedis Support offers no API for other systems: its help widget runs only inside Aimedis's own sites.

# Base URL: https://pro.aimedis.com · Authorization: Bearer apx_… (created by a practice administrator in Pro)
GET    /api/interop/fhir/r4/metadata             # CapabilityStatement, FHIR 4.0.1 (no credential)
GET    /api/interop/fhir/r4/Practitioner[/{id}]  # the practice's practitioners (appointments:read)
GET    /api/interop/fhir/r4/Schedule[?actor=]    # one Schedule per practitioner (appointments:read)
GET    /api/interop/fhir/r4/Appointment?date=&practitioner=&_count=&_offset=  # Aimedis bookings (appointments:read)
POST   /api/interop/fhir/r4/Appointment          # block busy time; PUT/DELETE …/Appointment/blk-{id} (appointments:write)
POST   /api/interop/hl7v2                        # one HL7 v2 message: SIU S12-S17 or ORU^R01 → ACK (2.5.1)
GET    /api/interop/hl7v2/siu?since=             # SIU v2.5.1 messages for bookings changed since (appointments:read)

# Base URL: https://rehab.aimedis.com · the signed-in patient, or a clinician the patient granted access
GET  /api/rehab/patients/{id}/fhir-export                    # FHIR R4 collection Bundle of the rehab record (download)
GET  /api/rehab/patients/{id}/discharge-report?episode={id}  # FHIR R4 document Bundle: discharge summary of one episode
POST /api/rehab/referrals/import                             # clinician uploads a FHIR R4 ServiceRequest or Bundle (≤ 6 MB)

# Base URL: https://decision.aimedis.com · the consultation's patient or physician, signed in
GET  /api/interop/care-plan/{consultationId}/fhir  # newest care plan as a FHIR R4 document Bundle (with the PDF)

AVA is the assistant inside every Aimedis app, with product-specific tasks. For medical questions, the AVAs of the seven v2 apps take their evidence from the Aimedis Wiki research endpoint (Aimedis Wiki, Aimedis RAG, PubMed, Public Medical Library).

1. 01Health-record assistant in Aimedis Care
2. 02Communication assistant in Aimedis Connect
3. 03Clinical-support assistant in Aimedis Pro
4. 04Rehab coach in Aimedis Rehab
5. 05Support assistant in Aimedis Support

This website and the v2 applications (Care, Pro, Booking, Onboard, Connect, Decision and Rehab) offer 18 interface languages, including right-to-left Arabic, Urdu and Hebrew. Some newly written product texts are still being translated and reviewed. Verify the languages of your target application and test any translated integration UI in its actual layout.

• 18 languages — website and v2 apps
• AVA conversation languages — product-dependent
• RTL layout — Arabic, Urdu, Hebrew

The 18 interface languages and the languages AVA can converse in describe different surfaces. Confirm actual language support with the target application.

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
• An append-only audit log in Aimedis Care whose entries are linked by SHA-256 hashes, shown to the patient as access history

Standards and Controls to Confirm

• GDPR
• Market-specific health-data rules
• Information-security controls
• HL7 FHIR R4
• HL7 v2.5.1

Aimedis Care answers every refused PIN the same way, without revealing whether a patient exists. Record reads return errors as FHIR OperationOutcome resources.

401

Redeem: unknown patient, wrong PIN, a spent single-use PIN or an ambiguous match, all with one answer. Read: the token is missing or expired, or its share was revoked.

403

A read asks for a resource type whose category the patient did not share.

429

Too many attempts: 5 per 15 minutes per client address and 10 per 15 minutes per patient. Five wrong PINs lock that requester out of the share, ten lock it for everyone, until 1 hour after the first wrong PIN. Respect Retry-After.

503

A rate limiter or the token service is unavailable, and Aimedis Care refuses rather than guess. Retry later.

None of the following is available today. Only the last item is planned, and only for a concrete partner project; no date is set. Do not build against them.

• Webhooks

  Not offered. Aimedis apps notify each other only through signed server-to-server requests that outside systems cannot use.

• Self-service credentials

  Not offered. Credentials come from a Wiki administrator (awr_ keys), a practice administrator in Aimedis Pro (apx_ credentials) or the patient (a PIN share).

• Client libraries

  Not published. The Wiki team can provide TypeScript and Python sample clients for the Wiki API; there are none for the care platforms.

• Sandbox environment

  Not offered: there is no public test environment with synthetic data.

• Interface gateway

  Planned only for a concrete partner project, not built: a separate gateway, for example for HL7 v2 over MLLP and SMART Backend Services.