Notice
- Important: This guidance is under active development by NHS England and content may be added or updated on a regular basis.
- This Implementation Guide is currently in Draft and SHOULD NOT be used for development or active implementation without express direction from the NHS England Genomics Unit.
Consent and Permission
The Unified Genomic Record (UGR) uses FHIR R4 Consent resources to represent patient authorization relating to access, sharing, and use of genomic information.
Two primary consent use cases are supported within the UGR:
- Data Sharing — consent to support sharing of genomic information with clinicians for the purposes of testing, interpretation, or clinical management relating to family members.
- Data Use — consent governing secondary uses of genomic information, including research, population health management, and healthcare service improvement activities.
The expected sequence for adding a familial relationship asserted by a patient, and subsequent verification/consent from the family member is as below:
Data Use
Consent will also be used to capture patient consent for their UGR, and elements within their UGR to be used for particular purposes, e.g. research, population health management etc. This MAY specify which classes or specific instances of data are included in that consent (i.e. consent to Data Use).
UGR Consent instances SHALL conform to the IHE Privacy and Consent on FHIR guidance, specifically the Explicit Intermediate Consent model, supporting:
- Conformance to an overarching consent policy
- Limiting timeframes
- Permit/deny constraints for specific users/user types
- Permit/deny constraints for specific purposes of use
- Optionally, data scoping by id; class of data; author; relationship to other resources, such as ServiceRequest; or more granular purposes of use, e.g. for specific research projects
Sensitivity-based controls: Aligning to the Explicit Advanced consent could additionally limit access based on sensitivity of the data, though the need for this is currently being investigated.
An example of a Consent aligning to IHE PCF is provided at Consent-DataAccess-Example.
Roles and responsibilities (PCF actors)
In terms of IHE PCF Actors, the UGR will perform the role of the Consent Registry and Consent Authorisation Server (in conjuction with the NHS England API-M IAM platform) and will also likely perform the role of the Consent Enforcement Point as the data the consent applies to will also be hosted/referenced by the same system.
Note: As per PCF guidance elements filtered out at enforcement due to 'deny' provisions SHALL be omitted entirely from returned results, including references from resources included in the response
Scope and Category:
Scope SHALL be fixed to http://terminology.hl7.org/CodeSystem/consentscope|patient-privacy.
Category SHALL be one of
http://terminology.hl7.org/CodeSystem/v3-ActCode|RESEARCH (research information access)for Order Management Consent for NGRL/RoD.http://terminology.hl7.org/CodeSystem/v3-ActCode|INFA (information access)for providing access to the patient's UGR for specific purposes, as described by the UGR lenses below.http://terminology.hl7.org/CodeSystem/v3-ActCode|IDSCL (information disclosure)for providing access to a relative's healthcare professional, to inform their care, e.g. in the case of familial/cascade testing.
Consent in the context of the UGR is only consent to access data, e.g. for direct care, or research etc. Consenting to direct care activities is assumed though submission of information to the Genomic Order Management service.
Consent to research activities is implied through associated Consent resources with the scope of research, e.g. as used for RoD recording.
"scope" : { "coding" : [ { "system" : "http://terminology.hl7.org/CodeSystem/consentscope", "code" : "patient-privacy", "display" : "Privacy Consent" } ] }, "category" : [ { "coding" : [ { "system" : "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code" : "INFA", "display" : "information access" } ] } ],
patient
SHALL reference the patient for whom the consent is for.
"patient": { "reference": "Patient/Patient-AnitaLamberts-Example", "identifier": { "system": "https://fhir.nhs.uk/Id/nhs-number" "value": "8449303649" } },
dateTime
SHALL be the time the Consent record was created, likely populated by the UGR system.
"dateTime": "2026-05-07T09:08:30",
performer
MAY reference a RelatedPerson/Patient or potentially PractitionerRole if consent is being provided via another individual e.g. a proxy, otherwise SHOULD reference the patient themself Note: this may change to a backported element for the R5 Consent.grantee based on National Proxy guidance.
"performer": [ { "reference": "Patient/Patient-AnitaLamberts-Example", "identifier": { "system": "https://fhir.nhs.uk/Id/nhs-number" "value": "8449303649" } } ],
organization
SHALL be fixed to the ODS code for NHS England (X26) as this is the managing organisation for the UGR consents.
"organization": [ { "identifier": { "system": "https://fhir.nhs.uk/Id/ods-organization-code" "value": "X26" } } ],
source[x]
TBC. Not relevant for UGR consent resources as this is generated automatically on creation of a UGR, though IHE PCF requires a reference or attachment. This MAY be a reference to a QuestionnaireResponse representing the patients consent selections, e.g. via the NHS App.
"sourceReference" : { "reference" : "QuestionnaireResponse/QuestionnaireResponse-ConsentQuestionnaire-Example" },
policy
MAY be used to reference the NHS England Privacy Policy, e.g.
"policy" : [ { "uri" : "https://www.england.nhs.uk/wp-content/uploads/2018/05/nhs-england-privacy-notice-v1.77.pdf" } ],
provision
The main element that determines who has access to the UGR, what aspects of the UGR they have access to, and for what purposes they are allowed the use the data for. Note: granularity of rules to be supported within the UGR are still pending business analysis.
The top level type SHOULD represent the patient's overall consent to use of their data e.g. as indicated via their National Data Opt-Out selection. Sub-level provision elements SHOULD be used to represent exceptions to the higher level provision, though MAY be used to explicitly permit usage of data for specific purposes, where the higher-level provision is of type 'permit'. The guidance below relates to sub-level provisions only.
period is not expected to be used as the consent is expected to be actively managed by the patient during their lifetime. Equally, action, securityLabel, code and dataPeriod are not expected to be used for consent within the context of the UGR.
actor MAY be used to specify a class of individuals included within the consent statement, e.g. access for direct care by healthcare professionals, or for individuals, e.g. access to patient proxy. The level of granularity is pending business analysis.
For sharing of genomic data for care of family members, the actor SHALL reference the RelatedPerson resource for the family member.
purpose SHALL be used for encoding the four lenses of data access described above, using the following codes:
| Lens | System | Code | Display |
|---|---|---|---|
| Direct Care | http://terminology.hl7.org/CodeSystem/v3-ActReason | TREAT | treatment |
| Research | http://terminology.hl7.org/CodeSystem/v3-ActReason | HRESCH | healthcare research |
| Population Health | http://terminology.hl7.org/CodeSystem/v3-ActReason | POPHLTH | population health |
| Management Information/Intelligence | http://terminology.hl7.org/CodeSystem/v3-ActReason | HOPERAT | healthcare operations |
For sharing of genomic data for care of family members, the purpose SHALL be fixed to http://terminology.hl7.org/CodeSystem/v3-ActReason|FAMRQT (Family member request).
class MAY be used to indicate the classes of data the provision applies to, where whole classes of data, e.g. DiagnosticReports, are consented to, rather than specific instances.
data SHOULD be used where the consent applies to specific instances of data, such as a single report or sequence.
data.meaning MAY use any of the codes specified in the consent-data-meaning ValueSet, as data may not be useful in isolation, e.g. a report without the referenced observations. However, the authoredBy code is not expected to be used for the UGR.
Note: Whether consent resources covering data access permissions should be created for each data instance, simplifying access enforcement workflows, or Consent provisions should be amalgamated per individual, reducing the amount of resources in the consent store is still pending investigation, the example below illustrates the latter approach. Additionally, further analysis is required to determine whether provisions should be split by data, actor, purpose etc. or amalgamated where criteria are the same, e.g. sharing with proxy and provider (identified through actor entries) under the same provision where purpose=TREAT and class=DiagnosticReport.
However, it is expected consent for data sharing for the care of relatives SHALL be represented through separate Consent resources per relationship following the Consent-DataSharing-Example example.
"provision": { "type": "deny", "provision": [ { "type": "permit", "actor": [ { "role": { "coding": [ { "code": "PAT", "system": "http://terminology.hl7.org/CodeSystem/v3-RoleClass" } ] }, "reference": { "identifier": { "system": "https://fhir.nhs.uk/Id/nhs-number", "value": "9999999999" } } } ], "purpose": [ { "code": "TREAT", "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason" } ], "data": [ { "meaning": "instance", "reference": { "reference": "Observation/FullBloodCount" } } ] }, { "type": "permit", "actor": [ { "role": { "coding": [ { "code": "PROV", "system": "http://terminology.hl7.org/CodeSystem/v3-RoleClass" } ] }, "reference": { "reference": "Group/PDMPractitioners" } } ], "purpose": [ { "code": "HRESCH", "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason" } ], "data": [ { "meaning": "related", "reference": { "reference": "DiagnosticReport/CancerReport" } } ] }, { "type": "permit", "actor": [ { "role": { "coding": [ { "code": "PROV", "system": "http://terminology.hl7.org/CodeSystem/v3-RoleClass" } ] }, "reference": { "reference": "Group/PDMPractitioners" } } ], "purpose": [ { "code": "TREAT", "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason" } ], "class": [ { "code": "DiagnosticReport", "system": "http://hl7.org/fhir/resource-types" } ] } ] }
Data Access Policies and Security
If FHIR R5 is adopted, Permission resources MAY be used to capture system determined permission to access resources, e.g. by role/relationship to patient, in line with the Data Access Policies IG. As this is a resource introduced in FHIR R5, an alternative to using Permission resources is to use the Consent resource in R4, with the scope=rbac and category=allowable-actions as per representation of directly assigned activities being developed by the Healthcare Worker API. Allowed activities attributed to National RBAC roles are expected to be inspected through interrogation of the National RBAC based on the user's SDS JobRoleCode. Usage of the Consent resource for representing allowed activities is documented in the Directory of Service Implementation Guide England-Consent-Healthcare-Worker profile, with an example available in the Examples section of the Implementation Guide
{
"resourceType": "Consent",
"id": "Healthcare-Worker-Consent-AllowableActions-Example",
"status": "active",
"scope": {
"coding": [
{
"system": "https://fhir.nhs.uk/England/CodeSystem/England-ConsentScope",
"code": "rbac",
"display": "RBAC"
}
]
},
"category": [
{
"coding": [
{
"system": "https://fhir.nhs.uk/England/CodeSystem/England-ConsentCategory",
"code": "allowable-actions",
"display": "Allowable Actions"
}
]
}
],
"policy": [
{
"uri": "https://digital.nhs.uk/services/care-identity-service/registration-authority-users/registration-authority-help/registration-authority-key-documents-and-forms"
}
],
"provision": {
"type": "permit",
"actor": [
{
"role": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-RoleClass",
"code": "EMP",
"display": "employee"
}
]
},
"reference": {
"reference": "https://directoryservice.example.nhs.uk/FHIR/R4/PractitionerRole/454567759542",
"identifier": {
"system": "https://fhir.nhs.uk/Id/sds-role-profile-id",
"value": "454567759542"
}
}
}
],
"action": [
{
"coding": [
{
"system": "https://fhir.nhs.uk/England/CodeSystem/England-SDSActivityCode",
"code": "D8001:C8004:B0820",
"display": "View Patient Demographics"
}
]
}
]
}
}
User claims regarding purpose of use SHALL be made in the authentication token, e.g. within the JWT access token, using the purpose_of_use parameter, as described in the IHE IUA Technical Framework. This SHALL use the same CodeSystem used within Consent.provision.provision.purpose. As user authentication lies outside the FHIR model, examples/guidance will not be elaborated within this Implementation Guide. Questions regarding authentication mechanisms can be directed to the NHS England Genomics Unit.
{
"iss": "urn:vendor:sts",
"sub": "https://fhir.nhs.uk/Id/sds-user-id|9999999998",
"aud": "https://int.api.service.nhs.uk/genomic-order-management-service/FHIR/R4/DiagnosticReport",
"exp": 1778679127,
"nbf": 1778675527,
"iat": 1778675527,
"scope": "ITI-68",
"extensions" : {
"ihe_iua" : {
"subject_name": "Dr. Eugene Smith",
"subject_organization": "MEDWAY MARITIME HOSPITAL",
"subject_organization_id": "https://fhir.nhs.uk/Id/ods-organization-code|RPA02",
"person_id": "https://fhir.nhs.uk/Id/nhs-number|7449306524",
"subject_role": [{
"system": "https://fhir.nhs.uk/England/CodeSystem/England-SDSJobRoleCode",
"code": "S8000:G8001:R8005",
"display": "Biomedical Scientist Access Role"
}],
"purpose_of_use": [{
"system": "http://terminology.hl7.org/CodeSystem/v3-ActReason",
"code": "TREAT",
"display": "treatment"
}]
}
}
}
Categorisation of data based on sensitivity or health domain SHALL use security/privacy sensitivity labels. The types of sensitivity labels supported, and inspected, by the Unified Genomic Record are still under investigation.
"meta" : { "security" : [ { "system" : "http://terminology.hl7.org/CodeSystem/v3-Confidentiality", "code" : "R", "display": "Restricted" } ] },
Enforcement of user access will be applied by inspecting the following, to ensure appropriate access to resources for clinicians is provided:
- Consent provided by the patient (Consent)
- Sensitivity of the data itself (Security Tags)
- Permissions associated with the user (Healthcare Worker Consent/National RBAC)
- Purposes claimed by the user (IHE IUA JWT Access Token)