Health Insurance Information

USCDI v3- "Health Insurance Information" Clarification

The “Health Insurance Information” Data Class currently does not provide applicable vocabulary standards nor guidance regarding the scope of the term “Health Insurance.” Arrive Health is seeking clarification confirming "Health Insurance” includes both medical and prescription insurance. Arrive Health supports the expansion of USCDI to include the new Health Insurance Information Data Class and recommends it accurately encompasses both medical insurance and prescription insurance information. Comprehensive health insurance information includes medical insurance coverage and prescription insurance coverage. Without requiring prescription insurance information, we are failing to capture the complete picture of health insurance coverage, and as a result, we are failing to capitalize on the innovative technologies and achievements presently available to provide transparency. One of the primary ways patients interact with the healthcare system is through prescription drugs. It is important to be inclusive of both medical and prescription fields given the increasing overlap for items like specialty medications and the growing importance of patients and providers knowing the full medical history. In the pivotal shift to include insurance information as a new Data Class, prescription drug insurance information is a critical element that must be included to support patient care, disparity reduction, drug adherence, and interoperability. As evidenced by Medicare Part D, comprehensive health insurance includes medical insurance coverage and prescription insurance coverage. Medical insurance information is just one piece of the critical data needed for price transparency. Often, patients have different insurance coverage for medical and prescription drugs. Employers that contract separately for medical and pharmacy require representation of both medical and pharmacy eligibility for interoperability to work comprehensively for their members. Thus, to achieve complete interoperability, prescription insurance information must be included in the Data Class. Arrive Health strongly encourages ONC to clarify that the USCDI v3 “Health Insurance Information” Data Class includes both prescription drug insurance information and medical insurance information. Thank you again for the opportunity to provide comment on USCDI Draft v3. We appreciate your efforts in maintaining core data sets to promote system-wide interoperability and value your consideration.   Sincerely, Arrive Health

USCDI-Version-3-July-2022-Final (1).pdf

Policy Number and Subscriber Name

Consider adding data elements for:

• Policy Number
• Subscriber Name

This comment is submitted on behalf of the National Emergency Medical Services Information System (NEMSIS) Technical Assistance Center.

Lantana Consulting Group Comment

Lantana recommends ONC include the Facility ID element in USCDI V3. The post-acute care (PAC) assessment instrument collects Facility Identifier information and standards exist for Facility ID.

Health Insurance Information

This new USCDI V3 data category includes several data elements related to an individual’s insurance coverage for health care.  While the information is valuable and necessary to support interoperability, several of the proposed data elements are not mature enough to be listed as a V3 element. If you consider the lack of clarity and consistency across V2, C-CDA Templates, and US Core Profiles for representing data elements such as Coverage Type, Member Identifier, Subscriber Identifier, Group Number, and Payer Identifier, these elements do not have sufficiently mature implementability compared to other USCDI V3 data elements. While we agree the proposed Health Insurance Information data elements are critical to support valuable interoperability use cases focused on getting the right information to the right parties at the right time, without well-formed identifier systems for elements such as payer identification and member or subscriber identifier, and without a single, consistent, accessible vocabulary for Coverage Type, adding this category of information to USCDI V3 will fail. It also will undermine trust in the methodology used to assess the maturity of data elements promoted to the level of a recognized USCDI data element.  If ONC is in favor of keeping Health Insurance Information in the list of USCDI V3, consideration needs to be given to enabling an effort that supports creation of well-formed identifiers and code systems for these concepts, as well as an initiative to drive adoption across all Health IT standards used to exchange this category of information. 

USCDI V3 Comment 20220429_1.pdf

NACHC Comment

NACHC supports the comment from CMD-CCSQ and believes health insurance information is critical to support patient access and care systems that support appropriate prescribing, referral, and benefits delivery.    We strongly support the use of the code systems and codes described by the code systems to ensure robust and patient-centered support for patients in the US healthcare system.   See attached document for a detailed summary of all NACHC USCDIv3 comments.

2022-04-30 NACHC USCDIv3 Letter of Support_5.pdf

Health Insurance Information

The Regenstrief Institute supports the USCDI Task Force recommendation to add Health Insurance Data Class to USCDI Version 3. We also recommend including LOINC as a terminology standard to capture concepts related to a patient’s health insurance status that can be coordinated or mapped to the SoPT Payer Value Set found here:  Source of Payer Typology Value Set Some LOINC examples include 87520-3 Coverage type and 89061-1 Insurance group number.

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.