Blog

Author Archive

Using AWS with HIPAA-Protected Data – A Practical Primer

When we started building the Wellpepper platform four years ago, we thought carefully about how to build for privacy and security best practices as well as HIPAA compliance, since we work with customers in the healthcare industry. We chose to build the system entirely on Amazon Web Services (AWS), and learned a few things in the process about building HIPAA compliant applications on AWS. Hopefully this will be helpful to others considering AWS as the home for their healthcare online service, whether you’re a software company hoping to sell to healthcare systems (as a “Business Associate” in HIPAA terminology) or an internal development team at a health system (a “Covered Entity”).

It’s Not Rocket Science

As you probably already know, the Health Insurance Portability and Accountability Act (HIPAA) is made up of several parts. Usually when IT people talk about “HIPAA compliance”, they are talking about the Title II Security Rule which governs privacy and security practices for electronic protected health information (ePHI).

Many of the requirements in the HIPAA Security Rule are simply best practices for security and data privacy that have been written into law. Things like encrypting traffic travelling over a network. Anyone building good, secure software, should be following these principles anyway. You need to be informed of the requirements, and you need to make sure you establish ongoing practices for maintaining security and privacy, but it’s not rocket science. In fact, your health system (or healthcare customers) may actually have more stringent or additional data security requirements to what is required by HIPAA.

Our experience is that HIPAA isn’t a major departure from what we would have built anyway.

Stay Up To Date

HIPAA was established in 1996, with the final Security Rule being published in 2003. In some cases, the guidance has not kept up with current threats and practices in 2017. If you are developing healthcare software, you should be applying industry best practices in combination with the HIPAA requirements. Your ultimate goal needs to be protecting patient data, not just regulatory compliance. Invest in training yourself and your team and staying current. Some resources we found helpful:

Take Responsibility

Compliance usually isn’t at the top of an engineering team’s list of fun things, so it’s tempting to look for solutions that can abstract away the responsibility. There are a few online healthcare platform-as-a-service hosters that make claims in this direction. Be wary of these. No service can remove your responsibility for compliance.

We decided that using AWS infrastructure services was the best level of abstraction. This let us build new services, host data, and install 3rd party applications in our VPC with high confidence that we were living up to our promises to protect patient data.

In addition to thinking about your software solution, compliance also covers your business practices and policies for things like training, background checks, and corporate device security – securing your people. These are often overlooked areas that are really important, since security researchers complain that people are the weakest link in the security chain. As with your software design, the application of commonsense practices and good documentation will go a long way.

There is no single group that certifies systems as HIPAA compliant. However, HHS can audit you at any time, whether you’re a covered entity or a business associate. You should do your own internal assessments against the HIPAA Security Rule both when you are building new capabilities, and on an annual basis. Augment this with external third party reviews. You’ll want to be able to show summarized reports of both your internal process and a stamp of approval from an external auditor.

HHS produces a tool called the SRA tool which you might find useful in performing security rule assessments: https://www.healthit.gov/providers-professionals/security-risk-assessment-tool. We used this for a couple years, but now just use an Excel Spreadsheet to evaluate ourselves. Bonus: this is probably what your auditor will want to see.

This Risk Toolkit from the HIPAA Collaborative of Wisconsin is a good starting point, and looks very similar to the spreadsheet we use: http://hipaacow.org/resources/hipaa-cow-documents/risk-toolkit/ (look at the Risk Assessment Template).

Share the Responsibility

AWS certifies a subset of their services for HIPAA compliance. This includes restrictions on how these services are used, and requires that you enter into a Business Associate Agreement (BAA) with AWS. This agreement establishes the legal relationship needed to handle ePHI, and ensures that you’ll be notified in the unlikely event that there is a data breach.

When you sign a BAA, you enter into a shared responsibility model with AWS to protect ePHI. AWS largely covers physical security for their facilities and networks. You can view their SOC audit results on request. You own the security for your applications and anything else from the OS on up. For example, if you use Elastic Compute Cloud (EC2) instances, it’s your responsibility to keep those instances patched.

AWS occasionally adds new services to their HIPAA-certified services, so you’ll want to check occasionally to see if there are new services you might be able to take advantage of.

Draw a Bright Line Around Your ePHI

At any time, you should be able to quickly say exactly which parts of your system (which servers, which network segments, which databases, which services) have or store ePHI. These systems are inside your bright line defense perimeter, are subject to HIPAA regulations including breach notifications. That means if you lose data on one of these systems, you need to notify your patients (or if you are a Business Associate, notify the Covered Entity so that they can notify the patients).

EC2, Simple Storage System (S3), Elastic Load Balancing (ELB), when used in accordance with guidelines can be HIPAA compliant. Make sure you read the guidelines – there are usually certain restrictions on usage in order to be covered. Many of AWS’ platform-as-a-service offerings are currently not offered under the AWS HIPAA umbrella (for example Kinesis and Lambda). You can still use these services, just not with ePHI.

