Extended Access Policies

[rahul1]

The Problem

We've encountered a few access policy scenarios that don't fit neatly into our meta.account framework for defining access compartments. The two settings where this comes up are:

• Pediatrics: Managing access between caregivers (including non-parents) and children
• Virtual Care Clinics: Assigning patients to physicians / care teams.

In both these cases the access model resembles a bi-partite graph structure, and breaks the key assumption of meta.account - that a user will only be part of a single compartment at a time.

Example 1: Pediatrics

The first example is pediatrics where one parent has access to multiple childrens' compartments, but others parents only have access to one child's compartment. This can happen, for instance, in families with divorced parents. In this case, parents are logging into Medplum, but the children are not

In this case, there is no clear way to draw organize the resources with a Group resource, and we can't use the Patient id as the meta.account value, since Parent 1 needs access to both children.

Another nuance is that different parents might have different access levels. One of our customers has a 2-tier system. "Primary users" can read and write data to Patient records. "Secondary" users only have read access. They
might also have access to fewer resource types than the primary user.

The other nuance this customer would like to support is account promotion. In this case, when an parent's account is "promoted" to a primary account, it should maintain read-only access to its previous child, but have read/write access to a new child that they enroll.

Example 2: Virtual Clinic

A similar model occurs in the "virtual clinic" setting, where providers might only have access to a subset of patients "assigned" to them. In this setting, there often aren't different tiers of access, but there are different organizational groupings.

• Many-to-many model: Physicians are can access patients "assigned" to them
• Care team Model: Every patient has a CareTeam assigned to them. Physicians are added and removed to the CareTeam as needed, and everyone in the CareTeam
• Cross Organizational Model: The Medplum user has multiple "client organizations", which of which has it's own patients. Physicians can be assigned to one or more organization, and then see access all patients within an organization the are assigned to.

Example 2a

Example 2b

Example 2c

Proposal

@codyebberson and I had a discussion offline about revisiting the conversation about access policy inheritance. The high level picture is that you would define an Access Policy "template", that would specify the access rules for a patient's compartment. This template could then be instantiated for each (patient, user) pair.

We could potentially create a new resourceType, AccessPolicyDefinition, to represent the template.

{
  "id": "parent-secondary",
  "resourceType": "AccessPolicyDefinition",
  "name": "Parent (secondary)",
  "resource": [
    {
      "resourceType": "Patient",
      "readonly": true,
       "compartment": "%patient",
    }
  ]
}

And the corresponding access policy could perform some kind of variable replacement like this (@codyebberson - please sanity check me on this)

{
  "resourceType": "AccessPolicy",
  "name": "Parent (Homer Simpson)",
  "instantiates": [
    {
      "definition": {
          "reference": "AccessPolicyDefinition/parent-secondary"
       },
      "params": [
           "name": "%patient",
           "valueReference": {
               "reference": "Patient/bart-simpson"
            }
        ]
    }
  ]
}

Open Questions

• Should a single AccessPolicy be able to instantiate multiple AccessPolicyDefinitions (as show above), or should we create multiple AccessPolicy resources, one for each (patient, user) pair. Keeping 1 AP per user seems easier to manage, but 1 AP per pair seems like it would be a more incremental change.
• When does the concrete access policy get created? When the ProjectMembership is created? Or is this a client responsibility? Or both?
• Should AccessPolicyDefinitions be able to inherit from other AccessPolicyDefinitions to created deeper hierarchies?

[codyebberson]

Thanks @rahul1 for putting this together!

Overall, I think the broad strokes make a lot of sense.

With regards to the questions about multiple inheritance... My preference would be to keep it as simple as possible unless we see hard limitations.

I was thinking about how we could potentially minimize the migration cost, and here's a slightly tweaked proposal:

1. Shift AccessPolicyDefinition back to AccessPolicy
2. Shift AccessPolicy.params into ProjectMembership
3. Perhaps make ProjectMembership.accessPolicy into an array (with gross migration) or add a sibling property for "parameterized access policies" (need to work on the name).

So for example:

Primary Caretaker Policy - read/write access to the patient and select resources

{
  "resourceType": "AccessPolicy",
  "name": "Primary Caretaker Policy",
  "resource": [
    {
      "resourceType": "Patient",
       "compartment": "%patient",
    },
    // ...
  ]
}

Guest Caretaker Policy - read-only access to the patient and select resources

{
  "resourceType": "AccessPolicy",
  "name": "Guest Caretaker Policy",
  "resource": [
    {
      "resourceType": "Patient",
      "readonly": true,
       "compartment": "%patient",
    },
    // ...
  ]
}

ProjectMembership could introduce combination of the above:

