Health Insurance Information
Data related to an individual’s insurance coverage for health care.
Data Element
|
Coverage Period
Description
The time frame in which the policy is in force.
|
| Submitted By: Robert C Dieterle
/ On behalf of the Da Vinci Project
|
| Data Element Information |
| Use Case Description(s) |
| Use Case Description |
There is a need for providers and healthcare insurers to support and exchange common identifiers for a shared patient/member to ensure that the unique individual is identified and that appropriate information is exchanged and appropriate care is delivered and paid for by the healthcare insurer. Support for these elements will ensure that this data can be exchange, as necessary, when clinical or administrative data is exchanged. |
| Estimate the breadth of applicability of the use case(s) for this data element
|
Virtually all providers (>1,000,000), all healthcare insurers (>1,800), all hospitals (>7,000), all Pharmacies (>88,000), all ancillary services that submit bills payers for services delivered.
|
| Link to use case project page |
http://hl7.org/fhir/us/davinci-pdex/2019Jun/4_Use_Case_Scenarios.html |
| Use Case Description |
Providing a data class to enable the capture and exchange of member and health plan related information will reduce the likelihood of assigning clinical data to a health plan’s member record inappropriately when it is received by a health plan. |
| Estimate the breadth of applicability of the use case(s) for this data element
|
Virtually all providers (>1,000,000), all healthcare insurers (>1,800), all hospitals (>7,000), all Pharmacies (>88,000), all ancillary services that submit bills payers for services delivered. |
| Use Case Description |
For patient’s to be able to share data with other payers or even apps, they will need an identifier that they know about (example on current or former insurance card) so that they can correctly reference the former payer. Current thought is to use a string for the payer name – that can be challenging and problematic when you think of common words used in payer names. |
| Estimate the breadth of applicability of the use case(s) for this data element
|
Payer’s covered by the CMS Interoperability Final Rule (>300) and affected patients (>125 Million) |
| Healthcare Aims |
- Improving patient experience of care (quality and/or satisfaction)
- Improving the health of populations
- Reducing the cost of care
- Improving provider experience of care
|
| Maturity of Use and Technical Specifications for Data Element |
| Applicable Standard(s) |
Member, subscriber, group, and plan identifiers are assigned by healthcare insurer.
The coverage period is a standard date range during which the coverage is in effect.
There is currently no standard Healthcare Payer Identifier (e.g. HPID) but frequently the NAIC identifier is used but not required.
|
| Additional Specifications |
The Da Vinci Payer Data Exchange and Health Record Exchange FHIR IGs that are in ballot reconciliation.
https://build.fhir.org/ig/HL7/davinci-epdx/
http://build.fhir.org/ig/HL7/davinci-ehrx/
The CARIN Consumer Directed Payer Data Exchange FHIR IG that is in ballot reconciliation
https://build.fhir.org/ig/HL7/carin-bb/index.html
All HIPAA mandated transactions as defined in the respective ASC X12N standard implementation guide (TR3) all require/support these elements. Transaction include( but are not limited to): eligibility (ASC X12 Version: 005010 | Transaction Set: 270/271 | TR3 ID: 005010X279), billing (e.g. professional claims ASC X12 Version: 005010 | Transaction Set: 837 | TR3 ID: 005010X222), and for prior authorization (ASC X12 Version: 005010 | Transaction Set: 278 | TR3 ID: 005010X217
NCPDP transactions for order and dispense
|
| Current Use |
This data element has been used at scale between multiple different production environments to support the majority of anticipated stakeholders |
| Supporting Artifacts |
Any request for eligibility, reimbursement for covered services delivered by a provider must include one or more of these elements in the exchange.
|
| Extent of exchange
|
5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders. |
| Supporting Artifacts |
CAQH report on electronic business transactions
https://www.caqh.org/sites/default/files/explorations/index/report/2019-caqh-index.pdf
|
| Potential Challenges |
| Restrictions on Standardization (e.g. proprietary code) |
None |
| Restrictions on Use (e.g. licensing, user fees) |
None |
| Privacy and Security Concerns |
This data, like any patient data should be exchanged securely. Current processes exist, governed by CMS and ONC, to securely transfer this data. |
| Estimate of Overall Burden |
This information is currently collected by EHRs, practice management systems, registration systems, payer systems, pharmacy systems, PBM systems and other systems that participate in delivering and billing payers for care. Overall burden is minimal since the data is already required when exchanging administrative information (e.g. billing) |
| Other Implementation Challenges |
May require some system integration or duplicate entry to ensure the information is available for exchange in FHIR APIs and C-CDAs |
|
Submitted by rdillaire on
CMS-CCSQ Supports Coverage Period for USCDI v6
Recommendation: CMS CCSQ recommends advancing the Medicare Patient Identifier element to Level 2 and inclusion of the Coverage Period, Group Name, Payer Name, Plan Name, and Medicare Patient Identifier data elements in final USCDI v6.
Rationale: Inclusion of these common health insurance data elements for nationwide interoperability is essential for such use cases as value-based care, including affordability for lower-income individuals, and enabling patients to determine costs and affordability up front. This Health Insurance Information data 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). While these data elements are already included in the latest Fast Healthcare Interoperability Resources (FHIR) US Core and Consolidated Clinical Document Architecture (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.