A major goal of MIPS is to increase the sharing of information between providers and eliminate so-called data silos. Central to this goal is the implementation of fast health care interoperability resources (FHIR). FHIR allows one EHR to directly query and pull information from another EHR, and is based on the belief that medical charts can be reliably abstracted into resources. All exchangeable content is defined as a Resource that acts as the container that is shared and is defined by reusable data types, a common set of metadata, and most important, a human-readable section. No fewer than 28 different coding libraries are supported, including SNOMED, LOINC, CPT, NDC, RXNORM, ICD-10, and a host of others. Billing, coding, and government mandates require the use of these multiple overlapping code sets. This results in a basket of non-identical codes, none of which can be directly mapped to each other. Forcing documentation into various coding systems often leads to subtle but important deviations from the true intent. FHIR assumes that all notes will be timely, accurate, complete, and that disparate sub-specialty clinical data can be successfully merged into an easily readable format. Any practicing clinician will tell you that it does not happen. There is the cut and paste provider, the procrastinating documenter, the very specialized provider, the over documenter, and the under documenter. Imagine trying to merge chart data from a psychiatrist, an orthopedist, an emergency department (ED) visit with an oncologist, and a cardiologist. What are the chances that the medication lists from these disparate providers would be the same? Anyone who practices medicine in the real world and sees real charts knows that frequently the ED is too busy to get a full medication list, non-specialists will not be familiar with the host of ever-expanding oncology drugs, and it is very unlikely that a psychiatrist, an orthopedist, and an oncologist would have a similar problem list. Yet, if the goal is to have searchable, discrete data not limited to any particular EHR silo, each of these charts need to merge information from these various specialty charts. This inevitably leads to chart bloat. Furthermore, since each provider controls their chart, it is guaranteed to lead to inconsistencies. Will the problem lists be the same? Will the medication lists be updated uniformly? Without a master chart, FHIR cannot possibly result in compact easy to read charts. But who owns the master chart? Is it the Family physician? What if the patient has no insurance? No family physician? What if the patients’ insurer changes their provider lists? Another drawback in the implementation of FHIR is the assumption that coded templated result sets can function as a user-friendly form of clinical communication. In the FHIR paradigm, a “resource” is viewed as a container for clinical data, and each resource is heavily dependent on four major code sets (SNOMED, LOINC, ICD-10, CPT) and a host of lesser codes. These codes, by their very nature, both limit and subtly modify clinical intent. Lately, there has been a flurry of reports concerning clinician burnout and frustration with existing EHRs. Much of this frustration is based on the fact that all EHRs at one level or another use these same code sets, which were designed to optimize billing and data retrieval but are not at all user-friendly to clinical providers. We are forcing physicians to document to code sets, and it should be the other way around. Based on the above discussion, coupled with the fact that there are literally hundreds of EHRs and 24 approved clinical specialties, it seems very unlikely that clinical data can be merged across multiple platforms and multiple specialties as currently envisioned. What is the solution? First, FHIR was designed to share and organize data; it should not be tasked with acting as a clinical tool. If my patient was just treated by an orthopedist for a fractured arm, do I want to see the results of the history, the X-ray, the procedure, the exam and the plan each assigned to its own header with associated codes and metadata which probably will take at least a page or two of words and display — or would I rather get the text message “12/16/2019 – typical FOOSH injury, uncomplicated Colles fracture, good alignment post-reduction – recheck in 2 weeks – Dr. Samuel Jones”? Whatever discrete data that exists is present in Dr. Jones EHR, and there is no reason to try to clone it into multiple other charts, updates should be short, simple and concise text messages that are clinically intuitive and informative. How then can we aggregate and use all of the data that EHRs are now generating? Based on timing, specialty bias, inherent inconsistencies on how literally millions of providers chart, the lack of a designated “master chart” and the sheer number of different EHRs, it seems unlikely that each EHR can be merged with every other relevant EHR data source. The simplest solution is to have a single patient record. At one level, Medicare already does this. Rather than trying to merge to multiple different EHRs so that they are all consistent and in synch (which won’t ever be accomplished), every visit would automatically upload FHIR documents to a single master chart. This solves multiple problems: 1. Rather than trying to communicate with many different EHRs, each with their own little features, every EHR would communicate with a single standardized repository. 2. Uploading would be automatic, thus ensuring a complete record. 3. FHIR would subsume the function that it is really designed for: to act as a data consolidator. 4. Most importantly, this solves the “silo” problem. The master record would exist outside of any EHR or provider network. Changing providers or moving to another state would have no effect on the patient’s medical record. Failure to recognize and react to these issues will lead to yet more clinician frustration, poor adoption, and worst of all, inconsistent and excessively wordy charts spread everywhere. The solution is simple: Share concise, simple text summaries which worked well 25 years ago and will work even better with the ability to send automatically, and divorce the clinical provider from the yoke of forcing them to communicate using unending and often poorly designed code sets. Andy Muchmore is an internal medicine physician and CEO, CodoniX. Source
