Intelligent Medical Objects (IMO) moved from quarterly to daily deployments, enabling up to date healthcare data for 89% of US clinicians

"Octopus has saved us from working many late nights, as we now deploy smaller chunks more frequently, with deployments measured in minutes not hours."

- Leslie Brody, Principle Site Reliability Engineer

Download PDF

Their story

IMO is a healthcare data enablement company. It provides accurate documentation, precise population cohorting, optimized reimbursements, robust analytics, and better care decisions to improve patient outcomes. In particular, IMO connects patient records with healthcare codes to make them easier to understand. IMO’s footprint of Electronic Health Records (EHRs) represents 89% of US clinicians, with more than 740,000 physicians using IMO at the point of care every day.


IMO’s solution is a SaaS product at scale. Their solution involves over 600 Git repositories, 150 Azure DevOps team projects, a multi-tenant architecture and it is deployed to multiple AWS regions. Primarily .NET and JavaScript, their databases are primarily PostgreSQL (previously, they used Oracle and Delphi). Before implementing Octopus Deploy, IMO had a physical ‘build server’. The Global Hosting Organization (GHO) group oversaw all deployments to separate concerns. Typically, a developer would log in to build their artifacts and would sign into a target server and manually copy the files.

The GHO deployments were manual. Developers built the artifacts and handed them over to GHO to push out, which still involved manually copying files. Eventually, GHO started writing tools to verify the files were copied to the correct directory.

As GHO was also responsible for outages, there was confusion about who owned what with the development teams because it wasn’t their responsibility to keep systems running. In addition, there were no clear standards when building servers which were previously all hosted in Rackspace and handcrafted. A server in one environment could have one patch installed, while a server in another environment could be 3 versions behind.


In response to the risks in their deployment process, IMO started to modernize its CI/CD pipeline in 2013. The team began by implementing Git, then TFS. In 2015, with their needs still unmet, IMO decided to implement Octopus Deploy. Octopus fulfilled their criteria and solved numerous issues they were facing. Today, IMO is leveraging Octopus by:

  • Standardizing their CI/CD pipeline and deployment automation approach.
  • Using everything ‘as code’, with plans to adopt built-in support for Config as Code.
  • Using the Octopus API, projects, and scheduled triggers to run tasks that audit Octopus Deploy.
  • Integrating with the Octopus API to automate tasks and customize their experience.
  • For example, they write custom API scripts for their help desk staff to save time.
  • Running Terraform on Octopus.


As a result of leveraging Octopus as part of their CI/CD pipeline, IMO was able to solve multiple issues, adding consistency, automation and increased deployment frequency.

Introduced consistency

Octopus introduced consistency to IMO’s server configuration. Although IMO expected some variation between environments, they were pleasantly surprised by Octopus’s functionality. With everything now hosted in AWS, IMO leverages Octopus and Terraform to spin up new servers and auto scaling groups (ASGs).

Octopus has a trigger that monitors when a new server is added, installing the software for that server to function.

It also means there is a standard way and specific settings to deploy a web service to IIS, making deploying applications consistent.

Octopus also introduced consistency with deploying anything, anywhere. IMO started using Octopus to deploy software to their build servers and help desk staff.

Leveraged automation step templates

Octopus enabled IMO to standardize across projects and teams, through the steps Octopus provides for normal standards, and by extending Octopus to enforce additional custom standards.

Enabled DevOps practices

When they first implemented Octopus, GHO was responsible for ‘pushing the button’ to production and managing the production variables. Meanwhile the development team was responsible for building and managing the deployment process. With Octopus, they shifted the responsibility for production from GHO to the development team, who have grown to 18 DevOps teams in their their software engineering department. These DevOps teams are now responsible for deploying to production, managing and monitoring their software, and getting notified when outages occur.

Increased deployment frequency

Before Octopus, IMO deployed to production infrequently, usually once per quarter. Now, IMO deploy once per week to several times per day.

This has been especially beneficial during the pandemic. As doctors learn more about COVID-19, the healthcare codes need updating. These codes are stored in massive data files that need to be deployed to a variety of servers quickly. Without Octopus, IMO staff would have to work late nights to cover the required deployments. However with Octopus, they deploy smaller chunks more frequently, with deployments measured in minutes, not hours.

Octopus has also reduced manual verifications. IMO now has a robust PR (pull request) process to verify a branch before merging to main. All branches are deployed to a pre- production channel to validate the code changes. After a change is merged to main and built by their CI server, they push to the default channel in Octopus. Octopus then uses automatic deployments to push the changes to production.

Are you ready to discover how Octopus can help your deployment strategy?

Start a trial Schedule a demo

Shout out to @OctopusDeploy for making their software so easy to work with. Just upgraded a 2 year out of date instance and migrated it to a new server and it worked with no effort beyond what their documentation said to do.

Twitter user Alex Dent Alex Dent

We've been overhauling our internal infrastructure and back-end systems over the past month, including a move back to full @OctopusDeploy deployments; rediscovering how nice it is to have a platform-agnostic orchestrator that can deploy practically anything, anywhere ❤

Twitter user Nicholas Blumhardt Nicholas Blumhardt

Tools like @OctopusDeploy can be great in enabling culture change, we've been able to scale and improve our configuration story since we started using it.

Twitter user Niel Chalk Niel Chalk