UGR Integration

Background

The Unified Genomic Record (UGR) is a key technological component designed to unify patient genomic data into a single, patient-centric record. The UGR is intended to standardise the collection, storage, and sharing of genomic data across the NHS, ensuring that genomic information is interoperable and accessible across all care settings.

The UGR architecture is structured into three key layers:

  1. End User Functionality – Integrating with existing NHS services to facilitate direct interaction with the UGR
  2. Interoperability – Serving as the primary gateway for accessing and sharing genomic data across different healthcare systems.
  3. Data Storage – Implementing a hybrid centralised and federated data storage model, leveraging the Patient Data Manager (PDM) as the central data entry point.

The key problems the UGR aims to address in support of delivering the Genomic Medicine Service are:

  1. Fragmented and Inconsistent Genomic Data Management, by bringing the genomic data into a single genomic record framework and enforcing UK Core FHIR interoperability standards. Access is centralised through APIM and MNS. Centralising genomic data access will help promote standards adoption by suppliers.
  2. Limited Reusability of Genomic Test Reports, by bringing the genomic data into a single genomic record framework and enforcing GA4GH and UK Core FHIR interoperability standards.
  3. Inefficient Data Use for Research and Population Health, by providing a centralised unified point of access for genomic data that is readily available for population health, management information and research, reducing the burden on GLHs and enabling more robust data analysis and insights.
  4. Limited Integration of Genomic Data with Clinical Pathways, by decoupling genomic data from the systems involved with the originating test request and making available for any other provider with other clinical data, enabling more comprehensive patient management and facilitating the use of precision medicine across the NHS.
  5. High Administrative Burden and Operational Inefficiencies, through use of the genomic order management service. Adoption of standards and a unified point of data access will significantly reduce administrative workloads and improving the overall efficiency of genomic services.
  6. Inadequate Data Linkage for Inherited and Rare Diseases, by providing a simple mechanism for securely linking genomic records, respecting patient preferences, and enabling the implementation of targeted, family-based care strategies.
  7. Lack of Centralised System for Identifying Clinical Trial Eligibility, by potentially serving as a centralised virtual repository that enables researchers to identify eligible patient cohorts, enhancing patient access to innovative therapies and supporting the growth of clinical research.
  8. Absence of a centralised access control, by providing an opportunity to streamline access control processes, allowing patient-based policies instead of organisation or system-based policies. With the data decoupled from end-user systems, enforcement of policies at source is assured and includes comprehensive audit and transparency for patients improving confidence and trust.
  9. Inconsistent Access to Pharmacogenomic (PGx) Data Across NHS, by providing the master PGx record for patients and making the data available nationally to any clinical decision support system involved in prescribing.
  10. Inability to Provide Comprehensive Patient Access and Transparency, by centralising access to the genomic record via the APIM. This significantly simplifies the integration of the UGR with the NHS App.

Genomic Data Reuse

One of the key aims of the UGR is to enable reuse of data across different health contexts: Direct Care; Population Health Management; Management Information; and Research. To support each context, slightly different data access approaches are needed.

Genomic data in direct care is mostly used as a diagnostic source. Data is shared using national standards and provider systems directly interact with the UGR via APIs. All direct care data is shared through legitimate access, managed by national RBAC, although data redaction and other minimisation approaches can be built into the API.

Population health management and management information requires access to groups of patient genomic records. This can be achieved in two ways:

  1. Separate API calls to the PDM via APIM per patient record.
  2. Bulk Query API calls to the PDM using GA4GH Beacon API requesting sets of data across multiple patients.

Purpose-Based Access Control (PBAC) is implemented for each patient, respecting their preferences for secondary data sharing. Data returned via the API is pseudonymised using NHS England's national pseudonymisation system or in the clear if used for commissioning purposes.

