Blog

Posts Tagged HIPAA

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) →

The Case for Patient Video in Doctors Visits: Take a Selfie and Call Me In the Morning

The selfie culture and our desire to photo-document every aspect of our lives has started to influence healthcare as well, and patients want to be able to record their doctors visits. The concept is so prevalent that it’s making headlines in the mainstream media.

Patients Press the Record Button, Making Doctors Squirm” from the Washington Post

Why You Should Record Your Doctor’s Visits” from Forbes.

Having a recording of a visit ensures that you don’t miss any information, and you can review it when you get home and are able to provide more attention to the topic. Much of what is said in a doctors visit is missed by patients, by some accounts between 40 and 80% is missed, and an additional half of that information is remembered incorrectly. As we learned during a course from the Institute for Healthcare Improvement, often healthcare providers are not trained in making sure the message is received.

When we ask patients about their experiences, they tell us that they thought they understood the instructions but realized when they got home they really didn’t retain enough or understand enough to comply with the instructions. Patients are often intimidated by healthcare personnel, worried about wasting valuable visit time with questions, or worrying about how what their being told will impact their lives, for example, who will walk my dog when I have my hip replaced? Is it any wonder that the information isn’t landing?

Patient Record on Parking

Patient record in parking garage of major health system

When handout instructions are available, they are often forgotten by patients, or confusing. One healthcare organization we work with conducted an audit of all their patient handouts and discovered that they were at an 18th grade reading level. The recommended reading level for health information is fifth grade, and yet these instructions required a graduate degree!

Patients have a seemingly simple solution to this: record their doctors. Doctors on the other hand have been warned about PHI and HIPAA, so a common ‘workaround’ is to record patients on their own phones. Legal departments hate this because then the patient has a copy of their prescribed instructions but the health system does not. Liability aside, it doesn’t result in good care if everyone is not working off the same information.

Including patient video as part of a HIPAA compliant digital treatment plan is a great way to solve this problem. Patients have a better experience and the health system is able to keep good records.

Patient video can cueing or instructions that is unique to that patient, and they show the patient’s actual experience whether that’s in wound care, using a medical device, or physical therapy. Patients feel a greater sense of connection and accountability to care plans when they are personalized and customized.

For complex instructions like wound care, using medical devices and durable medical equipment, and physical and occupational therapy, patients feel more confident that they can repeat the exercise or instructions at home when they see video of themselves doing it.

There are so many benefits to including custom video as part of a patient’s care plan. The technology is here today, it can be delivered in a HIPAA compliant manner, and it can be stored and easily retrieved. The challenge is that while patients are ready for this, health systems aren’t and the answer is often ‘no’. The risks to the health system, if video is delivered as part of an overall digital patient treatment plan solution are low, but the potential benefits to care are large.

We’ve tracked the evolution of the ‘consumerization of IT’ through other industries. Some have said it can never happen in healthcare, but this is a great example where patients starting to push the envelope and use technology in their care. Let’s hope they are able to convince their doctors as well.

Posted in: Adherence, Health Regulations, Healthcare Disruption, Healthcare Policy, Healthcare Technology, Healthcare transformation, M-health

Leave a Comment (0) →

ResearchKit: The Tip of the Iceberg

In March, during the much-anticipated Apple Watch keynote, Apple carved out a few minutes to announce ResearchKit, a system to enable faster and easier healthcare research. The announcement was received positively, some even saying that the announcement was bigger news than the Apple Watch itself! Within a week, one of the early apps, MyHeart Counts, had enrolled 11,000-patients, an enrollment pace and efficiency unheard of in the healthcare community. Without a doubt, Apple has the opportunity to bring the power of numbers to healthcare.

What It Is

ResearchKit is an SDK (Software Development Kit) containing presentation logic and user interface components for gathering healthcare research data on an iPhone. It can gain informed patient consent, present surveys (whether existing clinically-validated surveys, or novel surveys for a particular study), and also use the sensors on the device to do things like measure vocal tremor, conduct a 6-minute talk test, and measure motor reaction time.

