When talking about the role of public key crypto in creating a secure health data environment, tt is useful to separate transport layer signatures and encryption from message payload signatures and encryption. Mandating end-user keys and certs sets a high bar for the kind of PKI we would need to build. It might be reasonable to demand that of all providers (with a lot of burden), but it could be tough to swallow for patients. Can we make payload signatures and encryption optional, usefully? What about this as a conceptual frame?

Transport layer, between HISPs
  • Keys and certs belong to the HISPs, both sending and receiving.
  • Signature validation
    • Mandatory
    • Failure? SSL connection request halted.
    • "Are you really healthvault.com? Let me see your cert... OK, it's signed by someone I trust, so I'll talk to you."
  • Encryption
    • Mandatory
    • Failure? SSL connection disconnected.
    • To prevent sniffing of sensitive content by other parties.
    • HIPAA requires it.

Transport layer, between HISP and source/destination
  • Mostly defined ad-hoc between HISP and source/dest as their customer
  • Encryption mandatory, and thus signature validation mandatory.
  • [This needs more fleshing out]

Message payload, between source/destination entities.
  • Individual-level keys and certs; can also allow role-based keys/certs.
  • Messages without signatures from the source/destination gets a signature from the source/dest HISP, to validate it came from a user of their system.
  • Signature validation
    • Mandatory
    • Best case: source/destination signature checks out.
      • Assume to be known good content.
      • "This came from a doctor whose signature looks valid, even though I've never met them before, so I'll trust it."
    • Fallback 1: source/destination signature missing, but source/dest's HISP signature validates.
      • Recipient can decide how to handle, but presumed to be good.
      • "This content isn't signed by a doctor's key with a certificate that looks valid; but it was signed by Kaiser Permanente as the HISP, so I'll take a look at it anyways
    • Failure: source/destination signature invalid.
      • Recipient can decide whether to trust the message through other means.
      • "This content isn't signed and didn't come from a valid HISP; but the patient is here in my office telling me these are the charts from the specialist."
  • Encryption
    • Optional
    • Purpose: to keep contents completely confidential between parties.
    • Not required for participation in a NHIN Direct environment, as either sender or recipient.
    • Requires that the recipient have an individual key (and public key is shared with the sender or discoverable)
    • Possible loss of content-level functions provided by an HISP, such as content negotiation
    • Recipient can still decide whether to enter received data into their own EHR or PHR system in unencrypted form so it can be aggregated with other data, or even shared.

The idea here is to allow a simple case where individual providers and patients do not need their own keys and certificates, and HISPs do not need to support them, but can do more things if they have them, and eventually should.