Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CEP-X] Consent Restructure Proposal #26

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
88 changes: 88 additions & 0 deletions docs/care/CEP/0006-consent-restructure.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,88 @@
# CEP-6: Reimagining storing consents

## Preface

When consents were added to the patient consultation model, they were added based on the following assumptions:

- A patient (per consultation) can have multiple consents
- Each consent would have a type (e.g. consnent for admission, patient code status, consent for procedure)
- if type is patient code status, then the consent would have a sub type (e.g. DNR, DNH, Active Treatment)
- Each consent can have multiple files attached to it
- These files can be archived
- This form should be present in the consultation form

Looking at these requirements, a new JSON field was added to the patient consultation model with the following schema

```json
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "array",
"items": [
{
"type": "object",
"properties": {
"id": { "type": "string" },
"type": { "type": "number" },
"patient_code_status": { "type": "number" },
"deleted": { "type": "boolean" }
},
"additionalProperties": false,
"required": ["id", "type"]
}
]
}
```

Our initial UI allowed consents groups to be made, and each consent group had its own file manager. Different file manager due to the fact that files were stored associative to the consent id, and there was already a file manager component that could be reused.

![Initial UI](./assets/0006/initial-ui.png)

However, this did not have it's desired result on the field. Consents were not easily accessible and having a different file manager for each consent group was not intuitive.

The new requirement was to have a seperate page for consents, accessible from the patient consultation page.
In the consent page, files should be managed in a single file manager, and consents should be grouped by type.

The new UI requirement sounded more logical than the one I previously made, but the way I was handling consents in the backend were not compatible with this, thus hacks and workarounds were used to ship the new page, but it is clear that the current implementation is not sustainable.

![New UI](./assets/0006/new-ui.png)

## Proposal

We create a new model `PatientConsent`

```python
class PatientConsent(BaseModel):
consultation = models.ForeignKey(Consultation, on_delete=models.CASCADE)
type = models.IntegerField(choices=ConsentType.choices)
patient_code_status = models.IntegerField(choices=PatientCodeStatus.choices, null=True, blank=True)
archived = models.BooleanField(default=False)
files = models.ManyToManyField(FileUpload, related_name="consents")
```

Alongside this, a constraint that does not allow a consent of `type` patient code status to have a null `patient_code_status`. We enforce this through the serializer as well.

Incase a new patient code status is added, the previous consent is automatically archived. A consent archive will also archive all files associated with it.

`BaseModel` handles creator, editor and time stamps.

New APIs for CRUD operations on `PatientConsent`

```
{consultation_id}/patient-consents/
```

We fetch files by filtering on the `associating_id` field.

```
/files/?file_type=CONSENT_RECORDS&associating_id=patient-consent-12345
```

But this would need to fetch multiple times from the client for each consent, thus we update the `associating_id` filter to accept multiple ids.

```
/files/?file_type=CONSENT_RECORDS&associating_id=patient-consent-12345,patient-consent-12346
```

So on the client side, we first fetch the consents, and then fetch the files, and then group them.

If a new patient code status is needed, we archive the consent through a `PATCH` request, which triggers a cascade archive of the files.
Binary file added docs/care/CEP/assets/0006/initial-ui.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/care/CEP/assets/0006/new-ui.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
4 changes: 2 additions & 2 deletions docs/care/CEP/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

Care Enhancement Proposals are feature requests with lot's of specific details, CEP's can include customer stories, backend architecture, UI/UX mockups, designs etc.


## CEPs

[CEP-5: Care Apps](/docs/care/CEP/)
- [CEP-5: Care Apps](/docs/care/CEP/Plugin_Manager)
- [CEP-6: Bringing consents to their own table](/docs/care/CEP/consent-restructure)