PCAST Report Thoughts

Preface: There has been a lot of discussion about the PCAST report since December when the report was published. Recently, there were excellent blog postings from John Halamka and Wes Rishel on the subject. Those interested in learning more should access the HITPC committee PCAST work group hearing that starts at 8:30 AM EST tomorrow.

Here are some of my comments concerning the document.


Strong incentives and regulatory input are not needed to spur HIE. All clinicians recognize potential value of HIE. We do need a guide that references proven models for sustainable HIEs. Regulatory input is important for the adoption of standards that enable interoperability. It is important to establish minimal national requirements for privacy and security concerning protected health information that flows into or through HIEs.


Page 23. I agree that we need: 1) further development of technologies and architectures that enable HIE and, 2) financial resources to build required infrastructure.


Pg. 24. A single health IT system alone cannot simultaneously do all of these: 1) improve clinical encounters between doctor and patient, 2) support clinical research, 3) provide data needed to improve public health. It is unrealistic for EHR to maintain patient records and simultaneously perform the functions required for data mining. With current technology there is too much sacrifice of performance of the clinical system. This will not be tolerated by clinicians. All the goals of PCAST are difficult to achieve within one technical system. In fact, many of the data elements needed for clinical research are not acquired in the typical clinical record. The PCAST group did not seem to understand the capabilities of the typical EHR nor did it specifically call out the functions performed by data warehouses.


The idea of patient centric care is admirable but not really practical. It does not necessarily consider clinician workflow. The medical record will always need to be provider centric with respect to usability and workflow. One expects the medical record to be patient centric with respect to data collected and how the data is used. I assert that humans perform their work best through use of documents. These provide context as well as data. The technology to extract discrete data elements from documents such as CDA CCD and many IHE defined documents exists but is not widely utilized at this time. There have been no regulatory requirements to do this so the effort has not been made.


Pg. 25. Document centric approach deals with how humans (clinicians) collect and use information. Anatomic data collection would work fine for machine processing as long as there are standards, transport security and robust consent policies.


Pg. 26. I agree that streamlined data entry via checklists, customizable templates and other means of entering structured data is an area of opportunity. Natural language processing may offer a clinician friendly process. Templates are easy to use to enter findings but hard to use by other clinicians to evaluate and process the data. Text is much easier to comprehend. Many EHRs recognize this and translate templated data to human readable text.


Pg. 27. I agree that development and implementation of more robust CDS is important but it difficult to accomplish. If CDS interferes with workflow then clinicians often ignore the advice. An area where CDS offers great potential for avoiding medical errors is diagnostic CDS. Diagnostic errors can be reduced with diagnostic CDS that is always running in the background. Clinician diagnostic heuristics are prone to a variety of biases that CDS could overcome. There are a number of ways to activate CDS functions. I think the most effective are within the EHR itself where CDS output is most actionable. For business intelligence purposes CDS can be used but it usually is not real-time and its use is more strategic than tactical.


Pg. 31. I agree that data exchange and aggregation are important to realizing the potential benefits of HIT. The aggregation process may adversely affect EHR performance and probably is best performed in a separate but connected system.


Many HIEs provide view only portals for clinicians. This works with a simple browser technology even for clinicians without an EHR. The disadvantage of such portals is that it is difficult to transfer information to the viewing clinician's medical record for a patient. Furthermore the information is transient (as in a message format) and will not persist within the clinician's record system unless manually transferred.


Barriers to HIEs include: complex governance structures, lack of sustainable business models that are well accepted and distributed, stakeholder reluctance to share information, and the technical limits of linking disparate information systems.


The report predicts a proliferation of cloud-based EHRs. Cloud-based EHRs are likely because they are often less expensive in the short term and do not require the availability of sophisticated technological support within small practices.


Pg.39. I disagree with the assertion: "We believe that any attempt to create a national IT ecosystem based on standardized record formats is doomed to fail". The successes of HITSP, IHE, HL7, and other groups prove that this statement is erroneous. Read the blog posts above for more in-depth discussion of this topic.


Pg.40. Most HIEs began as pilot projects supported by grants. Many HIEs are not interoperable across geographic regions, markets, and other HIEs. ONC's state grant program is likely aggravating this problem. I think it would have been better to spend some time establishing best practices and selecting an approach based on successful pilots completed in the past. Then a set of policies, procedures, and technology could have been made available to states, with federal support.


Chapter VI. Economic and Regulatory Issues


The report asserts that there is little incentive for investment by providers in interoperability standards. A clear path to productive data exchange has been established via, at a minimum, the stage 1 and proposed stage 2 and 3 Meaningful Use requirements.


I thoroughly agree that local and regional exchanges will not provide a clear route toward national interoperability if they adopt different standards or settle on different governance models for regulating data access. Different models may need to be considered however based on intended use, i.e. the Direct Project (point to point exchange) vs. Nw-HIN exchange (network of networks) options.


Federal leadership does have a clear role to play.


The value of data increases as the number of participants in HIEs increases (fax analogy.) More people using HIE will decrease the cost.


An important strategic question is whether local experimental projects (56 state HIEs and 17 Beacon Communities are the appropriate approach if the end goal is a national infrastructure. I think the answer is clearly-no.


The report states two goals: 1) Index to data and 2) assembly of data elements for a purpose. A central repository is not needed. But if a central repository is not used there is a problem with small practices because data may not be available 7/24/365. This is NOT analogous to the Internet and search engine technology as asserted where servers are always online.


Pg.59. Discussions in the report of ACOs and Primary Care Medical Homes should not have been in the scope of this report. This is a political position statement not a technology discussion.


Pg. 60. Estimating Costs. Development of standards to fulfill recommendations will cost $20-40 million dollars. Upgrades to systems will result in an increase of 5% to 10% of current costs. I do not have expertise in estimating the cost of information technology development but the figures seem too small, perhaps by an order of magnitude, to me.


Chapter VII. Health Data and Research


I question the assertion in the report that valuable research data would flow from routine clinical care data. Many research studies use data elements that are not captured during routine medical care. Some have said that only 5-40% of data elements required for research are collected during routine care.


Recommendation might be good for adverse drug event reporting but this would still need the construction of a substantial reporting infrastructure-it would not be automatic. Even here, many data elements are not captured routinely.


The problem that medical records do not contain enough clinical detail will not be solved by the use of tagged data elements alone. There would need to be a revolution in how and what data is collected in a medical record. This even challenges the current definition of a "medical record."


I doubt tagged data elements alone will be useful for comparative effectiveness research. To be done properly this work needs a prospective research design.


Chapter IX Recommendations
IT systems should be capable of meta-tagged data by 2013. There is little likelihood of achieving this goal.


Support development of DEAS that are able to locate data relating to a specific patient. There are numerous technical and policy issues to solve before DEAS will be seen widely.


Transform CMS IT system by 2014. It is hard to know what will be needed because requirements for Meaningful Use stages 2 and 3 have not been determined. The work will be ongoing, costly, and relatively risky.