All case studies / IMO
){kind=logo}
Intelligent Medical Objects moved from quarterly to daily deployments with Octopus
About IMO
Intelligent Medical Objects (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. IMO connects patient records with healthcare codes to make them easier to understand.
With a footprint in Electronic Health Records (EHRs) across over 4,500 US hospitals, IMO owns 98% of its market, including private practices.
When you go see a doctor, information gets added to your medical record and this data needs to be translated into codes so others, such as insurance companies can understand it.
Challenges
Manual processes and inconsistencies
IMO’s solution is a SaaS product at scale. The solution involves over 600 Git repositories, 150 Azure DevOps team projects, and multi-tenant architecture deployed to multiple AWS regions. Primarily .NET and JavaScript, IMO’s databases are primarily PostgreSQL. Previously, they used Oracle and Delphi.
Before using 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 in to a target server, and manually copy the files.
The GHO deployments were manual. Developers built the artifacts and manually copied files to hand them over to GHO to deploy. Eventually, GHO started writing tools to verify the files were copied to the correct directory.
GHO was also responsible for outages, so there was confusion about who owned what to keep systems running. There were also 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.
Prior to Octopus, deployments to Production were infrequent, maybe once a quarter. Now they range from once a week to several times per day.
Solution
IMO modernized its CI/CD pipeline with Octopus
In response to the risks in the deployment process, IMO started to modernize its CI/CD pipeline in 2013. The team began by implementing Git, then TFS. In 2015, with its needs still unmet, IMO decided to implement Octopus Deploy. Octopus met the team’s criteria and solved many issues they were facing.
Today, the IMO team uses Octopus by:
- Standardizing their CI/CD pipeline and deployment automation approach
- Using everything ‘as code’, with plans to adopt Config as Code in Octopus
- 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 to save time for their help desk staff)
- Running Terraform on Octopus
IMO's CI/CD pipeline
)
)
Value
Consistency, automation, and increased deployment frequency
As a result of using Octopus in their CI/CD pipeline, IMO solved multiple issues, adding consistency, automation, and increased deployment frequency.
Introduced consistency
Octopus introduced consistency to IMO’s server configuration. IMO expected some variation between environments, but the team were pleasantly surprised by Octopus’s functionality. With everything now hosted in AWS, IMO usess 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.
There’s now a standard way and specific settings to deploy a web service to IIS, making deploying applications consistent.
Octopus also introduced consistency deploying anything, anywhere. IMO started using Octopus to deploy software to their build servers and help desk staff.
Standardization using step templates
Using Octopus, IMO standardized processes across projects and teams, through the steps Octopus provides for normal standards, and by extending Octopus to enforce additional custom standards.
The Dev team became a true DevOps team and are now responsible for deploying to Production, as well as managing and monitoring their software, being the ones who get paged when outages happen.
DevOps best practices
Before using Octopus, GHO was responsible for deploying to production and managing the production variables. Meanwhile, the development team built and managed the deployment process.
With Octopus, IMO moved responsibility for production from GHO to the development team, who have grown to 18 DevOps teams in their software engineering department. These DevOps teams now deploy to production, manage and monitor their software, and get notified when outages occur.
Increased deployment frequency
Before Octopus, IMO usually only deployed to production once per quarter. Now, IMO deploy once a week to several times a day.
This was especially beneficial during the pandemic. As doctors learned more about COVID-19, the healthcare codes needed updating. These codes were stored in massive data files that needed to be deployed to a variety of servers quickly. Without Octopus, IMO staff would have worked late nights to cover the required deployments. However, with Octopus, they deploy smaller chunks more frequently, with deployments measured in minutes, not hours or days.
Octopus has also reduced manual verifications. The IMO team has a robust PR (pull request) process to verify a branch before merging to main. They deploy all branches to a pre-production environment to validate 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.
Less manual work
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.
Octopus has saved us from working many late nights, as we now deploy smaller chunks more frequently, with deployments measured in minutes not hours.