Data related to an individual’s insurance coverage for healthcare.

Data Element

Applicable Vocabulary Standard(s)
Coverage Status

Presence or absence of health care insurance.
Coverage Type

Category of health care payer. (e.g., Medicare, TRICARE, Commercial Managed Care - PPO)
Relationship to Subscriber

Relationship of a patient to the primary insured person.
Member Identifier

Sequence of characters used to uniquely refer to an individual with respect to their insurance.
Subscriber Identifier

Sequence of characters used to uniquely refer to the individual that selects insurance benefits.
Group Identifier

Sequence of characters used to uniquely refer to a specific health insurance plan.
Payer Identifier

Sequence of characters used to uniquely refer to an insurance payer.

Data Element

Applicable Vocabulary Standard(s)
Coverage Status

Presence or absence of health care insurance.
Coverage Type

Category of health care payers. (e.g., Medicare, TRICARE, Commercial Managed Care - PPO)
Relationship to Subscriber

Relationship of a patient to the primary insured person.
Member Identifier

Sequence of characters used to uniquely refer to an individual with respect to their insurance.
Subscriber Identifier

Sequence of characters used to uniquely refer to the individual that selects insurance benefits.
Group Identifier

Sequence of characters used to uniquely refer to a specific health insurance plan.
Payer Identifier

Sequence of characters used to uniquely refer to an insurance payer.

Data Element

Applicable Vocabulary Standard(s)
Coverage Status

Presence or absence of health care insurance.
Coverage Type

Category of health care payers, insurance products, or benefits.

Examples include but are not limited to Medicaid, commercial, HMO, Medicare Part D, and dental.​
Relationship to Subscriber

Relationship of a patient to the primary insured person.
Member Identifier

Sequence of characters used to uniquely refer to an individual with respect to their insurance.
Subscriber Identifier

Sequence of characters used to uniquely refer to the individual that selects insurance benefits.
Group Identifier

Sequence of characters used to uniquely refer to a specific health insurance plan.
Payer Identifier

Sequence of characters used to uniquely refer to an insurance payer.

Data Element

Applicable Vocabulary Standard(s)
Coverage Status

Presence or absence of healthcare insurance.
Coverage Type

Category of healthcare payers, insurance products, or benefits.

Examples include but are not limited to Medicaid, commercial, HMO, Medicare Part D, and dental.
Relationship to Subscriber

Relationship of a patient to the primary insured person.
Member Identifier

Sequence of characters used to uniquely refer to an individual with respect to their insurance.
Subscriber Identifier

Sequence of characters used to uniquely refer to the individual that selects insurance benefits.
Group Identifier

Sequence of characters used to uniquely refer to a specific health insurance plan.
Payer Identifier

Sequence of characters used to uniquely refer to an insurance payer.

Data Element

Applicable Vocabulary Standard(s)
Coverage Status

Presence or absence of healthcare insurance.
Coverage Type

Category of healthcare payers, insurance products, or benefits. 

Examples include but are not limited to Medicaid, commercial, HMO, Veterans Benefits Administration, Medicare Part D, and dental.
Relationship to Subscriber

Relationship of a patient to the primary insured person.
Member Identifier

Sequence of characters used to uniquely refer to an individual with respect to their insurance.
Subscriber Identifier

Sequence of characters used to uniquely refer to the individual that selects insurance benefits.
Group Identifier

Sequence of characters used to uniquely refer to a specific health insurance plan.
Payer Identifier

Sequence of characters used to uniquely refer to an insurance payer.

Data Element

Applicable Vocabulary Standard(s)
Health Insurance Coverage Status

Presence or absence of healthcare insurance.
Health Insurance Coverage Type

Category of healthcare payers, insurance products, or benefits. 

Examples include but are not limited to Medicaid, commercial, HMO, Veterans Benefits Administration, Medicare Part D, and dental.
  • Source of Payment Typology (SOPT)
Relationship to Health Insurance Subscriber

Relationship of a patient to the primary insured person.
Health Insurance Member Identifier

Sequence of characters used to uniquely refer to an individual with respect to their insurance.
Health Insurance Subscriber Identifier

Sequence of characters used to uniquely refer to the individual that selects insurance benefits.
Health Insurance Group Identifier

Sequence of characters used to uniquely refer to a specific health insurance plan.
Health Insurance Payer Identifier

Sequence of characters used to uniquely refer to an insurance payer.
Health Insurance Coverage Period

The time frame in which the policy is in force.
Health Insurance Payer

Issuer of the policy.
Health Insurance Plan

Health insurance offering or package.
Health Insurance Plan Identifier

Sequence of characters used to uniquely refer to an insurance plan.

Comment

Submitted by csnewman on

Similar descriptions for 2 data elements

The descriptions of Health Insurance Group Identifier and Health Insurance Plan Identifier are very similar and should be disambiguated

  • Health Insurance Group Identifier - Sequence of characters used to uniquely refer to a specific health insurance plan.
  • Health Insurance Plan Identifier - Sequence of characters used to uniquely refer to an insurance plan.

