[Multiple Ordering Providers] Backend support for Multiple Ordering Providers

[jayna-SkylightDigital]

Why should we do this?

• The current SimpleReport data model only supports a single ordering provider per facility, which limits the flexibility and functionality for managing ordering provider information.
• To enable the ability to support multiple ordering providers, we need to extend the existing data model and make the necessary database schema changes.

User story

As a software engineer, I want to update the data model and database schema to support storing and managing multiple ordering providers per facility so that the new "Multiple Ordering Providers" feature can be implemented.

Action Requested

1. Extend the existing data model to support the following:
   • Storing multiple ordering providers per facility
   • Maintaining metadata and attributes for each ordering provider (e.g., name, address, contact info)
   • Associating ordering providers with specific facilities
   • Include ordering provider data in the existing get facility queue method to support selecting an ordering provider on the test card
2. Implement the necessary database schema changes to accommodate the new ordering provider data structure.
3. Ensure data integrity and consistency when updating or deleting ordering provider records, including handling any potential impacts on historical test results.
4. Implement the logic to persist ordering provider data when new providers are added or existing ones are updated.
   • Including identifying the default ordering provider to be used (last selected)
   • Ensure that ordering provider information is correctly displayed on historical test results, even if the provider has been deleted from the system
5. Ensure ordering provider data and associated api operations are limited to Admin users
6. Update save test flow to support receiving an ordering provider from the frontend.

Acceptance Criteria

Design

• Data model changes are designed and documented
• Database schema changes are designed and documented

Implementation

• Extend the data model to support multiple ordering providers
• Implement the database schema changes to accommodate the new ordering provider data
• Ensure data integrity and consistency when updating or deleting ordering provider records
• Validate the changes work as expected through comprehensive testing
• Implement the logic to persist ordering provider data when new providers are added or existing ones are updated
• Ensure ordering provider information is correctly retrieved and displayed on historical test results, even if the provider has been deleted
• Ensure ordering provider information and management is limited to Admin users
• Validate the data persistence and retrieval functionality through comprehensive testing

Additional Context

• Figma: https://www.figma.com/design/LglkDsGZDKMZm3XCkJPhfR/SimpleReport-2023%2B?node-id=5984-397&t=gcK2LTCUEPhQIxxY-0
• To support selecting ordering providers on the test card we must update the graphql query to return ordering provider(s)
• To support default ordering provider logic, we need to identify the last ordering provider used and save that information (similar pattern to the existing default test device implementation).

[fzhao99]

Found these old tickets while doing some other digging:

#2668
#4788

[mehansen]

From the Figma:

NOTE:
The default ordering provider could be the first provider added. For the test card, the order provider can be the last provider submitted.

[mehansen]

@jayna-SkylightDigital @kenieh
I found that for the state of ND, we don't require ordering provider data (see #1647). I wanted to verify that for the new design changes on the facility form, we will give the error toast if the facility doesn't have at least 1 ordering provider UNLESS the facility state is ND, in which case we will allow it.

[jayna-SkylightDigital]

@jayna-SkylightDigital @kenieh I found that for the state of ND, we don't require ordering provider data (see #1647). I wanted to verify that for the new design changes on the facility form, we will give the error toast if the facility doesn't have at least 1 ordering provider UNLESS the facility state is ND, in which case we will allow it.

@mehansen That is correct. SimpleReport should display the error toast if the facility doesn't have at least 1 ordering provider UNLESS the facility state is ND, in which case the toast will not display (as ND does not require ordering provider data).

[mehansen]

thanks @jayna-SkylightDigital! I have another question (cc @kenieh)

what's the expected behavior for the following?:

• someone is on the facility edit page, deletes a provider, then navigates away without saving the facility page
  • what if the provider is their only provider and now they have 0?
• someone is on the facility edit page, creates a provider and adds it to the facility, then navigates away without saving the facility page
• someone is on the facility edit page, updates an existing provider for the facility, then navigates away without saving the facility page

I realize these are a little redundant but wanted to outline all the cases. fwiw I think it makes sense for the changes to providers to be saved even if the user navigates away without saving the facility, since we have the success/error toasts that imply the action is completed. and we can refuse to delete a provider if it's only provider for a facility (except for ND)

[jayna-SkylightDigital]

@mehansen:

• Scenario 1: Deleting the only provider associated with the facility
• • Refuse to delete the provider if it's the only one (except in the case of ND).
• Scenario 2: Creating a new ordering provider but not saving
• Scenario 3: Updating existing ordering provider details but navigating away before saving
• • Are we currently auto-saving changes in other places in the application if a user navigates away? If we are, then your suggestion of simply showing the success/error toasts to indicate that the action has been completed would be fine.
• • If not...my preferred solution would be to display a modal telling them they have unsaved changes and asking if they want to save -- I didn't notice a version of this modal/confirmation message in the Figma. @kenieh is this something we could potentially do? @mehansen how difficult would that be to implement on the developer side?

Scenario 1: Deleting the only provider associated with the facility
Recommendation: (Agree with your original suggestion!) Refuse to delete the provider if it's the only one.

Step-by-Step User Experience:

• User clicks the trash can icon to delete the only provider associated with the facility.
• A modal/inline message appears: "This is the only provider for this facility. Facilities must have at least one provider. Please add another provider before deleting this one."
• The user is returned to the edit page.

Scenario 2: Creating a new ordering provider but not saving
Recommendation: Auto-saving in this case might lead to unintended changes.

Step-by-Step User Experience:

• User adds provider details.
• User navigates away (clicks a different link, closes tab, etc.)
• A modal appears: "You have unsaved changes to this facility's providers. Do you want to save these changes?" with "Yes" and "No" options.
• "Yes" saves the changes and navigates the user away. "No" discards the new provider information and navigates the user away.

Scenario 3: Updating existing ordering provider details but navigating away before saving
Recommendation: We should treat updates the same way we treat new additions (whatever we decide to do for scenario 2 would apply to scenario 3)

Step-by-Step User Experience:

• User edits provider details.
• User navigates away.
• Same modal as Scenario 2 appears: "You have unsaved changes to this facility's providers. Do you want to save these changes?" with "Yes" and "No" options.
• "Yes" saves the updated provider information and navigates away. "No" discards the changes and navigates away.

[mehansen]

@jayna-SkylightDigital

1. Are we currently auto-saving changes in other places in the application if a user navigates away?
   I think this is the first instance in the app where someone can be on an edit page and then open up another edit page, save that page, and then be directed back to the original edit page. As in: Edit a facility, click the pencil icon next to a provider and be directed to the edit provider page, hit save on that page and then be put back on the facility edit page. So imo this doesn't have an exact precedent. I'm good to do whatever makes most sense to product/design, which sounds like it is to not persist until the user hits save on the facility edit page.

2. Regarding the modal: We already have a modal for the facility form that will complain if you try to navigate away without saving but doesn't work if someone just closes the window. We could add that functionality as well but I don't think all browsers allow you to customize the text for that.

3. I do think there is no need for the "refuse to delete provider" if we are not going to persist until the user saves the facility, since we already have a validation on the facility to prevent saving if they don't have a provider.

[mehansen]

Met with @jayna-SkylightDigital, @kenieh, and @khayeni-SL and determined that if a user makes a change to the provider, they do not need to hit save again on the facility page to persist the changes.