Healthcare and HIPAA
The code that handles patient data, reviewed where it already lives.
A Security Rule review comes down to one question asked six ways: where does patient data go, and who can reach it. Your application code is the only complete answer, which is exactly why handing a copy of it to an outside service starts a second conversation you did not want. Vulkro reads that code on your own machines and produces the evidence without the copy.
- Built on the Safe Harbor identifier list
- Security Rule citations on findings
- No copy of your code is taken
- Runs inside the hospital network
01 / The Security Rule conversation
Six questions, asked of the application code
The technical safeguards are short. Translated out of regulatory language and into what somebody actually opens a file to check, they read like this.
| The question | What the review looks for |
|---|---|
| Can one patient record be reached with another patient’s session? | Endpoints that load a record by identifier and never check that the caller is entitled to it, and endpoints sitting beside guarded siblings without the same guard. Every route the application declares is inventoried first, because a route nobody mapped is a route nobody checked. |
| Is patient data protected where it rests and where it moves? | Health fields declared on a model with nothing encrypting them, and obsolete algorithms or transport settings on the paths those fields travel. |
| Is access to patient data recorded? | Reads and writes of patient tables with no audit event emitted at the same place in the code. An audit trail that depends on a middleware nobody applied to this route is the common failure. |
| Does patient data end up where it was never meant to be? | Identifiers reaching log lines, identifiers carried in URL paths (which puts them into proxy, load balancer and content delivery logs), and analytics or export paths that skip de-identification. |
| Are clinical and provider codes committed into the source? | Provider identifiers, diagnosis codes and procedure codes written into files rather than loaded from a reference store. Fixtures and seed data are the usual home for them. |
| Which outside services receive patient data? | Error trackers, analytics pipelines, support tooling and model providers receiving fields that carry patient data. This is the list your counsel checks agreements against, and it is section 03 of this page. |
None of these are healthcare inventions. What is specific to healthcare is the identifier list that decides which fields the questions apply to, which is the next section.
02 / What counts as patient data
An identifier list, not a list of likely-looking words
Healthcare is the sector where the regulator wrote down what counts. Eighteen identifiers, and the rule that any one of them bound to health information makes the whole record patient data.
The review is built around that list rather than around a vocabulary of medical-sounding words. It covers the obvious entries and the ones teams forget: the national identifier schemes used outside the United States, biometric identifiers, precise location, licence and certificate numbers, and dates tied to an individual. A field carrying any of them, sitting on a model that the rest of the code treats as clinical, is patient data whatever the column happens to be called.
Detection is structural. The scanner reads model definitions, serializers and response shapes and follows what they actually emit, rather than searching files for words that look sensitive. That is what lets it tell the difference between a field named for a patient and a field that reaches an outside system carrying one, and it is why a renamed column does not make a finding disappear.
The interesting failures are almost never in the database schema. They are in the places patient data leaks out of the shape the schema promised.
- Log lines
- A medical record number in a log line is patient data in your log retention, in your log shipper, and on the screen of whoever is on call. It is also the leak that survives longest, because logs outlive the request by months.
- URL and route paths
- An identifier in a path is captured by every proxy, load balancer and content delivery network between the browser and your application, none of which you chose for their retention policy. The fix is an opaque identifier in the path and the real key in the body.
- Analytics and export paths
- A reporting export or a data-warehouse feed that was built before anyone wrote the de-identification step, and then shipped without it. The Safe Harbor list is what decides whether the export is de-identified, and a partial removal is not a partial pass.
- Fixtures, seeds and migrations
- Real provider identifiers and clinical codes committed into test data during an integration, then inherited by every fork of the repository. This is patient data in your version control history, not in your database.
- Error trackers and third-party tooling
- A crash report that carries the request body, a support widget that captures a session, a model provider called with the record attached. Each is a destination that has to be covered by an agreement before it receives anything.
- Responses that return more than the caller asked for
- A serializer that returns the whole record because filtering it was somebody else’s ticket. The identifier list is checked against what the response actually carries, not against what the endpoint was documented to return.
03 / Business associates
The agreement question runs in both directions
Healthcare is the only sector on this site where the regulator names the vendor relationship itself and puts a contract around it. That cuts two ways, and the review is useful on both.
Outward, about the tools you buy. An analysis service that ingests your application code receives, in practical terms, a description of how patient data moves through your systems: the schemas, the access rules, and the paths between them. Whether that makes the vendor a business associate is a question your counsel answers, and the conservative reading most healthcare counsel take is that if the recipient could reconstruct how patient data flows, they get listed. Either way it becomes a review, an agreement and a renewal date.
Vulkro receives no code. The binary runs on your machine or your build runner, reads files on your filesystem and writes a report next to them. There is no upload step and no service on the far side holding anything, so there is no exchange of patient data to govern. That is a fact about the architecture rather than a legal opinion: whether your organisation still wants an agreement on file is your call.
Inward, about the services your product calls. The harder version of the same question is which outside services your own code already sends patient data to. Error trackers, analytics, support tooling, model providers: each one is a destination somebody added in a sprint, and each needs an agreement before it receives anything. The review flags the places patient-carrying fields reach one of those destinations, which turns an unanswerable question into a list your compliance team can work through.
The practical difference for an engineering team is timing. A tool that takes a copy of the code waits behind a vendor assessment before anyone can run it. A tool that takes no copy can be evaluated this afternoon, on a laptop, against a real repository.
04 / The evidence
Findings arranged against the Security Rule
The evidence pack maps what the scan found onto the Security Rule paragraphs those findings bear on, and writes it as files you can open, archive and compare with last quarter.
| Control | What it covers | Status | Findings |
|---|---|---|---|
| 164.312(a)(1) | Access control | Fail | 3 |
| 164.312(c)(1) | Integrity of patient data | Partial | 2 |
| 164.312(e)(1) | Transmission security | Partial | 1 |
| 164.308(a)(1)(ii)(D) | Information system activity review | Pass | 0 |
A control fails when a high or critical finding maps to it, comes back partial on lower-severity findings, and passes when nothing maps to it at all. That last case is worth reading carefully: it means nothing was matched, which is not the same as nothing being wrong, and the pack says so on its own front page before a reader reaches a finding.
This is a category mapping rather than a control-by-control assessment, and it is the right level for knowing where your gaps are before an audit starts. It does not attest your administrative or physical safeguards, it does not review your risk analysis or your agreement chain, and a clean result does not make an application compliant.
Everything else about audit evidence is shared with the other regulated sectors and lives one level up: what an auditor asks for, which frameworks are mapped, and why none of it requires sending your code anywhere. The full HIPAA control mapping is in the compliance docs.
The review, and the red team
Vulkro reviews your codebase. Vulkro for Salesforce reviews your Salesforce build, which is where a lot of healthcare runs: Health Cloud, the org settings behind it, and the data bridged out of it. Vulkro Red is the other half of the team, taking what the review found and working out what an attacker would do with it.
Reviews your code
Goes through every line of your codebase before a release, the way a senior engineer would if they had the time, and tells you what a customer could exploit.
Reviews your Salesforce build
The same review for the part of your business that runs on Salesforce, including the settings in the org itself, and what the AppExchange security review will ask you for.
Attacks what they found
Takes the review and works out what an attacker would actually do with it: which small problems chain together into a real break-in, and which ones are noise.
One engine behind all three, so the red team works from what the review already foundIt all runs on your machine. Your code never leaves it.