Blog

Posts Tagged CMS

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

MACRA: A Rule Worth Learning

Introduction to MACRA

Those of us who that work closely with clinicians or simply work in healthcare have no doubt heard of the total revamping of Medicare (Part B) clinician payments from a fee-for-service to a value-based system; this sort of change hasn’t occurred in over a generation. If that isn’t incredible enough for you, how about the fact that this 892 page document was passed by Congress with a bi-partisan ‘supermajority’; that alone speaks volumes on the importance of this change. The culprit of my angst and information overload is called the Medicare Access and CHIP Reauthorization Act of 2015 (MACRA) that will go into effect 1/1/17. This rule is so complicated with so many layers, it does not even have a Wikipedia page (nobody as been so bold); so keeping that in mind this blog post is my attempt to sum up my own understanding of this proposed rule.

Courtesy of CMS.gov

Two pathways to payment. MACRA is built upon two value based pathways that eligible clinicians (physicians, physician assistants, nurse practitioners, clinical nurse specialists, and certified registered nurse anesthetists) must chose from: Merit-based Incentive Payment System (MIPS) or the Advanced Alternative Payment Model (Advanced APM). Which path a clinician takes depends on their patient threshold and if they are new to the Medicare. It also depends if the clinician is part of an Accountable Care Organization that is established as an APM entity. The advantage of one over the other is a 5 percent annual payment increase from CMS over 6 years if a physician decides to be grouped with their ACO APM entity. The risk is if clinicians do not meet metrics chosen and set by their ACO they will not be rewarded with their shared savings. The good news is Physicians can elect to switch between the two payment models from on year to another. This flexibility is the foundation to the MACRA proposed rule. Additional choices given to eligible clinicians are: they can report on measures that are important to them and decide if they want to report as an individual or in a group.

Courtesy of HIMMS MACRA information Webinar

Fundamental basics to the MIPS. The MIPS replaces the Physician Quality Reporting System (PQRS), Value-Based Modifier (VBM) and Meaningful Use (MU) programs with the categories: Quality, Resource Use, Clinical Practice Improvement Activities and Advancing Care Information. Quality metrics are mainly derived from PQRS, Advancing Care Information is a simplified version of MU, and Resource Use is similar to VBM. The biggest change, as far as I can tell, is clinicians can choose six quality reporting measures that are important to them. Each year HHS will publish a list of quality measures to be used in the forthcoming MIPS performance period (which is 365 days) for clinicians to choose from. Out of these measures, one must be an outcome measure of high priority measure, one must be cross-cutting (hit on several quality measures), and clinicians can choose to report a specialty measure set. Clinicians composed quality score is measured against clinicians similar to themselves; this is another significant change. If you recall previously the sustainable growth rate (SGR) “set an arbitrary aggregate spending target” not based upon individual performance or clinician peers.

Introduction to Advance APM. There is a reason why I explained in more detail the MIPS path- because I understand it better; as with many things in my life I relate it to food. MIPS takes the wholesome ingredients from MU, PQRS and VBM programs and makes it a much better appeasing entrée. Whereas the Advanced APM program doesn’t focuses so much on the recipe but on the consumer. From what I understand so far, you have to be an eligible clinician determined by CMS, and work in an organization that participates already as an APM through an agreement with CMS. Also, so far, CMS has only identified six APMs that qualify as Advanced APMs. These include Comprehensive End Stage Renal Disease care, Comprehensive Primary Care Plus, Medicare Shared Savings Program (Track 2 and 3), Next Generation ACO Model, and Oncology Care Model. The three criterion’s in order to become an Advance APM clinicians are: 50% of physicians must use Certified EHR technology; payments are based on quality measures; financial risk and nominal amount standards. I hope to dive deeper into Advanced APMs in a later blog post. For now please check out the HIMSS information deck here.

MACRA professional I am not… is anyone? Whereas I love to always learn, MACRA was difficult for me to grasp, HOWEVER I spent about 2 years in Graduate school studying Meaningful Use, so that says a lot. I am sad to say that a lot of what I learned about MU no longer applicable, but good riddance! The beginning of this year the Acting Administrator of CMS said “The Meaningful Use program as it has existed, will now be effectively over and replaced with something better.” I hope we you are right Mr. Slavitt.

Posted in: Healthcare Legislation, Healthcare Policy, Healthcare transformation, Outcomes

Leave a Comment (1) →

Reducing Readmissions and Costs for Total Joint Replacement

Last week CMS announced a major new initiative for Total Joint Replacement, aimed at both reducing and reconciling costs. Total joint replacements are predicted to increase at a rate of 30% to 2020. Demographics are the major driver: people are getting joint replacements at a younger age, and may have more than one in their lifetime. On the one hand, more active baby boomers have put greater strain on their joints by running marathons, and on the other an overweight population is putting more strain on their joints just by walking around.

Since the demand is increasing, and the costs fluctuate wildly, up to 100% by Medicare’s estimates, the opportunities to look for costs savings and to reward based on outcomes is key. Like other bundled payment recommendations, Medicare is looking at the 90-day readmission rates and also using a carrot and stick reimbursement approach.

“Depending on the hospital’s quality and cost performance during the episode, the hospital may receive an additional payment or be required to repay Medicare for a portion of the episode costs.”

