I get a story that says, "As a user, when I press the H key I want a horn to play." And I go into the planning meeting and ask, "Is this like a bike horn?" And they say yeah! And I ask, okay, so when I press the key, do you want the horn to sound on key down, or key up? And they say, "How about it starts playing on key down, and stops playing on key up?" And then I say, "do you want different volumes, for let's say when they are on their bike and just want to politely let someone know they are there, versus when they're about to get hit by a truck?" And they say, "yes, eventually, but being able to play the horn at different notes is a higher priority." And then I ask, "wait, why is that useful for a bike horn?" And then they explain that they're going to be playing the horn as part of an orchestra. And then by the end of the conversation I realize the horn I'm implementing is a French horn midi keyboard, not a bicycle horn traffic signal, and the requirements are completely different.

I don't really buy this idea that people are just writing single, isolated requirements out of context.

From TFA

>in exchange for implementing clinical decision support (CDS) alerts in its EHR software designed to increase prescriptions for their drug products.

When and how the software would display the CDS alerts would be discussed in a planning meeting; the logic of each individual CDS alerts would not, those would be handed down from somewhere else. Software engineers are in no position to be suggesting or discussing individual clinical decisions. Software engineers aren't going into a planning meeting saying "hey, what about suggesting scheduling a pap test if the patient is a female between 21 and 60 and there's no record of a recent test?" That's not in the software engineer's purview.

So there's very little doubt in my mind that the "suggest opioids if XYZ" CDS alert came down in a list of other innocent CDS alerts like "suggest pap test if XYZ" or "suggest mammogram if XYZ" or "possible drug interaction detected" or "tetanus vaccine due."

Of course there's also the possibility that the system was engineered so that the person configuring the software builds all the CDS alerts themselves with a drag-and-drop interface.

But anyway, sometimes you, as an engineer implementing the system, don't get to personally participate in requirements gathering, planning meetings, or interfacing with the end users. Depending on a lot of factors, sometimes that's done by pointy haired bosses at a much higher level. Especially if you're just a contractor or a subcontractor. I once worked on a project as a short term subcontractor (around six months), I was literally handed detailed requirements, including mockups of all the screens, and told "implement this." Of course, everyone had their own opinion on how it should work, but it was not open for discussion.

So I have absolutely no reason to believe that the programmers of this software knew about this nefarious kickback scheme but I have reason to believe that they probably didn't.

Boy am I glad I work for an EHR that doesn't agree with you... If I was asked to implement a CDS rule that wasn't based on some reasonable clinical guideline (CMS quality measures, etc) you'd better believe I'd push back on it and want to understand where it was coming from.

Healthcare isn't some dark art that engineers couldn't possibly understand. These rules should be based on publicly available and widely agreed upon standards of care.

Let’s not be naive. The list is big. But elements are incriminating. If you implement them, you are morally—and eventually, legally—responsible.