This is the first in a series of articles on the dramatic transformation taking place in health informatics, in large part because of the new Health Level 7 (HL7) Fast Healthcare Interoperability Resources (FHIR) standard. HL7 is based in Ann Arbor, Michigan, and is a global nonprofit, volunteer health interoperability standards-creation body founded in 1987 to create a standard for data sharing among departmental systems in hospitals. After its significance is explained in this article, we will explore FHIR in detail in the next article in the series. The articles in this series are intended to introduce researchers from other fields to this one and assume no prior knowledge of health care or health informatics. They are abstracted from the author’s book Health Informatics on FHIR: How HL7’s New API Is Transforming Healthcare (Springer International Publishing: https://www.springer.com/us/book/9783319934136).
It is hard to conceive of a better rationale for healthcare interoperability than the management of chronic disease. People in advanced, industrialized countries are living longer, and chronic disease rates among the elderly are on the rise in part because of lifestyle issues, such as obesity and inadequate exercise. As a result, the care of chronic diseases (such as hypertension, heart disease, diabetes, chronic lung disease, and chronic kidney disease) accounts for well over 90% of spending by Medicare, the U.S. health insurance program for people age 65 and over. The Agency for Healthcare Research and Quality has found that the top 5% of patients with four or more chronic diseases are responsible for 30% of all Medicare chronic disease spending. While just 17% of Medicare patients live with more than six chronic conditions, they account for half of all spending on beneficiaries with chronic disease.
Given the highly specialized nature of the U.S. healthcare system, these multiple chronic disease patients receive care from many different physicians. The Growing Burden of Chronic Disease in America, an important 2004 study from the Johns Hopkins School of Public Health, found that patients with five or more chronic conditions see 14 physicians on average each year. Without an effective informatics infrastructure for sharing data among these physicians, such fragmented care can lead to errors and increased costs.
For example, diabetes predisposes patients to both heart and kidney disease, so a patient may well have all three diseases. Diabetes might be treated by an endocrinologist while heart disease is treated by a cardiologist and kidney disease by a nephrologist. If there is no effective means of sharing data, how do each of these physicians know what the others are doing? How do they avoid prescribing medications that interact? How do they avoid performing duplicate tests because they aren’t aware of prior tests or because they can’t access the results?
Arguably, creating the infrastructure to solve this kind of issue was a key goal of the federal government’s 2009 Health Information Technology for Economic and Clinical Health (HITECH) Act, which aimed to increase the adoption of electronic health records (EHRs) and create a secure infrastructure for data sharing (health information exchange).
A Learning Health System
Interoperability has other potentially broader impacts on health care, including research to gain new knowledge. In March 2001, Crossing the Quality Chasm: A New Health System for the 21st Century, published by the Institute of Medicine (IOM), now the Academy of Medicine, began by noting,
The U.S. healthcare delivery system does not provide consistent, high quality medical care to all people. Americans should be able to count on receiving care that meets their needs and is based on the best scientific knowledge—yet there is strong evidence that this frequently is not the case. Health care harms patients too frequently and routinely fails to deliver its potential benefits. Indeed, between the health care that we now have and the health care that we could have lies not just a gap, but a chasm.
A 2007 IOM publication, The Learning Health System, envisions health care as a place where “science, informatics, incentives, and culture are aligned for continuous improvement and innovation, with best practices seamlessly embedded in the delivery process and new knowledge captured as an integral by- product of the delivery experience.”
From an informatics perspective, a “learning health system” requires data as well as the ability to access the data. This, in turn, requires the widespread adoption of electronic medical record systems, the ability of those systems to represent the data they contain in a reasonably standardized way, and a universally sup- ported means of accessing those standardized data for patient care, research, and other important purposes, such as quality reporting. In short, a learning health system requires interoperability.
The Informatics Challenges
The HITECH Act succeeded in driving adoption of EHRs by creating financial incentives for their installation in medical facilities: today, virtually all U.S. hospitals have at least a basic system in place (fewer than 2% had one at the program’s inception in 2009), as do around 75% of physician offices (versus around 4% in 2008). Data sharing, however, has proven to be a far more difficult challenge. The adopted EHR systems are almost all proprietary products with their own unique data models and representations of clinical concepts. Their ability to share data is limited.
Health information exchanges (specialized networks for health data sharing) have had difficulty finding a sustainable business model. Despite years of effort by the U.S. government and by Health Level 7 (HL7), the international standards-setting body for the sharing of health data among software applications, until quite recently no technical solution to the representation or sharing of health data (i.e., interoperability) was widely embraced. Moreover, most healthcare providers have historically had no economic incentive for sharing their data with other providers, whom they might even view as competitors.
To make matters more complicated, many EHRs have usability issues. According to Computational Technology for Effective Health Care, a 2009 National Research Council report, the electronic medical record systems that have been adopted “appear designed largely to automate tasks or business processes. They are often designed in ways that simply mimic existing paper-based forms and provide little support for the cognitive tasks of clinicians or the workflow of the people who must actually use the system.”
As a result of these issues, EHR systems often frustrate physicians because using them takes too much time and data are often not displayed in a well-integrated manner that supports care decisions. The technical term for feeding back new medical knowledge to the physician, as envisioned in the learning health system, is clinical decision support (CDS). CDS tools often offer advice on making the correct diagnosis and providing the best treatments for it. Historically, CDS tools were not widely used because they have been stand-alone applications operating outside the EHR environment; thus, they usually require duplicate entry of data already recorded on paper or in the EHR and are not well integrated into the physician’s workflow and clinical processes.
Despite their limitations, the current generation of EHR systems is installed and in use after a national investment of some US$30 billion. Even if there were superior replacement systems available (and, arguably, there are none at present), the replacement cost, including the retraining of personnel, is prohibitive. Many feel a solution could be the creation of a new layer that would use the existing systems as a base but focuses on innovation.
Fast Healthcare Interoperability Resources
HL7’s first messaging standard (based on the Accredited Standards Committee X12 electronic data interchange standard) provided for communication among many specialized hospital systems. These systems were often the key revenue-producing departments at a medical facility, and the system was designed to optimize billing for services rendered. It was a huge success, still in wide use today. However, it was focused on fairly simple transactions and was not designed for the representation of the rich clinical data needed for patient care.
Later HL7 efforts to support the sharing of clinically richer data for patient care failed to achieve wide acceptance, in large part because of their complexity as well as the lack of a clear business case for using them. That business case is now stronger because healthcare providers in the United States and elsewhere are increasingly paid based on the quality and cost of the care they deliver and informatics is essential to achieve those goals.
In 2011, HL7 convened a “fresh look” task force to define a way forward to develop a workable interoperability solution. That same year, Australian standards guru Grahame Grieve proposed Resources for Health, a standard that would consist of a set of objects to represent granular clinical concepts—for example, a blood test for glucose or a patient’s current blood pressure—for use on their own or assembled into complex clinical documents.
The prior HL7 interoperability technology, Consolidated Clinical Document Architecture (C-CDA), was not granular and created large, complex XML-formatted electronic documents that essentially mimicked the structure and content of paper records. Using C-CDA, developers seeking a single data element, such as a lab test result, would have to parse a potentially quite long and complex document to find it. The means of accessing C-CDA documents was not standardized and often used healthcare-specific protocols.
By contrast, the objects in Resources for Health—now called Fast Healthcare Interoperability Resources (FHIR)—would be composable such that software developers could request only the information needed for their use case, and access to the data would be via a representational state transfer (REST) application programming interface. Some of the details of REST will be presented in a later article, but this is the most common way of accessing information on the Internet, and it is virtually certain that you use it many times each day without being aware that you are.
Grieve ended up leading the HL7 standards development effort that produced FHIR. Even though a formal “normative” version of FHIR has not yet appeared (but is anticipated late in 2018), the standard is achieving previously unthinkable adoption and appears virtually certain to be the foundation for interoperability and the next generation of health informatics systems and tools. We will consider FHIR and its potential for transformation in more detail in others in this series of articles.
To illustrate FHIR’s appeal now, we need only consider Apple’s recent announcements that patients can aggregate their medical records on their iPhone and developers can write apps to manipulate those data (and data the patients have recorded on their own) for purposes such as medication tracking, disease management, and nutrition planning, as well as contributing their data for medical research. FHIR and FHIR apps, the focus of the next two articles in the series, are at the heart of Apple’s new health capabilities. They are early examples of FHIR’s role in supporting the needed lifestyle changes and our ability to learn from the care of millions of patients discussed at the outset of this article.