Product, workflow and regulation—without the hand-waving.

The consumer product is provider-agnostic. It can help a person prepare for and remember conversations across primary care, hospital care and specialties. The same boundary applies everywhere: Companion organizes the patient’s information and recorded conversation; it does not independently diagnose or recommend treatment.

Potentially, yes—for example with a physiotherapist, dentist, dietitian or other professional—provided recording is appropriate and lawful in that setting. The product itself does not assume that the other participant is a physician.

Yes, in principle. The user still needs to follow the platform’s terms, local recording law and the other participant’s expectations. Audio capture quality may vary depending on whether the consultation audio is available to the browser microphone.

Companion can be used by a person supporting someone else when that is appropriate and permitted. Age, capacity, parental responsibility, consent and privacy requirements can change the legal analysis, so the app should not treat these situations as identical to an adult managing their own account.

No. A patient can use Companion independently. If the patient wants to share information, the clinician can view a temporary browser share without a Companion account.

No for the consumer product. There is no requirement for EHR access, SSO, FHIR or a hospital deployment in order for the patient to use Companion.

The patient’s account is private by default. A recipient sees information only when the patient creates and sends a share. Temporary sharing is separate from persistent account access.

Yes. The current sharing model creates a frozen, time-limited snapshot containing only the sections the patient selected. Receiving a share does not give the clinician access to the rest of the account.

The recording and transcript remain the source material. The product tells users that AI-organized text can contain errors. Clinicians should not treat a patient-provided AI summary as automatically verified clinical documentation.

No. Companion is a patient-side memory and organization tool. It is not the provider’s legal medical record and does not replace the provider’s own documentation, portal or patient-information duties.

The current consumer product is designed as a direct-to-consumer personal health-information and visit-memory service. It is not offered as a healthcare provider, insurer, EHR or diagnostic/treatment service. Exact obligations still depend on the relationship with users, providers and subprocessors.

Not automatically. HIPAA applies to covered entities and business associates. HHS guidance says a consumer-selected app that is not provided by or on behalf of a covered entity is generally outside HIPAA once the individual directs information to it. If a provider contracts with Companion to create, receive, maintain or transmit PHI on the provider’s behalf, a business-associate relationship can arise.

Not merely because a patient independently chooses Companion and shows or sends the clinician information. HHS says a patient-designated app does not create a business-associate relationship by that fact alone. A BAA may become necessary if Companion is contracted to handle PHI on behalf of the clinician or organization.

No. The FTC Health Breach Notification Rule can apply to vendors of personal health records and related consumer health technologies that are not covered by HIPAA. State privacy and consumer-protection laws may also apply. “Not HIPAA” never means “no privacy obligations.”

No. The current intended purpose is to capture, organize, remember and share information about healthcare conversations, not to diagnose, monitor disease, predict outcomes or recommend treatment. If future features make medical claims or perform medical-purpose decision support, the FDA analysis would need to be revisited.

The current product boundary is deliberately narrower. Preparation AI elicits and organizes what the user wants to say. Visit summaries and Ask about this visit are grounded in the transcript and are instructed not to generate new diagnosis, triage, testing or treatment recommendations.

Companion does not create a new professional relationship between Kinvectum and the clinician. A clinician’s own professional and documentation duties still apply to information they receive and choose to rely on. We do not claim that use of Companion eliminates or creates malpractice risk in every jurisdiction.

Yes. GDPR status is separate from medical-device status. Visit recordings, transcripts, medication information and health summaries are personal data concerning health and therefore special-category data under Article 9 GDPR. The controller must identify an Article 6 legal basis and an applicable Article 9 condition, provide required transparency, minimize data, secure it and support data-subject rights.

Article 9(2)(a) allows processing where the data subject gives explicit consent for specified purposes, subject to Union or Member State limits. For a direct-to-consumer product, explicit consent may be one relevant route, but the full legal-basis analysis—including Article 6, withdrawal, necessity and any national rules—should be documented before launch.

Our current product intent is non-medical-purpose software: helping people capture, organize, remember and share information about their own healthcare conversations. Under MDR Article 2 and MDCG 2019-11 rev.1, software qualifies as medical-device software when it has a medical intended purpose. The guidance also says not all software used in healthcare is a medical device. Because Companion does process patient-specific health information, this boundary must be maintained in claims and functionality and should be documented in a formal qualification assessment.

Features intended to diagnose, prevent, monitor, predict or prognose disease, recommend treatment, calculate doses, provide patient-specific clinical decision support or otherwise serve a defined medical purpose can move software into MDSW territory. Renaming a feature or adding a disclaimer would not override its actual intended purpose and claims.

The consumer app is not intended to be a provider’s electronic health record or system of record. The MDCG guidance separately notes that information systems intended only to transfer, store, convert, format or archive data are not medical devices in themselves, although medical-purpose modules can be. A clinician may still decide to copy relevant patient-provided information into their own EHR.

Article 50 transparency obligations apply from 2 August 2026. AI systems that interact directly with people must inform them that they are interacting with AI unless that is obvious. Companion therefore labels AI preparation and AI-organized visit content and keeps source material available for review. If future AI functionality becomes medical-device software, additional AI Act high-risk obligations may also become relevant.

There is no single EU-wide answer. Recording law, confidentiality rules and healthcare-provider policies vary by Member State and context. Companion should tell users to inform participants and comply with the law and clinic policy that applies where the recording occurs.

Not merely because an individual consumer independently uses Companion and later shows a clinician a patient-controlled share. If a healthcare organization procures Companion or Kinvectum processes personal data on that organization’s behalf, the controller/processor roles, Article 28 terms, security requirements and health-sector rules must be assessed separately.

Not automatically. The patient controls the transfer. Once a clinician receives information, the healthcare organization’s own national documentation, professional and retention obligations determine whether and how that information should be incorporated into the clinical record.

A production launch should include a documented GDPR legal-basis assessment, privacy notice, retention/deletion rules, processor and subprocessor contracts, international-transfer assessment where relevant, security controls, incident response, data-subject request workflows and a DPIA where the processing is likely to create high risk.