Requirements - Solution Design & Methods - SD07 - Equal Treatment

We should treat internal (NHS England) and external consumers equally.

Requirement description

This requirement is focused on interoperability, fairness of access, and API/product design consistency. Internal NHS England consumers should not receive preferential treatment compared to external consumers unless there is a documented and justified reason.

In simple terms:
Design services, APIs and capabilities so that internal and external consumers can access and use them through the same standards, interfaces, processes and governance arrangements wherever practical.

Scoring rubric – Equal Treatment of Consumers

Score What it looks like Typical evidence Key gaps / risks
0 No evidence of equal treatment. Internal consumers are provided with capabilities or access methods that external consumers cannot reasonably access. No documented API strategy, no consumer analysis, no published interfaces or standards. Significant interoperability risk, duplicated integrations, vendor lock-in, inconsistent consumer experience.
1 Limited awareness of the requirement. Some discussion exists but solutions are designed primarily around internal users. Informal design discussions, unsupported assumptions, isolated examples of reuse. High-risk gaps. Internal and external access models differ without documented rationale.
2 Some interfaces and standards are shared across consumer groups but significant exceptions exist. API specifications, interface documentation, partial consumer analysis, incomplete standards adoption. Notable inconsistencies. Different onboarding approaches, authentication models, documentation quality or support arrangements.
3 Much of the solution follows a common consumer model. Most interfaces are available on a consistent basis to internal and external consumers. Documented API strategy, consumer personas, architecture diagrams, onboarding processes, design rationale for known exceptions. Some notable gaps remain. Certain services, data sets or capabilities continue to favour one consumer group and require mitigation.
4 Most consumer interactions follow common patterns, standards and governance. Any differences are documented, reviewed and justified. Maintained API catalogue, common onboarding process, documented standards, governance approvals, stakeholder feedback showing consistent treatment. Minor gaps only. Remaining exceptions present low risk and have agreed remediation or justification.
5 Comprehensive and exemplar implementation. The solution is demonstrably designed consumer-first, with internal and external consumers using the same patterns, interfaces and lifecycle processes wherever possible. Published standards, reusable API patterns, consumer engagement evidence, service metrics, architecture reviews, governance records, continuous improvement activities, documented exception management. Minimal or no significant gaps identified.

What assessors should look for

  1. Consistent access model – Internal and external consumers use the same or equivalent interfaces, APIs and integration patterns where practical.
  2. Consumer-centred design – Consumer needs are considered regardless of organisational boundary.
  3. Standards and governance – Common onboarding, documentation, security, support and lifecycle processes exist.
  4. Justified exceptions – Any differences are documented with clear rationale and risk assessment.
  5. Evidence of active use – The approach is being applied in delivery decisions and is not simply documented.

What separates a 3 from a 4 or 5

A score of 3 normally demonstrates that the principle is understood and mostly implemented, but exceptions remain and are not always governed consistently.

A score of 4 requires evidence that exceptions are consciously managed, reviewed and justified through governance.

A score of 5 requires demonstrable exemplar practice, including common standards, measurable adoption, consumer engagement, maintained documentation and evidence that equal treatment of consumers influences architecture and delivery decisions.

Updated: 04 September 2026 (SAF Version 1.1)