InterweavePatient

FHIR Profile

The Notts Care Record will use the InterweavePatient Resource Profile as published in the Interweave Implementation Guide

Notts Guidance

NB: Whilst the term "Patient" is used by FHIR, the profile is equally relevant to a "citizen", "service user" or "client" in other contexts such as Social Care.

The Notts Care Record will use the PDS Patient as its master, which will be linked to local provider Patients with the same NHS number. The basic patient demographics and other administrative information from individual data providers' Patients will not be visible to users, as such data providers should focus on the Mandatory fields and those Must Support fields that are readily available.

History

The required history for Patient resources will largely depend on the history requirements for the clinical and care data that reference that Patient. As a rule of thumb the required history will be:

  • any 'active' item against the individual, regardless of when it was originally created
  • all completed activities / events from the last 12 months

However, since the local Patient resource is not viewable in the Portal, implementors may choose to maintain all local patients in the platform, if that is easier.

Mandatory fields

Bearing in mind the above principle, the following fields are mandatory:

  1. Resource.id is optional when creating a Resource, however MUST be provided for any update or delete request. See seperate guidance for Resource.id
  2. Meta.profile (all resources MUST detail the FHIR Profile(s) they conform to)
  3. NHS Number (fully traced and verified)
  4. Name ("usual" name, including given and family names, and matching PDS)
  5. Date of Birth (matching PDS)

Must Support fields

The individual data provider demographics are not currently viewable in the Notts Care Record Portal, however the following fields are "Must Support" and should be populated where possible, to support future use cases:

  1. Prefix and suffix for the "usual" name
  2. Gender (male | female | other | unknown)
  3. Active status (see note below)
  4. Telecom (eg phone and/or email details)
  5. Address (eg a current home address - see note below))
  6. Contacts (eg next of kin and/or emergency contact)
    Note: see overlap with RelatedPersons, which might be preferable in many use cases to Patient.contact
  7. Communication preferences - only required if a language other than English is preferred. (Note that CareConnect have defined an extension to be used in preference to the standard FHIR field)

Notes on "active" and "deceased" fields

There are several flags regarding the overall status of a patient, with further guidance on their use as follows:

  • Active - this is a "technical" flag, for example used to indicate if a record was entered in error, or has been merged. It has no bearing on the actual physical state of the patient
    (Suggest Notts Providers soft DELETE inactive Patients).

  • Death Notification Status - this CareConnect extension will not be used. There is a formal process for death notification which is already in place outside of this Care Record. That existing process should be used and not replicated here.
    (Do not use this Extension).

  • Deceased - this flag must NOT be populated by local Data Providers. It will however be populated in the regional Master Patient Index. This MPI is based on PDS and will reflect the deceased status of the patient, as formally recorded by PDS.
    (Do not use Deceased Flag or DateTime - Note Deceased Patient SHALL NOT be deleted, as there may still be a need for a user to search their record).

Notes on Adresses

Adresses should be structured where possible (i.e. Town/City in the address.city Field, however it is acknowledged that this will not be possible for manual addresses. Implementors should therefore choose which local address line is most likely to map to which FHIR Field, e.g. using the same logic as if the address had been entered using a lookup)

Restricted Records

Where a patient record is marked as Restricted on the line of business system it may be necessary to DELETE the associated FHIR Patient Resource and any Resources that reference that Patient.
When the record is subsequently unrestricted, there MUST be a mechanism to recreate the patient and all relevant data

Example Patient

Example Patient Resource: