“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.

You Need to Read – “What is Code?” By Paul Ford

Two weeks ago, the Wall Street Journal’s recommended weekend reading list included an opus by Paul Ford published on Bloomberg. You can find it here: http://www.bloomberg.com/graphics/2015-paul-ford-what-is-code/ warning – it’s not a short read.

Anyone working in health care who is not in IT should read this article, and anyone who works in the health care compliance, legal or governance spaces needs to read this article, in my opinion. Here’s why:

– Our technology runs largely on old code. Most information systems that power health care transactions are not running in the new, “sexy” languages, like Ruby. This makes it harder to find new coders who are proficient in the languages that need to be maintained. Older code langauges are also harder to work with to create what users want, leading to systems being used today in ways for which they were not intended or optimized to perform.

– Our industry has strict requirements for use of encryption and data security, but the tools we have to assure those requirements are imperfect. The code libraries that execute the encryption have been contributed to by many coders over time, and there could be a / or } in the wrong place buried at the very heart of the code creating a security flaw, but because of programs layered on top of each other no one has noticed.

– Healthcare has to use technology to collect patient information, maintain that information, and share it with those who need it (including doctors, nurses, quality reviewers, insurance companies, to name a few), while keeping it encrypted and logging user access. A stolen patient record is said to be worth anywhere from $50-70 on the black market (h/t to The Advisory Board Company for including that in a Daily Briefing email recently).

It’s important to remember that while HIPAA regulations require security audits and that encryption is used, there is no specific language setting a minimum standard for encryption. In part, I suspect this is because standards evolve so fast, today’s best practice “brick wall” equivalent is tomorrow’s “decorative white picket fence that won’t actually keep a bunny out of your vegetable garden”.  That’s no justification for poor security or encryption efforts.

My key take-away is to expect technology to continue to change. In healthcare leaders must balance making technology easier for nurses and doctors to use for patient care, and security of the technology.  At the end of the day, your technology is worse than worthless if not encrypted.

Hello world!

I am starting this blog as a place to share my perspective as a Michigan State University College of Law student on regulatory updates and other articles of interest in the health care space.  All thoughts are my own, and should not be taken as legal advice.