InterweaveEncounter

FHIR Profile

Notts Guidance

Encounter is arguably the most complex Resource that will need to be implemented in Phase 1 of the Notts Care Record, it will be used to represent multiple scenarios, including:

• 111 Call and Ambulance/Paramedic incidents
• Outpatient Visit
• Attendance at Accident & Emergency
• Inpatient Stay
• Presence on a Virtual Ward
• Group other Encounters related to a contiguous time period (TBD)

The diagram below highlights these different scenarios and possible groupings

Note: Decision required in Notts whether to Use Encounter Groupings in Phase 1

The detailed guidance for encounters is provided in the Interweave Implementation Guide, however the key considerations for Notts are summarised in the sections below

Encounter Start/End

Whilst there is an intuitive understanding of what constitutes the start / end of an Encounter, it is challenging to establish a rigorous definition. Nevertheless, the following guidelines should be used:

• An Encounter covers a period of continuous care

• A change in care-setting constitutes a change of Encounter. (This would include moving from Emergency to Inpatient, and/or Inpatient to Virtual Ward within a hospital – as indicated by the “class”)

• A change in location within the same care setting does NOT constitute a change of Encounter. (For example moving between beds and/or wards within a hospital inpatient stay. This would instead be modelled using the “location” sub-structure of the Encounter)

• A change in diagnosis (i.e. Chief Complaint) within the same care setting does NOT constitute a change of Encounter.

Mandatory fields

A significant set of mandatory fields are defined in order to properly describe an Encounter:

1. Status - this is already mandatory in FHIR. Use of "planned" is discouraged - Appointment will be used instead for these.

2. Class - this provides a categorisation, ie Emergency, Inpatient, Ambulatory. This should always be known, and vital for meaningful display purposes. A custom code list has been created, which replicates the standard list provided by Care Connect, and adds a codes to identify an "Encounter Grouping", and various types of ambulance/emergency service encounters. However it also enables the possibility of extending the list to cover a wider range of care settings if this is found to be necessary (please get in touch).

3. Subject - every encounter must be linked to a Patient (not a Group)

4. Participant - it is required to include EXACTLY ONE practitioner who has the "type" of "Primary Performer". This should be the main person responsible - someone who it would be useful to contact if further information is desired. (If this person changed during the course of the encounter then please pick just ONE to finally hold this key role, and demote the others to "participant")

   Also included in the list of participants might be:

   • Admitter and Discharger - should be included if known/relevant and different to the Primary Performer
   • Participant - FHIR offers a wealth of other participant type codes, however it is suggested that simply classifying others as "participant" is likely to be adequate in most cases.

   Participants can be given a "period" and this is optional. For regional sharing the most important thing is to see who has been involved with the patient, rather than to construct a forensic timeline of involvements. However this information might be useful in the case of a long Encounter with many brief involvements, and so may be provided if desired.

5. Period When the encounter occurred is vital to know. The start date/time is always mandatory, but as per the FHIR specification, the end date/time may be omitted if the encounter is ongoing

Must Support fields

In addition the following fields are "Must Support" - ie they must be populated if relevant and known. These largely relate to providing additional "clinical" detail about the Encounter - including links to related FHIR Resources such as the originating Appointment, the Condition, etc. These build up the rich dataset around an Encounter and are important to provide, but may not yet be available for an initial Encounter implementation.

1. Identifier - a Local Id should be provided, such that could be quoted if manually getting in touch to find out more

2. Type - categorises the type of place where the encounter took place. CareConnect modifies FHIR by providing a much more relevant list covering:

   • Indirect encounters - eg phone, video, letter, etc
   • In an establishment - a short list of top-level codes which cover a good range of care settings eg "Seen in clinic", "Seen in own home", "Seen in supervised accommodation", etc.
   • On the street

   NB: The code for "Seen in Clinic" offers the ability to drill down into a long list of specific clinic types. However this overlaps to some extent with the purpose of the "Service Type" field - so it is sufficient here to populate simply "Seen in Clinic".

3. Service Type (Extension) - this is perhaps one of the most important and useful fields about an Encounter as it describes the type of service - ie what the Encounter was "for".

   However this field is missing in FHIR STU3! This is corrected in FHIR R4, and so we pre-adopt it here as an extension.

   We also pre-adopt the UKCore value set (based on SNOMED refset 1127531000000102: Services Simple Reference Set), which is more relevant than the default FHIR example and also covers social care

4. Priority: This provides useful information about whether it was emergency, routine, elective, etc

