What healthcare can learn from Facebook and Amazon
Graph databases are rapidly growing in use in enterprises. They show their capabilities in social and ecommerce settings, but their ability to support networking has application in healthcare as well.
Users of Facebook, LinkedIn and other social media applications are often amazed by how omniscient the technology seems to be. How do a bunch of algorithms know, out of billions of users, who you might consider a friend, or which videos you should consider watching just because you liked “The Dark Knight”?
A big part of the answer is a core social media technology that holds great promise for transforming healthcare by making true interoperability at last possible.
It’s called the graph database. Designed specifically to interpret relationships between different sets of data, the graph database is the foundational technology that lets social media applications, as well as companies like Amazon, build sophisticated social networks around each account owner. For instance, it’s what enables us to look at our friends’ friends and navigate through their interests and connections.
With this kind of networking sophistication available, why can’t we do the same thing with healthcare data? Why is it so difficult to find out which providers have seen a particular patient across the continuum or which providers have prescribed which medications to that patient? Why can’t we quickly and easily search for a patient and then call up the entire, complex and connected network of providers and health events that surround her?
The answer to these questions is: If healthcare follows the lead of social networking companies and adopts innovations like the graph database, it can be done.
Most databases used in healthcare today are relational databases. Relational databases are composed of multiple tables of information—and they work very well for transactional systems, like electronic medical records (EMRs). Yet, in spite of their name, relational databases are not very good at defining complex relationships between multiple points of data.
Imagine sitting down with a piece of paper and a pen to draw the connections between a particular patient and her care team. Put the patient in the center, and then draw lines to connect her with her team of disparate providers—her primary care physician, the emergency department of the local hospital, her cardiologist, the rehab center, her local pharmacy. Then add specific clinical events for that patient (an ED visit, a hospital admission, a lab test, a radiology exam) and connect those events to the associated providers. Soon, you will have a complex web of people and events surrounding the patient.
Now, imagine handing that drawing to a database administrator and asking him to fit that complex web of relationships into a relational database. He can do it, but it will take a lot of time and expertise—and ultimately, it will prove unwieldy. That’s because relational databases force you to represent non-tabular data in a tabular format. Not only is such a database hard to build, it is also difficult to search and to update as the patient’s network of relationships expands. For sicker and older patients, that web of relationships and events can be mind-boggling.
The healthcare system needs to be connected, and the connections need to be more transparent and traceable. Now imagine the database administrator putting that drawing into a graph database. A graph database doesn’t force a restructuring of the relationships between the entities and events in the drawing. Rather, it accepts the web of relationships exactly as they are. In fact, the data stored in the database directly parallels the drawing because a graph database is structured as objects connected by relationships.
It goes without saying that our healthcare system is just as complex—if not more so—than an individual’s or group’s social network. The healthcare system needs to be connected, and the connections need to be more transparent and traceable. Healthcare has struggled to make this happen for many reasons, one of which is the fact that data is typically trapped in individual technology system silos, which are often relational databases.
The industry has made significant strides in breaking down these silos, but we still lack a system that can aggregate information across all silos and care settings to create one external longitudinal record that is complete and accurate. In fact, rather than achieving interoperability that seamlessly serves up information into clinicians’ workflow, we are mired in an environment of standard data exchange where data moves from one silo into another.
Although insufficient, this data exchange is still critical. It gets vast amounts of information flowing between systems. System A sends data to Systems B and C, and each system consumes the data according to its data model. What is missing is any sort of meta-cognition about the relationships existing in the data. What is needed is a solution that can plug into the existing flow of data—that can monitor the flow and make associations and relationships between data elements as they move from system to system.
Capturing and relating the data in this way is possible using graph database technology. In fact, associations, correlations and relationships can be captured in a graph database as a natural artifact of simply “listening in” on the flow of data.
For example, an HL7 message flowing from System A to System B reveals that John is being treated by Dr. Yu. Another message flowing from C to B contains the information that John is also being treated by Dr. Brown and Dr. Hernandez. In a third message, John has received treatment from Dr. Clark. Looking in any of these individual systems, we would not see all of these providers related to John, because these systems do not keep track of the totality of data relationships. But a graph database can and does make these associations, making it possible for a query of the database to show that John’s care team consists of all four of those doctors.
Graph database technology thus makes it possible to liberate data in practical and unprecedented ways. The following are just a few of the use cases where graph databases overcome the challenge of connecting healthcare.
Create a patient’s provider map. Many healthcare organizations have a real challenge finding out which doctors or team of doctors across the continuum are participating in the care of a particular patient. As alluded to above, graph database technology enables organizations to dynamically create and access a care team map.
As data about a particular patient flows into the system, new members of the patient’s care team can be added to the database and related appropriately to that patient. Any nurse or doctor who needs to know who is providing care to the patient can simply pull up the patient’s provider map. They can see not only the names of the providers and the specific care events that link them to the patient, but also their roles, where they practice, their schedules and how to get in touch with them.
This transparency improves patient care and also has important implications for value-based reimbursement and bundled payments. A graph database enables organizations to clearly see all of the providers associated with a clinical event and to make sure bills and payments are appropriately allocated and submitted.
Create a full, contextualized view of a patient’s care. For many years, organizations and technology vendors have worked to create complete longitudinal care records for patients. Unfortunately, most of these records remain incomplete or, at the very least, lack contextual information surrounding a patient’s care.
For example, a typical longitudinal health record might show that a patient had a lab test and display the result. It might even trend a series of results for a repeated lab test. A graph database—linked to a clinical document repository—can deliver that information plus the context surrounding that information. For example, it could show the provider responsible for that lab order, his practice schedule, his provider ID and how many times in the last year the patient has seen that provider.
As a result, it can raise awareness of other events that have taken place in the patient’s care, such as a medication prescribed as a result of that lab result, how long the patient has been on the medication and when she last filled her prescription. If the organization has the permissions to do so, it could then look at how many other patients that provider has treated with the same condition and how often he prescribes that medication.
Send alerts and notifications to the care team. Graph technology simplifies the process of notifying the right members of any care team about a patient’s meaningful events, especially transitions of care. Simply put, when an organization has a complete picture of the providers who comprise a patient’s care team, it is much easier to alert the right people about the patient’s clinical events and care needs.
Imagine that a hospital is discharging a patient to a cardiac rehab center. Because the hospital has access to the patient’s care team map, it can send out an alert about this discharge to all of the relevant providers: the primary care physician, cardiologist and others. It can send a discharge summary and other critical information. The rehab center in turn can use this same care map to ensure better care coordination as the patient leaves the center.
Of course, this approach won’t be effective without the confidence that the discrete data elements are related to the right patient, provider and event. That’s why an engine that accurately matches patients and providers must underlie the graph database. Patient-matching and provider registries must be done right to ensure a single best patient and provider record, connected together as part of a sophisticated web of events and networks.
With such foundational accuracy in place, organizations will be primed to aggregate data from multiple silos and organize it intelligently around the people, places and events that it relates to. Using social media networking technology in this way, fully connected healthcare can become a reality.
A big part of the answer is a core social media technology that holds great promise for transforming healthcare by making true interoperability at last possible.
It’s called the graph database. Designed specifically to interpret relationships between different sets of data, the graph database is the foundational technology that lets social media applications, as well as companies like Amazon, build sophisticated social networks around each account owner. For instance, it’s what enables us to look at our friends’ friends and navigate through their interests and connections.
With this kind of networking sophistication available, why can’t we do the same thing with healthcare data? Why is it so difficult to find out which providers have seen a particular patient across the continuum or which providers have prescribed which medications to that patient? Why can’t we quickly and easily search for a patient and then call up the entire, complex and connected network of providers and health events that surround her?
The answer to these questions is: If healthcare follows the lead of social networking companies and adopts innovations like the graph database, it can be done.Most databases used in healthcare today are relational databases. Relational databases are composed of multiple tables of information—and they work very well for transactional systems, like electronic medical records (EMRs). Yet, in spite of their name, relational databases are not very good at defining complex relationships between multiple points of data.
Imagine sitting down with a piece of paper and a pen to draw the connections between a particular patient and her care team. Put the patient in the center, and then draw lines to connect her with her team of disparate providers—her primary care physician, the emergency department of the local hospital, her cardiologist, the rehab center, her local pharmacy. Then add specific clinical events for that patient (an ED visit, a hospital admission, a lab test, a radiology exam) and connect those events to the associated providers. Soon, you will have a complex web of people and events surrounding the patient.
Now, imagine handing that drawing to a database administrator and asking him to fit that complex web of relationships into a relational database. He can do it, but it will take a lot of time and expertise—and ultimately, it will prove unwieldy. That’s because relational databases force you to represent non-tabular data in a tabular format. Not only is such a database hard to build, it is also difficult to search and to update as the patient’s network of relationships expands. For sicker and older patients, that web of relationships and events can be mind-boggling.
It goes without saying that our healthcare system is just as complex—if not more so—than an individual’s or group’s social network. The healthcare system needs to be connected, and the connections need to be more transparent and traceable. Healthcare has struggled to make this happen for many reasons, one of which is the fact that data is typically trapped in individual technology system silos, which are often relational databases.
The industry has made significant strides in breaking down these silos, but we still lack a system that can aggregate information across all silos and care settings to create one external longitudinal record that is complete and accurate. In fact, rather than achieving interoperability that seamlessly serves up information into clinicians’ workflow, we are mired in an environment of standard data exchange where data moves from one silo into another.
Although insufficient, this data exchange is still critical. It gets vast amounts of information flowing between systems. System A sends data to Systems B and C, and each system consumes the data according to its data model. What is missing is any sort of meta-cognition about the relationships existing in the data. What is needed is a solution that can plug into the existing flow of data—that can monitor the flow and make associations and relationships between data elements as they move from system to system.
Capturing and relating the data in this way is possible using graph database technology. In fact, associations, correlations and relationships can be captured in a graph database as a natural artifact of simply “listening in” on the flow of data.
For example, an HL7 message flowing from System A to System B reveals that John is being treated by Dr. Yu. Another message flowing from C to B contains the information that John is also being treated by Dr. Brown and Dr. Hernandez. In a third message, John has received treatment from Dr. Clark. Looking in any of these individual systems, we would not see all of these providers related to John, because these systems do not keep track of the totality of data relationships. But a graph database can and does make these associations, making it possible for a query of the database to show that John’s care team consists of all four of those doctors.
Graph database technology thus makes it possible to liberate data in practical and unprecedented ways. The following are just a few of the use cases where graph databases overcome the challenge of connecting healthcare.
Create a patient’s provider map. Many healthcare organizations have a real challenge finding out which doctors or team of doctors across the continuum are participating in the care of a particular patient. As alluded to above, graph database technology enables organizations to dynamically create and access a care team map.
As data about a particular patient flows into the system, new members of the patient’s care team can be added to the database and related appropriately to that patient. Any nurse or doctor who needs to know who is providing care to the patient can simply pull up the patient’s provider map. They can see not only the names of the providers and the specific care events that link them to the patient, but also their roles, where they practice, their schedules and how to get in touch with them.
This transparency improves patient care and also has important implications for value-based reimbursement and bundled payments. A graph database enables organizations to clearly see all of the providers associated with a clinical event and to make sure bills and payments are appropriately allocated and submitted.
Create a full, contextualized view of a patient’s care. For many years, organizations and technology vendors have worked to create complete longitudinal care records for patients. Unfortunately, most of these records remain incomplete or, at the very least, lack contextual information surrounding a patient’s care.
For example, a typical longitudinal health record might show that a patient had a lab test and display the result. It might even trend a series of results for a repeated lab test. A graph database—linked to a clinical document repository—can deliver that information plus the context surrounding that information. For example, it could show the provider responsible for that lab order, his practice schedule, his provider ID and how many times in the last year the patient has seen that provider.
As a result, it can raise awareness of other events that have taken place in the patient’s care, such as a medication prescribed as a result of that lab result, how long the patient has been on the medication and when she last filled her prescription. If the organization has the permissions to do so, it could then look at how many other patients that provider has treated with the same condition and how often he prescribes that medication.
Send alerts and notifications to the care team. Graph technology simplifies the process of notifying the right members of any care team about a patient’s meaningful events, especially transitions of care. Simply put, when an organization has a complete picture of the providers who comprise a patient’s care team, it is much easier to alert the right people about the patient’s clinical events and care needs.
Imagine that a hospital is discharging a patient to a cardiac rehab center. Because the hospital has access to the patient’s care team map, it can send out an alert about this discharge to all of the relevant providers: the primary care physician, cardiologist and others. It can send a discharge summary and other critical information. The rehab center in turn can use this same care map to ensure better care coordination as the patient leaves the center.
Of course, this approach won’t be effective without the confidence that the discrete data elements are related to the right patient, provider and event. That’s why an engine that accurately matches patients and providers must underlie the graph database. Patient-matching and provider registries must be done right to ensure a single best patient and provider record, connected together as part of a sophisticated web of events and networks.
With such foundational accuracy in place, organizations will be primed to aggregate data from multiple silos and organize it intelligently around the people, places and events that it relates to. Using social media networking technology in this way, fully connected healthcare can become a reality.
More for you
Loading data for hdm_tax_topic #better-outcomes...