Schema: Diary Entry

Introduction

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

Diary Entries

When Medicus returns a diary entry it will supply all the diary entry data.

The response to the query includes:

• A List profile containing references to ProcedureRequest for every Diary Entry that met the search criteria

• A List profile containing references to each ProblemHeader that is contained in the bundle

For each ProcedureRequest referenced in the List profile:

• The ProcedureRequest profile of the Diary Entry

• The ProblemHeader (Condition) profiles of any directly linked Problems

• All administrative profiles referenced directly (or via another administrative profile) by any of the clinical profiles included above

  • Include Patient, Organization, PractitionerRole, Practitioner and Location

Diary Entry (ProcedureRequest) Elements

id

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

meta.profile

The Diary Entry (ProcedureRequest) profile URL.

Fixed value profile

identifier

This will be populated with a globally unique and persistent identifier (that is, it doesn’t change between requests and therefore stored with the source data).

status

Medicus will only include incomplete diary entries - that is, complete or cancelled will not be included.

The status will only be active.

intent

The intent will only be plan.

code

The planned event, action or activity.

subject

The patient the diary entry relates to.

context

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

occurence

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

authoredOn

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

requester

The person or system who entered the diary entry into Medicus.

requester.agent

This will be the practitioner who entered the diary entry in Medicus, 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 will be a Device representing the providing system or an Organization representing the GP practice responsible for creating the record.

reasonCode

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

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

note

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.