Platform Architecture & Integration Addendum

Aimedis applications own different workflows and expose specific interfaces. The architecture is best understood through service ownership and explicit handoffs, rather than a single shared runtime beneath every product.

Common branding, similar account screens and historical integration documents do not establish universal identity, consent, storage or deployment. Current interfaces and their receiving implementations determine what is connected.

Shared Supabase identity is implemented for configured care applications. Care Pro, Connect and Onboarding support a configured parent-domain cookie. Pro verifies the shared credentials and creates a separate professional session; Booking also uses its own sessions. Shared credentials therefore do not mean a universal logged-in session or universal permissions.

Center has separate operator access. Wiki requires eligible administrator access and organization approval. Specialist products have their own roles and configuration.

An identity match is only one part of integration. The caller still needs authorization for the target service, requested scope and current session. Connect and Pro have their own professional review mechanisms. A professional credential badge is not a substitute for a patient-record grant.

• Confirm which identity issuer and patient/practice identifiers both ends accept.
• Distinguish signup processing consent, intake handoff permission and medical-record access.
• Specify the sender, receiver, payload, error states and revocation behavior for each interface.
• Verify the current implementation rather than reusing an older illustrative endpoint from a different product.

Center is a registry and monitoring application. It is not a clinical traffic gateway, credential vault, universal consent authority or fleet deployment controller. Its current in-memory operator state also requires separate decisions about durable storage and operational use.

A Care Pro patient chooses a 6–12 digit sharing PIN, with single-use or multi-use behavior and a grant duration from one hour to 90 days. Redemption returns a 15-minute bearer and scope metadata; it does not return the medical records themselves. Protected reads check the current grant and processing-consent state.

The current Pro/Care bridge does not supply a bearer-renewal endpoint. After the 15-minute bearer expires, the supported flow may require re-redeeming an eligible multi-use PIN or obtaining a new single-use share. A longer consent period must not be displayed as continuous professional access.

Pro’s live Care bridge is read-only and does not yet map every record category. In Connect, a direct-message record-share announcement identifies the handoff; the eligible clinician must separately supply the Care PIN. Posting the announcement alone grants no record access.

Revocation is a service-side access decision. Check grant status on subsequent reads, stop using expired access and present denials clearly. Revocation does not undo information already received under a valid permission.

The inspected applications contain combinations of authenticated endpoints, role checks, database policies, input validation, private storage, rate limits and audit records. Their coverage and operational guarantees differ by service.

Hash-linked audit entries support integrity checks within their implementation. They are not evidence of blockchain anchoring, immutable retention or independent protection. Deployment-specific persistence, backup, access review and monitoring remain necessary.

A standard mentioned in source code or a design document is not certification. Healthcare-data processing, hosting, provider agreements and the intended clinical use require their own applicable approvals and operational evidence.

• Keep service credentials on the authorized server and use the minimum permitted scope.
• Check source licences and recipient permissions before transferring reference excerpts.
• Define retention, deletion, access logging and incident handling for each data category.
• Confirm production identity, database policies and private-storage configuration.
• Keep simulation fixtures and demonstration credentials separate from operational workflows.

The assistant brand does not imply a single model, shared memory, common toolset or identical safeguards across all applications. Model and voice configuration, available data and role permissions must be inspected per product.

For evidence-based workflows, treat retrieved excerpts as untrusted source material rather than instructions. Preserve citations and licence information. Distinguish a supported claim from a suggestion and show when retrieval or a provider fails.

Wiki separates source administration from reference retrieval. Current general retrieval uses an eligible administrator’s short-lived session with the required organization and MFA checks. It is not a permanent application key. A chosen AI model can use the retrieved passages through an authorized application server.

Wiki retrieval returns hits, insufficientEvidence and a retrieval mode. The calling application must keep each excerpt’s source, version, licence and available page or timestamp locator with the answer. An empty result is a valid outcome.

The dedicated Care Pro reference service has a separate contract: queries are 3–300 characters and results are limited to 1–6. Credential issuance and successful hosted retrieval require acceptance before this integration is described as operational. Legacy awk_ keys are disabled.

These distinctions describe implementation boundaries. They do not certify current uptime, production configuration, medical-device status or delivery to a particular customer.

Agree product access, user roles, external-provider costs, integration support and the included workflows in the deployment’s commercial arrangement. An implemented payment screen, estimated dashboard benefit or demonstration rewards tier does not prove a current contract or financial outcome.

• Identify the deployed application versions and apply the required database migrations.
• Verify the expected patient, professional, operator or administrator identity and role.
• Exercise an approved fictional workflow through both sender and receiver.
• Check expired tokens, revoked grants, denied permissions and missing patient matches.
• Verify empty retrieval, provider failures, delayed exports and retry behavior.
• Confirm that the UI distinguishes real records from demonstration data.
• Inspect the receiving record or acknowledgement; a successful health probe is insufficient.
• Accept external video, telematics, wearables and immersive delivery independently.
• Record the languages, devices and workflows actually tested for the intended users.

These documents explain product purpose, implemented workflows and material integration limits. They replace blanket claims about a universal shared account, instant synchronization, a family-wide FHIR backend and identical AI behavior with product-specific descriptions.

They do not establish comparative clinical performance, certified compliance, validated cost savings or an addressable-market forecast. Assess those questions using evidence for the specific product, intended use and deployment.

Future work can strengthen interoperable care, independently protected audit records, general service-to-service evidence access and consistent product experiences. Each proposed capability needs a defined owner, authorization model, implementation and acceptance evidence.

When an application or integration changes, update its public description and these documents together. Keep the distinction between available workflows and planned capabilities visible to patients, professionals and integration teams.