Data Liquidity in Health Information Systems

Abstract

In 2001 the IOM report "Crossing the Quality Chasm" and the NCVHS report "Information for Health" were released and they provided the context for the development of information systems used to support health-supporting processes. Both had as their goals, implicit or explicit, to ensure the right data is provided to the right person at the right time, which is one definition of "Data Liquidity". This concept has had some traction in recent years as a shorthand way to express a system property for Health IT, but there is not a well-defined characterization of what properties of a system or of its components give it better or worse data liquidity. This paper looks at some recent work that help to identify those properties and perhaps can help to ground the concept with metrics that are assessable.

Background

The Institute of Medicine (IOM) report, “Crossing the Quality Chasm,”[1] called for nationwide changes in the ways that health care was delivered in order to reduce medical errors and improve the quality of health care. The committee proposed to focus on six qualities of care: Safe, Effective, Patient-centered, Timely, Efficient and Equitable. The IOM recognized that in order to achieve the goals, not only would the care processes need to be redesigned but there would also need to be a large investment in health information technology (Health IT) infrastructure. This investment was to be focused on supporting the care processes that take place in a clinica or a hospital within the context of the revolution in the use of the Internet to access health information by all stakeholders.

Later the same year the National Committee on Vital and Health Statistics (NCVHS) published what might be called a complementary report titled, “Information for Health: A Strategy for Building the National Health Information Infrastructure”. [2] The committee brought perspective that our country needed to create a knowledge-based system – using the National Health Information Infrastructure (NHII) as the conduit – in order to be able to provide information to all parties who might need to manage their own health. In this report committee broke down the major stakeholders in the healthcare system into three groups: consumers, healthcare providers and communities. The three groups then defined the content, needs and boundaries of three dimensions of the infrastructure: personal health, healthcare provider and population health. A key insight of this committee was that each of these groups use the same information, but for different purposes. And where there is a shared interest or process, there is a need to share information between these groups/dimensions. The NHII is in place to support those processes. As the report states, the purpose of this new infrastructure is “to push information and knowledge to the point where all these health decisions are made, so the right decisions can be made at the right time.”

Together, these two reports provided a roadmap going forward on how our nation could improve both clinical care and public health by investing in an information infrastructure specifically designed to support those improvements. And they each provided a somewhat distinct viewpoint: IOM firmly rooted in the care processes and seeing the value of Health IT to support them; NCVHS advocating a new infrastructure in order to connect the different systems and make information and knowledge available where and when needed.

“Data Liquidity” as a concept has been defined somewhat loosely in many different ways. One definition is that data is liquid “when health [data] flows faster and more freely” [3]. Another is that when one creates “more ways and more choices for patients to own their computable health data thus enabling patients to use their data to get help and advice”, this is known as Data Liquidity. [4]

At the more detailed end of the spectrum there is a very cogent and detailed description of data liquidity in the supply chain planning systems. According to this report, "By adding a mechanism to facilitate the flow of data throughout the enterprise”, vital data that is locked away in tightly controlled data systems, could be freed up for use and analysis by non-power users. [5] What this report goes on to identify as a major problem is that the interfaces used to interact with these systems are difficult to learn and use without substantial investment in training. Even though that is not a health system, that problem will no doubt sound familiar to most who use today’s clinical systems. There are also some recent papers from the medical field that address this concept and provide frameworks and detailed definitions that make it more likely to have operational meaning. [6, 7]

This paper will discuss how data liquidity can be used in a more formal way to describe the flow of data and information throughout a health information system.

Data Liquidity and Knowledge Management

What is “data liquidity”? It has been variously used to describe data that is no longer confined to databases or data silos in supply chain management systems [5], financial systems, and health systems. Another attribute of liquid data is that it flows to where it is needed and when it is needed. Although AHRP Director Carolyn Clancy was not referring explicitly to data liquidity, her description of the role of health IT as being able to “bring this information immediately to clinicians, patients, and others when and where they need it” beautifully describes the qualities of liquid data in the health system.[8]

There are two important concepts that need to be fleshed in order to understand the value of the concept of data liquidity as it relates to health systems in general and oncology care in particular. First is the relationship between data, information and knowledge, known in the knowledge management literature as the Knowledge Hierarchy (KH).[9] Data can be seen as the smallest and most granular unit of information, such as the weight or height of an individual. Information is then represented by data that are aggregated and organized in a configuration determined by contextual cues. This context can be other data about how or when the original data was collected. For instance, blood pressure and heart rate would be expected to be quite different if those data were obtained when an individual had been resting for ten minutes as opposed to being collected during a stress test. Operationally, this is best implemented if the data element of blood pressure is not stored as “resting for 10 minutes blood pressure” since another measure of blood pressure that is clinically relevant might be developed that is “resting for 10 minutes while standing blood pressure”. Instead this contextual metadata can be stored separately but linked to the data. In research use of metadata in this very granular fashion would be very useful to use to track consent in a research protocol. If a person consent for blood, tissue, genetic material and so on were to be stored in metadata linked directly to the data that was collected then if a query were run to find and return data for a specific research protocol, the metadata would travel with the data and would allow the data to either be included or filtered out.

