| Submitted By: Barry R Hieb
/ Global Patient Identifiers, Inc. (GPII)
|
| Data Element Information |
| Use Case Description(s) |
| Use Case Description |
[Note to reviewers: This ONDEC submission tool is malfunctioning and will not let me add additional use cases so I have submitted all the use case data as a single entry into this description buffer.]
identifiers will be used any time the healthcare system needs to accurately identify an individual. This may be for clinical care, for billing, for research, for education, or for other related activities. The individual requests an identifier and, once it is issued and assigned to that individual, can present it for identification at all subsequent healthcare encounters. Over time, as more patients and organizations enlist in the identification system it is assumed that a majority of United States patients will use this approach to reliably identify themselves at virtually any healthcare organization. identifiers are particularly valuable for any healthcare activities that occur across organizational boundaries. Because the identifier is tied to a person, rather than an organization, it remains valid wherever that person’s information is transported.
Accurate patient identification is inextricably linked to healthcare information interoperability. It is not possible to accomplish interoperable information exchange between two separate healthcare organizations until it is certain they have identified the same individual. Conversely, interoperability requires a patient identification mechanism that is permanently linked to each individual, rather than any set of healthcare organizations. A critical distinguishing characteristic of identifiers is that they are permanently linked to one, and only one, individual. Their identification of that individual is completely portable in the sense that that individual’s identity can accurately go wherever information about that individual is required. This combination of healthcare data interoperability and -mediated identity represents the critical synergy that will make simple, seamless, accurate healthcare information exchange a reality.
Typical use cases are numerous and include:
• Patient uses the identifier to register for a clinic visit or inpatient admission
• Provider uses the identifier to label a laboratory specimen
• Radiology vendor uses the identifier to label a radiology report
• Patient uses the identifier to assemble their own longitudinal medical record
• Physician uses the identifier to transmit information to another clinician
• Patient uses the identifier to enable their ‘new’ physician to access their information
• Parent uses their identifier to establish authorized access to their child’s medical data
• Researcher uses an identifier to create an anonymous patient record for analysis
• Physician, with appropriate authority, overrides patient privacy to provide life-saving emergency medical care
• Any other situation where a clinician is trying to reliably access a patient’s information
• Healthcare organization repairs identity for a victim of identity theft
The ability to easily identify each individual without error across all of their medical encounters will become a compelling reason for virtually every healthcare organization and the majority of United States patients to participate in this system. The system is designed to scale to cover the nation’s population for many generations if needed.
Estimate the number of stakeholders who would capture, access, use or exchange this data element or data class:*
We anticipate that over time (since participation in the system may be voluntary and patient recruitment may initially be a slow process) identifiers will evolve to a Level 2 degree of use. Use of this data element enables increased convenience and safety for patients as well as the ability to manage personalized privacy schemas. For providers and provider organizations, enable improved efficiency; improved patient safety; accurate interoperability; and make possible the realization of significant cost savings.
Primary Use Case - Patient registration across multiple sites
A patient presents to a healthcare organization (location A) to enroll and obtain a identifier. Since this is the first time this individual has encountered the system, the healthcare organization (likely in conjunction with a third-party identity provider) will identity-proof the patient to at least an IAL level 2 of assurance. After identity-proofing the patient, the organization submits a request to the core services for a identifier. Open-source software is provided for this function. The core services generate an open identifier while recording the date/time the identifier was created along with its status and the requesting healthcare organization’s identity.
The healthcare organization’s software, working with the open-source software provided, ensures that the is bound to that individual’s record in its local Enterprise Master Patient Index (EMPI). An identification token, with the in both human and machine-readable form, is provided to the patient. This token may be contained in a smartphone app or a simple wallet-size card.
For any subsequent visits to this healthcare organization (location A), the patient presents their token at the admitting department and the token is matched against the value listed in the EMPI. The healthcare organization authenticates the patient against PII it has retrieved from the EMPI to ensure they are the valid owner of the token. The entire registration process should take less than 30 seconds and should require no manual data entry.
Later, the patient presents their token to register at a different healthcare organization (location B). The is read automatically (preferred) or entered manually and an EMPI search is performed. The will not be found in location B’s EMPI. This causes that organization's open-source software to query core services to learn if the is valid and, if so, where it has been used previously. The services respond that the identifier is valid and information concerning this individual can be found at location A. Location B contacts location A to retrieve PII for this person and authenticates the individual against it to complete their registration.
If the patient has presented at location B previously, their EMPI record is now updated with the . If not, a new EMPI record is created containing the . When this transaction at location B is complete, the core services now know that information associated with this resides at both locations A and B.
Registration at all subsequent healthcare organizations follows this same pattern no matter how many locations are eventually involved. Over time, a comprehensive picture of all the locations that have medical information concerning this individual is formed in the core services. However, at no time do the core services have knowledge of the patient's identity.
Please describe the additional use case: *
Repair of identity theft
Estimate the number of stakeholders who would capture, access, use or exchange this data element or data class: *
Any patient who has been a victim of identity theft or a data breach will want to repair that damage as soon as possible. Similarly, any healthcare organization that has experienced an episode that compromises medical information wants to recover from that incident as rapidly and thoroughly as possible. Over time, a majority of the U.S. patient population will want to avail themselves of these recovery services.
Secondary use case - Repair of identity theft
A patient has used their token to register across multiple healthcare organizations. They keep their token, a laminated ID card, in their wallet. One day they forget their wallet at a gas station. By the time they return, the wallet and their token have disappeared. Realizing that this represents an opportunity for significant identity theft, the patient contacts his primary care provider’s office in order to have his deactivated and replaced.
The security agent at the physician’s office listens to the patient’s story. If the patient has a backup copy of their , they can present that as validation. Alternatively, the security agent has access to the patient’s PII through the organization’s EMPI and can use that to authenticate the patient’s claimed identity. Once the agent is convinced that the patient is the individual represented by the lost she transmits a “replace” directive to the core services. The patient’s current is deactivated when the core services change the identifier’s status to “terminated”. From this time forward that identifier is no longer useable for any medical activity.
The services create a new identifier of the same privacy class and issue it to the requesting care delivery organization. The new identifier is substituted in that organization’s EMPI and a new token with that identifier is issued to the patient.
At the same time, the core services send a transaction to each of the locations where the previous identifier has been used. This transaction indicates that the previous is now terminated and should be replaced with the new one. This activity ensures that no matter how many locations have used the “old” , they will be correctly updated at “electronic” speed to reflect the new one. At the end of this process the patient will have a new identifier and that change will have been communicated to every location where the old one has ever been used. This restores the integrity of the patient’s identity across all their medical record locations and ensures that the associated clinical information will still be properly processed.
This use case represents an example of the system’s ability to assist fraud prevention.
|
| Estimate the breadth of applicability of the use case(s) for this data element
|
We anticipate that over time (since participation in the system may be voluntary and patient recruitment may initially be a slow process) identifiers will evolve to a Level 2 degree of use. Use of this data element enables increased convenience and safety for patients as well as the ability to manage personalized privacy schemas. For providers and provider organizations, enable improved efficiency; improved patient safety; accurate interoperability; and make possible the realization of significant cost savings.
|
| 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) |
ASTM/ANSI E 1714 Standard Guide for Properties of a Universal Healthcare Identifier (UHID), originally approved in 1995. Most recently approved in 2007.
https://www.astm.org/E1714-00.html
|
| Additional Specifications |
A wide variety of documentation including use cases, descriptive material, white papers, technical and operational descriptions is available. Contact bhieb@vuhid.org, 520-320-6220. |
| Current Use |
In limited use in test environments only |
| Supporting Artifacts |
The data element described in this document is currently being used at the comment level in limited test environments.
Discussion: The federal unique identifier prohibition
The creation of a unique identifier system for healthcare was mandated by the federal HIPAA legislation passed in 1995. However, implementation of this system has been inhibited for over 20 years by the establishment in 1997 of a federal prohibition (HHS section 510) on the use of federal resources to create or promulgate a unique healthcare identifier (see subsequent discussion concerning this in the section on “Other challenges to implementation”.) Despite that prohibition being withdrawn by the House of Representatives each of the past 3 years, the prohibition remains in place because the senate has been unwilling to remove it.
To make progress on this issue possible, GPII has operated with private funding and suggests that going forward funding be provided by the healthcare industry completely separate from any federal support. The identification system described in this document has been specifically designed and implemented to succeed whether section 510 has been rescinded or not. In the future if section 510 is rescinded, we will welcome the presence of federal resources in an advisory role, but it is our intention to maintain the identification system described here as a permanently private enterprise/industry effort. We are confident that the simplicity and cost-effectiveness of the approach we have outlined here makes an entirely private-enterprise/industry implementation feasible.
Supporting artifact: AHIMA/PIDN
https://catalog.ahima.org/view/251156390/
In 2021 AHIMA, on behalf of The Patient ID Now coalition, released “Framework for a National Strategy on Patient Identity.” This 12-page document provides an overview of patient identification concerns, a history of significant events, a set of requirements to solve the patient matching problem, and a list of references. The identifiers system described here meets all the criteria contained in this document.
Supporting artifact: RAND analysis
www.rand.org/t/rr2275
The RAND Corporation has performed two in-depth analyses of the impact of the system on patient identification. The most recent evaluation was performed in 2018 and included the following statement (page 25) - “If adopted and used as intended, this solution would match records used by the same individual perfectly”. In other words, there would no longer be issues with errors in patient matching. Their analysis is contained on pages 23-27 and 76-78 of the report. The system (AKA voluntary universal identifier in their document) was evaluated favorably compared with any of the other options they considered.
Supporting artifact: The demonstration system
contact 520-320-6220; bhieb@vuhid.org
The identifier demonstration illustrates how accurate identification can be incorporated into the routine operation of healthcare organizations. This demonstration system includes the core services and multiple instances of the open-source software that is provided to healthcare organizations at no cost. The demonstration system has the ability to create new pseudo-healthcare organizations and pseudo-patients. It can then assign individuals one or more identifiers. These pseudo-patients can be registered at multiple locations and the person executing the demonstration can exercise all of the capabilities associated with . We anticipate that in addition to being a powerful educational tool, the demonstration system will help guide healthcare organizations on how to integrate system capabilities into their existing healthcare automation environment.
|
| Extent of exchange
|
1 |
| Supporting Artifacts |
The patient identification approach is just now preparing to enter its first clinical prototype deployments. We anticipate that it will be at least one year before high volume information exchange can be demonstrated. Because the approach relies on voluntary participation by both patients and healthcare organizations, it is difficult to anticipate the rate at which participation will accelerate. However, our preliminary analysis indicates that the economics and the operational benefits appear to offer overwhelming advantages to those who choose to participate.
|
| Potential Challenges |
| Restrictions on Standardization (e.g. proprietary code) |
The patient identification system represents a reference implementation of ASTM/ANSI standard E 1714 which was first approved in 1995. The implementation of this standard by GPII should enable a completely uniform and standardized deployment of the data element. GPII has defined the interface supported by the core system services. It also provides open-source software which is deployed at each healthcare organization site to ensure a standard interface with the system services. This combination ensures that each will be properly processed every time it is encountered by the system. Because are a new data element, there is an opportunity to deploy them in a controlled manner that avoids the entropy associated with pre-existing data elements that have been used in disparate ways by a variety of historical implementations and therefore cannot be effectively standardized. |
| Restrictions on Use (e.g. licensing, user fees) |
The precise financial model used to support the system is still under evaluation. We believe that the patient identification system should be available to patients at no charge. Instead, each participating healthcare organization could be charged an annual subscription fee based on its volume of identifiers used. There could also be incremental charges for unusual circumstances such as recovery from a data breach. Many possible options exist for how the funding model will be deployed. We believe that representatives from all parts of the healthcare industry should be involved in deciding on the most appropriate option. |
| Privacy and Security Concerns |
Privacy and anonymity
identifiers should be protected with the same privacy and security mechanisms as apply to any other patient identifiable information. If an identifier is compromised (e.g. loss, identity theft, data breach, etc.) efforts should be undertaken immediately - using the mechanisms provided by the system - to correct the error and restore the integrity of the patient’s identification. The system includes specific functions to make the correction of patient identification errors easy and simple including repair of an identifier that has been distributed to multiple separate healthcare organizations. Patients will be encouraged to guard the privacy of their personal but it will be impossible to avoid all instances of user error. Instead, the system has been designed so that once such an error is detected, it can be corrected rapidly and completely by the patient working in conjunction with their healthcare organization.
Privacy and the accompanying need to support anonymity are essential capabilities of the patient identification system. Each patient can define their own privacy schema as they see fit, and modify it over time as their medical situation evolves. Figure 1 shows the approach to privacy. Everyone may determine their own privacy domain requirements. They might have no privacy concerns, in which case the patient’s entire medical information set consists of an aggregate of all their information tied to one open . In contrast, the person shown in figure 1 has decided that from a privacy perspective they want to keep their psychiatric and genetic information separate from the rest of their openly available medical data. To accomplish this, she has requested a single open identifier for all the information she wants to be available to all her caregivers, and she has obtained two private identifiers and assigned them to the psychiatric and genetic components of her medical information. During each clinical encounter she controls what information her caregiver sees by deciding whether to present the associated to the caregiver by using her associated tokens. This approach allows each patient to define their own privacy requirements and can operate without the need for static consent documents.
Figure 1 (This figure did not properly download. A brief description follows.)
Figure 1 shows a patient that has chosen to divide their medical information into three segments. They have obtained two private to designate their psychiatric and genetics information and one open to link to all of their other clinical information.
Anonymity
Since private are anonymous, a patient can use them in situations where they choose not to be identifiable. This approach provides a simple but powerful mechanism to enable each patient to assert privacy as they see fit, while still maintaining error-free patient identification. For example, a patient could maintain complete anonymity by using only a single private identifier for all her healthcare information.
(It is important to note that it is not possible for a malicious individual to create a valid de novo. The existence of the “fingerprint” represented by the check digits in the identifier means that it is not feasible for a potential malingerer to create a specious that will be accepted by the system as valid. This is true even if the hacker has previously managed to gain access to a set of valid . The fingerprint cannot be reverse-engineered from existing valid identifiers.)
The patient can modify this privacy situation over time by adding new private identifiers or replacing existing ones to reflect changes in their medical situation. Using these techniques, sets of clinical information can be created, combined, subdivided, or eliminated from a privacy perspective.
The system also supports a break-the-glass option which allows an authorized physician to provide life-saving care by overriding established privacy to obtain a comprehensive view of a patient’s medical record. At the end of such an episode the patient’s privacy can be restored. More details on this process can be provided.
There are certain privacy issues, e.g. abortion, where there will not be an agreed-upon privacy approach that is acceptable to all. Each of these conundrums will require extensive analysis and debate. However, the privacy and anonymity approach described here provides the flexibility and autonomy for each patient to implement sufficient privacy constraints to meet their own personal needs.
|
| Estimate of Overall Burden |
The identifier will be used by all sections of the healthcare industry. Every organization can benefit from its use. Implementation is facilitated by standardization of interfaces using the open-source software provided.
How hard is it to access and provide the data? Each assigned is available as a PII data element in the organization’s EMPI.
Is it only available in an outside system, such as a lab reporting system? No, the is available to any healthcare organization’s IT system that provides access to the EMPI.
Does it need to be calculated by the patient or provider, or can it be automatically retrieved or calculated by the system in a production environment? No calculation is necessary. It can be automatically retrieved by the system in a production environment.
Does it require significant time on the part of patient or provider to access or record or does it require an interruption in normal workflow to capture? Storage of the identifier is performed as part of the initial process of acquiring it. There is no subsequent processing required.
Does it require significant developer time to implement in EHR systems? Initial creation of the software to acquire the may require roughly 1-2 weeks of development time. This will be much less once a completely standard interface EHR interface is deployed. There should be no further developer time required.
Each that is issued by an organization must be accompanied by one or more physical tokens that are presented to the requesting individual. The token is generated when the identifier is requested and is presented to the individual, preferably in real time. Each token has the listed in plain text as well as at least one automatically readable form (2D bar code, QR code, etc.) of the identifier. The requesting clinical organization is responsible for choosing the technology of its token(s) and being able to create them on demand when a new identifier is issued. The organization also must equip its ADT system with the technology needed to read the automated representation of the identifiers it produces, e.g. a QR code reader.
Installation of the system at a healthcare organization site will require interfaces to that organization’s EMPI and ADT systems. The organization will also need to design and implement a system to produce patient tokens that represent each they issue. A local server will need to be established to support that institution’s specific patient population data. Once those tasks are completed it is a question of training clinical and administrative staff on how to properly use the system.
|
| Other Implementation Challenges |
When the system creates a new identifier, this item needs to be written into the requesting healthcare organization’s EMPI. This action binds the identifier to the individual specified by that EMPI record and makes it subsequently available to authorized users. The most logical approach to accomplish this would be to establish a FHIR interface API and use it to connect the healthcare organization’s EMPI to the GPII-supplied open-source software. However, currently few healthcare organizations have chosen to implement the FHIR APIs that would enable the open-source software to write a directly into their EMPI. This means that the system cannot use a standardized FHIR interface to integrate with all healthcare organization IT systems. Instead, for each EHR vendor, we will create a software “shim” unique to that client’s EHR vendor. The client’s IT department can use that shim to create whatever custom software is necessary to write the into their own EMPI. |
ONC 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 0
- Data element is not 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 0
- Use cases apply to a limited number of care settings or specialties, or data element represents a specialization of other, more general data elements.
|
|
Comment