WhitepaperRevised English · 11 min read · 14 sections

Aimedis Whitepaper

Platforms, practical workflows and reviewed medical knowledge

A guide to the Aimedis applications, the people they serve and the workflows they support: patient records, professional care, communication, intake, appointments, rehabilitation, feedback and the Aimedis Wiki evidence library.

Functions described here depend on the product, permissions and configured services. An implemented feature or connector does not establish availability in every deployment. Planned capabilities are identified separately.

Executive summary

Aimedis develops applications for patients, healthcare professionals, practice teams, rehabilitation teams and organizations. Each application has a defined role. Connections between them support particular workflows and depend on configured interfaces, appropriate permissions and the receiving service.

Care Pro organizes personal health information. Pro supports professional work with authorized patient information. Onboarding collects structured intake, Booking supports scheduling, and Connect supports communication. Center gives operators a registry of participating systems and their integration contracts.

Decision Pro, Rehab, Insur and Support address specialist workflows. Aimedis Wiki is a separate, private library of reviewed medical reference material for people and authorized AI applications. It does not inherit patient-record access merely because it belongs to the same product family.

A connected workflow has explicit boundaries

An account, a professional role, a patient sharing grant and permission to use a reference library are different forms of access. A successful login to one product does not by itself authorize every other product or data source.

The practical problems addressed

Preparing for care

Patients can organize health information and complete structured intake before a consultation. A receiving practice still needs the appropriate handoff and access permissions.

Sharing selected information

Patient-record access can be scoped and time-limited. Teams need to distinguish permission to share from the shorter session used to read that information.

Coordinating care

Booking, communication and professional workspaces support different parts of a care journey. Their connection is a workflow to configure and verify.

Finding traceable evidence

Wiki keeps reviewed reference material connected to its source, version and licence, so a person or AI application can inspect the evidence behind an answer.

Design principles

  • Give each product a clear purpose, audience and access boundary.
  • Keep patient-record sharing explicit and check authorization at the service that owns the information.
  • Make handoff failures, expired access and missing evidence visible to the user.
  • Keep AI suggestions reviewable and preserve the responsibility of the healthcare professional.
  • Separate implemented features, demonstration modes and proposed integrations.
  • Preserve source provenance when medical reference material is used in an AI workflow.

Care applications and operator tools

The following applications support care-related workflows and their operation. They are separate products; their account roles, sessions and integrations must be checked individually.

Aimedis Care Pro

A personal health-record workspace for patients: profile, medications, conditions, measurements, laboratory results, documents and images, diary, nutrition, sleep and appointments. AVA uses bounded record context and supported record actions.

  • Manage scoped sharing and inspect access activity
  • Export selected record categories and generate printable reports
  • Review imported intake before incorporating it into the record
  • Spatial DICOM viewing uses locally imported browser files; its Care study adapter is not connected
Explore Care Pro

Aimedis Pro

A professional workspace combining practice and appointment workflows, patient-provided intake and authorized read-only views of selected Care Pro records. Registration includes professional evidence and administrative approval.

  • Review incoming structured intake
  • Use an eligible Care Pro sharing flow; some record categories are not mapped yet
  • General reference AI has provisioning gates; live patient-record AI is currently disabled
Explore Pro

Aimedis Onboarding

A guided patient-reported medical-history and intake workflow with review, account creation, PDF output and an optional factual physician summary. Its intake PIN is distinct from a Care Pro medical-record sharing grant.

  • Submission creates a new account; existing-account reuse is not automatic
  • Consent-controlled practice handoff
  • Configured export of supported clinical fields to Care Pro staging for patient confirmation
Explore Onboarding

Aimedis Booking

Practitioner discovery, availability, booking, cancellation and rescheduling, with practice schedules, appointment types and team administration. Configured shared scheduling tables let appointments appear in Care Pro and Pro.

  • Guest and account booking flows
  • Localized notifications depend on email configuration
  • Downloadable calendar events; no assumed bidirectional calendar sync or automatic video-meeting creation
Explore Booking

Aimedis Connect

Private and group messaging, spaces, files, translation, moderation and reporting for patients and professionals. It includes applications for verified professional status, AVA, record-sharing handoffs and chat-initiated Zoom meeting links.

  • Professional evidence receives administrative review
  • A record-share announcement alone contains no PIN or medical-record bundle
  • An eligible clinician separately redeems the Care PIN; Zoom requires provider configuration
