On using Temporal Cloud for HIPAA compliance(before it achieves HIPAA compliance)

[rabraham]

Hi,
I understand that HIPAA compliance for temporal cloud is in the roadmap but no ETA yet(Slack)

Since we have to be HIPAA compliant and we are evaluating Temporal, we may mostly run it on-premise.

But I was wondering if the following steps though manual and error prone can mitigate the lack of HIPAA compliance on Temporal Cloud:

• I understand workflow definitions store input and output arguments. But if we don’t pass PHI in these arguments, then it won’t be stored in the Temporal Cluster. We could technically pass ids to refer to customers which is fine as per HIPAA

• use of custom Data Converters to encrypt the data. If we use this for every workflow/activity function, then we should be good? Are there cases, where we can’t apply data converters? What is a Data Converter? | Temporal Documentation

Open Questions:

• In the 101 course, it says, we learn about the ctx workflow.Context argument. For Python, does this context object store state about a particular worker and send it to the Temporal Cluster? If so, would it contain intermediate worker state which contains PHI. This seems like some advanced stuff but I have seen Sentry store ‘breadcrumbs’ about the application(which can be turned off) where we leaked PHI sometime in the past for e.g text’ to the workflow. So I thought I’ll ask
• I’ve only done the 101 course. What am I missing about mitigating the lack of HIPAA compliance in temporal cloud

[Chad_Retz]

@rabraham

We could technically pass ids to refer to customers which is fine as per HIPAA

Yes, you are the source for all your data, so you can choose what to pass and what not

@rabraham

If we use this for every workflow/activity function, then we should be good? Are there cases, where we can’t apply data converters?

For the most part, yes, you’re good. The only payloads we don’t encrypt, for indexing purposes, are search attribute payloads. Also, other user-defined identifiers such as workflow IDs and workflow/signal/query/activity names are plain text, so be careful what you use to build those identifiers. Otherwise, yes, all input/output can be encrypted end to end.

@rabraham

In the 101 course, it says, we learn about the ctx workflow.Context argument. For Python, does this context object store state about a particular worker and send it to the Temporal Cluster?

That context is a Go, client-side thing only. We achieve similar in Python with contextvars. It is not sent to the server. All intermediate state remains in local memory.

@rabraham

What am I missing about mitigating the lack of HIPAA compliance in temporal cloud

I am afraid I don’t know enough about HIPAA and our cloud to have a good answer here. I’ll defer to others.

[Jnak]

@rabraham

use of custom Data Converters to encrypt the data. If we use this for every workflow/activity function, then we should be good? Are there cases, where we can’t apply data converters?

Our understanding is that encrypting PHI is not substitute for Temporal being HIPAA-compliant / signing a BAA. For data to be considered de-identified / de-anonymized in the HIPAA world, the data needs to be irreversibly anonymized, so that if there is a breach, the data cannot ever be used to identify the individuals.

We’re also interested in having a relatively easy solution to be use Temporal in a HIPAA compliant way. Either a HIPAA-compliant cloud version, or a pulumi/terraform provider to easily self-host it on AWS. Can we expect to see any movement on that in the next few months?