Monday, December 27, 2010

PCAST Report - Technology for an Integrated Health IT Ecosystem

President's Council of Advisors on Science and Technology (PCAST)on December 8, 2010 released their report to the President: "Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward." In this post I am going to focus on Chapter 4 of the PCAST Report on health IT "Technology for an Integrated Health IT Ecosystem." The chapter's text is below.

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.
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.

Wednesday, December 15, 2010

2010 Audio/Video Features

This past year has been a great one for health information technology. I've had a lot of fun serving on various committees and really enjoy my work. One of the things that has stood out for me from 2010 was writing blog posts for O'Reilly Radar. Many of the highlights of this past year for me were also the opportunities that I had both to interview thought leaders in health information technology and be interviewed by some leading healthcare and government journalists. There have been some great websites and print publications, but today I was looking back through some of the audio and video highlights of the year. The latest was an interview for iHealthBeat on December 15, 2010:

A few of the discussions I had in 2010 with leaders in health information technology were:

Interview with National Coordinator for Health Information Technology David Blumenthal, MD; March 26, 2010

Interview with Deputy National Coordinator for Programs and Policy within the Office of the National Coordinator Farzad Mostashari, MD, ScM; November 10, 2010

Interview with Brian Behlendorf, Arien Malec, David Riley at the OSCON 2010 Healthcare Track; July 21, 2010

Some of the other opportunities I had to be interviewed by the media on health information technology were:

Federal News Radio; August 7, 2010

HealthLeaders Media; August 3, 2010

Federal News Radio; May 7, 2010

And then there was my fun conversation with Liza Sizler of Perficient during the 2010 HIMSS Conference:

HIMSS Perficient Interview; March 4, 2010

Wednesday, December 8, 2010

The Language of the Health Internet

The President's Council of Advisors on Science and Technology (PCAST)on December 8, 2010 released a report entitled "Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward." You can watch the video of the event here. One of the striking features of the report is that it calls for the creation of a "universal exchange language" to enable healthcare providers to share health information in real time, and a "digital infrastructure for locating patient records" while still providing for patient privacy and security. Keith Boone gives a great opening post into the standards this entails.

The report advocates for the use of open standards and some type of XML variant in the development of a healthcare language that can be used to exchange data. This will be the language of the Health Internet. Using an XML-based approach might allow health IT to expand beyond EHR systems used in physician practices to a more widespread use across the entire healthcare industry. The report says:
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.
A universal exchange language will certainly help with broader adoption of a robust system for health information exchange. The report calls out certain advantages to using a universal language:
  • It will improve healthcare quality, by making it possible for a physician to integrate accurately all of a patient’s medical information.
  • It will improve healthcare quality and decrease costs, by making it possible for third-party innovators to compete to create widely applicable services and tools serving patients, providers, payers, public health officials, and researchers.
  • It will provide much stronger privacy protection than available under current approaches, allowing persistent privacy assurances (including applicable patient preferences) to be attached to different kinds of information and using data-level encryption to prevent access of data by unauthorized persons.
  • It will not require universal patient identifiers, nor will it require the creation of Federal databases of patients’ health information.
  • It will simplify the regulatory burden on providers, by decreasing the focus of meaningful use regulations on ad hoc list of data items.
  • It will help U.S. industry leapfrog to the front of the pack internationally in health IT, by providing exchange standards that can be more broadly adopted by others.
  • It will facilitate public health and medical research, by providing a secure way to de-identify data.
  • It will not require that existing systems be replaced, but only be modestly upgraded or augmented by “middleware.”
All of these points ring true. And the report further calls for more stringent data exchange requirements for future stages of meaningful use criteria. "The steps that must be taken can be accomplished with the required time frame. It can be accomplished via an evolutionary transition from traditional EHRs to a tagged data element model, along with a more rapid transition for the more limited purpose of data exchange by means of a universal exchange language," according to the report. "We note that these steps are not intended as an alternative to ONC's important work in promoting the adoption of electronic health records. Rather, they are complementary to that work and will accelerate adoption."

I am in favor of the direction this report takes and will conduct deeper analysis over the coming weeks. There will still be a great deal of debate over how to best implement the recommendations in this report, but an important discussion has been given the spotlight, and I believe this will help drive the agenda forward. One thing is for certain - this report brings health information exchange to the forefront of the discussion on meaningful use of certified electronic health records.


Realizing the Full Potential of Health IT to Improve Healthcare for Americans: The Path Forward

December 8, 2010 the President's Council of Advisors on Science and Technology (PCAST) released a report entitled “Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward.” (see report below)


  • Kathleen Sebelius, Secretary, Dept. of Health and Human Services
  • Lawrence Summers, Assistant to the President for Economic Policy and Director, National Economic Council
  • David Blumenthal, National Coordinator for Health Information Technology
  • Eric Lander and Christine Cassel, President’s Council of Advisors on Science and Technology
  • Private-Sector Discussants

Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward

Monday, December 6, 2010

Information Exchange Workgroup - Entity Level Provider Directories

On December 6, 2010 the The Information Exchange Workgroup of the HIT Policy Committee met. Much of the discussion centered around upcoming recommendations to the HIT Policy Committee on entity-level provider directories (ELPD).

Saturday, December 4, 2010

Information Technology and Priorities for Healthcare:The White House Perspective

The 2010 CAQH Administrative Simplification Conference was held September 21 - 22, 2010 in Washington, DC at the Omni Shoreham Hotel. The conference focused on two CAQH initiatives: the Universal Provider Datasource (UPD) and the Committee on Operating Rules for Information Exchange (CORE). Aneesh Chopra, Chief Technology Officer of the United States, gave the keynote address.