Search loading...


Explore and Make use of Nationally Defined Messaging APIs


Diary entry

Guidance for populating and consuming the Diary Entry profile


The headings below list the elements of the Diary Entry (ProcedureRequest) profile and describe how to populate and consume them.

Diary Entry (ProcedureRequest) elements


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

The logical identifier of the Diary Entry (ProcedureRequest) profile.


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

The Diary Entry (ProcedureRequest) profile URL.

Fixed value profile


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.


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

The provider MUST only include incomplete diary entries - that is, complete or cancelled MUST NOT be included.

The status MUST only be active.


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

The intent MUST only be plan.


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

The planned event, action or activity.


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

The patient the diary entry relates to.


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

A reference to the consultation from which the diary entry originates - that is, the consultation which the diary entry was created within.


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

The date or date range when the diary entry is planned to occur.


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

The date the diary entry was entered into the original source system. This may be the audit or equivalent created date for the diary entry.


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

The person or system who entered the diary entry into the original source system.


Data type: Reference(Practitioner | Organization | Device) Optionality: Mandatory Cardinality: 1..1

This MUST be the practitioner who entered the diary entry in the original source system, if it was entered by a user. If the diary entry was system generated and it is not possible to meaningfully associate the diary entry to a system user then this MUST be a Device representing the providing system or an Organization representing the GP practice responsible for creating the record.


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

The reason the action recorded in the diary entry is needed. This is the trigger reason for the diary entry not the action of the diary entry.


Data type: Reference(Observation) Optionality: Optional Cardinality: 0..*

Additional clinical information linked to the diary entry MAY be included, except a linked problem which MUST be included in the bundle as a ProblemHeader(Condition) which references the diary entry, not vice versa.


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

Free text narrative to describe the reason for the diary entry or the action / activity required by the diary entry. This is for additional content beyond the code and reasonCode coded elements and is not intended to duplicate the content of those elements.

ProcedureRequest elements not in use

The following elements MUST NOT be populated:


Data type: Code


Data type: Boolean


Data type: CodeableConcept


Data type: Boolean | CodeableConcept


Data type: Reference(Organization)


Data type: CodeableConcept


Data type: Reference(Device | RelatedPerson | Patient | Organization | Practitioner | HealthService)


Data type: Reference(Observation | Condition)

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


Data type: Reference(Specimen)


Data type: CodeableConcept


Data type: Reference(Provenance)

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