Author: Ashish Datta

The following article is the first part of a series on HIPAA and its impact on certain industries in the United States. This piece aims to define HIPAA, identify 2019 HIPAA regulations and violations, and explain HIPAA compliance. Hopefully, this read will be informational, and especially useful, if you are unfamiliar with HIPAA and it’s applicability. The importance of HIPAA (Health Insurance Portability and Accountability Act) has recently hit the U.S. headlines as a trending topic. Particularly, the impact of HIPAA in the healthcare space has circulated throughout the U.S. media. HIPAA compliance recently became a point of emphasis when the United States government made changes to the act, and its surrounding enforcement, in 2019. While HIPAA was enacted over 23 years ago, the significance of this act has evolved as western society has become increasingly involved with- and dependent upon- technology. When initially implemented, HIPAA served to protect personally identifiable information maintained by healthcare companies.

2019 HIPAA Regulations and Violations

In December 2018, the OCR (Office of Civil Rights) issued a request for information to HIPAA covered entities. The OCR was specifically focused on the current Privacy Rule to confirm that HIPAA was not prohibiting, nor discouraging, any patients from proper care. To instill safety and protection over access to patient’s rights and information, the OCR plans to increase enforcement around the Privacy Rule. The OCR is also optimistic that emphasis on HIPAA compliance will help to fight the opioid crisis in the United States. Additionally, the OCR is concerned with the number of email data breaches due to the major problem of phishing in the healthcare industry. If a company is caught in a violation of HIPAA, or fails to comply, they can be faced with serious fines and even incarceration. To ensure that this does not happen, there are a few fundamental precautions healthcare companies can take to warrant compliancy.

Maintaining HIPAA compliance

To guarantee HIPAA compliance, the first preventive measure every company must take is training their employees on HIPAA compliance. By educating an organization on the dangers of using PHI information for personal benefit, the chance of an accidental HIPAA violation can be greatly minimized. It is crucial for healthcare companies to implement policies around the hardware and electronic services that they share with their business associates. To do so, risk management assessments can be performed on security and storage measurements. A majority of recent HIPAA violations have stemmed from the way patient data is being stored, additionally, there are release forms patients must be provided to sign off on the disclose the use of their personal health information. Some practices failed to distribute updated release forms. By administering mandatory notices, and operating with patient consent, in writing, a large portion of ambiguity and uncertainty around HIPAA compliance can be waived.

Industries Impacted by HIPAA

Over the past twenty years, medical records have been transferred from paper to wireless systems, enhancing the need for IT software and applications. As the demand for IT systems to collect and store data grows, the risk of cyber-attacks presents itself. Since data in the health industry is stored on servers, and not in a cloud, IT providers, as well as mobile application companies, also become liable. Some effective practices to prevent data hacking and fraud include: audits, encryption, data breach notifications, and a recovery plan. In regards to software development, some necessary features to consider are: access control, authorization, and backup data.

HIPAA Enforcement

Last year was a record year for HIPAA enforcement. With total fines and settlements reaching over 28 million dollars, healthcare companies have a lot to think about. Ultimately, it is critical to be educated on HIPAA and how to maintain HIPAA compliance. Whether it is negligence, lack of information, or an unfortunate security hack, even companies in cohesion with the health industry can be liable for a HIPAA violation. Stay tuned for our next blog post as we delve into HIPAA in our local sector of Boston, MA.

One of Setfive’s New Years Resolutions is to prioritize our internal marketing. In establishing online presence, an initial project included refreshing the @setfive Twitter following list. To do so, we built a list of target accounts that we wanted to follow and then started searching for tools to automate the following. After some research, it appeared the only existing tools were paid with weird, and “sketchy,” pricing models. So, we decided to look at using the Twitter API to implement this list ourselves.

As we started looking at the API, we learned you need to be approved by Twitter to use the API. In addition, you need to implement OAuth to get tokens for write actions on behalf of a user, like following an account. We were only planning to use this tool internally once, so we decided to avoid the API and just automate browser actions via Puppeteer. For the uninitiated, Puppeteer is a library that allows developers to programmatically control Google Chromium, which is Chrome’s open source cousin.

Puppeteer ships as a npm package, so getting started is really just a “npm install,” and you’re off to the races. The Puppeteer docs provide multiple examples, so, I was able to whip up what we needed in a handful of lines of code (see below). Overall, the experience was positive and I’d be happy to use Puppeteer again.

