in your hmac example you have a separate key to manage, whereas in my example, it's implied it's sha256 or a variant that provides a layer of obfuscation in the lookup, and may even implement a "standard" to fool regulators. most regulations and standards say what tools to use (key bits, algos, etc) , and not that the implementations need to be approved by a professional.

my example is that the scheme uses tools in a way that is meaningless because I can just take a phone book, hash the names, and check to see if they are in the cancer database as though it were an cleartext database. to say the data subject's data is private in this case because it is hashed (or often, inaccurately, "encrypted") is to mislead people who make decisions about it. I'm saying the designers of such systems represent themselves as cryptography and security experts who build weakened systems like this to mislead regulators on behalf of their bosses and users who just want the cleartext data.

most protocols are a shell game where if you don't know where the root of trust secret is managed you're the sucker at the table. my experience has been that working cryptographers (protocol designers) in government, health, and financial institutions in general are a very refined class of bullshitters who pound the table whenever you ask them about details, and that one should not be intimidated by their theatrics. Hence in PHI management, dishonest cryptographers working on behalf of anti-privacy interests are the main threat.