“Playing by the rules” of a customer-facing systems is understandable, even essential much of the time. And if it engages you to come back and do or buy more stuff then the rules are worth it to all concerned, cool.
To verify your ID on a new computer, you have to recall the answer to those security questions: the name of your first pet, where you were born. (That is cruel in its own right; if you don’t know then maybe you ought not be online at all!) But you get to configure the questions in following the web site rules. A configurable if not dynamic user experience should be the norm today. When a vendor “upgrades” an online function or even core functionality of an on premise product, it has to at least keep status quo with basic features/functions.
Recently, Google introduced some “enhancements” to its ubiquitous Gmail that a USA TODAY Tech columnist commented on. It bordered on “doing some evil” if not just being “cruel” for what a Gmail user wanted to do. The Labs function in Gmail or Calendar is a reasonable way to offer some new features, but the cool rule would be to let the user configure the experience.
There are rule-intensive systems that border on “life and death,” or if not the latter, then “health.” Electronic Medical Record (EMR) Systems are based on essential rules so that proper care is provided, treatment and test results recorded in one place and lives made healthier. But who authors the rules? How are the rules adapted to specific deployments of the EMR? Here is a real life example of how the inability to configure rules can have a profound impact on the customer (here patient) experience.
Cruel rules: a person just had a very difficult spinal tap procedure. Three rules governed the post-op: 1) blood work right after the procedure; 2) drink a Coke! (no really; for a Coke lover a cool rule (it could be Pepsi as well so a “configurable” rule!); 3) pretty immediately lie down for at least 8 hours. But another EMR rule was the attending physician had to certify that the procedure was done before blood work. The lab orders could not be produced. The physician was on vacation that day. The EMR did not have a secondrule as to how somebody else could fulfill the first rule. So the patient sat in a waiting room as IT was called. This quickly became cruel.
Finally, IT called and reported that they got in contact with the ISV for the EMR and were told that “those permissions for the EMR site to set rules for who could change rules would be in the next release; we’ll have to Webex into your system to provide a work around. But the new release will only let IT change those rules.”
Insult to injury? When the patient returned several days later to get test results, the physician reported with great frustration that upon her return from vacation, she had been locked out of all her patient’s EMR information. The physician astutely observed that “it would have been so much better for me to designate another doctor to handle cases such as this, just like it’s so easy for me to set an OOO status in my email. That would be cool compared to the borderline cruel rules in this EMR.” Really, her words. She was apologizing for rules that were not configurable.
Oh, it got even more cruel: the patient asked about personal access to the EMR saying “my primary care provider provides all my information in a portal (sponsored by a healthcare industry leader, Allscripts). I can even set a rule for you to log in and see my information so you can easily coordinate care with him.” The physician said “that is really cool, sign me up!” She was given access right there on the spot. The patient configured the rules for who accessed his EMR data. Cool.
It of course begged the question: when would her hospital’s EMR allow for that? She reported in a subsequent email to the patient that “IT said the vendor had a full portal planned for a future version. Until then our security group has rules that prohibit outside access to the EMR and the vendor has not provided a way for us to adjust the EMR web service rules to make it happen.”
The “easy” solution ? Embrace the theme of this blog– thinking in rules. Allow subject matter experts to manage their own rules. Use rules to configure software, rather than code to customize it. Make business user ownership of configurable decision logic and rules for customer- facing applications an architectural requirement.
Oh my…. my bank just sent me an email telling they have a new rule when I login. I will have to always answer a security question, not just provide a password. And the bank will provide the questions I can choose from. Now if I can just remember the name of my second grade teacher…….
Rules may have just gone from cruel to dumb.