Patient Experience Management: How to Begin

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, 90 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 built 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 70 percent of the functional requirements of this entity called “our patients.”

Applications vendors often 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 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 the only way is to start  – is 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.