Additions To Our Hipaa Privacy Policy: Fill & Download for Free

It is very important to understand what you really need and pricing should NEVER be the first criteria to compare services. Most vendors who host healthcare software/app etc need to ensure that as a company they are HIPAA compliant. By having a HIPAA complaint hosting providers does not guarantee that as a company & your product will meet HIPAA compliance requirements.We come across many software developers, consultants, product architect and they start with the same question…. we need cheapest service to host our product. Normally i tell them that to evaluate the providers after YOU understand what is HIPAA requirements for privacy and security rule and then decide the vendor as it is difficult to switch later on.We suggest the vendor to first take the comprehensive level HIPAA compliance training of Certified HIPAA Privacy Security Expert (CHPSE)[1]. This helps in three different ways:Helps to have a comprehensive understanding of HIPAA privacy & security rule requirements so the software design can be based on it. This ensure that you do not have major design issuesAllows you to lead company’s HIPAA compliance initiative.After training, you are in a better position to evaluate the products, their features to your specific needs and how it will help you to meet the HIPAA requirements.The major HIPAA complaint hosting providers that we have heard from software developers, auditors, consultants are:Amazon Web Services (AWS)RackSpaceMicrosoft AzureFirehostAptibleCatalyzeVMRacksConnectriaIt is very important that you do your own due diligence as we have seen many hosting vendors that claim that they are “HIPPA” complaint. If their marketing flyer and website spells HIPAA wrong, you can understand at what level the will be HIPAA compliant. If the vendor is serious then they will be able to fill up the HIPAA compliance status questionnaire This form helps in understanding knowledge level of the vendor.I will suggest that do not evaluate services based on cost as you may not be comparing apples to apples. Some vendors pricing policy is low to attract client and then they start adding cost based on additional services needed.I hope this helps.Thanks,BobFootnotes[1] HIPAA Privacy and Security Training

Having worked in medical group practice administration for over 20 years, I’ll give you my recollections from the trenches as we implemented HIPAA.Title 1, which regulates group health care plans, probably had limited impact on us. As an employer, we already provided good health insurance coverage, and as a medical provider, it should have had a positive impact on reimbursement.The Title 2 privacy regulations were met with consternation. After all, we already went to great lengths to protect our patients’ privacy. And here was Uncle Sam regulating our behavior with a complicated list of rules. What did we do to comply? Updated record release forms to be more stringent, refrained from mentioning any PHI in email, secured paper charts, erected privacy barriers between receptionists, called patients from the waiting room by last name only. We had to be very careful about leaving an appointment reminder in a voice message. We wrote privacy policies and had patients sign agreements that included a list of who we could talk to about their care. We had to keep a list of medical record disclosures. We named a privacy officer who was a risk of jail if found to have disclosed any PHI maliciously. Who would want that job?The Security Rules laid out additional safeguards for protecting electronic patient information such as back-up and data recovery. And if your doctor ever loses his laptop with PHI on a flight to Hawaii, your group is in for a world of trouble.The transaction and code set rules were a necessary hurdle in a world where computers were increasingly processing insurance claims. I believe everyone understood the necessity because it made sense. Previously there were various electronic claim forms with no standards. Providers had a variety of identifying numbers. One of my jobs was applying for the National Provider Identifiers for our 80 providers. This number stays with them across employers and insurance plans. If you’d like to look up an NPI – here you go: https://npiregistry.cms.hhs.gov/.6���PNJ

