My Review of the PCAST Report on HealthIT

See also The Language of HealthIT which goes into more details about what we already have, John Halamka's thoughts and those of Joyce Sensmieir from HIMSS.

Keith

---

The PCAST report on Health IT was released today.  The first question you might have is who is PCAST and how are they different from the HIT Standards Committee, Policy Committee and other FACAs related to healthcare (e.g., NCVHS). From the report:

The President’s Council of Advisors on Science and Technology (PCAST) is an advisory group of the nation’s leading scientists and engineers, appointed by the President to augment the science and technology advice available to him from inside the White House and from cabinet departments and other Federal agencies. PCAST is consulted about and often makes policy recommendations concerning the full range of issues where understandings from the domains of science, technology, and innovation bear potentially on the policy choices before the President.

So, basically, these are advisors to the President, rather than advisors to the executive branch of government (FACAs). They provide an interesting cross-check to other advisory commmittees.

One of the interesting points made by this report is the focus on ROBUST information exchange rather than simple exchange.  This is along the lines that John Moehrke has pointed out earlier this year, dealing with deeper issues and requirements for information access.  Simple exchange is just one part of the problem, and too much focus on it can (and has) detract from resolution of the complete problem.  As PCAST says:

Though the [Meaningful Use] rule expresses an intent to require more robust exchange of health information among providers at later stages of meaningful use, its initial requirements that EHR systems communicate with each other are very modest. This creates a danger that EHR adoption during early stages of meaningful use may exacerbate the problem of incompatible legacy systems. What is needed is a simultaneous focus on the capability for universal data exchange, able to unleash the power of the competitive market, to produce increasingly better and less expensive systems, and to create the "network effect" that spurs further adoption.  (Page 3)

I was amused by the attribution of CDA to ONC rather than HL7, but impressed with PCAST's understanding of its capabilities and limitations (page 4).

Creating the required capabilities is technically feasible, as demonstrated by technology frameworks with demonstrated success in other sectors of the economy. The best way to manage and store data for advanced data-analytical techniques is to break data down into the smallest individual pieces that make sense to exchange or aggregate. These individual pieces are called "tagged data elements," because each unit of data is accompanied by a mandatory "metadata tag" that describes the attributes, provenance, and required security protections of the data. Universal exchange languages for metadata-tagged data, called "extensible markup languages" are widely and successfully used. Indeed, ONC’s clinical document architecture standard (CDA) is such a markup language, and is an important step in the right direction...

 Later they point out on Page 6:

 ... ONC’s clinical document architecture standard (CDA) is an important step in the right direction, but needs more focus on data transmission, on innate privacy features, and on the enabling requirements of a more robust marketplace in new and innovative health IT products.

Later on Page 72 (underlining is mine):

However, the thrust of CDA seems largely that it be an extensible wrapper that can hold a variety of structured reports or documents, each with vocabulary-controlled metadata. While this shares many features with the universal exchange language that we envisage, it lacks many others. In particular, it perpetuates the record-centric notion that data elements should "live" inside documents (albeit metadata tagged). We think that a universal exchange language must facilitate the exchange of metadata tagged elements at a more atomic and disaggregated level, so that their varied assembly into documents or reports can itself be a robust, entrepreneurial marketplace of applications. In a similar vein, we view the semantics of metadata tags as an arena in which new players can participate (by "publishing"), not as one limited to a vocabulary controlled by the government.

Which is really an acknowledgement that Phase 1 of meaningful use doesn't really address data transmission at all (and isn't part of the CDA standard either). Also missing is a way to address one of the biggest issues in exchange which is how to address Privacy Policy at a National level.Wow, someone actually read the standard and understood its intent.  NOTE: There is a GOOD reason to have a record centric notion of clinical data, but that's another blog post (probably tomorrow's).  If they'd gone one step further, they'd have understood that the CDA is based on the HL7 RIM, and the RIM deals with the metadata tagged elements at that more atomic and disaggregated level.  One of the things that IHE has done has shown how CDA R2 and the HL7 V3 Patient Care Messages (also based on the RIM) can work together, one to produce complete documents, and the other to get at the detailed data. 

Chapter 4 of the report goes on to reinvent HL7 Version 3 ... if only they knew.  FYI: They estimate the cost to create the necessary standards to be around $20 to $40 million.  My guess is that is about right based on what IHE and HL7 have spent actually doing it already over the last decade.  Moving forward, maybe we need to spend 3-12  ($M) more them easier to use and implement, but please, don't send us all back to the drawing board AGAIN.

Chapter 5 on Privacy and Security I will leave to John Moehrke to provide detailed comment on.  I will point out that they recognize that perfect is the enemy of the good, but then go on to describe a nearly impossible to implement, perfect security architecure.  When a policy advisor starts talking about technical approaches, they've probably overstepped their bounds, and in this case, their expertise in real-world implementations (same applies to DEAS reinvention of V3).

In summary, it's a good report, and worth reading.  The council has some good ideas, but isn't aware of some of what has already been done.  They should stay away from designing architectures and focus on policy requirements.  Tomorrow's post will address some of their recommendations on a universal language and how ONC and CMS could move forward on that taking advantage of existing standards.