GP Connect - Access Record Structured

What is a consultation?

For GP Connect, a consultation is the structure within which source systems group one or more clinical record entries which occurred at the same time and for the same or similar purpose attributed to or asserted by the same actor.

• the provider system determines under what circumstances to create a consultation - this may vary between provider systems
• consultations do not exclusively represent clinician-patient encounters, although they are commonly used for that purpose
• consultations may record purely administrative or communications triggered events on source systems (for example, repeat medication administration, a pathology report filed into the patient record via messaging workflow)
• consultations are generally assigned and attributed to what can loosely be termed a Date / Doctor / Place / Type (Encounter), although these attributes may be overridden or refined in the context of individual record entries within the consultation
• consultations may or may not have associated structure (for example, the ability to decompose a - consultation into multiple topics / subjects / problems and within each "topic" further group clinical content under headings (SOAP headings) in line with long standing clinical note taking practice)
• consultations may also be recorded in non-structured form - that is, a grouping of clinical record entries under the same Date / Doctor / Place / Type but without additional structure (topics or SOAP headings)
• consultations may incorporate a range of different record entries (for example, measurements, test results, textual narrative, structured narrative, coded observations, medications)

Logical structure

Consultations follow a common logical structure:

Context

• Each consultation has context data that describes when and where the consultation took place, the patient it covered, and who else was involved (such as a doctor). This information is usually generated automatically by the provider system but it may include some manually recorded values.

Topics

• A Consultation will be split into one of more topics. Each topic describes an area of discussion (or activity) that took place in the Consultation.
• A topic may (or may not) have a title.
• A topic may (or may not) be related to a specific problem in the patient’s record. In these cases, all the discussions and activities recorded under that topic are in regard to that problem.

Headings

• A topic may be split into one of more headings (sometimes referred to as SOAP headings). Each heading covers a specific part of the Consultation process about that topic.

• There is no national standard for headings so they will reflect the headings available in the provider clinical system.

Clinical items

• Within each heading there may be one or more clinical items. Grouped together and in order, these clinical items describe in full all the details recorded under that heading of the consultation.

• Any type of clinical item may form part of the consultation (medications, allergies, immunisations, uncategorised data, and so on).

Topics without headings

• A topic can be created without headings. In these cases, the clinical items are recorded directly under the topic the same way they are recording under a heading.

Approach

The logical structure of a Consultation is reflected in FHIR using the Encounter and List profiles.

Consultation structure

Consultation notes

Consultation notes are the human readable version of the clinical information recorded under each heading. They may or may not be accompanied by a clinically coded version of the information. Where text is entered freely into a consultation without being associated with a clinical code it will be returned in an Observation with the SNOMED code 37331000000100 Comment note

There are two primary ways that consultation notes are recorded on native GP systems:

Model #1

Consultation notes for a heading are recorded as a single piece of free text. Any clinical coded information under the same heading is associated to that text as a whole.

Model 2

Consultation notes for a heading are recorded as a collection of observations, each with a clinical code and or text. When read together in order they produce the consultation notes.

When refelcting these in FHIR, it is important that these two methods are represented in a way that:

• retains the structural information they contain
• does not create any unintended clinical meaning
• can be viewed / imported

This is done by taking any free-text in model one, and representing it as uncategorised data, and positioning it as the first clinical item under the heading.

While there are differences between the two outputs, the consultation notes can be derived from both by reading through each clinical item in order and merging the Term Text, Clinical Code, Values and Comment into a single narrative.

Example illustration

Clinical item references

Clinical items linked to a consultation, contain a reference to a FHIR resource, which is held in the entry.item field in the apporpriate CareConnect-GPC-List-1 resource.

• A planned prescription with a medication or medical device can be represented with the CareConnect-GPC-MedicationRequest-1 profile, with the intent element, containing the value of plan
• An issued prescription with a medication or medical device can be represented with the CareConnect-GPC-MedicationRequest-1 profile, with the intent element, containing the value of order
• An allergy can be represented with the CareConnect-AllergyIntolerance-1 profile
• An immunisation can be referenced with the CareConnect-GPC-Immunization-1 profile
• Uncategorised data can be represented with the CareConnect-GPC-Observation-1 profile
• A referral can be represented with the CareConnect-GPC-ReferralRequest-1 profile
• A document can be represented with the CareConnect-GPC-DocumentReference-1 profile
• An investigation can be represented with the CareConnect-GPC-DiagnosticReport-1 profile
• A diary entry can be represented with the CareConnect-GPC-ProcedureRequest-1 profile

Coded clinical items returned as text

The provider MUST return the following items as text, where they are contained in returned consultations, as they are not covered by the clinical areas defined in this specification version

• Completed diary entries
• Test requests (which are not in scope of investigations)

