Shift visibility

For GBW-88, there’s two related asks:

• Allow IV admin to indicate what states a doctor can see shifts in

• Allow IV doctors to indicate what states they want to see.

eligible to take shift

For first pass, this is going to just be a set of flags which an admin can manage.

IV is explicitly opting to delay any element of license/mgt as a factor in eligibility for shift taking/viewing at this point, in favor of expedience.

Initial thoughts on ‘licensing’ are retained below for future reference.

UI screens

admin mgt

Admin needs to be able to view an employee, see list of states, and mark employee as eligible to take shifts in that state.

Per IV feedback, ‘eligibility’ and ‘interest’ may be combined in to one instrument if that helps get a first iteration out faster.

dr preferences

We can provide a screen for doctors to toggle their interest in specific states on or off.

Shift ‘taking’ would IGNORE whether a dr is eligible for the first pass at this. Per IV feedback, they are going to trust drs to not take shifts where they are not licensed, even if they opt to view shifts in a particular state.

This UI screen may be something only available on a desktop view? In future, moving back towards a ‘geo’-type structure, users may be presented with more choices and these would not necessarily fit well within mobile device confines.

data

state_visibility

This is a table that will join employee table with

• employee_id
• state_abbreviation
• eligible
• interest

In future, a ‘region’ table with region type and label could added for more granularity. A region type may be ‘state’ with label of ‘NJ’, but that region may have child regions of type ‘county’ and label ‘bergen’ or type ‘area’ and label ‘south edison’. Marrying up sites to this region table would entail some manual work, but would then allow for doctors to be more granular in their interest, and allow for more granular reporting.

Future ‘licensing’ would almost always still be keying off a ‘state’ level only.

The first iteration of this will combine ‘interest’ and ‘eligibility’, likely by just modifying both flags at once.

Future state will allow for separate management of interest vs eligibility. At that stage, ‘taking’ shifts will be gate by eligibility flag.

POSSIBILITY - find unique states within 50 mile radius, update doctors to that as a default.

Misc needs

Would need a way for a user to be automatically assigned to their ‘home’ state when registering, or updating their address. We’ll make that assumption.

Would need a way for admin to set initial states for all users, or… just set everyone to visibility for their ‘home’ state (based on primary address).

Note

client/server state

Initially was thinking this might do server-side limiting of shift visibility, but given that we need to allow client-side filtering, we need some coordinated way to ‘permanent’ visibility state at the server and also incorporate any of those changes in to filtering process.

This may require some sort of trigger on client if the client side code changes the visibility state from a client screen - that change needs to be stored at server, but also influence the client. A trigger to update the global vuex state for ‘visibility’ might be the appropriate answer.

Tabled license thinking

The ‘where are you licensed’ may inform a default set of states a vet may filter on, but the goal was to also allow users to view items from other states, as they may be obtaining licensing in neighboring states and have an interest in seeing options.

per state licensing

‘certification’ table will have

• certification name
• issued on
• expiry
• state
• license type
• license number
• link (for any state that has a link to a verified page)
• verified date status (for IV to approve/verify the certification)
• internal comment/note?