So, what is PDL, and how does it achieve semantic understanding while regex and string search do not? Let’s take a look at an example to find out.

First of all, PDL does not just search for the literal form of the word in the query: instead, it automatically extends its search to all morphological forms of the word. For example, when searching for the word “company” in financial news articles, the PDL query will not only find “company”, but also “companies,” the plural form. This feature often comes in handy, especially when the search involves a verb. Suppose that you are interested in extracting what the CEOs said. With regex or other substring search, you will need to list all possible verb forms such as “say,” “saying,” “says,” and “said.” With PDL, simply entering “say” in the query will automatically fetch all possible verb forms. This behavior can also be turned off by enclosing the word in the form function, which will then restrict the search to the literal form of the word, such as in the example below.

Another notable feature of the PDL language is its capability for users to tailor the scope of their searches using a range of built-in functions. Returning to the previous example, you may not wish to confine your search exclusively to the specific verb “say,” but rather include other synonymous verbs like “tell” or “mention.” Achieving this is straightforward with PDL – users can invoke the synonym function with the verb “say,” as demonstrated in (a) below. As the subsequent results table (b) illustrates, the captured text now includes various speech verbs such as “tell,” “emphasize,” and “claim,” in addition to the word “say,” capturing them in all possible verb forms. For additional flexibility, the user can also create and modify synonym dictionaries.

The PDL language offers various modes of information extraction, including proximity search (e.g., finding words A and B within a sentence, or within a 3-words range), syntactic relation (e.g., finding word A that is the subject or object of B), semantic relation (e.g., finding words that are synonyms/antonyms to word A), access to dictionaries and ontologies, and more. This language is expressive enough to capture complex patterns, and yet relatively easy to use, having a syntax that closely resembles English. Having access to this versatile query language significantly enhances the power and quality of text mining operations.

In conclusion, PDL is a powerful and versatile query language that enables users to extract meaningful information from text with greater efficiency and accuracy than competing methods like regex or string search. Its ability to understand and capture morphological forms, synonyms, and other complex patterns makes it an indispensable tool for solving text mining tasks that require semantic understanding. By leveraging the capabilities of PDL, users can enhance their information extraction processes and gain valuable insights from their data, making it a true Swiss army knife of information extraction.

The post Query languages—the Swiss army knife of information extraction appeared first on Megaputer Intelligence.

Our personal data is a highly valuable commodity to a variety of businesses and agencies. This information is collected for a variety of reasons, and while some of the data can be fairly generic, other information—like surnames, birth dates, social security numbers, and account numbers—is more intimately linked with a person’s identity. In the wrong hands, this data can be exploited for nefarious purposes. As a result, there is a need to take measures to anonymize this personal data and minimize any consequences of a potential data breach or the risk of re-identification of individuals in published work. But what exactly do we mean by data anonymization?

What is Data Anonymization?

Data anonymization, also known as data redaction, is the process of removing or concealing the identifiable information of individuals (i.e., personal data), so that the data may be used more widely in different applications. Several organizations, such as the Institutional Review Board (IRB) and European Medicines Agency (EMA), require researchers and companies to anonymize their data before sharing or publishing their work, in order to protect the privacy of their data subjects and their personal data.

Article 3(1) in the Regulation (EU) 2018/1725 of the European Parliament defines personal data and data subjects as follows:

[P]ersonal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person[.]”

Of course, depending on the context of the data release, the anonymization requirements may change. For example, internal data sharing would have less strict anonymization requirements as opposed to a public release of a dataset.

According to the EMA, effective anonymization solutions may be evaluated on three criteria:

1. Possibility to single out an individual.
2. Possibility to link records relating to an individual.
3. Whether information can be inferred with regard to an individual.

If an anonymization solution fails in one of the three criteria, then the risks of re-identification must be evaluated.

What are the challenges?

There are several challenges associated with efficient data anonymization, the main one being the achievement of balance between anonymization and readability. Anonymized data is often used for training data models to predict certain characteristics, behaviors, or outcomes in a variety of fields. However, a dataset that has an important part of its data redacted may not be very useful for further analyses and may affect the performance of the models. Consequently, there is always a trade-off between privacy and model performance to consider.

With the rise of Big Data and the Semantic Web, another challenge has appeared: the risk of re-identification due to linked databases. The Semantic Web, or Web 3.0, allows linking diverse information about individuals across databases that may be used for Artificial Intelligence processes. However, this increases the difficulty of anonymizing personal data efficiently, since there are pieces of identifiable information in multiple locations. Even if we anonymize personal data in one database, we may be able to re-identify an individual based on the linked identifiable information in a different database.

