This
guidance
is under active development by NHS Digital and content may be added or updated on a regular
basis.
Release notes
Previous versions and their release notes can be found below, including links direclty to the respective version of the specification.
1.6.2
DRAFTTHIS VERSION
Important: The link to pre-published site needs updated once published.
The GP Connect API 1.6.2 release contains numerous changes intended to improve and clarify guidance for both providers and consumers. The more notable changes include:
Resources may contain a ‘no disclosure to patient’ security label
Affects: Access Documents, Access Record Structured
Impacts: N/A
Description:
Resources MAY have Meta.security populated with a security label indicating information is not to be disclosed to the patient in response to retrieve a patient's record, for applicable resources
Resources MUST have Meta.security populated with a security label indicating information is not to be disclosed to the patient in response to migrate a patient's record, for applicable resources
CareConnect-SDSJobRoleName-1 CodeSystem updated with additional job roles
Affects: Access Documents, Access Record Structured
Impacts: Provider and consumer systems
Description:
A number of additional job roles have been added to the CareConnect-SDSJobRoleName-1 CodeSystem
Pages changed:
N/A
Profiles link directly to Simplifier
Affects: Access Documents, Access Record Structured, Appointments, Foundations
Impacts: N/A
Description:
The majority of the Access Record Structured Implementation Guide (IG) that was hosted on developer.nhs.uk has been migrated to this IG (on Simplifier), see the change below. The Links to profiles in other sections of the IG hosted on developer.nhs.uk have been updated to link to the profile hosted on Simplifier within the GP Connect Data Model | FHIR STU3 Representation
Clarify handling for MedicationRequest with intent of order when plan has been discontinued
Affects: Access Record Structured
Impacts: Provider and consumer systems
Description:
The guidance for a MedicationRequest’s status in a scenario where a MedicationRequest with intent of order that is part of a discontinued plan has been clarified i.e. it should not be updated to stopped
Update Specimen collection.extension[fastingStatus] to include coded concept
Affects: Access Record Structured
Impacts: Provider and consumer systems
Description:
Specimen collection.extension[fastingStatus] should return the coding element with the appropriate information from the relevantClincialInformation ValueSet alongside the text
DiagnosticReport.identifier may be the lab report ID
Affects: Access Record Structured
Impacts: Provider and consumer systems
Description:
If the lab report ID uses the NHS PMIP Report Numbers CodeSystem and it could be used by consumers to match lab reports it can be included in DiagnosticReport.identifier
Clarify overarching principles for MedicationRequest element population
Affects: Access Record Structured
Impacts: Provider and consumer systems
Description:
There are two pre-existing overarching principles for populating MedicationRequest. The first is that all mandatory fields MUST be populated and has not changed. The second is how to populate fields that are duplicated in parent profiles, this has changed.
Previously, it was stated:
"Required fields MUST always be populated where the data exists in the system apart from where a lexically identical value exists for an equivalent data item in one of the parent profiles. For a MedicationRequest with intent of plan the associated MedicationStatement would be the parent profile. For a MedicationRequest with intent of order, the associated MedicationStatement and MedicationRequest with intent of plan are both considered parent profiles."
This has been updated to state:
"Required fields MUST be populated where the data exists in the system"
Remove potentially confusing statement from Medication.code
Affects: Access Record Structured
Impacts: N/A
Description:
A potentially confusing statement has been removed from the Medication.code element guidance. The (already linked) CodeableConcept guidance document is more prominent
Binding strength for VaccinationProcedure reduced to preferred
Affects: Access Record Structured
Impacts: Provider and consumer systems
Description:
The binding strength of the VaccinationProcedure extension element for the Immunization profile has been reduced from required to preferred
Pages changed:
N/A
Update MedicationRequest.medication and MedicationStatement.medication datatype
Affects: Access Record Structured
Impacts: Provider and consumer systems
Description:
MedicationRequest and MedicationStatement profiles have had the constraint on the medication element relaxed so they align with the base profile i.e. medication can be either a reference or a CodeableConcept. This is to accommodate use cases such as updating the record where only a single medication is needed and a CodeableConcept would mean a separate Medication resource is not needed as there would be no other references to it. The guidance is for both consumers and suppliers to treat the element as if it is a reference.
The 'Problems' section of the record was able to be filtered by the significance of the problem via the filterSignificance part parameter. The functionality is not required and has been removed, leaving only a problem's status as a filter for problems. The description of the OperationDefinition has been updated accordingly along with a description of how to handle the situation, should requests be made including the parameter. A link to the existing forward compatibility section has been included
Updated requirements catalogue to remove significance filter
Relax requirement for individual areas of the record to be turned on or off at a global level
Affects: Access Record Structured
Impacts: Provider systems
Description:
The requirement for individual areas of the record to be able to be turned on or off at a global level i.e. applicable to all sites, has been relaxed. Provider systems must continue to support toggling individual areas of the record at a site/practice level, along with responding to requests for areas that have been turned off continues to be the same.
New requirement for resolved allergies to be returned as transfer-degraded drug allergies
Affects: Access Record Structured
Impacts: Provider systems
Description:
Resolved allergies are returned within a specific list for ended allergies. The allergy resources returned within the list should be returned as transfer-degraded drug allergies using the appropriate coding system. This change mitigates against the scenario where the resolved attribution is lost during transfer as transfer-degraded resources are not able to be used by decision support.
The description of the OperationDefinition for the retrieve a patient's record API has been updated to ensure it aligns with the profile definition. The filterPrescriptionType part parameter isn't supported by the API but does exist on the profile. As a result, it has been added to the description and made clear it isn't supported. How to handle the situation, should requests be made including the parameter, has been described and a link to existing forward compatibility section has been included
Migrate patient document interaction is optional for existing suppliers on the GP IT Futures framework and required for New Market Entrants
Affects: Access Documents
Impacts: Provider and consumer systems
Description:
Added note to state the migrate patient’s document interaction MAY be implemented by existing suppliers on the GP IT Futures framework and MUST be implemented by New Market Entrants
Migrate patient record interaction is optional for existing suppliers on the GP IT Futures framework and required for New Market Entrants
Affects: Access Structured
Impacts: Provider and consumer systems
Description:
Added note to state the migrate patient’s structured record interaction MAY be implemented by existing suppliers on the GP IT Futures framework and MUST be implemented by New Market Entrants