Using genomic data for research requires request-specific data processing. The UGR utilises Purpose-Based Access Control to ensure legitimacy of all data requests regardless of the clinical context. For research, the request must be supported by a PBAC policy within each patient’s UGR for the ability to query their data as part of a cohort search. The PBAC rules can be defined to be as explicit as required. For example, a patient may permit their data to be used for cancer research, but request to be asked for permission for other types of research. The rules are defined, and patient preferences managed via the NHS App.

The returned data may be modified depending on the PBAC policies and the context:

  • Data minimisation – only return what is necessary for the functionality required.
  • Data redaction – make requester aware of data existing but respond with ‘data redacted’ in fields as defined in the PBAC rules.
  • Pseudonymisation – remove all patient identifiable information and provide an NHS England derived pseudonym for the patient ID.
  • Anonymisation - remove all patient identifiable information and ensure patient identity is unable to be derived from the patient data returned.

Scope

  • Order Management: The UGR will surface all test order requests and reports, and associated meta data provided by the order management services.
  • Digital Genomics Test Directory Services: The UGR may reference this service for data validation of storing test order requests and reports.
  • Specimen Data: The UGR will record sample metadata and reference any sample storage resources used as part of genomic diagnostics.
  • Sequence Data: The UGR will record and provide access to all data created from the DNA sequencing process. This applies to all genomic diagnostic modalities, including whole genome sequencing (WGS).
  • Family Linking: Linking UGR records is a key requirement and is within scope to support inherited disease diagnostics.
  • Purpose Based Access Control (PBAC): The UGR implements purpose-based access control at the data layer. Storing the access control policies and enforcement via data sharing processes are in scope.
  • Secondary uses: Storage and sharing of UGR data for population health management, management information and research.
  • National Genomic Research Library: Providing the structured data and transport into the NGRL from the UGR is in scope. Specific implementations must honour appropriate information governance.

The data output formats in scope are:

  • OMOP
  • FHIR
  • PLCM (TBC)
  • GA4GH

The data transports used to share data, which are in scope, are:

Architecture

Each patient will have a self-contained Unified Genomic Record. A simplified logical model can be expressed as a folder tree. Each folder holds relevant data and metadata.

UGRFolders

The data structure, storage type, and location within each folder may vary depending on the data requirements. The table below is an example of possible content of the UGR.

Folder Data Structure Storage Type Location
Demographics JSON (FHIR) FHIR Repository NHS England
Genomic Test Request JSON (FHIR) FHIR Repository NHS England
Genomic Test Reports JSON (FHIR) FHIR Repository NHS England
Genomic Data BAM, CRAM, VCF Local/Cloud File Store GLH or GEL
Family History JSON (FHIR) FHIR Repository NHS England
Purpose Based Access Controls and Consent JSON (CEDAR/FHIR) FHIR Repository NHS England
Audit Logfile/FHIR Cloud File Store/PARS NHS England

Genomic data is highly reusable, and it is possible to perform new genomic tests upon existing genomic data, e.g. through reanalysis and reinterpretation requests, negating the need to repeat a specimen collection and wet laboratory process. For this reason, test data can reference existing genomic data. The genomic data can be hosted in multiple places, and a FHIR document reference resource can refer to a GA4GH Data Repository Standard (DRS) location.

Data Storage Components

The UGR contains three primary classes of data, each necessitating a distinct approach to data management and storage:

  1. Structured data that captures the details of genomic test orders, sample processing, bioinformatics analyses, test reports and reporting etc. This data is characterised as being complex, highly structured based on HL7 FHIR standard, but low in volume compared to the primary genomic data.
  2. Unstructured data held in other general file formats such as CSV and PDF to support legacy systems incapable of consuming structured data.
  3. The large-scale data generated by DNA genotyping and sequencing technologies, such as the primary sequencing reads (in SAM, BAM or CRAM formats) and derived data such as variant calls (in VCF) and other data produced by bioinformatics analyses.

To accommodate this diversity and maximise functionality, multiple data repositories are utilised rather than a single physical repository. The Diagram below shows the separation components required to support the UGR.

UGRDataStore

Central FHIR Store

