1 Operations
Operations are the set of business activities a user needs to collect, consider and curate Reasonable Adjustments information on behalf of a patient. Users access this functionality through a Reasonable Adjustments client system.
These aren’t technically part of the API. Strictly, they are Client system functional requirements. Here they are used to illustrate/assure that the Interactions (which are part of the API) cover the functional scope of the Reasonable Adjustments system.
Reasonable Adjustments requires the ability to:
- Add Consent
- Add an Adjustment
-
Add an Impairment
- View Consent
- View Adjustments
-
View Conditions
- Remove Consent
- Remove an Adjustment
-
Remove an Impairment
- Remove Flag
-
Determine Provenance
2 Interactions
Interactions are the http request-response exchanges between client and server which are used to fulfil the operations above.
There isn’t a 1 to 1 correspondence to the operations, as for example, ‘Add an Impairment’ requires ‘Create Condition’ and either ‘Create List’ or ‘Update List’ Interactions, ‘Determine Provenance’ isn’t an http interaction at all.
- Create Consent
- Create Flag
- Create Condition
-
Create List
All use the Create Resource pattern
Condition and List must also consider the Create Condition resources pattern
- Read Consent
- Read Adjustments
- Read Conditions
-
Read List
Consent and Adjustments use the Read Resource pattern
List and then Condition use Read List followed by Read Conditions pattern
-
Update List
Update List is used when Creating or Deleting Conditions from an existing List
- Delete Consent
- Delete Flag
- Delete Condition
-
Delete List
All use the Delete Resource pattern
Condition and List must also consider the Delete Condition resources pattern
Interactions are described using Sequence Diagrams in the sections below.
The Remove Flag and Determine Provenance Operations are also discussed.
Interactions and Operations are further illustrated in the Use Cases & Examples section.