{
  "resourceType": "ProjectMembership",
  "access": [
    {
      "policy": { "reference": "AccessPolicy/abc", "display": "Primary Caretaker Policy" },
      "paramer": [
        { "name": "patient", "valueReference": { "reference": "Patient/123" },
      ]
    },
    {
      "policy": { "reference": "AccessPolicy/def", "display": "Guest Caretaker Policy" },
      "paramer": [
        { "name": "patient", "valueReference": { "reference": "Patient/456" },
      ]
    }
  ]
}

This would simplify the number of resources and setup process.

[reshmakh]

Wanted to follow up on this, @rahul1 - did we get the feedback we needed on this?

[rahul1]

We've shared with some customers, and they confirmed their use case but had no feedback on the implementation.

Follow up for me is to walk through the scenarios above and mock what the AccessPolicies would look like for each of the scenarios above.

[rahul1]

Just to sanity check, I'm going to run through all the examples listed above to see how we would implement them

Example 1: Pediatrics

Access Policies (caretaker)

{
  "resourceType": "AccessPolicy",
  "name": "Primary Caretaker Policy",
  "resource": [
    {
      "resourceType": "Patient",
       "compartment": "%patient",
    },
    // ...
  ]
}

{
  "resourceType": "AccessPolicy",
  "name": "Guest Caretaker Policy",
  "resource": [
    {
      "resourceType": "Patient",
      "readonly": true,
       "compartment": "%patient",
    },
    // ...
  ]
}

Project Membership

{
  "resourceType": "ProjectMembership",
  "access": [
    {
      "policy": { "reference": "AccessPolicy/abc", "display": "Primary Caretaker Policy" },
      "paramer": [
        { "name": "patient", "valueReference": { "reference": "Patient/123" },
      ]
    },
    {
      "policy": { "reference": "AccessPolicy/def", "display": "Guest Caretaker Policy" },
      "paramer": [
        { "name": "patient", "valueReference": { "reference": "Patient/456" },
      ]
    }
  ]
}

Example 2a: Many-to-Many

Access policy (physician)

{
  "resourceType": "AccessPolicy",
  "name": "Physician Access Policy",
  "resource": [
    {
      "resourceType": "Patient",
       "compartment": "%patient",
    },
    {
      "resourceType": "DiagnosticReport",
       "compartment": "%patient",
    },
    // ...
  ]
}

Project Membership

{
  "resourceType": "ProjectMembership",
  "access": [
    {
      "policy": { "reference": "AccessPolicy/abc", "display": "Physician Access Policy" },
      "paramer": [
        { "name": "patient", "valueReference": { "reference": "Patient/123" },
      ]
    },
    {
      "policy": { "reference": "AccessPolicy/abc", "display": "Physician Access Policy" },
      "paramer": [
        { "name": "patient", "valueReference": { "reference": "Patient/456" },
      ]
    }
  ]
}

Example 2b: Care Team

This is the trickiest one. The FHIR community explicitly decided that compartments based on indirect messages are not allowed. So I think we'd have to use bots to add/remove access policies when a practitioner enrollsl / unenrolls from a care team.

@codyebberson this probably requires some new endpoints to get/set APs on ProjectMemberships. After that we can use the same model as in 2a.

Example 2c: Cross organizational Model

Access policy

Patient

{
  "resourceType": "AccessPolicy",
  "name": "Patient Access Policy",
  "compartment": {
     reference: "%organization"
  },
    // ...
  ]
}

Physician

{
  "resourceType": "AccessPolicy",
  "name": "Physician Access Policy",
  "resources": [
    {
      "resourceType": "Patient",
       "compartment": "%organization",
    },
   ]
    // ...
  ]
}

Project Membership

Patient

{
  "resourceType": "ProjectMembership",
  "access": [
    {
      "policy": { "reference": "AccessPolicy/abc", "display": "Patient Access Policy" },
      "paramer": [
        { "name": "organization", "valueReference": { "reference": "Organization/1" },
      ]
    }
  ]
}

Physician

{
  "resourceType": "ProjectMembership",
  "access": [
    {
      "policy": { "reference": "AccessPolicy/def", "display": "Physician Access Policy" },
      "paramer": [
        { "name": "organization", "valueReference": { "reference": "Organization/1" },
      ]
    },
    {
      "policy": { "reference": "AccessPolicy/def", "display": "Physician Access Policy" },
      "paramer": [
        { "name": "organization", "valueReference": { "reference": "Organization/2" },
      ]
    }
  ]
}

Example 3: Asynchronous Encounter

See the example data model here: https://www.medplum.com/docs/communications/async-encounters

The main challenge is representing the encounter for the Encounter that represents the "session". This top-level encounter doesn't have a designated Patient as a "subject". However, the participating caregiver would be listed as a "participant".

For the primary caregiver, we could use the special %profile variable to tie the policy to the currently logged in user. For the guest policy, we'd need some kind of business logic to set the access policy.

Access Policy

Primary Caregiver

{
  "resourceType": "AccessPolicy",
  "name": "Primary Caregiver Policy",
  "resource": [
    {
      "resourceType": "Encounter",
       "criteria": "Encounter?participant=%profile",
    },
    // ...
  ]
}

Guest Caregiver

{
  "resourceType": "AccessPolicy",
  "name": "Guest Caregiver Policy",
  "resource": [
    {
      "resourceType": "Encounter",
       "criteria": "Encounter?participant=%primaryCaregiver",
    },
    // ...
  ]
}

ProjectMembership

Primary Caregiver

{
  "resourceType": "ProjectMembership",
  "access": [
    {
      "policy": { "reference": "AccessPolicy/abc", "display": "Primary Caregiver Policy" },
    }
  ]
}

Guest Caregiver

{
  "resourceType": "ProjectMembership",
  "access": [
    {
      "policy": { "reference": "AccessPolicy/def", "display": "Guest Caregiver Policy" },

    },
      "paramer": [
        { "name": "primaryCaregiver", "valueReference": { "reference": "Patient/987" },
      ]
  ]
}

[codyebberson]

Completed in #1520