NHSE Design and Development Approach

This guidance is under active development by NHS Digital and content may be added or updated on a regular basis.

A brief description of the purpose of this section

FHIR Assets

This section documents the approach used by the NHSE Development team to produce and maintain the NHSE Implementation Guides and the NHSE FHIR assets. It will be updated and matured in line with decisions taken during the Clinical and Technical Assurance process. This documentation is aimed at the technical reader and is included as reference material. The approach is based on the design principles.

Conformance

The NHSE IG conforms to the HL7 FHIR® specification (Release 4) and its assets are profiles of the corresponding base HL7 FHIR resources.

Further information about conformance in FHIR is available.

Design Principle

Key Principle:

FHIR assets must not be England specific and must be capable of representing the requirements of each UK nation identified during collaboration.

Other Principles

Reference DataType

If there is a draft or active NHSE IG version of a Resource then this Profile SHALL be used as the reference. If there is no NHSE IG version available then the reference SHALL be the HL7 Resource version.

Extensions

There is a NHSE IG requirement to develop extensions based on any equivalent CareConnect STU3 extensions. The exception to this is where an extension is no longer needed because either:

  • the data can be carried in a new element for a relevant resource in FHIR R4
  • a corresponding common extension has been developed in FHIR R4

Extension will be constrained (hard coded) into profiles to profiles after agreement during Clinical and Technical assurance.

The Implementation Guide for the NHSE IG will include an Extension Library page, which will list extensions and their corresponding NHSE IG profiles. There is no requirement to profile HL7 extensions locally. Where a HL7 extension is identified as in scope, a link to it will be added on the Extension Library page under HL7 Common Extensions.

Read more about FHIR Extensions and Extension Design.

Cardinalities

FHIR resource element cardinalities will only be amended, if clinical justifications are agreed during Clinical and Technical assurance. No elements will be removed unless deemed clinically unsafe following consultation and agreement during Clinical and Technical assurance. Read more about FHIR resource cardinalities.

Slicing

SHALL only be used where it enforces structure in a profile, for example for a ValueSet binding for the representation of an identifier in a list, such as a patient's NHS number Slicing SHALL be Open e.g. one or more additional slices can be added. Read more about Slicing in FHIR.

Must Support

Will only be used when there is a requirement arising from a use case identified during Clinical and Technical assurance. Read more about "Must Support" in FHIR.

ValueSets

Binding Strengths The UKCore ValueSet binding strength SHOULD be decided as part of the Clinical and Technical Assurance, but the general philosophy is as the following:

  • required - Used only when defined as 'required' by the FHIR standard, or when decided as part of the Clinical and Technical Assurance.
  • extensible - All ValueSets SHOULD be set to 'extensible', where not defined as 'required' by the FHIR standard, or 'preferred' by the NHSE IG standard.
  • preferred - Used when the ValueSet contains SNOMED CT or dm+d concepts due to their inherent complexities, or when decided as part of the Clinical and Technical Assurance.
  • example - Decided as part of the Clinical and Technical Assurance. Read more about ValueSets and ValueSet bindings in FHIR.

Validation

All FHIR assets SHALL be validated before being publicly available. See Validation of Implementations for more details.

FHIR Resource Spelling

FHIR Resources, along with ValueSets, CodeSystems and ConceptMaps use the American-English spelling, for example Organization. The NHSE IG approach is to use American-English for any Profile, Extension, ValueSet, CodeSystem, and ConceptMap names, and when directly referring to the names within the Implementation Guide, otherwise using the British-English for all other aspects.

back to top