5. Location - the location provides essential information about where the encounter took place. Exactly what is appropriate here will depend on the care setting:

   • For a hospital information should be provided down to the “ward” level. Thus enabling a visitor to find the patient, as well as potentially giving some insight into the type of treatment being provided.
   • For other (smaller) locations then the "site" level may be sufficient
   • Other types of care (eg community, emergency) may take place at home or in a vehicle

   It is useful to understand the history of where the patient has been seen, so the status and period MUST be populated, and a history SHOULD be provided. (As noted above, a change of location does not in itself constitute a new Encounter, simply append to this list).

6. Appointment: Link to the originating Appointment, if relevant

7. Reason: A long list of SNOMED codes to describe different reasons which may have led to the Encounter. (Note that this may duplicate to some extent information provided in a linked Appointment and/or Referral, but is seen as useful to pull through onto the Encounter itself also).

   We pre-adopt the value set used in R4. This builds on the existing STU3 list covering SNOMED codes for "Clinical Finding" and "Procedure", and adds codes for "Context-dependent categories" (Social Care) and "Events" (A&E)

8. Diagnosis: Link to a Condition diagnosed as a result of the Encounter. Can obviously be provided only if the Condition FHIR Resource is also being offered. If populated then it is required to rank the Conditions, and to assign one the "role" of "Chief Complaint"

9. Outcome fields: Care Connect defines three extension fields which cover aspects of the encounter outcome:

   • Outcome of Attendance - relevant to outpatient encounters
   • Emergency Care Discharge Status - relevant to emergency encounters
   • Discharge Method - found in the "hospitalization", and relevant to inpatient encounters

   These provide valuable information which is important to populate. However it is expected that only one of the three will be populated, as relevant for the type of encounter

10. Hospitalization: To provide details of admission and discharge, this might be populated fully, partially, or not at all - see section below for further details of the fields contained

11. Status History - this is seen as important - to understand the timeline of the Encounter. For example - if an HL7 message triggering an update has status that maps to finished but the current FHIR Encounter has status of in-progress, the update should end the previous statusHistory with the relevant dateTime and add a new one with the current status, starting with the same time.

The following sections provides further guidance for the difference classifications of Encounter:

Outpatient Visit

• Class - for regular Outpatient Visits will be 'AMB' - ambulatory, however see note below for home visits and phone calls/video chats.

• Type - will be a child of http://snomed.info/sct|308467007 - Seen in establishment (finding). Where no obvious mapping, suggest use http://snomed.info/sct|308021002 - Seen in clinic (finding).

• Service Type (Extension) - see ValueSet for Interweave-UkCoreCareSettingType

• Appointment - reference to the FHIR Appointment that that scheduled the visit

• Hospitalization - suggest not used for Outpatient Encounters

• Outcome of Attendance - See ValueSet CareConnect-OutcomeOfAttendance-1. Will be one of:

  1. Discharged from Consultant's care (last attendance)
  2. Another Appointment given
  3. Appointment to be made at a later date

Click here to see an example of an Outpatient Visit

Note: Some settings (e.g. Mental and Community Health) will also have Appointments and Encounters for home visits or phone calls/video chats, although these will follow the same basic model as actual Outpatient Visits, however the Encounter will have a different Class to identify that it took place outside a healthcare facility, e.g. HH - home health, or VR - virtual

Attendance in Accident & Emergency

• Class - for A&E Attendances will be 'EMER'

• Type - suggest default to http://snomed.info/sct|185210004 - Seen in hospital casualty (finding) where class='EMER'

• Service Type (Extension) - suggest default tohttp://snomed.info/sct|310000008 - Accident and Emergency service (qualifier value) where class='EMER'

• Emergency Care Discharge Status (Extension) - see ValueSet for CareConnect-EmergencyCareDischargeStatus-1. Common codes will include http://snomed.info/sct|1324201000000100 - Streamed from emergency department to inpatient unit following initial assessment (situation) and http://snomed.info/sct|182992009 - Treatment completed (situation)

• Priority - suggest default to http://hl7.org/fhir/v3/ActPriority|EM - emergency where class='EMER'

• Appointment - suggest not used for Emergency Encounters, unless business need to link back to a booking from 111 service

• Hospitalization

  • Admission Method - see ValueSet for CareConnect-AdmissionMethod-1. Code 21 'Accident and emergency or dental casualty department of the Health Care Provider' will be used in many cases
  • Origin - Information about the location which the patient arrived from (if relevant / known)
    • Required at the “site” level if arriving from another institution
    • Optional if arriving from a residential address
  • Admit Source - Useful information about the type of place the patient came from (eg home, other NHS hospital, care home, etc) - see ValueSet CareConnect-SourceOfAdmission-1