To start, and for full disclosure, I'm the co-founder of Catalyze. At Catalyze we offer APIs for developers looking to add HIPAA-compliant hosted infrastructure to web and mobile apps. We take a different approach from either of the two examples cited, and we believe we have good reasons from a risk mitigation and app functionality standpoint. Mapping Catalyze to the various aspects of HIPAA, we currently address technical and physical requirements, and will be very shortly adding a tool to address the administrative and policy safeguards; for this last part (admin and policy), we needed a tool internally to proactively address the admin and policy rules of HIPAA and, after building it, we've been asked by multiple customers if we could offer it as a service, so we are - HIPAAboard is your company's compliance department..Back to the question. The answers so far are very thorough and the bulk of what I would say has been covered. The specific comparisons between HIPAA IaaS and PaaS options are nicely laid out, though the distinction between IaaS, PaaS, and BaaS have eroded and aren't clean cut. It's probably worthwhile to give examples in each bucket:* IaaS - AWS, Rackspace, Azure, SoftLayer, Firehost, OnlineTech, etc. You can think of these as a blank slate or terminal in the cloud. These were the pioneering services. Very powerful and have led to incredible disruption.* PaaS - Heroku, Cloud Foundry, OpenShift, DotCloud, etc. These services take care of application deployment and scaling so you don't have to worry about linux or unix, at least remotely (you still have to get a local environment running as you build and test). You still have to write your own APIs and web services, but you don't have to worry about configuring a server and database.* BaaS - Parse, Kinvey, StackMob, etc. These began as mobile backends, but have evolved to offer web developers the same SDKs (JS); web and mobile are converging so this makes sense. With BaaS you can focus on the front-end - UI and UX - and distribution, without having to worry about touching a server or database. With the explosion of mobile apps, and bespoke apps, over the last several years these services have seen tremendous growth.* EVERYTHINGELSEaaS - Twilio/Plivo, UrbanAirship, Keen IO - The API for Custom Analytics, MongoLab, etc.The reason I say these buckets are converging is we're seeing AWS offer services like messaging via it's SNS service and Parse offer analytics, like Keen IO - The API for Custom Analytics and Flurry, and Push, like UrbanAirship. Heroku also offers a myriad of services via Add-ons.As a developer, the service layer you choose in large part depends on the application you are building and the specific needs you have from a business and use case perspective. The more complex the app, especially as it relates to backend logic and data modeling, the more likely you'll need to use a secure IaaS like Firehost. If you're new or the app is new, you may not know how complex the app needs to be or what your backend needs are, so using an abstracted service layer, like what Catalyze offers via APIs and SDKs, is a much faster and cheaper way to get up and running, and ideally validate some of your hypotheses. I can say that at Catalyze we haven't had many cases where we can't support the business or use cases; most apps and developers that have approached us and are using Catalyze can use API-based services like the ones we offer to get up and running on day one, without the need to roll their own infrastructure on Firehost, or OnlineTech or AWS or Rackspace. We also offer this at a considerable savings over Firehost or AWS or Rackspace.There's also a question of flexibility when developing. The more infrastructure services you rely on, the faster you'll get started and the less ongoing maintenance you'll have, but you'll also have less flexibility, and you'll likely pay a bit more for the convenience. That is one of the major gripes that developers have with BaaS like Parse; they often complain that you can only build simple apps using BaaS. Flexibility may not be a big deal and, when it comes to building a vertical-specific infrastructure, which is what we're talking about here, hopefully the infrastructure (PaaS or BaaS) provider knows healthcare and is close enough to its customers to build out the services and features required to meet the majority of developer use cases. At Catalyze we think HIPAA is just one part of health app development, and expand upon that with additional tools like data models, mappings, and sources. The more health-specific features you can offer means you're just left with corner cases, and no one service, even a vertical specific offering, is going to be able to meet all the corner cases.We do, or I should say our attorneys, our HIPAA auditors (we just completed our independent 3rd party HIPAA audit this summer/fall), and at least two health system compliance offices we've worked with, disagree with the assessment that you can add a storage layer via API to an existing app (on Heroku or Google App Engine) and address the security rules within HIPAA. It's not as simple as the approach Stripe takes to making apps PCI compliant because the data isn't as simple, and PCI and payment processing is a different problem from HIPAA compliance.Stripe is a really good example to illustrate this. For an app to be PCI compliant using Stripe it has to use HTTPS, which isn't really a major hurdle, and use one of the front-end JS libraries or widgets from Stripe (currently Stripe.js or Checkout). The reason for this is that, by using one of those front-end libraries, all payment data passes directly to Stripe and the app that's using Stripe is out of scope for PCI. So Stripe technically doesn't make apps PCI compliant, it enables apps to process payments while not touching PCI-relevant data, and in the process enables apps to remain out of the scope for PCI compliance.At the end of the day, all you need from Stripe is to store payment information and process payments, either on demand or at scheduled times. This is a simple use case, really, and is the reason why it is easy to handoff payments and PCI compliance to Stripe; it's also the genius of Stripe. It's really a very powerful solution. We've used it and love it! You can read more on Stripe and PCI here - Do I need to be PCI compliant? What do I have to do?.The thing about payment processing is that it is necessary but not a core part of any app. And the subset of PCI-relevant data is much, much smaller than PHI data. Because of that, applying the Stripe model to HIPAA is much, much harder. Any identifiable information, as defined by HHS - Guidance Regarding Methods for De-identification of Protected Health Information in Accordance with the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule, linked to a health related service or payment, is considered PHI, and in scope for HIPAA. It's far more likely an app would store and use a phone number or email or an IP address (in a log maybe), as an example of identifiable data, than an app would need to store a credit card number. And it's far harder to build front-end libraries, like Stripe.js and Checkout, for the myriad of data and models health app developers will want to create and store that would be considered PHI.It's really hard, and we see it as a burden to developers, to prevent custom apps from acting as a passthrough and touching PHI. Separating logic from data is a hard thing to do, and we think has very limited use cases. And if apps touch (transmit, process, store) PHI then those apps are considered in scope of HIPAA and have to be secured to meet HIPAA requirements. And, as of 9/23/2013, so do all subcontractors used to build or run those apps.Another fundamental difference with HIPAA is that the data you are storing is part of the core value of the app; if you build a health app, health data IS is your app. It's not payment processing. It's the data collected via a glucose monitor or a WiFi scale or an intake form or a virtual visit app (asynchronous telemed). The app has to use that data to power the app (provide logic) and provide a customized user experience. In the overwhelming majority of cases the app needs access to that data, and you can't simply hand off the storage layer and make an app compliant or out of scope of HIPAA.It's why, after spending a lot of time researching the challenges of HIPAA security, we built Catalyze the way we did, with version 1 being essentially a HIPAA-compliant BaaS offering, and not as an add-on for existing apps. Our platform (users, auth, storage, etc) is API-based, so could be used as storage layer, but we don't think that's a real path to HIPAA compliance. Our version 2 will include additional features and flexibility, something we're really excited about and hope will address more and more of the market need. Ultimately we want to give developers a simple way to add modern web services to health apps and, in the process, we want to mitigate risk for them and help them overcome some of the compliance roadblocks we encountered in building and selling apps in healthcare.