PHIPromise

[Crisfole]

This is something I want:

Sometimes I want to capture PHI at a certain point in time, but not use it until the future (capture before/after data, send it).

Being able to grab phi into a Promise like object and then record the access when (and if) it's actually accessed would be really useful.

# Data accessed, but Access not recorded:
before_promise = phi_object.capture_phi { |po| { secret: po.phi_protected_field } }

if update_protected_fields(phi_object)
  # Access Recorded (data *not* freshly recorded):
  before = before_promise.result
  # Data accesed *and* access recorded:
  after = phi_object.allow_phi { |po| { secret: po.phi_protected_field } }
else
  # Since before_promise.result was *not* called, the access was not logged
end

[wkirby]

I'm not 100% clear on what this request is. Two things:

1. In the example code, before is never used. What is the reason for capturing the before variable?
2. Access isn't logged until data is actually accessed: calling allow_phi! just toggles whether or not the value can be accessed, but the actual logging isn't triggered until the attribute method is called. If an attribute method is never called, access is never logged, even if it was allowed.

[HenryKeiter]

@wkirby For 1, it's a toy example so he's just touching the PHI result there to trigger access logging. Probably he means phi_object on line 8 to be before.

As for 2, the answer is in where Chris has put the logging comments. In the example, data access would currently be recorded on line 2, from po.phi_protected_field. However, that data might not actually ever get used, as shown by before_promise only appearing within a conditional. So the idea here is not to log access until the data is used in a meaningful way. The real use case would obviously be buried several layers deeper than this, where "just don't touch the values until you definitely want them" is more complex. Something like "set up a webhook to fire off this PHI payload" where the hook in question may never actually be run—we might really want to log that second access but not care about the first, IMO.

I'm not actually entirely sold on this yet, but I think it merits some exploration. At the very least we should be thinking about what we consider "access" within our model.