Why we cite our sources

We made a rule when we started writing about compliance: never use a number we cannot link to its source. If we cannot point you to the regulator's own notice, the number does not go on the page.

That rules out most of how this industry markets. The unsourced stat in a hero banner is everywhere, and careful buyers can always tell. We would rather hand you the real record and let you reach your own conclusion. Our sourced risk page does exactly that: it points to the regulator's own public record, and nothing more.

The regulator already did the work

ONC publishes information-blocking policy and enforcement. CMS publishes interoperability disincentive determinations. HHS OCR publishes every HIPAA settlement, every civil money penalty, and every breach affecting 500 or more individuals. ONC-ACBs publish their certification surveillance findings. State Attorneys General publish their privacy enforcement.

All of it is public, specific, and verifiable. None of it requires a vendor to invent.

If a number is worth citing, it is worth linking to its source.

The standards we hold ourselves to

  • Cite the regulator, not our own voice. The public record names names; we point you to it.
  • No number without a direct source link. If we cannot link to the actual notice, we do not use it.
  • No "ROI calculator" with invented inputs. Calculators promise precision the underlying data does not support.
  • No fear on the homepage. Positioning first; the risk record is there for buyers who choose to go look, not a worst-case banner on first paint.

Because you are a peer, not a mark

If you are a CTO, a compliance lead, or a founder reading this because surveillance is coming or a Series B data room is open, you already know the risk exists. What you need is the shape of it: which list would my company land on, where is that list published, and what does the public record actually show. That is what the sourced risk page answers, in the regulator's own words.

What this blog is for

Commentary, reviews, real numbers from public enforcement, and field notes from sixteen years of clinical safety and defect prevention work. Some posts are technical (the engineering bar for a CMS-9115-F Patient Access API, what a real DSI transparency check looks like). Some are strategic (what an audit committee actually asks, what a Series B technical diligence pack should contain). Some are opinion (why patient data ownership is a right, not a checkbox).

Cross-posted to LinkedIn. Reach out if a topic should be on the list.