Reasonable Adjustments

This page shows the functional use cases provided by the Reasonable Adjustments implementation within the PatientFlag API:

  • Retrieve a set of top-level Flags (just the Flags with no associated resources)
  • Retrieve a specific Reasonable Adjustment Flag with associated resources
  • Add a top-level Reasonable Adjustment Flag
  • Add a top-level Flag (and associated Adjustment, Impairment or Condition resources)
  • Add/remove associated resources (with the dependency that a top-level flag must already be added/removed)
  • Remove a top-level Flag (which will remove all associated resources)

Retrieve PatientFlags

Overview

For high level requirements, see Home.

This use case operates as per Retrieve PatientFlags

Retrieve a Reasonable Adjustment PatientFlag with associated resources

Overview

For high level requirements, see Home.

Use Case

A Reasonable Adjustment Record may be retrieved if it exists. It will be possible to determine that adjustment flags exist by searching for a England Flag Patient Flag with:

System Interaction

Queries

Using FHIR search capabilities, it is possible to retrieve the reasonable adjustment records in several ways.

This section describes how to query from the Flag endpoint using FHIR search and patient and code search parameters.

GET [baseUrl]/Flag?patient=9449306753&code=national-reasonable-adjustment-flag

This will return all associated flag resources for Reasonable Adjustments for a given patient.

e.g.

GET [baseUrl]/Flag?patient=9449306753&code=national-reasonable-adjustment-flag

This limits the search to patients that have the identifier 9912003888

identifier=9912003888

This limits the search to Flag resources linked via patient and have the code national-reasonable-adjustment-flag, and also includes the resource in the returned searchset Bundle.

Resources returned will conform to:

This query relies on the Flag patient and England FlagCode search parameters.


Add a Reasonable Adjustment PatientFlag

Overview

For high level requirements, see Home.

Use Case

After consultation with a patient, a Reasonable Adjustment Record may be created. This consists of a Flag resource containing an adjustment; a Condition resource may also optionally be created to record the details of an impairment or an underlying condition.

If a Reasonable Adjustment Record exists, a Flag resource designated as the patient flag must be created to indicate that there are reasonable adjustments recorded for the patient. There is a single instance of this type of resource per patient.

System Interactions

The practitioner decides to record a Reasonable Adjustment Record.

This is done with a call to the required individual /Flag endpoint

This can be done also be done as part of a single transaction Bundle along with other Flag and associated resources For which see

Command 'pagelink' could not render: Page not found.
. A transaction Bundle can help with data integrity requirements and also help to reduce required http calls.

Queries

Using FHIR create capabilities, it is possible to create/write the Reasonable Adjustment record to the Patient Flag API.

Flag endpoint write

Reasonable Adjustment records are created by POSTing the resource, conformant to England Flag Patient Flag to the relevant /Flag resource type endpoint.

POST [baseURL]/Flag

Examples

The following set of examples constitute the individual associated resources with the initial addition of a flag for Reasonable Adjustment. This includes a patient Flag resource, the adjustment Flag resource and the associated Condition resource. All resources have contained provenances.

A transaction Bundle is also given that allows these resources (plus the patient) to be entered in an atomic traction. It uses PUTs, where in the case of an initial update, it may be done as a conditional update

The following set of examples are for the same patient, and constitute an addition flag and condition. The transaction Bundle here illustrates an idempotent update by simply adding the new resources to the first transaction Bundle.


Add a Reasonable Adjustment PatientFlag and associated resources

Overview

For high level requirements, see Home.

Use Case

After consultation with a patient, a Reasonable Adjustment Record may be created. This consists of a Flag resource containing an adjustment; a Condition resource or resources may also optionally be created to record the details of an impairment or an underlying condition.

If a Reasonable Adjustment Record exists, a Flag resource designated as the patient flag must be created to indicate that there are reasonable adjustments recorded for the patient. There is a single instance of this type of resource per patient.

System Interactions

The practitioner decides to record a Reasonable Adjustment Flag, an Adjustment, and an U condition. This could be done with individual calls to the required endpoints, or can be done in a single transaction Bundle. A transaction Bundle can help with data integrity requirements and also help to reduce required http calls.

Examples

