January 10, 2011

The Role of the PCAST Report?

Filed under: Data standards,EMRs,HIEs,Meaningful Use — Tags: — HankMayers @ 12:20 pm

It is important, I think, to acknowledge that the technical and functional arguments behind the PCAST recommendations are persuasive. The future that they depict is quite desirable, and will be much easier to make happen once their meta-data tagged extensible language is in place.

However, getting to that future (hereafter the “PCAST future”) is no small undertaking. Furthermore, a preoccupation with its rapid achievement will mean significant delays in getting the overall HITECH vision in place (widespread EHR usage by practitioners and institutions, ubiquitous electronic health care transactions, rapid care information sharing and coordination amongst a patient’s care team, and care that is informed by the latest evidence-based guidelines). The biggest fear right now with PCAST is that it will require a serious stepping-back in our progress to date.

My reading of the report is that PCAST understands the importance of keeping our hard-earned momentum going. Indeed, some would argue that we are in the early stages of gathering momentum, and it would be all-too-easy to lose the ground that has been gained. PCAST’s initial focus for change appears to be on two areas of HITECH activity:
• Capability by the HIEs to be able to handle the translation and routing of (both?) document-based data, and tagged, extensible data
• Have Meaningful Use reporting (I presume this includes the related Clinical Quality Measures) be the first component based upon this new data tagging and processing capability

I find it encouraging that PCAST is limiting the initial changes to EHR technologies to just their MU reporting. However, Clinical Quality Measures is one of the more contentious corners of the HITECH venture. So, I think this “opportunity” might benefit from some more analysis. I also agree with their targeting of the HIE platforms as an early adopter of the tagged data and “data element access services,” in light of the key integration role of an HIE. HIEs are a true pivot point, and they will/must make interoperability happen.

However, the key factor in all of this is the matter of timing. PCAST wants ONC to tell the industry that systems will have to have this tagged data capability by 2013 to be certified under the EHR program. And vendors do have a number of ways to approach this, from “strapping on” middleware at the backend to do all the translating, or converting their products to this new data paradigm.

However, reaching this place by 2013 means:
1. The necessary data standards have to be hammered out at national policy levels, and once those are in place
2. Then vendors can decide on their approach to conform, and proceed to implement it.
3. All the while, the vendors are engaged in implementing features required to meet Stage 2 Meaningful Use criteria, which will not be final until late 2011
4. All the while the vendors are engaged in migrating their systems to accommodate ICD-10 and 5010.
5. Etc.

As I reflect on the numerous advantages articulated in the PCAST report, it strikes me that they are heavily related to the HITECH/EHR objectives envisioned primarily for Stage 3. Given the 5 industry preoccupation items listed above, I am convinced that the logical target for meaningfully implementing the PCAST report is 2015/Stage 3 (or whenever Stage 3 ultimately comes to pass).

Pushing the date off 2 years should not give us license to wait a couple of years to get going. It seems reasonable to me that a national standards effort to create a tagged-data, extensible healthcare markup language could be launched soon in parallel to other HITECH efforts. While the ONC and CMS are indeed working very hard on quite a few fronts, we are only going to be able to reach this new capability via parallel work and preparation. Waiting won’t make it any easier. Indeed, every year further down our current track means greater effort, cost, and resistance to ultimately changing over – even if incrementally.

I wholeheartedly concur with their suggestion that the payers become the long-range financiers of HIEs over time.

I believe that the publication of the PCAST report is actually an opportunity. For a whole bunch or reasons, HIT data exchange strategies have been focused on document definitions. As PCAST clearly pointed out, there are long-term higher costs, avoidable security & privacy control limitations, and information sharing complexities inherent it the document approach. This approach avoided having to choose winners and losers, and it provided a paradigm that was easily understood by the larger user community. However, the PCAST report was developed by a good cross-section of stakeholders and thought leaders who have articulated a technical vision that is truly in the public interest. The opportunity is that we now have that vision, and some logical implementation concepts, upon which we can fashion a specific implementation plan.

We need to finish this work by constructing a reasonable, but aggressive road map/time-line to turn it into reality without undue hardship on the vendors, the HIE organizations, and the users who do not need to adapt to their EHR twice.

Having encouraged my colleagues to get efforts underway to prepare for this valuable transition, I also want to share some points in the report that give me concerns:

1. The term “cloud computing” does not yet enjoy consistent use in the field. Some use it to include computing transactions that could never meet the scrutiny and rigor that health care data requires. So we’ll need to adopt some of its desirable characteristics in a manner that is appropriate. Federal certification and rigorous auditing will be essential.

2. Ambulatory physicians would appear to be one of the best markets for ASP-based service providers. I am puzzled why this version of cloud computing was not specifically called out.

3. The conventional functionality of HIEs and the authors’ “data element access services” sound remarkably similar. I am presuming that the DEAS capabilities AND the conventional functionality can be simultaneously operational within the HIEs. If not, then the switchover is going to be a complicated undertaking that was not candidly acknowledged in the report. This consideration needs to be fleshed out in greater detail.

4. Chapter 3 ends with a footnote on the unique level of EHR adoption Massachusetts has achieved. This would have been a good moment to have acknowledged the essentiality of adequate up-front funding for individual practitioners. For that factor, plus standing up HIEs, is what made Massachusetts so successful. Regrettably, the EHR funds fall short in this regards. Parenthetically, the SBA bill proposed by Senator Kerry would go a long way towards addressing this persisting impediment to practitioner engagement in the EHR incentive program.

5. While applications development within the internet has proven to be remarkably inexpensive to the end user, I see no evidence that it can result in the kind of presentation clarity that health care users, especially physicians, demand for their user interface. I am not convinced that individual physicians would be well served by any solution that departs from the data and feature integration that an ASP provider can deliver.

6. Please see my security management concerns noted in my earlier narrative.

7. The security chapter on page 52 seems to be saying that an assembled and delivered patient record (by the DEAS infrastructure) would be limited to immediate display, and not amenable to being “permanently stored locally.” It is essential that such information be permanently stored locally (the practitioner’s office or the care delivery entity), to serve as documentation for the physician’s decisions.

8. While cloud-based repositories offer some interesting storage economies, there would be simply too many opportunities for dilution of accountability. And from a consumer point of view, I believe this notion will never be acceptable. Presenting its theoretical possibility will only risk public distrust with entire tagged-data proposition.

9. The report decries current harmonization efforts to relate taxonomies that focus on diagnoses, test results, billing codes, medical device instrumentation, etc. It clearly says that this effort is misguided. There are significant healthcare market drivers behind such harmonization. As a layman in these matters, it would be very helpful if the report could articulate how their vision would accomplish the goals that drive the current harmonization efforts.

10. ONC/CMS has committed themselves to work with a number of practitioner and quality groups in constructing and testing definitions for quality measures for specialist care. Will these efforts have to be suspended whilst the tagged-data approach to quality data gets elaborated?

11. The report dwells on the numerous ways in which tagged data will enhance CDS capabilities. Their elaborations here were enough to convince me of the technical feasibility of their claims. However, the history of the clinical adoption of CDS technologies is one of repeated disappointments. In my opinion, we are only going to be successful if we find a way to make such services user-sensitive. That is, that they do not belabor what the practitioner already knows. And that is an additional layer of application intelligence – and another arena of debate!

Hank Mayers, President
ReliaTechConsulting, LLC
January 10, 2011

Powered by WordPress