Data isolation/namespacing in caching layer

[jnak]

Last week, Flexpa announced that it would update how it namespaces FHIR resources in its upcoming data cache. It will isolate data at the application level rather than at the Link access token level. This is a great improvement as it allows clients to get the same stable IDs for resources as a user refreshes a Link or creates a new Link. Clients can now easily track how an EOB evolves over time.

However, the new design means that the same ID will be returned for the same FHIR resource regardless of who has authorized the Patient in the family. This could lead to PHI leakage because, to comply with HIPAA, payers normally have to implement access control logic (ACL) within a family. For example, the policyholder of a plan may not be able to see the EOBs of their spouse or dependents over 18 years old. From the HHS website:

The Privacy Rule does not require a health care provider or health plan to share information with your family or friends, unless they are your personal representatives.

However, the provider or plan can share your information with family or friends if:

• They are involved in your health care or payment for your health care,

• You tell the provider or plan that it can do so,

• You do not object to sharing of the information, or

• If, using its professional judgment, a provider or plan believes that you do not object.

For those reasons, as a policyholder, you don't get to see the EOBs for your entire family when you log into your insurance portal. You will see the accumulators for your family and sometimes scrubbed EOBs to help with payment. Anecdotally, I worked on a project defining and implementing these access control rules at Oscar Health.

If payers implemented the ACL in the API, the new Flexpa isolation scheme could lead to unintended PHI leaks. For example, if a spouse fetches their own Patient records, and then the policyholder fetches the Patient record for their spouse, the policyholder would currently access all the cached records that were previously fetched by the spouse, completely bypassing the ACL of the payer. If the spouse had told their payer that the policyholder should not be able to see a specific EOB and the payer had hidden that record from the policyholder, the policyholder could still see that EOB through Flexpa.

Unfortunately, the CARIN specs do not mention anything about ACL in their implementation, so access control is currently left to the payers' discretion. As far as I know, none of the test accounts listed by Flexpa share some family data so we are left to use production data to understand each payer's implementation. Since Flexpa does not cache any data and their API currently does not differentiate between who is authorizing access for a Patient, we have no data points except for a few anecdotical reports from Flexpa's employees or Flexpa's customers; usually people on Anthem / Empire since it's the main commercial insurer who supports those Patient access API.

Given that (1) Flexpa has seen tremendous variability in payers' API implementations and that (2) HIPAA compliance is considered a top priority by payers, Flexpa should design its isolation system to prevent PHI leakage when payers implement ACL. It is very possible that no payers implement ACL in their Patient APIs today, but as those APIs get adopted, there will be some public blowback around PHI leakage that will inevitably lead to ACL being implemented in those Patient APIs, either independently or via an update to the CARIN specs.

To account for this, we're proposing that Flexpa allows clients to pass an optional userId to FlexpaLink.create so it can isolate FHIR resources at the level of the application and the user who created the Link (i.e. the user who authorized the access). The benefits of this approach:

1. Future-proof: There will never be unintended PHI leakage within a family, and Flexpa can guarantee it won't ever have to update its ID scheme to honor payers' ACL. The latter would be very disruptive for clients for the reason listed in the introduction and because they would have to redesign their production system after the fact.

2. Visibility: Flexpa gets visibility into how payers are dealing with ACL. Currently, Flexpa is completely in the dark and has to rely on anecdotal reports from customers.

3. Required: Unfortunately, clients have no way to implement this isolation system on their own and are completely dependent on Flexpa for this.

4. Optional for clients: Only clients who are paranoid about PHI leakage like us can use the system.

5. Simple: If Flexpa was able to move from the previous isolation scheme to the new one in a week, it's probably a low lift to add an extra parameter to their ID generation scheme.

Please, let us know what you think.

[healthbjk]

Hey Julien,

Thanks for the detailed request.

However, we wanted to clarify that today, Flexpa limits access based on the patient access token that is used to make a request. The access is therefore identical/transitive to what is implemented by the payer.

For those reasons, as a policyholder, you don't get to see the EOBs for your entire family when you log into your insurance portal.
Today, we do see policy holders able to access EOBs for their entire families via both the API and member portals. The access provided via our API therefore matches the ACL the payer has implemented.

If payers implemented the ACL in the API, the new Flexpa isolation scheme could lead to unintended PHI leaks. For example, if a spouse fetches their own Patient records, and then the policyholder fetches the Patient record for their spouse, the policyholder would currently access all the cached records that were previously fetched by the spouse, completely bypassing the ACL of the payer. If the spouse had told their payer that the policyholder should not be able to see a specific EOB and the payer had hidden that record from the policyholder, the policyholder could still see that EOB through Flexpa.

In the event that a payer implemented the ACL you describe, where a policy holder can authorize access to a dependent but can only retrieve a subset of information, no PHI leaks could occur. The current access control based on Patient Access Tokens would result in:

1. The spouse would authorize directly. Flexpa would fetch Patient, Coverage, EOB, and any other resources available, tagging them with the Patient Access Token.
2. The policy holder would authorize for the spouse. Flexpa would fetch what is available via the ACL (the Patient and Coverage resource, for instance), but not EOB. The Patient and Coverage resource would be tagged with the new Patient Access Token (PAT 2). 3. Only those resources (Patient and Coverage) would be available when an API request is made with PAT 2.

In this way, no PHI leaks could occur.

Regardless, we do think a feature in this area could be valuable and relatively reasonable to allow customers to:

1. Pass in metadata via the API
2. Augment retrieved resources with this metadata
3. Optionally limit access to data based on this metadata

We'll work on the API design and let you know what we're thinking shortly.

[jnak]

Would that meet your needs? Or would you need to pass in some other data type, for example a user object?

Got it. externalUserId works great. This is the only parameter we need to address the isolation issue, provided you update the ID scheme (see below).

Do you have a preference on any of those 2 approaches?

We have a big preference for using externalUserId as an input in the resource UUID as it makes things a LOT easier for us to keep data isolated.

Without this, we would need to transform and replace manually all the IDs we get from Flexpa to isolate date directly in our FHIR datastore (i.e. Medplum), which is a big lift, as you probably know ;) The alternatives would be to either (1) maintain in a separate database a mapping of all users to all the versions of FHIR resources they own or (2) somehow filter out FHIR resource versions based on the value of the meta tag (which is not supported by the FHIR spec); in both cases, it would make querying the data very cumbersome. Notably, we could not use FHIR GraphQL.

Sorry for getting in the weeds here, but hopefully, you better understand why we would much prefer Flexpa to incorporate the externalUserId in their UUID scheme.

Thanks!

[dylman123]

Thanks for your feedback and no need to apologize about getting in the weeds. The more detailed the feedback, the better we understand the problem.

Ok I will take this back to the team!

[dylman123]

Hey @jnak some good news!

We have released a new feature that allows developers to pass a user object to the create method of FlexpaLink.

When a user object is provided, all of the resource UUIDs that belong to the user are namespaced to that individual user.

Please feel free to start using the feature - as we'd love to know how it meets your needs and what we can improve.

Eager to help!

[jnak]

That's great to hear! We'll try it as soon as the caching layer is live. We'll report back then. Best!

[dylman123]

For the purpose of the public forum, the caching layer is now live! See details here.

[healthbjk]

Closing this as implemented. See details here.