I'm a compliance consultant for early stage startups with tight budgets. I'm not sure how to advise them regarding BAAs for third-party services such as customer support ticketing that aren't meant to collect PHI, but may incidentally. (E.g. "[Covered entity] entered my profile information wrong and I don't know how to change it. It should say...") These subcontractors meet the NIST definition of a cloud service provider, if that matters.
BAAs are often not available at my clients' service level. ZenDesk, for instance, doesn't offer a BAA until the client is paying $2K/mo. They do offer a Ticket Redaction App, but it doesn't purge the original logs of redacted info, so I don't know that we can call them a conduit, since they store any PHI/PII they come across...?
65 FR 82476 seems to establish that "intent" and "probability of exposure of PHI" matter in determining who's a business associate. My clients would prefer that such subcontractors not see PHI, but they haven't removed free-form text boxes where it could be disclosed. Even if my clients instruct users not to use a third-party customer service ticketing system to communicate PHI, it seems unlikely that all users will follow those instructions. Do their efforts constitute appropriate safeguards?
Also, does it matter, in determining whether these vendors are business associates, how my clients configure login (including end users and customer service representatives)? Is knowing end users' email addresses, names, affiliation with a SaaS business associate (my client), and/or non-treatment affiliation with a covered entity sufficient to require a BAA of these subcontractors? Or potentially knowing enough about the customer service reps to socially engineer an escalation to more sensitive info?
OCR's stances on these matters seem to err very much on the side of caution, but my clients would be grateful to find wiggle room that won't be problematic in an audit!