Building a new research app with ResearchKit-powered is a fairly standard mobile app development project. The ResearchKit components certainly accelerate the process, however you will still need an iOS developer, and you will need to follow all the usual software development steps of requirements gathering, design, implementation, stabilization, and then releasing through the App Store. The SDK was recently open-sourced on GitHub. Since most of the SDK relates to the user interface, ResearchKit really only helps with iPhone app development, which some have pointed out may give rise to a sample bias.

Image of an Iceberg

(Original source: National Ocean Service Image Gallery)

 

What It Is Not

More important than the development of the mobile app, though, it all of the infrastructure behind the app that allows the data to be securely transmitted, stored, aggregated, and analyzed by researchers. In systems of this kind, the scale and complexity of the underlying data service layer is usually considerably larger than the user-facing data collection app. This is especially true in healthcare, given the compliance overhead imposed by regulations like HIPAA.

On this dimension, ResearchKit has no immediate answer. Given Apple’s privacy-centric stance on data collection and aggregation and the sensitivity of the data, they are unlikely to build a cloud service offering for ResearchKit. As such, it will be up to individual researchers to build their own systems, at least until other software vendors move in to fill this need.

 

The Iceberg

Much like the proverbial iceberg where only 10% of the whole is visible, Apple’s ResearchKit is a beautiful, if small, slice of user interface that hides a large and complex underlying platform needed to actually deploy healthcare research apps.

 

 

 

Posted in: Healthcare Disruption, Healthcare Technology

Leave a Comment (0) →

The Connected Patient Is Here

After either a realistic or pessimistic Day 1 keynote, depending on whether you’re a glass half full or half empty kind of person, Day 2 at the MHealth Summit started with a difficult topic but a much more inspiring message and continued with presentations stressing that patients are already connected and engaged. A bonus for those of you who are counting (XX in Health, Halle Tecco), is that ¾ keynote speakers on this day were women.

Confronting Mental Illness Online

First up was Jen Hyatt (@jennyhyatt) CEO and co-founder of Big White Wall, and online community for mental health. Big White Wall provides an online community for people who are mentally distressed and sometimes suicidal. Jen relayed a heart-breaking story of a possibly preventable suicide, if the person had just had an anonymous place to share what he was feeling. Big White Wall provides a community of people who are trying to self-manage their mental distress with support from clinical process and staff. It does so confidentially and anonymously. Anonymity is a key part of how Big White Wall works. People are more comfortable sharing when they know they won’t be judged and sometimes talking to a machine rather than a person can provide that, to illustrate, Hyatt shared the story of the young autistic boy who made friends with Siri. Hyatt has compared the accuracy of the data behind Big White Wall to predict depression and suicide risk to that of standardized tests, and says that interactions on Big White Wall provide enough information to be as accurate as the tests. Considering the difficulty of getting people to take these tests, and especially those who might not be seeking help for mental illness, this holds great promise for the power of patient (or people) generated data.

Serving the New Connected Patient

Source: MHealth Summit

The connected patient is already here, and she’s a millennial says Janet Schijns, Vice President of Global Verticals and Channel Marketing at Verizon. Schijns used a recent ER visit by her daughter, a college student to elaborate how patients are outpacing hospitals when it comes to digital care. Schijns daughter sprained her ankle badly, while waiting for a nurse to return with discharge instructions, she had already found and watched a video on how to navigate the world on crutches, ordered groceries online so she wouldn’t have go out, and researched how she would be able to get around campus. Schijns posits that healthcare organizations are spending dollars in the wrong areas online because they don’t really understand what patients are looking for. She talked about how patients are creating their own content through community sites like Patients Like Me and filling in gaps in the information the healthcare system is providing.

 Email Is Our Killer Application

