Search loading...


Explore and Make use of Nationally Defined Messaging APIs


Design decisions

Overview of the design decisions made in relation to the Access Record capability

Back to Top


Scope of HTML view

What is the scope of what views we’re aiming to deliver?

  • DECISION initially a set of views covering the majority of the primary care record have been included based on workshops with principal suppliers to agree how the data can be most sensible sectioned
    • some desirable headings such as Procedures, Diagnosis, Symptoms have been amalgamated into the ‘Clinical Items’ heading because the underlying data structure of the GP systems cannot reliably extract these coded elements
  • DECISION the scope of the views will be reviewed and added to as future versions of the API are produced
  • DECISION provider MUST return minimal patient resource(s)
  • DECISION remove the structured clinical data from the bundle until Access Record Structured delivery

View non-retrieval

Potential grounds for not returning an HTML view?

  • DECISION technical constraints
    • generation from structured FHIR® resources
    • can’t safely retrieve from GP system
  • DECISION information governance
    • data sharing agreement not in place
    • patient dissent to record sharing
  • DECISION PDS status
    • corrupt record, etc.


Record ‘In-transit’ as a result of GP transfer

If the patient’s record is indicated in the provider system as not fully-integrated following a GP to GP transfer, then only data which has been entered to the current GP record should be returned, and NOT the contents of the previous GP record. Where data is excluded according to this, a warning should be included in the section banner indicating that some data has been excluded as a result of the transfer.

  • SELECTED provider to supply a warning that the record could be incomplete
  • other

DECISION The provider MUST display a banner message when a record is in-transit.

Record locking

Behaviour when Access Record query/request received while patient record being updated in provider system:

  • SELECTED return the requested record section, only including data that has been successfully committed to the database and is available to all users
  • return error message in lieu of record section.
  • return snapshot of record as-is at the time of request including any non-committed changes

DECISION The provider MUST return the most recently committed record for the patient.

Requesting a section

How can the HTML sections be requested?

  • [0..N] return a variety of views
  • [0..1] return everything vs. Return summary
  • SELECTED [1] only return a single section at a time

DECISION The ability to return multiple or all HTML care record sections in one request will not be provided.

HTML section ordering

How should the HTML sections be ordered?

DECISION Consumer systems MUST provide access to record sections in the order specified, which is captured in the ordering of the HTML composition sections with-in the FHIR gpconnect-carerecord-composition-1 data model.

User Interface

Platform support

Which platforms will be supported?

  • SELECTED desktop
  • SELECTED web
  • mobile

DECISION Mobile platforms will not be supported.

Render guidance

What UI guidance should be followed?

  • SELECTED reuse Common User Interface (CUI) Guidance
  • define our own

DECISION The CUI guidance supported by the NHS will be followed.

Patient tracing and verification

GP organisation location

How will the patient’s usual GP practice be identified?

  • SELECTED NHS Number MUST BE be used to resolve the ODS code for the patient’s usual GP
  • other mechanism

DECISION The patient’s NHS Number MUST BE used to identify their associated ODS code.

Patient trace handling

Is the consumer or provider responsible for running a trace?

  • SELECTED ideally the consumer and provider to have traced in both
  • consumer only
  • provider only

DECISION Consumers MUST perform a trace.

Timeliness of trace for consumers

How often should the trace be run by consumers?

  • immediately prior to all API calls
  • once per user session
  • once per multiple user sessions (meaning, monthly etc.)
  • SELECTED within the last 24 hours

DECISION The trace MUST have be performed within the last 24 hours.

Patient identity cross check

Although a traced national identifier is initially mandated for use with the GP Connect APIs, there are edge case scenarios where the patient record being retrieved from the GP system may have different patient details than the source system. The basic patient resource has been bundled into the response so that a cross check may be performed in the consuming system.

  • SELECTED consumer system to cross-check
  • provider system to cross-check
  • Spine Security Proxy (SSP) to cross-check