While private payers often follow Medicare, this is one area where Medicare cites that it is following a trend that has already been piloted in private scenarios, most notably with self-insured employers contracting directly with healthcare systems on fixed-price knee and hip replacements, like the deals Walmart and Lowe’s have struck directly with hospitals.

Screen Shot 2015-07-12 at 4.00.51 PMThe American Hospital Association is also ahead of the curve on this trend, and they published some recommendations in a 2013 report entitled “Moving Towards Bundled Payment.” In it, they also noted the wide fluctuations in pricing between health systems for total joint replacement, and also that 33% of the costs of a total-joint replacement come from post-acute care.

Screen Shot 2015-07-12 at 4.01.13 PM
Our research has shown that a large driver of these costs is discharge setting related. While the majority of patients do better when discharged to home, they were being discharged to skilled nursing instead as a “belt and suspenders” type of back up. Discharging to the right setting, can improve patient experience and lower costs. However discharge to home requires the right type of patient tools. Patients need to have great educational materials, the ability to track their progress, and the ability to get remote help if they need it. This is something we’re passionate about at Wellpepper, and we are working with a number of leading health systems that are moving to bundled payments to help them digitize the pre and post surgical instructions and collect patient reported outcomes. We’d like to be part of the solution for both patients and providers as we move to these new models of care and reimbursement.

The Medicare proposal is open for public comment for the next 60 days. It’s over 400 pages long, so you may want to print a copy and take it for a little light beach reading.

 

Posted in: Adherence, Aging, Behavior Change, Health Regulations, Healthcare Policy, Healthcare transformation, Outcomes

Leave a Comment (0) →

Will 2015 Be the Breakout Year for M-Health?

While on the one hand, many are proclaiming 2015 to be the year that M-Health finally becomes mainstream (and certainly CMS’s announcement that they will pay $42 per month for remote care for chronic diseases helps with that), the opening day keynote at  the M-Health Summit last week at the Gaylord National Harbor Convention center, seemed to suggest we are in the trough of disillusionment.

In particular Walgreens Chief Medical Officer Harry Lieder and Partner’s Center for Connected Health Director Joseph Kvedar were pragmatic to almost pessimistic about how mobile health would be adopted by consumers, healthcare systems, and payers. While being realistic about how mobile health can help, who can benefit, and who will actually pay for it is a conversation we all need to be having, the tone of the opening day keynote was not so much about celebrating successes but shoring up the audience to continue the good fight.

Walgreens CMO, Lieder outlined four areas where he thought that M-Health could have an impact across the care continuum:

  • Health, fitness, and well-being
  • Self-diagnosis
  • Acute care
  • Chronic care

Source: M-Health Summit

He then went on to debunk the myths of the quantified-self, that is that consumers will take their health in their own hands if presented with information. He also talked about why wellness is not popular with insurers and employers: the impact of wellness programs is generally only in the long-term, for example 10-20 years, and most employers and insurers hope that any individual won’t be their problem for that long. Taking the short term approach, Lieder said there were really only two ways to have a successful m-health startup today: enable people to bill for an existing CPT code or show significant cost savings to the healthcare system in 12-18 months. This is the current reality of the healthcare system, but certainly not how we’re going to drive change. CPT codes are backward looking not about new ways of delivering care, and while ROI needs to be forthcoming, managing patients over their lives needs to be the goal of the healthcare system.

So with this grounding in the somewhat depressing realities of today’s situation, Lieder then announced that Walgreens has partnered with MDLive to offer in-store telemedicine visits. Their recognition that consumer health alone doesn’t change behavior and that patients need support prompted the introduction of this new service, Lieder said “We need people available behind the device to change behavior.” If you can’t fix the system, reinvent it! One speaker called pharmacy the “last mile” that is, the patient loses connection to the health system at the pharmacy so brining the health system to the pharmacy might be the solution.

Joseph Kvedar of Partners.org asked if 2015 would be m-health’s coming out party but said that until applications hit certain key criteria we won’t see widespread adoption. He asked that application builders make m-health apps usable, social, personalized, and with relevance to everyday life. From a patient’s perspective applications should know the patient, engage the patient on his or her terms, and empower the patient. Kvedar did not seem to think that applications had nailed these things yet, especially in the area of usability and that we don’t get this right (and soon) m-health will “go down as another tech bubble.”

Joseph Kvedar

Source: MHealth Summit

M-health has had a lot of hype, and while this keynote provided some grounding in the reality of the market today, it seemed that this might have been a better keynote for the second or third day. Day one, it would have been nice to hear some success stories. After this keynote, I attended a session where one medical researcher spent most of the time explaining how she knew better on how to build good software than anything out there. We m-health entrepreneurs definitely need to get better at telling our success stories. It seems the press to date has been too much hype and not enough clinical substance and ROI to make our case.

At Wellpepper, we predict that if m-health companies can show real clinical evidence, tell real patient stories, and find partners in the ACOs and other organizations that are passionately trying to change healthcare in this country, then 2015 really will be the breakout year for M-Health, and next year’s keynote will see us out of the trough of disillusionment and firmly into real value.

Posted in: Uncategorized

Leave a Comment (0) →
Google+