Since according to Dr. David Blumenthal, the National Coordinator for Health IT, the President strongly supports the approach of the PCAST report, there will certainly be ramifications for future stage meaningful use requirements regarding health information exchange. "We are going to move forward with a great deal of aggressiveness on health information exchange and interoperability, and even faster than we had expected based on the council’s report," he said."Ultimately, when we are setting standards for the second stage of meaningful use, we’re going to be relying on this committee."
ONC will create a new advisory panel to evaluate strategies for implementing recommendations from the PCAST report. The panel will include members of the Health IT Policy and Standards committees, as well as other privacy and security experts. The panel will make recommendations to the Policy and Standards committees in April. Then the Standards Committee will evaluate the proposals for a universal health data exchange language. Blumenthal said the Standards Committee will be tasked with selecting a proposal that is "technically as refined and as open to innovation, but as reliable, as we can make it."
Keith Boone, the Standards Geek for GE Healthcare, gives an excellent critique of the PCAST report. He makes the point that "we need to figure out how to take the work that has already been done and use it to guide it towards the behaviors we want to see: use of the healthcare language. That evolution will enable the revolution that PCAST is looking for."
Much of the groundwork for this language has been laid by Health Level Seven (HL7)Joseph Conn, from Modern Healthcare magazine, spoke with Gary Dickinson, co-chairman of the electronic health-record work group of HL7. "We’ve spent a lot of time in this very area, and this seems to be moving in the direction we’ve been espousing for a long time," Dickinson said. "To put it into everyday, ordinary language, 'meta data' is a way of describing actual data, the things we use in healthcare, and tagging is a way to have a generalized exchange mechanism, such as a generalized container, where the container is used universally and the content will change," he said. "The container would allow you to capture that summary record inside, and in that container you'd have a diagnostic code, some patient identification information, the symptoms reported by the patient and the particular things that were observed during that encounter, such as vital signs, and orders to the lab and a follow up with a specialist."
The best explanation of the PCAST report I've seen comes from Dr. John Halamka, who both worked on the report and sits on the HIT Standards Committee. Dr. Halamka believes that the PCAST report is consistent with the work done to date and that the foundation created by Meaningful Use Stage 1 puts us on the right trajectory to embrace the spirit of PCAST. I agree that the report builds on the work of the ONC, and while it does give some impetus for new emphasis on health information exchange, it does not radically alter the current trajectory.
Introduction
The current health IT landscape is dominated by enterprise systems based on proprietary formats. These systems lack ability to communicate and aggregate health information in the ways needed to serve patients, doctors, and researchers. The systems have been designed primarily to enable point-to point communication of administrative information rather than clinical data. Importantly, the nature of current systems makes it difficult for innovators to develop new tools to improve the use of health information. There are few policies or governance models to drive innovations, such as research, advanced clinical decision support, or benchmarking. In short, there is no fuel for an ecosystem of economically selfsustaining healthcare innovation.
The overarching goal is to have a national health IT ecosystem in which every consumer, doctor, researcher, and institution has appropriate access to the information they need, and in which these groups are served by a vibrant market of innovators. At the end of the previous chapter, we listed a set of technical and market-related requirements for enabling this overarching goal. Here, we look at several possible technological approaches and describe in some detail an approach that, we think, has the greatest likelihood of rapid forward progress.
Earlier Models for Enabling Data Exchange
Over the last 20 years or so, an era dominated by vertically integrated, proprietary EHRs, one approach has been to seek to create standardized health records. Because the medical system has long relied on filling in paper records, it was natural to assume that exchange or reuse of data would be impossible without establishing standardized record formats that would be comparable across providers. However, we believe that any attempt to create a national health IT ecosystem based on standardized record formats is doomed to failure. First, there is too much diversity and incompatibility for any kind of a priori standard to emerge. With so many vested interests behind each historical system of recording health data, achieving a natural consolidation around one record format for any particular subset of data would be difficult, if not impossible. Second, systems based on fixed records are inherently limited in their functionality. Consider, for example, a health record in which all types of blood test information are always stored. When a new type of blood test is developed, it is difficult to expand the record to include it. Moreover, it is difficult to exchange only parts of such an electronic record according to a patient’s choice (for example, blood glucose measures but not HIV status).
A second approach to health IT, spurred by the emergence of the Internet, has focused on serviceoriented architecture (SOA) as a way to solve the problems inherent in standardized record formats. SOA essentially involves using software policies, practices, and frameworks to enable one user to access sets of “services” on another party’s computers and data.43 For example, two hospitals, using two different systems, might create bilateral arrangements that enable them to run “services” on each other’s systems to execute transactions or access data. The approach could be expanded to small networks, and even to networks of networks.
As an analogy, one might consider two libraries with completely different systems for filing books. Each library’s users have no idea how to find books in the other library. But if each library sets up a “service desk” with an actual librarian, then the other library’s users can get what they need by lining up at the service desk for assistance. This analogy also makes clear one of the big limitations of SOAs, namely scalability. A library’s own users can all be looking for books on the shelves at the same time; but users from the other library must queue for the librarian “service.”
There have been extensive efforts to implement the above approaches in local and regional HIEs that seek to connect multiple organizations. By 2009, there were more than 190 HIE initiatives in the United States—although only about one-third were fully operational.44 These HIEs report lower costs, improved outcomes, reduced staff time spent on process-oriented work, and increased data exchange—demonstrating the benefit of health information exchange. But despite these benefits, these approaches fall far short of what is needed. Most HIEs are based on standardized record formats or integrated care systems that cannot readily scale. Others link a range of proprietary systems. If a patient moves between two hospitals even within an HIE, critical tests done at the first hospital must often be repeated.
Most HIEs face the administrative burden of requiring adoption of legal agreements at each provider organization to share data. In addition, HIEs that began as pilot projects do not appear to be spreading or scaling up beyond their initial scope because they were launched without significant attention to long-term business models, a problem that the meaningful use incentives may not overcome. Most HIEs, moreover, are not currently interoperable across regions and markets to other HIEs, and thus remained closed and proprietary even as patients seek and require care outside their confines.45 Because each HIE system is different, there is little incentive for entrepreneurs who make middleware and other innovative tools to serve this marketplace.
While such systems can surely be incrementally improved, we believe that such approaches will not solve the fundamental need for data to be universally accessed, integrated, and understood while also being protected. In a sector as fragmented and rapidly evolving as healthcare, we believe it is impossible to build a national implementation of SOA solutions and directories that could be used and scaled indefinitely into the future. (To draw a loose analogy, the approach is like trying to enable free trade among hundreds of entities by negotiating a huge number of bilateral trade agreements. Or it is like trying to promote dialog among speakers of a thousand different languages by training one million translators, each knowing a pair of tongues, instead of enabling them to speak a common language. The idea is laudable but impractical.) Moreover, the approaches will not overcome the barriers to entry for innovators wishing to develop new solutions. We believe that a steady supply of such innovators in the ecosystem is essential for increasing quality and decreasing cost.
Universal Exchange Using Metadata-Tagged Data Elements
The best way to achieve a national health IT ecosystem is to ensure that all electronic health systems can exchange data in a universal exchange language. The systems themselves could be designed in any manner desired — they could accommodate legacy systems that prevail or new recordkeeping systems and formats. The only requirement would be that the systems be able to send and receive data in the universal exchange language.
We believe that the natural syntax for such a universal exchange language will be some kind of extensible markup language (an XML variant, for example) capable of exchanging data from an unspecified number of (not necessarily harmonized) semantic realms. Such languages are structured as individual data elements, together with metadata that provide an annotation for each data element.
With some risk of oversimplifying, let us give an example. Imagine that an elderly patient has lived in several different cities and, over the years, has had mammograms done at various hospitals and clinics. Her physician now needs to retrieve images of her breast tissue over the previous decades to determine whether a current lump is of concern. In a health IT ecosystem where tagged data elements make up a universal language, the data elements the doctor could retrieve about this patient would include the mammograms themselves from all of the various places the patient has sought treatment regardless of provider network, geographic location, or whether the patient remembers them. The physician would be able to securely search for, retrieve, and display these privacy-protected data elements in much the way that web surfers retrieve results from a search engine when they type in a simple query.
What enables this result is the metadata attached to each of these data elements (mammograms), which would include (i) enough identifying information about the patient to allow the data to be located (not necessarily a universal patient identifier), (ii) privacy protection information—who may access the mammograms, either identified or de-identified, and for what purposes, (iii) the provenance of the data—the date, time, type of equipment used, personnel (physician, nurse, or technician), and so forth.
Most of the time, the metadata will not be needed by the physician; this information will be invisibly in the background. Occasionally, as in the case of a false positive or false negative in a particular image, the physician may want to dig deeper: The metadata will be there.
The metadata will also be important for researchers who may have access only to de-identified data. They might use it, for example, to determine whether a certain type of imaging equipment for breast cancer is yielding excessive numbers of wrong diagnoses.
Data Element Access Services
In the example above about retrieving multiple mammograms, we assumed more than simply a universal exchange language. We also assumed the existence of certain national infrastructure for finding health data, and for controlling access to it. (Importantly, though, we have not assumed a national repository for storing health data, which would be a more difficult and politically problematic issue.) We call this infrastructure, collectively, data-element access services. The services would include those associated with crawling, indexing, security, identity, authentication, authorization, and privacy. As proposed, these DEAS and their components would have no right to use the data being exchanged; in fact, they would probably not even see the data. Rather, they would act much like today’s web search engines, but with additional levels of responsibility for exposing only those data elements authorized by applicable privacy rules and policies (including a patient’s persistent privacy choices) and only to authorized, authenticated users. A patient would have the right to restrict the types of data elements indexed at all, or could opt out of the DEAS completely (although such a choice might negatively impact that patient’s future care). We discuss privacy protection and security in more detail in Chapter Five.
Today, when a user views a web page, the data that make up the various parts of the page (text, images, ads, audio, video, etc.) are dynamically aggregated in real time from numerous computers in a range of physical locations and are then presented to the user as a single logical entity: the web page being viewed. The individual elements are not routed through any central server or repository. Rather, a set of access services enables the browser to query many distant computers simultaneously. Similarly, for health IT, a query submitted to the data-element access services would result in the seamless, dynamic aggregation of all the data requested. For example, a doctor’s request for patient information could involve an indexing system identifying all the physical locations on the network of the data; real-time aggregation of the data; and analysis, translation, and presentation by the software application that the doctor is using.
The health IT ecosystem we envision does not require the existence of a uniform patient identifier. Instead, it could use associations of intrinsic patient-related information to link the appropriate data to specific patients. This method is used now to create patient record locators within local closed systems and regional health exchanges, but as employed today, it can be plagued by human error. Since an automated system can use many more than the two factors (such as name and birthdate) now often used, it can be correspondingly more accurate. Indeed, “identity resolution” is an established technology, with commercial offerings available. For greater accuracy and convenience in the record-keeping associations, some patients (e.g., those named “John Smith”) might elect to index their records by an email address or a reference to a personal health record account, but this would be optional.
How should DEAS be brought into existence and operated? There are several viable options: Individual states (or self-formed groups of states) could establish and operate DEAS. Federal funds might be used in the manner of a “race to the top,” to support the best state’s proposals, or to create an additional interoperating and intercommunicating DEAS for use by Medicare providers. DEAS could be established in large health delivery networks (including those operated by the Federal Government, such as the Veterans Administration). They could emerge from a more aggressive push toward achieving interoperability among existing HIEs. Or, their growth could be left to the private sector, perhaps seeded by some start-up funds in response to requests for proposals.
As a matter of engineering, fewer DEAS providers is better, since communication between DEAS in response to queries is an additional overhead, but this must be weighed against socio-technical, governance, and policy forces favoring a more distributed network of DEAS.
In any case, all DEAS would need to be interoperable and intercommunicating in conformance to a single Federal standard, and would need to be audited for compliance with privacy and security policies. In response to a HITECH mandate, ONC has already begun a process for establishing governance of the NHIN. This process might also explore how best to operate DEAS.
Advantages of the Tagged Data Element Approach
Because of its multiple advantages, we advocate a universal exchange mechanism for health IT that is based on tagged data elements in an extensible markup language. If there were another equally good solution, it should also be considered; we have collectively been unable to think of one.
Tagged data elements can be combined for a single patient to produce the equivalent of an EHR, and organized around the needs of that patient at the time of care. At the same time, the data can be analyzed and combined with links to other information to provide physicians with clinical decision support, delivering patient-specific information to their fingertips to make the best possible decision for a patient given all of the information available. Tagged data elements from aggregated populations can also be combined to analyze comparative effectiveness of aspects of healthcare and improve efficiency and quality.
Since the language of metadata-tagged data elements is extensible, not fixed, it can itself evolve in response to the development of new applications and new medical knowledge. As already mentioned, extensible exchange languages exist today and are already used within health IT in specialized niches—and are used widely in other sectors. A main finding of this report is that the time is ripe for such a language to be declared as a universal exchange language for health IT, and that doing so will catalyze a large number of immediate and longer term advances.
Tagged data elements can be extracted by special software (known as middleware) from existing clinical systems. Or they can be produced from enhanced versions of those systems, or by completely new and innovative applications. In this way, all data could be exchanged among all systems no matter the origin or internal record formats of the data, and without the necessity of replacing existing legacy software.
A universal data exchange language can scale up to any level. It can allow retrieval by patients and physicians of information from different providers, in different parts of the country, to improve safety and coordination. It can deal with the diversity and complexity of both the underlying business and clinical systems. New types of data and associated metadata can be added at any time, since new data elements do not have to fit into a particular format. Data can be converted to whatever form best supports their intended use, from clinical diagnosis to medical research. This approach can create a fully interoperable, less costly, more effective national health IT ecosystem.
The availability of a universal exchange language can dramatically accelerate the entry of third-party innovators, because they can create applications that rely on uniformly described data elements and can access a larger market. These new applications could include cloud-based subscription services for individual doctors, small healthcare practices, long-term care facilities, large practices, and hospitals to handle practice management (e.g., registration, scheduling, and billing); sophisticated medical systems (e.g., decision support, integrated lab ordering, medication management, allergy tracking); integrated medical-image management; integration engines to facilitate data exchanges with personal health records and other types of EHR in the cloud; and population health management (e.g., analytical tools for public health reporting, clinical research, and outcomes analysis).
The approach that we describe is consistent with existing market trends. Innovative companies are emerging that can access data from existing records and rearrange, store, and exchange the data as desired. Other companies are offering advanced software applications, information, and other services via the Internet. PHRs allow patients to store and monitor all of their health information and research their conditions using the full range of electronic resources.
The approach described does not require the creation of a uniform patient identifier or a national repository for healthcare data. The data, protected by strong encryption, can be stored on existing legacy systems or in the rapidly evolving “cloud” of distributed data stores. Data involving a particular person can be stored in many different places and then aggregated, just as individual web pages are constructed from elements stored on many different computers. Specialized and secure search engines can crawl and index the metadata while actual access to the underlying data remains constrained by privacy protections.
This system can provide much greater security and privacy protection than can the current system. The attached metadata would describe the use and access provisions of the data, in accordance with law, policy, or the patient’s privacy preferences where applicable. For example, in a circumstance where consumers give their consent for particular uses of their data and prohibit other uses, this information would be encoded in the metadata. For example, privacy restrictions embedded in the metadata could permit a physician to send a pharmacist the data required to fill a prescription and permit de-identified data to be used for clinical research, but restrict other uses of the data. Privacy considerations are discussed in greater detail in the following chapter.
This chapter’s bottom line: A universal language for the exchange of health data is needed. An extensible markup language, where individual pieces of data can be tagged with context-setting metadata, is a straightforward solution and is superior to other proposed architectures.
No comments:
Post a Comment