Acceptable Use and Patient Data Policy
About this document
| Field | Value |
|---|---|
| Version | 1.0 |
| Effective date | 1 August 2026 |
| Publication date | 1 August 2026 |
| Last reviewed | 26 July 2026 |
| Status | Approved public document |
Version history
| Version | Effective date | Change summary | How this version applies |
|---|---|---|---|
1.0 | 1 August 2026 | Initial public version | Applies with the applicable Alessia Terms or institutional agreement |
1. Purpose and scope
This Acceptable Use and Patient Data Policy explains the content and conduct rules for Alessia.
Alessia is designed for professional education, training, assessment and portfolio evidence. It is not a patient record, electronic health record, clinical communications or emergency system and must not be used for current patient care.
"Content" includes anything entered, recorded, dictated, uploaded, imported, linked, generated, saved or shared through Alessia, including structured fields, text, calculations, assessments, audio, transcripts, images, video, documents, metadata and reports.
For an individual account, the user normally determines the portfolio purpose for personal information in Content. For an Institution-controlled account, the Controller or Controllers are identified by the Institution's agreement. Alessia acts as Processor for Customer Personal Data and separately as Controller for limited security, abuse-prevention, legal-compliance and legal-rights purposes.
2. The default patient-data rule and institutional exception
Patient Personal Data means information relating to an identified or identifiable patient. Identification may be direct or may arise by combining Content with a clinical record, local knowledge, memory or information reasonably available to another likely recipient.
Patient Personal Data is prohibited by default. It is prohibited in every individual account and in an Institution account unless all of the following apply:
- an active institutional Order incorporates Alessia's Patient Data Addendum;
- the Order identifies the authorised Patient Data Tenant and relevant Controller or Controllers;
- a completed Patient Data Permission Schedule identifies the permitted patient categories, data categories, purposes and operations; and
- the user acts within that exact institutional authorisation and the Institution's instructions.
The exception applies only to the authorised Tenant and scope. It does not extend to another account, Tenant, school, clinic, Institution, feature, integration or user.
Patient consent does not create an exception. A lawful basis or professional permission does not by itself expand Alessia's product rule or an institutional authorisation.
3. Direct identifiers and other out-of-scope Patient Personal Data
Unless a Patient Data Permission Schedule permits the specific category and operation expressly, do not submit a patient's:
- name, initials, care alias or username;
- date of birth, address, email, telephone number or precise home or work location;
- hospital, clinic, health, medical-record, insurance, device or other unique identifier;
- face, identifiable voice, biometric or genomic identifier, or distinctive body feature;
- unredacted wristband, label, prescription, referral, letter, form, screenshot, scan or clinical-system display;
- relative or carer details that identify the patient; or
- link, QR code, filename, metadata or external reference that leads to an identifiable record.
A replacement code or pseudonym remains Patient Personal Data where a user, Institution, Alessia or another reasonably likely recipient can reconnect it to a patient. Pseudonymisation is not anonymisation.
In an authorised Patient Data Tenant, Content outside the permitted categories, purposes or operations remains prohibited.
4. Indirect identification and data minimisation
Information may identify a patient through a distinctive combination even when direct identifiers have been removed. Consider the complete entry, attachments, linked entries and the information likely to be known in the relevant workplace or community.
Potentially identifying combinations include:
- exact encounter date or time;
- exact age;
- named hospital, clinic, ward, service, town, treating team or clinician;
- rare diagnosis, unusual procedure, adverse event or distinctive history;
- ethnicity, nationality, occupation or unusual demographic detail;
- detailed narrative or a quotation;
- a small service, rural location or public incident; and
- images of a scan, wound, body part, room, document or screen.
Outside an authorised Patient Data Tenant, use the minimum learning-focused information needed. Depending on context, this may mean using an age band, broad time period, general setting, broader procedure or condition category, short reflection or competency identifier.
These examples do not guarantee anonymity. The relevant user and Controller must assess the complete context.
Alessia may use warnings or place affected Content under restricted review where there is a reasonable patient-identification concern. Those safeguards are not legal determinations. A warning, the absence of a warning or a user's acknowledgement does not establish that Content is anonymous, lawful or permitted.
5. Audio, images, video and documents
Outside an authorised Patient Data Tenant, do not record a patient or clinical conversation. A retrospective voice note must be made away from the patient and contain no Patient Personal Data.
Before uploading a file:
- use a copy rather than the source record;
- remove visible identifiers from every page, frame and layer;
- remove hidden comments, tracked changes, annotations, thumbnails and embedded metadata;
- check filenames, backgrounds, reflections, screens, labels and audio;
- consider whether the remaining combination identifies a patient; and
- confirm that you have authority and the rights needed to use it.
Covering text visually may not remove the underlying information. Use a redaction method that permanently removes it and check the exported copy.
Where Alessia requests an upload confirmation, it does not replace the user's or Institution's responsibility. Users in an authorised Patient Data Tenant must follow the applicable Patient Data Permission Schedule and Institution instructions.
6. AI-assisted features
Patient Personal Data must not be submitted to an AI-assisted feature unless the Institution has a separate, feature-specific written authorisation in addition to the Patient Data Addendum. An authorised Patient Data Tenant alone is not enough.
Content selected for an AI feature may be sent to an approved Subprocessor to perform the requested task. Current provider roles, locations, retention and training restrictions are published in Alessia's Subprocessor and Service-provider List.
AI output may be inaccurate, incomplete, biased or may repeat information from the input. A suitably qualified person must review and correct it. AI output must not make a solely automated clinical, academic, employment, progression, credentialing or disciplinary decision.
Users must not use Customer Data, Patient Personal Data or Service content to train a model without express written authority.
7. Calculators and clinical use
Do not use Alessia calculators, scores, AI output or reference content to make or support a decision about a current patient. Do not delay care, diagnosis, escalation or emergency assistance based on Alessia.
Users must independently verify inputs, units, formulas, assumptions, results and current source guidance. Permission to store Patient Personal Data does not change the educational and retrospective purpose of the Services.
8. Assessments, evidence and professional integrity
Users must not:
- fabricate, alter or misrepresent an encounter, credential, certificate, signature, assessment, feedback item or supervisor relationship;
- impersonate another person or Institution;
- use another person's account or share credentials;
- submit evidence they are not authorised to possess or disclose;
- present an AI-generated draft as independently verified human evidence; or
- represent an Alessia report as verified, accredited or officially accepted where it is not.
Professional details about supervisors, colleagues and assessors may be recorded only where they relate to a genuine professional or educational relationship, are reasonably necessary and may lawfully be provided. The Controller is responsible for required transparency.
9. Institution use and significant decisions
An Institution must not use Alessia to:
- make a solely automated decision producing legal or similarly significant effects;
- infer or monitor health, wellbeing or another sensitive characteristic without a separately approved feature, lawful basis, assessment and safeguards;
- conduct covert worker or student monitoring;
- discriminate unlawfully or deny a fair review or appeal;
- treat unverified Content as conclusive proof of competence or misconduct; or
- operate Alessia as the primary or legal patient record.
The Institution is responsible for verifying assessors and evidence and for its academic, employment, progression, credentialing, disciplinary and regulatory decisions.
10. Intellectual property and third-party materials
Do not upload or configure a framework, curriculum, assessment instrument, clinical dataset, terminology set, publication, template, image, video or document unless you have the rights needed for its use in a commercial hosted service.
A public source, academic citation or educational-use permission does not necessarily allow commercial reproduction, adaptation, translation, structured extraction, redistribution or use across Institutions.
Institution Materials may be used only within the owning Institution's authorised scope unless the owner permits broader use and Alessia verifies the rights.
11. Security and Service integrity
Users must not:
- access or attempt to access another account, Institution, Tenant, system or data without authority;
- probe, scan, penetration-test or load-test the Services without written permission;
- bypass authentication, subscription, storage, usage, download or other controls;
- introduce harmful code or interfere with availability;
- scrape, bulk extract or use automated access except through an authorised interface;
- reverse engineer except to the limited extent applicable law makes that right non-excludable;
- send spam, phishing, harassment, threats or unlawful Content; or
- infringe privacy, confidentiality or intellectual-property rights.
12. Reporting a patient-data concern
If prohibited or out-of-scope Patient Personal Data is found, stop unnecessary access, downloading, sharing and duplication. Use an available in-product reporting control or email privacy@alessiahq.com with an account or entry reference and a safe description. Do not copy Patient Personal Data into ordinary email.
An Institution must also follow its own incident procedure and notify its privacy or information-governance contact. The relevant Controller decides whether and how to notify a patient, Supervisory Authority or another organisation unless Alessia has an independent legal duty.
Alessia may review the minimum information reasonably needed to assess and contain the concern, restrict affected Content and cooperate with the relevant Controller. A report, warning or restriction does not by itself mean that a legally notifiable Personal Data Breach has occurred.
Nothing in this policy prevents or penalises a legally or professionally protected report, regulatory complaint, professional duty, duty of candour or whistleblowing disclosure.
13. Proportionate enforcement and challenge
Alessia may warn, restrict, quarantine, suspend or remove affected Content or access where reasonably necessary to address a breach, security or confidentiality risk, unlawful use, infringement or legal requirement.
Action will be limited to the affected Content, user, feature, integration or Tenant where practicable. Alessia will normally explain the issue and provide an opportunity to correct it. Immediate action may be taken where delay would materially increase security, confidentiality, legal or third-party risk, with an explanation as soon as reasonably practicable afterwards.
Processing Permitted Patient Personal Data within the authorised scope of an active Patient Data Addendum is not, by itself, a breach of this policy. Any unauthorised access, disclosure, loss, out-of-scope processing or other security or privacy concern must still be assessed under this policy and the applicable agreement. Suspension does not authorise automatic permanent deletion. Alessia will restore access promptly after the issue is resolved where continued restriction is not otherwise required.
For an Institution-controlled account, Alessia will coordinate with the relevant Controller. The Institution, not Alessia, decides academic, employment, disciplinary, progression and professional consequences.
Alessia will contact a patient, regulator, law-enforcement body or other third party only where legally required, where Alessia acts as Controller for that decision, or on the relevant Controller's instruction.
Termination of an institutional Order is governed by the Institutional SaaS Master Agreement. This policy does not create a separate unrestricted termination right.
A user or Institution may question or challenge an Alessia restriction by contacting privacy@alessiahq.com. A challenge does not automatically remove a necessary interim restriction, but unaffected use should remain available where practicable.
14. Policy versions and contractual priority
An institutional Order identifies the version of this policy incorporated at signature. Alessia may update the policy for legal, security, abuse-prevention or product reasons and will give reasonable notice of a material change where practicable.
An update cannot change Charges, liability, data ownership, controller or processor roles, the institutional term or Patient Data Permission Schedule. The applicable Order, Patient Data Addendum, DPA and Master Agreement prevail over this policy for those matters.
Superseded public versions will be archived when a later version is issued.
15. Questions and reports
- Product and policy support: support@alessiahq.com
- Privacy and patient-data reports: privacy@alessiahq.com
- Legal and rights notices: legal@alessiahq.com