Explore Connect

Aimedis Center

An operator interface for registered platforms, documented contracts, relationships and configured observations of system health. It links to each application’s administration tools and monitors interfaces without retrieving patient records.

  • Registry and integration ownership
  • Configured liveness and interface checks
  • Separate operator access; monitoring includes simulation modes

How the workflows connect

Intake → practice → patient review

Onboarding prepares a structured intake. A practice receives it through the authorized intake handoff. A configured Onboarding export to Care Pro stages information for patient review; submission alone does not prove that the receiving record has been updated.

Booking → practice schedule

Booking creates and manages a booking. Patient identity, the target practice and the receiving application’s integration determine where that booking can also appear. Confirm receipt and handle cancellation or failed synchronization explicitly.

Patient grant → professional session

The patient selects a sharing scope and permitted duration. A professional uses the appropriate redemption flow to obtain access. The resulting session can expire before the underlying grant, requiring renewed authorization through the supported flow.

Conversation → consultation

Connect supports communication, while Decision Pro supports a structured clinician-led consultation. A chat membership or meeting link alone does not grant access to the patient’s Care Pro record.

Specialist applications and immersive services

Aimedis Decision Pro

Clinician-led remote consultation from patient symptom intake and attachments to a waiting queue, triage documentation and a care plan. AVA supports the clinician and helps patients understand existing care information.

  • Distinct patient, doctor and administrator workflows
  • Human review of clinical decisions
  • Configured Zoom meeting links and downloadable care plans
  • Telematics and prescription submission require implemented and configured external adapters
Explore Decision Pro

Aimedis Rehab

Patient and professional workspaces for rehabilitation sessions, exercises, assessments, resources and progress. AVA supports guided interaction and reviewable activity entries. Configured immersive experiences launch through Aimedis Stream.

  • Assessment and rehabilitation planning workflows
  • Review before supported AI-proposed entries are saved
  • XR catalogue entries do not establish device compatibility or treatment efficacy
Explore Rehab

Aimedis Insur

An insurer-engagement application with patient tasks, challenges, activity and nutrition records, rewards, benchmark scores and programme dashboards. Some integration and AI surfaces remain demonstrators.

  • Patient and insurer programme views
  • Care Pro synchronization is currently simulated; the coach uses mock patient and health context
  • Reward levels and dashboard projections are not guaranteed premium reductions or proven savings
Explore Insur

Aimedis Support / Feedback Pro

Product support and community feedback through polls, multi-page surveys, NPS campaigns, issues, comments, voting and moderation. Documentation-based support chat and administrator insights help teams respond to participation.

  • Campaign, survey and moderation workflows
  • Support knowledge and stored-feedback analysis
  • Some creation and analytics assistant modes remain demonstrations
Explore Support

Aimedis XR

Aimedis XR focuses on medical education and collaboration in interactive 3D spaces, including virtual hospitals and learning environments. Experience delivery uses separate content and streaming tools; organizations should confirm the available modules, access and required equipment for their programme.

  • Immersive education and shared learning environments
  • Separate experience delivery and access requirements
  • Hardware and content acceptance per deployment
Explore Aimedis XR

Capability is different from outcome

An assessment form, AI suggestion, rewards calculation or XR session label does not establish clinical validation, treatment effectiveness, insurer acceptance or tested headset support. Those require evidence for the particular product and intended use.

Aimedis Wiki: reviewed reference knowledge

Aimedis Wiki is a private medical evidence library for approved administrators and organizations. It preserves original material, authorship, dates, licences and versions. Sources pass through independent publication review before becoming eligible for reference retrieval.

Administrators can organize material by medical specialty and other catalogue fields, inspect extraction results, compare evidence and prepare cited research briefs with AVA. OCR and transcription require the relevant processors. A PubMed bibliography import does not itself grant access to licensed full-text evidence.

Authorized applications can retrieve excerpts and give them to their own AI model, keeping source and version citations with the answer. The reference API does not authorize access to patient records. Patient-data processing in Wiki has separate controls and approval requirements.

For knowledge teams

Maintain a reviewed reference collection, inspect revisions and preserve the original evidence and usage rights.

For AI developers

Retrieve eligible reference passages over HTTP and use them with a chosen model. The application must preserve citations, respect licences and show when evidence is insufficient.

