Dan Gonzalez
JD, Health Law Certificate. Building healthcare compliance programs from the inside: writing the policies, designing the controls, running the audits, sitting in the room when the regulator asks.
Establishing the first program
I built Rycan's first formal compliance program in 2013 and served as its HIPAA Privacy and Security Officer. The company handled electronic payments in healthcare, it was growing quickly, and I was the person accountable for the program.
The timing did most of my education for me. HITECH's implementing rule took effect that September and made business associates directly liable for the first time. We were the business associate. Hundreds of provider clients needed their agreements renegotiated against 45 CFR 164.504(e)(2) at once.
The federal government was paying providers to adopt electronic health records at the same time. Every one of those things produced documents, and every one of those documents was read by a person.
We were acquired twice while I held the program. One of those transactions landed inside our SOC 2 Type II observation period, the window in which controls must be shown to have operated rather than merely to exist. An acquisition arriving mid-window means establishing which evidence still counts and who owns which control before the observation can restart. I spent much of that period reconciling lists, and handed the program to operators at a publicly traded acquirer once it was done.
That is where I formed the view I still hold. Not that compliance was broken; the people doing it were good at it. The volume was climbing and the method was one person reading one document, and those two were never going to stay compatible.
The programs that followed
What followed was the same work in different settings. I built programs rather than maintaining ones someone else had built, which means you write the policy and then own what happens when it turns out to be wrong.
One organization where I built the program from nothing and carried it through a HITRUST validated assessment, approving changes to the security architecture along the way. A health plan services company where I built the framework on the Federal Sentencing Guidelines and OIG guidance, and where streamlining state regulatory licensing saved roughly a hundred thousand dollars a year. Multi-state mergers and acquisitions for long-term care facilities, which is regulatory research in every state involved, then securing the approvals. A state health benefit exchange.
Every engagement on this site is work I have done from the inside, at organizations that had to live with the result.
Why I build software
Early on, when I was testing whether AI could handle compliance work, I fed it a business associate agreement and asked it to review. It came back with notes about formatting consistency, a missing signature block, and a suggestion to ensure compliance with applicable regulations. Technically correct. Professionally useless.
The model was not missing information. It knows what 45 CFR 164.504(e)(2) says. What it lacked was any sense of which provisions actually kill a deal, which gaps recur in startup agreements, or what a finding has to say for someone to act on it without a follow-up call. Each of those is a judgment, and I had to make them one at a time and then write them down explicitly enough for a machine to execute.
That became Rote Compliance, which I architected and built solo and use on my own engagements. It reads agreements against the regulation, maps a policy set to framework controls, and runs gap analysis with every finding cited to the document it came from. The skills behind it are open source and have crossed 10,100 downloads on ClawHub, so the method can be read rather than taken on my word.
It is also where I worked out how to deploy generative AI in this work. The model does the mechanical reading. A human signs the finding. I can tell you what an automated pass covers and what it misses because I decided where that line falls.
I built Safe LLM Lab for a related reason: there is a wide gap between what an AI policy document says and how a deployed model behaves, and the only thing that closes it is evidence.
The platform is not currently open for signups, and it is not what is being sold here. It runs as the instrument behind my own delivery, and access is arranged inside an engagement. What you hire on this site is me.
How the work gets done
I work out my own position before I bring anything else to it, whether that is a model, a tool, or a draft. Usually that happens on paper, and the point is not to produce anything. It is to find out whether I have a view worth defending.
After that it varies, some of it is orderly. Some of it stays messy for days. How much correction a thing needs is the useful signal either way, and when it runs high I was less clear going in than I believed.
Before compliance
I grew up in the Pacific Northwest and went to the University of Puget Sound for undergrad, Psychology and Comparative Sociology. My first job out of school was clinical research at the VA in Seattle, where I built and ran the database tracking fourteen thousand biological samples. That was the first system I built to keep regulated data in order. It was not the last.
The engagements are here. The method and the software are at rotecompliance.com.