Liquid layout

[jtquach1]

Describe your changes

Please include a summary of the changes and the related issue/task. Please also include relevant motivation and context. List any dependencies that are required for this change, including links to other pull requests/branches in other repositories if applicable.

This PR implements WCAG techniques G146, G179, G199

• Liquid layout
• no loss of content or functionality when zooming in
• indication of form submission success (existing for submitting REMS bundle, but fixed bug with form loading)

It turns out LForms actually has built in display options for small, medium, and large screen sizes if one clicks the settings cog icon and selects an option from the View Mode dropdown. So that also already covers G146 and G179 on the QuestionnaireForm page.

Default breakpoints in MUI 5 to reference for below

---

Before - Home page with patient view and medication select dropdown

xs screen (problematic)

sm screen (problematic at breakpoint, but otherwise OK)

md screen (problematic horizontal scroll bar on patient view, but this is just above the sm-md breakpoint)

present content without introducing horizontal scroll bars

lg screen (OK)

After - Home page

xs screen (after pre-wrapping whitespace, fixing ETASU/MedicationDispense.status text spacing, and text-wrapping MedicationRequest dropdown)

sm screen (after fixing ETASU/MedicationDispense.status text spacing)

md screen (after pre-wrapping whitespace)

---

Before - Document Status

Applies to all screen sizes xs, sm, md, lg - horizontal scrollbar for FHIR Resource JSON inside <pre> tag

After - Document Status

---

Before - QuestionnaireResponse form launched from within REMS SMART on FHIR app

xs screen (problematic cut-off text with input fields' helper text and values)

After - QuestionnaireResponse form

xs screen (no padding)

sm screen and above (original padding)

---

Issue ticket number and Jira link

Please include the Jira Ticket Number and Link for this issue/task.

https://jira.mitre.org/browse/REMS-654

Checklist before requesting a review

• I have performed a self-review of my code
• Ensure the target / base branch for any feature PR is set to dev not main (the only exception to this is releases from dev and hotfix branches)

Checklist for conducting a review

• Review the code changes and make sure they all make sense and are necessary.
• Pull the PR branch locally and test by running through workflow and making sure everything works as it is supposed to.

Workflow

Owner of the Pull Request will be responsible for merge after all requirements are met, including approval from at least one reviewer. Additional changes made after a review will dismiss any approvals and require re-review of the additional updates. Auto merging can be enabled below if additional changes are likely not to be needed. The bot will auto assign reviewers to your Pull Request for you.

[zacharyrobin]

Merge Conflicts need to be addressed

[KeeyanGhoreshi]

When you load a previous form, then modify it, then try to save it to the ehr, it reverts your form back to the previously loaded version, erasing any progress.

[jtquach1]

When you load a previous form, then modify it, then try to save it to the ehr, it reverts your form back to the previously loaded version, erasing any progress.

Thanks for catching that, should be fixed now