Skip to content

Commit

Permalink
editing non-eventful data (#2852)
Browse files Browse the repository at this point in the history
* editing non-eventuful data

* editing non-eventuful data

* exapnd and reword

* add editing to feature list

* update text h/t rowo

---------

Co-authored-by: pld <[email protected]>
  • Loading branch information
ageryck and pld authored Nov 8, 2023
1 parent 001a47a commit 44dce3c
Show file tree
Hide file tree
Showing 2 changed files with 70 additions and 5 deletions.
68 changes: 65 additions & 3 deletions docs/engineering/android-app/configuring/editing.mdx
Original file line number Diff line number Diff line change
@@ -1,8 +1,70 @@
# Editing

You can manage edits through
You can manage edits through

1. complex structure maps to ensure that any potential downstream affects of an edit (like changing CarePlan or Task status) are accounted for,r
2. limiting what is editable to only those pieces that do not have downstream affects.
1. complex structure maps to ensure that any potential downstream effects of an edit (like changing CarePlan or Task status) are accounted for, or
2. limiting what is editable to only those fields(data elements) that do not have downstream affects.

We suggest following approach (2.) to reduce the chance of errors and the resulting inconsistent data.

## Limiting what is editable

Below we describe how to limit what is editable while reusing the same FHIR resources that created the data. This assumes that you have

- a Questionniare that data is originally entered in and will be edited in,
- a StructureMap that extracts data from the QuestionnaireResponse into other resources,
- a config the specifies one interface to launch the Questionnaire for creation and another to launch it for editing.

1. Create a new hidden item in the Questionnaire to hold the `is-edit-mode` value

```
{
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/questionnaire-hidden",
"valueBoolean": true
}
],
"linkId": "is-edit-profile",
"type": "boolean"
}
```

2. Pre-populate the new item on when loading the questionnaire, to use a static rule with a boolean value of true. Do this for any button or menu-item that you want to launch the edit form.

> Sample rule:
>```
>{
> "name": "isEditProfile",
> "condition": "true",
> "actions": [
> "data.put('isEditProfile', true)"
> ]
>}
>```
> Sample pre-population:
>```
>{
> "paramType": "PREPOPULATE",
> "linkId": "is-edit-profile",
> "dataType": "BOOLEAN",
> "key": "isEditProfile",
> "value": "@{isEditProfile}"
>}
>```
3. Use the pre-set value of the edit mode item, `isEditProfile`, to enable the items with downstream effects in the Questionnaire, such as date of birth and gender, using the `enableWhen` Questionnaire item attribute. This will cause those items only to show when `isEditProfile` is false, i.e. when creating data.

```
"enableWhen": [
{
"question": "is-edit-profile",
"operator": "exists",
"answerBoolean": false
}
],
"enableBehavior": "any"
```

4. Launch the Questionnaire from an edit menu just as would is creating, but prepopulate the previously captured items. This approach allows to you to use the existing Questionnaire and StructureMap.
7 changes: 5 additions & 2 deletions docs/features/app-features/readme.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ sidebar_label: App Features

# App Features

As of release [**v0.2.4**](https://github.com/opensrp/fhircore/releases/tag/v0.2.4-opensrp) (July 18th, 2023)
As of release [**v1.0.1**](https://github.com/opensrp/fhircore/releases/tag/v1.0.1-opensrp-rc1) (September 21st, 2023)

## Patient and family registration

Expand All @@ -15,6 +15,10 @@ Patients and households are associated to a health worker through a location. A

In cases where patients visit or health workers cover multiple clinics across area, both the patient and the health worker would be assigned to a higher level location. For example, instead of being assigned to a village, they would be assigned to a facility area or county. That would result in a patient showing up on any of the facility patient lists in that higher level area, and for that patients medical record to be synced to the health worker's device.

### Editing submitted data

You can configure the app to allow data editing to fix mistakes or account for changes to information like name or address. Configuration options give you the flexibility to specify what fields can be edited. It is important to assess the downstream impacts of edits when designing your app.

## Finding patients

Navigating to a patient quickly is paramount for health work, especially when in the community. Because it is common for OpenSRP to be used in places where many people may share similar names, we offer many ways for patient look-up.
Expand Down Expand Up @@ -123,5 +127,4 @@ Through sync insights OpenSRP makes it possible to understand which data has bee
![sync insights](/img/sync-insights.png)

## Roadmap for 2023–2024
- Editing submitted form data
- Draft and in-progress forms

0 comments on commit 44dce3c

Please sign in to comment.