Data related to an individual’s insurance coverage for health care.

Data Element
Policy Number
Description

The unique identifier for a specific insurance policy that defines a set of covered benefits and services along with other information that is necessary to administer the policy (e.g. financial obligations for both parties)
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

Comment

Log in or register to post comments