function followBot(params) {

    return new Promise(async (resolve, reject) => {
        const browser = await puppeteer.launch({headless: false});
        const page = await browser.newPage();

        await page.goto('https://mobile.twitter.com/login');

        await page.waitFor('[name=\'session[username_or_email]\']');
        await page.$eval('[name=\'session[username_or_email]\']', (el, params) => el.value = params.username, params);
        await page.$eval('[name=\'session[password]\']', (el, params) => el.value = params.password, params);

        await page.$eval('[data-testid=\'LoginForm_Login_Button\'', el => el.click());
        await page.waitFor('main');

        const accounts = fs.readFileSync("targets.txt", "utf8").split("\n");

        for(const account of accounts){

            console.log("Following " + account);

            await page.goto('https://mobile.twitter.com/' + account);
            await page.waitFor('.css-18t94o4');

            await sleep(1000);

            await page.$$eval('div', (elements) => {
                return new Promise(async (resolve, reject) => {
                    elements.forEach(f => {
                        if (f.getAttribute("data-testid") && f.getAttribute("data-testid").indexOf("follow") > -1) {
                            f.click();
                        }
                    });

                    resolve(true);
                });
            });

            await sleep(5000);
        }

        resolve();
    });
}

So why would Puppeteer be interesting to your business?

In 2019 APIs are popular, many business provide access to data and actions through programatic means. However, not all of them do and that’s where Puppeteer provides an advantage. For example, many legacy insurance companies only provide quotes after you fill out a web form, which normally, you’d have to complete manually. If you automated that process with Puppeteer, you’d be able to process quotes at a much faster rate. 24 hours a day, and give yourself a competitive advantage against your competition.

Have you ever tried anything other than JavaScript or Typescript for front end and what was the result?

I tried Scala.js a couple of years ago, before TypeScript was popular. The results were mixed, at best. My experience was not recent, but, if I recall correctly, my two biggest stumbling blocks were tooling support and interop with standard JavaScript libraries.

On the tooling side, the major challenge was that scala.js needs to be compiled via the JVM based Scala compiler in order to produce JavaScript. That made integrating with JavaScript build tools like Gulp or Grunt fairly difficult. On top of that, I was sort of stuck writing scala.js in Eclipse since it had the best Scala plugin support. What that meant is that I had to give up IntelliJ’s awesome web development capabilities.

Integrating with third party libraries is a struggle for all of the “compile to JavaScript” solutions. A few years back, scala.js had a pretty rough integration story. Scalajs still relies on typed “facades,” Write facade types for JavaScript APIs to for integration. The problem faced is that there is not “any” type of Scala where you can skirt needing actual type information. These two issues highlight how well TypeScript is implemented in regards to tooling and 3rd party library support. Today, (2019) I think it that TypeScript is really the only effective option for compiling to JavaScript.

At the beginning of last year we tried something different and deployed an application on Amazon’s Elastic Container Service (ECS). This is in contrast to our normal approach of deploying applications directly on EC2 instances. So from a devops perspective using ECS involved two challenges, working with Docker containers and using ECS as a service. We’ll focus on ECS here since enough ink has been spilled about Docker.

For a bit of background, ECS is a managed services that allows you to run Docker containers on AWS cloud infrastructure (EC2s). Amazon extended the abstraction with “Fargate for ECS” which launches your Docker containers on AWS managed EC2s so you don’t have to manage or maintain any underlying hardware. With Fargate you define a “Task” consisting of a Docker image, # of vCPUs, and amount of RAM which AWS uses to launch a Docker container on a EC2 which you don’t have any access to. And then naturally if you need to provision additional capacity you can just tick the 1 to 2 and AWS will launch an additional container.

The Setup

Reinforces cattle, not pets

There’s a cloud devops mantra that you should treat your servers like a herd of cattle, not the family pets. The thinking being that, especially for horizontally scalable cloud servers, you want the servers to be easy to bring up and not “special” in any way. When using EC2s you can convince yourself that you’re adopting this philosophy but eventually something will leak through. Sure you use a configuration management tool but during an emergency someone will surely manually install something. And your developers aren’t supposed to use the local disk but at some point someone will rely on files in “/tmp” always being there.