Access, consent and audit

Consent to platform terms or processing at signup, permission to receive an intake, and a grant to read medical-record categories are distinct decisions. They should not be described as one consent that automatically applies everywhere.

Care workflows use service-specific authorization, scopes and expiry. Intake and record sharing have different PIN contracts. Revocation must be enforced on subsequent access; it does not erase information already received by an authorized recipient.

Applications record access and operational activity. Some implementations cryptographically link audit entries to support integrity checks. Retention, independent protection and inspection capabilities depend on the service and its deployment; these records should not be described as universally immutable or tamper-proof.

  • Check the person, role, organization and data scope for the particular request.
  • Keep patient information out of unrelated support, reference-library and monitoring workflows.
  • Agree data handling, retention and applicable approvals before enabling an integration.

AVA works within each product

AVA is the Aimedis assistant brand across several separately configured applications. Its tools, data context, permissions and providers differ by product. A conversation in one application does not create a shared memory or unlock another application’s records.

Care Pro can use authorized patient-record context. Pro’s general reference AI has provisioning gates, and its live patient-aware AI is currently disabled: permission to view a record does not authorize sending it to an external AI provider. Decision Pro provides clinician-led support; Rehab supports rehabilitation interaction; Support uses product documentation and feedback; and Wiki uses reviewed references. On the public website, AVA searches public site content and helps visitors navigate. It has no patient-record access.

AI output needs the review appropriate to the workflow. Clinical suggestions are decision support for a qualified professional. Retrieval similarity and model-reported confidence are not measures of clinical certainty. Missing evidence or a failed dependency must be surfaced rather than disguised as a complete answer.

Language coverage varies by surface

Several care applications and the public website declare 14 interface locales. Specialized tools, documents, voice services and reference catalogues may support a different set. Confirm the languages required for the intended workflow.

Commercial scope

Organizations can discuss product access, implementation, support, reference-library use and specialist programmes with Aimedis. The commercial arrangement should name the actual application, permitted users, included services and any external providers needed for delivery.

  • Confirm subscriptions, licences, provider costs and support responsibilities for the deployment.
  • Agree integration scope and acceptance criteria before treating a connector as operational.
  • Keep demonstration rewards, benchmark projections and estimated savings separate from binding programme benefits.
  • Confirm rights to uploaded reference material and the permitted use of retrieved excerpts.

Practical adoption scenarios

A practice preparing consultations

Combine structured intake, appointment management and professional review of patient-authorized information. Verify patient matching, handoff status and expired-access handling.

A rehabilitation team following progress

Use session, exercise and assessment workflows with suitable professional oversight. Accept any external immersive delivery separately.

An organization grounding an assistant

Curate a licensed Wiki reference collection, approve publication and connect an authorized retrieval workflow to a chosen AI model.

A product team collecting feedback

Run surveys or NPS campaigns, moderate community issues and use support documentation and stored feedback to inform responses.

Development and rollout boundaries

Further integration is a development and acceptance process. A feature present in a local application, a green demonstration dashboard or a contract labelled live is not proof that an entire patient journey has succeeded in a hosted environment.

  • Confirm deployed versions, required database migrations and configured providers.
  • Test each sender and receiver with approved fictional fixtures and inspect the receiving result.
  • Separate demonstration records and simulated monitoring from operational data.
  • Validate dedicated service credentials before promising unattended AI integration.
  • Confirm external telematics, prescription, video and XR services independently.
  • Document limits and known gaps for the users who will rely on the workflow.

Technology and interoperability

The product family consists of separate web applications and service integrations. Data ownership and access checks reside in the relevant service. Center supplies a registry and observations; it does not route all clinical traffic or act as a universal identity provider.

Care Pro exposes a read-only FHIR projection over its records. Wiki provides scoped FHIR R4 reference-resource read/search interfaces. These do not establish a family-wide FHIR-native clinical database, universal resource support or a ready-made HL7, CDA, PACS or hospital integration.

Choosing the next step

Start with the person’s task and the product that owns it. Identify the information needed, the required approval and the receiving workflow. Add integrations after their access, failure handling and delivery have been confirmed.

For a product overview, use the application pages. For Wiki retrieval, use the concrete API guide. For a care-platform integration, agree the owning service’s current contract and acceptance process with Aimedis.