Incomplete Regression Testing = Production Defects
Skype pushed out a new release last week to Mac users. (According to their blog, they also apparently pushed out a “preview release” to Windows users, but I don’t know if they are affected by the bug I found.)
Like any software team, the Skype team does this on a regular basis. This time, they failed to adequately test, so they introduced a production defect that I found.
In this case, the defect involves the Skype workflow for blocking a spammy contact request, like this real example from my Skype session this morning.
(That these bogus connection requests are a regular occurrence in Skype could be a whole post in itself about the hazards of feature decisions.)
The basic workflow is to click on the “Block” button, then answer the pop-up dialog to confirm this. In that dialog, one can also check the “Report abuse from this person” option as I have done in this example.
In the case of this Skype defect, clicking the “Block” button on in this dialog box does briefly show that “honey.innes” is blocked–until Skype crashes, which opens up Apple’s “crash report” screen like this (click to see a larger image):
After dealing with this crash screen, a new dialog opens up when Skype is re-launched so they can collect their own crash reports:
got patient safety?
Yes, Virginia, this is a minor problem (as far as I know at this moment) that can be worked around easily by ignoring this contact request until Skype pushes out a new release with their defect correction. I use Skype as a vital link to my extended team of internal and external collaborators, so it is an important tool to me, but it is not managing sensitive data like patient information.
But what if it did?
What if this defect was in my hospital’s EHR? What if the bug caused that EHR to sent the wrong person’s drug information to another hospital?
This is not a far-fetched scenario. Patient matching is one of the toughest things to get right in health information exchange, so a defect introduced during a software version release process could easily result in the wrong patient’s information being transmitted.
How would you like it if your patient died from an adverse drug interaction because your EHR vendor tests only as well as Skype?
Losing a patient is always a tragedy, but I cannot imagine the unspeakable horror of a situation like this–especially because 30 minutes of testing could easily prevent it.
Interoperability: got proof?
Calling all healthcare CIOs: The next time you talk to your EHR vendor team, ask them about interoperability. The same thing goes for your other vendors who offer tools and infrastructure to provide interoperability.
Demand proof of interoperability. Think of it as “proof of life.”
If your vendors cannot provide you proof that–during each release cycle–they test to definitively validate (i.e., prove) that their system retains its ability to safely exchange your patients’ health information, I recommend you drop everything and go see your most senior legal team, because your organization has an existential problem.
To not act decisively in this situation–to allow your vendors to continue to ignore their responsibility to deliver fully tested software–is to place your patients at risk.
If you don’t have proof of continuous interoperability, call your lawyer. NOW.
I’ll close with my best wishes that you never have a morning with your EHR infrastructure like I had with Skype. 😉