Alternative Chart-Note Capture and Other Data Input Methods
Robert Rowley, MD
Twitter: @RRowleyMD
Some very interesting trends are occurring in the health IT arena, which raise the question of what role Electronic Health Records (EHR) systems will have in the future. A few years ago, the focus for health care professionals and hospitals was EHR acquisition and implementation, as well as qualification and access to federal incentive money from the EHR Incentive Program (Meaningful Use).
This year, as could be seen in the recent HIMSS conference, the focus was much less on EHR implementation and Meaningful Use – these things were assumed. They were a given. Most hospitals and a majority of clinicians have already moved from paper to EHRs. Instead, the focus has been on other things: (1) patient engagement, (2) actual interoperability of data (not just at the high institution-to-institution level, but in the trenches at the point of care, whether you’re in an institution or not), and (3) analytics, with a subset of that being population health management – critically important as we move into an era of ACOs and value-based compensation.
Of particular interest to me were businesses that provide alternative chart-note capture and other data input methods which ride as a layer on top of already-installed EHRs. In essence, they provide an alternate user interface (UI) for an EHR that intrinsically has bad UI. I was struck not so much by what such companies are, but more by what this means.
The anatomy of an EHR
It is useful to think of a modern EHR as having several elements: (1) there is a UI layer, which is the default interface for entering and viewing patient data into the system; (2) there is the data layer; (3) there is the analytics layer, usually presented as a collection of in-EHR reports; (4) and there is the patient portal, which connects to the data layer and presents patient-facing views, much like the EHR UI presents professional-facing views of that data.
Let’s look at each of these elements to see where current and emerging health IT products fit in, and what that means for the future of EHRs
The EHR “default” UI
EHRs present a “default” UI to the user. Much has been said, and much has been criticized about how such UI interfaces exist with vendors today. The biggest complaints are that they slow down workflow, and result in taking 30 minutes to do a task that used to take 10 minutes. Or, worse yet, they take 15 minutes to do something you never had to do before at all.
Vendors face the difficult challenge of trying to have either a “one size fits all” UI, or a configurable and adaptive one that may address certain roles or needs. The problem is that there are more workflow and use-case needs than a vendor can ever hope to anticipate. After all, health care is local. Health care trends are national, driven largely by policy, or are regional, driven largely by market. But health care delivery itself is local. As a result, there will always be local-provider needs that are poorly addressed by the default UI of any given EHR. Rule of thumb: if you have to create a work-around to do something that is done poorly by your EHR, then you have a UI failure. And everyone who uses EHRs will eventually develop their own work-arounds.
This is where an emerging sector of business comes in – layering on a more-efficient, better UI for specific use cases. An EHR vendor that allows such specific UI plug-ins will do well. It will augment the user experience. Those that don’t will lag until they either fail or eventually give in to the irresistible trend.
The data layer
The EHR UI, perhaps supplemented by specific use-case add-ons, creates and interacts with the data. Typically, this data has been local, housed within the institution that created it. And, as has been amply addressed in the literature, the fragmentation of this patient data around institutional silos remains a problem.
Another emerging trend in health IT, not surprisingly, is the effort to link together all the data sources where they exist, creating globally patient-centric (rather than institution-centric) aggregated data. There are data-aggregation efforts around enterprise / institutional data, and similar efforts around ambulatory data. Products that support effective transition of care create and are built on data feeds from multiple siloed sources.
Another domain to consider, outside EHR-created data, will be consumer (or PHR) created data. This can come from direct patient (consumer) input, or, more likely, from connection to wearable devices. Wearable devices are an emerging market, which is making explosive growth. Integrating such data feeds into one place, and linking them with health data derived from EHRs is a very interesting area of growth, of which we have barely scratched the surface and realize its full impact.
The analytics layer
Looking at EHR-generated data, currently mostly locked up in the institutional silos that created them, there are analytics tools that can extract important reports and insights for a variety of audiences. EHRs tend to have a collection of reports built in them. But, again, it is not possible for any vendor to anticipate all the locally-important reporting that a hospital, medical group, ACO or individual medical practice will need. Things come up ad-hoc, and reports need to be created from the data that is there which are not part of the “off the shelf” reports that come with the EHR.
A whole new crop of businesses are emerging which do sophisticated data analytics around specific use-cases. The needs for reporting gaps in care, or clinical quality metric reporting, or utilization and cost insights around populations being managed by risk-taking medical organizations – all these things (and more, of course) are addressed by very inventive companies that can dig into the data and report on things that really matter.
And when the data sources that these analytics companies tap into become aggregated, cross-institutional data – perhaps including device-generated or patient-generated data as well – then the value derived becomes truly extraordinary.
The patient-facing portal
Most modern EHRs contain a patient-facing portal which allow a patient to log in and see a view of their data from the institutional place where the data is found. If care is being sought from an integrated delivery system (IDS), where the hospital, the health plan, and all the associated physicians are all on a unified enterprise chart, there is a valuable patient portal that is popular among consumers.
But for most people, care is sought in multiple settings with separate EHR systems, which may change over one’s lifetime. The fragmented picture of one’s health story becomes evident, and each place offers the patient a separate log-in to see segments of their story. “Portal overload” will eventually cause patients to throw their hands in the air and not use any of them, except for maybe just a few.
Another emerging trend, then, is the unified patient portal, which attempts to connect in a virtual way with every place where patient engagement is offered, so that there is a single sign-on, single UI place to view all of one’s data. New companies are making headway in this arena also.
So what will the future role of EHRs be?
If, as we have seen, that the native UI of EHRs is supplemented by improved UI add-ons that address specific use-cases, and data becomes aggregated across institutions and moves to the cloud, and analytics are done by specific companies that can cull data needed for specific ongoing and ad-hoc needs, and patient portals become aggregated into universal places – where does that leave EHRs?
The role of EHRs, in my opinion, will be around in-office or in-hospital workflow optimization. The EHR should be one built to easily allow specific add-ons to supplement their native UI, and therefore make the user (the care professional) more efficient, not less efficient as is sadly often the case now.
The basic structure of the EHR needs to be around workflows, and how to make them better. Gone should be the days when the expectation was that clinicians (“users”) would need to adapt themselves to do things the way the EHR was built – this paradigm needs to be turned on its head. EHRs should adapt to the workflows that exist, and offer shortcuts and improvements that allow all users to function “at the top of their licensure.”
An EHR vendor that creates the API linkages to “work well with others” will succeed. The native UI needs to allow other external apps to augment the experience and allow for better user experience. The data created needs to be sharable with external aggregated repositories. The data needs to allow external analytics companies to provide the supplemental reporting that is beyond what comes “in the box.” And the data needs to be able to interface with aggregated patient portals so that patient engagement can reach its potential.
This is a different role, and a different vision for EHRs in the future. It has happened in other industries, and will happen in healthcare as well. Those vendors that welcome this will do well. Those that resist will become dinosaurs, or (to use a popular Silicon Valley term) become zombies (companies that only stay alive by eating resources around them, but die once the investment dries up).
Healthcare is an ecosystem. So is health IT.
This article was original published on Dr. Rowley’s blog. It is republished here with permission.