-
Notifications
You must be signed in to change notification settings - Fork 4
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
9497dce
commit 0fa5337
Showing
10 changed files
with
345 additions
and
41 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,117 @@ | ||
| ### Overview | ||
|
|
||
| For high level requirements, see [Key purposes of the FGM Flag](index.html#fgm-key-purposes) | ||
|
|
||
| ### Usecase | ||
|
|
||
| <div style="text-align: left;"> | ||
|
|
||
| {%include add-fgm-record-usecase.svg%} | ||
|
|
||
| </div> | ||
|
|
||
| #### Scenarios | ||
|
|
||
| ```gherkin | ||
| Given a practitioner has received consent from a patient | ||
| And the consent is for reasonable adjustments | ||
| When a practioner adds an adjustment flag | ||
| Then an additional flag designated as a patient flag will be created | ||
| Given a practitioner has received consent from a patient | ||
| And the consent is for reasonable adjustments | ||
| When a practioner adds an patient flag | ||
| Then the details of who created the patient flag will be recorded | ||
| And the flag will be linked to the patient | ||
| Given a practitioner has received consent from a patient | ||
| And the consent is for reasonable adjustments | ||
| When a practioner adds an patient flag | ||
| Then the category of the flag will indicate that it is reasonable adjustments | ||
| Given a practitioner has received consent from a patient | ||
| And the consent is for reasonable adjustments | ||
| When a practioner adds an patient flag | ||
| Then the code of the flag will indicate that it is reasonable adjustments | ||
| Given a practitioner has received consent from a patient | ||
| And the consent is for reasonable adjustments | ||
| When a practioner adds an adjustment flag | ||
| Then the details of who created the adjustment flag will be recorded | ||
| And the flag will be linked to the patient | ||
| Given a practitioner has received consent from a patient | ||
| And the consent is for reasonable adjustments | ||
| When a practioner adds an adjustment flag | ||
| Then the category of the flag will contain a code that indicates it is reasonable adjustments | ||
| And the cateogry of the flag will contain a code that indicates which adjustment category the flag is | ||
| Given a practitioner has received consent from a patient | ||
| And the consent is for reasonable adjustments | ||
| When a practioner adds an adjustment flag | ||
| Then the code of the flag will be a SNOMED-CT concept that provide details of the adjustment | ||
| Given a practitioner has received consent from a patient | ||
| And the consent is for reasonable adjustments | ||
| When a practioner adds an adjustment flag | ||
| Then a condition resource may also be created | ||
| And the details of who created the condition will be recorded | ||
| And the condition will be linked to the patient | ||
| Given a practitioner has received consent from a patient | ||
| And the consent is for reasonable adjustments | ||
| When a practioner adds an condition | ||
| Then the category of the condition will indicate which catgory the condition is | ||
| Given a practitioner has received consent from a patient | ||
| And the consent is for reasonable adjustments | ||
| When a practioner adds an condition | ||
| Then the code of the condition will be a SNOMED-CT concept representing an impairment/condition | ||
| Given a practitioner has received consent from a patient | ||
| And the consent is for reasonable adjustments | ||
| When a practioner adds an adjustment flag | ||
| Then a freetext note may be added to the flag | ||
| ``` | ||
|
|
||
| ### Workflow | ||
|
|
||
| A practitioner performs an examination and determines that a condition and/or an adjustment should be recorded. If the patient does not consent, no details are recorded. If the patient consents, then the adjustment is recorded, and optionally the condition as well. | ||
|
|
||
| <div style="text-align: left;"> | ||
| <img style="max-width: 70%" alt="Add Patient Flag record workflow BPMN diagram." src="add-pf-record-workflow.svg"/> | ||
| </div> | ||
|
|
||
| ### System Interactions | ||
|
|
||
| The practioner decides to record a condition with the patients consent. 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. | ||
|
|
||
| <div style="text-align: left;"> | ||
| {%include add-fgm-record-sequence.svg%} | ||
| </div> | ||
|
|
||
| ### Examples | ||
|
|
||
| * [Patient example](Patient-PatientExample1.html) | ||
|
|
||
| The following set of examples constitute the individual associated resources with the intial addition of a flag for Reasonable Adjustment. This includes the Consent resource where the patient has agreed to share information. Also 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 intial update, it may be done as a [conditional update](https://www.hl7.org/fhir/http.html#cond-update) | ||
|
|
||
| * [Consent](Consent-RAConsentExample1.html) | ||
| * [Patient flag](Flag-RAPatientFlagExample1.html) | ||
| * [Reasonable Adjustment flag 1](Flag-RAFlagExample1.html) | ||
| * [Condition 1](Condition-RAConditionExample1.html) | ||
| * [Transaction Bundle 1](Bundle-AddRARecordTransactionExample1.html) | ||
|
|
||
| The following set of examples are for the same patient, and constitute an addition flag and condition. The transaction Bundle here illustates an idempotent update by simply adding the new resources to the first transaction Bundle. | ||
|
|
||
| * [Reasonable Adjustment flag 2](Flag-RAFlagExample2.html) | ||
| * [Condition 2](Condition-RAConditionExample2.html) | ||
| * [Transaction Bundle 2](Bundle-AddRARecordTransactionExample2.html) | ||
|
|
||
| ### Relevant Documentation | ||
|
|
||
| * [Bundle](https://hl7.org/fhir/r4/bundle.html) | ||
| * [Transaction](https://hl7.org/fhir/r4/http.html#transaction) | ||
| * [Upsert](https://hl7.org/fhir/r4/http.html#upsert) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,63 @@ | ||
| ### Overview | ||
|
|
||
| For high level requirements, see [Key purposes of the FGM Flag](index.html#fgm-key-purposes) | ||
|
|
||
|
|
||
| #### UseCase | ||
|
|
||
| <div style="text-align: left;"> | ||
|
|
||
| {%include remove-fgm-record-usecase.svg%} | ||
|
|
||
| </div> | ||
|
|
||
| #### Scenarios | ||
|
|
||
| ```gherkin | ||
| Given a patient or their advocate revokes consent | ||
| And the consent is for reasonable adjustments | ||
| When a practioner records the consent | ||
| Then consent will be marked as inactive | ||
| And all flags will be deleted | ||
| And all conditions will be deleted | ||
| ``` | ||
|
|
||
| #### Workflow | ||
| <p> | ||
|
|
||
| A patient may revoke consent to share information about Reasonable Adjustment records and if they do, all records must be removed. | ||
|
|
||
| </p> | ||
|
|
||
| <div> | ||
| <img style="max-width: 70%" alt="Remove Patient Flag record workflow BPMN diagram." src="remove-pf-record-workflow.svg"/> | ||
| </div> | ||
|
|
||
| ### System Interactions | ||
|
|
||
| In the following sequence diagram, a patient revokes consent. The Consent resource is updated to reflect the patient dissent, and all adjustment records are deleted. | ||
|
|
||
| <div style="text-align: left;"> | ||
|
|
||
| {%include remove-fgm-record-sequence.svg%} | ||
|
|
||
| </div> | ||
|
|
||
| The following resource types will be deleted from the record if consent is not granted i.e. | ||
|
|
||
| * [Patient Flag](StructureDefinition-PatientFlag.html) | ||
| * [Programme Flag](StructureDefinition-ProgrammeFlag.html) | ||
| * [Condition Flag](StructureDefinition-FlagCondition.html) | ||
|
|
||
| #### Example | ||
|
|
||
| Multiple resources can be deleted using a transaction bundle. This [example delete transaction Bundle](Bundle-RemoveRARecordExample.html) demonstates deleting the following resources | ||
|
|
||
| * [Patient Flag](Flag-RAPatientFlagExample1.html) example. | ||
| * [Programme Flag](Flag-RAFlagExample1.html) example. | ||
| * [Condition Flag](Condition-RAConditionExample1.html) example. | ||
|
|
||
| ### Relevant Documentation | ||
|
|
||
| * [Bundle](https://hl7.org/fhir/r4/bundle.html) | ||
| * [Transaction](https://hl7.org/fhir/r4/http.html#transaction) |
Oops, something went wrong.