LighthouseView

June 22, 2017

Godfather of the Structured Medical Record Dies

Filed under: Data standards,EMRs,Medical Records — HankMayers @ 12:27 pm

For anyone who has worked to improve the understand-ability and availability of medical records, their godfather was always Dr. Larry Weed. Well, with his passing at 93, he now becomes our ‘patron saint.’ He died on June 3rd in Underhill, Vermont.

His passion for understandable (even helpful!) medical records has saved untold millions of patients over the years. He was truly a trailblazer, and will be missed.

January 9, 2016

Turning to the Problems Inherent in Getting to the Right Diagnosis

Late in 2015, the National Academy of Medicine (formerly, the Institute of Medicine a/k/a the IOM) generated an important follow-up report to their earlier To Err is Human: Building a Safer Health System.  Their 2015 report is entitled Improving Diagnosis in Health Care. The report starts out acknowledging that, in spite of its importance to the value of care, the diagnostic process remains a rarely studied subject.

Errors in diagnoses remains a significant problem. The report cited some study data that concluded:

  • Diagnosis errors contribute to around 10% of all deaths
  • 17% of adverse events in a hospital setting had diagnosis errors
  • An analysis of malpractice claims indicated that diagnosis errors were the leading type of paid claim

As significant as this problem is, the authors, Erin P. Balogh, et. al., found that there was limited research on this topic. The authors identified 3 themes that repeat in their findings on what inhibits study in this area of medical practice. Those themes are

  1. Data is sparse
    1. Few reliable measures exist
    2. Errors are identified only in retrospect
  2. Patients play a big role in the diagnosis, and often are not adequately factored in
  3. Reaching a diagnosis is typically a collaborative process, and support for such collaboration remains a challenge in healthcare

The study produced the following 8 goals that they believe can lead to improvement in the diagnosis process and reduce diagnostic errors.

  1. Facilitate more effective teamwork in the diagnostic process among health careprofessionals, patients, and their families
  2. Enhance health care professional education and training in the diagnostic process
  3. Ensure that health information technologies support patients and health care professionals in the diagnostic process
  4. Develop and deploy approaches to identify, learn from, and reduce diagnostic errors and near misses in clinical practice
  5. Establish a work system and culture that supports the diagnostic process and improvements in diagnostic performance
  6. Develop a reporting environment and medical liability system that facilitates improved diagnosis by learning from diagnostic errors and near misses
  7. Design a payment and care delivery environment that supports the diagnostic process
  8. Provide dedicated funding for research on the diagnostic process and diagnostic errors

What I find especially encouraging is that these goals reveal the systemic nature of the challenge in improving diagnoses. We need to make progress on a number of fronts. Like so much in the health care system, the challenges flow from the fact that healthcare is a team sport. And, as the first goal makes clear, central to the team is the (engaged) patient.

In all settings, the bedrock for effective team work is participant engagement and respect, backed up by effective communications. While not listed as a goal, the study rightly touches on the need for healthcare entities to become continuously learning organizations. Being able to learn from one’s mistakes, in healthcare, requires overcoming cultural barriers, achieving some simultaneous changes in how liability is addressed, and understanding what it means to be accountable in our complex healthcare system.