Many modern systems designs make use of 3rd party framworks and SaaS offerings for things like analytics, monitoring, customer support, etc. When you are holding and conveying ePHI, you will need to be careful about which dependencies you take. For example, in one of our recent product updates we were considering using an external web & mobile analytics platform to better understand our traffic patterns. We walked through our use cases and decided that while none of them required us to send any ePHI to the analytics platform, the risk of accidentally sending some piece of protected data was too high. So we came up with a different plan that allowed us to keep PHI within our safe boundary and under our direct control. Many of your decisions will be grey-area tradeoffs like this.

Secure at Rest and Over the Wire

This is often the first question we see on any healthcare IT security review. How do you protect data at rest and over the wire? Use strong SSL certs with robust SSL termination implementations like ELB. If you terminate your own SSL connections, they need to be well patched due to evolving threats like Heartbleed, POODLE, etc. You may choose to do further application-level encryption in addition to SSL, but SSL should usually be sufficient to satisfy the over-the-wire encryption requirements.

For at-rest storage, there are many options (symmetric/asymmetric) that will depend on what you are trying to do. As a baseline, AWS makes it incredibly easy to encrypt data with AES-256 both in S3 or in the Elastic Block Store (EBS) drives attached to your EC2 instances. There’s almost no reason not to use this, even if you are using additional encryption in other layers of your architecture. AES-256 is usually the “right answer” for IT reviews. Don’t use smaller keys, don’t use outdated algorithms, and especially never try to roll your own encryption.

Good guidance in this area is easy to find:

Logging and Auditing

A key HIPAA requirement is being able to track who accessed and changed patient records and verify the validity of a record. Even if you don’t make this available through a user interface, you need to log these actions and be able to produce a report in the case of an audit or a breach. Keeping these logs in encrypted storage in S3 is a good way to do this. You’ll want to restrict who has access to read/write these audit logs as well.

In addition to automatic audit trails generated by your application-level software systems, remember to carefully keep track of business-process events like granting someone access to a system or revoking access. AWS CloudTrail can help track system changes made to AWS resources like servers, S3 buckets, etc.

Authentication

All healthcare applications will need a way to identify their users and what permissions those users have. HIPAA is not specific about authentication systems beyond being “reasonable and appropriate” (164.308(a)(5)(ii)(D)), but does require that you have good policies in place for this. Here you should follow well-established security best practices.

For starters, you should try not to build your own authentication system. In purpose-built systems, you may be able to integrate into an existing authentication system using oAuth, or SAML (or maybe something more exotic if you’re plugging into some legacy healthcare application). In patient-facing applications, you may be able to integrate with a patient portal for credentials – this is something that will probably show up on your requirements list at some point anyway. If neither of these apply, you may be able to use another identity provider like AWS’ Identity and Access Management (IAM) system to manage user credentials. We briefly tried using consumer-facing oAuth using Facebook, but quickly found that consumers are (rightly) worried about privacy and chose not to use this method.

If you find that you need to build an authentication system, be sure to follow current best practices on things like how to store passwords securely, as well as other tricky areas like password resets.

Since Wellpepper is often deployed standalone before being integrated into other back-end systems, we offer a built-in username + password authentication system. One silver lining to building this ourselves is the ability to build meaningful password complexity rules, especially for patients. Some of the traditional healthcare systems have truly draconian rules that are not only user un-friendly, but actively user-hostile. Thankfully, the best practices in this area are changing. Even the draft NIST password recommendations, updated in August 2016, trade some of the human-unfriendly parts of passwords (multiple character classes) for more easily memorable, but still secure ones (length). Also, consider the difference between health-system password requirements for clinicians with access to thousands of records and those for patients who only access a single record.

Once your users are authenticated, they will need to be authorized to access some set of resources. As with authentication, if you can delegate this responsibility to another established system, this is probably the best approach. If you are adding unique resources with unique access control rules, you will need to make sure that your authorization mechanisms are secure and auditable.

Conclusion

Creating a HIPAA-compliant service doesn’t have to be a big scary problem, but you do want to make sure you have your ducks in a row. If you’re reading this blog post (and hopefully others!), you’re off to a good start. Here are some additional resources that we found handy:

Posted in: Data Protection, Health Regulations, Healthcare Policy, Healthcare Technology, Uncategorized

Leave a Comment (0) →

Decreasing the Patient Survey Burden for Total Joint PROs

At Wellpepper we believe strongly about the value of patient-reported outcomes, especially when they are delivered as part of the patient care plan. However, the recent trend towards collecting PROs for reimbursement, plus HCAHPS and other surveys can result in some over-surveying of patients. We were pleased to hear at AAHKS that there is a movement to decrease the number of questions for total joint replacement with a proposal of using a HoosJr and a KoosJr. Outcomes-mobile.screen3