Christine Paige, Senior Vice President of Marketing and Internet Services from Kaiser Permanente helped all m-health entrepreneurs in the audience breathe a sigh of relief when she said that Kaiser was not going to get into the m-health app business and instead focus on working with companies that help them improve the patient provider relationship. Paige called email Kaiser’s killer app for two reasons, one is that patients are not able to absorb key information when they’re in the clinic, especially if they’ve had a difficult or surprising diagnosis and second because they want convenience and a connection to their physicians. Kaiser’s patients who engage online are healthier, and only 1/4 emails results in a doctor’s office visit.

While personalized medicine is a hot topic these days, Paige warned against personalization trumping patient privacy and the risk of personalized recommendations being wrong. That is, patients using technology trust their physician with the information, but not necessarily if an application starts intervening and providing recommendations based on that data.

While the day 2 keynote was optimistic about the promise of m-health, it was definitely cautiously optimistic. Patients and providers are still feeling their way through the role of technology in communication and automating care.

Posted in: Behavior Change, Healthcare Disruption, Healthcare motivation, Healthcare Technology, Healthcare transformation, M-health, Telemedicine

Leave a Comment (0) →

Helping Patients Protect Their Own Personal Health Information

Last week I was leaving a meeting at a large hospital when I saw a patient record sitting on top of the payment machine in the parking garage. Incredibly this is the second time that I’ve seen documents left here. People put them down when they pull out their wallets to pay for parking and then walk away.

Patient Record on ParkingThe information the patients left behind included treatment plan instructions – so you can be pretty sure they are not doing their follow up home care – but worse than that it contained a schedule of future appointments with the patient’s name, date of birth, and social security number. Yes, you read that right: a perfect package for anyone practicing identity theft. This was all on a page that was printed directly from the EMR. The DOB and SSN were probably included on the record to verify that the information was for the correct patient, but this could be verified by asking the patient without printing it on a schedule of appointments.

So – first things first – I took the paper records back into the hospital. But afterwards it got me thinking about information protection and privacy, and in particular about the many people who still think that a paper print out is more secure than the cloud.

Although concerns about information protection and privacy are valid, many of the major HIPAA breaches of the last few years have had nothing to do with the cloud and usually are related to human error and not great security practices.

A few examples:

Good protection of patient information is important whether that information is in the cloud, on an internal computer or system, or on paper. HIPAA regulations encourage building good encrypted software, however we also need to have safeguards to protect against human error.

If patient information were in the cloud, the patient would either access the information through a secure portal, email, or application on their mobile device. He or she would then authenticate themselves to receive the information, and would not need to worry about accidentally forgetting their treatment plans sitting on a parking payment machine.

While patients expect to be able to interact with their healthcare providers through portals and mobile applications in the same way they interact with their banks, many healthcare CIOs we’ve encountered are still extremely wary of cloud-based systems. Financial services is another heavily regulated industry that has been able to successfully move to the cloud to better serve its customers.

Wellpepper is a cloud-based application, which in the healthcare world, makes us a business associate and on the hook for any breaches of patient health information. On the hook means that we need to sign a HIPAA agreement with any organization and we have liability for breaches of information. This is a job we take very seriously and we do our utmost to protect all information that flows through Wellpepper. This includes encrypting information at rest and in transit, ensuring strong passwords, and conducting audits of our system as well as making sure we are well-insured.

With Wellpepper, we provide the same level of encryption and safeguards to the patient’s own device as we do on the clinical devices. Information is not stored locally so if a device is lost or stolen there is much lower risk than in the laptop examples. Patient can do whatever they like with their own data. If I want to post my x-rays on the lamppost in-front of my house I can do that. However, that doesn’t mean that a healthcare organization should facilitate me in sharing my personal health information, which is actually significantly easier with paper-based systems than cloud based.

Yes this information would have been transferred over the Internet which could leave it open for hacking but a secure cloud system is no less, and sometimes more secure than internal IT systems which are also vulnerable. The key is to ensure that everyone in the chain, from internal IT to external partners, and finally to the providers and the patients understands the importance of protecting health data, and has the tools they need to do so, whether that’s on paper, online, or in the cloud.

Posted in: Data Protection, Health Regulations, Healthcare Technology, Healthcare transformation, M-health

Leave a Comment (0) →
Google+