Application & Architecture Overview

Describes the main application surfaces, user groups, and simple technical architecture for a future validation system.

Product Shape

The proposed system is a SaaS platform with multiple connected user experiences:

• a browser-based practitioner application
• a participant-facing mobile and/or web application
• an organisational administration and support layer
• secure shared services for identity, data, reporting, configuration, messaging, and video consultation

The platform should operate as a coordinated service delivery system rather than as separate disconnected apps. Each user group sees the information and controls appropriate to their role, consent settings, and support responsibilities.

Audience 1 - Practitioner

Practitioners are the primary day-to-day professional users. They need a browser-based control system that helps them manage participants between face-to-face sessions and online consultations.

Practitioner Application

Likely delivered as a secure web application available from desktop, laptop, and tablet browsers.

Core capabilities:

• View assigned participant caseload
• See recent engagement, missed check-ins, and routine completion
• Review mood, feeling, struggle, task, calendar, and journal summaries
• Configure participant check-ins, routines, reminders, and support prompts
• Schedule or view face-to-face sessions, online sessions, and follow-ups
• Start or join one-to-one and group video consultations
• Send structured messages or support requests
• Review participant progress and engagement trends
• Flag concerns or escalate support needs
• Capture practitioner feedback about what is and is not working

Practitioner Value

• understand what is happening between formal sessions
• intervene earlier when participants disengage or struggle
• prepare better for face-to-face consultations
• manage larger caseloads without losing visibility
• provide a more consistent support experience
• contribute feedback for continuous service improvement

Audience 2 - Participant and Support System

The participant-facing system is the daily-use experience for the neurodivergent person. It should be available on mobile first, with the option of browser access where appropriate.

The term "support system" includes family members, carers, local support workers, or other approved people who help the participant use the system or follow their support plan.

Participant Application

Likely delivered as a mobile application, with a responsive web version where useful.

Core capabilities:

• Daily or scheduled check-ins
• Feeling, mood, or struggle feedback
• Simple to-do list
• Simple calendar
• Routine and medication reminders
• Notes or journal entries
• Visibility of upcoming face-to-face and online sessions
• Push notifications, SMS reminders, or affirmations
• Simple support requests
• Join scheduled one-to-one or group video sessions
• Interface complexity and notification style configured to the participant's needs

Support Circle Access

Support access should be configurable, because participants will have very different levels of independence and local support.

Possible support roles:

• family member
• carer
• support worker
• local coordinator
• trusted person

Possible support capabilities:

• view selected routines or reminders
• see upcoming appointments
• receive missed check-in alerts
• help the participant complete tasks or routines
• assist with video session attendance
• provide limited feedback to the practitioner
• receive escalation prompts where appropriate

Supporter access should not automatically mean full access to all participant information. It should be controlled by permissions, consent, role, and support intensity.

Participant and Support System Value

• make support more regular and predictable
• reduce confusion about what is happening and when
• create a simpler way to share how the participant is feeling
• help families and local supporters understand their role
• reduce the gap between infrequent face-to-face sessions
• make online engagement feel like additional support rather than removed service

Audience 3 - Organisation Administration and Practitioner Support

Provider organisations need an administration layer to manage their service delivery, practitioners, compliance needs, reporting, and support quality.

This is separate from the practitioner application, although some senior practitioners or team leaders may use both.

Organisation Administration Application

Likely delivered as a secure browser-based SaaS admin portal.

Core capabilities:

• Manage practitioners and teams
• Assign participants to practitioners
• Configure organisational settings and service programs
• Manage role-based access and permissions
• Review aggregate engagement and service delivery reporting
• Monitor practitioner workload and caseload distribution
• Review adoption, usage, and pilot KPIs
• Manage consent, privacy, and data retention settings
• Support practitioner training, supervision, and mentoring
• Identify where practitioners need additional support

Practitioner Support and Mentoring

As caseloads increase, practitioners may need support inside the organisation. The platform could help by making patterns visible:

• which participants are disengaging
• which practitioners are overloaded
• which workflows are not being used
• where additional training is required
• where peer support or mentoring should be offered
• which digital service patterns are producing better engagement

This layer matters because the product is not only improving participant support. It is also changing how practitioners work, and the organisation needs tools to manage that transition responsibly.

Simple Technical Architecture

The system can be understood as four connected layers.

1. User Applications

• Practitioner web application
• Organisation administration web application
• Participant mobile application
• Participant/supporter web access where appropriate

2. Platform Services

• Identity and authentication
• Role-based access control
• Participant profile and configuration service
• Check-in and routine service
• Calendar and scheduling service
• Messaging and notification service
• Video consultation service
• Reporting and analytics service
• Audit, consent, and privacy controls

3. Data Layer

• Participant profiles
• Practitioner and organisation accounts
• Support-circle permissions
• Check-in history
• Task and routine history
• Session and appointment history
• Notes, journals, and structured feedback
• Usage and engagement analytics
• Audit logs and consent records

4. Integration Layer

Potential integrations over time:

• SMS provider
• email provider
• push notification service
• video infrastructure
• calendar systems
• provider case management systems
• reporting exports for funders or government
• health or disability service compliance systems where required

Interaction Flow

1. The organisation sets up practitioners, participants, roles, and service programs.
2. The practitioner configures the participant's routines, check-ins, reminders, and support-circle access.
3. The participant uses the mobile or web application for daily engagement.
4. Family or local supporters receive only the access and prompts appropriate to their role.
5. The platform turns participant activity into summaries, alerts, and trends.
6. The practitioner reviews this information and adjusts support.
7. Online or face-to-face sessions are scheduled and tracked through the system.
8. The organisation reviews aggregate reporting, adoption, workload, and service quality signals.
9. Pilot evidence is generated for future funding, cost, and service model discussions.

Simple Architecture Diagram

flowchart LR
    Participant["Participant App
Mobile / Web"]
    Supporter["Family / Local Support
Limited Role-Based Access"]
    Practitioner["Practitioner Portal
Browser-Based SaaS"]
    Admin["Organisation Admin Portal
Browser-Based SaaS"]

    Platform["Core SaaS Platform
Identity, Permissions, Configuration,
Check-ins, Scheduling, Messaging,
Video, Reporting, Audit"]
    Data["Secure Data Layer
Profiles, Engagement, Notes,
Schedules, Consent, Audit Logs"]
    Integrations["External Services
SMS, Push, Email, Video,
Calendars, Reporting Exports"]

    Participant --> Platform
    Supporter --> Platform
    Practitioner --> Platform
    Admin --> Platform

    Platform --> Data
    Platform --> Integrations
    Platform --> Practitioner
    Platform --> Participant
    Platform --> Supporter
    Platform --> Admin
          

Design Implications

• The practitioner experience should feel operational, fast, and caseload-oriented.
• The participant experience should be calm, simple, and configurable.
• Supporter access should be permissioned and specific, not broad by default.
• The organisation layer should focus on governance, reporting, workload, and service quality.
• Data should flow into useful summaries rather than overwhelming practitioners with raw detail.
• Privacy, consent, auditability, and role-based access need to be treated as foundational from the start.