The HOOS and KOOS surveys are standard, validated survey instruments that are commonly used for measuring hip and knee function. We’ve heard that CMS is moving towards requiring these measures for evaluating outcomes of TJAs and other surgical procedures. A group of surgeons representing the major American orthopedic associations (American Association of Hip and Knee Surgeons, the American Association of Orthopedic Surgeons, The Hip Society and The Knee Society) has recently proposed shortened version of these surveys to lower the patient data collection burden. Details were presented at the 2015 AAOS and AAHKS conferences. These shortened versions are being called HOOS Jr. and KOOS Jr. Note that these are different than the lesser-used HOOS-PS and KOOS-PS physical short form surveys. The updated surveys are designed to be used standalone or in combination with a general health survey like VR-12, or PROMIS 10 Global. The number of questions is reduced from 40 to 6 (for HOOS) and from 42 to 7 (for KOOS), while retaining reliable, responsive output scores. With a patient completion time of under 3 minutes, these shortened surveys should dramatically aid in increasing survey response rates. Wellpepper supports HOOS and KOOS today, and looks forward to supporting HOOS Jr. and KOOS Jr. as soon as scoring rules are released.

Posted in: Health Regulations, Healthcare Technology, Outcomes, Patient Satisfaction

Leave a Comment (0) →

Best Practices in Healthcare Software Usability from the American Telemedicine Conference

BaltimoreA few weeks ago, Wellpepper took a road trip to the American Telemedicine Association conference in Baltimore. In addition to exhibiting and presenting at the venture summit, we also had the opportunity to attend a couple of the pre-conference sessions, which had some excellent content. In particular, one topic that we wanted to highlight was the Human Factors in Telemedicine session.

The session was presented by  Patrick Boissy, PhD, Neil Charness, PhD, and Elizabeth Krupinski, PhD. The focus of this session was on HCI (Human-Computer Interaction) and usability – some of the key tenets that we’ve held from the beginning while we built Wellpepper. Based on some of the healthcare-focused software we’ve seen, there is lots of opportunity here. It’s a shame the session wasn’t better attended, but in fairness it was also at 8am on a Sunday.

Dr. Boissy started by illustrating the importance of Human Factors Engineering with two case studies. First he examined Healthcare.gov. He pointed out many engineering failures that have been well documented in the press, the biggest of which was the limited end-to-end testing, which in some cases didn’t even happen until after the launch. Second, Dr. Boissy walked through a study by Desroches, C.M. et al (2013) on EHR adoption. Looking through the taxonomy of barriers to adoption, Human Factors issues are some of the most-cited barriers to technological acceptance of EHR systems. Essentially: doctors and nurses have trouble using the systems.

While EHR and EMR systems are certainly solving a difficult problem, there seems to be a cognitive disconnect in a world where you can go to an Apple Store and buy an iPhone that is easy enough for 2 years olds to use. If highly educated clinicians have trouble using Healthcare IT, what hope is there for the rest of us?

One theme that emerged throughout the morning is that usability is not something can be added on later – it’s infused throughout the software engineering process. This starts at requirements gathering, includes frequent iteration with user feedback, and may culminate in formal user-centric measurements of acceptance.

One practical technique that was shared is Contextual Inquiry – essentially sitting down with the user in a room, watching them perform tasks with prototypes or functioning software, and using this as an opportunity to understand the user’s thought process and conceptual model. It’s also a good opportunity to gather quantitative metrics like time-to-task, enabling you to measure improvements in your product as you iterate.

It’s a deceptively simple idea, but ever since I started using CI during my time at Microsoft, I can attest that it’s a wonderfully powerful technique that almost forces you to build user-centric products. At Microsoft, we had fancy usability labs with cameras, eye trackers, and one-way mirrors, but the technique can be applied simply, and frankly most effectively when you just get out and go visit users. Even just a few users can make a huge difference. I recall one time where my team and I had spent several weeks building a super-smart machine-learned recommender system, but when we put it in front of a user for the first time and gave them a task, they said something to the effect of “okay… but why do I want this?”. Back to the drawing board. This is actually pretty typical. As software professionals, regardless of how well we think we understand the problem, the first time we put a prototype in front of users, I’m never surprised to hear something that causes a big reset because it’s so easy to make false assumptions early on in the design process. One hint: always capture video when you do CI – it’s amazing how much depth you can extract from an hour-long conversation.

Dr. Charness went on to describe some of the specific challenges of building usable patient-facing healthcare solutions. He argued that even something as simple and pervasive as the pill bottle can be hostile to users, and is emblematic of the usability issues in healthcare IT. “Pill bottles seem fine when you have 20/20 vision, good fine-motor control, and are in a brightly lit office. But what about the diabetic patient who lives in a trailer with a single 60W lightbulb?” This is an area where pharmaceutical retailers like Target have been innovating.

Posted in: Healthcare Technology, Healthcare transformation, Telemedicine

Leave a Comment (0) →
Google+