ASTM's "Standard Guide for Properties of a Universal Healthcare Identifier (UHID)" deals with the conceptual characterization of a UHID. It defines thirty (30) characteristics required of a UHID. The scope of the guide does not include implementation methodology, cost, or policy decisions. Encrypted UHIDs (EUHIDs) are included in the guide for hiding the identity of individuals while linking information. Separate EUHIDs are allowed for different episodes of care for the same patient. The guide also recommends the use of temporary patient identifiers (TPIs) controlled by individual organizations for emergency use and requires them to subsequently transfer all information to the correct UHID.
The UHID requires a Central Trusted Authority for processing request for a UHID. The Central Trusted Authority's responsibility will include issuing the sequential UHID, computing the check-digit, choosing the encryption scheme, generating the EUHID and maintaining either a cross index between UHID and EUHID or an appropriate decryption scheme to link the UHID and the corresponding EUHID. Therefore, the implementation of UHID will depend on the establishment of a Central Trusted Authority.
The guide provides a sample UHID and illustrates the application of the 30 UHID criteria to evaluate candidate UHIDs. The sample UHID and the illustration are not part of the ASTM Standards. The sample UHID consists of a sixteen (16) digit sequential identifier, a "." (period) that serves as a delimiter, a six (6) digit check- digit and a six (6) digit encryption scheme. Altogether, it consists of 28 numeric digits and a period. Dr. Barry Hieb, M.D. of Sunquest, Inc. proposes the sample UHID which was provided in the ASTM guide solely for the purpose of illustration for a candidate Unique Patient Identifier.
The Veterans Integrated Systems Network (VISN) in Florida is piloting the development and use of an Internal Control Number (ICN) based on the ASTM guide. The ICN is used for cross-indexing patients that visit multiple sites of care. The Veterans Health Administration (VHA) System maintains a national data base of patients' visit information received from the various VHA medical centers. The ICN works in conjunction with the national data base to track the locations of a patient's record. It uses patient identifiers and record locations to accomplish the cross indexing. VHA's objective is to create an index of ICNs (Master Patient Index) that uniquely ties the distributed records to patients. The ICN Master Patient Index includes patient identifier(s) and record locations. Mismatch and discrepancies are reported to respective sites and resolved with human intervention. ICN structure model does not include the trusted authority or the use of EUHID. Currently, the sample UHID is being piloted at three sites (Tampa, Gainesville and Lake City).
In November of 1996, the U. S. Department of Veterans Affairs (VA) issued its new Veterans Universal Access Identification Card with SSN, patient's photo and date of birth. The new card has these information printed, embossed, bar coded and also included in its magnetic stripe. It is used to identify patients and retrieve their demographic information during the course of active treatment. To handle patient encounters, SSN continues to be VHA's system-wide patient identifier. The ICN is piloted to serve as an internal control number to build a system wide Master Patient Index for cross referencing the distributed patient information.
Therefore, only Dr. Barry Hieb's Sample UHID proposal is analyzed here.
Both the ASTM guide and the example do not address implementation methodology. ASTM points out in its own evaluation that the sample UHID meets the ASTM criteria in concept, but its ability to meet the criteria in practice will depend on implementation methodology, policies and procedures, and the necessary administrative and technology infrastructure in place (Central Trusted Authority). In order for these components to be in place, planning and extensive preparation is required. It includes the designation of a central trusted authority, funding and development of specifications, design, testing, deployment, etc. The evaluation below is based on information currently available.
Accessible: Access is dependent upon the establishment of a network infrastructure, the trusted authority and policies and procedures that support the system.
Assignable: Assignment of the Sample UHID or EUHID, regardless of time or place of request, depends on the establishment and functions of a network infrastructure, the trusted authority, and the implementation of policies and procedures that support the system. It will also depend on the mechanism to request a Sample UHID.
Identifiable: This will depend on the identification information that the trusted authority links to the Sample UHID.
Verifiable: The Sample UHID includes a six (6) digit check-digit for verification.
Mergeable: The internal data structure of the Sample UHID does not directly support merging duplicate or redundant identifiers. They can be linked at the trusted authority.
Splittable: There is no inherent support for splitting the Sample UHID. New IDs can be issued for future use. Splitting for retroactive information must be handled by the trusted authority.
Linkable: The Sample UHID has the ability to function as a data element and support the linkage of health records in both manual and automated environment.
Mappable: With the use of appropriate database system and software, the Sample UHID can be used to map currently existing healthcare identifiers.
Content Free: The Sample UHID is free of information about the individual.
Controllable: This depends on the policies and methods that will be adopted by the trusted authority.
Healthcare Focused: The Sample UHID is recommended solely for the purpose of healthcare application.
Secure: The Sample UHID includes an EUHID which offers mechanism for secure operation through the use of encryption and decryption processes. These capabilities depend on the policies and procedures that will be implemented by the trusted authority.
Disidentifiable: EUHID supports multiple encryption schemes offering multiple EUHIDs to prevent revealing the identification of the individual.
Public: The EUHID's encryption scheme is intended to hide the identity of individual when linking information. However, public disclosure of a patient identifier without any risk to the privacy and confidentiality of patient information depends on appropriate access security and privacy legislation, similar to other identifiers.
Based on Industry Standards: The Sample UHID is not based on existing industry standards. It is based on ASTM's Standard Guide for Properties of a Universal Healthcare Identifier (UHID).
Deployable: The Sample UHID is capable of implementation in a variety of technologies such as scanners, bar code readers, etc.
Usable: The Sample UHID is capable of implementation in a variety of technologies such as scanners, bar code readers, etc. The 28 digit identifier will present difficulty for manual computation and transcription. It may be a time-consuming process and subject to human errors.
The ASTM guide and the proposed Sample UHID do not address the implementation issues and infrastructure requirements.
Unique: The trusted authority will be responsible for the uniqueness of the Sample UHID.
Repository-based: The Sample UHID can be stored in a repository.
Atomic: The Sample UHID consists of a sixteen (16) digit sequential identifier, a one (1) character delimiter, a six (6) digit check-digit and a six (6) digit encryption scheme. It can function as a single compound data element.
Concise: The Sample UHID is not concise. It is a 29-character length identifier.
Unambiguous: The Sample UHID is unambiguous. It uses numeric characters and a period as a delimiter.
Permanent: The Sample UHID has sufficient capacity to prevent reuse of identifiers.
Centrally governed: This policy issue is not addressed. The Sample UHID requires central administration and is dependent on the establishment and functions of a trusted authority.
Networked: The Sample UHID can be operated on a computer network. It requires establishment of the necessary network and technology infrastructure.
Longevity: The Sample UHID can support patient identification for a foreseeable future.
Retroactive: Has the capacity for retroactive assignment of the Sample UHID to every person in the United States
Universal: Can support patient identification for the entire world population
Incremental Implementation: The Sample UHID can be implemented on an incremental basis. With the development and use of appropriate procedures and establishment of the necessary bidirectional mapping, both the Sample UHID and existing patient identifiers can co-exist during the time of transition.
Cost-effectiveness: The Sample UHID has the potential to support the functions of a Unique Patient Identifier. The establishment of both the administrative and technology infrastructures, the creation of a Trusted Authority, the design and development of computer software, hardware and communication networks, and the implementation security measures will require substantial investment of resources, time and effort.
Currently operational: The Sample UHID is not currently operational. The ICN involved in the VHA's Florida pilot project is used as an internal control number for cross indexing records distributed among multiple providers and not as a patient identifier. It does not include encryption (EUHID) and Central Trusted Authority.
Existing infrastructure: Does not have existing administrative or technical infrastructure. The sample UHID relies on the Central Trusted Authority to administer its functions such as encryption, repository, check-digits, uniqueness, security, etc.
Readiness of the required technology: The basic technologies to support encryption and check-digit methodologies are ready and available.
Timeliness: The administrative and technology infrastructures (Central Trusted Authority, software, hardware, communication network, etc.), and the implementation methodology, policies and procedures, must be designed and developed before the Sample UHID's nation-wide implementation. This will require a substantial amount of time.
Adequacy of identification information to support identification functions: A repository is part of the conceptual characteristics, but the Sample UHID does not discuss its content or structure. The record location or provider information necessary to access a patient's medical record distributed among multiple providers is also not addressed.
The Sample UHID's focus is mainly on the Identifier Component. The 29-character ID format (16 digit sequential ID followed by a six digit check-digit and a six digit encryption scheme and a "." as delimiter) provides ample capacity. The length of the identifier will be difficult for patients to remember and users to process manually.
The Sample UHID requires the use of a patient's identifying data elements such as name, date of birth, sex, etc. But it does not address the content or structure of the data base that will contain such data elements.
The proposal indicates that Sample UHIDs will be stored in a data base and linked with patient's identification information. It does not address the content and use of an index such as a Master Patient Index that can provide this link. It requires a central governing body for administration, but does not indicate whether local, regional, or central MPIs will be used.
Provides a six (6) digit encryption scheme capable of generating multiple encrypted UHID for a single patient.
Does not have an existing technology infrastructure. The technology infrastructure is not addressed in the proposal.
Does not have an existing administrative infrastructure. The Sample UHID requires a Central Trusted Authority, but it does not include a proposal for the administrative infrastructure.
Compliance with the basic functions criteria depends on the identifier's compliance with operational characteristics and the identifier components requirements. The Sample UHID does not meet several of the operational characteristics. It addresses only two of the six Unique Patient Identifier components, namely the identifier component and encryption protection. It treats the remaining four components (Patient Identification Information, Index, Technology Infrastructure and Administrative Infrastructure) as implementation and policy issues, outside the scope of the proposal. However, the identifier and the encryption scheme are dependent on the establishment and implementation of these four components. In the absence of these components and the required operational characteristics, the Sample UHID's ability to fulfill the basic functions discussed below is unknown and uncertain. UHID's 29-character length is unsuitable for manual calculation/use. Therefore, at best, it can only partially meet the Unique Patient Identifier's basic functions.
Delivery of Care Functions: The Sample UHID's ability to support the positive identification of an individual required during the course of active treatment will depend on its ability to address both the implementation of the remaining identifier components and all of the operational requirements. The length of the identifier will not be conducive for patients to remember and for users to process manually.
Administrative Functions: The Sample UHID's ability to support the identification for administrative functions required by practitioners, provider organizations, insurers, HMOs, federal health plan agencies, etc. will depend on its ability to address both the implementation of the remaining identifier components and all of the operational requirements. The length of the identifier will not be conducive to manual use by patients, providers, payers, etc.
Coordination of Multi-disciplinary Care Processes: The Sample UHID's ability to support multi-disciplinary functions and coordination of care processes including, ordering of procedures, medications and tests, communication of results and consultations will depend on its ability to address both the implementation of the remaining identifier components and the operational requirements. The length of the identifier will not be conducive to manual use such as verbal communication, telephone enquiry and personal interactions.
Organization of Patient Information and Medical Record Keeping: The Sample UHID's ability to support manual medical record keeping and automated collection, storage and retrieval of information will depend on its ability to address both the implementation of the remaining identifier components and the operational requirements. The length of the identifier will not be conducive to manual use. Currently, most provider organizations are required to maintain manual medical records in addition to electronic information.
Manual and Automated Linkage of Lifelong Health Records: The Sample UHID's ability to identify, organize and link information and records across multiple episodes and sites of care will depend on its ability to address both the implementation of the remaining identifier components and all of the operational requirements. The length of the identifier will not be conducive to manual use.
Aggregation of Health Information for Analysis and Research: The Sample UHID's ability to support the aggregation of health information on the basis of groups of patients, regions, diseases, treatments, outcomes, etc. for research, planning and preventive measures will depend on its ability to address both the implementation of the remaining identifier components and the operational requirements.
Support the protection of privacy, confidentiality & security
Access Security: The Access Security and the authentication procedures needed to access the patient care information are not addressed.
Content-free Identifier: The Sample UHID is a content-free Identifier.
Mask/Hide/Encrypt/Protect/Disidentify: The Sample UHID proposal includes encryption to protect the Identifier. This capability will depend on its ability to address both the implementation of the remaining identifier components and all of the operational requirements.
The Sample UHID has the potential to support the functions of a Unique Patient Identifier. It is contingent upon the establishment of both the administrative and technology infrastructures, the creation of a Trusted Authority, the design and development of computer software, hardware and communication networks and the implementation of security measures. According to ASTM's own evaluation the cost of implementing UHID will be substantial. The nation-wide implementation of a new system will require a huge investment of resources, time and effort.
1. Immediate establishment of study/implementation teams to work on:
1. Establishment of administrative infrastructure including the Central Trusted Authority
2. Development of the policies, procedures and implementation methodologies not addressed in the proposal
3. Inclusion of missing identifier components such as patient's identification information, record locations, provider information and the necessary index
4. Development of the necessary technology infrastructure including the software application, communication systems, encryption methodology and control, access security, etc.
5. Enactment of the privacy and security legislation
6. Required investment of resource and effort
7. Timeliness of the solution.