A capability the future DFSV solution requires
Web portal
Digital Channels
Overview
The public-facing digital channel through which a person seeking help, or a worker supporting them, can make first contact, apply for a service, track progress and receive an outcome.
Alignment to the Royal Commission recommendations
- R59Further enhancing the Domestic Violence Disclosure Scheme, including improvements to the online application portal.
Publicly available starting point to dive deeper and validate
The Disclosure Scheme application is currently hosted on SAPOL's website, and the Royal Commission called for it to move to the government's central DFSV website with improved accessibility for people who speak other languages and people with disability. The scheme is a means of requesting information about another person, so it does not serve as a help-seeking channel, and no digital help-seeking channel was identified in the public material reviewed. AlignedRec. 59
Systems supporting this capability across the sector
Initial requirements for the future DFSV information sharing solution 13 · 6 must have
| Requirement | Type | Priority |
|---|
| Provide an online application channel for the Domestic Violence Disclosure Scheme, hosted on the government's central DFSV website, and not an individual agency's site. | Functional | Must haveR59 |
| Support the DVDS assessment and disclosure workflow end-to-end: application intake, assessment task routing, disclosure decision, and outcome notification to the applicant. | Functional | Must haveR59 |
| Allow a caseworker to view and progress an in-flight DVDS application task queue. | Functional | To be assessed with stakeholder input |
| Provide a persistent application reference or status an applicant, or a worker supporting them, can check without re-lodging. | Functional | To be assessed with stakeholder input |
| Present the application and its outcome in a form navigable by screen readers and other assistive technology. | NFR | Must haveR59 |
| Provide the application, and the explanation of its outcome, in community languages relevant to the client base, using translations reviewed by a qualified human translator, and provide access to an accredited interpreter where a person needs to discuss their application. | NFR | Must haveR59 |
| Support use by applicants with disability (e.g. alternative input methods, extended session timeouts, a plain-language mode). | NFR | Must haveR59 |
| Be capable of being hosted through the government's central DFSV website rather than a single agency domain. Any expansion beyond the Disclosure Scheme would be tested through service design and governance work. | NFR | Must haveR59 |
| Provide a help-seeking entry point through which a person, or a worker supporting them, can make first contact and be routed to a service, distinct from requesting information about another person. | Functional | To be assessed with stakeholder input |
| Be presentable through separate web presences for adults and for children and young people, while holding a single record of a contact behind both. | NFR | To be assessed with stakeholder input |
| Allow the central entry-point service to create and retain a record of each contact made through the channel, with the custodian of that record identified and the retention period set against it. | Functional | To be assessed with stakeholder input |
| Meet the authentication and session-security requirements that apply to comparable SA Government citizen-facing digital services, to be confirmed during Phase 2. | NFR | To be assessed with stakeholder input |
| Present information, and the outcome of a request, in a form appropriate to the age of the person reading it, so that a child or young person using the children and young people presence is not served an adult-facing response. | Functional | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- Take us through a Disclosure Scheme application from the moment it is lodged to the moment the person is told the outcome — who touches it, what has to be checked by hand, and where does it sit waiting?
- For workers who sit beside someone while they apply: what stops an application being finished — the language it is offered in, the detail it asks for, the device the person has, or the risk of doing it at home?
- If applications moved onto a single DFSV website, which team would own that site day to day, and who would answer an applicant ringing to ask where their application is up to?
- Which other DFSV services should sit behind that same front door within the first two years, and which need to keep a separate entry point of their own?
- If the help-seeking channel is built into the Central Entry Point and that service is commissioned to a non-government organisation, who is the custodian of the records it creates — the provider, the commissioning department, or the owner of the web platform — and under what retention obligation?
- With separate web presences planned for adults and for children and young people, does a contact made through one need to be visible from the other, and who decides that for a young person?
A capability the future DFSV solution requires
Agency / provider portal
Digital Channels
Overview
The channel through which an agency or funded provider records and reads shared information, where it does not have a case management system of its own.
Alignment to the Royal Commission recommendations
- R20A whole-of-government technological solution for information aggregation and sharing for DFSV.
Publicly available starting point to dive deeper and validate
There is no single "front door" — help-seeking today happens through numerous separate, parallel entry points (SAPOL, crisis helplines, DVDS, specialist DFSV services, housing/homelessness services, courts/legal services, the Adult Safeguarding Unit, child protection, victims-of-crime channels, and advocacy/community/health services). AlignedRC report, Ch.4, "Current pathways for help seeking", p.270–271, p.278–293
Systems supporting this capability across the sector
Initial requirements for the future DFSV information sharing solution 7 · 3 must have
| Requirement | Type | Priority |
|---|
| Allow an agency or funded provider without its own case management system to record intake, assessment and service information directly. | Functional | Must haveR20 |
| Present to each participating organisation the shared information its access profile authorises, and no more. | Functional | Must haveR20 |
| Allow a provider to submit a referral and to see its progress through to acceptance or decline. | Functional | To be assessed with stakeholder input |
| Allow a provider to update service delivery and outcome information against a shared client record it contributes to. | Functional | To be assessed with stakeholder input |
| Support organisations of widely differing size and technical maturity, including those with no integration capability of their own. | NFR | To be assessed with stakeholder input |
| Allow access profiles to be set per organisation and per program as an administrative act. | NFR | Must haveR20 |
| Meet SA Government requirements for third-party access to government-held information. | NFR | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- Walk us through an intake at your service — what you ask, what you write down, and which system it goes into.
- What would let your service contribute to and draw from a shared record while keeping the case management system you already use?
- When a person is being supported by several services at the same time, who notices, and how?
- What would you need to see before you were confident that what you record about a client cannot be read by someone who should not read it?
A capability the future DFSV solution requires
Practitioner workspace
Digital Channels
Overview
The single working view a practitioner uses to see and act on the clients they are responsible for, drawing information from across participating agencies.
Alignment to the Royal Commission recommendations
- R20A whole-of-government technological solution for information aggregation and sharing for DFSV.
Publicly available starting point to dive deeper and validate
No consolidated practitioner view was identified in the public material reviewed. Workers assemble a picture of a client from their own agency's system, telephone calls and what the client tells them, which is the practice the Royal Commission described. Whether a shared workspace or an integration into each agency's existing system is the better answer will be tested with practitioners during Phase 2. KPMG hypothesis for validation
Initial requirements for the future DFSV information sharing solution 7 · 2 must have
| Requirement | Type | Priority |
|---|
| Present a practitioner with one working view of the clients they are responsible for, drawing on information held across participating agencies. | Functional | Must haveR20 |
| Show, for each client, what is known, which agency holds it, when it was last updated and the authority it was shared under. | Functional | Must haveR20 |
| Allow a practitioner to complete the tasks a case requires — assessment, referral, note, plan update — without leaving the workspace. | Functional | To be assessed with stakeholder input |
| Surface what has changed since the practitioner last looked, rather than requiring them to re-read the record to find it. | Functional | To be assessed with stakeholder input |
| Support handover of a caseload between practitioners, with the receiving practitioner able to see what was known at the point of handover. | Functional | To be assessed with stakeholder input |
| Where an agency's own system remains its system of record, avoid duplicate entry of the same information. Whether the system of record remains with each agency will be tested with practitioners during Phase 2. | NFR | To be assessed with stakeholder input |
| Meet the accessibility requirements applying to SA Government workplace systems. | NFR | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- Walk us through what a practitioner opens at the start of a shift, and how many systems they are in before they have a picture of one client.
- Which parts of a practitioner's work must stay in their own agency's system of record, and which could move to a shared workspace?
- What would a practitioner need to be told has changed since they last looked, and what would be noise?
- When a caseload moves between practitioners, what is handed over today, and what gets lost in the handover?
A capability the future DFSV solution requires
Mobile & field access
Digital Channels
Overview
Access for workers operating away from a desk — family safety practitioners, child safety practitioners, social workers and outreach workers — in field, home visit and court support settings.
Alignment to the Royal Commission recommendations
- R20A whole-of-government technological solution for information aggregation and sharing for DFSV.
Publicly available starting point to dive deeper and validate
No mobile or field access gap specific to this channel was identified in the public material reviewed. This will be treated as an evidence gap for Phase 1 validation, and not as a finding that no gap exists. KPMG hypothesis for validation
Initial requirements for the future DFSV information sharing solution 7 · 1 must have
| Requirement | Type | Priority |
|---|
| Give a practitioner working away from a desk read access to the client information their role authorises. | Functional | To be assessed with stakeholder input |
| Allow a visit note, assessment or risk observation to be captured in the field and written back to the shared record. | Functional | To be assessed with stakeholder input |
| Allow a practitioner to signal an urgent change in risk from the field so that it reaches the coordinating record immediately. | Functional | Must haveR20 |
| Define what information may be stored on a device, for how long, and under what controls, including the risk of device loss, theft or unauthorised viewing. | NFR | To be assessed with stakeholder input |
| Define the behaviour where there is no connectivity, including what is held on the device and what is queued for later write-back. | NFR | To be assessed with stakeholder input |
| Work with the device management and access tooling each agency already operates. | NFR | To be assessed with stakeholder input |
| Revoke access to a device remotely, and evidence that revocation. | NFR | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- Which practitioners work away from a desk — family safety practitioners, child safety practitioners, social workers, outreach and court support workers — and what do they carry with them today: a phone, a printed list, or notes on paper?
- What is the minimum information a worker needs on a device at someone's front door, given the risk that the device could be lost, taken or viewed by someone else?
- What should happen when there is no signal — hold information on the device, or accept that the worker goes in without it?
- How does a worker record what happened during a visit today, and how long before it reaches a system anyone else can see?
A capability the future DFSV solution requires
Contact centre
Digital Channels
Overview
Telephone and contact-centre access into DFSV services. The question for this study is how existing agency-owned channels connect to the broader information sharing model, and not whether they should be rebuilt.
Alignment to the Royal Commission recommendations
- R20A whole-of-government technological solution for information aggregation and sharing for DFSV.
- R47Procurement of a records management and information-sharing system for the central entry-point service and its partner organisations.
Publicly available starting point to dive deeper and validate
Reports primarily arrive through police domestic abuse occurrence reports and phone-based triage, feeding into MAPS's SAPOL-led review team. No shared intake pathway is evident across the wider service system. AlignedRC report, Ch.2, p.157
Systems supporting this capability across the sector
Initial requirements for the future DFSV information sharing solution 8 · 3 must have
| Requirement | Type | Priority |
|---|
| Create a contact record at the point of first contact, capturing what the person chose to disclose, without requiring them to identify themselves. | Functional | Must haveR47 |
| Link a contact to an existing client record where the person consents and their identity can be established, and hold it unlinked where they do not. | Functional | To be assessed with stakeholder input |
| Raise a referral from within a contact and confirm its receipt back to the person who took the call. | Functional | Must haveR47 |
| Present a returning caller's earlier contacts to the worker taking the call, to the extent the consent recorded against them allows. | Functional | To be assessed with stakeholder input |
| Record a risk indicator raised during a call so that it is visible to the next worker without the person repeating the account. | Functional | Must haveR20 |
| Support rapid contact recording during a call through a workflow that does not materially disrupt the safety conversation, with detailed usability requirements defined during Phase 2. | NFR | To be assessed with stakeholder input |
| Operate at the availability a crisis line requires, with a defined degraded mode that still allows a contact to be captured. | NFR | To be assessed with stakeholder input |
| Retain contact records under the State Records Act 1997 (SA), with a retention period set specifically for crisis contact information. | NFR | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- Which phone lines and triage points are in scope, and do any two of them share a client record today?
- When a call comes in from someone already known to another service, what can the person answering see, and what do they have to ask all over again?
- Where does a call end in a referral that someone then re-types into another system, and how many times does that happen in a shift?
- What would a triage worker need in front of them to make a safe decision at two in the morning, and what should they be prevented from seeing?
A capability the future DFSV solution requires
Client & case management
Service & Case Management
Overview
The client record that persists across services and episodes, and the case records attached to it.
Alignment to the Royal Commission recommendations
- R47Procurement of a records management and information-sharing system for the central entry-point service and its partner organisations.
- R80Inclusion of accommodation options for people using violence within the statewide DFSV accommodation register, with clear separation from accommodation for victim-survivors.
Publicly available starting point to dive deeper and validate
Homelessness2Home is used for DFSV crisis case recording but was designed for homelessness services and has been identified as not meeting specialist DFSV provider needs. AlignedRC report, Ch.4, p.298
Systems supporting this capability across the sector
Initial requirements for the future DFSV information sharing solution 8 · 5 must have
| Requirement | Type | Priority |
|---|
| Hold a client record that persists across services and episodes, distinct from the case records attached to it. | Functional | Must haveR47 |
| Support more than one concurrent case against the same client, held by different agencies, without merging them. | Functional | Must haveR47 |
| Hold records for victim-survivors, children and young people, and perpetrators separately, with separate visibility settings. | Functional | Must haveR80 |
| Record the plan for a case, the actions under it, their owners and their status. | Functional | To be assessed with stakeholder input |
| Record case closure and the reason for it, and support reopening a case without losing the earlier history. | Functional | To be assessed with stakeholder input |
| Link a case to related cases — the household, the family, or the same perpetrator — without merging the underlying records. | Functional | Must haveR47 |
| Support the case volumes and concurrent users of the statewide DFSV service system, with sizing established during Phase 2. | NFR | To be assessed with stakeholder input |
| Preserve an unaltered history of what a case record held at each point in time. | NFR | Must haveR47 |
Questions we would raise in stakeholder workshops and interviews
- Which case management systems would need to connect, who owns each of them, and who holds the vendor contract?
- Where should a shared DFSV record end and your own case management begin — what would you want to keep inside your system?
- What would your agency need in order to accept a referral or an update raised outside its own system, and what would stop you acting on it?
- When you send a referral today, how do you find out whether it was accepted, and what do you do when you hear nothing back?
A capability the future DFSV solution requires
Integrated risk assessment
Service & Case Management
Overview
The assessment of risk to a person, the plan that follows from it, and the referral pathway the outcome informs. The Domestic Violence Risk Assessment is the tool in use, and KPMG understands a replacement framework is in development. No published confirmation of its scope or timing was identified, and this will be validated with DHS Office for Women during Phase 1.
Alignment to the Royal Commission recommendations
- R20A whole-of-government technological solution for information aggregation and sharing for DFSV.
- R59Further enhancing the Domestic Violence Disclosure Scheme, including improvements to the online application portal.
Publicly available starting point to dive deeper and validate
Risk Assessment and Referral Forms are currently manual, paper-based records sent ahead of Family Safety Meetings, and not shared system records. AlignedFamily Safety Framework Practice Manual
Systems supporting this capability across the sector
Initial requirements for the future DFSV information sharing solution 8 · 4 must have
| Requirement | Type | Priority |
|---|
| Support completion of whichever risk assessment framework is in force, currently the Domestic Violence Risk Assessment, without rebuilding when the framework is revised or replaced. | Functional | Must haveR20 |
| Hold the assessment as a structured record rather than a document, so that its factors and its rating can be read by another authorised service. | Functional | Must haveR20 |
| Support cohort-specific variation in the assessment, including for Aboriginal people, children and young people, people with disability, multicultural communities and people who identify as LGBTIQA+. | Functional | To be assessed with stakeholder input |
| Make the assessment outcome available to the referral pathway. Whether an outcome triggers a referral automatically or prompts a practitioner decision would be settled with the sector during Phase 2. | Functional | Must haveR20 |
| Show the most recent assessment, its date, its author and its authority alongside any earlier assessment, without overwriting the history. | Functional | To be assessed with stakeholder input |
| Allow an authorised worker in another agency to see the rating, the rating with its contributing factors, or the full assessment, according to what the sharing arrangement for their role permits. | Functional | Must haveR20 |
| Support a shared system record of the assessment in place of routing paper forms ahead of a Family Safety Meeting. | NFR | To be assessed with stakeholder input |
| Allow the prescribed users of each version of the framework to be maintained as an administrative act. | NFR | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- The Domestic Violence Risk Assessment has been in use since 2007 and was revised once in 2014. Is a replacement framework in development, and if so what is the transition path and the timeline?
- Which agencies and services will be prescribed users of the new framework, and does that group match the people who actually need to see a risk rating?
- How is a risk assessment completed and shared today — walk us through it from the moment it is started.
- If a worker in another agency could see a risk assessment your service completed, what should they see: the rating alone, the rating with the factors behind it, or the full assessment?
- How does a risk assessment vary for different cohorts of victim-survivors — Aboriginal people, people with disability, multicultural communities and people who identify as LGBTIQA+ — and does the assessment tool carry those differences, or does the worker hold them?
A capability the future DFSV solution requires
Referrals & handover
Service & Case Management
Overview
Raising a referral, routing it to the right service, and transferring responsibility for a client between services.
Alignment to the Royal Commission recommendations
- R20A whole-of-government technological solution for information aggregation and sharing for DFSV.
- R47Procurement of a records management and information-sharing system for the central entry-point service and its partner organisations.
Publicly available starting point to dive deeper and validate
The Royal Commission found referral pathways depend on the referring worker knowing who to call, and that a referral often cannot be followed to an outcome. Separating referral and handover from case management makes the requirement explicit rather than assumed inside a case management product. KPMG hypothesis for validation
Initial requirements for the future DFSV information sharing solution 8 · 3 must have
| Requirement | Type | Priority |
|---|
| Raise a referral from within a case, carrying the information the receiving service needs and the authority under which it moves. | Functional | Must haveR20 |
| Confirm to the referring worker that a referral was received, and whether it was accepted or declined, with the reason. | Functional | Must haveR20 |
| Support routing of a referral on assessed need and on the receiving service's eligibility and capacity. | Functional | To be assessed with stakeholder input |
| Support transfer of responsibility for a client between services, with the receiving service able to see what was known at the point of handover. | Functional | Must haveR47 |
| Detect and show where the same person has been referred to the same service more than once. | Functional | To be assessed with stakeholder input |
| Allow a referral to be withdrawn or redirected, with the reason recorded. | Functional | To be assessed with stakeholder input |
| Support referral to organisations with no integration capability, without the referral leaving the audited pathway. | NFR | To be assessed with stakeholder input |
| Establish the balance between system-determined routing and practitioner judgement. This is a design decision to be considered with the sector during Phase 2. | Functional | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- Take us through a referral from the moment a worker decides to make one to the moment the client is seen — where does it wait, and who chases it?
- How does a referring worker find out whether a referral was accepted, and how long does that take?
- Should the system route a referral on the assessed need, or should that stay with the worker's judgement? What goes wrong with each?
- When responsibility for a client moves between services, what does the receiving service need to see, and what should not travel with it?
A capability the future DFSV solution requires
Collaboration and coordination
Service & Case Management
Overview
The coordinated view and the forums through which more than one agency works a single case, including Family Safety Meetings and MAPS.
Alignment to the Royal Commission recommendations
- R20A whole-of-government technological solution for information aggregation and sharing for DFSV.
- R25Model principles for Aboriginal-led responses, including that Aboriginal Community Controlled Organisations retain sovereignty over their own data. This recommendation is not listed in Part B, but it is a direct dependency for information sharing design. The Department has confirmed that the relevant recommendation set extends beyond those Part B identifies.
Publicly available starting point to dive deeper and validate
The Royal Commission and the Flinders review found the Family Safety Framework and MAPS coordinate the same high-risk cases through separate mechanisms that share neither a system nor a single view, and that MAPS does not have access to the Family Safety Framework Portal. AlignedWith Courage, pp.157–158; Flinders SWIRLS review 2024
Initial requirements for the future DFSV information sharing solution 7 · 4 must have
| Requirement | Type | Priority |
|---|
| Provide a coordinated view of a case where more than one agency is involved, while preserving agency system-of-record responsibilities where required. | Functional | Must haveR20 |
| Support the coordinating forums the response uses, including Family Safety Meetings and MAPS, holding agenda, participants, decisions and actions against the case. | Functional | Must haveR20 |
| Record which organisations are involved in a case, their role and their current responsibilities, so workers can identify other relevant participants. | Functional | To be assessed with stakeholder input |
| Notify participants where a decision or action affecting their part of the response changes. | Functional | To be assessed with stakeholder input |
| Allow a specialist or community-controlled organisation to contribute to the coordinated view as a core participant. | Functional | Must haveR25 |
| Produce the coordinated summary a forum needs at the time the forum needs it, rather than through a separate document production process. | NFR | To be assessed with stakeholder input |
| Allow forum types, membership and decision rights to be changed as an administrative act, so that a change to the operating model does not require redevelopment. | NFR | Must haveR20 |
Questions we would raise in stakeholder workshops and interviews
- Where do the Family Safety Framework and MAPS overlap for the same family, and who reconciles the two?
- What does a coordinating forum need in front of it, and how is that produced today?
- What decisions does a forum actually make, and where are they recorded so the next worker can find them?
- If an ACCO or a specialist service joined a forum as a core member, what would have to change in how the meeting record is kept?
A capability the future DFSV solution requires
Client & identity matching
Information Exchange
Overview
The ability to identify and maintain links between records relating to the same person across multiple systems, without requiring a single statewide client identifier.
Alignment to the Royal Commission recommendations
- R80Inclusion of accommodation options for people using violence within the statewide DFSV accommodation register, with clear separation from accommodation for victim-survivors.
Publicly available starting point to dive deeper and validate
No shared identifier or matching mechanism across agency systems was identified in the public material reviewed. This is a hypothesis to test during Phase 1, and not a cited finding. KPMG hypothesis for validation
Systems supporting this capability across the sector
Initial requirements for the future DFSV information sharing solution 9 · 2 must have
| Requirement | Type | Priority |
|---|
| Process records across defined data sources to identify likely records relating to the same person, and support an authorised consolidated view where permitted. | Functional | Must haveR20 |
| Match person records without necessarily requiring a single unique client identifier. | Functional | To be assessed with stakeholder input |
| Display partial or suspected matches to a worker for confirmation or rejection, showing the basis for the suggested match to the extent that worker is permitted to see it, and recording the decision and the worker who made it against the person. | Functional | To be assessed with stakeholder input |
| Use the outcome of a worker's confirmation or rejection to improve future match attempts against the same person. | Functional | To be assessed with stakeholder input |
| Use a configurable set of client-identifying attributes to perform matching, recognising some attributes will not be present in every record. | Functional | To be assessed with stakeholder input |
| Support analysis of false positives and false negatives to improve match accuracy over time. | Functional | To be assessed with stakeholder input |
| Perform matching as a system service, without displaying match-attribute data to users who are not permitted to see it. | NFR | To be assessed with stakeholder input |
| Distinguish and separately manage matched records for perpetrators versus victim-survivors, consistent with Recommendation 80. | NFR | Must haveR80 |
| Log every match, confirmation and rejection decision for audit purposes. | NFR | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- When someone you are supporting has already been through two or three other services, how do you find that out today — do you ask them, ring around, or does a system tell you?
- When a match is uncertain, should the system show it to you flagged for confirmation, or hold it back until it is certain — and what would you need in front of you to decide?
- In the system you administer, which identifying fields are mandatory and reliably filled in, and which are free text that workers skip when someone is in crisis?
- Where a victim-survivor has changed their name, date of birth or address for safety reasons, who should be permitted to see that two records belong to the same person?
A capability the future DFSV solution requires
Information sharing
Information Exchange
Overview
The controlled exchange of defined information between agencies and providers involved in a person's safety, applying the legal threshold that fits each case, in place of a single blanket rule.
Alignment to the Royal Commission recommendations
- R20A whole-of-government technological solution for information aggregation and sharing for DFSV.
- R118Potential integration with the Courts Administration Authority's victim-centred information-sharing system. It is being progressed separately and its delivery is out of scope for this procurement. What is in scope is engaging with the CAA to understand dependencies, integration points and constraints.
Publicly available starting point to dive deeper and validate
The Family Safety Framework and MAPS operate as parallel processes. MAPS Information Summary Documents can take weeks or months to produce. Existing victim-notification arrangements do not cover all court outcomes. AlignedRC report, Ch.2, p.158–159; Rec. 118 rationale, p.556–557
Systems supporting this capability across the sector
Initial requirements for the future DFSV information sharing solution 12 · 4 must have
| Requirement | Type | Priority |
|---|
| Share defined information between DFSV-relevant agencies (child protection, family violence services, health, SAPOL, youth justice, NGOs/ACCOs, courts) against a configurable set of authorised transaction types. | Functional | Must haveR20 |
| Apply the risk-based and consent-based sharing thresholds set out in the SA Information Sharing Guidelines to each transaction, without requiring bespoke agreements per agency pair. | Functional | To be assessed with stakeholder input |
| Support without-consent sharing in high-risk cases under the existing Family Safety Framework referral and meeting mechanism, where that mechanism remains the approved pathway. | Functional | Must haveR20 |
| Present a coordinated view of shared case information across agencies, including information currently managed through the Family Safety Framework and MAPS. | Functional | Must haveR20 |
| Aggregate relevant risk information drawn from the SA Risk Assessment and Management Framework and the agencies within the integrated response model. | Functional | Must haveR20 |
| Extend information sharing to cover court and justice outcomes beyond bail/sentence and intervention-order changes, closing the gap today's victim-notification mechanisms leave open. | Functional | To be assessed with stakeholder input |
| Record and make auditable every cross-agency information-disclosure decision, including its legal basis. | NFR | To be assessed with stakeholder input |
| Prevent blanket agency-level access to shared information. Access must be role, purpose and permission based. | NFR | To be assessed with stakeholder input |
| Operate within a defined data-retention and disposal schedule consistent with State Records Act 1997 (SA) obligations for each information type shared. | NFR | To be assessed with stakeholder input |
| Show, against every item in an aggregated view of a person, which agency holds the source record, when that record was last updated, and a working link back to the source item for a worker permitted to see it. | Functional | To be assessed with stakeholder input |
| Notify workers with a current, authorised interest in a person when newly shared information materially changes what is known about that person's risk, and record that the notification was delivered and whether it was acknowledged. | Functional | To be assessed with stakeholder input |
| Present the sharing threshold and legal basis that applies to a proposed disclosure at the point the worker is deciding to make it, with a link to the source provision it comes from. | Functional | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- For people who sit in both a Family Safety Meeting and the Multi-Agency Protection Service: what does each one give you that the other does not, and what do you end up doing twice?
- By the time an Information Summary Document reaches you, what has already been decided? What would change in your response if the same picture arrived within a day?
- Which pieces of information do you share almost every time without hesitating, and which do you stop and seek advice on first?
- The Royal Commission heard that victim-survivors learn about court and justice outcomes late or by accident. Which outcomes should reach a victim-survivor automatically, and who should be accountable for making sure they do?
A capability the future DFSV solution requires
Consent, authority and disclosure
Information Exchange
Overview
The consent, statutory authority and disclosure basis under which each item of information moves, held against the item rather than the person alone.
Publicly available starting point to dive deeper and validate
The Information Sharing Guidelines establish a consent and risk-based sharing model, but no dedicated system was identified that captures, applies and audits individual consent decisions across agencies. KPMG hypothesis for validation
Systems supporting this capability across the sector
Initial requirements for the future DFSV information sharing solution 10 · 0 must have
| Requirement | Type | Priority |
|---|
| Capture a documented consent or legal-basis status (e.g. consent given, consent withdrawn, without-consent high-risk pathway, statutory obligation) against each information-sharing transaction, including the channel and form in which consent was given. | Functional | To be assessed with stakeholder input |
| Record who sought consent, from whom, when, and for what specific purpose or disclosure. | Functional | To be assessed with stakeholder input |
| Allow a client to withdraw or vary consent, and propagate that change to any sharing decisions still pending. | Functional | To be assessed with stakeholder input |
| Distinguish consent captured for routine sharing from the without-consent, high-risk pathway the Family Safety Framework provides, so the correct legal basis is always visible to a worker deciding whether to share. | Functional | To be assessed with stakeholder input |
| Support consent capture in a form and language accessible to people who speak other languages or have disability, consistent with the accessibility standard the Royal Commission sets for the Domestic Violence Disclosure Scheme. | NFR | To be assessed with stakeholder input |
| Make every consent decision and its legal basis auditable, independent of the audit trail for the sharing transaction it supports. | NFR | To be assessed with stakeholder input |
| Prevent a sharing transaction from proceeding where no valid consent or legal basis is recorded, unless an explicit high-risk override is applied and logged. | NFR | To be assessed with stakeholder input |
| Retain the evidence supporting a recorded consent — a signed form, a recording of consent given verbally, or a worker's contemporaneous file note — and link it to the consent record it supports. | Functional | To be assessed with stakeholder input |
| Make a consent captured through one channel visible to, and usable by, a worker operating in another, so a person is not asked to give the same consent twice for the same purpose. | Functional | To be assessed with stakeholder input |
| Support age-appropriate consent and capacity arrangements where the client is a child or young person, including whose consent governs a disclosure and when a young person can consent for themselves. | Functional | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- Where do you write down that a person has agreed to their information being shared, and could a worker in another agency see that today?
- When someone withdraws consent, what do you do about information that has already been passed on, and what do you tell them you can and cannot undo?
- How often do you rely on the high-risk pathway to share without consent, and what makes it hard to be confident the threshold has been met?
- Who should be accountable for the accuracy of a recorded legal basis — the worker who made the call, their agency, or the steward of the shared system?
A capability the future DFSV solution requires
Integration, APIs & events
Information Exchange
Overview
The technical means by which systems exchange information with each other, and the notifications that tell a system a relevant event has changed in another system.
Alignment to the Royal Commission recommendations
- R20A whole-of-government technological solution for information aggregation and sharing for DFSV.
- R118Potential integration with the Courts Administration Authority's victim-centred information-sharing system. It is being progressed separately and its delivery is out of scope for this procurement. What is in scope is engaging with the CAA to understand dependencies, integration points and constraints.
Publicly available starting point to dive deeper and validate
No shared technical integration layer was identified in the public material reviewed. MAPS's information sharing product is a relevant current mechanism, and the Commission has stated that any new solution must have regard to it. AlignedRec. 20(b)
Systems supporting this capability across the sector
Initial requirements for the future DFSV information sharing solution 9 · 3 must have
| Requirement | Type | Priority |
|---|
| Expose and consume a defined set of APIs and events to exchange DFSV-relevant data with agency case-management systems — including, but not limited to, child protection, police, health, justice, courts and funded providers — without requiring those systems to be replaced. | Functional | Must haveR20 |
| Provide event-based notification (e.g. a new risk flag, referral or disclosure outcome) to subscribing agency systems, without requiring those systems to poll for changes. | Functional | To be assessed with stakeholder input |
| Interoperate with the state's new child protection case-management system, KidSafe Connect, via a defined interface. | Functional | Must haveR20 |
| Interoperate with SA Health's information-exchange mechanisms via a defined interface. | Functional | To be assessed with stakeholder input |
| Have regard to, and where appropriate reuse patterns from, the information-sharing product currently used by MAPS. | Functional | Must haveR20(b) |
| Maintain a defined, dependency-only interface with Courts Administration Authority systems relevant to Recommendation 118, without assuming responsibility for CAA's own delivery of that recommendation. | NFR | To be assessed with stakeholder input |
| Version and deprecate integration interfaces without forcing a synchronised release across every connected agency system. | NFR | To be assessed with stakeholder input |
| Monitor and alert on integration failures or latency per connected system, so a broken feed does not silently degrade information sharing. | NFR | To be assessed with stakeholder input |
| Apply consistent authentication and authorisation to every system-to-system integration, independent of the human user access model (see Security & access control). | NFR | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- When a Multi-Agency Protection Service partner needs information from another agency, is that a query into a shared platform, or does each agency go into its own systems and bring the answer back?
- For each system you own: can it publish an event when something changes, can it accept a call from outside, or would it have to be polled on a schedule?
- The new child protection case management system is still being procured. What integration obligations can still be written into that contract, and who holds the pen on them?
- What information could the Courts realistically make available to a system in the executive arm of government, who approves that, and on what timeframe?
A capability the future DFSV solution requires
Master data and information management
Data & Records
Overview
The authoritative record of core entities — people, households, organisations and services — and the management of the information held against them.
Alignment to the Royal Commission recommendations
- R47Procurement of a records management and information-sharing system for the central entry-point service and its partner organisations.
Publicly available starting point to dive deeper and validate
Agencies capture DFSV data inconsistently, including service types, locations and demographics. Inconsistent capture limits reporting, visibility of whole-of-government investment and cross-agency analysis. AlignedRC report, Ch.2, p.103, p.107
Systems supporting this capability across the sector
Initial requirements for the future DFSV information sharing solution 8 · 1 must have
| Requirement | Type | Priority |
|---|
| Maintain shared reference/lookup data (e.g. service types, program areas, geography/service-delivery territory) used consistently across records, registers and analytics. | Functional | To be assessed with stakeholder input |
| Maintain consistent locational reference data usable by the accommodation register, records and analytics alike. | Functional | To be assessed with stakeholder input |
| Maintain consistent demographic reference-data definitions so the same client attributes are captured the same way everywhere. | Functional | To be assessed with stakeholder input |
| Keep this shared reference/structured data distinct from DFSV case-record narrative content (see Records management & lifecycle). | Functional | To be assessed with stakeholder input |
| Let agencies extract data in a consistent format to support the whole-of-government DFSV investment/activity reporting the Royal Commission found currently missing. | Functional | Must haveR3 |
| Apply data-quality rules (mandatory fields, valid value sets) at the point of capture, without relying on downstream cleansing. | NFR | To be assessed with stakeholder input |
| Support retrieval performance for defined risk assessment and information sharing transactions, with service levels established during Phase 2. | NFR | To be assessed with stakeholder input |
| Encrypt DFSV data at rest and in transit consistent with SA Government whole-of-government data-handling requirements. | NFR | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- When someone asks your agency for a consistent statewide count of DFSV activity, what do you have to do to produce it, and where do the definitions differ between regions or teams?
- Which reference lists — service types, program areas, locations, demographics — already exist as a whole-of-government standard we should adopt, and which would have to be built for DFSV?
- How quickly does a risk lookup need to return an answer for a worker on the phone with someone in immediate danger, and how does that differ from what your reporting extracts need?
- Which data-handling rules — classification, encryption, residency — would constrain where DFSV data can be held, and who signs off an exception?
A capability the future DFSV solution requires
Records lifecycle management
Data & Records
Overview
The creation, versioning, retention and disposal of records across their life, under the State Records Act 1997 (SA).
Alignment to the Royal Commission recommendations
- R47Procurement of a records management and information-sharing system for the central entry-point service and its partner organisations.
Publicly available starting point to dive deeper and validate
Victim-survivors are often required to retell their story across services. More than half of surveyed respondents who sought help had contacted four or more services, and almost one in four had contacted seven or more. Homelessness2Home, the current DFSV crisis-recording system, has been identified for replacement. AlignedRC report, Ch.4, p.275, p.298
Systems supporting this capability across the sector
Initial requirements for the future DFSV information sharing solution 16 · 5 must have
| Requirement | Type | Priority |
|---|
| Securely record narrative case notes, risk and needs assessment results, safety plans and their supporting documents for each client, recording the author of each entry. | Functional | Must haveR47 |
| Replace the Serial Offender Database's function of letting a worker check whether a perpetrator is already receiving services from another provider. | Functional | Must haveR47 |
| Present a client's accumulated record to an authorised new service contact so they are not required to retell their story from scratch, and use information already held to pre-populate the common fields of a new assessment, referral or form, with the worker reviewing and confirming the pre-populated content before it is submitted. | Functional | To be assessed with stakeholder input |
| Version and timestamp case notes, assessments and safety plans so a worker can see what was known at a given point in time. | Functional | To be assessed with stakeholder input |
| Link records to the relevant value-stream stage(s) so a case's history is navigable by stage. | Functional | To be assessed with stakeholder input |
| Apply retention, archival and disposal schedules to each record type consistent with State Records Act 1997 (SA) obligations. | NFR | Must haveState Records Act 1997 (SA) |
| Restrict access to case-note content on a role/need-to-know basis, separate from and finer-grained than agency-level access. | NFR | To be assessed with stakeholder input |
| Support migration of existing Homelessness2Home and Serial Offender Database records, with data quality, reconciliation and exception handling requirements defined during Phase 2. | NFR | Must haveR47 |
| Present any system-generated summary, transcription or draft of case-record content to the worker who conducted the interaction, for review, correction and explicit acceptance, before it forms part of the client's record. | Functional | To be assessed with stakeholder input |
| Retain the source material a summary or transcription was derived from, for as long as the derived content is retained, so the derived content can be checked against its source. | Functional | To be assessed with stakeholder input |
| Distinguish system-generated content from worker-authored content within a record, showing which worker accepted the system-generated content and when. | NFR | To be assessed with stakeholder input |
| Attach, retrieve and search source documents against a client's record — including reports, orders, assessment forms, correspondence and images — under the same access controls that apply to case-note content. | Functional | To be assessed with stakeholder input |
| Allow a worker to filter and search a client's accumulated record by date range, keyword, record type and originating agency. | Functional | To be assessed with stakeholder input |
| Record a client's stated preferences about who works with them — for example the gender of a worker, or an Aboriginal-identified worker or service — and carry those preferences with any referral to another service. | Functional | To be assessed with stakeholder input |
| Support a worker capturing a record while away from a desk, including capture that begins before the record is linked to a confirmed client match. | Functional | To be assessed with stakeholder input |
| Carry forward the DFSV crisis-recording function currently performed by Homelessness2Home, which the Royal Commission identified for replacement. | Functional | Must haveR47 |
Questions we would raise in stakeholder workshops and interviews
- For workers using Homelessness2Home on DFSV cases: what do you end up recording somewhere else because the system has nowhere to put it?
- Who uses the check on whether a perpetrator is already engaged with another service, how often, and what do they do with the answer?
- Has a retention and disposal schedule been determined for DFSV case notes, risk assessments and safety plans — and what changes where the record concerns children and young people?
- When a victim-survivor moves to a new service, which part of their record should travel with them by default, and what should they be asked before it moves?
A capability the future DFSV solution requires
Provenance & evidentiary integrity
Data & Records
Overview
The record of where each item of information came from, what status it carries, and whether it can be relied on later.
Alignment to the Royal Commission recommendations
- R47Procurement of a records management and information-sharing system for the central entry-point service and its partner organisations.
Publicly available starting point to dive deeper and validate
Information held about DFSV includes allegations, assessments, findings and court outcomes, and the Royal Commission's treatment of the Serial Offender Database shows the evidentiary standard a replacement capability would have to carry explicitly. Whether current systems distinguish these statuses in a way a later reader can rely on was not established in the public material reviewed. KPMG hypothesis for validationSA Government Submission 351, pp.83–84
Initial requirements for the future DFSV information sharing solution 7 · 3 must have
| Requirement | Type | Priority |
|---|
| Record, for every item of information, its source, its author, when it was created and which agency holds it. | Functional | Must haveR47 |
| Distinguish information recorded as an allegation, an assessment, a finding and a court outcome, and carry that status wherever the item is read. | Functional | Must haveR47 |
| Preserve the original of an item when it is amended, so that what was known at an earlier point can still be established. | Functional | Must haveR47 |
| Show the reader whether an item was entered directly, received from another system, or derived by the system itself. | Functional | To be assessed with stakeholder input |
| Hold information to a standard that would support its use in a coronial inquiry, a review of a death, or a court proceeding. | NFR | To be assessed with stakeholder input |
| Detect and evidence unauthorised alteration of a record. | NFR | To be assessed with stakeholder input |
| Apply the evidentiary requirements of proceedings under the Intervention Orders (Prevention of Abuse) Act 2009 to items relied on in them. | NFR | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- Which information in your system is an allegation, which is an assessment, and which is a court outcome — and can a reader tell them apart today?
- When a record is corrected, what happens to what it said before?
- What has been asked of your records in a coronial inquiry or a court proceeding, and what was hard to produce?
- Where does information arrive from another system, and does the reader know that is where it came from?
A capability the future DFSV solution requires
Accommodation & specialist registers
Data & Records
Overview
The statewide register of accommodation, covering its type, location, capacity and suitability, including accommodation for perpetrators held separately from accommodation for victim-survivors.
Alignment to the Royal Commission recommendations
- R47Procurement of a records management and information-sharing system for the central entry-point service and its partner organisations.
- R80Inclusion of accommodation options for people using violence within the statewide DFSV accommodation register, with clear separation from accommodation for victim-survivors.
- R104Development, implementation and ongoing maintenance of a statewide DFSV accommodation register covering availability, suitability and capacity.
Publicly available starting point to dive deeper and validate
No statewide register today distinguishes and coordinates accommodation for perpetrators separately from victim-survivor accommodation. AlignedRec. 80, Rec. 104
Systems supporting this capability across the sector
Initial requirements for the future DFSV information sharing solution 16 · 4 must have
| Requirement | Type | Priority |
|---|
| Record accommodation types, locations and dates of effect for persons, clients and groups of clients. | Functional | Must haveR104 |
| Characterise accommodation by type, risk factors (client and staff) and geography (linked to service-delivery territory) across program areas. | Functional | To be assessed with stakeholder input |
| Link accommodation records to specific case and plan conditions, orders and restrictions. | Functional | To be assessed with stakeholder input |
| Link specific accommodation types and locations to incident records. | Functional | To be assessed with stakeholder input |
| Record more than one concurrent address or location for a client, with a clear indicator of which is current (e.g. a registered home address while temporarily relocated to crisis or safe accommodation, or currently admitted to hospital following an incident). | Functional | To be assessed with stakeholder input |
| Restrict visibility of a victim-survivor's current safe-accommodation address to an approved need-to-know access group, recognising the safety sensitivity of location data. | NFR | Must haveR104 |
| Link placements to the payment system. | Functional | To be assessed with stakeholder input |
| Flag a client's whereabouts as unknown. | Functional | To be assessed with stakeholder input |
| Apply business rules to support a placement hierarchy (e.g. preferred, emergency and temporary placement ordering). | Functional | To be assessed with stakeholder input |
| Record and manage placement profiles to support client-needs matching. | Functional | To be assessed with stakeholder input |
| Record incidents against placements. | Functional | To be assessed with stakeholder input |
| Report on placement type, location category, capacity and utilisation using fields agreed during Phase 2. | Functional | To be assessed with stakeholder input |
| Report on capacity, at a level that could support the statewide register the Royal Commission calls for at Recommendation 104. | Functional | Must haveR104 |
| Keep accommodation records and options for perpetrators separately identifiable from victim-survivor accommodation, consistent with Recommendation 80. | NFR | Must haveR80 |
| Maintain an auditable record of who accessed or amended accommodation and placement information, given the safety sensitivity of the data. | NFR | To be assessed with stakeholder input |
| Surface known staff-safety risk factors recorded against a location to an authorised worker before they attend it, without disclosing a protected address, or the reason a location is protected, to a worker not permitted to see it. | Functional | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- When you are placing someone after hours, how do you find out what is free — do you ring around a list of numbers, or is there something you can look at?
- How stale can a vacancy figure be before you stop trusting it and ring around anyway, and who should be responsible for keeping it current?
- Accommodation for perpetrators has to stay clearly separate from accommodation for victim-survivors. Should that be separate records, separate access for staff, or both — and who decides who sees each?
- What is the smallest set of people who should be able to see a victim-survivor's current safe address, and how would you know if someone outside that set had looked?
A capability the future DFSV solution requires
Analytics, reporting & insights
Data & Records
Overview
The de-identified, linked view of DFSV activity and outcomes across government, to support oversight by the Government Steward and the Implementation and Impact Monitor.
Alignment to the Royal Commission recommendations
- R3A linked-data DFSV dashboard bringing together data across government to support the Government Steward and the Implementation and Impact Monitor.
- R20A whole-of-government technological solution for information aggregation and sharing for DFSV.
- R47Procurement of a records management and information-sharing system for the central entry-point service and its partner organisations.
Publicly available starting point to dive deeper and validate
BEBOLD draws de-identified data from child protection, health and housing, and not from police or the courts. Separately, no whole-of-government view of DFSV investment and activity is available. AlignedRC report, Ch.2, p.105, p.107
Systems supporting this capability across the sector
Initial requirements for the future DFSV information sharing solution 7 · 4 must have
| Requirement | Type | Priority |
|---|
| Produce a de-identified, linked-data view of DFSV activity and outcomes for the Government Steward and the Implementation and Impact Monitor. | Functional | Must haveR3 |
| Draw linked data from, at minimum, DCP, SA Health, SA Housing Trust, SAPOL and CAA — extending beyond BEBOLD's current DCP/Health/Housing-only coverage. | Functional | Must haveR3 |
| Report on whole-of-government DFSV investment and activity. | Functional | Must haveR3 |
| Integrate dashboard outputs with the records-management/information-sharing system's underlying data. | Functional | Must haveR3 |
| Support governed linkage between aggregate trend views and case-level records only where the user has appropriate authority, and where the transition is logged and auditable. | Functional | To be assessed with stakeholder input |
| Apply de-identification consistent with what a shared cross-government dashboard requires, before data leaves agency systems for this purpose. | NFR | To be assessed with stakeholder input |
| Leave open, for Phase 2 assessment, whether to extend BEBOLD or build a dedicated capability, without pre-determining that choice here. | NFR | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- BEBOLD draws linked de-identified data from child protection, health and housing, but nothing from SAPOL or the Courts. What has stopped those two datasets being added?
- What are the three or four measures the Government Steward and the Implementation and Impact Monitor would look at each quarter to know whether people are safer than they were?
- Which of those measures could be produced from data your agency already collects, and which would require a frontline worker to record something new?
- What de-identification standard has to be met before your agency's data leaves it for a shared dashboard, and who inside your agency signs that off?
A capability the future DFSV solution requires
Data governance, privacy & Aboriginal data sovereignty
Governance & Enabling
Overview
The rules that define data ownership, decision rights for new sharing arrangements, and how Aboriginal data sovereignty is applied in practice.
Alignment to the Royal Commission recommendations
- R25Model principles for Aboriginal-led responses, including that Aboriginal Community Controlled Organisations retain sovereignty over their own data. This recommendation is not listed in Part B, but it is a direct dependency for information sharing design. The Department has confirmed that the relevant recommendation set extends beyond those Part B identifies.
Publicly available starting point to dive deeper and validate
The Commission set out that Aboriginal Community Controlled Organisations should retain sovereignty over their own data. Aboriginal people are overrepresented across the DFSV service system, and are represented in around 40 per cent of Mapped incidents at MAPS, where the Commission noted that no ACCO or specialist Aboriginal worker sits. South Australia also remains the only jurisdiction without a Privacy Act. AlignedWith Courage p.75 (overrepresentation), p.158 (MAPS), p.170; Rec. 25/Fig. 2.4
Systems supporting this capability across the sector
Initial requirements for the future DFSV information sharing solution 9 · 4 must have
| Requirement | Type | Priority |
|---|
| Give Aboriginal Community Controlled Organisations a defined role and corresponding information-sharing access as core, resourced members of integrated response teams, addressing the gap that no ACCO/Aboriginal-specific worker currently sits within MAPS. | Functional | Must haveR25 |
| Allow an Aboriginal Community Controlled Organisation to define access and onward-use conditions for data about its own communities, distinct from general agency access settings. | Functional | Must haveR25 |
| Apply the Children and Young People (Safety) Act 2017's information-sharing mandate to all child-safety-relevant information the solution handles. | Functional | Must haveChildren and Young People (Safety) Act 2017 |
| Extend Aboriginal data sovereignty and governance principles with SNAICC's "Safe and Supported" National Framework wherever DFSV and child-protection data intersect. | Functional | To be assessed with stakeholder input |
| Support review and reconfiguration of information-sharing settings if a future South Australian Privacy Act changes applicable consent, privacy or access obligations. | NFR | Must haveWith Courage, p.170 |
| Make data-governance roles and decision rights (who approves a new sharing arrangement, who owns a given dataset) explicit and configurable, not hard-coded to today's participating agencies. | NFR | To be assessed with stakeholder input |
| Support a documented data-governance framework covering ownership, quality accountability and stewardship across every participating agency and ACCO. | NFR | To be assessed with stakeholder input |
| Treat any system-generated content that informs a decision about a person's safety as an input to a worker's decision, with the accountable worker recorded, and prevent it from being recorded as a decision in its own right. | NFR | To be assessed with stakeholder input |
| Allow Aboriginal Community Controlled Organisations to define, review and withdraw any culturally specific practice guidance the solution presents to workers about Aboriginal people, and record which organisation authored it. | Functional | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- For ACCOs: what would control over your community's data have to look like in practice — approving each release, holding the data yourselves, seeing who has looked at it, or something we have not put on this list?
- Aboriginal people are represented in around 40 per cent of Mapped incidents at the Multi-Agency Protection Service, and no Aboriginal Community Controlled Organisation sits inside it. What access and standing would an ACCO worker need for that to change?
- South Australia has no Privacy Act. If one is legislated while this system is being built, which of today's sharing arrangements would be at risk, and how do we protect them?
- Once the system is live, who decides that a new agency can join or a new information type can be shared — and how long should that decision take?
- Who holds the authority to approve Aboriginal data governance settings — the access conditions themselves, not just who is granted access — and through what forum is that decision made?
A capability the future DFSV solution requires
Interoperability standards
Governance & Enabling
Overview
The standards that let participating systems exchange information without bilateral negotiation for each connection.
Publicly available starting point to dive deeper and validate
No shared interoperability or data standard across agency systems was identified in the public material reviewed. This is an inference from the documented fragmentation and will be tested during Phase 1. KPMG hypothesis for validation
Systems supporting this capability across the sector
Initial requirements for the future DFSV information sharing solution 6 · 0 must have
| Requirement | Type | Priority |
|---|
| Define a common data standard (shared entities, field definitions, code sets) that every connecting agency case-management, health information-exchange and justice system maps to. | Functional | To be assessed with stakeholder input |
| Define a common integration and API standard covering protocols, message formats and authentication pattern, so each new connection follows a repeatable pattern and bespoke build is minimised. | Functional | To be assessed with stakeholder input |
| Publish these standards so a vendor or agency can self-assess integration effort before a connection is built. | Functional | To be assessed with stakeholder input |
| Version standards so an older-integrated system can keep operating while a newer one adopts a later version. | NFR | To be assessed with stakeholder input |
| Validate incoming and outgoing data against the defined standard at the integration boundary, flagging non-conforming data, with silent acceptance ruled out. | NFR | To be assessed with stakeholder input |
| Align with existing SA Government and national interoperability standards already in force, without defining a parallel one. | NFR | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- Which data and integration standards is your agency already obliged to build to, so a DFSV standard aligns with them instead of competing?
- Who would own the DFSV data standard once it exists — publish it, version it, and decide when a change becomes mandatory for everyone connected?
- When a connecting system sends data that does not meet the standard, should it be rejected at the boundary or accepted and flagged for follow-up? Which would your operations team prefer to deal with?
- What would an agency or a vendor need published to estimate the effort of connecting, without booking a discovery workshop first?
A capability the future DFSV solution requires
Security & access control
Governance & Enabling
Overview
Who can see what, under which conditions, and the evidence trail proving it, with access granted only where a defined role, purpose and authority exist.
Systems supporting this capability across the sector
Initial requirements for the future DFSV information sharing solution 12 · 1 must have
| Requirement | Type | Priority |
|---|
| Let a core integrated-response-team member extend case visibility to another relevant worker for a feedback loop, on a role and permission basis, with blanket agency-wide access ruled out. | Functional | Must haveWith Courage, Fig. 2.3(f)(ii) |
| Support role-based access profiles distinct per agency and program, with no single profile applied across the board. | Functional | To be assessed with stakeholder input |
| Allow a worker's access to a case to be time-limited or automatically reviewed (e.g. when a case transitions to exit/transition). | Functional | To be assessed with stakeholder input |
| Log and make auditable every cross-agency information-disclosure decision. | NFR | To be assessed with stakeholder input |
| Apply multi-factor authentication consistent with SA Government's whole-of-government ICT, Digital and Cyber security policies. | NFR | To be assessed with stakeholder input |
| Detect and alert on anomalous access patterns (e.g. a worker viewing an unusually high number of cases outside their normal caseload). | NFR | To be assessed with stakeholder input |
| Support periodic access recertification (a manager confirming continued need) so access does not persist indefinitely once granted. | NFR | To be assessed with stakeholder input |
| Apply the access controls of the source records to any summary, extract or derived content produced from them, so derived content cannot be reached by a worker not permitted to see what it was derived from. | NFR | To be assessed with stakeholder input |
| Support a supervisory access role that can view and act on a case in a worker's absence, with supervisory access logged and attributable in the same way as the worker's own. | Functional | To be assessed with stakeholder input |
| Apply session controls, including inactivity timeout and re-authentication, consistent with SA Government's whole-of-government ICT, Digital and Cyber security policies. | NFR | To be assessed with stakeholder input |
| Require device-level re-authentication for access from a mobile or field device. | NFR | To be assessed with stakeholder input |
| Prevent persistent local retention of client information on a device beyond the period it is needed. | NFR | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- What access model do the whole-of-government ICT, digital and cyber policies already require of you, and what would DFSV need on top of that?
- How does a worker in an NGO or an ACCO get an account and a permission level today, and who removes it when that worker changes employer?
- Should a worker's access to a case end automatically when the case moves to exit or transition, and who should be able to hold it open?
- In an integrated response team, who should be able to extend visibility of a case to another worker for a feedback loop, and what record should that leave behind?
A capability the future DFSV solution requires
Hosting, resilience and continuity
Governance & Enabling
Overview
The hosting, resilience and continuity arrangements the solution depends on, including its availability and recovery obligations.
Systems supporting this capability across the sector
Initial requirements for the future DFSV information sharing solution 6 · 0 must have
| Requirement | Type | Priority |
|---|
| Be deployable on existing SA Government hosting/cloud arrangements where these can meet the solution's requirements, without assuming dedicated infrastructure by default. | Functional | To be assessed with stakeholder input |
| Meet availability and performance service levels appropriate for high-risk, time-critical decisions, with target levels confirmed during Phase 2. | NFR | To be assessed with stakeholder input |
| Scale to handle concurrent use across all participating agencies and ACCOs, including peak periods following a high-profile incident. | NFR | To be assessed with stakeholder input |
| Provide defined disaster-recovery and business-continuity arrangements appropriate to a system supporting active risk and safety decisions. | NFR | To be assessed with stakeholder input |
| Support environment separation (test/staging distinct from production) so integration and standards changes can be verified before affecting live agency connections. | NFR | To be assessed with stakeholder input |
| Support continued read access to a client's record, and capture of new information against it, where a worker has intermittent or no network connectivity, synchronising captured information once connectivity is restored. | NFR | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- Which whole-of-government hosting arrangements could this sit on, and what have other agencies found they had to build around?
- What availability target is defensible for a system a worker relies on while someone is in immediate danger, and what is the fallback when it is unavailable?
- What happens today when a system a frontline team depends on goes down overnight — who finds out, and what do workers do in the meantime?
- What load should be planned for, including the surge in reports and searches that follows a death or a high-profile incident?
A capability the future DFSV solution requires
Audit and assurance
Governance & Enabling
Overview
The durable record of who saw what, when and under what authority, and the assurance activity that relies on it.
Alignment to the Royal Commission recommendations
- R20A whole-of-government technological solution for information aggregation and sharing for DFSV.
- R47Procurement of a records management and information-sharing system for the central entry-point service and its partner organisations.
- R80Inclusion of accommodation options for people using violence within the statewide DFSV accommodation register, with clear separation from accommodation for victim-survivors.
Publicly available starting point to dive deeper and validate
The public material reviewed indicates that cross-agency disclosure largely rests on an individual worker's judgement recorded in a case note, which leaves limited evidence that can be reviewed or defended afterwards. The Royal Commission's findings on deaths and reviews indicate the relevant later question is what was known, by whom and when, which is a higher standard than routine compliance reporting. KPMG hypothesis for validation
Initial requirements for the future DFSV information sharing solution 7 · 4 must have
| Requirement | Type | Priority |
|---|
| Record every access to, and disclosure of, client information with the identity of the user, the time, the purpose and the authority relied on. | Functional | Must haveR20 |
| Make consent decisions auditable independently of the sharing transactions they support. | Functional | Must haveR20 |
| Make access to safety-critical information, including protected addresses, separately auditable. | Functional | Must haveR80 |
| Support an inquiry or review in reconstructing what was known, by whom, and when, for a given person and date. | Functional | Must haveR47 |
| Detect and alert on anomalous access patterns, and support periodic recertification of access. | Functional | To be assessed with stakeholder input |
| Hold audit records for the retention period required under the State Records Act 1997 (SA) and any applicable inquiry, review or legal hold requirements. | NFR | To be assessed with stakeholder input |
| Make audit records tamper-evident, and separable from the operational records they describe. | NFR | To be assessed with stakeholder input |
Questions we would raise in stakeholder workshops and interviews
- If a review asked what your agency knew about a person on a given date, how would you answer that today, and how long would it take?
- Who reviews access to sensitive records now, how often, and what happens when something looks wrong?
- How long should an audit record be kept, relative to the record it describes?
- What would you need to show an inquiry about a disclosure decision, beyond the fact that it happened?
