Skip to content

Defence and DMICP evidence baseline

Evidence boundary: This dossier explains the evidence and reasoning behind an Analysis article. It does not establish that DMICP caused harm, contains the civilian defects described, is unsafe, or fails DCB0129/DCB0160. Evidence cut-off: 15 July 2026.

This baseline separates public evidence, historical material, author-supplied operational context, analytical hypotheses and unresolved questions. It supports the manuscript; it is not a current architecture document, interface catalogue or clinical-safety case.

Publicly evidenced baseline

Proposition What the public evidence supports What it does not support
Current use MOD statistics call DMICP the MOD electronic medical record and use it as a 2025/26 data source (SRC-145). The exact current version, configuration, topology or control effectiveness
Platform lineage A 2019 MOD notice identifies the then underlying platform as EMIS DPCS; historical CGI material describes an EMIS PCS basis (SRC-146, SRC-139, SRC-155). That every historical component or adaptation remains live in 2026
Historical hosting and access Public historical sources describe central secure hosting, fixed/deployed use and MODNet-terminal access (SRC-139, SRC-137, SRC-155). The complete current service path or security architecture
Network terminology A separate MOD contract defines MCN as the MoD Core Network and describes MODNet end-user access (SRC-147). A current DMICP-to-MCN route; the source is terminology evidence, not a DMICP contract
Documented connectivity NHS England documents a DMICP–Spine Patient Demographic Service connection; MOD documented pathology messaging in 2017 (SRC-148, SRC-149). A complete or currently assured integration and access catalogue
Work as done CQC records date- and site-specific examples involving searches, coding, referral tracking, paper/email/scanning, separate registers, restricted access, outages and local mitigations (SRC-141, SRC-150, SRC-151, SRC-156, SRC-157, SRC-158). National prevalence, a representative facility comparison, a product-wide defect or a software root cause
Programme transition Parliament, MOD and procurement records document CORTISONE intent, a successor award, assurance activity and SystmOne rollout planned from 2027 (SRC-138, SRC-143, SRC-144, SRC-152, SRC-153, SRC-154). Delivered configuration, successful integration, migration safety or clinical-safety acceptance

Author-supplied operational context

The project owner supplies current operational context concerning the live EMIS PCS/DPCS product family, a centrally hosted Defence service accessed through MCN/MODNet clients, and named national-service access boundaries (SRC-005). This is retained to define the evidence that should be sought, not as independent proof.

The journal manuscript therefore uses only the narrower propositions supported by public sources. The sibling-project audit registered as SRC-142 is a provenance and routing control, not an evidential authority; raw sibling paths and working material are not published in this dossier.

Analytical hypotheses requiring direct testing

Hypothesis Why it matters Controlled route
Registration, physical support location, current care responsibility and record source can diverge. A patient may have a correct individual record yet be absent from a practice safety search or recall denominator. REQ-001, REQ-002; AST-001, AST-002
A technically available external record may not enter the receiving workflow or acquire an owner. Availability without visibility, acknowledgement and closure can still permit harm. REQ-003, REQ-006; AST-003, AST-006
Coexistence, migration and retirement can remove or change established barriers. Displays, alerts, task behaviour, data transformations and manual fallbacks may change before the old service is retired. REQ-010, REQ-012; AST-010, AST-012

These are analytical inferences, not findings that DMICP exhibits the mechanism.

Unknown—not absent or non-conformant

The following remain unresolved in the reviewed evidence:

  • exact current EMIS PCS/DPCS version, adaptations and component baseline;
  • authoritative current hosting, MCN/MODNet route and security/trust boundaries;
  • complete current interface, browser-access and manual-workflow catalogue;
  • adopted DCB0129/DCB0160 or Defence-equivalent clinical-safety regime and responsibility allocation;
  • named Clinical Safety Officer arrangements and controlled Hazard Log, Clinical Safety Plan or Clinical Safety Case Reports;
  • current incident frequency, control performance and residual-risk acceptance; and
  • population reconciliation behaviour under posting, attachment, embarkation, temporary care and incorrect registration.

The controlled request for this evidence is VAL-019. Until direct evidence is reviewed, these matters must be described as unknown, never as absent, unassured, non-compliant or unsafe.

Minimum evidence needed before a stronger conclusion

  1. A controlled current architecture, configuration and interface baseline.
  2. Named manufacturer, adaptor, integrator, infrastructure and deploying-organisation responsibilities.
  3. Applicable clinical-safety plans, hazard records, safety-case reports and residual-risk decisions.
  4. Synthetic end-to-end traces covering mobility, cross-boundary care, absence, workload and degraded operation.
  5. Operational monitoring for unresolved tasks, missing cohorts, failed transfers, downtime and workarounds.
  6. A transition safety case covering coexistence, data transformation, rollback, decommissioning and preservation of existing barriers.

The wider controlled translation is available in the Defence application and clinical and patient-safety thematic analysis.