MA hedis hos frm

What it is

1. 1CMS Medicare Advantage HEDIS Public Use File — the HOS (Health Outcomes Survey) "Falls Risk Management" sheet.
2. 2One contract-year record of two patient-reported fall-prevention process rates per MA contract, used as a Star-Ratings quality input.
3. 3NOTE: this is a quality/clinical-outcome measure, NOT a price or payment-rate table — the word "rate" here means a survey percentage, not a dollar amount or a negotiated cost.

Grain

How to read it

1. 1"SELECT contract_id, plan_name_raw, rate1, rate2 FROM medicare_silver.hedis_hos_frm WHERE report_year = 2025 ORDER BY rate2 DESC" answers: for the 2025 reporting year, which MA contracts have the highest share of members who received a fall-prevention recommendation (rate2) and discussed falls with their doctor (rate1) — a quality-benchmark ranking of plans on the HOS Falls Risk Management measure.
2. 2To trend a single plan over time, drop the year filter and add 'WHERE contract_id = ' a specific contract and 'ORDER BY report_year'.
3. 3Join to medicare_silver.hedis_general or Stars tables on (contract_id, report_year) to pull plan-type/enrollment/Star-rating context.

Traps

1. 1NOT a cost/price table despite living in a US-healthcare-COST catalog. 'rate1' and 'rate2' are patient-reported survey PERCENTAGES (0-100, fall-prevention process measures), not dollars, not negotiated rates. Its value to a cost catalog is indirect: it's a Star-Ratings quality input, and Stars drive MA plan quality-bonus payments — so it informs plan-quality/payment context, not procedure prices.
2. 2The minimal grain is just (contract_id, report_year) = 3,207 rows. The profiler reported a 4-column key (adding plan_name_raw + effective_period_start + observed_period) but those three are redundant: observed_period/effective_period_start are collinear with report_year, and plan_name_raw is functionally determined within a contract-year. Don't add them to a join/dedup key.
3. 3contract_id is NOT unique on its own (735 distinct vs 3,207 rows — same contract recurs each year) and plan_name_raw is unstable (one contract can carry up to 4 different printed names across years; many contracts share a parent name). Key on contract_id, never on plan_name_raw.
4. 4Year 2020 is legitimately absent (CMS suspended HEDIS/HOS reporting for measurement year 2020 due to COVID) — do not treat the 2019->2021 gap as a missing load or pipeline error.
5. 5Nulls carry meaning and rate2 is null far more than rate1 (443 vs 56, ~14% vs ~2%, rising in recent years) due to CMS small-denominator suppression. A row with rate1 present but rate2 null means the contract reported but the second indicator was suppressed — not zero, not missing data. rate2 is always >= rate1 when both present (0 inversions).
6. 6No snapshot/version churn and no is_current column: cms_vintage_sequence, parse_revision, and asserted_at are all single-valued constants (1, 1, 2026-05-15) across every row, and there's exactly one source SHA per year. This is one clean historical load — no de-dup-to-latest step is needed, unlike point-in-time tables in this catalog.
7. 7Sibling-table confusion: this is specifically the FRM (Falls Risk Management) HOS sheet. medicare_silver has parallel HOS tables hedis_hos_mui (Management of Urinary Incontinence, 3 rates, 2021+), hedis_hos_pao (Physical Activity, 2 rates), and hedis_hos_oto (one rate, 2019+2021 only) with the SAME (contract_id, report_year) grain and identical-looking rate1/rate2 columns — the rate columns mean DIFFERENT clinical things per table. Some scout docs label the siblings with '(?)' guesses; FRM's two indicators (talking-to-doctor / receiving-recommendation) are the confirmed meanings here per the parser config.

Columns (14)

Query it

describe_data_source(source_fqn="medicare_silver.hedis_hos_frm")     # the card, live
query_substrate(sql="SELECT * FROM medicare_silver.hedis_hos_frm WHERE contract_id = '<value>' AND report_year = '<value>' LIMIT 100")