AI Engine with UI Interface Development

Product scope effort 1. Product Summary The platform is an AI-powered medication safety and compliance platform. Users upload or type in a full medication list, and the system returns: Interaction risk analysis across the entire medication list (not just pairwise checks) Injury-relatedness verdicts for compensation/claims contexts (per medication: injury-related / partial / unrelated) Compliance and safety checks against regulatory and clinical guidance (TGA, WorkSafe/SIRA, NICE, PBS), with a specific recommended action for every flag and an audit trail Target users: individuals, carers, claims professionals (workers' comp / CTP / life insurance case managers), insurers, return-to-work coordinators. Core promise: turn a medication list into a clear, explainable risk report in minutes. 2. Why We're Building This (Context for Vendors) Case managers, insurers, and RTW coordinators currently need to manually work out: whether a claimant's medications interact dangerously whether each medication is actually related to the compensable injury whether prescribing is compliant with opioid/Schedule 8 rules This is slow, manual, and inconsistent. The platform automates it and produces a defensible, auditable report. 3. Core Modules Module 1 — Whole-of-List Interaction Risk What it does: Checks every medication against every other medication in the list simultaneously — not one pair at a time — and flags multi-drug interaction risk that pairwise tools miss. Features: Upload prescription as PDF or photo (OCR/extraction required) Manual entry of medication list (drug name, dose, frequency) Combination/interaction checking across the full list, not just 1:1 pairs Output: Major / Moderate / Low risk rating with plain-English reasons for each flag Data source: continuously updated from TGA (Therapeutic Goods Administration, Australia) medicine data, plus an interaction/drug-drug-interaction database (vendor to recommend — e.g., a licensed clinical interaction database; see Section 6) Module 2 — Injury-Relatedness Verdict What it does: For each medication in the list, determines whether it is related, partially related, or unrelated to a specified compensable injury. Features: Per-drug verdict: Injury-related / Partial / Unrelated Uses the same medication list already uploaded in Module 1 (no re-entry) Requires a way to capture the claim's injury/diagnosis (e.g., ICD-10 code, free text, or claim type selector) so the AI has something to test relatedness against Output written in plain English, suitable for a non-clinical case manager to read and use directly on a claim Module 3 — Compliance & Safety Check What it does: Runs the medication list against relevant regulatory/clinical guidance and produces a compliance report. Features: Checks against: TGA (Australia) — safety standards SUSMP / the Poisons Standard — the national scheduling rulebook (TGA-maintained) that actually defines which drugs are Schedule 4, Schedule 8, etc. This is the underlying reference TGA Schedule 8 rules are built on, so it needs to be a named data source in its own right, not folded silently into "TGA" State-based Real-Time Prescription Monitoring (RTPM) systems — SafeScript (VIC), SafeScript NSW, QScript (QLD), ScriptCheckSA (SA), ScriptCheckWA (WA), CanberraScript (ACT), TasScript (TAS), NTScript (NT). These aren't just guidance — several states make checking them mandatory before prescribing/dispensing monitored medicines, and they vary in which Schedule 4 drugs (benzodiazepines, gabapentinoids, quetiapine, z-drugs, tramadol, etc.) are added on top of the nationally-consistent Schedule 8 list. Vendor should confirm whether any of these have accessible data/APIs we could integrate with, versus us only being able to reference the rules around them (e.g. "this claimant's opioid pattern would trigger a mandatory RTPM check") WorkSafe / SIRA and other state workers' compensation schemes — prescribing guidance; note this is genuinely state-by-state (WorkSafe Victoria, SIRA/icare NSW, WorkCover QLD, ReturnToWorkSA, WorkCover WA, and the federal Comcare scheme for Commonwealth employees), each with its own rules — not one national standard AHPRA / Pharmacy Board of Australia National Law — the legal framework prescribers and pharmacists operate under; relevant for flagging things like unauthorised-prescriber or scope-of-practice issues Therapeutic Guidelines (eTG) / Australian Medicines Handbook (AMH) — the standard clinical reference Australian prescribers actually use for dosing and appropriateness; worth naming explicitly since it's a common formulary reference vendors may use as a data source rather than TGA raw data alone NICE (UK) — clinical guideline reference, where applicable PBS (Pharmaceutical Benefits Scheme) — subsidised medicine rules/limits Flags: opioid duration limits, Schedule 8 review triggers, multiple-prescriber flags, guideline-exceeding doses, mandatory-RTPM-check triggers For every flag: a specific recommended action (not just "this is a problem") Audit trail: every check performed, its result, and timestamp, exportable/ready to file as part of a claim record 4. The AI Engine (What We Need Vendors to Scope) This is the heart of the system and where we most need vendor input on approach and cost. It needs to: Ingest a structured/unstructured medication list (from OCR or manual entry) Cross-reference against a drug interaction database (multi-drug, not just pairwise) Apply a rules engine encoding: TGA safety data, the SUSMP/Poisons Standard scheduling rules, and Schedule 8 rules State-based RTPM system rules (which medicines are monitored, and where checking is mandatory vs. voluntary, per state) WorkSafe/SIRA and other state workers' comp schemes' prescribing guidance (state-by-state, plus Comcare federally) Therapeutic Guidelines (eTG)/AMH clinical reference data NICE guidance PBS rules Apply a reasoning layer (LLM or clinical logic, or hybrid) that: Explains why something is flagged, in plain English Makes the injury-relatedness judgment call per drug Recommends a specific action per compliance gap Log every check for audit purposes We need vendors to advise on and quote for: Whether to license an existing clinical drug-interaction database (e.g., a commercial DDI API) vs. build one from TGA public data — recommend an approach and cost How rules from TGA/WorkSafe/SIRA/NICE/PBS get encoded and kept up to date (manual rules engine vs. LLM-assisted vs. hybrid), including who is responsible for maintaining currency of clinical rules over time Approach to "continuously updated" data feeds (are these public APIs, scraped, licensed, or manually curated on a schedule?) Clinical governance: do we need a registered pharmacist/clinician to sign off on the rules engine and its outputs before this can be marketed as clinically authoritative? (Vendor should flag this even if it sits outside dev scope — it affects product validity and possibly regulatory classification.) 5. User Flows Individual/carer: Upload prescription (photo/PDF) or type meds → Module 1 result (interaction risk) → optional Module 3 (compliance) Claims professional/insurer: Upload/type meds → enter injury/claim detail → Module 1 + Module 2 + Module 3 results → export/audit trail attached to claim file All users: Account creation/login Save/retrieve past medication lists and reports Export report (PDF) for filing "Talk to Sales" / book-demo CTA (already exists at [your-domain]/book-demo — marketing site, not in this build scope unless stated otherwise) 6. Functional Requirements Checklist User accounts with role types (individual, carer, claims professional, insurer) and appropriate permissions/views Prescription upload: PDF and photo, with OCR/extraction of drug name, dose, frequency Manual medication entry with autocomplete against a drug database Multi-drug interaction engine (not pairwise-only) Risk rating output: Major / Moderate / Low, with plain-English reasoning per flag Injury/claim detail capture (diagnosis/ICD-10 or free text) Per-drug injury-relatedness verdict engine Compliance rules engine covering TGA, WorkSafe/SIRA, NICE, PBS Specific recommended action per compliance flag Audit trail: logged, timestamped, exportable PDF report export (client-ready, professional formatting) Admin/back-end for updating rules and drug database as regulations change Data security appropriate to health information (see Section 8) 7. Non-Functional Requirements Data currency: interaction and compliance data must be kept current; vendor to propose an update mechanism/cadence Explainability: every risk rating and verdict must come with a plain-English reason — no black-box outputs Auditability: every check must be logged and retrievable for claims/legal purposes Scalability: must handle individual users through to insurer-scale batch/claims volumes Accessibility: usable by non-clinical staff (case managers) and general public (individuals/carers) 8. Security, Privacy & Compliance (Australia-first) Because this handles health information: Must comply with the Australian Privacy Act 1988 and Australian Privacy Principles (APPs) Consider My Health Records Act implications if integrating with health records Health data should be encrypted at rest and in transit Data residency: confirm hosting location (AU-based hosting likely preferred/required for claims/insurer clients) Role-based access control, especially where claims professionals/insurers view individuals' health data Vendor to advise whether this product's clinical claims (risk ratings, compliance verdicts) require any regulatory classification (e.g., as a clinical decision support tool) under Australian therapeutic goods or software-as-a-medical-device frameworks — flag this even if outside dev scope, as it affects legal review before launch 9. Cybersecurity, Governance & PII Compliance — ASX-Listed Client Requirement Insurers and claims organisations in our target market are frequently ASX-listed companies (or their subsidiaries). Before they'll onboard a platform that touches health/PII data, their procurement, legal, and security teams will run us through a formal review. The platform must be built to pass these checks, not retrofitted afterwards. This needs to be priced into the build, not treated as a later add-on. At minimum, the platform needs to be able to demonstrate: ACSC Essential Eight alignment — the ASD/ACSC's baseline cybersecurity framework (application control, patching, MFA, restricted admin privileges, backups, macro controls, etc.). Insurers and larger ASX-listed procurement teams increasingly ask for evidence of Maturity Level 2 as a baseline before they'll onboard a vendor, and treat it as a factor in cyber insurance and supply-chain risk assessments. (Note: ASD announced in 2026 that the Essential Eight will be progressively retired in favour of a new "Essentials" series over roughly 24 months — vendor should confirm which version of the framework they're building against at contract time, since this is actively transitioning.) ASX Corporate Governance Council Principles — our ASX-listed clients are required to report on cyber/operational risk oversight to their boards; a vendor supplying them with software needs to be able to answer their due-diligence questionnaires (data flows, access controls, incident response, sub-processors). Privacy Act 1988 (Cth) and Australian Privacy Principles (APPs) — correct handling of health information as sensitive information under the Act, with data minimisation, consent, and access/correction mechanisms Notifiable Data Breaches (NDB) scheme — architecture and logging must support breach detection and the mandatory OAIC/affected-individual notification obligations APRA CPS 234 (Information Security) — if our insurer clients are APRA-regulated entities, they will likely require their vendors/service providers to demonstrate information security controls consistent with CPS 234, including incident notification to APRA-regulated clients within contractually agreed timeframes ISO 27001 and/or SOC 2 — many enterprise/ASX procurement teams will ask whether the platform (or its hosting provider) holds, or is on a roadmap to, one of these certifications. Vendor should advise on realistic timeline/cost if we want to pursue certification post-launch Data residency and encryption — Australian data hosting (unless a client specifically requires otherwise), encryption at rest and in transit, and clear data flow diagrams we can hand to a client's security team Audit-ready access logging — every access to a PII/health record must be logged (who, when, what), separate from the clinical audit trail described in Module 3, so we can answer a security questionnaire without a rebuild What we need from vendors on this specifically: Confirmation of which of the above your proposed architecture and hosting provider can support out of the box, and which require additional configuration/cost Whether your team has experience passing enterprise/ASX-listed vendor security questionnaires (this is a very common, and often lengthy, gate before an insurer will sign a contract) A recommendation on whether to pursue ISO 27001/SOC 2 certification pre- or post-launch, and rough cost/timeline either way Confirmation that PII/health data handling in your proposed design is reviewable by our legal/privacy advisor before build sign-off 10. What We Need From Vendors in Their Quote Please respond with: Recommended technical approach for the AI engine (interaction database sourcing, rules engine design, LLM use if any) Recommended tech stack (frontend, backend, hosting, database) Breakdown of cost and timeline by module (Module 1, 2, 3, plus core platform/accounts/reporting) Data licensing costs, if a commercial drug interaction database is recommended (separate from your dev fee) Ongoing maintenance cost for keeping rules/data current post-launch Team composition proposed for the build (and whether any clinical/regulatory advisor is included or recommended separately) Assumptions and exclusions — anything you're assuming is out of scope Any regulatory/compliance risks you'd flag before we proceed, even if resolving them isn't part of your quote How your architecture meets the cybersecurity/governance/PII requirements in Section 9 — this is a hard requirement for us to close deals with ASX-listed insurer clients, not a nice-to-have 11. Explicitly Out of Scope (for this quote, unless flagged otherwise) Insurer-side claims management systems integration (unless raised as a future phase) 12. Open Questions We Still Need to Answer Internally (for vendor awareness) Which drug interaction database will be licensed vs. built Final list of jurisdictions/guidelines beyond TGA/WorkSafe/SIRA/NICE/PBS (state-by-state WorkSafe/SIRA variance in Australia is significant — NSW SIRA vs. other states' schemes differ) Data hosting/residency requirements from prospective insurer clients Whether we pursue ISO 27001/SOC 2 certification before approaching ASX-listed insurer prospects, or use it as a post-sale commitment during contract negotiation