Sequence of characters used to uniquely refer to the individual that selects insurance benefits.
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.
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.
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