Another kind of context could be provenance of the data if it had been derived from other values. A trivial example of this is BMI, which is calculated from the height and weight using a specific formula. So by these examples it is clear that even the smallest unit of data will still need to have some metadata attached to it so that it can be properly collected with other data given the right context. (Figure 1)

FIGURE 1.

Knowledge Hierarchy model as modified for this health system context. Data with contextual metadata provides the foundation for the process of creating information. Knowledge requires humans to act on the information.

Knowledge can be understood to be actionable information or information in action. In either case, knowledge requires a human mind to comprehend the information (data in context) as presented and to synthesize information that comes from other kinds of information. In the clinical context this could be patient history, family history and influences from work and the social milieu. The clinician combines these sources their professional experience and identifies one or more possible actions to suggest to the patient.

So, if data is to be liquid and flow to where it is “needed”, it would be clearer and more accurate to say that the data is collected on the basis of contextual information contained in the metadata in order to form a unit of information. The ability to break down the information into the “atomic” data while keeping the metadata linked means that the data is agile and available.

Data Liquidity and Health IT

Given the KH model for the relationship between data, information and knowledge, what then are the necessary characteristics of a health information system that will enable data liquidity as a property of that system? William Stead has been working with computers in medicine since 1972 [11] and has recently put together a reconceptualization of the EHR [12] uses the ideas of KH discussed above without explicitly stating so. In addition, two of his three proposals address issues connected with data liquidity. The first one is: “Define interoperable data as data that can be assembled and interpreted in the light of current knowledge, and re-interpreted as knowledge evolves. Re-interpretation requires access to an archive of "raw signal" (voice, image, text, biometrics, etc).”

This sounds quite like the discussion above about data and metadata in the KH model. The raw signal is the deconstruction of information into its component data elements with the metadata coming from the original information. This deconstruction is what gives the data the agility to be reinterpreted into new kinds of information. Stead’s next proposal explicity deals with data liquidity, as he has defined it: the separability of data from applications. It speaks to the fact that clinical systems are often built in a vertically integrated fashion – think of how Apple created the iPod to work with iTunes, and Microsoft created Zune to work with their Media Player, but neither the software nor the devices work well if at all outside their “homes”. These technology companies do this to ensure that their music and their devices keep making them money. In software systems in a medical center, this can be the same paradigm at work with different vendors having created systems with components that work with each other but not at all well with each other. This can even be the case when your own developers create a system if they are not doing so with this separation of data from application as part of their design strategy. (Table 1)

Table 1.

Example of Barriers to Data Liquidity in Health Information Systems - The last column gives examples of mitigating actions that could free up data in a potentially useful manner.

Barriers	Example	Mitigation
Siloed and isolated databases;	Patient data in EHR cannot be accessed or viewed by patient	Provide means to export data to PHR
Localized or proprietary representation of data in storage	A tissue storage system and a clinical system use different IDs to identify patients	Either migrate both to one system or provide a mapping between the two.
Data are stored as derived or concatenated values	Application concatenates two ID numbers, one for the physician and one for the service, to create a provider number.	Externalize data sources that are common across multiple applications and use a link between a provider table and a service table to uniquely identify the individual.
Mismatch between system conceptual model and user’s mental model of information	Patient attempting to read and understand a lab report.	Reconceptualize and reformat report with visual cues to indicate lab values that require attention or action.

There is a December 2010 report from the President’s Council of Advisors on Science and Technology (PCAST) [10] on rethinking the paths taken up to now in order to realize the full potential of the health information infrastructure, the roadmap for which was laid out by the IOM and NCVHS. There are some striking similarities between some of the proposals contained within this report and those put forth by Stead. Echoing Stead’s first proposal is one in the PCAST report that calls “break data down into the smallest individual pieces that make sense to exchange or aggregate”. Perhaps most importantly this report points out that the path of development we have been on collectively, using Service Oriented Architecture (SOA) as the model, is just not sustainable. As in other scientific disciplines health too is becoming data–driven and the information systems in place will need to change to support that paradigm.

Discussion

Data liquidity may have some utility in being able to assess in a qualitative manner how efficiently the health information system is handling its tasks. Although there is no one definition of the term in the literature as yet, the different definitions found in the literature all fit into a construct that would describe some aspect of system fitness. We also identified some barriers to data liquidity and listed possible mitigation to increase the liquidity in the system.

The PCAST report and Stead’s reconceptualization of the EHR both look at how far we have come in developing our health information system but indicate where we have stalled and lay out ways to move beyond.

Conclusion

Data liquidity is a term and a concept that has increased in use over the last few years to describe how data flows in an information system. This is probably the result of greater use of information systems for managing our health and other areas of life. In short, we may have seen the roadmap for the next decade in the PCAST report and in Stead’s reconceptualization of the EHR. We may even be seeing a healthy learning cycle in this country if we can evaluate this new advice and forge ahead.