Click here to see an example of an A&E Attendance

Inpatient Stay

• Class - The following codes can be used for Impatient Stays
  • ACUTE - An acute inpatient encounter
  • NONAC - Any category of inpatient encounter except 'acute'
  • IMP - Generic inpatient classification ... to be used where unknown if acute or not
• Type - will be a child of http://snomed.info/sct|308467007 - Seen in establishment (finding). Where no obvious mapping, suggest use http://snomed.info/sct|185212007 - Seen in hospital ward (finding).
• Service Type (Extension) - see ValueSet for Interweave-UkCoreCareSettingType
• Appointment - might be relevant for elective admissions, which are booked in in advance
• Hospitalization
  • Admission Method - Not required where there is a preceding A&E Attendance Encounter. For Elective/Routine Inpatient Stays, the requirements will be as per those with class = 'EMER'
  • Origin - As above
  • Admit Source - As above
  • Discharge Method - See ValueSet CareConnect-DischargeMethod-1). Will usually be expected for a 'finished' Inpatient Encounter.

    Note: Still need to model 'discharge' when the patient is transferred to a Virtual Ward - i.e. which aspects relate to when the patient physically leaves the hospital location, and which when they leave the care of the trust

  • Destination - Information about the location which the patient is discharged to (if relevant / known)
    • Required at the “site” level if discharged to another institution
    • Optional if discharged to a residential address
  • Discharge Disposition - Useful information about the type of place the patient has been discharged to (eg home, other NHS hospital, care home, etc). See ValueSet Interweave-DischargeDestination-1)
  • Medically Safe For Discharge - This is a key Extension for Discharge Planning / Capacity and Flow work, as such is not required for initial load of historic Encounters, but SHOULD be populated for Inpatient Stays going forward.
    • Status: Medically safe for discharge status. ready | notready | unknown
    • Predicted Date: The date when it is predicted the patient will be medically safe for discharge (i.e. PDMST)
    • Actual Date: The date when the patient was actually medically safe for discharge. Should only be populated when status=ready. Where the patient's status changes back to not ready, the actual date should be removed.

    Note: with medically safe for discharge, 'Discharge' refers to safe to leave the hospital, not the care of the trust, hence includes when safe to transfer to a Virtual Ward

Click here to see an example of an Open/Current Inpatient Stay

Click here to see an example of a Closed Inpatient Stay

Virtual Ward

Hospitalization Structure

Within the Encounter sits the "Hospitalization" structure. This structure provides information about the admission and discharge. Therefore it is particularly important for a regional shared record - as this defines the touchpoints with other care providers.

Fields in the Hospitalization structure are as follows:

• Must Support

  • Admission Method - this CareConnect extension provides a useful list of codes about the method of admission (eg Planned, A&E, transfer, etc)
  • Discharge Method - this CareConnect extension provides a useful list of codes about the method of discharge relevant to an inpatient stay (eg clinical discharge, self-discharge, deceased, etc). It is one of three alternatives for providing outcome information, depending on the type of encounter - see above under the main encounter "must support" heading for further details.
  • Origin - Information about the location which the patient arrived from (if relevant / known)
    • Required at the “site” level if arriving from another institution
    • Optional if arriving from a residential address
  • Admit Source - Useful information about the type of place the patient came from (eg home, other NHS hospital, care home, etc)
  • Destination - Information about the location which the patient is discharged to (if relevant / known)
    • Required at the “site” level if discharged to another institution
    • Optional if discharged to a residential address
  • Discharge Disposition - Useful information about the type of place the patient has been discharged to (eg home, other NHS hospital, care home, etc)). (We use a value set which updates that provided by CareConnect with the latest improved list from the NHS Data Dictionary)
  • Medically Safe For Discharge - This extension has been added to capture important information to assist with discharge planning and analysis. It contains a status code (ready, not ready, or unknown), plus the predicted and actual date when the patient is medically safe for discharge.

  Note that Origin and Destination are likely to be external locations - please refer to guidance on the Location profile about use of References. For example the use of a Contained Resource may be appropriate.

• Optional

  • Readmission - flag may be provided if known and relevant

• Discouraged

  • Diet Preferences, Special Courtesy, Special Arrangement - additional details that are relevant internally for planning the patient's stay, but not so relevant for external sharing.