“What is Code?” Review Part Two

In my last post I told you why you need to read, “What is Code” by Paul Ford.  The following is what I feel most critical of Ford’s article for a compliance or legal leader in health care to read:

5. The Time You Attended the E-mail Address Validation Meeting

In the interest of understanding more about how all this works, and with an open invitation from TMitTB, you attend a meeting of the programmers.

Two of them are late, and bravely you ask the one already in attendance to explain what’s going on. He quickly gathers the limits of your information through a series of questions, beginning with, “Do you know what a Web page is?”

Here’s what he shows you: To gather an e-mail address and a name, you can make a Web page using HTML.

On today’s agenda: How to make sure that registration is a positive experience for users but also a secure experience for the company. The questions to be discussed, the programmer tells you, are along the lines of, “Where will you put this data? Will you put it in a text file? What will you do with it? How will you act upon it?”

What follows is an illustration of a conversation between hypothetical programmers. In the again-hypothetical website upgrade in Paul’s article, the questions can be resolved through choosing to create the site update in a language that will include scripted answers for all of these questions.

This is critical because most healthcare companies aren’t writing their own code or creating their own software.  They’re purchasing a software package or a subscription to a software hosted through the Internet from another company.  You then become reliant on that company having resolved these questions in advance, and having answered them in a way that meets your risk profile. Your IT people will have to figure out, after implementation, if there are issues with the software, such as duplicate accounts, lack of data validation, if all the passwords are hashing to an unencrypted text file…  And now it’s your data in play. All of these examples are things that really do and have happened.

Healthcare compliance professionals and compliance lawyers who understand the limitations of software can ask better questions during the software demonstration. Assure that your information security officer has reviewed the program under consideration.  Asking hard questions up front can prevent being in a hard place later, when it’s real patient, employee, or provider data on the line.