The University of California, San Francisco Family Health Outcomes Project (FHOP) recommends the use of standard data sets for the identification of patient information. FHOP is part of the Department of Family and Community Medicine and is affiliated with the Institute of Health Policy Studies in California. FHOP has opted for data standardization and unique client identification instead of establishing a unique client ID. FHOP's identifying data elements consist of two sets namely Core Data Elements and Confirmatory Data Elements. The Core Data Elements consist of the following five (5) data items:
1. Birth Name
2. Birth Date
3. Birth Place
4. Mother's First Name
5. Gender
The Confirmatory Data Elements consist of the following seven (7) data items:
1. Social Security Number
2. Other Client Number
3. Father's Name
4. Mother's Maiden Name
5. Current Name/Client Alias/Nickname
6. County of Client's Residence
7. Zip of Client's Residence
The FHOP approach uses object oriented software technology and a method known as blocking technique. The blocking technique is used to determine the relative weighting of each of the common data elements and their sequence. From the resulting data set in their weighted order an alphanumeric string value is derived. This value is used to detect and link duplicate records in pilot projects which yielded impressive results. FHOP points out that the alphanumeric value based on the common core data elements can be used as a Common Patient Identifier. The Common Patient Identifier value can be destroyed after linkage. It will then serve as a Virtual Identifier. An object-oriented software matching algorithm is used for a probabilistic matching. The FHOP proposal is aimed at facilitating database linkage among the various centers of care with data standardization. They do not replace the institution specific identifiers that are currently used at the various branches of the statewide health services for managing the patient encounter and record keeping.
Accessible: Does not apply; the method uses patients' demographic information instead of a Unique Patient Identifier.
Assignable: Does not apply; the method uses patients' demographic information instead of a Unique Patient Identifier.
Identifiable: FHOP uses a set of five Common Core Data Elements and seven Confirmatory Data Elements.
Verifiable: Not applicable; FHOP's Core Data Element-based Patient Identification is not a Unique Patient Identifier proposal.
Mergeable: FHOP's Core Data Element-based Patient Identification is not a Unique Patient Identifier proposal. It uses a set of five Common Core Data Elements and seven Confirmatory Data Elements. Pilot studies have shown its ability to identify duplicate records.
Splittable: Not applicable; FHOP's Core Data Element-based Patient Identification is not a Unique Patient Identifier proposal.
Linkable: Pilot studies have shown its ability to identify duplicate records.
Mappable: FHOP's Core Data Element-based Patient Identification can map patient's existing identifiers.
Content Free: FHOP's approach utilizes a set of patient's personal identification information.
Controllable: FHOP's proposal does not include encryption.
Healthcare Focused: The FHOP's Common Core Data Element and Confirmatory Data Elements are healthcare focused.
Secure: FHOP's proposal does not include encryption.
Disidentifiable: FHOP's proposal does not include encryption for disidentification.
Public: The patient information used by the FHOP approach cannot be disclosed in public.
Based on Industry Standards: FHOP's Core Data Element-based identification is not based on industry standard.
Deployable: FHOP's Core Data Element-based Patient Identification uses the object- oriented software technology.
Usable: The five Common Core Data Elements and seven Confirmatory Data Elements will be difficult to process manually on a routine basis. It requires the use of a computer program to process the identification.
The FHOP's approach uses object-oriented technology for identifying and matching patient information. It does not address the administrative infrastructure.
Unique: The Common Core Data Elements and Confirmatory Data Elements support the unique identification of individuals.
Repository-based: FHOP's Core Data Element-based Patient Identification is not a Unique Patient Identifier supported by a repository.
Atomic: FHOP's Core Data Element-based Patient Identifier is not atomic.
Concise: FHOP's Core Data Element-based Patient Identifier is not concise.
Unambiguous: Not applicable FHOP's Core Data Element-based Patient Identification is not a Unique Patient Identifier.
Permanent: Not applicable FHOP's Core Data Element-based Patient Identification is not a Unique Patient Identifier.
Centrally governed: FHOP's approach does not include a central governing body.
Networked: Applications based on object-oriented technology can be deployed over networks.
Longevity: Does not apply; not a Unique Patient Identifier.
Retroactive: Does not apply; not a Unique Patient Identifier proposal.
Universal: Does not apply; not a Unique Patient Identifier proposal.
Incremental Implementation: Can be implemented incrementally.
The FHOP Common Core Data Elements have the potential to link duplicate patient records. It does not replace the existing site (provider) specific patient identifier and does not address all of the basic functions of a Unique Patient Identifier.
Cost-effectiveness: This method uses object oriented computer technology to process the actual demographic information for identification. It does not replace the existing patient identifier. It is currently used for the management of clinical data bases. Cost effectiveness depends on this option's capability to fulfill all of the basic functions of a Unique Patient Identifier.
Currently operational: Not operational as a Unique Identifier. FHOP's Core Data Elements and Confirmatory Data Elements have been field tested in three pilot counties in California for data base applications.
Existing infrastructure: Infrastructure for nation-wide application is not addressed.
Readiness of the required technology: FHOP uses object oriented software algorithm for its local application. The basic technology necessary to develop the infrastructure is ready and available.
Timeliness: Use of patients' actual demographic information instead of an identifier across the nation and development of appropriate technology infrastructure are expected to require enormous amount of time, resource and effort.
Adequacy of information to support identification functions: FHOP's Core Data Element-based Patient Identification uses a set of five Common Core Data Elements and seven Confirmatory Data Elements. They do not include provider information or record locations relating to previous episodes of care.
Not a Unique Patient Identifier. FHOP's method uses the actual identification data elements of the patients instead of an identifier.
Not a Unique Patient Identifier. FHOP's method uses a set of five Common Core Data Elements and seven Confirmatory Data Elements. They do not include provider information or record locations relating to previous episodes of care.
FHOP's method uses the actual identification data elements of the patients instead of an identifier. It does not use an Index.
Does not use encryption
FHOP uses object oriented software developed locally. Nation-wide application is not addressed.
Nation-wide administrative infrastructure is not addressed.
FHOP's method is not a Unique Patient Identifier proposal. It makes use of the actual identification data elements of the patients instead of an identifier. It does not meet all of the operational characteristics and component requirements of the Unique Patient Identifier. Therefore, its ability to perform the basic functions of the Unique Patient Identifier is significantly limited.
Delivery of care functions: FHOP's method does not use a Unique Patient Identifier. It requires the use of actual data elements. Transcription errors, spelling mistakes and other discrepancies can interfere with the identification process. Manual verification and use may prove to be cumbersome, time consuming and error prone during the delivery of care.
Administrative functions: FHOP's method requires the use of actual data elements. Transcription errors, spelling mistakes and other content discrepancies may interfere with the identification process. Manual verification and use may prove to be cumbersome, time consuming and error prone for administrative processes both during and after the delivery of care.
Coordination of multi-disciplinary care processes: FHOP's method requires the use of actual data elements to facilitate the multi-disciplinary functions and coordination of care processes among multi-disciplinary team members. However, transcription errors, spelling mistakes and other content discrepancies may interfere with the identification process. Manual verification and use may prove to be cumbersome, time consuming and error prone for administrative processes both during and after the delivery of care.
Organization of patient information and medical record keeping: FHOP's method requires the use of actual data elements. Transcription errors, spelling mistakes and other content discrepancies may interfere with the identification process. Manual verification and use may prove to be cumbersome, time consuming and error prone for the maintenance of medical record and information management.
Manual and automated linkage of lifelong health records: FHOP's method requires the use of actual data elements. Transcription errors, spelling mistakes and other content discrepancies may interfere with the identification process while linking information from multiple sites of care and different providers. Manual verification and use may prove to be cumbersome, time consuming and error prone for administrative processes both during and after the delivery of care.
Aggregation of health information for analysis and research: FHOP's method requires the use of actual data elements. Transcription errors, spelling mistakes and other content discrepancies may interfere with the identification process while aggregating information from multiple sites of care and different providers.
Access Security: The Access Security and the authentication procedures needed to access the patient care information for the nation-wide application is not addressed.
Content-free Identifier: FHOP's method makes use of the actual identification data elements of the patients instead of an identifier.
Mask/Hide/Encrypt/Protect/Disidentify: Does not include encryption
Since the FHOP's method makes use of the actual identification data elements of the patients instead of an identifier, it may prove to be an expensive and time consuming option.
a) prior knowledge of record location and sufficient identification information
b) provider organization's participation in the FHOP's Core Data Element-based Patient Identification process and authorization for searching for the patient, patient identifier and patient information by another computer system
c) adequate security arrangements for searching and exchanging patient information
d) development and implementation of a powerful and reliable searching and matching algorithms.
The FHOP Core Data Element-based Identification is not a Unique Patient Identifier Proposal. It must include a Unique Patient Identifier solution in addition to its core and confirmatory data elements. The solutions to barriers includes: