Choosing a CDS: laboratory requirements, architecture and evidence

A CDS is often selected by looking at supported instruments and report appearance. Problems emerge later: an interrupted sequence behaves unexpectedly, a reviewer cannot see processing history, or a second site depends on an unassessed connection. Selection must examine the complete path from signal to decision.

1. Describe the work the CDS must support

Define instruments, models, modules, methods, techniques, users, sites and expected workload. Distinguish installed instruments from future extensions and identify which extensions are confirmed. Record who acquires, processes, reviews and approves, which results support GMP decisions and which activities remain in other systems.

Claimed support for an instrument family does not demonstrate support for the actual combination of model, module, version and function. Request evidence for the proposed configuration: instrument control, acquisition of required channels, sequence handling and error behaviour. Avoid universal capacity thresholds; define a representative laboratory workload and the criterion for assessing it.

Use the LIMS, ELN, CDS and SDMS map to define platform boundaries. The CDS must not implicitly become responsible for the sample lifecycle or archive when those functions belong elsewhere.

2. Separate acquisition, processing and review

Map objects and responsibilities through the flow: analytical request, sequence, injection, original signal, processing method, result, review and approval. Check which modules and licences each step requires. A workstation that displays a report may not support review of the dataset and its audit trails.

Controls must identify users and method versions, retain relevant processing histories and explain why a result changed. Examine role separation, permissions, the meaning of approval and its link to the approved record. A “Part 11 compliant” label cannot replace assessment of laboratory use, configuration and procedures.

Ask to see a complete event: authorised change, reason, new version, comparison with the previous version and subsequent review. An audit trail button is insufficient if the reviewer cannot connect the events to the result under examination.

3. Compare architectures and dependencies

Describe where instrument control, acquisition, storage, processing and review occur. Local, centralised or distributed architectures may suit different contexts; none is automatically compliant or preferable. Identify servers, workstations, networks, identity services, shared services and LIMS or SDMS connections.

For each dependency, assess what happens when it becomes unavailable. Does acquisition continue or stop? Where are the data retained? How is the interruption signalled, and how is the return of service reconciled? Demonstrate the answers using the proposed configuration rather than assuming that every CDS has independent local capture.

Continuity also involves people: who intervenes, who assesses analytical impact and who authorises return to use. Design failure tests in isolated, authorised environments. A sales demonstration does not justify interrupting production systems.

4. Use a requirement–risk–evidence matrix

Compare proposals with the same scenarios and synthetic datasets. Agree initial conditions, expected results and acceptance criteria in advance. Record version, configuration, outcome and demonstration limitations. Distinguish an existing feature, necessary configuration, proposed customisation and a future promise.

The matrix is an original working example, not a validated specification. An essential requirement without evidence remains open: a good average score cannot compensate for lost original data. The laboratory must justify selection weights and criteria; there is no universal ranking.

5. Simulated case and lifecycle decision

Two QC sites compare a solution with local workstations and one with centralised services. Both demonstrate ordinary acquisition and reporting. The first requires consistent governance of several configurations; the second introduces a network dependency between sites. Neither represents an absolute advantage or disadvantage: tests and responsibilities change.

The QC–QA–IT team adds an interrupted sequence, review from the other site and historical dataset retrieval. If the centralised proposal cannot demonstrate behaviour during connection loss, that point remains open. If the local proposal cannot demonstrate controlled method distribution, that point also remains open. The case names no winner and invents no costs: evidence and non-negotiable requirements drive the choice.

Before commitment, examine validation feasibility, available documentation, training, support, updates, future compatibility and export at contract exit. Clarify who will retain native formats, relationships and reading dependencies: the presence of files does not establish usable retrieval.

A demonstration supports selection; it does not replace validation of the installed system for its intended use. Hand over approved requirements, assessed evidence, residual risks and conditions to close before release. Keep later changes to configuration and scope traceable.

6. References and limitations

Sources checked on 1 October 2026; article prepared on 2 October. Context: a GMP laboratory for human medicinal products. Adapt the design criteria to the process; they do not mandate a particular architecture.

• European Commission — Annex 11, January 2011 revision, principle and §§3–4, 7, 9–12, 16–17: suppliers, intended use, controls and lifecycle. In operation from 30 June 2011; the 2025 revision is a consultation proposal, not an adopted requirement.
• FDA — Data Integrity and Compliance With Drug CGMP, final December 2018, Q1 and Q3: data context and intended-use validation. Nonbinding US guidance, to be read alongside applicable rules.