Wednesday, December 8, 2010

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.

5 comments:

  1. I suppose that RIM here has nothing to do with Blackberry?;-) Although some mobile devices, especially those on Android can profit from ICU4J and the UCUM (used by HL7, DICOM and various others) part of Eclipse UOMo based on ICU and OSGi.

    ReplyDelete
  2. Would that the PCAST report were only ill-informed regarding standards. A 100 page report emphasizing the Language of Health not once mentions SNOMED. It totally dismisses current interop standards work, and instead promotoes an unproven, probably unimplementable, and potentially dangerous approach. If they can't even have minimally understood HL7, how can we trust that they even understand the system they are proposing?

    Let me expound briefly on "potentially dangerous". What we (should) have learned from the aerospace industry is that safety in complex systems is only achieved by rigorous systems analysis involving understanding the complete flow of information and its use in specific task contexts by humans. By promoting an unconstrained infrastructure based on data elements out of context, and with no understanding of the tasks and goals of clinicians in using that data, the proposal creates an inherently unsafe system for which system safety analysis will be difficult, if not intractable.

    Moreover, in such a wide open ecosystem who would be responsible for analyzing the safety of applications and SOA-enabled mash-ups? The app developers? We can't even get developers of single institution EMR systems to do proper human factors and safety evaluations of their own products.

    This seems to me like a patient safety disaster from the get-go.

    ReplyDelete
  3. We are working now since ten years in an international field. I am pesonally sitting also in some standardization working groups. IHE has done a great job over the last 10 years but it seams that IHE has a problem to sell and explain this value in the right way to the right political people. What we need is a recommendation from the US Government to use IHE as THE methodology for achieving interoperability in the field of healthcare.
    We have done this together with many other people in many other countries worldwide and it works well. Btw europe IS ALREADY using IHE as base for exchanging clinical content between 9 memberstates. We should try to bring the right political people together. It is for me personally strange that the inventor ( USA ) of all that IHE stuff is not straight following and recommending these specifications.

    Martin Tiani
    Tiani "Spirit"

    ReplyDelete
  4. Believe it or not, DoD Military Health System RFPs are now including requirements for IHE Integration Profile use as a requirement in the PWS and scope of work. I have advocated this for over 10 years whenever I have the opportunity to be heard. IHE has been doing what was needed to solve HIE securely several years back - industry and Government just need to pay a little more attention and pick up the IHE documents and read them.

    V/R,

    John Wolf
    Sr. Director/System Architect
    DoD MHS and VA Healthcare Systems

    ReplyDelete
  5. Here here John! And thank you for your service :-)

    ReplyDelete