> For the complete documentation index, see [llms.txt](https://docs.dataplex-consulting.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dataplex-consulting.com/data-catalog/medicare-physician-volumes-dataset.md). # Medicare Physician Procedure Volumes ### About the Dataset **Every team that works with Medicare Part B utilization data hits the same wall: CMS hides the rows you most need, and the public file gives you no way to tell hiding from absence.** Any combination of provider, procedure code, and place of service performed for fewer than 11 beneficiaries is suppressed. Counted at the provider-year-code level, that removes roughly 72% of the relationships present in CMS's own pre-suppression counts on the most recent data year. So a missing row might mean low volume, or it might mean no volume, and every ranking, market size, and trend you build on it inherits that ambiguity silently. The **Medicare Physician Procedure Volumes** dataset is NPI-level Part B procedure volumes, payments, and patient mix from the **Centers for Medicare & Medicaid Services (CMS)** **Medicare Physician & Other Practitioners** datasets, covering 116M+ procedure rows across 1.9M+ providers and 9,000+ **HCPCS** codes since 2013. It carries the one thing the public files do not: a measure of how much of itself the data is hiding. Alongside every visible detail row we publish CMS's own pre-suppression totals, so completeness is measurable rather than assumed. That happens at two grains, because CMS suppresses at provider by code by place of service: per provider-year, so you know how much of a physician's practice you can see, and per procedure code, place of service, state, and year, so you know how much of a procedure's market you can see. Those two numbers diverge sharply, and knowing which one applies to your question is the difference between a defensible market size and a misleading one. Each provider is resolved onto an entity-matched spine with validated practice geography, so volumes join cleanly to specialty, group practice size, rurality, federally designated shortage areas, health-centre status, and the breadth of a provider's hospital and facility affiliations. Procedures are classified by **Restructured BETOS Classification System (RBCS)** category, and payments are available as submitted, allowed, and geographically standardized amounts so markets compare like for like. One queryable source for provider targeting, market sizing, practice-setting analysis, compensation benchmarking, access research, and clinical trial site selection. {% hint style="info" %} **Get Full Access** | [Snowflake Marketplace](https://app.snowflake.com/marketplace/listing/GZT1Z7QRT4RP) | [Contact our team](mailto:support@dataplex-consulting.com) {% endhint %} ### What You Get | | | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Procedure volumes at NPI level** | 116M+ rows of service counts, beneficiary counts, and payments by provider, HCPCS code, place of service, and year | | **Suppression measured, not hidden** | CMS pre-suppression totals published beside the visible detail, so you can quantify what is missing per provider and per procedure code | | **Completeness at two grains** | Provider-year coverage for judging a physician's record, plus per-code coverage ratios for judging a procedure's market | | **Resolved provider spine** | Entity-matched NPIs with specialty, credentials, entity type, and group practice size, so volumes join cleanly to provider attributes | | **Validated practice geography** | Standardized practice address with county, CBSA metro, census tract, ZIP, and coordinates for spatial queries | | **Access and equity context appended** | Rurality, federally designated shortage areas (HPSA), medically underserved areas, and health-centre site status on every provider | | **Affiliation breadth flagged** | How many hospitals and facilities each provider is affiliated with, and of which types, as a measure of practice setting rather than a facility roster | | **Procedures classified** | Restructured BETOS (RBCS) category and family on every procedure row, so a practice can be summarized by clinical category rather than raw code | | **Payments comparable across markets** | Submitted, allowed, and geographically standardized payment amounts, so geography-adjusted differences do not distort market comparisons | | **Coverage** | Every US state, DC, and all five territories. Procedure history since 2013 | | **Refresh cadence** | The provider spine and practice geography refresh weekly as the source registry publishes. Procedure volumes are annual, on the CMS publication cycle | **Consumer tables** (7 in the share): * **Procedure detail**: `PROCEDURE_VOLUMES`, `PROCEDURE_BENCHMARKS` * **Provider level**: `PROVIDER_VOLUME_SUMMARY`, `PROVIDER_VOLUME_PROFILE` * **Evaluation**: `TRIAL_COHORT` * **Metadata**: `SOURCE_VINTAGES`, `DATA_DICTIONARY` ## Overview The Medicare Physician Procedure Volumes dataset provides analytics-ready access to Medicare Part B utilization at the individual provider level, with the completeness of that utilization published alongside it. **Procedure detail:** * **PROCEDURE\_VOLUMES** : One row per provider, procedure code, place of service, and year. Service counts, distinct beneficiaries, submitted / allowed / standardized payment amounts, RBCS clinical category, and the practice state the provider billed from * **PROCEDURE\_BENCHMARKS** : One row per procedure code, place of service, geography, and year. CMS published totals for the code joined to what is visible in the detail, producing per-code coverage ratios. This is the table that answers "how much of this procedure's market can I actually see" **Provider level:** * **PROVIDER\_VOLUME\_SUMMARY** : One row per provider per year. CMS pre-suppression totals for the provider beside the totals visible in the detail file, with the resulting coverage ratio, coverage class, and a ranking-eligibility flag * **PROVIDER\_VOLUME\_PROFILE** : One row per provider, describing the latest data year. Specialty, professional qualifications, entity type, group practice size, validated practice geography, rurality, shortage-area and health-centre designations, and affiliation counts by facility type **Evaluation:** * **TRIAL\_COHORT** : The providers reachable during a free trial, with the context needed to use them. Coverage-selected and stratified across states and territories, and deliberately including low-coverage providers so the completeness measures are exercisable rather than only described ### Metadata Tables | Table | Purpose | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `SOURCE_VINTAGES` | Provenance for the CMS publication feeds behind the procedure data: which data years are loaded, when CMS released each file, and how long after the period it landed. Does not cover the provider spine and enrichment inputs | | `DATA_DICTIONARY` | Column descriptions for every consumer-facing view | ## Ask it questions: Cortex Analyst and the semantic view The share includes the **`VOLUME_ANALYST` semantic view**, a semantic model over procedure volumes, provider-year completeness, provider profiles, and RBCS categories, with relationships, synonyms, and business definitions built in. Point **Cortex Analyst** at it (in Snowsight: AI & ML → Cortex Analyst → select `DWV.VOLUME_ANALYST`) and ask questions in plain English: * *"Which specialties bill the most services?"* * *"How many providers have complete data coverage?"* * *"Show me rural provider counts by state."* New to these features? See Snowflake's documentation on [Cortex Analyst](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst) and [semantic views](https://docs.snowflake.com/en/user-guide/views-semantic/overview). The same semantic model is queryable directly in SQL with the `SEMANTIC_VIEW()` construct: ```sql -- How many providers fall in each completeness band. Start here: it tells you -- how much of the provider universe is safe to rank or trend SELECT * FROM SEMANTIC_VIEW( DWV.VOLUME_ANALYST DIMENSIONS provider_years.coverage_band METRICS provider_years.provider_count ) ORDER BY 1; ``` ```sql -- Services and Medicare payment by clinical category. The semantic view -- resolves the procedure to RBCS category join for you SELECT * FROM SEMANTIC_VIEW( DWV.VOLUME_ANALYST DIMENSIONS procedure_categories.category_name METRICS procedures.visible_services, procedures.total_paid_amount ) ORDER BY 2 DESC; ``` ## Entity Relationship Diagram ![Medicare Physician Procedure Volumes Entity Relationship Diagram](https://813439891-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDeimGtBflXKQn786VLvj%2Fuploads%2Fgit-blob-7a6d635f605212d4be72a92c4b81797fc1863990%2Fentity-relationship-medicare-physician-volumes.png?alt=media) `NPI` is the spine. `PROCEDURE_VOLUMES` is keyed by NPI, HCPCS code, place of service, and data year, and joins to `PROVIDER_VOLUME_SUMMARY` on NPI *and* data year for the completeness of that provider-year. `PROVIDER_VOLUME_PROFILE` joins on NPI alone and carries the latest data year only, so treat it as a current provider directory rather than a historical one. `PROCEDURE_BENCHMARKS` sits beside the detail rather than under it: it is keyed by geography instead of by provider, and answers questions about a procedure's market rather than a provider's practice. `SOURCE_VINTAGES` is the provenance table that every data view's `FEEDS_FILES_ID` resolves against. ## Why Some Providers and Procedures Are Missing This is the most important thing to understand before writing a query against Medicare Part B utilization data, and it applies to every source of that data, including the files published directly by CMS. **CMS suppresses any provider-and-procedure combination performed for fewer than 11 Medicare beneficiaries.** The row is not published at all. Roughly 72% of the provider-year-code relationships CMS reports never reach the public detail file. The consequence that catches analysts out: **an absent row does not mean zero volume.** It means either that the volume fell below the publication threshold, or that the provider did not perform the procedure. The public detail file on its own cannot tell you which. ### What this dataset adds Alongside the visible detail, this product publishes **CMS's own pre-suppression totals**, so the size of the gap is measurable rather than assumed. That happens at two grains, because CMS suppresses at provider by code by place of service: | Grain | Table | Answers | | ------------------------------------------- | ------------------------- | ----------------------------------------------------------------- | | Per provider-year | `PROVIDER_VOLUME_SUMMARY` | How much of *this provider's* practice does the detail file show? | | Per code, place of service, geography, year | `PROCEDURE_BENCHMARKS` | How much of *this procedure's* published market is visible? | Both grains are necessary. A provider-year measure cannot tell you whether one procedure code is complete, and a code-level measure cannot tell you whether a given provider's record is trustworthy. ### Coverage class and coverage ratio answer different questions These two columns are easy to confuse, and confusing them is the most common mistake with this data. `DETAIL_COVERAGE_CLASS` is about **procedure codes**. It tells you whether any of the codes a provider reported are missing from the detail file entirely: | Value | Meaning | | -------------- | ------------------------------------------------------------------------------------------------ | | `COMPLETE` | None of the provider's procedure codes were suppressed | | `PARTIAL` | Some codes are visible, some were suppressed | | `SUMMARY_ONLY` | Every code was suppressed. The provider appears in CMS totals with no visible detail rows at all | `DETAIL_COVERAGE_RATIO` is about **services**. It is the share of the provider's reported service volume that appears in the detail file, always between 0 and 1. {% hint style="warning" %} **`COMPLETE` does not mean "all services visible".** A provider can have every procedure code present and still show a low service ratio, because suppression is applied per code *and place of service*. Records classed `COMPLETE` are observed with ratios as low as about 0.23. Read the class to learn whether codes are missing, and the ratio to learn how much volume is missing. Use both. `SUMMARY_ONLY` records always carry a ratio of 0. {% endhint %} ### The two code-level ratios diverge, and that is the point `CODE_PROVIDER_COVERAGE_RATIO` and `CODE_SERVICE_COVERAGE_RATIO` both run from 0 to 1, and for the same procedure they are usually far apart, because high-volume providers clear the suppression threshold and the long tail does not. Across the panel as a whole, weighted by volume, you can see roughly three-quarters of the service volume in CMS's pre-suppression totals but only about a quarter of the provider-to-procedure relationships. **Do not carry those aggregates onto a single procedure.** They are dominated by a handful of very high-volume codes. For a typical code the picture is far tighter: the median national code shows under a fifth of its services and only a few percent of its operators. That gap between the aggregate and the typical code is the single best reason to read the ratio for the specific code you care about rather than assuming a headline figure applies. The practical consequence is that neither question has a general answer. For any specific procedure and setting: * **Read `CODE_SERVICE_COVERAGE_RATIO` before sizing a market on services.** For the highest-volume codes it is high enough to size on directly. For a typical code it is not, and sizing on mostly suppressed volume will understate the market badly. * **Read `CODE_PROVIDER_COVERAGE_RATIO` before building a target list.** It is almost always the lower of the two, often by a wide margin, so a list of named operators should be treated as a partial roster rather than the field. Look both up for the code you actually care about. That is what the two columns are for, and it is the step that no general rule of thumb can replace. {% hint style="warning" %} **Read the code-level ratios as an upper bound on visible coverage, not as ground truth.** The CMS benchmarks they are measured against are themselves suppressed independently per geography, so the denominator can be too small and the true visible share may be lower than the ratio suggests. Equivalently, `1 - ratio` is a *lower* bound on what is missing. Check `GEOGRAPHY_NOT_COMPARABLE` before comparing one geography against another. {% endhint %} ### Practical rules 1. **Never treat a missing row as a zero.** Join to the completeness columns and decide explicitly how to handle low-coverage records. 2. **Scope provider rankings to `RANKING_ELIGIBLE`.** Without it, a high-volume physician whose record happens to be heavily suppressed ranks below providers who are merely more visible. 3. **Check coverage in every year before trending.** Coverage is not constant across years, so an apparent change in volume can be a change in visibility. 4. **Decide which denominator your question needs.** Provider counts and service counts are covered very differently, and the right ratio depends on which one your analysis rests on. ## Data Quality ### How current is this data? `SOURCE_VINTAGES` records the **CMS publication feeds** behind the procedure data: which data years are loaded, when CMS released each file, and how long after the reporting period it landed. It does not cover the provider spine and enrichment inputs that refresh on their own cadence, so it tells you the vintage of the volumes rather than of every column in the product. Query it before drawing conclusions about recency: ```sql -- What is loaded, and when did the publisher release it SELECT source_feed, vintage_kind, data_year, source_file_published_date, days_from_period_end_to_publication, is_latest_data_year FROM DWV.SOURCE_VINTAGES ORDER BY source_file_published_date DESC; ``` `DAYS_FROM_PERIOD_END_TO_PUBLICATION` is worth reading closely. CMS publishes each data year roughly 17 months after that year closes, normally in the spring, so the most recent year available sits two calendar years behind for most of the year and three in the months just before a release. That lag is a property of the source, not of this pipeline, and it applies equally to the files CMS publishes directly. `VINTAGE_KIND` tells you how a feed is versioned. `ANNUAL` feeds carry a `DATA_YEAR` and add one year at a time. `SNAPSHOT` and `RELEASE` feeds, such as the procedure classification system and the hospital affiliation file, have no data year at all and are replaced wholesale, so their `DATA_YEAR` is null by design. That distinction matters when pinning analysis to the newest year. Use `IS_LATEST_DATA_YEAR` rather than hardcoding a year that will age, and exclude the feeds that carry no year: ```sql -- The newest data year available, without hardcoding it. -- DATA_YEAR IS NOT NULL excludes the snapshot feeds, which carry no year. SELECT DISTINCT data_year FROM DWV.SOURCE_VINTAGES WHERE is_latest_data_year = TRUE AND data_year IS NOT NULL; ``` ### Standardization applied * Provider identity is resolved onto a single entity-matched spine, so a provider joins consistently across every view * Practice addresses are standardized and geocoded, with county, CBSA metro, census tract, ZIP, and coordinates attached * Payments are carried as submitted, allowed, and geographically standardized amounts, so market comparisons are not distorted by locality adjustment * Procedures are classified by Restructured BETOS (RBCS) category and family * Completeness measures are computed against CMS published totals rather than inferred ## Getting Started ### Platform and schema reference Queries use schema-only references. The database is already set by the share context, so write `DWV.PROCEDURE_VOLUMES`, not a database-qualified name. | Platform | Schema | Example | | ------------- | ------ | ----------------------- | | **Snowflake** | `DWV` | `DWV.PROCEDURE_VOLUMES` | ### Discover what is in the product `DATA_DICTIONARY` describes every column in every consumer-facing view. It is the fastest way to orient yourself: ```sql -- Every column in the product, with its description SELECT table_name, column_name, data_type, description FROM DWV.DATA_DICTIONARY ORDER BY table_name, column_name; ``` ```sql -- Just the completeness columns, which are the ones worth reading first SELECT table_name, column_name, description FROM DWV.DATA_DICTIONARY WHERE column_name ILIKE '%COVERAGE%' OR column_name ILIKE '%SUPPRESS%' OR column_name ILIKE '%ELIGIBLE%' ORDER BY table_name, column_name; ``` ### Where to start If you are new to the data, work in this order: 1. **`PROVIDER_VOLUME_SUMMARY`** for a provider and year. It is keyed by NPI and data year, covers every provider-year in the panel, and tells you immediately how much of that provider's activity you can actually see. 2. **`PROVIDER_VOLUME_PROFILE`** to find providers by specialty, geography, and setting. One row per provider, but remember it describes the latest data year only, so it is a current directory rather than the spine of the panel. 3. **`PROCEDURE_VOLUMES`** for the procedure detail itself. 4. **`PROCEDURE_BENCHMARKS`** when your question is about a procedure's market rather than a provider's practice. ## Common Pitfalls These are the mistakes that produce plausible but wrong answers. Each one is easy to avoid once you know it exists. **`PROVIDER_VOLUME_PROFILE` describes the latest data year only, so inner-joining it to history drops providers.** The profile is a current provider directory: it carries one row per NPI describing the most recent data year, and it contains no row at all for a provider who stopped billing Medicare before that year. Roughly a third of the NPIs that appear in `PROCEDURE_VOLUMES` have no profile row for exactly that reason. The consequence is quiet. An inner join from historical procedure detail to the profile silently removes every provider who has since left, which biases any multi-year analysis toward survivors: ```sql -- WRONG for historical analysis: the inner join drops providers who -- stopped billing before the latest data year SELECT p.data_year, COUNT(DISTINCT p.npi) AS providers FROM DWV.PROCEDURE_VOLUMES p JOIN DWV.PROVIDER_VOLUME_PROFILE f ON f.npi = p.npi GROUP BY 1 ORDER BY 1; -- RIGHT: keep every provider, and accept that profile attributes are -- NULL for those no longer present in the latest year SELECT p.data_year, COUNT(DISTINCT p.npi) AS providers FROM DWV.PROCEDURE_VOLUMES p LEFT JOIN DWV.PROVIDER_VOLUME_PROFILE f ON f.npi = p.npi GROUP BY 1 ORDER BY 1; ``` Run both and the gap is visible: across the full history the inner join returns roughly a fifth fewer provider-years than the left join, and every one of those missing rows belongs to a provider who is simply no longer active. Use an inner join when you deliberately want currently active providers. Use a left join, or no join at all, for anything historical. `PROVIDER_VOLUME_SUMMARY` is keyed by NPI *and* data year and has a row for every provider-year in the detail, so it is the safe companion for multi-year work. **Beneficiary counts do not add up across rows.** A patient is counted once per procedure code and setting, so summing `BENEFICIARY_COUNT` across codes double counts people. For distinct patients per provider, use `PROVIDER_VOLUME_SUMMARY.BENEFICIARY_COUNT_REPORTED`, which is already a provider-year figure. Service counts and payments *do* sum correctly. **Average payment columns need service weighting.** `AVG_MEDICARE_STANDARDIZED_AMOUNT` and its siblings are per-provider averages. A plain `AVG()` across providers weights a provider with ten services the same as one with ten thousand. Weight by `service_count`, as the office-versus-facility example below does. **Unfiltered volume rankings are led by laboratories.** Reference labs, pharmacies, and group entities bill enormous service counts. Filter `ENTITY_TYPE_VALUE = 'Individual'` when you want clinicians. **`PRACTICE_CITY` is unstandardized free text.** Filter geography on `PRACTICE_STATE`, county, ZIP, or CBSA instead. **Shortage-area status is not a narrow filter.** `PRACTICE_IN_HPSA` covers roughly nine in ten providers, so it does not isolate underserved markets on its own. `PRACTICE_IS_RURAL` is the sharper filter for rural analysis. **`RANKING_ELIGIBLE` describes a provider-year, not a single code.** Showing it beside a per-code ranking is informative. Filtering a per-code ranking on it biases the result, because a provider can be broadly incomplete for the year while the one code you care about is fully visible. **`PLACE_OF_SERVICE` is part of the key, so the same code appears twice.** Medicare pays facility and non-facility settings from separate fee schedules, so CMS publishes them separately. A provider billing one code in both settings has two rows in `PROCEDURE_VOLUMES`. Aggregate across them deliberately rather than by accident. **`PROCEDURE_BENCHMARKS.GEO_CODE` is NULL on National rows, not blank.** `WHERE geo_code = ''` returns nothing, and any equality join or `COUNT(DISTINCT ...)` including `GEO_CODE` silently drops every National row. Filter on `GEO_LEVEL` instead, or wrap the column in `COALESCE`. **`PROCEDURE_BENCHMARKS` is designed to be read on its own, not joined to the detail.** It is grained by geography rather than by provider, so it answers "how much of this procedure's market is visible" directly. Select from it with `GEO_LEVEL` and `HCPCS_CODE` pinned, as the last query example does, and you avoid every trap below. If you do need to attach benchmark context to detail rows, two things will bite you. **`GEO_CODE` is a state FIPS code, not a USPS abbreviation.** It holds `'01'`, `'02'`, `'04'`, while `PRACTICE_STATE` holds `'AL'`, `'AK'`, `'AZ'`. Joining those two columns returns **exactly zero rows**, with no error to tell you why. **Do not substitute `PRACTICE_STATE_FIPS` for it either.** That column is not a reliable state key: most `PRACTICE_STATE` values carry more than one distinct FIPS value, and a FIPS-based join misattributes a small number of providers to the wrong state. The reliable key is the state name in `GEO_DESCRIPTION`, which means supplying your own USPS-to-name mapping. **Always pin `GEO_LEVEL` when you do join.** A single code, setting, and year has one National row plus one row per state, so leaving `GEO_LEVEL` unconstrained multiplies your result by 61. ```sql -- PREFERRED: read the benchmark directly. No join, no geography key problem. SELECT geo_description, place_of_service, benchmark_provider_count, visible_provider_count, code_provider_coverage_ratio, code_service_coverage_ratio FROM DWV.PROCEDURE_BENCHMARKS WHERE hcpcs_code = '99213' AND data_year = 2024 AND geo_level = 'State' ORDER BY code_provider_coverage_ratio; ``` **Do not sum State rows to get a national figure.** CMS publishes the National and State benchmarks independently, and applies suppression to each separately, so the state rows usually do not add up to the national row. Across the code, setting, and year combinations in this table, the two agree for only a small minority, almost all of them very high-volume codes where every state clears the suppression threshold on its own. For everything else, summing states understates the national total by whatever each state withheld. Select `GEO_LEVEL = 'National'` when you want a national number. For the full column-level detail behind these, see the [Schema Reference](/data-catalog/medicare-physician-volumes-dataset/schema-reference.md). ## Query Examples ### Rank providers by volume for one procedure in one market Ranks individual clinicians by billed volume for a single procedure in a single state, carrying each one's completeness alongside so you can see what the ranking rests on. `RANKING_ELIGIBLE` is shown rather than filtered, for the reason given above. ```sql SELECT p.npi, pr.specialty_description, pr.practice_state, SUM(p.service_count) AS services_this_code, s.detail_coverage_ratio AS provider_year_coverage, s.hcpcs_codes_suppressed AS provider_codes_hidden, s.ranking_eligible AS provider_broadly_complete FROM DWV.PROCEDURE_VOLUMES p JOIN DWV.PROVIDER_VOLUME_PROFILE pr ON pr.npi = p.npi AND pr.entity_type_value = 'Individual' JOIN DWV.PROVIDER_VOLUME_SUMMARY s ON s.npi = p.npi AND s.data_year = p.data_year WHERE p.hcpcs_code = '99214' AND p.data_year = 2024 AND pr.practice_state = 'SC' GROUP BY 1, 2, 3, 5, 6, 7 ORDER BY services_this_code DESC LIMIT 25; ``` ### How complete is one provider's record Shows a single provider's visible versus reported volume across every year, so you can see what CMS withheld before drawing conclusions. ```sql SELECT data_year, distinct_hcpcs_codes_reported, distinct_hcpcs_codes_in_detail, hcpcs_codes_suppressed, service_count_reported, service_count_in_detail, detail_coverage_ratio, detail_coverage_class, ranking_eligible FROM DWV.PROVIDER_VOLUME_SUMMARY WHERE npi = 1003863929 ORDER BY data_year; ``` ### What does a practice consist of Breaks one provider-year down by Restructured BETOS category with payments. Services and payments sum across codes. Beneficiary counts do not. ```sql SELECT rbcs_category_description, COUNT(DISTINCT hcpcs_code) AS distinct_procedures, SUM(service_count) AS services, ROUND(SUM(total_medicare_payment_amount), 2) AS medicare_paid FROM DWV.PROCEDURE_VOLUMES WHERE npi = 1003863929 AND data_year = 2024 GROUP BY 1 ORDER BY medicare_paid DESC; ``` ### High-volume clinicians in rural markets Finds high-volume individual clinicians, rather than laboratories or group entities, in rural markets, with shortage-area and health-centre status attached. ```sql SELECT npi, specialty_description, practice_city, practice_state, practice_is_rural, practice_in_hpsa, is_fqhc_site, service_count_reported, beneficiary_count_reported, detail_coverage_class FROM DWV.PROVIDER_VOLUME_PROFILE WHERE entity_type_value = 'Individual' AND practice_is_rural = TRUE AND service_count_reported > 10000 ORDER BY service_count_reported DESC LIMIT 50; ``` ### Office versus facility split for a procedure Compares where a procedure is performed, by state, with geographically standardized payment so markets are comparable. The payment is service-weighted, because the stored column is a per-provider average. ```sql SELECT practice_state, place_of_service, COUNT(DISTINCT npi) AS providers, SUM(service_count) AS services, ROUND(SUM(avg_medicare_standardized_amount * service_count) / NULLIF(SUM(service_count), 0), 2) AS avg_standardized_payment FROM DWV.PROCEDURE_VOLUMES WHERE hcpcs_code = '99213' AND data_year = 2024 GROUP BY 1, 2 ORDER BY practice_state, place_of_service; ``` ### How much of a procedure's market can you see Compares CMS published totals for a procedure against what is visible in the detail. The provider ratio runs far below the service ratio, so size markets on services, and treat the operators you can name as a partial list rather than a complete one. ```sql SELECT data_year, place_of_service, benchmark_provider_count AS cms_operators, visible_provider_count AS operators_we_name, code_provider_coverage_ratio, benchmark_service_count AS cms_services, visible_service_count AS services_we_show, code_service_coverage_ratio FROM DWV.PROCEDURE_BENCHMARKS WHERE hcpcs_code = '33418' AND geo_level = 'National' ORDER BY data_year DESC, place_of_service; ``` ## Who Uses This Data **Medical device and diagnostics commercial teams** size a territory by procedure rather than by specialty label, finding the clinicians who actually bill a target code and ranking them by volume, payment, and patient count. **Life sciences market access and HEOR teams** establish how a procedure or Part B therapy is used in practice across settings, geographies, and years, building the real world utilization baseline that supports a value dossier or a reimbursement submission. **Health system strategy and network planning teams** map procedure volume across a geography, see which service lines local clinicians drive, and quantify capture by comparing local volume against state and national totals. **Payer network teams** assess adequacy and referral capacity by procedure in a given geography, using observed billing rather than directory self attestation. **Researchers and policy analysts** study geographic variation, practice patterns, and procedure diffusion since 2013 on a panel that carries the completeness measurements needed to state limitations honestly in a methods section. **Health equity and access analysts** join procedure volume to shortage area designations and health center status, quantifying who performs which procedures in underserved geographies. **Program integrity and compliance teams** identify billing patterns that sit far outside a peer distribution, using per procedure and per specialty denominators that account for what CMS withheld. *** ## Frequently Asked Questions **What is one row in this data?** One row represents one provider (identified by NPI), one procedure code (HCPCS), one place of service (facility or office), and one data year. A single provider therefore has many rows: one for every combination of procedure and setting they billed in that year. Place of service is part of the key because Medicare applies separate fee schedules to facility and non facility settings, so the same procedure appears twice for a provider who performs it in both. Aggregating without accounting for the setting will double count that provider. **Why is the total row count lower than the sum of CMS's published files?** Because CMS republishes prior years, and adding every published file together counts the same year more than once. Summing all of CMS's published physician detail files produces 135.6M rows. Resolving each data year to its correct publication vintage produces 116.3M rows, roughly 16% fewer. The larger figure is not more data, it is the same data counted repeatedly. We resolve each data year to a single authoritative vintage before publishing, so a year over year comparison is not silently inflated by a republication. If you have seen the higher number quoted elsewhere, this is the difference. **Why is the most recent data year about two years behind?** CMS builds this data from final action claims, meaning every adjustment, appeal, and resubmission has been resolved before a year is published. That settlement period is the reason for the lag. In practice CMS publishes a data year in the spring roughly 17 months after the year closes, so the most recent year available is normally two calendar years behind the current one, and briefly three in the months just before an annual release. This lag is a property of the source, not of our processing: we load a new year within a day of CMS publishing it. Nothing available anywhere, at any price, is more current than this for Medicare fee for service physician utilization, because the underlying file does not exist sooner. **A provider I expect to see is missing. Why?** Three common reasons, in order of likelihood. First, the provider may have billed Medicare fee for service too little that year for any row to survive CMS's privacy threshold (see the next question). Second, they may not bill Original Medicare Part B at all: this data excludes Medicare Advantage, Medicaid, and commercial claims, so a clinician with a young or commercially insured panel can be legitimately absent. Third, the data covers Part B non institutional claims and excludes durable medical equipment claims, so providers whose Medicare work sits entirely outside that scope will not appear. A provider present in the national registry but absent here has not necessarily done anything unusual. **If there is no row for a provider and a procedure, does that mean they never performed it?** No, and this is the most consequential thing to understand about this data. To protect beneficiary privacy, CMS removes any row representing fewer than 11 beneficiaries before publishing. The row is deleted rather than flagged, so in the public detail file an absent row and a procedure never performed look identical. On our measurement of the most recent data year, more than 70% of provider to procedure relationships are withheld this way, though those hidden rows are individually small and account for only about a fifth of total service volume. This is not only a small provider effect: the majority of relationships remain hidden even for providers serving more than a thousand beneficiaries. Treat an absent row as unknown, never as zero. Questions like "does this provider perform this procedure" and "has this provider stopped performing it" cannot be answered from visible detail alone. Because CMS also publishes totals calculated before suppression is applied, we carry a coverage measure for each provider and each procedure code, so you can see what share of a provider's activity is visible to you and decide whether a given question is answerable. Provider level volume, payment, patient counts, and growth all come from those pre suppression totals and are unaffected. **How is this different from downloading the files from CMS directly?** The source files are free, and for a one off lookup CMS's own tool is the fastest route. The difference matters when you are querying at scale or building something on top of the data. CMS publishes each year as a separate large flat file (the detail file alone is several gigabytes, and CMS notes it is too large to open in a spreadsheet), with no history joined, no provider identity resolved, no procedure taxonomy attached, and no measure of what suppression removed. This product delivers the full span since 2013 as one queryable panel, with publication vintages already resolved, provider identity and practice location joined from the national registry, hospital affiliations attached, procedure codes grouped into clinical categories using CMS's own taxonomy, shortage area and health center status appended, and a coverage ratio on every provider and code. The raw data is public. The work of making it comparable across 9,000+ codes and a dozen years, and of knowing what is missing from it, is what you are buying. **There are three service counters. Which one should I use?** They answer three different questions and are not interchangeable. Use **`SERVICE_COUNT`** (CMS calls it Tot\_Srvcs) for services billed. This is the count Medicare paid against, and it is the correct multiplier for turning the per service averages into totals. Use **`BENEFICIARY_DAY_SERVICE_COUNT`** (CMS calls it Tot\_Bene\_Day\_Srvcs) for something closer to encounters. CMS describes it as removing double counting where a beneficiary receives several services of the same type on one day, and calls it "a proxy for a count of visits." Use **`BENEFICIARY_COUNT`** (CMS calls it Tot\_Benes) for distinct patients: the number of individual beneficiaries who received that service from that provider. One caution on the first of these. CMS warns that the unit behind a service count varies by procedure type: it is miles for ambulance transport, weight or volume for Part B drugs, and minutes for some psychotherapy and evaluation services. Summing service counts across a provider's entire code list therefore adds quantities that are not the same kind of thing. Filter to the codes or the clinical category you actually mean, and use the drug indicator to exclude Part B drug codes from procedure counts. **Are the years comparable for trend analysis?** Mostly, with three corrections you should apply deliberately. First, suppression creates false movement. A provider whose volume crosses the 11 beneficiary threshold between two years appears to go from nothing to substantial, or to vanish. That is a change in visibility, not in activity. Because it is an artifact of the threshold, it does not affect the totals CMS calculates before suppression, which is where provider level growth should be measured. Second, a year over year calculation needs to compare adjacent years explicitly. If you take each provider's previous observed year, a provider with a gap in the panel will have a recent year compared against one several years earlier. On our measurement about a tenth of the most recent year's providers have no adjacent prior year, and an unguarded aggregate overstates growth by roughly a third. We carry growth columns that only populate where the prior calendar year is genuinely adjacent. Third, procedure categories can change between CMS releases. This product applies the **current** classification to every data year, not the classification in force during the service year, and publishes `RBCS_ASSIGNMENT_RELEASE_YEAR` so you can see which release the label came from. Category trends are therefore consistent across years, but they do not show how codes were classified historically. Two smaller discontinuities to know about: CMS changed the underlying claims source between the 2013 and 2014 data years (CMS measured the difference at a hundredth of a percent or less), and revised its chronic condition algorithms partway through the panel, so patient mix percentages should not be trended across that revision. **Which payment amount should I use?** Four amounts are published per row, and the right one depends on your question. The **submitted charge** is what the provider asked for. It is not a negotiated or paid price and should not be read as a market rate. The **allowed amount** is the full permitted amount for the service, including what Medicare paid plus the beneficiary's deductible and coinsurance and any third party share. Use it to size the total economic value of a service. The **Medicare payment** is what Medicare itself paid after deductible and coinsurance. Use it to model Medicare revenue. Note that fee for service claims from April 2013 onward carry a 2% sequestration reduction, which matters because the panel starts in 2013. The **standardized payment** removes geographic differences in payment rates. Use it whenever you compare across geographies, so that differences reflect practice patterns rather than local price adjustments. All four are published as averages per service, not per patient. To recover a total, multiply by the service count. Multiplying by the beneficiary count instead is a common error and can be wrong by more than an order of magnitude on high frequency procedures. These values carry many decimal places: aggregate first and round last, because rounding before you aggregate restates most payment figures. **Can I compare average payment between office and hospital settings?** Not directly, and this catches people. When a service is delivered in a facility, Medicare makes two payments: one for the clinician's professional fee and one to the facility. This data contains only the non institutional claim, so a facility row carries the professional fee alone and not the facility payment. An office row, by contrast, carries the complete payment for the service. Comparing the two is comparing a component against a whole, and a provider who shifts cases from office to hospital will appear to take a large rate cut when nothing about their reimbursement has changed. Volumes and patient counts are comparable across settings. Payments are not. One exception worth knowing: ambulatory surgical center facility fees are submitted on non institutional claims and are therefore included. **Does this cover all of a provider's patients?** No. This is Original Medicare Part B fee for service only. It excludes Medicare Advantage, Medicaid, commercial insurance, and self pay, so it represents a slice of most clinicians' practices and undercounts total volume, often substantially, and unevenly across specialties and geographies. Two further attribution caveats matter for interpretation. In teaching settings, residents and fellows may bill under a supervising clinician's identifier, so academic providers' volumes can exceed their personal caseload. And the data is not risk adjusted and carries no quality or outcome measures, so it describes what was billed and not how complex the patients were or how well the care went. **Can I break a provider's volume out by practice location?** No, and CMS is explicit on this point: the data does not let users distinguish services delivered at different practice locations. Each provider carries a single address drawn from the national registry, and it reflects that registry at the time of extraction rather than the address in force during the service year. For a clinician practicing at several sites, all volume is attributed to one location. Plan territory and catchment analysis with that in mind: the volume figures are sound, the geographic attribution for multi site providers is approximate. *** ## Reading CMS's Own Caveats CMS documents this data thoroughly, across a methodology document, a technical specification, per file data dictionaries, and a long frequently asked questions list. Much of what surprises new users is written down there, though it is spread across four documents and some of it sits inside collapsed sections. These are the caveats that change how you should write a query, rather than the ones that merely describe the data. **The privacy threshold removes rows silently.** CMS states that it "has redacted all data elements from this file where the data element represents fewer than 11 beneficiaries." In the provider level summary file this appears as masked values with an indicator character. In the provider and procedure detail file there is no indicator at all: the row is simply gone. No field in the detail dictionary flags it. This is why a completeness measure has to be constructed from the summary totals rather than read off the detail. **Suppression also applies within patient mix breakdowns.** CMS notes that beneficiary counts in the demographic subgroups "may not aggregate to the 'Number of Unique Beneficiaries'" because the same threshold is applied inside each subgroup. Subgroup columns legitimately fail to sum to the total, which is expected behaviour rather than a data defect. **Service counts do not all count the same thing.** CMS warns that the metrics behind a service count "can vary from service to service," and specifies miles for ambulance claims and drug weight or volume for Part B drugs. CMS also notes that bundled procedures produce wide variation in the count. Any aggregate service figure needs its codes scoped first. **Averages are divided by services.** CMS states that the average payment and charge variables reflect total payments or charges "divided by the line\_srvc\_cnt." There is no total payment column in the detail file, so totals must be reconstructed, and only the service count is the correct multiplier. **Facility rows exclude the facility payment.** CMS explains that for services in a facility the data "only represents the physician's professional fee." This single sentence is the reason cross setting payment comparisons fail, and it is easy to miss. **Specialty is derived from billing, not declared.** The technical specification assigns each provider one specialty: the one associated with their largest number of services. A clinician who works across specialties receives a single label chosen by volume. Filtering a procedure to an expected specialty will therefore drop legitimate billers who are labelled differently, sometimes a meaningful share of them. When you want everyone who performs a procedure, filter on the procedure code and not on the specialty. **Claims are not audited.** The data summarises claims as received. CMS does not verify their clinical accuracy, and payment amounts legitimately vary with modifiers, geography, place of service, and multiple services delivered on one day. **Provider demographics come from a different source and a different moment.** Names, credentials, addresses, and entity type are drawn from the national provider registry rather than from the claims, and are extracted after the close of the reporting year. Provider attributes and billing activity in the same row are therefore as of slightly different times. **Linking to other public datasets requires care about populations.** CMS cautions that files cover different Medicare populations and time periods. Its own example is Part D: some beneficiaries in this data have no drug coverage, and some in the Part D data have no fee for service Part B coverage, so neither file is a subset of the other. One further note on procedure descriptions. The descriptions attached to numeric procedure codes are the consumer friendly wording maintained by the American Medical Association, which CMS notes is intended to help non clinicians understand a bill and "should not be used for clinical coding or documentation." Descriptions for other codes are truncated to a fixed length, so the same description can appear against more than one code. Use the code as the key, never the description. *** ## Related Dataplex Products This dataset pairs naturally with: * [NPPES Provider Golden Record](/data-catalog/nppes-validated-dataset.md) for the full provider master behind the NPI spine, including validated addresses, duplicate resolution, and Medicare enrollment status. * [HRSA Healthcare Resources](/data-catalog/hrsa-dataset.md) for the county-level workforce and shortage-area context behind the access designations carried here. * [CMS Medicaid Provider Spending](/data-catalog/cms-medicaid-provider-spending-dataset.md) to set Medicare Part B utilization beside Medicaid spending for the same provider population. {% hint style="success" %} **Ready to work with Medicare Part B procedure volumes?** | Platform | Action | | ------------- | -------------------------------------------------------------------------------- | | **Snowflake** | [Get on Marketplace](https://app.snowflake.com/marketplace/listing/GZT1Z7QRT4RP) | A 14-day trial of the evaluation cohort is available on the listing. Questions? [Contact our team](mailto:support@dataplex-consulting.com) for a walkthrough. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.dataplex-consulting.com/data-catalog/medicare-physician-volumes-dataset.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.