Finally, there are challenges in identifying and extracting personal data properly, but also in making the anonymization reversible. Many companies use manual annotation systems that add tags to the information, or entities, that need to be anonymized. The available volume of data nowadays makes this process extremely time-consuming and labor-intensive. In addition, a good anonymization solution should also use secure encryption for saving the original information and allowing the reversal of anonymization: the de-anonymization of data. For these reasons, there is increased demand for automated systems that efficiently and accurately identify different types of personal data in unstructured text.

How is it done?

Anonymization may be approached from a utility or a privacy viewpoint. The utility approach focuses on preserving the utility of the data as much as possible and allows for some loss of privacy, whereas the privacy approach focuses on implementing methods that offer the highest privacy while sacrificing some of the data utility. Depending on the data release context, we may choose one or the other; however, an ideal anonymization solution should strike a balance between privacy and utility.

The two main steps in a data redaction task are the data preprocessing and the anonymization.

Data Preprocessing

During the data preprocessing step, we make sure that our data is formatted appropriately and as clean as possible. For example, spelling mistakes may decrease accuracy when identifying the personal information that needs to be anonymized. The identification of information, or entities, that need to be anonymized is also part of the data preprocessing step, and it is achieved either via manual tagging or an automated approach; of course, the latter is preferred. Once this information is identified and tagged, it is classified into direct identifiers and quasi-identifiers based on replicability, distinguishability, and knowability.

Anonymization

There are several considerations that we need to take into account when moving onto the anonymization step. First, we need to identify any possible attacks to our data and the entities behind them. Where will the data be released? Who will have access to it? Could it be used in a malicious way? If so, how? The answers to these questions help us evaluate and decide on the balance between low re-identification risk and data usability.

Next, we need to choose an anonymization methodology that is appropriate for our selected privacy-utility balance and data goals. The simplest anonymization technique is the complete and irreversible removal of any personal information using a data redaction software. While this offers a very low risk of re-identification, it scores very low in data utility since the de-identified data is not very readable.

Another method is pseudonymization, where personal information is replaced with terms that indicate the type of information (such as “Redacted Name” or “Redacted Address”). Even though this method makes the text more readable, it is difficult to track specific points of interest among multiple documents for research purposes. An alternative technique is the use of unique numeric or alphanumeric sequences that allow tracking among documents; when combined with a helpful term for the type of information redacted, they also offer high readability.

While pseudonymization makes the anonymized text more readable, it also increases the risk of re-identification via quasi-identifiers: if enough non-direct pieces of personal information are combined, one may be able to infer the identity of an individual. For this reason, the use of algorithms that use a generalization or a randomization approach have been introduced into data redaction tasks in order to decrease the possibility of re-identification even when using quasi-identifiers scattered in our data. The generalization approach replaces a value with a range (e.g., age value 53 replaced with range 45-55), and k-anonymity is a popular generalization method that ensures an individual cannot be identified since they are grouped with k-1 other participants in that range. Even though k-anonymity is a great choice for structured data, it does not work well with unstructured text and results in less accuracy when creating machine learning models because of information loss. In contrast, the randomization approach (noise addition and permutation, e.g. shifting dates randomly backward or forward) may cause issues with relationships between attributes, but is more suited for unstructured text. More specifically, the method based on the differential privacy concept has recently become very popular because of its low impact on model accuracy: it is used to anonymize the data by randomizing values or adding noise so that a query cannot verify whether or not an individual is part of a database. Despite its popularity, this method is fairly complex to implement.

Documentation Required

Finally, whatever methodology we decide to use, we need to make sure that we document it thoroughly. In certain cases, the anonymization methodology documentation may be a requirement by regulatory agencies, such as the EMA, but it is also considered a good data science practice in general.

Megaputer offers an automated solution for both the data preprocessing and anonymization parts of a data redaction task. If you are interested in learning more details about how you can anonymize your data using PolyAnalyst™, feel free to contact us for a free demo.

The post The Balance between Data Redaction and Data Utility appeared first on Megaputer Intelligence.

For example, if we wanted to collect a subset of medical records associated with cancer, we could search the database for the word ‘cancer’. This simple search would return plenty of records containing this literal string:

As shown above, there are some records that may not be good matches for what we intend for the cancer subset. The first thing that we need to ensure is that we avoid returning negations of a keyword. For this search, we would certainly not like to include records in which there are no signs of cancer. Searching for a keyword alone fails to recognize linguistic patterns around it, such as negation. By restricting our query to filter out false positives of cancer, we can significantly improve accuracy of our search. PolyAnalyst™ has built-in features that innately recognize complex signs of negation to automate such filtering.

