Closed pete-gov closed 4 years ago
I think this is covered by adding "role" in the person profile. If we think this is going to be an issue beyond that then suggest we make this a design ticket to validate it, otherwise suggest we close this ticket.
Ticket might not be clear, this isn't role related - this is for display / text localization and was requested by design. https://usds.slack.com/archives/C019PRYMR0Q/p1603229852319900
@hmyers-cms - are you okay to close this ticket (or to move it out to past MVP if you want to keep it alive)?
I think this came out of the need for us to change the word "patient" to instead say "people". I'm not sure if we got our wires crossed when we talked about what was needed or if I'm misunderstanding what this ticket says.
Changing the word "patient" to "people" on the UI is needed for MVP (and appears to mostly be done already). Additionally we need a way to differentiate between different people types (residents/staff for our first rollout at an LTC), and in the future (not MVP) we may want to be able to customize that by facility (like adding students for schools). The feature seemed pretty important to the users we spoke to in Pima County because staff and residents are on different testing schedules. Open to discussing priority of the feature though @aliciabeckett-gov
Yo this feature will probably take less time to implement than has been spent discussing it.
(sorry, to clarify - I just mean, it's a really low lift feature)
@hmyers-cms - my understanding of this ticket is to change "Manage People" to "Manage X" where X can change by organization. I do not think this is allowing role to be customizable but rather the navigation UI.
My suggestion is we either change this ticket to be change the hard coded string of "Manage Patients" to "Manage People" or close it.
The role should be set person by person, and for now I think we just create a hardcoded list of options (staff, resident, student, etc.) I do not think we need anything beyond that for MVP, but let me know if you disagree @hmyers-cms. If you decide we should not close this ticket can you update the description to make it more clear what the change is?
I grabbed this ticket to get started on something.
Changing the name used in the UI does seem easy enough. Note that the route (the URL in the browser bar) shows the word patient
still though. Is that going to be a problem? Can we change to something sufficiently generic that it covers all humans who might be tested regardless of their role? If so what would that word be? Maybe people
is a better word for that.
@aliciabeckett-gov I disagree with the idea that "manage people" should be "Manage X". That seems unnecessary because "People" works fine as a generic term across all facility types. And re-reading the original Slack message that doesn't seem like what we were trying to do. It was two separate things.
(@pete-usds I get your point, sorry to keep beating this horse, but I just want to make sure we are all on the same page! :) )
More of a devs thing but we use "patient/patients" extensively in the current code for our variable names and data structures. We can change the UI and even the URL to match "people" but it could be confusing to refer to people as patients within the code.
@aliciabeckett-gov I disagree with the idea that "manage people" should be "Manage X". That seems unnecessary because "People" works fine as a generic term across all facility types. And re-reading the original Slack message that doesn't seem like what we were trying to do. It was two separate things.
- Update the word "patient" to "people" everywhere that it appears on the UI
- Add the ability to tag people as either "staff" or "residents", as represented in the design (attached)
(@pete-usds I get your point, sorry to keep beating this horse, but I just want to make sure we are all on the same page! :) )
Agreed. Can we update this ticket to reflect that?
I think we should just stick with the original ticket, there were good reasons for suggesting that implementation and it was intended to reduce work and allow a cleaner implementation from the technical side.
The ask in the ticket wasn't to worry about urls/routes initially, but just to focus on simple management of these terms. There are a few of them to isolate out initially, but this type of localization is going to be necessary in this app and implementing it the first time will save us work in the long run.
The original ticket was very simple and involves minor changes in a few files.
Here's an example PR: https://github.com/CDCgov/prime-data-input-client/pull/40
Fixed "New Patient" placeholder button / unused var imports / some formatting suggestions from Dave's feedback / tests passed / merged. Work on this issue is initially complete, if we missed any renames we can flag them as bug for fixing!
Different organizations may want to use different terms to refer to the individual whose information is being tracked by the Data Input app. This may include patient, person, student, resident, and more.
Feature Request
patientTerm
or similar that is available to all pages{{patientTerm}}
)Acceptance / Review Criteria
There will be a file in the application where the
patientTerm
constant will be set toperson
and all references topatient
in the current UI will instead showperson
- and any changes to this will be immediately reflected in the UI on reload.patientTerm
that all instances on every page was changed to something else