· ReadyStack
Worked example
Real numbers from this tool, line by line.
A US Core Patient resource pinned to 3.1.1 is 260 days past the line, and the health IT developers shipping it in Boston, Nashville and Madison mostly do not know, because it validates clean.
That is the whole trap. Hand the official HL7 validator a resource whose meta.profile says us-core-patient|3.1.1 and it will tell you it is valid. It is - a valid USCDI v1 resource. Nobody asked it whether that profile is still the floor.
Since 2026-01-01 it is not. USCDI v3, at 45 CFR 170.213, is the data set certified health IT has to carry, and Health IT Modules seeking certification to criteria referencing that section had to be capable of exchanging it by 2025-12-31. USCDI v3 is not a cosmetic bump over v2 either: it brought in elements the earlier versions never had, among them gender identity and social determinants of health. A 3.1.1 pin is not one version behind. It is the USCDI v1 element set, two whole data sets back.
Stale pins keep appearing in new code for a reason. US Core 3.1.1 is the version most public FHIR examples on the internet were written against, so ask an assistant for a US Core Patient and 3.1.1 is what comes back: right shape, wrong version string. The one part nobody re-reads on review is the URL after the pipe.
US Core Profile Gap Check is a VS Code extension that reads the FHIR R4 JSON in your workspace and answers what the validator will not. It carries 10 rules. Two are the version pins: 3.1.1 as USCDI v1, 5.0.1 as USCDI v2, both resolved against a US Core 6.1.0 floor. One catches a US Core profile claimed with no version at all - the quieter failure, because nothing in the file then proves which USCDI version you meet on test day. One catches a US Core resource type with no us-core profile anywhere in it. Two catch pre-R4 wreckage: STU3 and DSTU2 artefacts, and retired v2 and v3 terminology URLs. Two read Patient demographics, looking for us-core-race with us-core-ethnicity, and for us-core-genderIdentity. One reads CapabilityStatement.fhirVersion and expects 4.0.1. The last flags a meta block with no lastUpdated, which a surveyor cannot date.
The numbers here are measured, not estimated. Two fixtures ship with the extension. The clean one holds a US Core 6.1.0 Patient with race, ethnicity and gender identity, a 6.1.0 Condition and a 4.0.1 CapabilityStatement: 0 findings. The dirty one is a Bundle of 4 resources exported from an older stack: 9 findings, 6 errors and 3 warnings, hitting 9 of the 10 rules. Both were scanned at today = 2026-09-18, which is how the report knows the line is 260 days back.
Getting the clean fixture to 0 took one real fix. A first pass treated every us-core StructureDefinition URL as a conformance claim, so the three extension URLs on a correct Patient - race, ethnicity, gender identity - came back as three unpinned profiles. Only meta.profile is a claim; a StructureDefinition URL under an extension url is a definition reference and carries no version. The scan now reads only the profile arrays, and the clean Bundle returns 0 instead of 3.
It recognises 23 US Core resource types, runs offline, and no PHI leaves the machine. The free tier finishes the job on screen: every gap, every resource, its own line, the USCDI version that pin actually meets. No key, no file cap, no watermark.
What a person costs for the same pass: a US FHIR consultant averages $49.72 an hour, with most between $24.28 and $62.50, on ZipRecruiter figures published 31 July 2026. Opening each resource and checking its pin against the US Core 6.1.0 element list is an afternoon on any repository a few years old.
15 seconds — what it actually does
Questions people ask
What does US Core Profile Gap Check actually do?
It reads the FHIR R4 JSON files in your workspace and applies 10 rules. It flags meta.profile pins on US Core 3.1.1 (USCDI v1) and 5.0.1 (USCDI v2), profiles claimed with no version at all, pre-R4 STU3 and DSTU2 artefacts, retired v2 and v3 terminology URLs, Patient resources missing race, ethnicity or gender identity, and a CapabilityStatement whose fhirVersion is not 4.0.1.
Who is this for?
Health IT developers and FHIR integration engineers at US EHR vendors, payers and digital health companies. If your product carries an ONC certification, or you are preparing a Health IT Module for testing, you are the reader. It recognises 23 US Core resource types, so it fits a working repository rather than a single sample file.
Why will a free FHIR validator not catch this?
The official HL7 validator checks a resource against whichever profile you hand it. Pin us-core-patient 3.1.1 and it will happily tell you the resource is valid, because it is valid against USCDI v1. Nothing in that run says the version you pinned stopped being the certification floor on 2026-01-01.
What is free and what needs the full version?
Free finishes the job on screen: every gap in every resource, on its own line, with the USCDI version that pin meets. On the dirty sample shipped with the extension that is 9 findings, 6 of them errors. The full version exports the same scan as one conformance report file you can attach to a certification or a customer audit.
What does it cost to do this by hand?
A US FHIR consultant averages $49.72 an hour and most earn between $24.28 and $62.50, according to ZipRecruiter figures published on 31 July 2026. Opening each resource, reading the profile pin and checking it against the US Core 6.1.0 element list is an afternoon on any real repository. The full version is $29 once.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. US Core Profile Gap Check (USCDI v3) checks the file you open against 10 rules from a rule set dated 2026-09-20, and points at the exact line. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.