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

(feat) Add support for pre-filled questions #70

Merged
merged 5 commits into from
Feb 1, 2024

Conversation

icrc-jofrancisco
Copy link
Contributor

@icrc-jofrancisco icrc-jofrancisco commented Jan 19, 2024

Requirements

  • This PR has a title that briefly describes the work done, including the ticket number if there is a ticket.
  • My work conforms to the OpenMRS 3.0 Styleguide.
  • My work includes tests or is validated by existing tests.

Summary

IN PROGRESS

In the fast data entry app, users often need to input data for multiple patient encounters. With this enhancement, users can now pre-populate several questions with the same answers for all patients. This streamlines the data entry process and enhances efficiency, especially in scenarios where consistent information needs to be entered across different patient records.

Specific Questions:
Introduces a flexible structure for capturing specific questions associated with forms.
Each specific question includes:

  • forms: Identifies the forms to which the question applies.
  • questionId: Unique identifier for the form question where will be placed the default value.

Configuration example:

...
    "specificQuestions": [
      {
        "forms": [
          "17dea7cc-a0e6-34be-af31-9867004202df",
          "798a600f-fe2b-3d24-ad15-19d8ff2c17ac"
        ],
        "questionId": "placeOfConsultation"
      },
      {
        "forms": [
          "17dea7cc-a0e6-34be-af31-9867004202df",
          "798a600f-fe2b-3d24-ad15-19d8ff2c17ac"
        ],
        "questionId": "practitionerAffiliation"
      },
      {
        "forms": [
          "17dea7cc-a0e6-34be-af31-9867004202df",
          "798a600f-fe2b-3d24-ad15-19d8ff2c17ac"
        ],
        "questionId": "practitionerId"
      },
      {
        "forms": [
          "17dea7cc-a0e6-34be-af31-9867004202df",
          "798a600f-fe2b-3d24-ad15-19d8ff2c17ac"
        ],
        "questionId": "practitionerName"
      }
    ]
    ...

Screenshots

image

Related Issue

Other

This pull request is dependent on the changes introduced in here.

Thanks,
CC: @ibacher

@icrc-jofrancisco icrc-jofrancisco marked this pull request as ready for review January 22, 2024 10:07
Copy link
Member

@ibacher ibacher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @icrc-jofrancisco, but I do think we want to try to collect things as a standard form element instead of adding yet another form schema in the configuration.

_type: Type.UUID,
_description: "Concept UUID of the question.",
},
answers: {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this element necessary?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically, can we rework things to use the existing form?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @ibacher , This element is just to know the translated label of the question, coming from the backend, thus avoiding specifying a hardcoded label.

@@ -138,6 +144,7 @@ const FormBootstrap = ({
}
}, [patientUuid, formUuid, patient]);

const { activeSessionMeta } = useContext(GroupFormWorkflowContext);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would move this up in the compontn a big.


type PreFilledQuestions = {
[key: string]: string;
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
};
};

const { specificQuestions } = useConfig();
const { formUuid } = useParams() as ParamTypes;

const questions = useMemo(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this doing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To search for the form for which we are using in and see if there are any specific questions for this session/form.

@@ -122,6 +138,41 @@ const SessionDetailsForm = () => {
</Layer>
</Tile>
</Layer>
{getSpecificQuestionsByForm(specificQuestions, formUuid).length >
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we calling getSpecificQuestionsByForm() twice here instead of relying on a single call?

@@ -122,6 +138,41 @@ const SessionDetailsForm = () => {
</Layer>
</Tile>
</Layer>
{getSpecificQuestionsByForm(specificQuestions, formUuid).length >
0 && (
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Always prefer:

condition ? <ReactJSX> : null

@icrc-jofrancisco
Copy link
Contributor Author

Thanks @icrc-jofrancisco, but I do think we want to try to collect things as a standard form element instead of adding yet another form schema in the configuration.

Thanks @ibacher !
I understand your point, the idea is that these are just a few questions.
The reason I did it this way is because the logic for fetching the schema and rendering the labels and the form is only in the next phase, here we only have the formuuid. In other words, with the other approach, the request to fetch the schema is called twice.
So, what do you think would be the best approach?

@icrc-jofrancisco
Copy link
Contributor Author

Thanks @icrc-jofrancisco, but I do think we want to try to collect things as a standard form element instead of adding yet another form schema in the configuration.

Thanks @ibacher ! I understand your point, the idea is that these are just a few questions. The reason I did it this way is because the logic for fetching the schema and rendering the labels and the form is only in the next phase, here we only have the formuuid. In other words, with the other approach, the request to fetch the schema is called twice. So, what do you think would be the best approach?

Hi @ibacher , Actually, I've implemented your suggestion. Now, all you need to do is specify the questionId and the forms list. It'll automatically fetch the labels and values for the questions and answers.
Super simple configuration, right?

If you've got more suggestions,feel free to comment, Appreciate your input!

@ibacher ibacher changed the title (feat) Add Support for Pre-Filled Questions (feat) Add support for pre-filled questions Feb 1, 2024
@ibacher ibacher merged commit c98ac69 into openmrs:main Feb 1, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants