Data used to categorize individuals for identification, records matching, and other purposes.

Data Element
HL7-Identifier
Description

Globally unique identifier assigned to a patient by an organization asserting compliance with the referenced HL7 FHIR Identify Matching IG
Submitted By: Julie Maas / EMR Direct
Data Element Information
Use Case Description(s)
Use Case Description identifiers will be used both in organization to organization and in consumer-directed healthcare queries in which single high confidence person matches are needed. This may be for healthcare purposes though use beyond healthcare is permitted, when authorized. An individual can control the use of the identifier in consumer-directed workflows and identity services implementing the identifier may share it with the individual’s consent.
Typical use cases include:
• Patient registration, check-in, and access to portal or FHIR data
• Cross-system patient matching for treatment or other permitted purpose
• Patient Request purpose of use or Individual Access point to point or broadcast query
• Network-wide opt-in or -out of information services
• Audit log curation and access by a patient
• Access to health data and authorization of data sharing with third parties, via a credential bound to the identifier; credentials can be provisioned and retired as needed
• Identity services implementing the standard may offer its use outside healthcare settings, whenever strong authentication and/or identity assurance is needed, or simply to reduce the number of secure credentials an individual needs to maintain—reducing the likelihood of account compromise related to security fatigue and generally reducing instances of identity theft while increasing confidence in the identity of the individual on the other side of a transaction
• Numerous other privacy-preserving use cases in which a high assurance, secured (if an associated credential is desired by the individual) Digital Identity is available for passive (as permitted by law—i.e. patient match in a B2B records request for payment purpose) and permissioned use (sharing verified PII with a third party when authorized)
Estimate the breadth of applicability of the use case(s) for this data element Due to the ability for identifiers to be passively assigned at industry standard identity assurance levels, most industry stakeholders would be capable of implementing this identifier and would likely upgrade their enterprise identifiers or local database indexes to reflect unique individuals. Those implementers could be expected to include health care insurers (>1,800), third-party application developers, Credential Service Providers, healthcare provider organizations (300K), and all US consumers (>320M).
Link to use case project page https://confluence.hl7.org/display/PA/Patient+Matching+PSS
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) A system exists for using the identifier within HL7 FHIR transactions, particularly those invoking $match, but the standard also intends for the identifier to be used in other health information exchange transaction types as well as in non-healthcare specific transactions for example in OpenID Connect identity claims.
http://hl7.org/fhir/us/identity-matching/NamingSystem/Identity-HL7-Identifier
Additional Specifications HL7 Interoperable Digital Identity and Patient Matching Implementation Guide (http://hl7.org/fhir/us/identity-matching/ImplementationGuide/hl7.fhir.us.identity-matching)
Current Use In limited use in test environments only
Extent of exchange N/A
Potential Challenges
Restrictions on Standardization (e.g. proprietary code) N/A
Restrictions on Use (e.g. licensing, user fees) N/A
Privacy and Security Concerns Addressed in the Implementation Guide.
Estimate of Overall Burden This is difficult to estimate although systems likely create identifiers meeting this bar already; the initiative to step up identity assurance practices and manage records based on identities is expected to have cost savings in prevention of patient safety issues resulting from erroneous matches and in saving some cost of re-verifying patient identity when a reusable, strong assurance digital identity credential is available.
ASTP Evaluation Details
Each submitted Data Element has been evaluated based on the following criteria. The overall Level classification is a composite of the maturity based on these individual criteria. This information can be used to identify areas that require additional work to raise the overall classification level and consideration for inclusion in future versions of USCDI
Criterion #1
Maturity - Current Standards		 Level 2 - Data element is represented by a terminology standard or SDO-balloted technical specification or implementation guide.
Criterion #2
Maturity - Current Use 		Level 0 - Data element is captured, stored, or accessed in limited settings such as a pilot or proof of concept demonstration.
Criterion #3
Maturity - Current Exchange		 Level 0 - Data element is electronically exchanged in limited environments, such as connectathons or pilots.
Criterion #4
Use Case(s) - Breadth of Applicability		 Level 2 - Use cases apply to most care settings or specialties.
Evaluation Comment Given the limited use and exchange of this data element as submitted, further development, testing and use is needed before considering for advancement.

Comment

Log in or register to post comments