# Manufacturer and deployment responsibilities # Manufacturer and deployment safety responsibilities The review needs two accountable safety perspectives. The manufacturer addresses the software and the conditions for its safe use. The deploying organisation addresses the actual care environment, users, configuration, interfaces and continuing operation. A shared evidence library can support both, but one organisation's assurance does not automatically answer the other's questions. The NHS publication pages currently identify DCB0129 Amd 24/2018 and DCB0160 Amd 25/2018. Their specifications are versions 4.2 and 3.2 respectively. DCB0129 covers development and maintenance; DCB0160 covers deployment, use, maintenance and decommissioning. The published review is not itself a replacement. [DCB0129](https://digital.nhs.uk/data-and-information/information-standards/governance/latest-activity/standards-and-collections/dcb0129-clinical-risk-management-its-application-in-the-manufacture-of-health-it-systems/), [DCB0160](https://digital.nhs.uk/data-and-information/information-standards/governance/latest-activity/standards-and-collections/dcb0160-clinical-risk-management-its-application-in-the-deployment-and-use-of-health-it-systems/). ## Establish the applicable route Record the jurisdiction, funding and commissioning route, intended function, contract, product release and deployment. An England NHS GP review must not silently become a finding about every UK or Defence deployment. A contract may impose a requirement independently of statutory scope. A recommendation to follow an equivalent safety process must remain labelled as a recommendation. The 2025 commencement regulations preserve the former statutory framework for information standards already in effect before 7 July 2025. Therefore the new powers do not, by themselves, establish a widened duty for every use of the 2018 DCB releases. Determine actual applicability and any contractual obligations separately; the saving is not a general exemption from clinical safety, professional or other duties. [SI 2025/807, regulation 3](https://www.legislation.gov.uk/uksi/2025/807/pdfs/uksi_20250807_en.pdf). ## Assemble two evidence packets For the manufacturer packet, identify the exact build and modules, intended use, limitations, hazard analysis, release evidence and safe-use conditions. Ask which controls are inside the supplied software and which are allocated to a receiving organisation. An interface gateway, optional module or local adaptation may introduce a different evidence boundary from the product named on the contract. For the deployment packet, record the receiving organisation, workflows, patient groups, local configurations, dependencies and operational ownership. Trace every transferred action to a local owner and the evidence that the action is usable in that setting. A warning in a supplier document does not demonstrate that a practice has configured, understood or acted on it. Use a transfer record with the supplier control identifier, cause addressed, assumption, recipient, acceptance state, implementation evidence, verification evidence and unresolved dependency. Preserve the original identifiers. If a supplier says “the customer must reconcile failed messages”, ask which worklist exposes failures, who monitors it, what response is expected and how that response was exercised. ## Separate documents, decisions and evidence The safety case is the organised argument and evidence; a safety case report presents that position at a defined lifecycle point. The hazard log is one part of that evidence. A log can reference a test without containing it, and a report can name an assumption that has not been met locally. Keep these relationships visible rather than treating the number of documents as assurance strength. DCB0160 §2.2.2 places deployment authorisation and residual-risk acceptance with top management. Both specifications require CSO approval of each hazard-log version. These are different decisions. A review assistant can identify missing records or conflicting evidence, but cannot supply either approval. [DCB0160 specification](https://digital.nhs.uk/binaries/content/assets/website-assets/data-and-information/information-standards/standards-and-collections/dcb0160/0160252018spec.pdf). ## Use the risk process precisely Keep the organisation's actual risk definitions and matrix. Both standards' §5.1.2 excludes §§6.1–6.3 where initial risk is acceptable. This does not justify accepting an unexplained rating or omitting the wider evaluation and acceptance record. Multidisciplinary analysis is a SHOULD requirement; do not convert every statement inside a grouped mandatory control into MUST. [DCB0129 specification](https://digital.nhs.uk/binaries/content/assets/website-assets/data-and-information/information-standards/standards-and-collections/dcb0129-clinical-risk-management-its-application-in-the-manufacture-of-health-it-systems/0129242018spec.pdf). For each concern, distinguish the observation, the interpretation and the decision required. “No local acceptance record was supplied” is an evidence finding. “An accountable owner confirms deployment occurred without the required authorisation” may support a process nonconformance once the applicable obligation and facts are established. Neither statement proves a software defect. No product-specific workbook or safety case has been assessed in preparing this knowledge base. The records described here are proposed review inputs, not findings about a supplier or deployment.