Search loading...

API Hub

Explore and Make use of Nationally Defined Messaging APIs

 


ReferralRequest resource

FHIR resource for population guidance for ReferralRequest

Introduction

The headings below list the elements of the ReferralRequest resource and describe how to populate and consume them.

ReferralRequest elements

id

Data type: Id Optionality: Mandatory Cardinality: 1..1

The logical identifier of the ReferralRequest resource.

meta.profile

Data type: uri Optionality: Mandatory Cardinality: 1..1

The ReferralRequest profile URL.

Fixed value https://fhir.nhs.uk/STU3/StructureDefinition/CareConnect-GPC-ReferralRequest-1

identifier

Data type: Identifier Optionality: Mandatory Cardinality: 1..*

This MUST be populated with a globally unique and persistent identifier (that is, it doesn’t change between requests and therefore stored with the source data). This MUST be scoped by a provider specific namespace for the identifier.

Where consuming systems are integrating data from this resource to their local system, they MUST also persist this identifier at the same time.

If the referral was made via the e-Referral Service and a Unique Booking Reference Number (UBRN) exists for the referral, then it MUST be included as an identifier. The system identifier for this is https://fhir.nhs.uk/Id/ubr-number.

basedOn

Data type: Reference(CarePlan, ProcedureRequest, ReferralRequest) Optionality: Optional Cardinality: 0..*

Indicates any plans or prior referrals that this referral is intended to fulfill.

status

Data type: Code Optionality: Mandatory Cardinality: 1..1

Fixed value of unknown. Referrals ‘entered in error’ must not be included.

intent

Data type: Code Optionality: Mandatory Cardinality: 1..1

Fixed value of order.

priority

Data type: Code Optionality: Required Cardinality: 0..1

A mapping is applied to the priority codes to align it to the e-Referral Service priority types. This MUST be populated where the source system has a referral priority which matches the e-Referral Service priority codes or can be mapped to those priority codes. If there is a priority code for the referral but it is incompatible with the e-Referral Service priorities, this element MUST be excluded and the priority MUST be supplied in the note element.

serviceRequested

Data type: CodeableConcept Optionality: Optional Cardinality: 0..*

This MUST NOT be populated with the source system’s main code for the referral, which MUST be returned in the reasonCode element. This MAY be populated if the GP clinical system also holds a distinct entry for the type of service requested.

subject

Data type: Reference(Patient) Optionality: Mandatory Cardinality: 1..1

A reference to the patient who is the subject of the referral.

context

Data type: Reference(Encounter) Optionality: Required Cardinality: 0..1

The Consultation within which the referral was recorded.

authoredOn

Data type: dateTime Optionality: Required Cardinality: 0..1

The main date for the referral as entered by the end user in accordance with the date of referral guidance.

requester

Data type: BackboneElement Optionality: Required Cardinality: 0..1

The details of the person, practitioner or organisation responsible for the decision to refer the patient or, if is not attributed specifically, then populate with the recorder.

requester.agent

Data type: Reference(Device, Organization, Patient, RelatedPerson, Practitioner) Optionality: Mandatory Cardinality: 1..1

The preferred agent is the practitioner responsible for the decision to refer the patient. If the referral is not attributed to a practitioner, then any of the other resource options MAY be used as most appropriate. If the referral does not clearly identify responsibility for the referral decision or action, this MUST be the user who recorded the referral.

requester.onBehalfOf

Data type: Reference(Organization) Optionality: Required Cardinality: 0..1

This MUST be populated if the requester.agent is a practitioner and the Organization associated with the referenced Practitioner is not the GP practice responsible for the referral. This element SHOULD be absent if the requester.agent is not a practitioner.

specialty

Data type: CodeableConcept Optionality: Optional Cardinality: 0..1

This MUST NOT be populated with the source system’s main code for the referral, which MUST be returned in the reasonCode element. This MAY be populated if the GP clinical system holds a distinct entry for the clinical or practitioner specialty requested by the referral.

recipient

Data type: Reference(HealthcareService, Organization, Practitioner) Optionality: Required Cardinality: 0..*

This MUST be populated with the practitioner and/or organisation the patient has been referred to, if that is recorded in a suitable coded format. If the referral recipient details are in a form which cannot be returned as a referenced resource, the details MUST be populated to the note as key value pairs.

reasonCode

Data type: CodeableConcept Optionality: Required Cardinality: 0..*

This MUST be populated with the source system’s main coded entry for the referral. Additional, coded or text entries which are clearly captured as reasons for referral MAY be included.

description

Data type: string Optionality: Required Cardinality: 0..1

The free text description associated with the referral.

supportingInfo

Data type: Reference(Any) Optionality: Required Cardinality: 0..*

Reference to the referral letter(s) and any other supporting documents or resources which are not covered by other more specific elements, for instance this could include reference to linked observations or test results.

This does not apply to a linked problem. The problem MUST be included in the bundle and reference to the referralRequest. The referralRequest MUST NOT reference to the problem.

note

Data type: Annotation Optionality: Required Cardinality: 0..*

Any additional information recorded against the referral which is not accommodated by other elements. This could include additional categorisation of the referral or notes recorded against the referral after it has been made such as details of progress or outcomes.

Elements not in use

The following elements MUST NOT be populated:

definition

Data type: Reference(ActivityDefinition, PlanDefinition)

This is not required by GP Connect.

replaces

Data type: Reference(ReferralRequest)

Terminated referrals are not in scope so cannot be referenced. Any association to a prior, completed referral can be made via the basedOn element.

groupIdentifier

Data type: Identifier

This is not required by GP Connect.

type

Data type: CodeableConcept

This element has not been defined for GP Connect use. The reasonCode element MUST be used for the SNOMED CT coded referral code.

occurrence

Data type: dateTime, Period

reasonReference

Data type: Reference(ProblemHeader-Condition)

A referral may have a linked problem which represents the reason for the referral. This is required information where it exists, but the problem MUST be included and reference to the referralRequest. The referralRequest MUST NOT reference to the problem.

relevantHistory

Data type: Reference(Provenance)



All content is available under the Open Government Licence v3.0, except where otherwise stated