Of course, it's just as likely, this already being a government program and a massive overreach at that, that your identifying data is stored in plain text. I just wanted to throw out it's possible it's not.
Think about the inputs of the mechanism you just described though. Presumably the goal of the "secure hash" is to prevent government workers from grabbing samples of specific people to do whatever with, so let's break it down. To calculate this hash you apparently need:
1. The name. If you're going after a specific persons sample, you already know this.
2. The date of birth. I don't know when this program started, but if you're alive today you definitely aren't more than 43,830 days old (365.25 * 120).
3. The hospital. I have no idea how many hospitals exist or have existed in California, but lets say there's been 100,000.
So the total number of possible hashes given only the name is 4,383,000,000. Sure, you could salt it as well, but the people we're trying to defend from have access to the DB and thus the salt, so we gain nothing from that. Here's some hashcat benchmarks: https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...
Looks like 1000MH/s is a reasonable rate to be able to process sha-512 hashes, so according to that benchmark you should be able to generate the complete rainbow table in about...4 seconds.
It's probably longer given drive speeds and such, I've never actually tried to do what I'm describing, but it does seem like a less-than-one-work-shift process to calculate the hash of a specific person on commodity hardware if that's the only three inputs required. If that's the case, hashing it hasn't made it anonymous.
Possible, but unlikely, given that this is the government we're talking about.
Also, even if they were hashed like that, I just gave them that identifying information as part of the destruction request.