GP Records and Patient Services
NHS App GP-record and GP-linked services should be mapped to GP Connect Patient Facing APIs where public NHS evidence supports that route. NHS App roadmap material references GP Connect patient-facing API adoption for health-record and related improvements. GP Connect PFS pages define patient-facing access to GP record, repeat-prescription, and user-permission functions.
Interface Mechanism 1 (IM1) is a separate GP supplier interface route. IM1 standards include patient API functions for viewing medical records and communicating with the GP practice where specified by the GP practice, plus supplier-specific pairing and assurance requirements. Record it as a possible supporting interface, not as proof of NHS App feature parity.
For CORTISONE implementation analysis, keep GP Connect Patient Facing APIs and Interface Mechanism 1 as candidate patient-facing data routes only after proving the Programme Cortisone provider role, supplier route, onboarding state, and practice/capability enablement. NHS App Adoption and Implementation records this as the later CORTISONE patient-data phase.
Feature Dependencies
| Feature | Likely dependency | DPHC question |
|---|---|---|
| View GP health record | GP Connect Patient Facing Access Record | Is the Defence Primary Healthcare (DPHC) GP record exposed through a supported GP system/API path? |
| View GP record through supplier patient route | Interface Mechanism 1 Patient API | Does the DPHC GP supplier support and pair the relevant patient-facing route? |
| Request repeat prescriptions | GP Connect Patient Facing Prescriptions plus local prescribing workflow | Does the DPHC system support this API and prescription process? |
| Permissions and user access | GP Connect Patient Facing User Permissions | Are DPHC user permissions represented in the same way as ordinary GP practices? |
GP-Filed Document and Result Gates
GP health-record evidence is not one evidence category. Documents filed into a GP record and results visible through a GP record have different source, filing, release, and safety controls. Use these gates before treating either route as available for DPHC patients.
| Route | Evidence gate | DPHC implementation question | Boundary |
|---|---|---|---|
| GP-filed document view | Prove the document exists in the GP record, has a document type and filing state, is exposed through NHS App GP health-record access, and is not only held in a provider Patient Engagement Portal (PEP) or hospital system. | Does the DPHC GP clinical system receive and expose GP-filed documents through a supported GP Connect PFS or IM1 patient-facing route? | GP-filed document evidence does not prove provider-held document access, PEP results-release, or test-result availability. |
| GP-filed result view | Prove the result exists in the GP record, has a result source, has completed any clinical review / release process, and is exposed through NHS App GP health-record access. | Does the DPHC GP clinical system receive and expose GP-filed results through a supported route, with DPHC release settings and age/proxy controls? | GP-filed result evidence does not prove provider PEP results-release, provider documents, or CORTISONE-held data publication. |
| DPHC GP-system equivalence | Prove Personal Demographics Service (PDS) registered-GP state, Organisation Data Service (ODS) organisation identity, supplier route, practice capability, release settings, and patient cohort behaviour. | Is the DPHC Firmbase or DPHC(O) registration context treated as an NHS App-capable GP-record source for this route? | Ordinary NHS GP-record evidence is a baseline only; it is not DPHC feature availability. |
Boundary
API capability does not equal local availability. For DPHC, the missing link is the exact practice, ODS, GP system, supplier-interface route, supplier assurance, practice enablement, and MOD operating model.