The following set of examples constitute the individual associated resources with the initial addition of a flag for Reasonable Adjustment. This includes a patient Flag resource, the adjustment Flag resource and the associated Condition resource. All resources have contained provenances.

A transaction Bundle is also given that allows these resources (plus the patient) to be entered in an atomic traction. It uses PUTs, where in the case of an initial update, it may be done as a conditional update

The following set of examples are for the same patient, and constitute an addition flag and condition. The transaction Bundle here illustrates an idempotent update by simply adding the new resources to the first transaction Bundle.


Add associated resources

Overview

For high level requirements, see Home.

Adjustments

Adjustments are used to represent individual reasonable adjustments. Adjustments SHOULD be recorded in Flag.code as a code selected from the SNOMED CT valueset [https://fhir.nhs.uk/England/ValueSet/England-FlagCodeRA] (https://fhir.nhs.uk/England/ValueSet/England-FlagCodeRA)

Impairments

A Reasonable Adjustment Flag record MAY (optionally) contain further Condition resources detailing additional Impairments details These SHALL be recorded as Condition resources with .code set to a code value from CodeSystem CodeSystem/England-ConditionCodeRA

Underlying Conditions

A Reasonable Adjustment Flag record MAY (optionally) also contain further Condition resources detailing Underlying Conditions that are relevant to provision of reasonable adjustments to care These SHALL be recorded as Condition resources with .code set to the relevant SNOMED CT concept

Add Use Cases

System Interactions

The practitioner decides to record additional detail to support or enrich the Reasonable Adjustment Flag record

This could be done with individual calls to the required endpoints, or can be done in a single transaction Bundle. A transaction Bundle can help with data integrity requirements and also help to reduce required http calls.

Add Adjustment

Add Impairment/Underlying Condition

Queries

Using FHIR create capabilities, it is possible to create/write the Additional Detail resource, adding it to the Patient Flag record.

Flag endpoint write

Following the standard ReST pattern POST [baseURL]/[resourceType] for create operations, to:

Add Adjustment

Use POST [baseURL]/Flag with query payload a Flag resource conformant with profile England Flag Patient Flag Adjustment

Add Impairment/Underlying Condition

Use POST [baseURL]/Flag with query payload a Flag resource conformant with profile England Condition Flag


Remove associated resources

Overview

For high level requirements, see Home.

Remove Use Cases

System Interactions

The practitioner decides to remove additional detail supporting or enriching the Reasonable Adjustment Flag record

This could be done with individual calls to the required endpoints, or can be done in a single transaction Bundle. A transaction Bundle can help with data integrity requirements and also help to reduce required http calls.

Remove Adjustment

Remove Impairment/Underlying Condition

Queries

Using FHIR delete capabilities, it is possible to delete the Additional Detail resource, removing it from the Patient Flag record.

Flag endpoint write

Following the standard ReST pattern DELETE [baseURL]/[resourceType] for create operations, to:

Remove Adjustment

Use DELETE [baseURL]/Flag/[FlagID] Provide a Removal reason string as header: x-removal: [removalReason]

Remove Impairment/Underlying Condition

Use DELETE [baseURL]/Condition/[FlagID] Provide a Removal reason string as header: x-removal: [removalReason]


Remove a Reasonable Adjustment PatientFlag

Overview

For high level requirements, see Home.

Use Case

System Interactions

In the following sequence diagram, a patient and/or practitioner decide to remove the Reasonable Adjustment patient flag and all suppporting resources (either Adjustments, Impairments or Underlying Conditions).

Queries

Using FHIR conditional delete capabilities, it is possible to delete the entire Reasonable Adjustment Flag record for a given patient.

Flag endpoint write

Following the standard FHIR conditional delete ReST pattern DELETE [baseURL]/[resourceType] for delete operations, to:

Remove entire Reasonable Adjustment record

Use DELETE [baseURL]/Flag?[searchParameters] Include searchParameters:

  • 'patient' - [patientNHSNumber]
  • 'code' - [patientFlagCode] Provide a Removal reason string as header: x-removal: [removalReason]

The following resource types will be deleted from the record:

This query relies on the Flag patient and England FlagCode search parameters.

Example

Multiple resources can be deleted using a transaction bundle. This RemoveRARecord-Bundle-Example: