Diary entry

Guidance for populating and consuming the Diary Entry profile

Introduction

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

Important: Any element not specifically listed below MUST NOT be populated or consumed. A full list of elements not used is available here.

Tip: You’ll find it helpful to read it in conjunction with the underlying ProcedureRequest profile definition.

Diary Entry (ProcedureRequest) elements

id

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

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

meta.profile

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

The Diary Entry (ProcedureRequest) profile URL.

Fixed value profile

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.

status

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.

intent

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

The intent MUST only be plan.

code

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

The planned event, action or activity.

subject

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

The patient the diary entry relates to.

context

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.

occurence

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

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

authoredOn

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.

requester

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

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

requester.agent

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.

reasonCode

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.

supportingInfo

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.

note

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:

priority

Data type: Code

doNotPerform

Data type: Boolean

asNeeded

Data type: Boolean | CodeableConcept

requester.onBehalfOf

Data type: Reference(Organization)

performerType

Data type: CodeableConcept

performer

reasonReference

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.

specimen

Data type: Reference(Specimen)

bodySite