The IA3 should include the following sections:
Success Criteria¶
Success criteria should be developed by considering the problem from both the user’s and the developer’s perspective, and by breaking the problem down to identify what “quality,” “appropriate” and “secure” actually mean for this solution.
Criteria should address:
user experience
technical outcomes
problem-specific security considerations for data, e.g. confidentiality, integrity, availability
Possible Solutions¶
User Interface¶
Should show mock-ups/sketches of the dashboard:
explain the application of the elements (space, line, colour, shape, texture, tone, form, proportion, scale) and principles (balance, contrast, proximity, harmony, alignment, repetition, hierarchy) of visual communication
have explicit reference to usability principles (accessibility, effectiveness, safety, utility, learnability) justifying design decisions
demonstrate how the interface differentiates access/views for the three end-user profiles (practice manager, clinical staff, administration staff), reflecting their different levels of dashboard access
demonstrate how graphs, logs and other visual data representations are used to display privacy/security status, per the stimulus’s functional requirements
demonstrate compliance with accessibility standards relevant to the chosen technology context (web or mobile), per the stimulus’s non-functional requirements
show how UI design decisions relate to the data and security design of the solution, so the interface, data and back-end behave as one coherent system
Secure Data and Data Repositories¶
Draw on relevant secure data concepts to justify your design decisions against your success criteria — you do not need to demonstrate every technique below, only those relevant to your solution:
data naming conventions, formats and structures
secure data transmission techniques: encryption, decryption, authentication, hashing, checksums
symmetric (DES, Triple DES, AES, Blowfish, Twofish) and/or asymmetric (RSA) encryption algorithms
encryption and authentication strategies, e.g. 2FA/MFA (verification codes vs biometrics)
security principles: confidentiality, integrity, availability of data
how application sub-systems (front end, back end) work together
data flow through the system (data flow diagrams)
Australian Privacy Principles considerations from a digital systems perspective
Programmed Components¶
Should show pseudocode that demonstrates your solution’s logic — select the constructs and features relevant to your solution rather than attempting to include everything below:
that uses the basic algorithm constructs: assignment, sequence, selection, condition, iteration, modularisation
for security-related algorithms
that references the five basic features of programming: variables, control structures, data structures, syntax, libraries and classes
that has evidence of good programming practices: dependability, efficiency, testing, debugging, error correction, coding conventions (commenting, naming conventions), code simplicity, portability
for receiving, processing and displaying data from an external source (relevant to the dashboard pulling data from the database)
that considers appropriate data formats for exchange, e.g. JSON or XML
that includes SQL statements as applicable: CREATE, DROP, ALTER, INSERT, UPDATE, SELECT with WHERE, GROUP BY, HAVING, ORDER BY, sub-selection, inner-joins
Prototype Digital Solution¶
Should show:
functioning UI screens for at least the core APP-related features
actual programmed logic demonstrating selection, iteration, user input, and data output
evidence the components interact coherently — UI actions reflecting data changes, data being retrieved/displayed securely
Potential and Desired Impacts¶
Should include:
evaluation of impacts specifically tied to data security and privacy (not general solution impacts)
personal impacts — e.g. effects on patients whose data is collected/shared, and on staff using the dashboard
social impacts — e.g. trust in the practice, community perception of data handling
economic impacts — e.g. cost of compliance, cost/consequences of breaches, resourcing implications for the practice
explicit grounding in the Road to Recovery context and the specific solution generated, not generic commentary
links to relevant Australian Privacy Principles and risks to data confidentiality, integrity and availability
evidence-based judgements, supported by specific, measurable outcomes rather than vague statements — a succinct list of key outcomes is acceptable under the 2025 syllabus
authentic acknowledgement of constraints, e.g. where the prototype could not fully implement a security feature and what that means for the impact assessment
Evaluation¶
Per the ISMG Evaluating criterion and syllabus specification, this section must evaluate the prototype against the established success criteria, covering:
User Experience
Programmed Components
security considerations for data
Note:
judgements should be specific and measurable, linked directly back to the success criteria established earlier
success criteria should guide what is actually tested, so the testing/feedback evidence should map cleanly onto the criteria set out earlier in the response
this can be presented as a succinct list of key outcomes rather than lengthy prose
Refinements and Recommendations¶
specific refinements/recommendations for current improvements
recommendations for future improvements
Note: both must be explicitly justified by user feedback and testing outcomes — judgements should be evidence-based, not general opinion.
Communicating¶
Throughout the response:
combine visual representations with annotations and written or spoken features to describe, explain and justify decisions clearly and cohesively, within the response limits
use subject-matter language accurately and appropriately for a technical audience
use accurate grammar and sentence structures to maintain clarity
use referencing conventions consistently to acknowledge sources