Another consideration is the intention or context of the search. When we are looking for records that are related to cancer, are we looking for patients who have developed cancer? Do we want to ignore family history of cancer or cancer risks associated with a patient’s medications? The breadth of a search is largely dependent on the types of questions that we are looking to address with the search.

Of course, the search gets even more complex when we consider the many ways to express cancer as well as its symptoms. We may be missing true matches of cancer related records because we are not capturing certain pathology names, synonyms, symptoms, and other terms related to this condition. One could try to search for every technical term associated with a specific keyword, but that would be needlessly inefficient and would require a high level of domain knowledge. For the pharmaceutical and medical domains, a professional may even reference trusted knowledge bases such as MeSH and MeDRA to study terms semantically related to the medical keyword of interest. Instead of compiling this knowledge into every query, it makes sense to automate this process with a semantic ontology to not only get returns for ‘cancer’ but also synonyms and subtypes of cancer. Further, one could even expand this search by including cancer symptoms and medications used to treat cancers.

With these considerations, it becomes easier to search smarter and extract exactly what you need from your unstructured text. Utilizing the effectiveness of simple keyword searches combined with the analysis of linguistic patterns and semantic relations, the automated querying of unstructured data returns the sought relevant information in a tiny fraction of the processing time compared to manual searches.

The post Beyond keyword searching appeared first on Megaputer Intelligence.

Insurers initially fulfill claims regardless of fault

Consider an insurance company. Our solution deals with auto insurance and it is helpful to use auto insurance to learn the basic concepts of the problem. Note, however, that these applications can be easily generalized to any other types of insurance.

With auto insurance, it is just a fact of life that soon an accident will occur and the insurer will need to make coverage payments on the behalf of the insured. However, it is also a fact that very frequently that insured party was not liable for the damages incurred. For example, the other party involved in the accident may have ran a red light or may have been cited with a DUI. In these situations, the insured may choose to pursue legal action against the liable party; but this rarely happens. The insured already was covered by their insurance and it would cost substantially to fight the court battle necessary not to mention that they might not even succeed in the end. This leaves insurance companies rather displeased. Another party caused the accident and may be legally liable for the damages yet they ended up footing the bill!

The basic subrogation process

Fortunately a legal process called subrogation allows an insurer to pursue damages against the liable party in the stead of the insured party. Thus, a sequence of events can now occur:

1. An accident happens,
2. the insurance company pays for damages,
3. the insurance company reviews evidence and realizes that the other party was responsible,
4. then the insurance company decides to act on this through subrogation in order to recover their loss from the other party (or, rather, the other party’s provider).

The difficulty of subrogation

This is essentially the subrogation process. It is – on a macro level – simple. Complications arise when we zoom in to see how it works in practice.

For instance, how does an insurance company assess that the other party was liable? It may have access to police reports and witness statements but these need to be read by someone who can then take all of the facts into account to decide not only how liable the parties are under the law but how likely would they succeed if they actually took action on the claim and tried to recover the payments. This can be a time consuming process.

On top of that, information is not available at the same time. It may be awhile before access to certain records is made available so once this new data is obtained the analysis will have to be redone with this new information taken into account and this may occur several times as batches come in.

Finally, this repetitive and time consuming task needs to be performed on an overwhelming number of claims, which can drown an insurance company if they are not diligent in keeping ahead of the analysis. And so this is the heart of the problem behind subrogation opportunity identification as it is commonly done:

It is a manual, time consuming task that is subject to the biases of the humans performing it leading to inconsistency or simply missed opportunities.

Analyzing claims data to identify subrogation opportunities

Now that we understand the problem let’s discuss a solution!

We have developed a system, PolyAnalyst, to ingest unstructured text records from insurance companies, which are a compilation of available information such as the police reports and witness statements to a car accident.

Next, these records are cleansed. The later steps require more useful data, but real world data often is full of data entry errors, acronyms, and other complexities of natural language and data processing. For example, we can automatically correct common spelling errors found in the claim text.

Next, with the power of PolyAnalyst’s natural language processing tools, we automate the extraction of pieces of information important for making a subrogation decision on the claim. What traffic lights or signs did each party have? Was someone cited by the police and if so, what for? How did the collision occur? These and many other questions are asked and our automated information extraction system reads the text to find the answers.

Once key facts are mined from the text, we use machine learning to create models for assessing whether a given claim is a good subrogation opportunity or not. Using thousands of historical claims whose subrogation status has been decided by humans, we have trained multiple models using advanced machine learning techniques such as decision trees, support vector machines, and neural networks. The models trained on our historical data can be used for future assessments of new claims.

The benefits of computer-assisted subrogation

