CareMatch Intelligence Prototype governance pack
TRANSPARENCY SUMMARY · VERSION 2

What CareMatch Intelligence does, how matching is proposed to work, and what still requires validation

This page is designed for Local Authority, provider, safeguarding, information-governance and procurement review.

01 · PURPOSE AND BOUNDARY

Decision support, not an automated placement decision

The proposed service

Structures placement requirements, identifies incompatible options, ranks potentially suitable homes and explains the factors that require professional review.

What it is not

It is not a statutory assessment, safeguarding decision, placement authorisation, guarantee of suitability or replacement for consultation with the child and relevant professionals.

Human responsibility

Qualified professionals verify source information, investigate concerns, consider the child’s views, apply law and policy, and record the final decision and rationale.

02 · PROPOSED MATCHING METHOD

A transparent five-stage professional workflow

1Completeness checkIdentify missing, stale or contradictory information before comparison.
2Safety exclusionsFlag options that cannot meet an essential, current and evidenced requirement.
3Indicative comparisonCompare remaining homes against agreed care, household, child-centred and practical factors.
4Explanation and uncertaintyShow strengths, concerns, missing evidence and the reason for every material result.
5Professional reviewA named professional accepts, rejects or overrides the result and records why.
Factor groupInformation consideredProposed treatment
Safety constraintsRegistration scope, admission criteria, critical risks, staffing minimums and environmental requirements.Proposed hard exclusions where a home cannot safely meet an essential requirement.
Care capabilitySupport model, staff qualifications, clinical input, waking-night and enhanced staffing capability.Proposed high weighting, subject to professional validation.
Existing-child compatibilityPseudonymised context about current household risks, triggers, vulnerabilities and safeguards.Professional review required; never an automatic acceptance decision.
Child-centred fitChild’s wishes, identity, culture, education, family links, interests and what helps the child feel safe.Used to explain fit and trade-offs, not as a simplistic demographic ranking.
Practical suitabilityLocation, accessibility, transport, timing, vacancy status and indicative fee.Cost and convenience must not override safety or essential needs.
What the displayed score means

The prototype’s 0–100 figures illustrate a possible comparison format only. They are not probabilities of placement success, independently validated predictions or measured safety outcomes. Factor definitions, weightings, exclusions and score bands must be co-designed and tested with participating authorities, providers and people with relevant lived experience before operational use.

03 · CURRENT DEMO DATA FLOW

Separate identity, account administration and demonstration content

Adult professionalGoogle or email sign-in
→
Supabase AuthIdentity and session
→
Role checkProvider, authority or admin
→
Demo servicesAccount records and restricted documents
Structured account data

Organisation requests, role, approval status, subscription state and account audit events are stored in the site’s protected database.

Verification documents

Optional evidence is stored in restricted object storage and can be opened only through an administrator-authorised route. Reviews are logged.

Care and matching data model

The database now separates referrals, homes, existing-child compatibility, rule versions, score runs, decisions, audit events and outcomes by owning organisation. The public demonstration still uses synthetic examples and does not save live case data.

Future live pilot

The participating authority’s controller role, CareMatch’s processor role, hosting locations, subprocessors, retention, deletion and incident responsibilities must be agreed in writing before operational use.

04 · CONTROLS AND LIMITATIONS

Implemented controls and work still required

Implemented in the demo

  • Google or password-free email authentication through Supabase.
  • Administrator approval before workspace access.
  • Separate Provider and Local Authority workspaces.
  • Configurable, version-ready weights and visible hard exclusions.
  • Pseudonymised existing-child compatibility explanations.
  • Commissioner override with mandatory reason.
  • Decision-audit and outcome-monitoring demonstrations.
  • Restricted verification-document access with review logging.
  • Public prohibition on live identifiable child data.

Required before operational use

  • Joint DPIA and documented lawful basis.
  • Data-processing and information-sharing agreements.
  • Multi-factor authentication or authority single sign-on.
  • Independent penetration testing and vulnerability management.
  • Cyber Essentials or an agreed equivalent security assurance.
  • Operational API authorisation tests for every organisation boundary.
  • Business continuity, recovery, support and incident-response procedures.
  • Accessibility testing against WCAG 2.2 AA.

Initial risk and mitigation register

Unfair exclusion or biasTest outcomes and false exclusions across relevant groups; review proxy variables and allow professional challenge.Open for pilot validation
Out-of-date provider informationTimestamp evidence and vacancies, require scheduled confirmation and show users when information needs review.Open for pilot validation
Over-reliance on a scorePresent reasons, limitations and missing information; require named professional review and recorded rationale.Open for pilot validation
Excessive or identifiable dataUse data minimisation, pseudonymised references, role separation and explicit demo restrictions.Open for pilot validation
Security or access failureUse authenticated access, server-side authorisation, restricted document delivery, audit events and an incident process.Open for pilot validation
05 · DPIA READINESS

A DPIA cannot be completed by the supplier alone

CareMatch can prepare the technical information, but each participating authority must define its purpose, lawful basis, users, source systems, data fields, retention and decision process. The DPIA should be completed before any live identifiable or special-category information is used.

1Describe the processing and parties
2Confirm necessity and proportionality
3Map personal and special-category data
4Assess children’s rights and expectations
5Test bias, accuracy and false exclusions
6Define access, retention and deletion
7Assess suppliers and international transfers
8Record risks, mitigations and approvals
ICO DPIA guidance
06 · CONTROLLED PILOT

Validation before claims

Search efficiency

Time to identify options, repeated searches and staff time compared with the agreed baseline.

Recommendation quality

Viable options found, false exclusions, professional overrides and reasons for disagreement.

Safety and fairness

Safeguarding concerns, missing information, results across relevant groups and potential proxy bias.

Provider experience

Relevant enquiries, response burden, decline reasons, profile freshness and confidence in explanations.

Placement pathway

Progression to consultation and placement, without claiming causation from the tool alone.

Governance acceptance

User confidence, audit completeness, accessibility findings, information-governance actions and residual risks.

No cost saving, safety improvement or outcome claim will be presented as proven until the agreed pilot method produces evidence that supports it.