Schema: Encounter

Introduction

The headings below list the elements of the Encounter profile and describes how to populate and consume them for Consultations.

Important: Any element not specifically listed below will NOT be populated or consumed.

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

Encounter Elements

id

Data type: Id

Optionality: Mandatory

Cardinality: 1..1

The logical identifier of the Encounter profile.

meta.profile

Data type: uri

Optionality: Mandatory

Cardinality: 1..1

The Encounter profile URL.

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

identifier

Data type: Identifier

Optionality: Mandatory

Cardinality: 1..*

This will be populated with a globally unique and persistent identifier

Example payload:

JSON

{
    "system": "https://medicus.health",
    "value": "105298e8-d5d0-11ec-a79f-0a58a9feac02"
}

status

Data type: Code

Optionality: Mandatory

Cardinality: 1..1

Where the consultation record has been finalised on Medicus set to finished.

Where the consultation record has been saved onto Medicus in a draft (or equivalent) status, set to unknown.

Existing vocabulary is driven by use of Encounter for appointment style encounters rather than provision of consultation context. Hence, use the most appropriate value from limited set available.

type

Data type: CodeableConcept

Optionality: Mandatory

Cardinality: 1..1

Carries the consultation type as displayed by the system. This may be a SNOMED CT code or free text.

subject

Data type: Reference(Patient)

Optionality: Mandatory

Cardinality: 1..1

Reference to Patient profile representing the patient against whom the source consultation/encounter was recorded.

participant

Data type: BackboneElement

Optionality: Mandatory

Cardinality: 1..*

This will be populated with the Reference(Practitioner) of the person that recorded the consultation on the system with participant.type value of REC, recorder, from the vocabulary.

Where there are additional participants, will always be populated with at least one participant.individual Reference(Practitioner) with participant.type value of PPRF from the vocabulary. This should reference a Practitioner profile representing the individual with primary attribution for the consultation/encounter (usually the single primary attributed user shown in system journals or other views).

Other participants, such as registrars, trainees or other parties present, may be referenced but with a participation type of PART.

No other values of participation type should be used.

period

Data type: Period

Optionality: Required

Cardinality: 0..1

If recorded, period.start is mandatory and should be populated with the date and time the consultation started.

period.end should be populated where the encounter end date and time is known or calculated and populated where the duration is known.

The audit trail date time of the consultation is carried by the associated consultation list via List.date.

The period attribute may be omitted where the effective/clinical date for the consultation on the source system is not recorded (for example, an unknown date and time).

length

Data type: Duration

Optionality: Required

Cardinality: 0..1

Specifies the length of the consultation. Should be calculated and populated where an end time for the consultation is known.

location

Data type: Reference(Location)

Optionality: Required

Cardinality: 0..*

References an instance of the Location profile that provides more detail on where the consultation/encounter took place - for example, branch surgery.

location.status and location.period are not used.

serviceProvider

Data type: Reference(Organization)

Optionality: Required

Cardinality: 0..1

Reference to the responsible organisation for the consultation/encounter.