In contrast, deploying on ECS reinforces thinking of individual servers as disposable because the state of your container is destroyed every time you launch a new task. So each time you deploy new code a new container will be launched without retaining any previous state. At the server level, this dynamic actually makes it impossible to make ad hoc server changes since it’s impossible to SSH to your ECS so any changes would have to present in your Dockerfile. Similarly at the app level since your disks don’t persist between deployments you’d quickly stop writing anything important just to disk.

Logs are...challenging

When using Fargate on ECS the only way to access output from your container is through a CloudWatch log group through the CloudWatch UI. At first look this is great, you can view your logs right in the AWS console UI without having to SSH into any servers! But as time goes on you’ll start to miss being able to see and manipulate logs in a regular terminal.

The first stumbling block is actually the UI itself. It’s not uncommon for the UI to be a couple of minutes delayed which ends up being a significant pain point when “shit is broken”. Related to the delays, it seems like sometimes logs are available in the ECS Task view before CloudWatch which ends up being confusing to members of the team as they debugged issues.

Additionally, although the UI has search and filtering capabilities they’re fairly limited and difficult to use. Compounding this, there frustratingly isn’t an easy way to download the log files locally. This makes it difficult to use common Linux command line tools to parse and analyze logs which you’d normally be able to do. It is possible to export your CloudWatch logs to S3 via the console and then download them locally but the process involves a lot of clicks. You could automate this via the API but it feels like something you shouldn’t have to build since for example the load balancer automatically delivers logs into S3.

You'll (probably) still need an EC2

The ECS/container dream is that you’ll be able to run all of your apps on managed, abstract infrastructure where all you have to worry about is a Dockerfile. This might be true for some people but for typical organizations you’re probably going to need to run an EC2. The biggest pain points for us were running scheduled tasks (crontabs) and having the flexibility to run ad hoc commands inside AWS.

It is possible to run scheduled tasks on ECS but after experimenting with it we didn’t think it was a great fit. Instead, the approach we took was setting up Jenkins on an EC2 to run scheduled jobs which consisted of running some command in a Docker container. So ultimately our scheduled jobs shared Docker images with our ECS tasks since the images are hosted by AWS ECR. Because of this, the same CircleCI build process that updates the ECS task will also update the image that Jenkins runs so the presence of Jenkins is mostly transparent to developers.

Not having an “inside AWS” environment to run commands is one of the most limiting aspects of using ECS exclusively. At some point an engineer on every team is going to find themselves needing to run a database dump or analyze some log files both of which will simply be orders of magnitude faster if run within AWS vs. over the internet. We took a pretty typical approach here with an EC2 configured via Ansible in an autoscale group.

Is it worth it?

After a year with ECS+Fargate I think it’s definitely a good solution for a set of deployment scenarios. Specifically, if you’re dealing with running a dynamic set of web frontends that are easily containerized it’ll probably be a great fit. The task scaling is “one click” (or API call) as advertised and it feels much snappier than bringing up a whole EC2, even with a snapshotted AMI. One final dimension to evaluate is naturally cost. ECS is billed roughly at the same rate as a regular EC2 but if you’re leaving tasks underutilized you’ll be paying for capacity you aren’t using. As noted above, there are some operational pain points with ECS but on the whole I think it’s a good option to evaluate when using AWS.

Last week my girlfriend Diane was looking for some help scraping pollen data from a couple of sites. The code was simple enough to hammer out but how was I going to deliver it? Diane is fairly tech savy but even so asking her to install nodejs and run a command line app was going to be a bit much. After considering options like a Java Swing app or Qt+nodejs I decided to give Electron a shot. Just want to see the code? It’s available here, pollen-scraper.

Electron is a cross platform application runtime which basically “runs” code inside a Chrome browser alongside nodejs. In practice you can use nodejs libraries with your favorite JavaScript framework too build applications that run anywhere that Chrome will. Several popular companies including Slack and Spotify have desktop clients powered by Electron. Pretty much perfect for my use case. So what was using Electron for the first time like?

Getting started is easy

The NodeJS ecosystem

Debugging

All in all, my first foray with Electron was a pretty positive experience. With a couple of beers and an afternoon of work I was able to deliver a cross platform application which saved my girlfriend’s team a dramatic amount of time.