We addressed a small UX issue in our dashboard application this week. A
blog-post-worthy UX issue? Not really. Transparency in the process of how
we address issues however, can greatly benefit our customers and their
experience with our products.

Aptible is an application deployment platform built to automate HIPAA compliance
for web and mobile technology. We have a web-based
dashboard application
to aid customers in managing their organization, access controls, and ops.
It is built with EmberJS, an open source JavaScript
application framework.

Contributing to the EmberJS community motivated our decision to open source
the dashboard. Often available applications are small and optimized for
evaluating the framework quickly. Sharing our production application builds on
the many smaller examples and helps answer bigger questions around code
organization, utilizing components, and test coverage.

We use a copy-to-clipboard action throughout the app for
long strings that a user would likely need to paste in a terminal
(database connection strings, git commit references, links, etc.).

A user reported some confusion via one of our support channels when the
click-to-copy link reloaded their browser.
A github issue
was created and diagnosed the root of the problem. In browsers without Flash,
the component was not set up and a link with a common placeholder destination,
triggered the reload.

1

<a href="#">Copy</a>

Because the dashboard is open source, anyone with a free github account can
create, comment, and follow issues. A new open source tool,
clipboard.js, was noted as a
possible solution. It does not use Flash and offers a nice fall-back for
unsupported browsers to get targeted text on the clipboard. Note, the tool’s
creator, zenorocha chimed in with a
+1 and a wink. Feel the open source github love!

The click-to-copy component used in the dashboard is part of our shared library,
ember-cli-aptible-shared,
also open source. After making changes to the component, we updated the
dashboard, and problem solved!

This is the second in a series of blog posts exploring the state of the digital health landscape from a technical perspective. Our first post on popular languages has already proven to be one of our most read blog posts. If there are other analysis you would like to see on the state of digital health, please get in touch

One of the things we have noticed in working with a variety of digital health companies is that there is much more willingness to explore database technologies when architechting a new application. While developing in a new language typically takes a serious investment and will greatly slow initial progress, a different database variant may present lots of benefits with a minimal learning curve. As such, I expect we’ll see some interesting trends emerge as we repeat this survey over the coming months and years.

For this survey, we examined the database layer for applications deployed on Aptible. The pupulation of databases is limited by what Aptible (and AWS) support. That said, we are very quick to add support for any database requested by users.

As this is the first time we have collected this data, we can’t make any definitive claims about trends. However, DB-Engine is a great source for trends in database popularity. Their methodology, however is much squishier than our directly measured metrics.

DB-Engine October 2015 Ranking

1

Oracle

2

MySQL

3

Microsoft SQL

4

MongoDB

5

PostgreSQL

6

DB2

7

Microsoft Access

8

Cassandra

9

SQLite

10

Redis

The most interesting difference in these lists is with Redis. The Aptible data is based on web and mobile applications while the DB-Engine list is based on a much broader variety of factors. So Redis may make more sense for the types of applications currently “hot” in the health tech world. It’ll be interesting to see how the list changes and whether the Aptible list is a leading indicator of rapidly growing Redis popularity.

This is the first in a series of blog posts exploring the state of the digital health landscape from a technical perspective.

Working exclusively with companies in digital health, we are regularly asked about technical trends. One common question is, “What types of languages and frameworks do you see the most?” As a deployment platform for nearly 100 (as of October 2015) digital health companies with over 550 deployed applications, we have some interesting data.

For this survey, we examined the primary language for apps deployed on Aptible. We have tried to only include primary production apps and exclude any helper or logging apps (e.g., the ELK logging stack is a popular utility to run on Aptible, but doesn’t tell us much about the main app.) Finally, of course, these data only represent apps deployed on Aptible, so ASP.NET-specific languages are not represented.

As this is the first time we have collected this data, we can’t make any definitive claims about trends. There are other sources of data for the general tech community, such as RedMonk’s survey on popular programming languages and BuiltWith’s Framework Usage Statistics.

RedMonk Language Ranks

1

JavaScript

2

Java

3

PHP

4

Python

5

C#

6

C++

7

Ruby

8

CSS

9

C

10

Objective-C

11

Perl

12

Shell

13

R

14

Scala

15

Go

BuiltWith Top 10k - Frameworks

