New fields for practical support?

[colinxfleming]

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.

• What are we trying to do?

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:

• [x] A detail/notes field -- scrambleable/nonexportable -- up to this point we've talked about just using notes, but I think they've made a compelling case for why this is important to be associated with particular elements of care. They're doing a lot of logistical information and coordinating and looking at it JUST against a particular record is helpful. At the very least, could add a practical_support_notes field to the patient model - something severed from the main notes field is helpful.
• [ ] date of purchase -- exportable -- I'm lukewarm on this being crucial (might be better served as a note, or with the attachment field) but I expect this would make the existing date field 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.)
• [x] attachment_url -- idk if exportable or not but probably -- a text field to store receipts uploaded to a fund's google drive or something. I explicitly passed on managing uploads for them which felt out of scope, but we handle google drive links elsewhere in configs and it's fine. I FEEL like this is safe to keep on archive but interested in @lomky 's thoughts.
• [x] fulfilled/paid out -- exportable -- a boolean field, similar to confirmed, but that indicates whether or not they've done whatever, for fund logistics reasons.

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?

[lomky]

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.

[colinxfleming]

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.

[colinxfleming]

Here's the response from client:

for it to be usable on my end I would want to be able to download the receipt itself. We're required by the state to do an audit of our finances each year and one of the things that the auditor does is randomly select expenses from the year for me to back up. I need to be able to link each expense that he pulls to a work purpose (i.e. this McDonalds meal was for a client on March 5th, 2023 after their appointment) and provide him with a receipt. If I can't download the receipt from DARIA to provide to the auditor we would need to save it in two places, at which point being able to save it in DARIA sort of becomes moot.

So I think that is an argument for linking straight up and accepting the risk.

Maybe what I would suggest is:

• Including the URL in export
• Making it extremely clear somehow (config?) that there's an added risk for this, and that clientele should make sure to permission their shit defensively (e.g. in a google drive that only a few people have access to)

@lomky do you think that's a good medium here?

[colinxfleming]

Okay, my plan of attack:

• Add a config for 'turn on including attachment URL'
• add attachment_url as an encrypted field, and fulfilled as a boolean field on practical supports table
• add those both to the practical supports views notes has also been requested, but I think that might be a larger UI change, so I'm gonna keep my powder dry on that for right now