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.
Related: Can EHRs Achieve the Interoperability We Need?
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.
Dr. Rowley writes regularly about his clinical & technical insights into health IT on his site: Robert Rowley MD where this was first posted.