1

PHP

2

ASP.NET

3

J2EE

4

ASP.NET Ajax

5

Ruby on Rails Token

6

Shockwave Flash Embed

7

Ruby on Rails

8

ASP.NET MVC

9

Adobe Dreamweaver

10

Classic ASP

11

Adobe ColdFusion

12

Express

13

DAV

14

Django CSRF

15

Telerik Controls

Ruby and JavaScript dominate the Aptible sample, which makes sense because Aptible is used primarily to deploy web apps and mobile APIs. PHP is also popular, as it is on the open web. Java and PHP are used less frequently on Aptible than on the open web. To speculate, this may be because many Aptible apps were built recently, whereas top 10k sites may be older, with more legacy code.

Slides:

We’re proud to announce our role in the world’s first population health study focused on gay and transgender men and women.

PRIDE Study

Spearheaded by researchers at the University of California - San Francisco, the LGBTQ-focused study is called PRIDE. Researchers’ ultimate goal is to build the largest LGBTQ health database in history so that medical professionals have the proper tools to address the physical, mental and social issues exclusive to gender and sexual minorities.
For example, 33% of the LGBTQ community are smokers, a rate far higher than the national average. While scientists speculate this statistic means that more of these community members die from cancer and other smoking-related diseases, there is no official data to back these theories.
Needing a way to gather loads of sensitive information quickly and efficiently, PRIDE leaders reached out to the tech world, and we of course responded with innovation.

PRIDE App

The first contribution to the UCSF study was ThreadResearch’s iOS app, aptly named PRIDE. Employing the newly-released Apple ResearchKit, the app collects public health data using iPhones.
Prompted to answer questions about their health history and concerns, LGBTQ participants will inform the longer-term PRIDE study, which kicks off in January of 2016.

Our Role

To ensure this private information remains secure, we’re powering a streamlined HIPAA- and IRB-compliant platform behind the scenes of PRIDE.
Our CEO, Chas Ballew, says, “The UCSF PRIDE study is a great example of the changing face of health tech. Smart phones and cloud-based data collection are just now becoming viable solutions in the tightly regulated health-data world. We’re excited to be pioneers in this fast-growing technology.”
Confident that their private information is protected under our prudent watch, researchers and study participants alike can now move forward into realms of medical advances that have never before been explored. And hopefully the fresh strategies developed by physicians will make a dent if not eradicate issues that have long plagued this misunderstood field of medicine.

This week we teamed up with AWS and TelePharm to talk about architecting for HIPAA compliance in the cloud:

Slides:

More questions from the audience:

Does data that is stored long-term in RAM (in Redis, for example) need to be encrypted, or does it only need to be encrypted when persisted to disk? Does HIPAA require that data within a VPC be encrypted? Is data considered encrypted at rest on EBS if the instance is still running?

HIPAA has no specific mandatory requirement that data be encrypted, but regulated entities must take “reasonable and appropriate” measures to safeguard PHI. Whether data is encrypted at the point of breach depends on how a potential breach occurs. It may be more helpful to take a risk-based approach, breaking potential threats into categories and asking: How likely is an attack to be attempted? How likely is it to succeed? What impact to PHI would result?

The Aptible compliance platform helps customers analyze risk using SP 800-30 Revision 1, a federal methodology developed by NIST in collaboration with the Department of Defense and the Office of the Director of National Intelligence.

How do Aptible databases work?

Databases are built from standardized images and run in private subnets, inaccessible from the outside Internet. We attach encrypted storage volumes and make nightly encrypted backups.

If a deployment needs to be available in Europe as well as in the US, who is responsible for where the data is stored and how PHI data flows across regions?

Aptible customers define environments for apps and databases. Those environments run in discrete geographic AWS regions that you specify. Communication across regions is routed over the Internet. You can easily and clearly control the countries and legal jurisdictions where your data is stored and moves through.

How does Aptible manage data encryption on/through ELB?

We only pass encrypted data through load balancers. SSL/TLS is terminated on the EC2 instance. (See the webinar, around 24:47.)

I work for a national MSP. I’m a certified AWS Cloud Solution Architect. I have a customer in the healthcare vertical that would benefit from moving certain workloads to AWS. Is Aptible willing to partner?