-
Notifications
You must be signed in to change notification settings - Fork 241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New fields for practical support? #3171
Comments
my first impression is that while the data of the attachment_url itself isn't an issue, the linked object itself could serve to re-identify a record as belonging to a particular person, right? i.e. the receipt for a plane ticket has the passenger name. It's not as dangerous as PII on the object itself, but I'm still wary of exporting it. I would lean towards either not exportable, or exportable as 'has attachment/does not have attachment' boolean. I agree with your exportable calls on the other objects. |
yeah that's definitely true. I'll check with the fund and see what they think on this and make sure it doesn't cut too much value. My instinct is probably not, as hopefully by this time it's in quickbooks and not needed anymore. |
Here's the response from client:
So I think that is an argument for linking straight up and accepting the risk. Maybe what I would suggest is:
@lomky do you think that's a good medium here? |
Okay, my plan of attack:
|
Thanks for creating an issue! Please fill out this form so we can be sure to have all the information we need, and to minimize back and forth.
This is a discussion ticket for some practical support work requested by a fund. Their model of practical support has adjusted quite a bit and I'd like us to consider adding some fields on the Practical Support object to support that work. (Practical support is our representation of logistics concerns like bus tickets, airfare, a hotel stay, driving someone to and from their appointment, etc. Some funds use a different name for it that I can't remember off the top of my head.)
Specifically, these fields:
practical_support_notes
field to the patient model - something severed from the main notes field is helpful.date of service
and this would be date of purchase. (My inclination is to pass and tell people to use notes for this, or be insinuated from a receipt upload or something.)I think this entails a bit of frontend work to get all the information in, and would make it the most complicated subobject we have. I think I'm pretty okay with that as this represents (often) the most complicated part of abortion care, so fine to have that granular level of detail here.
What feature or behavior is this required for?
Better practical support utilities
How could we solve this issue? (Not knowing is okay!)
Let's get some thoughts on those issues and their safety, figure out scope, and if so we'll do a quick frontend design and then ticket for hacknite.
Anything else?
The text was updated successfully, but these errors were encountered: