Dr. Peter Szolovits from Massachusetts Institute of Technology recommends a Healthcare Identifier System based on cryptography method. It consists of the use of two keys that allow arbitrary messages to be encoded and decoded. These two keys contain mathematical functions that are inverses of each other. The patient holds a patient private-key and the provider organization holds an organizational (provider) public-key. The two keys together generate and maintain IDs that are both organization specific and unique to individual patients within that organization. The ID can be revealed to other institutions or practitioners only with the private-key of the patient.
The cryptography method supports both centralized and decentralized control. Under the decentralized system, the patient has the ultimate control over the degree to which the lifetime collection of medical information is made available to others. Every individual at birth is issued a private key and every institution receive a public key. The cryptography function computes institution specific Patient IDs using these two keys. Under the centralized system a central authority handles all private-keys via an ID Server. At the request of authorized institutions, the ID Server will generate Patient ID with the use of both the patient's private-key and the public-key. Under both centralized and decentralized systems, the use of smart card and the computer is required. A set of patient demographic identification is used to calculate the keys which are used in turn to generate Patient IDs. Based on the identification information, a digital certificate is issued to each individual which can be in the form of a smart card. The keys and IDs are hundreds (100s) of characters in length.
Due to the length and format of the ID, Dr. Peter Szolovits envisions his method to evolve over a period of time. In the initial stage, the ID will function as a component of the patient demographic information and coexist with the existing medical record number. The initial function of this digital ID will be exchanging information between organizations. It will facilitate the exchange of information without transmitting the medical record number itself, thereby protecting the identity of the individual. When the level of automation and the use of computers have become universal, the digital ID will assume the role of the primary identifier and function as the Unique Patient Identifier. To assure anonymity of care and protection of privacy, Dr. Szolovits does not recommend tracking the various points delivery of care.
Automation and use of computer technology are prerequisites for the implementation and use of the Cryptography-based Patient Identifier. It cannot be used in a manual environment. The cryptography based method is popular in the financial industry and it is used mainly to facilitate secure electronic transactions over computer networks. However, the Cryptography-based Patient Identifier is still only a concept. It needs to be developed further. Dr. Szolovits points out that the cryptography-based public-key and private-key method is a very powerful tool, and its creative application will yield different degrees of privacy, convenience and flexibility. Therefore, the method needs to transition from the conceptual stage to specification, design, development, testing and large scale deployment in order to meet the requirements of the healthcare industry.
Dr. Szolovits points out that in the initial stage, the Cryptography based Identifier will function as a component of the medical record number to facilitate exchange of information. Until the use of computer has become universal, it will not be used as a primary patient identifier. His concept of ID Server, issuing authority, centralized and decentralized use, etc. need to be developed further to fully understand the characteristics of the Cryptography-based Patient Identifier.
Accessible: Dr. Szolovits, recommends a trusted authority/institution such as a government or semi-public consortium to function as a ID Server for the issue of the Cryptography-based identifier.
Assignable: The ID will be assigned by the ID Server. Both the patient's private key and the provider organization's public key are required.
Identifiable: The trusted authority will have the necessary information to support the issue and maintenance of the Cryptography-based Patient Identifier. However, the necessary specifications, design and development are yet to be planned.
Verifiable: It should be possible for the trusted authority to verify the validity of the ID. However, no details have been included in the proposal.
Mergeable:This can be accomplished at the trusted authority level.
Splittable: This can be addressed with appropriate procedures at the trusted authority level.
Linkable: The Cryptography-based Patient Identifier can be used to link patient records from multiple sources.
Mappable: Bidirectional linkage is possible between the Cryptography-based Patient Identifier and the existing Identifiers. The proposal expects it to be part of the patients demographic information in the initial stage.
Content Free: The patient's private-key and an institution's public-key are based on their respective personal and demographic information.
Controllable: This method requires the trusted authority to maintain security of the private and public keys and encryption information.
Healthcare Focused: The Cryptography-based Patient Identifier proposal is healthcare focused.
Secure: This method requires the trusted authority to maintain security of the private and public keys and related information. However, the necessary policies, procedures, specifications, design and development are yet to be planned.
Disidentifiable: Encrypted identifier has the ability to hide the identity of the individual.
Public: Public disclosure of the Unique Patient Identifier without risk to privacy and confidentiality of patient information is not discussed. The private key and institution specific patient ID are not meant to be public information.
Based on Industry Standards: Not based on existing Unique Patient Identifier Standards.
Deployable: The financial industry is using the cryptography method for secure electronic transactions. The Cryptography-based Patient Identifier cannot be used in a manual environment.
Usable: The identifier is in an encrypted format containing hundreds of characters. It is not suitable for manual use.
Unique: IDs issued are institution specific. Patients will receive different IDs from different institutions. Cryptography-based Identifiers are not unique across the nation.
Repository-based: Patients' private keys will be calculated from the patient demographic identification information. Therefore, such information can be maintained in a repository. However, its design especially relating to the issuing method (Centralized vs. Distributed) will determine its feasibility.
Atomic: The identifier itself is in the encrypted format and can be treated as a single data item.
Concise: The identifier is in the encrypted format containing hundreds of characters. Therefore, it is not concise.
Unambiguous: The identifier is in the encrypted format containing hundreds of characters. Its content will not be meaningful for manual review.
Permanent: Patients will have multiple identifiers each issued by different organizations that delivered the care. Even, within the same institution, the use of different encryption scheme will yield different identifiers.
Centrally governed: The issue and maintenance of the ID can be governed both centrally as well as in a distributed manner. They will be subject to the specification, design, development, testing and deployment that are yet to be organized.
Networked: Digital IDs, encrypted messages and transactions are currently transmitted over computer networks.
Longevity: This method can support patient identification for a foreseeable future.
Retroactive: This method can be used for retroactive assignment of identifiers.
Universal: This method can support universal use.
Incremental Implementation: Dr. Szolovits recommends an incremental implementation. In the initial stage, this ID will function as a component of the patient demographic information and coexist with the existing medical record number. The initial function of this digital ID will be exchanging information between organizations. When the level of automation and the use of computers have become universal, the digital ID will assume the role of the primary identifier and function as the Unique Patient Identifier.
Cost-effectiveness: This is subject to specification, design, development, testing and deployment that are yet to be planned.
Currently operational: The Cryptography-based Patient Identifier is not currently operational.
Existing infrastructure: Does not have existing administrative or technical infrastructure.
Readiness of the required technology: The method requires the healthcare industry to increase its level of automation and use of computer in order to use the Cryptography-based Patient Identifier. According to its proponent, the initial role of this method is intended only for exchanging information between organizations.
Timeliness: The Cryptography-based Patient Identifier method is at a conceptual level and needs to be developed further. The level of automation in healthcare organizations also needs to be increased before this method can be implemented.
Adequacy of information to support identification functions: The Cryptography- based Patient Identifier is at a conceptual level. The identification data base and its contents have not yet been addressed.
The Cryptography-based Patient Identifier is not a Unique Patient Identifier. It focuses on the use of private-key and public-key to generate an institution specific patient identifier. The keys and identifiers are of hundreds of characters in length. They are suitable for secure electronic transmission of information but, unsuitable for manual use and cumbersome for record keeping functions.
The Patient identification data base and its contents have not yet been addressed.
The index that would link the identifier and the patient's identification information has not been addressed.
The identifier will be in encrypted format.
The technology infrastructure required to support the healthcare identification functions has not been addressed.
The proposal requires a trusted institution for centralized control and use of escrow agents and trusted intermediaries for decentralized control. But it does not provide any specific solution.
According to Dr. Szolovits, the main focus of this method is to make unauthorized access to large scale medical information difficult. Initially the Cryptography-based Patient Identifier will be part of the patient demographic information to facilitate secure exchange of patient care information and eventually evolve in to a patient identifier once the use of computers by healthcare has become universal. In addition, compliance with the basic functions criteria depends on the identifier's compliance with operational characteristics and the required identifier components. The cryptography method is at a preliminary stage. Currently the method does not meet all of the operational characteristics and component requirements. Therefore, its ability to perform all of the basic functions discussed below will depend upon the development of a complete proposal and inclusion of missing comnents and operational requirements.
Delivery of care functions: According to Dr. Szolovits, the identifier will not support these functions initially. The use of computers by healthcare organizations must become universal and their functions automated adequately.
Administrative functions: Patient identification required by practitioners, provider organizations and secondary users for administrative functions will not be supported until the use of computers by healthcare organizations becomes universal and their functions automated adequately.
Coordination of multi-disciplinary care processes: Multi-disciplinary functions and coordination of care processes including, ordering of procedures, medications, tests, etc., communication of results and consultations will not be supported. The use of computers by healthcare organizations must become universal and their functions automated adequately.
Organization of patient information and medical record keeping: Manual medical record keeping and automated collection, storage and retrieval of information during the course of active treatment will not be supported. The use of computers by healthcare organizations needs to become universal and their functions automated adequately.
Manual and automated linkage of lifelong health records: The focus of the cryptography method is to facilitate secure exchange of information. Therefore, it has the potential to link information and records across multiple episodes of care and multiple sites of care. However, it will depend upon the implementation of the remaining Unique Patient Identifier components and the capability to address all of the operational requirements.
Aggregation of health information for analysis and research: The aggregation of health information on the basis of groups of patients, regions, diseases, treatments, outcomes, etc. for research, planning and preventive measures will not be supported initially. The use of computers by healthcare organizations must become universal and their functions automated adequately.
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 patient's private-key and an institution's public-key are based on their respective personal and demographic information.
Mask/Hide/Encrypt/Protect/Disidentify: The identifier will be in an encrypted format.
The method does not support several of the basic functions initially. It has the potential to facilitate secure exchange of electronic medical information and link longitudinal records. It requires the use of computers by healthcare organizations become universal and their functions automated adequately.
1) Inclusion of the missing identifier components and operational characteristics
2) development of identifier specifications, design, etc.
3) establishment of a Central Trusted Authority
4) development of technology infrastructure including software, hardware and communication issues
5) development of implementation methodologies and policies and procedures
6) preparation of cost-benefit analysis and an implementation schedule
7) increasing the current level of automation in healthcare organizations.
This method has been proposed by Drs. Paul Carpenter and Chris Chute of Mayo Clinic. It is based on an individual's immutable personal properties. Both Dr. Carpenter and Dr. Chute believe that in addition to characteristics such as uniqueness, verifiability, reliability and administrative ease, the Unique Patient Identifier (UPI) should be based on immutable personal properties rather than those which may be changed by political or personal whim (i.e. last name, town, state, country etc.). Their model consists of three universal immutable values plus a check digit. The three values are 1) a seven-digit date of birth field, 2) a six-digit place of birth code, 3) a five-digit sequence code (to identify the individual born on the same date in the same geographic area) and 4) a single-check digit. The place of birth code identifies world grid coordinates using 360 degrees for longitude and 180 degrees for latitude. Each increment of a degree represent approximately 70 square miles. Local organizations can administer the Unique Patient Identifier and forward it to an international registry such as World Health Organization.
For emergency situations a temporary UPI with the prefix "T" is recommended. This model also recommends the adoption of a base 34-character representation of the UPI for personal memory and ease of use and entry into electronic medical record of the future. Although the proposal does not address the Central Issuing Authority, it indicates the need for a central registry at an organization such as WHO to compare and link records.
Just like other proposals, the Unique Patient Identifier based on Personal Immutable Properties is also at a conceptual stage. Therefore, the method needs to progress from the conceptual stage to specification, design, development, testing and large scale deployment in order to meet the requirements of the healthcare industry.
Accessible: Local organizations can handle the issue of Unique Patient Identifier.
Assignable: Requires local issuing authority to assign the Unique Patient Identifier and forward it to an international authority such as WHO. The required specifications, design, development, testing and deployment are yet to be organized, and the establishment of a local and international authority and their functions are yet to be planned.
Identifiable: Requires the local registry organization to collect demographic data.
Verifiable: Check-digit verification is included in the proposal.
Mergeable: Requires central registry to compare information supplied by the local registry and perform the necessary linkages
Splittable: Requires central registry to compare information supplied by the local registry and take the necessary steps
Linkable: The Personal Immutable Properties-based Unique Patient Identifier can be used to link patient records from multiple sources.
Mappable: Bidirectional linkage is possible between the Personal Immutable Properties-based Unique Patient Identifier and the existing identifiers.
Content Free: The Identifier is created from personal immutable properties and therefore, is not content-free.
Controllable: The Personal Immutable Properties-based Unique Patient Identifier can be encrypted. However, encryption is not included in the proposal.
Healthcare Focused: The proposal is made for healthcare purpose.
Secure: Encryption is not addressed in the proposal. The Personal Immutable Properties-based Unique Patient Identifier can be encrypted and security can be administered by the local issuing authority.
Disidentifiable: Encryption is not included in the proposal. The Personal Immutable Properties-based Unique Patient Identifier can be encrypted in multiple ways.
Public: Public disclosure of the Unique Patient Identifier without risk to privacy and confidentiality of patient information is not discussed in the proposal. The Personal Immutable Properties-based Unique Patient Identifier contains personal information about the individual. Therefore, it is not a public information.
Based on Industry Standards: Not based on industry standard.
Deployable: Does not indicate any barriers.
Usable: The model recommends the adoption of a base 34-character representation of the UPI for personal memory and ease of use and entry into electronic medical record of the future. The 19-character length and the mathematics involved will present difficulty for manual calculation and use.
Unique: The three immutable personal properties namely date birth, place of birth and the sequential identifier assure the uniqueness of the identifier.
Repository-based: The patient ID is made up of the patient's personal properties information. The use of other demographic identification information is not discussed in the proposal. However, there is no inherent barriers to maintaining a repository.
Atomic: This model consists of a series of three universal immutable values plus a check digit. It can be considered a single compound data element.
Concise: This model consists of a 19 character length identifier which will be difficult for manual use.
Unambiguous: The identifier uses numeric characters only and does not present ambiguity.
Permanent: The identifier is intended as a permanent identifier.
Centrally governed: The proposal recommends local organizations to issue identifiers and function as local registries and report to the central organization such as WHO.
Networked: This identifier can be operated on network.
Longevity: The method is capable of functioning for a foreseeable future.
Retroactive: Unique Patient Identifiers can be assigned to existing individuals retroactively. However, the sequence code for individuals born on the same date may not be in the intended sequence while retrospectively assigning their ID.
Universal: This method can support identification of every living person for a foreseeable future.
Incremental Implementation: The proposal does not address the implementation approach. This method can be implemented incrementally.
Cost-effectiveness: This is subject to specification, design, development, testing and deployment that are yet to be organized.
Currently operational: The Unique Patient Identifier based on Personal Immutable Properties is not currently operational.
Existing infrastructure: Administrative and technical infrastructures are not ready yet.
Readiness of the required technology: The necessary technology and check-digit methodologies are ready and available for use.
Timeliness: The proposal does not address the implementation approach. The set-up of administrative and technology infrastructures (Central Trusted Authority, software, hardware, communication network, etc.), and the development of implementation methodology, policies and procedures, etc. must be completed before the nation-wide implementation. The implementation of an entirely new system will require substantial amount of time.
Adequacy of information to support identification functions: The identification data base and its contents have not been addressed. The Unique Patient Identifier based on Personal Immutable Properties still remains only as a concept.
The focus of the Unique Patient Identifier based on Personal Immutable Properties is mainly on the Identifier Component. The model consists of 1) a seven-digit date of birth field, 2) a six-digit place of birth code, 3) a five-digit sequence code (to identify the individual born on the same date in the same geographic area) and 4) a single digit check-digit. For easy representation the method recommends the use of a 34 base number. The 19 character ID length and the mathematics involved will be difficult for manual calculation and use.
The method will require 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 both local and central registries will exist. It does not address its content or the use of an index such as a Master Patient Index.
Does not use encryption
Does not have an existing technology infrastructure and is not addressed in the proposal
Does not have an existing administrative infrastructure. The proposal indicates that both local and central registries will exist, 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 Unique Patient Identifier based on Personal Immutable Properties mainly addresses the identifier component and does not meet several of the operational characteristics. Its ability to meet the basic functions of the Unique Patient Identifier will depend on the inclusion of the remaining five components and the required operational characteristics. It will be unable to meet the basic functions discussed below without them.
Delivery of care functions: The Personal Immutable Properties based Unique Patient Identifier's capability to support the positive identification of an individual 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.
Administrative functions: The identifier's capability 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.
Coordination of multi-disciplinary care processes: The identifier's capability 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.
Organization of patient information and medical record keeping: The identifier's capability to support the manual medical record keeping and the 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.
Manual and automated linkage of lifelong health records: The identifier's capability to identify, organize and link information and records across multiple episodes of cares and multiple 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 identifier'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.
Access Security: The Access Security and the authentication procedures needed to access the patient care information are not addressed.
Content-free Identifier: The Unique Patient Identifier based on Personal Immutable Properties is based on personal immutable properties.
Mask/Hide/Encrypt/Protect/Disidentify: Does not include encryption protection
The method has the potential to support the functions of a Unique Patient Identifier. However, it will depend upon the implementation of the remaining Unique Patient Identifier components and the capability to address all of the operational requirements. The establishment of both the administrative and technology infrastructures, the design and development of computer software, hardware and communication networks, and the implementation of security measures, etc. will require substantial investment of resource, time and effort.
VIII. Potential Barriers & Challenges to Overcoming the Barriers