Self-contained system for de-identifying unstructured data in healthcare records

CROSS-REFERENCE TO RELATED APPLICATION(S)

0001This application claims priority to, and the benefit of, co-pending U.S. Provisional Application No. 62/622,677, filed Jan. 26, 2018, for all subject matter common to both applications. The disclosure of said provisional application is hereby incorporated by reference in its entirety.

FIELD OF THE INVENTION

0002The present invention relates to identifying personally identifiable information (PII) and protected health information (PHI) within unstructured data, removing the PII and PHI from the unstructured data, and replacing the removed information with a case-type tag. In particular, the present invention relates to a system and method configured to provide an improvement in computer capabilities that enables a computer system to merge data sets without compromising data privacy and security that computers were not capable of performing before using existing data replication techniques, by de-identifying (removing PII and/or PHI) found within unstructured data fields, such as physician notes, laboratory results, and medical histories, from public and private sources, etc. and replacing the removed personal information with a case-type tag that enables the user to understand what information was removed and to tune the level of information removal in future de-identification runs.

BACKGROUND

0003There exists a vast store of information within the unstructured data fields of healthcare records that can be critical to properly understanding the effectiveness and safety of clinical treatment. However, due to their inherent lack of structure, de-identification of these data fields is a challenge due to the lack of an automated solution, leaving much of this information absent from analytical datasets. This challenge is one that was created by the implementation of databases and other data storage and analysis technologies combined with the unstructured nature of healthcare records combined with the need for meeting privacy regulations and requirements. Conventional healthcare data systems are limited in their ability to provide information from individual records in healthcare data sets because each record contains protected health information (“PHI”) or personal identification information (PII) (e.g., names, addresses, dates of birth, dates of death, social security numbers, etc.). It is a potential Health Insurance Portability and Accountability Act (HIPAA) violation to incorporate PHI elements into a healthcare data set. Accordingly, to be compliant with government regulations, all PHI data elements must be removed and/or de-identified before being incorporated into any healthcare data set. However, once PHI data elements are removed from record, users have no way to understand which individuals in the data set match particular structured or unstructured data relevant for analysis.

0004Generally, conventional (systems, devices, methods) are unable to identify, flag, and remove protected health information (PHI) or personal identification information (PII) (e.g. names, addresses, dates of birth, dates of death, social security numbers, etc.) from unstructured data in an automated fashion. Instead, the current practice is to remove PHI or PII manually based on human determinations, or to not incorporate any unstructured data fields into healthcare data sets being used for non-clinical purposes, because of the inability to efficiently and accurately identify, flag, and remove PHI or PII using existing technologies.

SUMMARY

0005There is a need for improvements for enabling healthcare data sets within healthcare records of individuals to be accessible and useable without exposing protected healthcare information of the individual. There is a need for improvements for a system whereby unstructured data can be de-identified in an automated manner, but still be able to be matched to individual records in healthcare data sets without exposure of PHI or PII. Additionally, the de-identification process needs to be “tune-able” to control redaction of sensitive information while allowing information that looks like PHI or PII, but is not, to remain in the data set. Moreover, it would be desirable to have the de-identified text to remain coherent after the personal identifying information has been removed.

