Contributed by Brian Clark, VP Product Management

 

Scalable and distributed graph databases, like InfiniteGraph, are designed to manage the relationships and connections between data points, like patient records and treatment options.

The problem:

There are many common modeling patterns when storing applications data in a database. Much of the data fits neatly into rows and columns of a relational database (RDBMS); modeling relationships as joins between two tables.

In cases where there is a “many-to-many” relationship, such as a customer buys many products, a product is bought by many customers – a join table is used to show those relationships.  Information about patients, drugs, and specific patient reactions to medication fall into this type of many-to-many relationship scenario, as shown in the diagrams following.

Upon further analysis, there may be a need to define the many-to-many relationship as an object itself that has its own data, e.g. date, symptoms, etc. In graph terms, the relationship is known as an Edge. Navigating through the encounter is an easy operation. However, if the number of joins or the number of tables used in a query get very large this can become a problem for a relational database.

Patient allergic reactions to a drug’s ingredients.

In this use case a patient is prescribed drug medications. Each drug is made from a number of different ingredients. A patient may have allergic reactions to any of the ingredients in the drug. The doctor needs to know if prescribing the drug will cause an allergic reaction.

This is a variation of the many-to-many problems. In this case we need to calculate the intersection of the ingredients in the drug and the ingredients the patient has allergic reactions to. Performing traversals from the patient, through the drug allergy and ingredient, to the drug will render if the prescription is safe or not.

Objectivity, Inc. will be releasing a sample of this functionality using InfiniteGraph which generates 100,000 patients using random name data from the Census Bureau, and drug information downloaded from the FDA National Drug Code database. A number of patients are randomly chosen and for each patient we create 5 allergic reactions to 5 randomly chosen ingredients. Then we try to prescribe a drug medication to a patient, and the system tells us straight away if the drug contains an ingredient that the patient is allergic to.

This can be performed in code using iterators (similar to a SQL SELECT and a cursor) to perform the traversal. A more natural way using a graph database is to set up a navigator and then use qualifiers to control the navigation. In InfiniteGraph the navigator and qualifiers can be provided as plugins that can be re-used by the InfiniteGraph visualizer.

In the visualizer we can look up an index of MMI (patient ids) to find a specific patient and display the graph of all connections from the patient. As you can see below this is a lot of data. However, using the plugin capabilities of InfiniteGraph and the visualizer we can perform the specific query looking for allergic reactions to a prescribed drug for a specific patient .

 

 

After using the navigator plugin to filter the query we see that there is an allergic reaction to the prescribed drug.:

 

 

The World Health Organization estimates that 60% of adverse drug reactions are avoidable. The implications of having this type of application widely accessible could easily help to save lives from deadly allergic reactions that may remain unknown otherwise.

“Adverse Reactions to Drugs Cause Hospitalization of 1.5 Million Americans Each Year”  (http://www.worstpills.org/public/page.cfm?op_id=4)

With applications like this one from InfiniteGraph, medical practitioners everywhere would be able to reduce adverse reactions to prescription drugs, improving treatment outcomes.

 

SHARE THIS POST
Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedIn