If I may add. A model that is normalized a-la SQL and which does not analyze the use-case will most likely caused performance issues.

In your case I would ask:

Do I allow duplicate user names? Probably not.

Do I allow duplicate provider names? Most likely not.

Is changing a user name a frequent use case? Hardly,

Is changing a provider name a frequent use case? That would be confusing.

Is finding data with user name and/or provider name a frequent use-case? I would think so since a provider would like to see its data and ditto for a user.

So in your case I would:

Store the user name and provider name directly in my data keeping or not the _id. Your find data use-case above would become trivial and an order of magnitude faster as it would not invoice $lookup. Yes changing a user name and provider name would be complex and slow. But I prefer simple and fast frequent use-case at the expense of complex and slow rare use-case.