
But a CMS download is not a prospect list. Results depend on picking the right dataset, defining your ideal customer profile (ICP), resolving facility and health-system identities, and reading each file's limits correctly. The CMS Hospital General Information file alone lists 5,419 rows across 38 columns, and none of them is a buyer.
This guide covers how to select sources, build and score an account list, avoid common errors, and recognize when another data source fits better.
Key Takeaways
- CMS data works best for account discovery, segmentation, and territory planning.
- Define your ICP and business question before downloading anything.
- Validate identifiers, dates, and facility-to-system relationships before calling a record an account.
- CMS rarely shows buying intent, current decision-makers, or commercial payer activity.
- Pair CMS data with permitted enrichment and human review before CRM entry.
How to Use CMS Hospital Data to Find Healthcare Accounts
Step 1: Define the account profile first
Write down who you sell to before opening a file. Specify:
- Facility or organization types (acute care, psychiatric, children's, rehabilitation)
- U.S. states or regions
- Specialties or service lines
- Size indicators and ownership models
- The operational problem your offer solves
Then separate fit criteria from priority signals. Fit is binary: facility type, location, ownership. Priority is graded: service mix, utilization patterns, recent changes. Priority signals need further validation before anyone acts on them.
Step 2: Match the official source to your question
Combine the appropriate hospital and facility datasets, Care Compare provider information, enrollment and ownership files, and relevant cost reports. Use them to investigate location, facility type, scale, ownership, and system relationships. Check publication notes and definitions before treating a field as a current commercial attribute.
| Source | Best for | Key limit |
|---|---|---|
| Hospital General Information | Facility list, type, ownership, location | Medicare-registered hospitals only; the "Facility ID" field is not an NPI or system key |
| Provider of Services (POS) | Certification and facility characteristics | Includes non-hospital facilities; filter carefully |
| Hospital Enrollment and All Owners | CCN, NPI, PAC ID links; ownership | Active enrollments only; self-reported |
| Inpatient and Outpatient PUFs | Medicare activity by provider and service | Original Medicare fee-for-service only; small counts suppressed |
| Cost reports (HCRIS) | Costs, utilization, characteristics | Needs careful interpretation |
Hospital General Information is the usual starting point for a facility roster. Layer ownership and enrollment files on top when you need hierarchy clues.
Step 3: Clean, standardize, and enrich
Facility rows become accounts only after cleanup. Use CCNs, NPIs, legal names, addresses, and ownership fields to detect duplicates and connect hospitals to parent systems and affiliates.
CMS defines the CCN as a six-digit Medicare certification number. The NPI is a separate 10-digit provider identifier. In the hospital enrollment file, a single PAC ID can link multiple enrollment IDs, so treat these as different levels.
Practical cleanup steps:
- Standardize names and addresses.
- Preserve CCN, NPI, and PAC ID in their own columns.
- Create separate facility, parent-organization, and buying-account fields.
- Add contacts and technology data only from permitted, properly sourced business data.
Step 4: Score and activate
Combine ICP fit, data confidence, relevant CMS signals, and geographic priority into a score. Then route high scorers to a human reviewer with the evidence attached.
Teams that run this process repeatedly can add a workflow layer. Intellectible, for example, supports CSV uploads, PostgreSQL databases, API request and webhook nodes, and Salesforce connectivity.
Workflows can pause at approval nodes and log each decision. Revenue Discovery approval gates require human sign-off before outreach or a CRM update. The platform does not replace validation; it makes the review step consistent.

When CMS Hospital Data Is the Right Fit, and What You Need First
When this approach works
CMS data is a strong starting point for:
- Building a broad healthcare account universe
- Planning territories
- Identifying facility types
- Researching health-system footprints
- Prioritizing hospitals for vendors and contractors
It is less efficient when you need:
- Real-time purchase intent
- Technology-installation data
- Current executive contacts
- Private-provider activity
It is also overkill for a list of 30 named accounts you could research by hand.
What you need before starting
A defined output. Decide whether you want a facility list, parent-system list, territory file, ranked queue, or CRM-ready record. Then set the fields an account must have to qualify.
A workable environment. A spreadsheet handles small lists. Larger pulls need CSV or API ingestion, deduplication, identifier matching, and change tracking, usually through SQL, BI tools, or workflow automation.
Governance rules. Settle these before analysis:
- CMS states that Public Use Files contain no PHI or PII, but that applies only to files classified as PUFs. Avoid patient-level data entirely.
- Record source terms, update dates, and provenance for each field.
- Have legal or compliance review your outreach rules. The FTC's CAN-SPAM guide states there is no B2B exception for commercial email.
Key Parameters, Common Mistakes, and Troubleshooting
Segment the universe by the size proxy, facility type, geography, system, and ownership relevant to the offer. Check reporting periods and revision dates: cost reports can lag current operations, and a changed public record may reflect a correction rather than a new business event.
Data source, version, and freshness
Datasets cover different years, programs, and reporting units, so a current-looking record may not answer your sales question. Log the official source, release date, coverage period, update cadence, and exclusions.
Cadences vary by source:
- Provider Data Catalog hospital measures: quarterly (not every measure each quarter)
- POS: typically quarterly
- Enrollment files: monthly
- Inpatient PUF: annual
Refresh on each source's schedule.
Entity resolution and account hierarchy
A hospital campus, billing entity, medical group, and parent system can appear as separate records. That inflates counts and misdirects outreach.
Ownership is not the same as system affiliation either. The All Owners file records active ownership or managing control, and indirect owners may sit above direct ones. Do not read it as a clean parent-system tree.
Market totals also differ by definition. AHA's 2024 survey counts 6,100 U.S. hospitals, while AHRQ's 2023 Compendium counts 639 health systems. Do not mix those denominators.

Signal selection and interpretation
Utilization, payments, quality measures, and facility characteristics are not interchangeable evidence of need.
- Inpatient and outpatient files reflect Original Medicare fee-for-service only.
- Providers with 10 or fewer discharges (or services) are suppressed.
- The outpatient file excludes Maryland and includes selected APCs only.
- Reported charges are billed amounts, not market prices.
Write down what each signal can and cannot prove. Require supporting evidence before labeling an account high priority.
Geographic and coverage scope
A facility address, parent headquarters, service area, and claims geography can point to different places. Decide whether territory assignment follows facility address, system presence, or your ability to serve the account. Then validate state, county, facility status, and reporting period.
Common mistakes and troubleshooting
- Account count looks inflated: check inconsistent names, multiple identifiers, closures, acquisitions, and facility-versus-parent confusion before deduplicating.
- Few usable contacts or weak response: treat this as an activation gap. Add permitted enrichment, verify decision-maker roles, and test whether your CMS signals actually relate to your offer.
Alternatives to Using CMS Hospital Data
CMS data is one layer in account research, not a replacement for commercial intelligence or direct research.
Commercial healthcare intelligence databases
Choose these when current contacts, hierarchies, technology indicators, or export-ready CRM records matter more than raw public data. Definitive Healthcare, for instance, markets facility-level technology-install data with 15 primary categories. The AHA Annual Survey Database adds survey-derived staffing, service line, and affiliation fields across 1,000+ data points.
Trade-offs to compare:
- Licensing cost
- Source transparency
- Refresh frequency
- Contact accuracy
- How the vendor matches records
EHR, CRM, partner, and first-party data
Use these when you already have relationships, referrals, inbound activity, or account notes showing real engagement. Keep the limits in view:
- Coverage stays limited to existing relationships
- Data may be siloed or stale
- Healthcare privacy and access rules need careful review
Manual account-based research
Best for a small named list or strategic accounts where a researcher must verify leadership, initiatives, and purchasing structure. It yields richer context but is slower, harder to standardize, and harder to refresh across a large territory.

Outsourced research services, including Intellectible's, can cover list building, account research, and contact finding when you want that work done without adding headcount.
Conclusion
CMS hospital data works when the account definition, source selection, entity matching, and interpretation rules exist before the data enters a sales workflow.
Common failures are predictable:
- Treating raw rows as complete account profiles
- Confusing facilities with parent systems
- Reading payment or utilization data without its coverage limits
The strongest process pairs public-data efficiency with enrichment, human review, documented provenance, compliance checks, and a refresh plan.
Frequently Asked Questions
What should count as a healthcare account?
Define the healthcare account unit before collecting data: hospital, enrolled provider, operating facility, legal owner, or health system. Relevant CMS files can support a broad account universe, but each dataset has its own scope and identifiers; no single file is a complete record of every US healthcare business.
Which CMS datasets should be combined?
Combine the appropriate hospital and facility datasets, Care Compare provider information, enrollment and ownership files, and relevant cost reports. Use them to investigate location, facility type, scale, ownership, and system relationships. Check publication notes and definitions before treating a field as a current commercial attribute.
How should hospital and parent identities be matched?
Normalize CCNs, NPIs where relevant, legal names, addresses, parent relationships, and facility identifiers. Deduplicate without collapsing distinct sites into one buying entity. Ownership changes, newly observed facilities, and altered system links should enter a verification queue before account routing.
How should size and ownership segmentation handle stale data?
Segment the universe by the size proxy, facility type, geography, system, and ownership relevant to the offer. Check reporting periods and revision dates: cost reports can lag current operations, and a changed public record may reflect a correction rather than a new business event.
Which changes justify further sales research?
Monitor ownership changes and new locations across the full eligible healthcare market. Give sellers the source, date, matched entity, possible service need, decision-owner hypothesis, and what still requires confirmation. A CMS listing does not reveal an account’s private vendor contracts or establish an active purchasing process.
How should the account universe stay useful?
Maintain source refresh checks, entity-resolution tasks, account ownership, and evidence-backed seller queues. Compare coverage with purchased lists, then measure accepted accounts and healthcare sales-accepted opportunities. The result should be a reusable market-research system, not a one-time hospital spreadsheet.