Health Insurance Information

CMS-CCSQ Support for Health Insurance Data Class for USCDI V3

CMS-CCSQ supports the USCDI Task Force recommendation to add the entire Health Insurance Data Class to USCDI Version 3. This data class is critical to support assessments of patient access to resources and care—a CMS priority. CMS calls for inclusion of two Health Insurance data elements:

1. Data Element: Coverage Type, defined as the type of all-payer healthcare entity, as defined by the US Public Health Data Consortium Source of Payment (SOP) code system, applicable to a patient. For example, Medicare, Medicare HMO, Medicare FFS, self-insured, dental care, state SCHIP, private health insurance, commercial managed care, and self-pay.

Rationale: This patient-level information provides context for how healthcare benefits are covered for a patient and supports analyses and measurement of patient access to resources and care. This information is vital for administrative purposes (billing) and for quality measurement to help define target populations and to assess quality differences among patients with differing insurance coverage.

Maturity:

• Current standards: This data element is standardly defined by the SOP code system. The Coverage Profile has also been added to QI Core Implementation Guide (STU 4) and coverage type information can be exchanged using ‘.type’. The FHIR Coverage resource is currently classified as Level 2 for maturity level by HL7, indicating “the artifact has been tested and successfully supports interoperability among at least three independently developed systems leveraging most of the scope (e.g., at least 80% of the core data elements) using semi-realistic data and scenarios based on at least one of the declared scopes of the artifact (e.g., at a Connectathon). These interoperability results must have been reported to and accepted by the FMG”.
  • Code System SOP; value set: Payer (OID: 2.16.840.1.114222.4.11.3591)
  • FHIR Coverage resource, profile included in QI Core IG
• Current uses, exchange, and use cases: This information is currently electronically submitted by providers (hospitals, clinicians) using diverse EHR systems to CMS with every eCQM submitted for measurement. It is also necessary information for CMS and insurer reimbursement. Insurance type information is used by providers (e.g., hospitals, clinicians) for data used in billing.

2. Data Element: Subscriber ID, to enable exchange of the CMS Medicare Beneficiary ID (MBI), defined as the unique MBI used to identify Medicare patients.

Rationale: In the ONDEC system, there currently exists a data element for Subscriber ID under Health Insurance Data Class and a data element for Medicare Patient ID under patient demographics. MBI is a type of subscriber ID and may therefore be best represented under the Health Insurance Data Class as a specific Subscriber ID. We recommend the addition of Subscriber ID to USCDI version 3, which will allow for exchange of MBI as well as other subscriber IDs that may meet other use cases. MBI is a standardized identifier for all Medicare patients across the United States and is routinely exchanged with CMS. Providers and healthcare insurers need to support and exchange common identifiers for a shared patient/member. This ensures unique individuals’ information can be identified and linked across care settings and data sources to support clinical care and other use cases, including quality measurement.

Maturity:

• Current standards:
  • MBI format specifications: https://www.cms.gov/Medicare/New-Medicare-Card/Understanding-the-MBI.pdf where MBI is assigned to all Medicare beneficiaries.
  • FHIR Coverage profile included in QI Core IG: This information can be exchanged via ‘.subscriberID’.
• Current uses, exchange, and use cases: MBI is exchanged across the nation for all Medicare beneficiaries to facilitate provider-payer data exchange and member-mediated information exchange.