Not surprisingly, Goal number 3, Ensure that health information technologies support patients and health care professionals in the diagnostic process, clearly asserts that HIT must play a significant role. In addition, closer examination of the report details on Goals 1, 2, 4, 5, 6, and 7 reveals the need for new or enhanced HIT applications to meet those goals as well. Some examples of those related HIT applications or enhancements are [I acknowledge having elaborated on a few of these items to make them a bit clearer]:

  • Technologies (Portals/PHRs) that allow patients (1) to contribute valuable input to diagnoses, and (2) enable patients to provide feedback on diagnoses
  • Technologies that enable close collaboration amongst practitioners – electronic data exchange and interoperability were mentioned as an exceptionally high priority within the HIT realm
  • Within the educational/training settings, a need to include HIT applications that are typically used to support diagnosis within the live clinical setting
  • Move on from the present focus of EHR clinical documentation, which is mostly data that supports billing, to presenting and recording data that supports the diagnosis process
  • EHRs, Radiological, and Laboratory applications all must do a better job at focusing on the diagnosis process and providing better capabilities for tracking the evolution of a patient diagnosis and incorporating second opinions.
  • PHRs can play a stronger role in engaging the patient in the diagnosis process. The report also touched on the emerging opportunities and special challenges in incorporating mHealth-based data.
  • Radiological and Laboratory applications need good access to clinical information that resides in EHRs
  • Identification and tracking of performance measures specific to the diagnostic process
  • Expand the concept of entity-specific, and national, registries for never events to include diagnostic errors. Envision applications that can systematically gather relevant clinical data on diagnoses from clinical & other applications so to enable systematic analysis, feedback, and workflow improvement for the diagnosis process
  • Improved patient access to clinical documentation for the purpose of identifying and correcting diagnosis errors
  • More consistent use of human factors engineering and ergonomics to identify application design flaws that actually are contributing to diagnosis errors
  • Systematically leveraging and communicating the knowledge of the professional liability insurance carriers regarding diagnosis errors

I believe that the National Academy of Medicine with its Improving Diagnosis in Health Care report has done a good job of helping all of us think about the web of HIT applications and how it can be enhanced to improve one of the most important tasks in healthcare – getting the right diagnosis for a patient as quickly as possible. It will take years of effort, moving on multiple fronts. The good news is that what is being recommended is not blue sky, just very complicated.

A worthy challenge indeed.

Cheers

April 10, 2015

Standards-Based Interoperability Is Finally Being Candidly Addressed

Filed under: CHERT,Data standards,EHR Record Portability,EMRs,HIEs,Interoperability — HankMayers @ 9:29 pm

It appears that National Coordinator DeSilva has laid down the gauntlet over the obstacles that the software industry has often (tho not universally) placed in the way of true, open standards, interoperability. In the ONC’s own words from their report to Congress, Health Information Blocking:
“While many stakeholders are committed to achieving this vision, current economic and market conditions create business incentives for some persons and entities to exercise control over electronic health information in ways that unreasonably limit its availability and use. Indeed, complaints and other evidence described in this report suggest that some persons and entities are interfering with the exchange or use of electronic health information in ways that frustrate the goals of the HITECH Act and undermine broader health care reforms. These concerns likely will become more pronounced as both expectations and the technological capabilities for electronic health information exchange continue to evolve and mature.”

And the former Coordinator Mostashari tweeted substantial agreement later today when he said:
“The second interoperability challenge that is really top of mind for these practices, in many cases, that they have spent years inputting data in to the systems that they have paid for, and now, to get their own data out of these systems, they are having to pay the vendor $5,000 to $10,000 for an interface. We’re covering that cost, but it’s outrageous. What we really want is basically the CCDA that they, for certification purposes, are supposed to be producing anyway.”

It has generally been understood that leadership has been quiet on this major problem because of its complexity, and the need for the solutions industry to truly get behind electronic medical records. Well, after $28 billion in EHR Incentive Funds (and untold billions by others to address electronic records needs for sectors of healthcare that were not eligible for HITECH funds), it is safe to assert that the market is no longer in its infancy. There are important elements in the healthcare information highway that must no longer be ignored, and agnostic interoperability is one of them.

This is precisely the thrust of the remarkable letter of January 21, 2015 wherein 22 medical specialty boards and the AMA said enough was enough to the National Coordinator and the Secretary of HHS. One of their major complaints was the absence of any meaningful (my intentional wording) agnostic interoperability readily available by federally certified medical records systems.

The S&I Wiki and HL7 have made great progress in providing agnostic interoperability concepts and standards. We now need the political will and the sense of common purpose to designate those standards that the industry must use to gain CHERT (now, HIT Certification Program) certification on the matter of interoperability. While there is still ways to go to reach our ultimate interoperability goal(s), we can set a starting point with what we have now, and incrementally reach where we need to be.

This is one of those areas where we must place aside our national zest for competition, and cooperatively build that which we all must ultimately share.

I am going to be very interested in the buzz at HIMSS15 in Chicago next week.

Comments, anyone?
Cheers

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