These must be returned in an CareConnect-GPC-Observation-1 profile in the same manner as a comment note and as defined in the uncategorised data profile. The returned resource must represent the full text as presented in the GP system, including notes and qualifiers, not just the code description.

Consultations containing unsupported clinical items

Depending on the GP Connect version supported by the provider system it can be possible for the consultation to link to a clinical item that the provider system is not yet able to export with GP Connect. For example, if the consultation contains a link to a referral record, but the provider system does not yet support exporting referrals.

Where a provider system is not able to export a linked clinical item, it will create a section.section.entry (or section.entry) entry with the:

• List.entry.item.display with the value of "[Clinical area] items are not supported by the provider system."

    Where [Clinical area] identifies the type of the clinical item that is not supported.
  

The example below shows references to two items, one for an observation, and the other for referrals that aren't supported by the provider system.

<List>
    ...
    <section>
        <entry>
            <item>
                <reference value="observation-99asd2" />
            </item>
            <item>
                <display value="Referral items are not supported by the provider system" />
            </item>
        </entry>
    </section>
</List>

{
  "item": {
    "reference": "Observation/6734572634"
  }
},
{
  "item": {
    "display": "Referral items are not supported by the provider system"
  }
}

Consultations containing confidential items

A consultation which is marked as confidential will (as per the structured requirements on confidentially) not be included in the returned data, and the Confidential Items warning message will be included in the primary List containing the query response.

If a consultation is not marked as confidential, but includes items that are marked as confidential or are considered sensitive, the following information is returned:

• the consultation will be included in the response as normal
• the confidential item(s) will NOT be included in the response
• there will be NO reference to the confidential item(s) in the List profiles defining the consultation structure
• the Confidential Items warning message will be included in the appropriate secondary list (Using secondary lists to respond to queries for consultations and problems) for the relevant type of type data that was omitted (for example, if a piece of uncategorised data was excluded as it was confidential then the warning code would be in the List "Consultations - uncategorised data contained in consultations" that was returned as part of the query) - the warning will NOT be included in the List profiles defining the consultation structure

In effect, there will be a warning message that items were excluded from the response due to confidentiality but there will be no indication from which consultation(s) they were removed from.

Draft consultations

In some GP practice clinical systems, it is possible for the clinician to save a consultation record in a draft (or equivalent) status.

Consultations in this draft status MUST be included in the response. Encounter.status is used to identify them as draft.

Suppression of empty consultations, topics and headings

On some systems all or almost all record entry is captured in the context of a consultation. This, coupled with default behaviours such as starting a consultation on opening a patient record, leads to the phenomenon of ‘empty’ consultations where the Data / Doctor / Place / Type has been created as a default but there is no subsequent entry of any clinical information within the consultation.

Provider systems which allow empty consultations should not return empty consultations in response to consultation queries.

The same approach is followed for empty topic and heading levels recorded at source - that is, these should be suppressed by the producer.

What information may be recorded outside of consultations

• some systems do not restrict entry of clinical data to a consultation context - that is, it is possible to record clinical information about a patient without starting or initiating a consultation
• such "Non-Consultation" behaviour does not imply any loss of information or structure by the source system - that is, the record items are still fully recorded and attributed
• however, since they are recorded outside of a consultation context, they will not be returned by an API query directed at returning consultation resources (see the "Design decisions" section below)

Consumer (receiver) guidance

Although the expression of full consultation structure is provided by the specified protocols, it is recognised that many consumers simply want access to the resources referenced by the consultations rather than the topic or SOAP heading structures.

Consumers (receivers) in the category may simply flatten the consultation structure or otherwise extract the resources referenced within the List resources carrying the consultation structure

Consumer (receiver) cautions

• A consumer making consultation-oriented queries only MUST NOT expect to obtain all items in the patient record
• Other GP Connect APIs will provide full access to items in the patient record including all medications, all allergies, all problems up to and including get whole record queries

Design decisions

Systems which allow direct recording of data outside of consultation contexts should not fabricate consultations to return such data when consultation queries are received.

To do so would be generating information and structure which does not exist on the source system, and which would obscure the genuine consultation content that does exist.

Systems that fall in this category have clear distinctions between consultations and other types of record content (for example, last x consultations displayed in patient summaries and to synthesise consultations would distort this native behaviour).

Using the List resource for consultation queries

The results of a query for consultation details MUST return a List containing references to all the Encounter resources which represent each consultation that is returned.

The List MUST be populated in line with the guidance on List resources.

If the List is empty, then it MUST be returned where the emptyReason.code has the value of no-content-recorded, and the List.note element MUST be populated with the text "Information not available".

<List>
    <emptyReason>
        <coding>
            <system value="https://fhir.nhs.uk/STU3/CodeSystem/CareConnect-ListEmptyReasonCode-1" />
            <code value="no-content-recorded" />
            <display value="No Content Recorded" />
        </coding>
    </emptyReason>
</List>