Search our
entire site
Enter your search
terms below, or visit
our search page

Search case
studies only
Enter your search
terms below:

For the table
of contents and
hyperlinks to
general topics
proceed to toc

12. FHOP's Core Data Element-Based Patient Identification

I. Description of the Options

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.

II. Author/Proponent and Documentation

1. The University of California, San Francisco Family Health Outcomes Project (FHOP) is the proponent of this method. .
2. Data Element Specification document and Dr. Geraldine Olivia's description of the methodology are the documents available for this analysis.

III. Compliance with ASTM Conceptual Characteristics

a) Functional Characteristics

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.

b) Linkage of Lifelong Health Record

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.

c) Patient Confidentiality and Security

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.

d) Compatibility with Standards and Technology

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.

e) Design Characteristics

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.

f) Reduction of Cost and Enhanced Health Status

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.

IV. Compliance with Operational Characteristics and Readiness

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.

V. Compliance with Unique Patient Identifier Components Requirements

Identifier

Not a Unique Patient Identifier. FHOP's method uses the actual identification data elements of the patients instead of an identifier.

Identification Information

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.

Index

FHOP's method uses the actual identification data elements of the patients instead of an identifier. It does not use an Index.

Mechanism to protect, mask or encrypt the identifier

Does not use encryption

Technology Infrastructure

FHOP uses object oriented software developed locally. Nation-wide application is not addressed.

Administrative Infrastructure

Nation-wide administrative infrastructure is not addressed.

VI. Compliance with Basic Functions Criteria

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.

Identification of individuals

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.

Identification of information

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.

Protection of privacy, confidentiality & security

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

Improve health status and help reduce cost

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.

VII. Strengths and Weaknesses

Strengths:

1. Uses a common set of data elements from which an alphanumeric value can be derived to serve as a Patient Identifier or a Temporary/Virtual Identifier
2. Uses a set of data elements that patients are familiar with
3. Eliminates the effort, time and investment that will be required for developing and implementing a new identifier.

Weaknesses:

1. Not a Unique Patient Identifier and does not meet ASTM requirements (meets only 8 of the 30 requirements)
2. Does not meet three (3) of the five (5) Unique Patient Identifier's operational characteristics and only partially meets the remaining two (2)
3. Does not meet four (4) of the six Unique Patient Identifier Component requirements and only partially meets the remaining two (2)
4. Only partially fulfills the Unique Patient Identifier's basic functional requirements
5. Does not replace existing identifiers, but is used in addition to existing identifier
6. Use of Common Core Data Elements in combination with seven additional Confirmatory Data Elements for identification, verification, registration and patient care communication and other day-today activities may become complex, time consuming and burdensome
7. FHOP approach uses patient data and therefore, not content free.
8. The use of patient's personal information for identification instead of a content free identifier has inherent risk for violation of privacy.
9. Searching and accurately matching 5 to 12 data elements instead of a single identifier present complexity even with computer.
10. The alphanumeric value derived for use as a Common Patient Identifier or a temporary Virtual Identifier requires the use of weighting and probabilistic matching algorithms which are too complex for manual use.
11. The approach relies on patient's accurate supply of Data Elements every time.
12. Inconsistent spellings, mispronunciation and typographical errors may alter the value of both the Common Patient Identifier and Virtual Identifier values.
13. Pilot projects by FHOP were designed to identify, link and eliminate duplicate records from databases. The method's applicability to perform all of the basic functions of a Unique Patient Identifier has not been established.
14. Nation-wide use which includes accessing independent organizations and searching, matching and exchanging information has not been included in the proposal.
15. Nation-wide application requires:

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.

VIII. Potential Barriers & Challenges to Overcoming the Barriers

1. Ability to fulfill all of the basic functions of a Unique Patient Identifier functions
2. Development of necessary communication technology and computer software and tools to facilitate access and the exchange of information from multiple institutions
3. Both the Common Core Data Elements and Confirmatory Data Elements have patient's personal information with potential for violation of patient's privacy.
4. Adequate protection must be provided to assure accurate matching and secure transmission of patient information.
5. Cost-effectiveness
6. Timeliness.

IX. Solutions to the Barriers:

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:

1. Inclusion of the missing Unique Patient Identifier's operational characteristics
2. Inclusion of the missing Unique Patient Identifier's components
3. Inclusion of the missing Unique Patient Identifier's basic functions requirements
4. The ability to fully meet all of the basic functions of the Unique Patient Identifier
5. Development of the technology infrastructure including application software, computer and communication protocols for the nation-wide use
6. Development of administrative infrastructure to address the nation-wide use
7. Development of implementation methodologies, policies and procedures.

TABLE OF CONTENTS