0006The present invention is directed toward further solutions to address this need, in addition to having other desirable characteristics. Specifically, the present invention provides an advancement made in computer technology that consists of improvements defined by logical structures and processes directed to a specific implementation of a solution to a problem in software, data structures and data management, wherein the existing data structure technology relies upon unacceptable reproduction of protected health information, personal identification information, or other private information to transmit data for data processing purposes that cannot meet or be used under current requirements of the Health Insurance Portability and Accountability Act (HIPAA) (42 U.S.C. § 1301 et seq.), and other laws, regulations, rules and standards governing privacy and data security (e.g. General Data Protection Regulation (Regulation (EU) 2016/679), Federal Trade Commission Act (15 U.S.C. §§ 41-58), Children's Online Privacy Protection Act (COPPA) (15 U.S.C. §§ 6501-6506), Financial Services Modernization Act (Gramm-Leach-Bliley Act (GLB)) (15 U.S.C. §§ 6801-6827) and California Consumer Privacy Act of 2018), by providing a system and method in which unstructured data is processed from individual records in a healthcare data set without exposing PHI. The present invention provides a system and method that creates a specific, non-abstract improvement to computer functionality previously incapable of merging certain data sets without exposing PHI and PII, that de-identifies data by removing protected health information and personal identification information from the record, adds a unique encrypted person token to each record, and merges the record with other healthcare data sets that have likewise been de-identified and tokenized by matching the unique encrypted person tokens in data sets to one another, thus maintaining the ability to match disparate data (e.g., unstructured data and structured healthcare data) from disparate sources for a same individual. In particular, the present invention implements a self-contained, dictionary-based system containing tunable lists of PHI or PII entities and data formats (e.g., names, birth dates, phone numbers, addresses, etc.) to be utilized to de-identify unstructured data within healthcare and other data sets. The dictionaries include blacklisted terms (e.g., first names, last names, etc.) to be redacted from the unstructured data and also include blacklisted standard number formats (e.g., social security numbers, telephone numbers, etc.) to be removed from records, a project specific whitelist of terms not to be removed (terms to be allowed to remain in the data despite being included in the blacklist), and a record-specific blacklist created from the PHI or PII present in a specific record (e.g., individual patient records). Taken together, these three dictionaries create an adjusted blacklist that can be “tuned” to control the level of de-identification and scrub a set of records. The present invention uses the dictionaries to remove all elements determined to be PII or PHI, but also replaces the removed elements with a case-type tag identifying the type of information being removed (e.g., “first name”, “address”, etc.). The addition of the case-type tag ensures that the unstructured data are still coherent even after information has been removed/redacted.

0007Additionally, to connect the resulting de-identified data to other data sets, the invention works in a manner consistent with other de-identification systems and methods. In particular, the records are tokenized in a standardized format to include encrypted patient tokens with every record. This “tokenized” data can then be merged with structured healthcare data sets that have also been de-identified and tokenized by matching the tokens in each data set against each other. In this way, users can connect individuals across healthcare data sets without ever seeing or using PHI or PII.

0008In accordance with example embodiments of the present invention, a method for de-identifying unstructured data within data sets is provided. The method includes initializing a blacklist dictionary and a whitelist dictionary, modifying the blacklist dictionary by removing terms included within the whitelist dictionary to create an adjusted blacklist dictionary, and augmenting the adjusted blacklist dictionary with a record-specific blacklist for each individual record within the data sets. The method also includes scrubbing personally identifiable information (PII) and protected health information (PHI) from each individual record utilizing the record-specific adjusted blacklist dictionary. The scrubbing includes removing all elements within each individual record determined to be PII or PHI according to terms in the record-specific adjusted blacklist dictionary, replacing removed elements with a case-type tag identifying a type of information being removed according to the record-specific adjusted blacklist dictionary, and repeating the removing and replacing step for each individual record within the data sets.

0009In accordance with aspects of the present invention, the method can further include tokenizing and merging each individual record in the data sets. The blacklist dictionary can include standard terms and standard number formats to be removed from records within the data sets. The standard number formats can include social security numbers, telephone numbers, URLs, zip codes, email addresses, IP addresses, dates, patient IDs, record numbers, and insurance IDs. The standard formats can include cities, counties, first names, last names, prefixes, and medical terms. The whitelist dictionary can include terms allowed to remain in the data sets despite being included in the blacklist dictionary. The record-specific adjusted blacklist dictionary can include terms created from the PII or PHI present in specific individual records within the data sets.

0010In accordance with aspects of the present invention, the method can further include tuning terms in the whitelist dictionary and the record-specific adjusted blacklist dictionary to adjust a level of de-identification of records within the data sets. The whitelist dictionary and the record-specific adjusted blacklist dictionary can include a tunable list of names, birth dates, phone numbers, addresses and other forms of PII and PHI. Augmentation can include adjusting the adjusted blacklist dictionary to include known PII and PHI terms for an individual associated with an individual record, according to the record-specific adjusted blacklist dictionary, that should be removed.

BRIEF DESCRIPTION OF THE FIGURES

0011These and other characteristics of the present invention will be more fully understood by reference to the following detailed description in conjunction with the attached drawings, in which:

0012<figref idref="DRAWINGS">FIG. <b>1</b></figref> is a diagrammatic illustration of a system for implementation of the present invention;

0013<figref idref="DRAWINGS">FIG. <b>2</b></figref> is a flow chart illustrating how the standard blacklist is combined with the whitelist to generate an adjusted blacklist;

0014<figref idref="DRAWINGS">FIG. <b>3</b></figref> is a flow chart illustrating the relationship between structured patient data, the creation of a record-specific blacklist, and its addition to the adjusted blacklist for use on that record;

0015<figref idref="DRAWINGS">FIG. <b>4</b></figref> is a flow chart illustrating how the adjusted blacklist for the record is applied to the unstructured patient record data to generate the de-identified, tokenized record;

0016<figref idref="DRAWINGS">FIG. <b>5</b></figref> is an illustration and example of how de-identified patient records are redacted, with the addition of case-type tags;

0017<figref idref="DRAWINGS">FIG. <b>6</b></figref> is a flowchart illustrating the processes by which de-identified unstructured data can be merged with other de-identified datasets of structured data; and

0018<figref idref="DRAWINGS">FIG. <b>7</b></figref> is a diagrammatic illustration of a high-level architecture for implementing processes in accordance with aspects of the invention.

DETAILED DESCRIPTION

0019An illustrative embodiment of the present invention relates to a system and process for providing automated de-identification of unstructured data within health records. The present invention utilizes a dictionary-based and format-based engine to identify PHI and PII information for removal. The dictionaries can include tunable de-identification parameters through the use of a whitelist and standard and record-specific blacklist dictionaries to ensure that the correct information is being flagged as PHI or PII while not incorrectly flagging information needed for a particular analysis. The combination of the standard blacklist, customizable whitelist, and record-specific blacklists allow users to tune which terms they wish to obfuscate or pass through the de-identification process. Other de-identification methods for unstructured data do not include this element of tuneability.

0020The specific system and method improve the existing technology by reciting specific structures, functions and steps that accomplish the desired result through an inventive arrangement by combining unstructured data with other healthcare data in a manner that does not violate HIPAA or other privacy related regulations that restrict PHI or PII. In particular, unstructured data is accessed or aggregated from different data sources and is de-identified by removing or modifying all elements regarded as protected health information, and a unique encrypted person token is added to each record. The “tokenized” data is merged with other healthcare data sets that have been de-identified and tokenized in a similar process, that uses a combined order of specific incorporated rules and functions, not mere use of the computer and existing data processing technology, that improves the existing data management technological processes that renders unstructured data and health care information into a specific format that is then used and applied to create desired results of data sets that can be used together in an encrypted and privacy preserving manner. Specifically, the healthcare data sets are merged with the unstructured data by matching the unique encrypted person tokens associated with each data record with one another and the data records with matching unique encrypted person tokens are merged together. Using the system and method of the present invention provides a specific, non-abstract improvement to computer functionality that enables “individuals” (e.g., de-identified healthcare records) in a healthcare data set to be supplemented with unstructured data that is tunable without exposing protected health information or personal identification data. This in turn enables databases or data structures containing health care data sets, operated by separate, potentially unrelated entities, to query, receive, and incorporate (including by merging) data sets including unstructured data or related data in a separate database or data structure that ordinarily would not be capable of interacting due to the above discussed restrictions on combining such data and the existing technological requirements of reproducing data within data structures in order to preserve unique identifiers and data used to accurately correlate or match data based on association with an underlying entity.

0021The data sets, used or created by the present invention, contain the de-identified unique encrypted person tokens, an indicator of the individual previously identified in the data record, and tag data including case-type tag data. This transformed data functions differently than, and achieves benefits over, conventional database structures and data therein, providing increased flexibility, and the ability to combine otherwise un-combinable data sets. To improve accuracy without sacrificing privacy and data security, data sets provide encrypted person tokens that are unique to a particular individual. Once the data sets and healthcare data sets are merged, a user can perform analysis of anonymous healthcare data with the added benefit of the case-type tags indicating what type of data was removed or replaced for the de-identified individuals originally associated with the healthcare records. This functionality provides many added benefits not previously available to healthcare practitioners. For example, unstructured data is critical to properly understanding the effectiveness and safety of clinical treatment. Additionally, the present invention can be utilized to prevent identity theft, fraud, and similar negative occurrences by reducing transmission and retention of versions of data containing PII and PHI. The de-identification of healthcare data sets including unstructured data sets provided by the present invention enables additional data to be merge-able with the healthcare data sets in such a way that data sets from disparate sources but relating to a same individual can be matched up and associated with each other without the exposure of PHI. More specifically, the present invention utilizes the dictionaries to identify PHI or PII information, remove it, and add back a case-type tag (e.g. [name]) in place of the removed information. This combination of dictionaries provides a wide array of standard terms that are commonly associated with PHI or PII as well as a customizable whitelist of terms that may provide false positives for PHI or PII. The present invention allows modification of the standard list with the customized list to ensure the most accurate automated de-identification process. In particular, because the list of terms utilized by the automated system can be finely tuned to specific applications (e.g., healthcare records) and even specific records (e.g., a specific patient record), it can provide a process which will remove all PHI or PII while keeping terms that may look like PHI or PII when viewed without context (e.g., disease names like Parkinson's) but are not PHI or PII. This ensures that the right information is removed (PHI or PII) while not unnecessarily removing other non-protected information (e.g., false positives).

0022Additionally, by providing tags for removed information, the process of the present invention provides a record that is clear of PHI or PII while maintaining a level of coherency with the tags providing context to the removed text. More specifically, when removing PHI or PII, the present invention replaces these elements with a case-type tags (such as [First Name], [Address], etc.) so that the reader of the resulting de-identified data can determine the type of data that was removed. The inclusion of these case-type tags makes the de-identified data more legible, and allows the user to better tune the system (by seeing what information was removed).

0023<figref idref="DRAWINGS">FIGS. <b>1</b> through <b>7</b></figref>, wherein like parts are designated by like reference numerals throughout, illustrate an example embodiment or embodiments of improved operation for the de-identification of PHI and PII within unstructured data sets, according to the present invention. Unstructured data sets can include any collection of data that is not organized in a structured manner. For example, unstructured data sets can include collections of data such as a physician's notes, narrative text (e.g., dictated report, typed findings, etc.), or any data that are not stereotypical, conventionally arranged, and/or predictable. Although the present invention will be described with reference to the example embodiment or embodiments illustrated in the figures, it should be understood that many alternative forms can embody the present invention. One of skill in the art will additionally appreciate different ways to alter the parameters of the embodiment(s) disclosed in a manner still in keeping with the spirit and scope of the present invention.

0024<figref idref="DRAWINGS">FIG. <b>1</b></figref> depicts an illustrative system <b>100</b> for implementing the steps in accordance with the aspects of the present invention. In particular, <figref idref="DRAWINGS">FIG. <b>1</b></figref> depicts a system <b>100</b> including a de-identification engine <b>102</b> configured to provide the de-identification of unstructured data. The system <b>100</b> is also configured to tokenize the de-identified data and merge the tokenized data with de-identified data created from structured data sets. In accordance with an example embodiment, the de-identification engine <b>102</b> is a combination of hardware and software configured to carry out aspects of the present invention. In particular, the de-identification engine <b>102</b> is a computing system with specialized software and databases designed for providing a method for de-identifying and tokenizing unstructured healthcare records. For example, the de-identification engine <b>102</b> can be software installed on a computing device <b>104</b>, a web-based application provided by a computing device <b>104</b> which is accessible by computing devices (e.g., the user devices <b>122</b>), a cloud based application accessible by computing devices, or the like. The combination of hardware and software that make up the de-identification engine <b>102</b> are specifically configured to provide a technical solution to a particular problem utilizing an unconventional combination of steps/operations to carry out aspects of the present invention. In particular, the de-identification engine <b>102</b> is designed to execute a unique combination of steps to provide a novel approach to automatically removing PHI and PII from unstructured data sets/records.

0025In accordance with an example embodiment of the present invention, the de-identification engine <b>102</b> can include a computing device <b>104</b> having a processor <b>106</b>, a memory <b>108</b>, an input output interface <b>110</b>, input and output devices <b>112</b> and a storage system <b>114</b>. Additionally, the computing device <b>104</b> can include an operating system configured to carry out operations for the applications installed thereon. As would be appreciated by one skilled in the art, the computing device <b>104</b> can include a single computing device, a collection of computing devices in a network computing system, a cloud computing infrastructure, or a combination thereof. Similarly, as would be appreciated by one of skill in the art, the storage system <b>114</b> can include any combination of computing devices configured to store and organize a collection of data. For example, storage system <b>114</b> can be a local storage device on the computing device <b>104</b>, a remote database facility, or a cloud computing storage environment. The storage system <b>114</b> can also include a database management system utilizing a given database model configured to interact with a user for analyzing the database data.

0026Continuing with <figref idref="DRAWINGS">FIG. <b>1</b></figref>, the de-identification engine <b>102</b> can include a combination of core components to carry out the various functions of the present invention. In accordance with an example embodiment of the present invention, the de-identification engine <b>102</b> can include a PHI and PII register module <b>116</b>, a de-identification module <b>118</b>, and a merging module <b>120</b>. As would be appreciated by one skilled in the art, the PHI and PII register module <b>116</b>, the de-identification module <b>118</b>, and the merging module <b>120</b> can include any combination of hardware and software configured to carry out the various aspects of the present invention.

0027In accordance with an example embodiment of the present invention, the system <b>100</b> can include a plurality of user devices <b>122</b> configured to communicate with the de-identification engine <b>102</b> over a telecommunication network(s) <b>124</b>. The de-identification engine <b>102</b> can act as a centralized host, for the user devices <b>122</b>, providing the functionality of the modules <b>116</b>, <b>118</b>, <b>120</b>, sharing a secured network connection. As would be appreciated by one skilled in the art, the plurality of user devices <b>122</b> can include any combination of computing devices, as described with respect to the de-identification engine <b>102</b> computing device <b>104</b>. For example, the computing device <b>104</b> and the plurality of user devices <b>122</b> can include any combination of servers, personal computers, laptops, tablets, smartphones, etc. In accordance with an example embodiment of the present invention, the computing devices <b>104</b> and <b>122</b> are configured to establish a connection and communicate over telecommunication network(s) <b>124</b> to carry out aspects of the present invention. As would be appreciated by one skilled in the art, the telecommunication network(s) <b>124</b> can include any combination of known networks. For example, the telecommunication network(s) <b>124</b> may be combination of a mobile network, WAN, LAN, or other type of network. The telecommunication network(s) <b>124</b> can be used to exchange data between the computing devices <b>104</b>, <b>122</b>, exchange data with the storage system <b>114</b>, and/or to collect data from additional sources.

0028In accordance with an example embodiment of the present invention, the PHI and PII register module <b>116</b> manages a standard blacklist and whitelist stored and managed by the system <b>100</b> (e.g., on storage system <b>114</b>). Each of the blacklists and whitelist contain lists of entities acting as definitions for identifiable words, terms, phrases, numeric sequences, etc. The standard blacklist contains a predetermined list of commonly defined entities that should be removed in accordance with protected health information (PHI) and personal identification information (PII). For example, the blacklist can include defined entities for names for individuals (first and last), street addresses, dates, social security numbers, etc. As would be appreciated by one skilled in the art, the blacklist can include an aggregated set of restricted terms according to PHI and PII rules and restrictions in any combination of data sets and data configurations. For example, the entities in the blacklist can be represented by lists of each entity organized in categories (e.g. a list of all known names, a list of all known phone numbers or, alternatively, phone number formats, etc.). Although the standard blacklist contains a predetermined list of defined entities, it can be modified by adding or removing individual words, terms, phrases, numeric sequences, numeric formats, etc. within the categorized lists or by adding/or removing entire lists of entities. Moreover, each of the entities can include multiple formats. For example, a social security number can be represented as 123456789, 123-45-6789, etc.

0029In accordance with an example embodiment of the present invention, the whitelist is a user-defined list of defined entities that should permitted to be included within a data set in accordance with PHI or PII rules and regulations. For example, permitted entities could include, but are not limited to, a list of all disease names, numerical disease codes, etc. As would be appreciated by one skilled in the art, the whitelists can also utilize different dictionary sources including but not limited to medical and healthcare dictionaries and databases. The words, terms, phrases, numeric sequences, etc. included within the whitelist are entities that should be removed or modified within excluded words, terms, phrases, numeric sequences, etc. included within the predefined entities in the standard blacklist. In other words, the whitelist is an aggregation of entity lists that can be utilized by the PHI and PII register module <b>116</b> and are provided to modify the standard blacklist when the lists of entities included therein are too comprehensive such that they may remove elements in the data sets which are not actual PHI or PII. Thus, to mitigate over comprehensive issues, the customizable whitelist is used to define the specific terms and elements that are not to be removed from data sets, even if they are included in the standard blacklist.

0030Similar to the blacklist, the whitelist can include categorized lists of entities. Moreover, as would be appreciated by one skilled in the art, the entities in the lists for the blacklists and whitelists can include any combination of case-sensitivity, not case-sensitive, exact matches, partial matches, etc. Additionally, the entities in the blacklist and whitelist can be drawn and updated from fixed lists or from real-time data sources. Entities in these lists can be updated with information from a variety of data sources (e.g., government databases, public records, etc.) with new data (e.g., such as new birth announcements, zip codes, addresses, etc.) as it becomes available.

0031<figref idref="DRAWINGS">FIGS. <b>2</b>-<b>4</b> and <b>6</b></figref> show illustrative flow charts depicting implementation of the present invention. As would be appreciated by one skilled in the art, the individual steps in any of the flow charts can be performed through different techniques, and/or merged into single processes or split into smaller processes that can be run serially or in parallel. Likewise, the combination of steps represented by the flow charts themselves can be performed through different techniques, and/or merged into single processes or split into smaller processes that can be run serially or in parallel.

0032<figref idref="DRAWINGS">FIG. <b>2</b></figref> depicts an exemplary process <b>200</b> for configuring tunable entity lists for the de-identification of data sets. In particular, <figref idref="DRAWINGS">FIG. <b>2</b></figref> depicts how the PHI and PII register module <b>116</b> is utilized to modify a standard blacklist with a customized whitelist to generate an adjusted blacklist for use by the de-identification module <b>118</b>. Upon completion of the process <b>200</b>, the adjusted blacklist can be utilized by the de-identification module <b>118</b> to determine which unstructured elements are to be removed from a data set.

0033At step <b>202</b> of the process <b>200</b>, the PHI and PII register module <b>116</b> loads the list of entities from the blacklist. At step <b>204</b> the PHI and PII register module <b>116</b> loads the list of entities from the whitelist. As would be appreciated by one skilled in the art, the blacklist and whitelist can be loaded from any combination of local or remote storage devices. At step <b>206</b>, the PHI and PII register module <b>116</b> identifies the terms that are included within both the blacklist and the whitelist. For example, the PHI and PII register module <b>116</b> runs a comparison operation and caches all entities (e.g., terms, phrases, etc.) found in both lists. At step <b>208</b>, the terms identified in step <b>206</b> are removed from the entity lists included in the standard blacklist. By removing the terms identified in step <b>206</b> from the standard blacklist, these entities will be preserved within the data sets during the de-identification process.

0034As shown in <figref idref="DRAWINGS">FIG. <b>2</b></figref>, the result of step <b>208</b> (e.g., removing the whitelisted entities from the standard blacklist entities) is the generation of an adjusted blacklist. The adjusted blacklist can be tuned to remove more or less information during the subsequent de-identification process by modifying the elements that are contained in the whitelist (and in some instances the standard blacklist). In ideal conditions, the adjusted blacklist will be tuned to specific data set types such that it will include entities that are PHI or PII while removing terms that may be false positives in that type of data set. For example, in medical-related data sets, the term “Parkinson” can be identified as a name to be removed per the standard blacklist, however, the phrase “Parkinson's Disease” can be defined as an allowed term per the whitelist. In the process <b>200</b> depicted in <figref idref="DRAWINGS">FIG. <b>2</b></figref>, the combination of the standard blacklist and the whitelist would result in the term “Parkinson” not being present in the adjusted blacklist (e.g., designated for removal). Thus, the adjusted blacklist can be utilized to more accurately remove PHI and PII without removing data that may not be PHI and PII (e.g., Parkison's disease) but is critical information to maintain in the record. Accordingly, the process <b>200</b> of combining a standard blacklist with a user-defined whitelist enables a customizable, and more importantly, a tunable degree of de-identification. The combination of, and customizable nature of, the standard blacklist and the whitelist gives users a much higher level of control over the de-identification process than is currently available for unstructured data. Additionally, the use of these lists over a manual process de-identification process makes the system more automatic, more accurate, and more predictable in repeated results. The results of the process <b>200</b> can be analyzed to tune the effectiveness of the de-identification process. In particular, as results are provided, the results can be analyzed to determine if too much or too little PHI or PII has been removed and the blacklist and whitelist can be adjusted accordingly (e.g., “tuned”). Tuning incorporates risk tolerance profiles, and can be done by a user who is reviewing the results and assessing what level of risk they are desirous of accepting.

0035In accordance with an example embodiment of the present invention, the adjusted blacklist can be further adjusted on a per-record basis. <figref idref="DRAWINGS">FIG. <b>3</b></figref> depicts an exemplary process <b>300</b> for the augmentation of the adjusted blacklist with a record-specific blacklist. The process <b>300</b> for augmenting the adjusted blacklist is an additional independent process from the process <b>200</b> in <figref idref="DRAWINGS">FIG. <b>2</b></figref> because the process <b>300</b> is performed on a per record basis within a data set to more finely tune the data while the process <b>200</b> is performed at a data set level. In particular, regardless of the entities that are designated as “allowed” to remain in the adjusted blacklist, per the whitelist and process <b>200</b> in <figref idref="DRAWINGS">FIG. <b>2</b></figref>, the entities that are known to be PHI or PII for an individual associated with a specific record must be removed. In other words, the process <b>200</b> is the initial part of an overall process that includes running both the process <b>200</b> and process <b>300</b> in succession.

0036At step <b>302</b> of the process <b>300</b>, structured patient data records for specific individuals are loaded by the system <b>100</b>. As would be appreciated by one skilled in the art, the structured patient data record can be a record populated with data for a specific individual patient and can be populated through any combination of manual data entry and automatic processes. Because the PHI and PII information in structured data sets are easier to identify, the structured data sets for an individual can be leveraged to further tune the blacklist to be utilized in unstructured data sets. For example, birth dates can be differentiated from other dates in free text by understanding which field in the structured data set contains the birth date. Likewise, patient names can be differentiated from physician names in unstructured data by understanding which fields in the structured data contain those elements. Extraction of the values from these identified PII and PHI fields in the structured data creates a record-specific blacklist.

0037At step <b>304</b> the PHI and PII register module <b>116</b> scans for a structured patient data record for a specific individual. As would be appreciated by one skilled in the art, the specific unstructured data record must be tied to a specific structured data record for this process <b>300</b> to work. For example, the records can be linked through a record ID number, a patient ID number, an encrypted token, etc.

0038At step <b>306</b>, if there is a structured patient data record for the specific individual, the PHI and PII register module <b>116</b> extracts PHI and PII entity data from the structured patient data record and creates a record-specific blacklist for the individual with that entity information. For example, the record-specific blacklist will include words, terms phases, etc. such as the name, birth date, addresses, phone numbers, etc., of the individual.

0039At step <b>308</b> the PHI and PII register module <b>116</b> adds the entities from the record-specific blacklist and the adjusted blacklist from process <b>200</b> into a single record-specific adjusted blacklist for the record associated with the individual. The record-specific adjusted blacklist defines the complete set of entities to be removed from the unstructured data in that specific record. For example, continuing the previous example, the term “Parkinson” was not removed from unstructured data because, though it looks like a name and may be contained in the standard blacklist, it is an allowed disease term per the whitelist. In the event that the individual record being de-identified, however, contains the term “Parkinson” in its structured data as PHI or PII (perhaps as a name, e.g. “John Parkinson”), the term “Parkinson” will be added to a record-specific blacklist and thus will be removed from the unstructured data in that particular record regardless of its whitelist status (e.g., because it is identifiable information for that particular individual). Implementing the additional structured patient data for a record the system <b>100</b> of the present invention accounts for record-specific details that impact the de-identification process. In other words, supporting this type of record-specific customization generates more accurate and flexible automatic de-identification of unstructured data by taking into account record-specific variations.

0040At step <b>310</b>, upon completion of the de-identification process on that record (discussed in greater detail with respect to <figref idref="DRAWINGS">FIGS. <b>4</b>, <b>5</b>, and <b>6</b></figref> below), the adjusted blacklist for the specific record (generated at step <b>308</b>) is discarded. In particular, the record-specific entities added as a result of steps <b>306</b> and <b>308</b> are dropped, and the process <b>300</b> is repeated for the next record.

0041<figref idref="DRAWINGS">FIG. <b>4</b></figref> illustrates the process <b>400</b> by which the de-identification module <b>118</b> performs de-identification on the unstructured data records (e.g., patient records) utilizing the record-specific adjusted blacklist. Initially, at step <b>402</b> the de-identification module <b>118</b> receives the record-specific adjusted blacklist for the specific individual's record from the process <b>300</b> (e.g., the result of step <b>308</b>).

0042At step <b>404</b> the de-identification module <b>118</b> scans through the unstructured data fields within an individual record, identifies and flags entities that are included in the record-specific adjusted blacklist. For example, the system <b>100</b> can search through the text using identifying predefined fields of data and data formats.

0043At step <b>406</b> each flagged protected health information entity is removed from the unstructured data record and replaced with a case-specific tag (e.g. [name]). For example, if the record-specific adjusted blacklist includes a list of names and a matched entity in that list is found in the unstructured data record, then that identified name will be removed and placed with the list specific tag of [name]. The addition of these tags provides context to the end-user about the type of data that was removed for better tuning and for increased legibility of the remaining de-identified data.

0044<figref idref="DRAWINGS">FIG. <b>5</b></figref> is an illustrative example of how text from unstructured data is de-identified and removed and replaced with the case-specific tags. In particular, <figref idref="DRAWINGS">FIG. <b>5</b></figref> depicts example textual data (including PHI) for an unstructured record and how that textual data is transformed into a de-identified unstructured patient record <b>512</b> through the processes <b>200</b>, <b>300</b>, and <b>400</b> depicted in <figref idref="DRAWINGS">FIGS. <b>2</b>-<b>4</b></figref>. The initial text for the unstructured data record includes “John Smith, born Jul. 3, 1985 is diagnosed with diabetes”. This record is transformed by the de-identification process of the present invention to remove PHI of “John Smith” and “Jul. 3, 1985” and replace the removed text with case specific tags. The result of this transformation is the de-identified unstructured patient record <b>512</b> that includes “[First Name] [Last Name], born [DOB] is diagnosed with diabetes”. This process takes the input of the unstructured data and outputs the de-identified data automatically following the steps provided in the processes discussed in greater detail in <figref idref="DRAWINGS">FIGS. <b>2</b>-<b>4</b></figref>. As would be appreciated by one skilled in the art, the example provided in <figref idref="DRAWINGS">FIG. <b>5</b></figref> is for exemplary purposes only and not intended to limit the scope of the present invention to the terms/tags utilized therein. For example, the case-type tags can be made to give more context to the removed elements.

0045In accordance with an example embodiment of the present invention, the de-identified unstructured data records can be tokenized such that they can be matched with other de-identified data records. <figref idref="DRAWINGS">FIG. <b>6</b></figref> illustrates the process <b>600</b> of linking de-identified unstructured data (as shown in <figref idref="DRAWINGS">FIGS. <b>2</b>-<b>4</b></figref>) with other data sets that have been de-identified through a different de-identification process (e.g., a process that works with structured data sets). For example, the de-identification of structured data sets can be provided by the de-deification process discussed in U.S. patent application Ser. No. 15/045,605 filed on Feb. 17, 2016 and U.S. Patent Application No. 62/561,032 filed on Sep. 20, 2017, incorporated herein by reference. The tokenizing process for de-identifying and tokenizing structured data sets can be used alongside the present invention to create an encrypted token for the unstructured data records of the present invention, as depicted in <figref idref="DRAWINGS">FIG. <b>6</b></figref>. In particular, using encrypted patient tokens <b>602</b>, the de-identified unstructured data can be merged with other datasets, structured or unstructured, that have been similarly tokenized without any exposure to PHI or PII (e.g., in compliance with the Health Insurance Portability and Accountability Act (HIPAA) or other regulations). As depicted in <figref idref="DRAWINGS">FIG. <b>6</b></figref>, the de-identified data records created from unstructured data sources (as provided by the system <b>100</b> of the present invention) can be combined with de-identified data records created from structured data sources (as described in U.S. patent application Ser. Nos. 15/045,605 and 62/561,032). In accordance with an example embodiment of the present invention, the records can be combined by the merging module <b>120</b> in a similar method utilized in U.S. patent application Ser. Nos. 15/045,605 and 62/561,032. In short, the merging module <b>120</b> identifies the same token in both data sets and joins the records together to form merged data <b>612</b>.

0046<figref idref="DRAWINGS">FIG. <b>6</b></figref> also depicts an additional optional step in which the de-identified unstructured data processed by the present invention can undergo a subsequent step <b>606</b> of natural language processing to extract specific terms of interest and placing them in a structured data format. The case-type tags can assist in identifying elements of the unstructured data to be extracted. The resulting structured data can be then merged at step <b>612</b> with other structured data sets using the encrypted patient tokens.

0047Any suitable computing device can be used to implement the computing devices <b>102</b>, <b>122</b> and methods/functionality described herein and can be converted to a specific system for performing the operations and features described herein through modification of hardware, software, and firmware, in a manner significantly more than mere execution of software on a generic computing device, as would be appreciated by those of skill in the art. One illustrative example of such a computing device <b>700</b> is depicted in <figref idref="DRAWINGS">FIG. <b>7</b></figref>. The computing device <b>700</b> is merely an illustrative example of a suitable computing environment and in no way limits the scope of the present invention. A “computing device,” as represented by <figref idref="DRAWINGS">FIG. <b>7</b></figref>, can include a “workstation,” a “server,” a “laptop,” a “desktop,” a “hand-held device,” a “mobile device,” a “tablet computer,” or other computing devices, as would be understood by those of skill in the art. Given that the computing device <b>700</b> is depicted for illustrative purposes, embodiments of the present invention may utilize any number of computing devices <b>700</b> in any number of different ways to implement a single embodiment of the present invention. Accordingly, embodiments of the present invention are not limited to a single computing device <b>700</b>, as would be appreciated by one with skill in the art, nor are they limited to a single type of implementation or configuration of the example computing device <b>700</b>.

0048The computing device <b>700</b> can include a bus <b>710</b> that can be coupled to one or more of the following illustrative components, directly or indirectly: a memory <b>712</b>, one or more processors <b>714</b>, one or more presentation components <b>716</b>, input/output ports <b>718</b>, input/output components <b>720</b>, and a power supply <b>724</b>. One of skill in the art will appreciate that the bus <b>710</b> can include one or more busses, such as an address bus, a data bus, or any combination thereof. One of skill in the art additionally will appreciate that, depending on the intended applications and uses of a particular embodiment, multiple of these components can be implemented by a single device. Similarly, in some instances, a single component can be implemented by multiple devices. As such, <figref idref="DRAWINGS">FIG. <b>7</b></figref> is merely illustrative of an exemplary computing device that can be used to implement one or more embodiments of the present invention, and in no way limits the invention.

0049The computing device <b>700</b> can include or interact with a variety of computer-readable media. For example, computer-readable media can include Random Access Memory (RAM); Read Only Memory (ROM); Electronically Erasable Programmable Read Only Memory (EEPROM); flash memory or other memory technologies; CDROM, digital versatile disks (DVD) or other optical or holographic media; magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices that can be used to encode information and can be accessed by the computing device <b>700</b>.

0050The memory <b>712</b> can include computer-storage media in the form of volatile and/or nonvolatile memory. The memory <b>712</b> may be removable, non-removable, or any combination thereof. Exemplary hardware devices are devices such as hard drives, solid-state memory, optical-disc drives, and the like. The computing device <b>700</b> can include one or more processors that read data from components such as the memory <b>712</b>, the various I/O components <b>716</b>, etc. Presentation component(s) <b>716</b> present data indications to a user or other device. Exemplary presentation components include a display device, speaker, printing component, vibrating component, etc.

0051The I/O ports <b>718</b> can enable the computing device <b>700</b> to be logically coupled to other devices, such as I/O components <b>720</b>. Some of the I/O components <b>720</b> can be built into the computing device <b>700</b>. Examples of such I/O components <b>720</b> include a microphone, joystick, recording device, game pad, satellite dish, scanner, printer, wireless device, networking device, and the like.

0052As utilized herein, the terms “comprises” and “comprising” are intended to be construed as being inclusive, not exclusive. As utilized herein, the terms “exemplary”, “example”, and “illustrative”, are intended to mean “serving as an example, instance, or illustration” and should not be construed as indicating, or not indicating, a preferred or advantageous configuration relative to other configurations. As utilized herein, the terms “about”, “generally”, and “approximately” are intended to cover variations that may existing in the upper and lower limits of the ranges of subjective or objective values, such as variations in properties, parameters, sizes, and dimensions. In one non-limiting example, the terms “about”, “generally”, and “approximately” mean at, or plus 10 percent or less, or minus 10 percent or less. In one non-limiting example, the terms “about”, “generally”, and “approximately” mean sufficiently close to be deemed by one of skill in the art in the relevant field to be included. As utilized herein, the term “substantially” refers to the complete or nearly complete extend or degree of an action, characteristic, property, state, structure, item, or result, as would be appreciated by one of skill in the art. For example, an object that is “substantially” circular would mean that the object is either completely a circle to mathematically determinable limits, or nearly a circle as would be recognized or understood by one of skill in the art. The exact allowable degree of deviation from absolute completeness may in some instances depend on the specific context. However, in general, the nearness of completion will be so as to have the same overall result as if absolute and total completion were achieved or obtained. The use of “substantially” is equally applicable when utilized in a negative connotation to refer to the complete or near complete lack of an action, characteristic, property, state, structure, item, or result, as would be appreciated by one of skill in the art.

0053Numerous modifications and alternative embodiments of the present invention will be apparent to those skilled in the art in view of the foregoing description. Accordingly, this description is to be construed as illustrative only and is for the purpose of teaching those skilled in the art the best mode for carrying out the present invention. Details of the structure may vary substantially without departing from the spirit of the present invention, and exclusive use of all modifications that come within the scope of the appended claims is reserved. Within this specification embodiments have been described in a way which enables a clear and concise specification to be written, but it is intended and will be appreciated that embodiments may be variously combined or separated without parting from the invention. It is intended that the present invention be limited only to the extent required by the appended claims and the applicable rules of law.

0054It is also to be understood that the following claims are to cover all generic and specific features of the invention described herein, and all statements of the scope of the invention which, as a matter of language, might be said to fall therebetween.