Medical Software Deployment and HIPAA: Cloud, Native, or Hybrid?

 October 28, 2020


Should your medical imaging application be built for the cloud, native, or a hybrid approach? In this article, we compare several deployment strategies and how each relates to HIPAA compliance. We assume you have some familiarity with HIPAA-terminology.

Software applications can not be HIPAA compliant—only organizations can be HIPAA compliant. For an organization to be HIPAA compliant, it must enact certain administrative policies, provide training to employees, and document that these policies are being met.

Thus, when choosing a deployment strategy, the question is not, “how can we make our software HIPAA compliant?” Instead, the two key questions are:

  1. Will this strategy require us to become a Business Associate, and thus become HIPAA compliant?
  2. What software features do we need to build to enable our customers to easily remain HIPAA compliant?

Below, we list six deployment strategies, along with their advantages and disadvantages. Generic lists like this can be dangerous. Be aware that there are almost undoubtedly project-specific considerations you should consider. Also, we don’t explicitly discuss EMR or PACS integrations. Even so, we hope this list is a useful starting place. Please reach out to us if you would like to discuss the specifics.

1. Native app 🔗


  • Better performance in most cases; e.g., for visualization tasks
  • Native apps have better access to the operating system than web apps; e.g., you can save files, poll a PACS system, etc.
  • No need to manage servers
  • Avoids uploading large medical images (which can be slow)
  • Easier to sell and distribute to individuals


  • Users need to install the application
  • Data stored locally; sharing data is more difficult
  • Software updates are more difficult; need to worry more about backwards compatibility
  • More difficult to support multiple operating systems
  • Easier for people to pirate software
  • More difficult to gather analytics or data for machine learning algorithms

2. Web app served locally 🔗


  • Individual users will not need to install software locally
  • Centralized data store enables some features like sharing data between users
  • Fewer concerns about pirating (although we have seen hospitals pirate software)
  • Have control over the server hardware; e.g., you can run Linux and depend on a particular GPU model being present


  • Software updates are applied by the IT department
  • Must sell to hospitals
  • Customers need to set up and maintain the local servers
  • Need to support the customer’s IT department as they set up the server, or will need to purchase servers to ship to customers
  • Need to worry about running out of processing capacity on the local server

3. Web app served from cloud 🔗


  • Customer will not need to install or update software
  • Have complete control over the server hardware; no worries about pirating
  • Good intellectual property protection for code running in the cloud
  • Easy to collect analytics and usage data
  • Can scale processing capacity to meet demand


  • Since you have access to PHI, you will be a Business Associate with your customers; will need to sign BAAs with each customer
  • Your organization will need to be HIPAA compliant
  • Need to sign BAAs with your hosting services; hosting costs will be higher
  • Some hospitals do not like using cloud hosted servers; a relatively easy solution is to sell an “enterprise version” using (2)
  • Need pay for cloud hosting costs
  • Data transfer over the internet is slower than in-network; can be an issue when time-sensitivity is a problem

4. Web app served locally + cloud processing server 🔗


  • Many of the advantages of (3) while avoiding many HIPAA issues
  • Lower hosting costs than (3)
  • Within FDA limits, can update processing algorithm independently from local server software
  • Good intellectual property protection for code running in the cloud


  • Several of the disadvantages from (2)
  • Need to maintain two sets of server hardware
  • Higher initial development costs than (3)

5. Native app + cloud processing server 🔗


  • Advantages of using a native app
  • Within FDA limits, can update processing algorithm independently from local server software
  • Good intellectual property protection for code running in the cloud
  • Lower hosting costs than (3)
  • Ensures users can’t pirate the software


  • All the disadvantages from (1), except easier to collect analytics and prevent pirating

6. Web app + cloud processing server + 3rd party HIPAA platform 🔗


  • Most of the advantages of (3), but without the disadvantages of being a Business Associate
  • The 3rd-Party platform implements several HIPAA requirements; e.g., encryption-at-rest and access controls


  • Constrained by the features of the 3rd party platform
  • De-identification + re-identification must occur on the client instead of a local server, which is can be much more difficult
  • Locked into the third party’s platform; would be difficult to switch later; e.g., to provide an enterprise version using (2)
  • The risk that the 3rd party platform will go out of business
  • Higher hosting costs than vanilla HIPAA hosting services

Footnotes 🔗

1 It is also possible to deploy a native app if you need the visualization performance but it comes with many of the disadvantages of (1) 2 It may be possible to also use a web app in rare cases. However, web apps don’t provide a reliable way to store long-term data. One exception is if you could use the web app to de-identify the data, but you don’t need to store any PHI for longer than a single session 3 Cloud hosting platforms can go out of business too, however, switching is usually easier


Get To Market Faster

Monthly Medtech Insider Insights

Our monthly Medtech tips will help you get safe and effective Medtech software on the market faster. We cover regulatory process, AI/ML, software, cybersecurity, interoperability and more.