There's an excellent blog post over at Health Affairs Blog titled "The Strategic Challenge of Electronic Health Records" that goes over the inherent problems and promises in this age of EHRs and structured data. The post, as written by Scott Wallace, examines the gap between the ability to collect important health data that technology represents and EHRs' tendency to disrupt workflows due to lack of user-friendly design.
This hits home for us at mTuitive because when we design synoptic reporting solutions for health providers, we are painfully aware that time is the most precious commodity that physicians have. If you add even a second on to a process, without at least compensating for it somewhere downstream, then it becomes an uphill struggle to convince a health care provider to use your product. Even if we point out all the ways that structured data is important and improves data liquidity, or helps adhere to some synoptic reporting requirement, the moment it becomes arduous is the moment those benefits becoming meaningless to the user. As Wallace puts it:
In a world of Apple-typified simplicity, why is it so hard to get the right EHR? Because, unlike Apple, EHR designers haven’t started with the question of how value can be created for users of the technology. Technology isn’t the problem. The challenge is in articulating clinicians’ information needs and meeting them by making the right tradeoffs between corporate and business unit strategies. EHRs can, and should, provide relevant information when and where clinicians need it, recognizing that care is not a commodity and that different care processes have different information needs. User interfaces must anticipate clinicians’ needs rather than require individual user design. EHRs need to eliminate low-information pop-ups and alarms and instead provide alerts and reminders that are both timely and relevant. They must be designed with assiduous attention to data entry requirements, replacing blind mandates with thoughtful assignment of the task and the timing. When tech companies assume how physicians will use their products, or simply adhere to the bare requirements to meet meaningful use, a fissure is created between purposes of the physicians and their tools.
It's funny that a term that should be synonymous with "meaningful use," "practical value," is rarely used when discussing electronic solutions for healthcare. The two could be interchangeable and used to define each other, and yet in real life they are fairly disconnected. In the world of EHRs, "meaningful use" has a specific definition as proscribed by the government in order for the technology platform to obtain certification as an EHR. There are differing levels of meaningful use that EHRs must meet to attain the varying levels of certification. The problem, as the post adroitly points out, is that "meaningful use" is being decided by bureaucrats and mostly refers to how data is transferred (and mildly on how it is captured). This is a problem because those are processes that occur in the background and don't truly involve physicians (though it does affect them, but more on that later). "Meangingful use" has a worthy aim - data liquidity, which is the ability to take data entered in one form/location and then use it for other applications and needs. So entering in a patient's drug allergies in one form should then populate other forms and throw up any warning signs should physicians attempt to use that drug on the patient. Or entering in different points of structured data can end up feeding into outcomes reporting or being sent into disease registries for improved understanding of population/demographic health trends.
Data liquidity is a noble and important goal. It's something mTuitive believes in and utilizes by eliminating redundant questions or using logic branching to remove any irrelevant fields that a physician may see. But the more important goal should be "practical value" — that is demonstrable ways that a solution is providing help to the user. That means removing it from the theoretical (downstream use of data is helpful, but doesn't impact most users when they just are trying to get through their day or complete their various documents), and placing it into a space where it will have concrete positive repercussions for the user. For example, by showing how completing three fields in a document will generate ICD-9/ICD-10 codes which, in turn, will aid with reimbursement and insurance claims reveals the practical value of a solution.
Meaningful use is meant to cover how data is captured so it can translate it into how data is sent (hence a push for structured data in order to better send it across various parts of a system). But, to parse terms, the "how" in this case is focusing on the wrong aspect of the manner in which to document information. The "how" certainly needs to encompass the way data is structured for better use and data liquidity, but it also needs to mean the various ways that doctors are interacting with solutions. If it's rigidly built but not specific to the doctors' needs, then they will rebel and feel like they are being forced into something they despise. Workflows matter, human factors in crafting documents matter, and meaningful use needs to align with practical value in order to improve synoptic reporting participation and physician satisfaction.