(Epic) General settings page in the app

[willusds]

This is the epic to build the General Settings page.

Invision Mockups Here

Specs & Feature Needs:

• Design updates to Settings page (add Facility address and phone.) @hmyers-cms
• [x] Build the UI #115
• [x] Make data from the settings page available to the test queue (device type) #115
• [x] Link settings data at the time of the test to saved test result (so it can be passed through in the HL7 result via the data hub) #115

Additional Context This page captures data needed for the HL7 results send to public health that. Settings page should capture data that is: -Relatively stable from test to test (i.e. facility or device specific data) -Does not change from person to person -Required to be sent to public health as a part of the HL7 message

List of data fields needed from the General settings page from the Airtable:

• Facility Name
• CLIA Number
• Device Type
• NPI
• (Ordering Provider) Last Name
• (Ordering Provider) First Name
• (Ordering Provider) Address
• (Ordering Provider) Zip Code
• (Ordering Provider) Phone Number
• Facility Name
• Facility Address
• Facility Zip Code
• Facility Phone Number
• Device Type
• Swab Type*

*We don't have a design for this and haven't tested it with users, so let's skip it for now. This is ticket #106

[sharmaneil]

Im working on the first version of this. It will include:

• a link to the settings page
• the ability to view, add, and delete devices

Should be done in maybe another day

[aliciabeckett-gov]

Here's the current device options on the market to include in the drop down: -Quidel Sofia 2 -BD Veritor -Abbott BinaxNow -Abbot IDNow -LumiraDX

[aliciabeckett-gov]

Here's the complete list of fields we need coming from the settings page:

• Facility Name
• CLIA Number
• Device Type
• NPI
• (Ordering Provider) Last Name
• (Ordering Provider) First Name
• (Ordering Provider) Address
• (Ordering Provider) Zip Code
• (Ordering Provider) Phone Number
• Facility Name
• Facility Address
• Facility Zip Code
• Facility Phone Number
• Device Type
• Swab Type*

*We don't have a design for this and haven't tested it with users, so let's skip it for now.

[aliciabeckett-gov]

@hmyers-cms - do you want a separate ticket for updating the settings page with address and phone for the facility?

[hmyers-cms]

Re: swab type... From what we have heard, facilities use different swab types depending on what supplies they are able to get. If it is changing frequently then it may not be a global settings thing, you may need to specify per test, which could get burdensome. Need to learn more about this.

Re: Adding address and phone no need for another ticket this works

[pete-gov]

@aliciabeckett-gov: @RickHawesUSDS had specifically requested Device Manufacturer and Device Model rather than just Device Type and that it match the official manufacturer and device name list. Reference: https://github.com/CDCgov/prime-central/issues/83

Can you clarify, is the Airtable and the spec in this ticket out of date for not having those fields, or was there a deliberate choice to not implement the separate fields?

---

If we do want to just use these example models, but match the requirements, looks like it would be more like:

• Quidel or Quidel Corporation : Sofia 2 SARS Antigen FIA or Sofia 2 Flu + SARS Antigen FIA
• Becton, Dickinson and Company (BD) : BD Veritor System for Rapid Detection of SARS-CoV-2
• Abbott : BinaxNOW COVID-19 Ag Card
• Abbott : ID NOW
• LumiraDX - bunch of different models here

(Is there any particular reason we shouldn't just include all the valid manufacturers and model names from the spreadsheet?)

[aliciabeckett-gov]

@sharmaneil @hmyers-cms - Should the settings auto-save?

If it's all the same tech effort let's try auto-save so we don't have to remind people to save their unsaved changes. @katiealoisi maybe something to test in usability tests next week.

[hmyers-cms]

Katie and I talked about this and already told Neil that we think it should not save anything until you click the button. In the interest of not re-litigating decisions I think we should stay on the current course of having a save button. I tagged you in the slack convo so you can see, and posting a screenshot here for anyone else who looks at this [issue.]([url](url ))

[aliciabeckett-gov]

Katie and I talked about this and already told Neil that we think it should not save anything until you click the button. In the interest of not re-litigating decisions I think we should stay on the current course of having a save button. I tagged you in the slack convo so you can see, and posting a screenshot here for anyone else who looks at this [issue.]([url](url ))

Sounds good.

[aliciabeckett-gov]

@aliciabeckett-gov: @RickHawesUSDS had specifically requested Device Manufacturer and Device Model rather than just Device Type and that it match the official manufacturer and device name list. Reference: #83

Can you clarify, is the Airtable and the spec in this ticket out of date for not having those fields, or was there a deliberate choice to not implement the separate fields?

If we do want to just use these example models, but match the requirements, looks like it would be more like:

• Quidel or Quidel Corporation : Sofia 2 SARS Antigen FIA or Sofia 2 Flu + SARS Antigen FIA
• Becton, Dickinson and Company (BD) : BD Veritor System for Rapid Detection of SARS-CoV-2
• Abbott : BinaxNOW COVID-19 Ag Card
• Abbott : ID NOW
• LumiraDX - bunch of different models here

(Is there any particular reason we shouldn't just include all the valid manufacturers and model names from the spreadsheet?)

@pete-usds : The list I shared with @sharmaneil was what should be displayed to the user so that they can easily select the right device in the setting page. At some point, what we show on the front end needs to map to the appropriate LOINC codes for the HL7 message. Whether that happens in the app front end, backend, or in the data hub doesn't matter to me and seems like more of an engineering decision.

[pete-gov]

At some point, what we show on the front end needs to map to the appropriate LOINC codes for the HL7 message. Whether that happens in the app front end, backend, or in the data hub doesn't matter to me and seems like more of an engineering decision.

Right, this is exactly why we have to collect specific and known valid Device Manufacturer Name and Device Model in the Device Settings page when they are adding a new device - we don't have any way to programmatically reverse engineer those from the friendly names in the examples (Quidel Sofia 2 doesn't give a way to uniquely identify a manufacturer and model).

[hmyers-cms]

@pete-usds I had a similar convo with @sharmaneil recently, and learned that this wasn't clear before: Users cannot add any device they want. There is a set list of available devices they can choose from. We need to map those devices to the appropriate LOINC codes/manufacturer/model in the back-end.

[pete-gov]

Sorry for all the confusion on this. I just wanted confirmation on if the device models that are in this ticket are the device models that Rick wants us to use per his request: "PDI should also collect device manufacture and model. The manufactures and models should be restricted to those found on this mapping guide."

The mapping guide he sent doesn't have device models that match the names in this ticket, hence my first comment (i.e. there is no Device Model of Sofia 2).

... except reading through this more it looks like the information Rick linked in the original request was for Test Device Kits which might be why things aren't lining up with the names in this ticket.

If y'all are confident we can ignore that request from Rick or don't have any concerns about needing to know a more specific device model than the ones here, then no worries!

[aliciabeckett-gov]

I used the same list Rick used, so I'm pretty confident the list of devices is correct. We also verified it with Jason Hall.

Also, FWIW not every device maps to a unique LOINC code. For Example, the BinaxNow shares a LOINC code with the BD. So there is some value in keeping the user facing label and the mapping label separated.

[sharmaneil]

I'm working on finishing up the UI for the settings page, just in case others were planning to do that.

[pete-gov]

I've approved the merge of the current implementation into the codebase, but please see my feedback on the PR here for some bugs and other issues we'll want to address: https://github.com/CDCgov/prime-data-input-client/pull/49#issuecomment-723143413

[aliciabeckett-gov]

It looks like the remaining work here is the design of, and development of, adding Facility address and Facility phone number to the settings page. I'm going to cover those updates with #118 and close this ticket.