GP Organisation Location

• SELECTED NHS Number must be used to resolve the ODS Code for the patient’s usual GP.
• Other mechanism.

Scope of HTML View

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

• 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.
• The scope of the views will be reviewed and added to as future version of the API are produced.

¹ Provider SHALL return minimal Patient resource(s).

DECISION Remove the structured clinical data from the bundle.

HTML Sections

Delivery Mechanism

• SELECTED Desktop
• Web
• Mobile

Render Guidance

• SELECTED Reuse Common User Interface (CUI) Guidance
• Roll our own.

Patient Trace Handling

• SELECTED Consumer and Provider to have traced in both
• Consumer only.
• Provider only.

Timeliness of Trace

• Immediately prior to all API calls.
• Once per user session.
• SELECTED Once per multiple user sessions (i.e. monthly¹ etc.)

¹ period of renewal/rechecking to be determined by commissioning organization.

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 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 As per GPSoC requirements make minimal registration details mandatory (i.e. First Name, Surname, Gender, DOB) in the FHIR profile.

Minimum Patient Demographics

• SELECTED Patient Banner as defined in the CUI guidance.
• Community driven (i.e. just add Gender).
• Absolute minimum (Name, DOB and NHS Number).

DECISION Consumer SHALL cross-check with demographics returned from the Provider system.

View Non-Retrieval

Potential grounds for not returning an HTML view:

• Technical constraints
  • Generation from structured FHIR® resources
  • Can’t safely retrieve from GP system
• Information Governance
  • Data Sharing Agreement not in place
  • Patient Dissent to record sharing
• PDS Status
  • Corrupt Record etc.

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. [As agreed in workshops]
• Return error message in lieu of record section.
• Return snapshot of record as-is at the time of request including any non-committed changes.

Patient Consent

Patient Consent Preferences:

• SELECTED Patient consent enforced by the Provider system and cannot be overridden.
• Patient consent enforced by the Provider BUT can be overridden by Consumer.

Patient Data Exclusions

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

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

• Manual exclusion (based on explicit patient preference).
  • SELECTED Provider system-based patient preferences.
  • SCR standard patient preferences (in addition).¹
• Automatic exclusion (based on implied patient preference).²

¹ Providers are not initially expected to enforce SCR patient preferences in relation to returning API data. They SHALL only respect their own Principle patient preferences.

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

‘Confidential’ (GP Practice-designated) Data Exclusions

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

Items designated by the Practice as confidential SHALL not be provided, and processed in the same way as Patient Data Exclusions.

Sensitive Data Exclusion Set

DECISION Provider API processing SHALL support the application of an exclusion set, which SHALL be configurable, including containing Null values. The current RGCP Sensitive Exclusion Set SHALL be applied for FoT, for the complete patient record, or sections/data-items, but is likely to to amended pending the results of the current national review, expected February 2017 to be approved by the Joint GP IT Committee (JGPIT).
GP Summary Exclusion Code Lists

Data Sharing Agreements

• Data-Sharing Agreement must be in place between the consuming organisation and the providing organisation
• The Spine Security Proxy validates this requirement, therefore Provider Systems SHALL NOT apply or change locally-configured Data-Sharing validation

Exclusion Warnings

• No indication that data has been excluded.
• SELECTED Warning indication per section that data has been excluded (within the time frame).
• SELECTED In line with some information related to the data item.
  • i.e. 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.

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.

SCR Consent Model

SCR model (between Consumer and Provider’s who have an existing Data Sharing Agreement in place).

• No explicit consent (implied consent).
  • Core Data Set (Allergies, Adverse Reactions and Medications).
• Given explicit consent.
  • Diagnosis, Immunisations, Problems, Procedures and End of Life Preferences.
• Explicit consent needed (exclusion set).
  • Sexually Transmitted Infections, Terminations, Gender Reassignment.

Section-by-section Time Frames for data

Summary Time Frames

Date range handling in the summary per section:

• No date range due to clinical safety.
• SELECTED Date range to match workshop agreements.
  • Current XYZ (what does it mean for each section)
  • Last 3 Months Recent Investigations.
  • Last 3 Encounters
  • etc.
• Date range to match SCR time-frames for all sub sections.

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 (e.g. always return all allergies) with clinical sign off.

HTML Section Ordering

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

Operation Definition

Requesting A Section

• [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.