Where OrthoLog uses AI—and where it does not

1. Purpose and scope of this notice

This notice explains the AI-enabled functions in the current OrthoLog release, the data sent, the provider relationship, oversight, limitations and intended regulatory boundary. It should be read with the Terms and Privacy Notice.

2. AI is optional and user initiated

AI does not run automatically in the background. It is invoked only when a user selects an image or PDF workflow, has configured a provider credential and confirms the disclosure for that extraction. Manual case entry and local spreadsheet import remain available.

3. AI-assisted functions

• Suggesting multiple draft case records from a theatre-list photograph, screenshot or PDF page.
• Suggesting fields for one draft case from a photographed operation note.

The extraction instruction requests fields such as date, hospital, optional identifier, DOB/age, operation, side, consultant, supervision, urgency and ASA only when present. It asks the provider not to return a patient name and not to infer unsupported values. Provider compliance is not guaranteed.

4. Functions that do not use AI

• manual entry, editing and local spreadsheet parsing;
• duplicate checks and deterministic procedure normalisation;
• encryption, locking, masking, local reference generation and deletion;
• Google Drive file encryption, synchronisation and merge logic;
• CSV generation and descriptive case counts;
• learning points, reflections, PBA-style notes, links, attachments and follow-up notes.

5. Inputs, processing and outputs

The input is the selected image data plus a structured extraction instruction and technical request metadata. The user’s API key authorises the direct request. The provider processes the input using the selected model and returns generated text or JSON suggestions. OrthoLog parses that output into draft fields.

No RQAI intermediary server is intended to receive the image or result. Network, DNS, operating-system, browser and provider infrastructure still process technical metadata.

6. Providers and changing model versions

The current adapters support Google Gemini, Groq and OpenAI. The user chooses a provider and model name. Providers can retire or silently update models, change availability, apply safety filters or return a different error or format. RQAI does not train or operate those foundation models and does not guarantee a model’s continuity.

Provider data terms must be checked against the exact account and endpoint. A free, consumer, paid, enterprise or zero-data-retention configuration can have materially different handling.

7. Human oversight and review workflow

Every AI result is a draft. The user must review each proposed case against an authorised source, correct or delete errors and decide whether it may be saved. A sequential review screen does not certify the content. OrthoLog does not provide a calibrated confidence score or independent verification.

Where the image cannot be checked, extraction should be abandoned and the case entered manually from an authorised source.

8. Accuracy and foreseeable failure modes

• wrong patient-to-procedure association on dense, rotated or multi-page lists;
• missed rows, duplicated rows or merged cases;
• misread handwriting, low contrast, glare, folds, stamps or annotations;
• incorrect dates, laterality, consultant, supervision, ASA or urgency;
• confusion between MRN, NHS number, encounter number and other identifiers;
• expansion of an abbreviation to the wrong procedure;
• fabricated values or plausible text absent from the source;
• provider refusal, truncation, outage or changed output schema.

9. Privacy, confidentiality and data minimisation

The source image may expose identifiers that the model instruction does not request. Crop or irreversibly redact unnecessary material before an approved transmission. Do not rely on prompt wording as a privacy control. Use the minimum image area and resolution reasonably necessary for the authorised extraction.

Never send a patient image merely because the local vault is encrypted. Transmission to an AI provider is a separate processing operation requiring its own authority, contract, security and transfer assessment.

10. Provider data controls

As of the review date, provider documentation describes different retention and zero-data-retention options. OpenAI documents endpoint-specific API retention and approved data controls; Gemini distinguishes paid-service training treatment, abuse monitoring and approved ZDR; Groq describes limited inference retention scenarios and configurable ZDR. These statements are provider-controlled and can change.

Users must verify the provider’s current official documentation, contractual terms, subprocessors, data location and configured account controls. OrthoLog cannot enforce provider-side deletion or zero retention.

11. No automated significant decisions

OrthoLog is not intended to make a solely automated decision with legal or similarly significant effect. AI output must not be used to assess competence, employment, credentialing, training progression, misconduct, insurance or access to care. It must not be used for diagnosis, treatment, triage or patient monitoring.

12. EU AI Act position

The EU AI Act entered into force on 1 August 2024. AI-literacy obligations have applied since 2 February 2025, general-purpose-model obligations since 2 August 2025, and Article 50 transparency obligations apply from 2 August 2026, with some high-risk rules on later dates. Application depends on role, location, intended purpose and deployment.

For its stated intended purpose, OrthoLog provides user-controlled administrative drafting and does not make a clinical or significant decision. RQAI’s current view is that this limited feature is not presented as a high-risk medical or employment AI system. This is not a binding classification. A deployer that changes the purpose, integrates the output into care or assessment, or materially modifies the system must reassess its role and obligations.

13. AI literacy, governance and change management

Users and approving organisations should understand the provider, model, input, output, common failure modes, human-review requirement, privacy risks and escalation route. Organisations should document approved accounts, model/version controls, test examples, prohibited data, monitoring and incident response. A material model or purpose change should trigger renewed validation, DPIA and legal assessment where applicable.

14. UK data-protection and professional duties

UK data-protection, confidentiality and professional duties apply independently of the EU AI Act. The controller must establish the lawful bases, special-category condition, transparency, processor arrangements, security and international-transfer mechanism, and complete a DPIA where the processing is likely to result in high risk. Terms acceptance by the app user is not patient consent.

15. Safer default and incident reporting

If authority, processor approval, provider account controls or transfer safeguards cannot be confirmed, do not send the image; enter the case manually using the minimum permitted information. If an incorrect or unauthorised disclosure occurs, stop further transmission, follow the organisation’s incident process and rotate the API key where relevant.

16. Official references and contact

Current official sources include the European Commission AI Act overview, Article 50 transparency guidelines, official Regulation text and ICO AI and data-protection guidance. Questions about the OrthoLog implementation may be sent to hello@rqai.co.uk without confidential material.