Quest v0.1 / G6PD: Patient Profile View

[f-odhiambo]

Patient Profile View:
we just need to visualize the patient's demographic information. For this scope, we don't need to implement editing or removing patients unless we get this for free. You will have the default landing page showing the available questionnaires and once you press on the menu item, you can be able to view the patent profile

(mock from Quest, exact details TBC - User profile )

(mock from G6DP, exact details TBC - Test Reulst page)

[pld]

Related to discussion today and conversation in #571, to decide what to show in the list of forms here we will eventually want to filter based on useContext, for now I think it's fine to show ALL the forms in this list.

After we've had a discussion on our goals and firmed up the implementation plan we can circle back.

[f-odhiambo]

This profile view has been updated when being viewed for G6PD

See mock

[pld]

I think this issue is 2 issues

1. the first generic version that's closer to the screenshots in the issue description.

2. a more use-case specific version, like in the above screenshot that needs a configuration to control what's displayed and is not yet scoped

@syedowaisali90 please only concern yourself with the generic version for now, @f-odhiambo can you create a new issue for the configured version that's marked blocked and needs scoping?

But, for the generic version, what do we display? Is it like the final screen but it shows all the forms, doesn't show anything under the patients name, and only has the date for previous result?

[pld]

I may also be missing information here, are we far enough along with configuration that we do these as a single issue? If so that's great, and if so @syedowaisali90 can you add more details on the implementation plan for doing this through configuration so we can discuss and give feedback before work begins? Thanks

[owais-vd]

@pld I don't think it will be controlled by configs and I think the updated mock that @f-odhiambo has shared looks like a more updated version and if not so then we need more context.

[pld]

OK, more context is needed then. The updated mock is specific to g6pd, which this is not supposed to be, so we'd want to implement a version of this that is not-g6pd specific and if we need anything g6pd specific that would have to be controlled through dynamic files loaded via sync.

@rowo @f-odhiambo can we build a generic version of this that is effective for g6pd? If not, let's schedule a meeting to define the implementation plan for how to have the g6pd portions of this loaded dynamically so this stays in-line w/the single APK approach.

[pld]

Marking as blocked until we resolve the above

[isabelcshaw]

@pld there are two things that I see as unique to G6PD here, and my understanding from my conversation with @rowo is that these are both client requirements:

1. The addition of the "results" component below the list of questionnaires
2. A G6PD status indicator on the patient name

We had planned to implement a way to visualize questionnaire responses in the v2 of Quest, so this is expediting this timeline. It seemed like the component was the best possible compromise, but I'll talk to @f-odhiambo now about how this could potentially be scoped back even further.

Defer to the implementation conversation, but I can move this results component and status indicators each into separate issues.

[pld]

OK, so @owais-vd let's implement this based on the first screenshot in the description and put anything configurable to later issues that @isabelcshaw you can be in charge of doing the first round of scoping for

[isabelcshaw]

@owais-vd after discussion with @pld we've aligned on this version of the profile view that only has one addition for G6PD. Some notes on the image below:

1. I've removed the G6PD status on the client's name (sorry it isn't neater) - you can consider that out of scope
2. The expectation is that the questionnaire launch button will show whatever the questionnaire name is, so these are not hardcoded.
3. Similarly, the number of questionnaire launch buttons is based on how many active questionnaires are available / tagged the the user. Even for the G6PD use case, we expect that if there are multiple questionnaires, we would show multiple buttons. For the case of client demonstration, we can just deactivate any extra questionnaires.
4. The second component on the profile view that shows previous responses has been simplified. For WP1, we are only going to show the name of the questionnaire and the date it was submitted - not any info on the results. For WP1, we are also NOT going to make these clickable. We will address those added steps in WP2.

[pld]

Note the list of forms is generated dynamically from any forms linked to the user and the name item in the list of responses is from the submitted QuestionnaireResponse

…

On Oct 7, 2021, at 14:27, Isabel Shaw ***@***.***> wrote:  @owais-vd after discussion with @pld we've aligned on this version of the profile view that only has one addition for G6PD. Some notes on the image below: I've removed the G6PD status on the client's name (sorry it isn't neater) - you can consider that out of scope — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[pld]

