I am designing a bot to be triggered on a change of a related person (as a part of our family model), and have a few questions about how to prevent race conditions. Essentially, the idea is that when a related person is linked to a "caregiver" patient (establishing a caregiver relationship), we would have a subscription fire a bot and update the caregivers project membership to create the right access policies. Should this type of bot subscribe to Patient changes or RelatedPerson changes? The Link and RelatedPerson are not created in an atomic operation, so we need to avoid race conditions. Any advice would be appreciated 🙏

Great questions! I'll lay out 4 different options. Which one works best for you will depend on: 1) The kinds of updates your client will expect to make and 2) Your atomicity requirements 1.* Subscribe to

Patient

*- If your client is first making the

RelatedPerson

, and then populating

Patient.link

, you could establish the convention that the caregiver does not have access until the

Patient.link

is established. There would still be still be a small window where the caregiver does not have access, until the bot has completed executing, but it should be on the order of milliseconds. Conversely on removal, there were would be a brief window where the caregiver retains access before the bot has completed. You can actually subscribe to changes to only changes on the

Patient.link

element by using Expression Based criteria (https://www.medplum.com/docs/subscriptions/subscription-extensions#expression-based-criteria) 2.* Subscribe to

RelatedPerson

*- Option will not cover the case where

RelatedPerson.patient

is modified. This is uncommon, because what you're saying is that the caregiver retains the same relationship, but to a different patient (e.g. Marge is the mother of Lisa -> Marge is the mother of Bart). Typically, you would create a new

RelatedPerson

for this. A more realistic example, is when customer service fixes clerical errors in the

RelatedPerson

(e.g Marge is the mother of Lisa -> Marge is the Foster Mother of Lisa). Depending on how this affects access, you may want to listen to these changes 3. Subscribe to both

RelatedPerson

and

Patient.link

- If you need to cover both changes in #1 and #2. You can have 2 subscriptions point to the same Bot. In that case, you can treat the type of

event.input

as

Patient | RelatedPerson

@rahul1 With option number 4, how is that secure?

Do you mind elaborating on the potential attack vector?

Can anyone with an access token execute the bot?

By default yes, but the Bot is another resource, so it can be restricted by access policy

And what about the resources that the actual bot code accesses? Is their access token used by the medplum client in the bots handler?

This is optional. - By default, bots are unrestricted - Each bot has a flag called

Run as user

. If it is set to true, then it uses the caller's access token and only has access to what the caller has access to. - Bots also have

ProjectMemberships

, just like

Users

. So you can set an arbitrary access policy directly onto the Bot that is not correlated to the calling user

In this case we would want to run it as a user I think

So, your practitioners won't have access to

ProjectMembership

resources by default, so they won't be able to modify their own access policies. If you run as user, your Bot also won't be able to modify access polcies

Oh hm

If you wanted to use option 4, you could restrict access to the bot such that only providers could execute it, but not caregivers

Ahhh, which for our registration flow - that's appropriate. Thank you rahul!