It is expected that all FHIR resources will be stored in a national FHIR store, available through RESTful API Access via the national API platorm.

Federated Object Store

Not all genomics-related data is suitable for storage within FHIR repository. To accommodate different data classes, multiple Federated Object Stores can be utilised, leveraging cloud object stores. To ensure consistency, the GA4GH Data Repository Service (DRS) protocol will be adopted as the standard retrieval mechanism for all data accessible via the UGR. The use of DRS enables the UGR to support both centralised and federated storage models, or a combination thereof. DRS URIs stored within FHIR DocumentReference Resources for each patient will serve as the logical identifiers for all files hosted within the Federated Object Stores.

Bulk Query Interface

For population health management and research use cases, the UGR requires the ability to perform queries across larger sets of data. The APIs supporting these queries are typically read-only and may operate asynchronously to facilitate population-level analysis. The Bulk Query Interface component is designed to support these use cases, with the data made available potentially being transformed and reformatted to optimise bulk querying an RDMS source.

FHIR API

Composition

The main resource type supporting implementation of the UGR will be the Genomics-Composition resource. This resource aligns with existing Summary Care Record implementations and mirrors the EU Patient Summary guidance, in which sections are defined for different clinical data categories (for example, laboratory reports and patient demographics), each containing references to the relevant resources.

It is expected that the UGR could be represented as a section under a more general patient summary, though details of whether aspects of the UGR will be represented as a standalone component or separated within relevant sections of a wider single patient record, e.g. aligned to the International Patient Summary, are pending finalisation of the SPR design. When the UGR is integrated into a single patient record, the generation of the Composition resource will follow the selected system's approach.

The implementation approach is that a Composition resource will be generated and updated automatically by the UGR system following addition of resources referencing a patient, e.g. upon submission of a request to the Order Management service. In this case, the Order Management service would persist the information on the UGR, triggering the creation of a Composition resource which acts as the manifest for the Genomics related data. The UGR Composition always represents the current state of the unified genomic record. Other services, such as the National Care Record Service (NCRS), can then retrieve the Composition resource and generate a FHIR document using the $document operation.

Consequently, the Composition endpoint is read-only. Create and update operations are performed through the clinical resource endpoints, together with the Consent (for data access permissions) and RelatedPerson (for linkage of UGRs) only, though this may be integrated with the OM and SPR APIs. This prevents clients from directly modifying the Composition resource, reducing the risk of inconsistent or overwriting information.

This is illustrated in the below sequence diagram (assuming a single unified Genomic Digital Service entry point, and also incorporating notifications via the Multicast Notification Service):

The sections included within the UGR are coded using UK Core Record Standard Headings CodeSystem, as follows (Note: these may need to be aligned to IPS section headings depending on where the UGR sits within the wider Single Patient Record):

Section Title Code Entry Resource Type
Patient demographics patient-demographics Patient (may reference the NHS identifier where the patient is registered in PDS)
Investigations and procedures requested investigations-and-procedures-requested ServiceRequest
Investigation results investigation-results DiagnosticReport (this resource will link off to the various Genomic Data Files and Observations, Note: a separate section for genomic data and observations irrespective of the report/request which generated this is currently being investigated, e.g. for on demand CDS)
Consent for information sharing consent-for-information-sharing Consent
Family history family-history RelatedPerson/FamilyMemberHistory
TBC:
Alerts		 alerts Expected to reference a Flag resource to record considerations for treatments, e.g. for medication, based on genetic results.

An example of a UGR record can be found at Composition-UGR-Example

Type and Category

To appropriately categorise the UGR alongside other Compositions and Documents, the type and category SHALL be fixed as represented below.

"type": {
  "coding": [
    {
      "system": "http://snomed.info/sct",
      "code": "824321000000109",
      "display": "Summary record"
    }
  ]
},
"category": [
  {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "321401000000106",
        "display": "Genomics"
      }
    ]
  }
],

Author and Custodian

As the UGR is created and managed by NHS England, the author and custodian elements will be fixed to the X26 ODS code.

