DMICP evidence gaps
The review now contains direct public evidence about DMICP's lineage, selected interfaces and some inspected workflows. None demonstrates that DMICP has every defect described in the civilian PFD corpus or establishes its DCB0129/DCB0160 status. The sponsor cannot currently confirm the applicable clinical-safety regime or artefacts, so their status is recorded as unknown, not absent or non-conformant (SRC-005). This page separates sourced characteristics and site observations from the Defence evidence required to substantiate, reject or refine a system-level concern.
The project-sponsor concern that wrong-practice registration could make people operationally invisible appears as CLM-007 with low / analytical confidence. It is a discovery hypothesis, not a system finding.
Current public evidence baseline
| Dimension | What the sources support | Boundary retained |
|---|---|---|
| Current use | MOD's July 2026 statistics call DMICP the MOD electronic medical record, use it as a 2025/26 data source and describe it as a live system (SRC-145). | This proves current use, not the current application build, deployment topology or interface catalogue. |
| Product family and lineage | The sponsor confirms that the live DMICP clinical application is EMIS PCS/DPCS (SRC-005). A 2019 MOD procurement notice identifies the then underlying platform as EMIS's legacy DPCS; CGI described its 2015 continuation service and historical case study as EMIS PCS-based (SRC-146, SRC-139, SRC-155). | Current product family is sponsor-supplied operational context and is historically consistent with the dated public evidence. The exact live version, Defence adaptations, packaged components and modification baseline remain unverified. |
| Hosting, access and Defence network | The sponsor clarifies that MCN means MOD Core Network and that DMICP is a centrally hosted service inside Defence/MCN infrastructure, accessed from medical-centre/user MCN/MODNet client terminals or devices—not through a separate server at each medical centre (SRC-005). CGI historically described central secure hosting in Wales/UK facilities and dedicated-portal access; Parliament recorded configurable MODNet-terminal access in 2018 (SRC-139, SRC-137). The FSDC schedule independently uses the styling MoD Core Network and defines MODNet as end-user devices/networked systems for that separate personnel/HR contract (SRC-147). |
The terminology and central-versus-practice-local distinction are resolved as sponsor-supplied current context and are consistent with the dated public material. No located public source independently confirms the complete current topology or maps the exact DMICP service path to MCN; an authoritative current architecture artefact remains open. |
| NHS interfaces and service access | NHS England documents DMICP integration with Spine Patient Demographic Service (PDS); a 2017 MOD answer records pathology-report delivery through an NHS messaging service (SRC-148, SRC-149). The sponsor clarifies that e-RS is accessed separately as an HSCN/Spine web application in a native browser, not integrated with DMICP, and that EPS, GP Connect, NHS App, Summary Care Record and the Scottish, Welsh and Northern Irish national platforms are unavailable to Defence (SRC-005). | PDS is one documented current integration; pathology is dated evidence. Browser access to e-RS is service access, not EPR interoperability. The named unavailability statement is current sponsor-supplied context. Isolated local systems or manual routes must not be presented as general platform availability. |
| Work as done | Recent CQC reports document isolated site-specific manual and hybrid workflows and associated gaps, including Scottish pathology/referral boundaries, overseas referral boundaries and a Welsh FIT-access workaround, alongside age-related DMICP slowness, outages and newer-technology compatibility described as widely affecting DPHC (SRC-150, SRC-151, SRC-156). | These are dated regulator observations with local mitigations, not evidence that national platforms are available to Defence, a representative service inventory, a DCB assessment or causal analysis. |
| Clinical-safety regime | The sponsor is not presently able to confirm whether DMICP uses DCB0129/DCB0160 or a Defence equivalent, or whether a named Clinical Safety Officer, Hazard Log and Clinical Safety Case are maintained (SRC-005). | Status is unknown. This is not evidence that the regime or artefacts are absent, inadequate or non-conformant; direct controlled evidence is required. |
| Transition | MOD says current NHS–DMS record transfer still relies on paperwork; the successor SystmOne rollout is scheduled to begin in 2027 (SRC-152, SRC-153). | “Integrated for the first time” is programme language, not proof that every earlier connection or access route was absent; PDS integration, dated pathology messaging and browser-only e-RS access remain distinct. |
Illustrative home-nation and overseas routes
The open record does not support one generic “NHS interface” proposition. It shows different services, access entitlements and manual controls in different places and years:
| Setting | Dated observation | What it can and cannot support |
|---|---|---|
| England — Tidworth, 2021 | DMICP referrals inbox → NHS e-Referral Service → restricted SharePoint registers; internal referrals used DMICP tasks and acknowledgements (SRC-158). | Demonstrates a hybrid local route and controls at one English site; not its current state or an England-wide design. |
| Scotland — Redford, 2025 | One referrals lead could use SCI Store; letters were downloaded then uploaded/scanned to DMICP. Pathology used paper requests and emailed/printed results with transcription and review-visibility risks (SRC-150). | Direct evidence of limited access and manual boundaries at that site, with mitigations; not NHS Scotland-wide or product-wide prevalence. |
| Wales — Brawdy, 2025 inspection | CQC said the Defence system was not linked with Welsh NHS online services and routine FIT home-test kits had been unavailable; staff created an electronic-form/email route and policy. The report also recorded age-related DMICP slow response, regular outages and limited newer-technology compatibility as widely affecting DPHC (SRC-156). | A close analogue for screening-service access, resilience and legacy constraints, but not cohort-search failure, a DCB assessment, quantified prevalence or a technical root-cause analysis. |
| Northern Ireland — regional rehabilitation, 2023 | The Defence Patient Tracking System did not link with DMICP, so a separate sent-referral folder was maintained; non-attendance was documented in DMICP (SRC-157). | Shows a cross-system referral workflow in one specialist setting, not an inventory of Northern Ireland health-service connectivity. |
| Overseas — Sennelager, 2026 | NHS/German-provider/DMICP connectivity remained on the risk register; the practice used DMICP tasks, fax/email, paper/translation and separate referral registers, with three clinicians holding e-RS smartcards (SRC-151). | Demonstrates host-nation and NHS boundary complexity and local mitigation; not a general deployed-service model. |
These rows are deliberately not scored or compared. They make location and service context part of the hazard boundary and define the minimum fields for a current authoritative inventory: administration, service, interface or manual route, access cohort, message/status semantics, record-incorporation method, failure control, evidence date and owner.
Open evidence-gap register
| Gap ID | Question | Evidence needed | Related requirements | Status |
|---|---|---|---|---|
| GAP-001 | How do identity, physical support location, accountable service, administrative registration and record source relate in current DPHC workflows? | Authoritative data model, registration/posting workflow, exception routes, role ownership, configuration samples and reconciled synthetic traces | REQ-001 | Open |
| GAP-002 | Can each practice enumerate everyone it supports and explain inclusions, exclusions, freshness and missing sources for every safety search? | Query definitions, cohort denominators, exclusion logic, temporary/mobile test cohort, reconciliation reports and accountable follow-up workflow | REQ-002 | Open |
| GAP-003 | Which recent NHS, Defence, allied and host-nation records are retrieved, reconciled or disclosed as unavailable? | Interface catalogue, minimum dataset, source/freshness presentation, known failure modes, access controls and transfer test evidence | REQ-003, REQ-006 | Open |
| GAP-004 | How do abnormal results become owned work, and what happens when a recipient is absent, disconnected or overloaded? | End-to-end event traces, severity rules, queues, acknowledgement/escalation/closure definitions, workload observation and incident review | REQ-004, REQ-009 | Open |
| GAP-005 | Do messages, referrals and recommendations from every supported channel enter clinical triage and the longitudinal record? | Channel inventory, routing/configuration rules, rejection/reassignment handling, audit events, user research and unresolved-task reports | REQ-005 | Open |
| GAP-006 | Are draft, corrected and final transfer records visible and reconciled after evacuation, civilian referral or unit transfer? | Handover architecture, draft/final semantics, interface acknowledgements, verbal reconciliation workflow and representative transfer traces | REQ-006 | Open |
| GAP-007 | How are paper fallback, amendments and exports represented and reconciled across clinical and investigation views? | Downtime procedure, sample controlled amendments, print/export schemas, audit-view comparison, reconciliation ownership and safety assessment | REQ-007, REQ-008 | Open |
| GAP-008 | Which existing safety barriers must survive CORTISONE migration, and how are omissions or changed behaviour governed? | Current/target control inventory, requirement mapping, hazard log, migration and clinical-safety plans, regression suite and residual-risk authority | REQ-010 | Open |
| GAP-009 | What happens under prolonged disconnection, partial endpoint failure, clock skew, retry and staged reconnection? | Offline authority model, queue/version semantics, conflict-resolution design, failure injection and synchronisation test evidence | REQ-011, REQ-012 | Open |
| GAP-010 | Which safety-relevant signals may cross clinical-operational boundaries, for what purpose and under whose review? | Use-case and legal basis, information-governance assessment, minimum signal set, access model, audit evidence and operational user research | REQ-013 | Open |
| GAP-011 | What is the observed scale and consequence of relevant DMICP incidents or near misses? | Defined search strategy, safety reports, help-desk/problem records, clinical audit, denominator and coding method with disclosure controls | All | Open |
| GAP-012 | Do representative users understand status, ownership, missing information and fallback under real workload? | Contextual inquiry, task analysis, usability/accessibility testing across fixed and deployed settings, and documented design responses | All | Open |
| GAP-013 | What is the authoritative current DMICP technical and security boundary? | Current architecture pack showing EMIS PCS/DPCS version and adaptations, central and deployed components, hosting locations, MCN/MODNet path, endpoints, trust boundaries, portal/client access, synchronisation and accountable service owners | All | Partially clarified — sponsor confirms the live EMIS PCS/DPCS product family, that MCN is the MOD Core Network and that DMICP is centrally hosted in Defence/MCN infrastructure with MCN/MODNet client access rather than practice-local servers; the exact version/adaptations, current route, components, trust boundaries and independent architecture evidence remain open |
Minimum claim threshold
A gap can be closed only for the stated system version, configuration, workflow and population. Evidence should identify provenance, collection date, coverage, limitations and accountable reviewer. Anecdote or absence of a reported incident is insufficient to claim that a control is present or effective.
When Defence evidence becomes available, add it to the source and claims registers before changing a REQ- validation status. Sensitive evidence may need a controlled reference and an openly publishable summary rather than inclusion in this public-facing wiki.