With a fully automated and central system, processing claims for subrogation opportunities can be done in a consistent manner in almost no time. The sooner an opportunity is identified the sooner the company can recover the funds it is entitled to. This solution can be utilized in a number of ways beyond simply replacing humans in this task. It can be used as a first pass system that quickly sorts claims based on how likely they are to be opportunities. For instance, claims discussing matters like a rock hitting the windshield would never be subrogation opportunities and they can be quickly read and sorted out by the machine so that a human does not waste time with them and can more appropriately spend they expertise on examining complicated claims. Or the system could be used as a quick check on the work of the humans. Claims that are rejected by human analysts can be subsequently fed to the system and rapidly and inexpensively checked once more to make sure no claims with good subrogation potential are missed. If the system thinks it found an opportunity, it can alert a human and make sure the insurance company performs the recovery on all claims that lend themselves to subrogation.

Ultimately this system highlights the power of joint application of advanced text analysis and predictive modeling. This particular application was built with subrogation in mind, but the process of reading text, extracting information, and then processing that information and making decisions with machine learning is an extremely universal concept that can be applied in any domain.

We hope that this short synopsis of our solution has been interesting or has sparked ideas on how text analysis and machine learning could be useful in your own work.

The post Identifying subrogation opportunities appeared first on Megaputer Intelligence.

The difficulties in accurately capturing entities in text

This task alone can be challenging, but in many scenarios it is further complicated by the fact that entities can be highly contextual and can be referenced in a myriad of forms. Referencing people easily demonstrates this phenomenon. For example, the individual whose name is Steve Michael Johnson may be referred to as Steve, Steve Johnson, Mr. Johnson, and in other ways. However, this is only the beginning of the complexity. All of these references are simply versions of the full name and so they are not too difficult to link together. However, depending on the context, an individual may be referenced in a manner using no fragment of their human name.

Challenges present in warranty claims data

Consider auto accident reports. In this data an individual may be referenced by a form of their name or they could be simply called “the insured party” or “the claimant”, or any of the shorthand variations thereof. In addition to this, some party may be referenced as their vehicle with a metonym such as “the red Toyota was speeding.” In auto accidents there are usually multiple drivers. In the text, there will be references to “Driver 1” or “the second driver”, which represent specific parties without mentioning them directly. Finally, people can also be referenced with pronouns in anaphora as in “He did not see the red light.”

Linking entities together

Identifying names of individuals is one thing, but we often need to link those entities with other entities we discover in the text to create a more holistic representation of knowledge the text contains. This task is called Entity Resolution. A major application of Entity Resolution is in the example examined above with auto accident reports. If an insurance company wished to analyze these reports for subrogation, litigation, or liability assessment, then it is essential to accurately identify two parties – the insured and the claimant – and extract the actions these parties took and the conditions they were in. As we saw, these parties can be referenced dynamically from record to record. We cannot simply build a list of names to search for ahead of time because human names can be shared and Mr. Smith may be an insured person in one record while a different Mr. Smith may be a claimant in another record. The same is true for other types of references such as vehicles and drivers. The red Toyota could be driven by anyone and Driver One is not always the insured party or the claimant party. Instead of relying on pre-assumed knowledge, we have to dynamically search for information within each record that can build a profile of the two parties including their names, what they drive, and what driver they are being referenced as.

Solving the problem with PolyAnalyst’s Extensible Pattern Definition Language

This technique is achieved by using PolyAnalyst’s Entity Extraction capabilities with XPDL and is broken into several steps. The first step is to look for these references independently. These means searching for all names and vehicles regardless of what we know about their relationships to the parties. After we have identified these entities we can, in the second step, create links between them and the respective parties they belong to. For example, the text may contain “The insured, Steve Johnson, was rear-ended” and other types of phrases that link entities together semantically. Here we now know that the insured party has the name Steve Johnson. After we search the text for semantic links between the entities, we can enact the third step called post-processing. Here we propagate the knowledge obtained in step two across entities. For example, whenever we see “Steve Johnson” or variations thereof in the text, we can mark it as the insured party. Furthermore, this allows us to create jumps in deduction. If we spot “The insured, Steve Johnson, was rear-ended” and “Steve was in a white F-150” we may not initially conclude that the insured owned a white Ford F-150 in step two but by propagating this information across the data we can deduce such new links.

Conclusion

This three step process of finding isolated entities, establishing logical links between them, and aggregating that information in post-processing, allows us to achieve Entity Resolution within the text in PolyAnalyst. This technique greatly expands how much information we can reliably extract from the text with XPDL. It can be applied to any scenario where complex entities such as people can be referenced in multiple manners.

The post Entity resolution in text analysis appeared first on Megaputer Intelligence.

The post Manual validation of entities in entity extraction appeared first on Megaputer Intelligence.