"author": [
  {
    "identifier": {
      "system": "https://fhir.nhs.uk/Id/ods-organization-code",
      "value": "X26"
    }
  }
],
"custodian": {
  "identifier": {
    "system": "https://fhir.nhs.uk/Id/ods-organization-code",
    "value": "X26"
  }
},

Section

To better conform to the EU Patient Summary (EPS) Implementation Guide, section.text has been added to provide a human-readable HTML representation of the UGR sections.
An example is provided below.

"section": [
  {
    "title": "Patient demographics",
    "code": {
      "coding": [
        {
          "system": "https://fhir.hl7.org.uk/CodeSystem/UKCore-RecordStandardHeadings",
          "code": "patient-demographics",
          "display": "Patient demographics"
        }
      ]
    },
    "text": {
      "status": "generated",
      "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Pheobe Smitham, Female, DOB: 2013-09-27</div>"
    },
    "entry": [
      {
        "identifier": {
          "system": "https://fhir.nhs.uk/Id/nhs-number",
          "value": "9449307539"
        }
      }
    ]
  },

Other Fixed Elements

  • status SHALL have a fixed value of final
  • title SHALL have a fixed value of Unified Genomic Record Summary
  • confidentiality SHALL have a fixed value of R due to the sensitivity of the data within the UGR

RelatedPerson

UGRs for family members are linked using Genomics-RelatedPerson resources, following the same profiling used by the Genomic Order Management Service. Note: The Order Management use case assumes family relationships are asserted/validated by the requesting clinician, however analysis is needed to determine whether UGR familial relationships can be asserted and approved by the patient/related person themselves

Family Members Without a UGR

FamilyMemberHistory resources MAY additionally be used to link clinical family history for individuals who do not have a UGR, such as deceased family members, those who live abroad, or individuals whose identity cannot be confirmed. When used FamilyMemberHistory resources SHALL conform to the Genomics-FamilyMemberHistory profile guidance.

The PersonalRelationship resource, introduced in FHIR R5, is simlar to the RelatedPerson resource as it provides a mechanism for expressing relationships between two individuals. However, unlike RelatedPerson, it does not represent an individual as a standalone clinical entity and instead models the relationship only. Although conceptually appealing for linking UGR records, the resource is of low maturity and not part of the normative content in R6. As such, PersonalRelationship SHALL NOT be used in the context of the UGR until further notice.

The GA4GH Pedigree standard provides a data model for representing family health history. This is equivalent to the Genomics use of the FamilyMemberHistory resource, with caveats around the FMH resource being limited to pairs of individuals rather than complete family units.

Data Access and Search Guidance

The Unified Genomic Record (UGR) is exposed as a FHIR Composition-based summary, structured into sections (e.g., demographics, investigations requested, results, consent, family history).

Direct care

For direct care, the UGR supports record retrieval only for a known patient. Patient discovery is out of scope and MUST be performed externally via PDS. API clients MUST supply an NHS Number or a local identifier (non-NHS Patient) previously registered via the Central Genomic Order Management System.

Supported search pattern:

Option A
Clients SHALL retrieve the UGR via the Composition resource and then resolve each section.entry reference as needed. Required SearchParameters

  • Composition.subject:identifier (NHS Number or local identifier)
  • Composition.status=final
  • Composition.type=824321000000109 (Summary record)
  • Composition.category=321401000000106 (Genomics)

Example:

GET /Composition?subject:identifier=https://fhir.nhs.uk/Id/nhs-number|9449307539&type=http://snomed.info/sct|824321000000109&category=http://snomed.info/sct|321401000000106&status=final&_sort=-date&_count=1

Option B
Generate a complete UGR Document Bundle via Composition/$document operation as per Composition document.

Cohort / Population Search

For population health, management information, and research, cohort  access SHALL use bulk query APIs, separate from the direct care endpoints. Searches MAY be performed using cohort-level criteria (e.g. genomic variants, conditions), and results SHALL be pseudonymised or anonymised and meet minimum cohort size thresholds to prevent re-identification. The minimum threshold is under review, TBC.

To protect confidentiality, queries that risk identifying individuals (e.g. highly specific rare disease searches scoped to small geographic areas) SHALL be rejected. E.g. You cannot search for a patient in a single post-code with a rare disease.

All queries MUST operate under Purpose-Based Access Control (PBAC), with explicit declaration of purpose (e.g. research, population health).

Phamacogenomic Medication Alerts

For Pharmacogenomic use cases, results from genomic testing may indicate that certain treatments are contraindicated. For example, in CYP2C19 testing, it may be identified that a patient is a poor metaboliser of certain medications which require activation through the CYP2C19 enzyme. This includes Clopidogrel, meaning other antiplatelet therapy may need to be considered.

It is still to be confirmed whether the UGR would explicitly record prescribing implications for medications (as many could be affected by a gene variant) or simply record details of the genetic testing, such as metaboliser status, which is then assessed at the point of prescribing against the medication being considered, using applicable computable pharmacogenomic guidelines.

There are multiple resources which are relevant to proposed or prescribed medication alerts. However, each resource type has a different use case, as detailed below:

Purpose Resource Notes
Genomic fact Observation Used to record the information obtained directly from genomic testing, independent of any specific medication or clinical interpretation
Persistent patient warning or prescribing consideration Flag Used to highlight information which should be prominently visible across care settings, such as reduced efficacy or increased toxicity risk
Specific prescribing conflict DetectedIssue Result from a Clinical Decision Support service, which evaluated the underlying genomic finding against a concrete, proposed medication, using available clinical guidelines, at the point of prescription
Actual adverse reaction AllergyIntolerance / AdverseEvent Recording of allergies or adverse reactions, generally post medication administration, to warn of effects

A snippet of a Flag resource for warning against clopidogrel use is provided below, with key elements populated, though usage of the Genomic finding itself is more future-proof as it can be applied to multiple drugs. Note in the below example the code indicates intolerance to clopidogrel but the scenario above requires a code for ineffectiveness, which is not currently in SNOMED CT as a finding/situation:

{
  "resourceType": "Flag",
  "id": "Flag-Clopidogrel-Example",
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/flag-detail",
      "valueReference": {
        "reference": "Observation/Observation-CYP2C19Metaboliser-Example",
        "display": "CYP2C19 poor metaboliser phenotype"
      }
    }
  ],
  "status": "active",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/flag-category",
          "code": "drug",
          "display": "Drug"
        }
      ]
    }
  ],

  "code": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "88191000000108",
        "display": "Clopidogrel not tolerated"
      }
    ], 
    "text": "CYP2C19 poor metaboliser. Consider alternative antiplatelet therapy to Clopidogrel"
  },
  "subject": {
    "identifier": {
      "system": "https://fhir.nhs.uk/Id/nhs-number",
      "value": "9999999999"
    }
  },
  "period": {
    "start": "2026-07-27"
  },
  "author": {
    "identifier": {
      "system": "https://fhir.nhs.uk/Id/ods-organization-code",
      "value": "X26"
    }
  }
}

Flag lifecycle

Flag creation

A flag is created when the need for an alert on the patient record is identified. This may be at the point of reporting, where the genomic findings and implications are returned to the requesting clinician, or when the requesting clinician has reviewed the report and identified the need for an alert. Alternatively, this could be created when CDS identifies an issue at the point of prescribing (though this could equally be represented through a DetectedIssue resource).

Flag updating

The only updates to flags are expected to be setting a status of inactive, and adding of a period.end, though this is expected to be very rare, as the underlying genomic findings will remain the same, though implications may change as PGx guidance is updated. As such it is not expected that a Flag originating from genomic findings would naturally expire. Any organisation MAY update a Flag as part of routine care for a patient.

New Flags may be created to replace ones that are no longer valid or need to be superseded. Equally Flags may be withdrawn by marking them as entered-in-error, though this is expected to be rare.