Also instead of saying Test Result that should say Responses

…

On Oct 7, 2021, at 14:27, Isabel Shaw ***@***.***> wrote:  @owais-vd after discussion with @pld we've aligned on this version of the profile view that only has one addition for G6PD. Some notes on the image below: I've removed the G6PD status on the client's name (sorry it isn't neater) - you can consider that out of scope — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[isabelcshaw]

@pld updated the comment and image - let me know if anything is missing

[owais-vd]

#585 (comment) Noted. Thanks, @pld @isabelcshaw

[owais-vd]

OK, so @owais-vd let's implement this based on the first screenshot in the description and put anything configurable to later issues that @isabelcshaw you can be in charge of doing the first round of scoping for

@pld for dynamic forms population i think we need to wrap up first these PRs #590, #595 cc: @maimoonak @trevorgowing

[pld]

yea definitely, I'd leave that widget w/demo content until those PRs are merged in

[f-odhiambo]

Update

1. Updated the UI as per new mock and load test forms from configs and dynamically populated the test results.
2. Adding test cases and then create a PR for review.

[owais-vd]

• Updated a UI as per this comment Quest v0.1 / G6PD: Patient Profile View #585 (comment).
• Test form loading from form_configurations.json previously it was hard-coded.
• Responses are loading dynamically from the DB based on patient id.

Note: #585 (comment) in point 3 we are expecting the questionnaire can be multiple and loaded dynamically from the DB but it has not been scoped yet. so for now im using the form configs.

cc: @f-odhiambo @pld @isabelcshaw

[pld]

What's needed for scoping there? Let's use the same work that's loading the form for registration to load the list of forms here

[owais-vd]

@pld However, when we launch the form, it loads from the DB just like others. The config is just filtering out the forms like what questionnaire will be loaded on click and if you mean to populate all the questionnaire title and ids from the DB then what filter will be used for populating the test related questionnaires, because we have also other questionnaire forms in the DB as well.

[pld]

Why do we need the config in that case?

For the Questionnaire title and IDs, it should pull any forms linked to this Patient. From the resource, it looks like as the source field is most appropriate

[owais-vd]

ok, so what field will be used in the Patient resource which will hold the questionnaire ref/id. I don't think that any fields are available in either Patient or Questionnaire resource that links to each other.

[pld]

Sorry I meant QuestionnaireResponse, that has the source field for this

[pld]

Questionnaire's are not patient specific

[owais-vd]

sorry, we but don't store any QuestionnaireResponse resource in the DB, we just extracting the actual resource based on the subject by using the ResourceMapper and save it.

[pld]

What resource are you storing based on what's submitted to the Questionnaire?

[owais-vd]

like we have a questionnaire for registering a Patient then we load the Questionnaire and extract the QuestionnaireResponse on submit and then we pass the QuestionnaireResponse to the ResourceMapper which is responsible to convert the QuestionnaireResponse to the actual resource based on the Questionnaire subject i.e Patient and then we save the Patient resource in the DB.

[pld]

I see I did not realize that, so then there is no resource stored if there's nothing in the ResourceMapper?

In that case, for Quest, can we have a default resource mapping that stores a QuestionnaireResponse linked to the patient?

[pld]

I've spoken w/ @maimoonak we're going to save a QuestionnaireResponse, she may cover this in #570

[owais-vd]

I don't think we need to save QuestionnaireResponse in case of this issue because we need to filter the test-related questionnaires from the DB based on some constraints. i.e useContext cc: @maimoonak

[pld]

Yes true, my point is more that the QuestionnaireResponse will be created when the form is completed, you can retrieve the list of items to show in Responses by querying for the QuestionnaireResponse resources linked to this patient and displaying them in a list format

[owais-vd]

@maimoonak are we not extracting the DiagnosticReport from the QuestionnaireResponse for now?

[owais-vd]

because currently, i'm querying the DiagnosticReport list as a responses.

[pld]

No, we're not extracting anything yet

[owais-vd]

ok cool, then i need to update the PR. Thanks