Here is my new post on http://www.healthsystemcio.com
Patient Experience Management (PEM) is not about Patients, but it is often designed just that way. The problem lies with the plurality, the pesky little “s” that takes the design and implementation away from an individual patient, and places the focus on patients.
Other industries grapple with the same problem, only with them the issue comes about when designing and implementing systems and processes around customers instead of a customer.
Do you recall the talking points of the recent McKinsey survey about patient experience management? The study made drew two conclusions. First, ninety percent of hospital executives responded that improving PEM was their first or second priority within the next three to five years. Second, those same individuals stated they did not expect much to happen regarding PEM because they did not know who in their organization ‘owned’ the PEM business problem.
Ignoring that issue, if only for the reason that almost everyone else seems to be taking the same approach, what if a hospital wanted to move forward and deal with PEM in a meaningful way—not meaningful as in the term Meaningful Use—but in a way whereby having a PEM system actually yielded something for the hospital?
Few industries have done a stellar job with Customer Experience Management (CEM). What can be learned from their failures? Plenty. The failure of CEM systems originates at the get-go. The organization does a poor job of defining its business problem, deciding it needs a system to manage its customers, as though all customers are the same. With that as its target, it goes out and finds and implements such a system.
Here is the problem from the perspective of PEM, and in some regards for EHR. Whatever system you choose for PEM, CEM, or for that matter EHR has been designed to address thousands of individuals as a single entity called “our patients” or “our customers.” The system is build upon managing the experiences of a core set of patient attributes. Chances are good that whatever PEM system you select—they really are pretty much the same—will address roughly seventy percent of the functional requirements of this entity called “our patients.”
Applications vendors build solutions and hope to find a problem which matches the system they built. If all your individual patients fit neatly into their vision of this “our patients” entity your worries are over. If however, patients are different, which they are, they will have many needs which lie outside of the boundary of their application. It is these set of needs—functional requirements—upon which the success or failure of your PEM will be based. These same needs are the ones that are unmet today. These are the ones, the outliers, which raise the ire of your patients and the ones lowering your organizations PEM scores; assuming you track this.
One way to solve this problem, in fact, to my knowledge to only way is to start by defining rigorously the functional requirements of one patient, a super-patient, which encompasses every requirement. With this done, you have a PEM model, based on a single patient. Now instead of having PEM requirements which lie outside of the boundaries or core competencies of what a vendor wants to sell you, you have a turbo charged set of requirements. The diverse PEM requirements of your individual patients are contained within the capabilities of the defined super-patient.
If you approach PEM this way you have defined for yourself a solvable problem. You now have a problem looking for a solution instead of a vendor with a solution looking for a problem.
I’ve always considered myself to be rather athletic, although I must have been on break when they handed out the coordination genes. Perhaps that is why I tended towards individual efforts like running.
My favorite thing about healthcare is having witnessed it up close and personal both as a cancer patient in the 80’s and as the survivor of a heart attack seven years ago.
Many organizations have a Program Management Office and a Program Steering Committee to oversee all aspects of the EHR. Typically these include broad objectives like defining the functional and technical requirements, process redesign, change management, software selection, training, and implementation. Chances are that neither the PMO or the steering committee has ever selected or implemented an EHR. As such, it can be difficult to know how well the effort is proceeding. Simply matching deliverables to milestones may be of little value if the deliverables and milestones are wrong. The program can quickly take on the look and feel of the scene from the movie City Slickers when the guys on horseback are trying to determine where they are. One of the riders replies, “We don’t know where we’re going, but we’re making really good time.”
The first home I bought was in Denver. Built in 1898, it lacked so many amenities that it seemed better suited as a log cabin. There was not a single closet, perhaps because that was a time when Americans were more focused on hunting than gathering. Compared to today’s McMansions, it was doll-house sized.
Cerealizable.