DECISION Consumer MUST cross-check with demographics returned from the provider system.

Minimum patient demographics

What are the minimum patient demographics that must be returned?

  • SELECTED patient banner as defined in the CUI guidance
  • community driven (that is, just add Gender)
  • absolute minimum (Name, DOB and NHS Number)

DECISION As per GPSoC requirements make minimal registration details mandatory (meaning, First Name, Surname, Gender, DOB) in the FHIR profile.

How are patient consent preferences dealt with?

  • SELECTED patient consent enforced by the provider system and cannot be overridden
  • patient consent enforced by the provider but can be overridden by consumer

DECISION Patient consent enforced by the provider system MUST be adhered to when returning a patient record.

Patient data exclusions

What patient data exclusions are associated with Access Record HTML?

These can be determined by two potential sets of exclusion settings:

  • manual exclusion (based on explicit patient preference)
    • SELECTED provider system-based patient preferences
    • Summary Care Record (SCR) standard patient preferences (in addition) 1
  • automatic exclusion (based on implied patient preference) 2

1 Providers are not initially expected to enforce SCR patient preferences in relation to returning API data. They MUST only respect their own principal patient preferences.

2 Automatic or inferred exclusions are not supported as this would be technically impractical (it’s not possible to filter out all free-text and other fields which could potentially contain data which should ideally be excluded).

DECISION Provider system MUST enforce exclusion rules, either for the complete patient record, or sections/data-items.

‘Confidential’ (GP practice-designated) data exclusions

How are ‘confidential’ data items dealt with?

  • DECISION provider system MUST enforce exclusion rules, either for the complete patient record, or sections/data-items
  • DECISION items designated by the practice as confidential MUST NOT be provided, and processed in the same way as patient data exclusions

Sensitive data exclusion set

How are sensitive data items dealt with?

DECISION Provider API processing MUST support the application of an exclusion set, which MUST be configurable, including containing null values. The current Royal College of General Practitioners (RCGP) sensitive exclusion set MUST be applied, for the complete patient record, or sections/data-items, but is likely to amended pending future guidance and review (to be approved by the Joint GP IT Committee (JGPIT)).
GP summary exclusion code Lists

Information: You will need to register for an account on TRUD (the NHS Terminology Reference Data Update Distribution Service) in order to view the above link.

Data sharing agreements

What data sharing agreements need to be in place?

  • DECISION data-sharing agreement must be in place between the consuming organisation and the providing organisation
  • DECISION the Spine Security Proxy validates this requirement

Therefore, provider systems MUST NOT apply or change locally-configured data-sharing validation.

Exclusion warnings

How are exclusion warnings identified within Access Record HTML?

  • no indication that data has been excluded
  • SELECTED warning indication per section that data has been excluded (within the time frame)
  • SELECTED inline with some information related to the data item
    • that is, encounter date/time but not the place or encounter details

DECISION Warning needed that data supplied for a patient may be incomplete/withheld due to patient preferences, GP practice designation of ‘Confidential’ or as a result of the application of the sensitive exclusion set - to be displayed both within the section banner as well as at line item level.

Date handling

Summary time frames

Date range handling in the summary per section:

  • SELECTED no date range due to clinical safety
  • date range to match requirements identified on each HTML view page
    • Active problems and issues
    • Current medications issues
    • Last 3 encounters
    • etc.
  • date range to match SCR time-frames for all subsections

DECISION No date ranges are applied to the summary section.

Section time frames

Date range handling in the HTML view per section:

  • no date range, return all data always for all sections
  • fixed date ranges for sections
  • SELECTED date ranges to be applied as indicated in the relevant section implementation guidance (for example, always return all allergies) with clinical sign off

DECISION Date ranges are applied, where permitted, throughout Access Record HTML, please see each HTML view page for details.

All content is available under the Open Government Licence v3.0, except where otherwise stated