Submitted by rdillaire on

CMS-CCSQ Sup. Health Insurance Info data elements for USCDIv6

Data Elements:  Coverage Period (Level 2), Medicare Patient Identifier (Level 0), Payer Name (Level 2), Plan Name (Level 2), and Group Name (Level 2)

  1. Recommendation: Advance Medicare Patient Identifier to Level 2 and add all these data elements to Final USCDI v6.
  2. Rationale: Inclusion of these common data elements for nationwide interoperability is essential for such use cases as value-based care, health equity including affordability for lower-income individuals, and enabling patients across the board to determine costs and affordability up front. This Health Insurance Informationdata class is associated with the overall primary and secondary coverage for the individual. In some cases, it may be different from the benefit used for a particular encounter or claim (e.g., worker's comp benefits). We recommend aligning the naming of Medicare Patient Identifier (MPI) with CMS’s use of Medicare Beneficiary Identifier (MBI). While these data elements are already included in the latest FHIR US Core and Consolidated CDA implementation guides (IGs) referenced in the Health, Data, Technology, and Interoperability-1 Final Rules (HTI-1), the implementation community can benefit from more clarity on how to consistently populate these fields—in particular Payer Name and Group Name—as there is variation between what a typical insurance card shows versus what is best used on real-time eligibility (RTE) queries with health plans.

Submitted by NCQA on

NCQA Recommendations for USCDI v6- Coverage Type

Coverage Type: 

Recommendation type: Modification to existing USCDI element.

Recommendation: Adjust the data element definition and examples to note that coverage type should include product line (for example Commercial, Medicare, Medicaid), product (for example PPO, HMO, POS), and benefit (for example drug, mental health).

Rationale: Comprehensive, and hierarchical, coverage type information allows for utility of the data. One individual could fall into several categories within Coverage Type. For example, an individual may be classified as enrolled in an HMO, but under the current element definition, stakeholders would be unable to distinguish if the HMO is a commercial product. In NCQA’s HEDIS reporting structure, we mitigate this challenge by asking organizations to submit multiple records to indicate if a member is in multiple Coverage Type categories. For example, one member enrolled in a commercial HMO with a drug benefit has three sets of records: one indicating commercial enrollment dates, one indicating HMO enrollment dates, one indicating drug benefit enrollment dates.  It would be more efficient to have one set of records indicating that the member is in Product line: Commercial; Product: HMO; Benefit: Drug. NCQA created a reference sheet (attached) to inform HL7 community efforts to further refine the Coverage Type structure. We encourage ASTP to consider how to make this data element more granular in USCDI. 

NCQA-Coverage Type-SOP.pdf

Submitted by NCQA on

NCQA Comment on Smoking Status: for USCDI v5

  1. Smoking Status:

NCQA recommends updating the element name to Tobacco-Use Assessment to encompass assessment of broader tobacco products beyond smoked products/cigarettes; This aligns with the FDA definition of Tobacco products. We also recommend adding to the examples of items that fall under this element quit date and smoking duration, in addition to the examples of pack-years and current use already included.

We recommend updating the terminology to include LOINC in addition to SNOMED. Smoking status, tobacco-use status, and smoking behavior details (i.e., pack-years) are well defined by LOINC and/or SNOMED.

Comprehensive assessment of tobacco-use and smoking behaviors remain a public health priority and are essential to appropriately providing cessation intervention. These data elements are also crucial for understanding a patient’s eligibility for lung cancer screenings, a screening that is recommended by the U.S. Preventive Services Task Force and that remains underutilized despite its proven effectiveness. NCQA is currently developing measures to incentivize routine tobacco use assessments and appropriate lung cancer screening for those eligible based on smoking history.

Submitted by NCQA on

NCQA Comment on Coverage Period: For USCDI v5

  1. Coverage Period:

NCQA recommends the inclusion of coverage period, the coverage start and end dates, in USCDI v5. This information is essential when sharing any other health insurance related information already included in USCDI for context about the coverage time period and supports assessments of patient access to resources and care, a stated ONC priority. Coverage period is also used widely in quality measurement to assign people appropriately to the measure population. This element is included in the US Core IG Coverage profile as must support.

Submitted by EMLANDON on

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

Submitted by joshualegler on

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.

Submitted by Lantana Consul… on

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.

Submitted by LisaRNelson on

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

Submitted by RUy on

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

Log in or register to post comments

FormGuide

Help

1. Optional: Background Text / Cover Letter

The "Optional Background Text / Cover Letter" field provides space for additional context or introductory information related to your comment.

If you wish to provide context, explanation, or an introduction to your comment, enter this information in the field labeled "Optional Background Text / Cover Letter." This is entirely optional and is most useful when submitting multiple related comments or when additional background would help reviewers understand your feedback.

If you are only commenting on a single data class or element, you may leave this field blank.

2. Select the Data Class

To specify which data class your comment addresses:

  1. In the "Data Class" drop-down menu, select the appropriate data class you want to comment on.
  2. If you are providing a general comment that is not specific to a data element, select "General" from the options. Comments with this designation will be displayed on the USCDI landing page.
  3. Note that the Data Class field will automatically populate based on your current location in the platform:
    1. If you are on a data class page, the field will be set to that specific data class
    2. If you are on a data element page, the corresponding data class will be pre-selected
       

3. Select the Data Element

To specify which data element your comment addresses:

  1. In the "Data Element" drop-down menu, select the specific data element you want to comment on.
  2. The drop-down menu will display only the elements available under the data class you selected in the previous step.
  3. You can use the search function within the drop-down to quickly locate a specific data element.
  4. If you are commenting on the data class itself rather than a specific element, you may leave this field blank.

Note: Comments on a specific data element will appear on the respective data element page, while comments on a data class (without a specific element selected) will appear on the landing page for that data class.
 

Data Class and Data Element

Fig 1 The "Data Class" and "Data Element" dropdown menus allow users to specify the exact content they wish to comment on.

4. Optional: Propose New Data Class or Element

If you cannot find the appropriate data class or element for your comment:

  1. Instead of clicking the "Comment On An Existing Data Class Or Element" button, click the adjacent button labeled "Propose a New Data Class or Data Element."
  2. This will redirect you to the ONDEC (ONC New Data Element and Class) Submission System.
  3. In the ONDEC system, follow the provided instructions to submit your proposal for a new data class or element.
  4. Once your proposal is submitted through ONDEC, it will be reviewed separately from the commenting process.
Propose New Data Class or Element

Fig 2 The "Propose a New Data Class or Data Element" button redirects users to the ONDEC Submission System for proposing new data elements not currently available in the system.

5. Complete the Comment Form

Fill out the required fields in the comment form:

Subject: Enter a brief, descriptive title that summarizes your comment. This helps reviewers quickly understand the nature of your feedback.

Comment: In this field, provide the full details of your comment or feedback. Be as clear and specific as possible about your suggestions, concerns, or observations. Include any relevant details that support your position.

6. Optional: Add Additional Comments

If you need to comment on multiple data classes or elements:

  1. After completing your first comment, click the link labeled "Comment on another data element" at the bottom of the form.
  2. A new comment section will appear, allowing you to enter details for your additional comment.
  3. For each additional comment, you must select the appropriate data class and data element from the drop-down menus.
  4. Complete the Subject and Comment fields for your additional comment.
  5. Repeat this process for each additional comment you wish to submit.

Fig 3 The "Comment on another data element" link enables users to create multiple comments addressing different elements within a single submission.

7. Optional: Upload Supporting Files

The platform allows you to upload supporting documentation to enhance your comment:

  • Locate the "File Upload" section at the bottom of the comment form.
  • Click to upload any files (such as PDFs or documents) that provide additional context, evidence, or clarification for your comment.

Important: If you have already entered your comments using the form fields, there is no need to upload duplicate content in PDF format. The file upload feature is intended for supplementary materials only. Please avoid uploading files that contain the same information already provided in your comment text.

Upload Supporting Files

Fig 4 The "File Upload" section permits users to attach supporting documentation that supplements their written comments.

8. Optional: Save and Exit

If you need to pause your work and return to complete your comment later:

  1. Click the "Save and Exit" button at the bottom of the form.
  2. Your comment will be saved as a draft that you can access and complete later.
  3. When you return to the platform, you will see a red triangle with an exclamation mark next to the “Return to saved Comment” button, indicating that you have saved comments in draft status.
  4. Click this button to continue working on your draft.
  5. You will be taken to a review page where you can:
    1. Select "Submit Comment" to officially submit your feedback.
    2. Click "Edit" to return to the comment form and make changes
    3. Select "Discard Draft" to delete the saved draft and start fresh

Fig 5 A red triangle with exclamation mark indicator appears next to the “Return to saved Comment” button when draft comments are saved in the system.

9. Review and Submit

Once you have completed your comment:

  1. Click the "Review and Submit" button at the bottom of the form.
  2. This will take you to a review screen displaying your comment(s) in full.
  3. Review all information for accuracy and completeness.
  4. On this review screen, you have three options: 
    1. Click "Submit Comment" to officially submit your feedback
    2. Click "Edit" to return to the comment form and make changes
    3. Click "Discard Draft" to delete the comment and start fresh
  5. The review screen also includes a "Print" button that allows you to create a printed copy of your comments for your records. 
  6. If you choose to submit, your comment will be recorded in the system and made available for review by the appropriate stakeholders.
Review and Submit

Fig 6 The review screen allows users to verify comment content and make any necessary modifications before final submission.

USCDI Comments

Close

Add a New Comment

Review comment and Submit

Edit
Comment #1