FHIR isn't a company's product, and it isn't a government invention. It comes out of HL7 International — a nonprofit standards organization (the name is short for "Health Level Seven") where the people who build and run health systems argue, draft, vote, and publish. Think of it like the body that standardizes Wi-Fi: no single vendor owns it, and the standard matters because everyone agreed to it.
How a standard actually gets made. Volunteer work groups — clinicians, payer engineers, EHR vendors, government staff — draft a specification. It goes to ballot: members comment and vote, authors reconcile every comment, and the spec republishes. Standards graduate through maturity stages you'll see stamped on every page: draft, STU ("Standard for Trial Use" — stable enough to implement, still allowed to change), and eventually normative (locked; breaking changes essentially prohibited). When you hear that an implementation guide is "STU 2.2," that's this system talking.
Where Da Vinci fits. General-purpose FHIR says what a Claim looks like. It doesn't say how a payer and provider should conduct prior authorization. That gap is filled by implementation guides (IGs) — rulebooks that profile FHIR for a specific job. The Da Vinci Project is an HL7-hosted collaboration of payers, providers, and vendors writing exactly those rulebooks for payer workflows: PAS for prior-auth submission, CRD for coverage rules, DTR for documentation requirements, and more. The guides this site's validator checks payloads against — Da Vinci PAS 2.1.0 and 2.2.1 — are products of that process.
Where the government fits. Regulators don't write the standards; they adopt them. CMS and ONC rule-making (like CMS-0057-F) points at specific HL7 FHIR guides and says: payers in federal programs must implement these, by this date. That's the handshake that turns a volunteer-balloted document into a compliance deadline — and it's why a ballot cycle that seems arcane can quietly determine what half the industry builds next year.
The honest caveat: balloted doesn't mean finished. STU guides change between versions — sometimes in ways that break payloads that used to pass. That's precisely why this site's workbench validates against multiple versions of the same guide and shows you what changed between them.