How To Strategically Evolve Cloud Architecture for IoMT

As a cloud architect at Punch Through, I’ve seen firsthand the unique challenges and intricacies of architecting cloud services in the Internet of Medical Things (IoMT) space. On one hand, much of the work to design the perfect cloud infrastructure is wasted when requirements change. On the other hand, not investing time and effort into scalable cloud architecture can result in inefficient use of cloud resources and slower, less reliable applications. Getting cloud architecture right is difficult and requires experienced engineers that companies might not have on staff.

What’s In This Article

We’ll provide a high-level understanding of how to grow your cloud architecture across your connected product lifecycle. We aim to equip you with the key phases, considerations, and strategies for standing up and evolving a robust medical cloud architecture to support your IoMT ecosystem as your product grows. We hope it will serve as a valuable guidepost on your IoMT cloud development journey. 

If you run into any blockers along the way and need an expert cloud development partner, reach out; Punch Through’s cloud team is here to help you achieve success. Now, let’s talk about project phases…

---

Project Phases: Startup, Growth & Maturity

Understanding the optimal timing for cloud architecture in IoMT product development is foundational to success. While every company is different, common challenges are faced at key stages. We’ve distilled these observations into three phases where cloud architecture considerations are critical: Startup, Growth, and Maturity. Identifying your current phase will help determine how to best approach your cloud architecture strategy.

• Startup Phase: At this initial phase, companies are developing prototypes or navigating through clinical trials without a product yet on the market. Their focus is on proof of concept and foundation building.
• Growth Phase: Typically, these organizations have recently launched their product and are now grappling with scaling challenges, such as expanding their offerings, attracting new customers, and integrating new team members. Their focus is on scalability and efficiency.
• Maturity Phase: Companies in this phase have laid down the infrastructure needed to support ongoing growth. They often boast multiple successful products and focus on streamlining processes and exploring third-party integrations, including Electronic Health Record (EHR) systems like Epic or Cerner. Their focus is on stability and interoperability.

Next, we’ll delve deeper into each phase, using situational examples to help illustrate the unique challenges and strategies in tackling cloud architecture for each situation.

---

Startup: Architecting a Foundation for Growth

During the startup phase of a project, where the product hasn’t been released yet, you don’t have the time or resources to build everything all at once. So, you start by building a solid foundation for future work and then iterate on the most important features.

Scenario

To help illustrate cloud architecture needs at the startup phase, lets use New Product LLC as an example situations:

Specific Cloud Challenges at the Startup Phase

In the startup phase, designing a robust and scalable cloud architecture can be challenging due to various factors inherent in the early stages of a project. Here are some specific challenges that startups often face:

• Unclear Requirements: At the beginning of a project, many unknowns can lead to ambiguous or incomplete requirements. This lack of clarity makes it difficult to design an optimal cloud architecture that will meet the project’s current and future needs.
  
• Changing Priorities: As new information is discovered during the implementation phase, requirements and priorities may shift. These changes can necessitate significant modifications to the cloud architecture, which can be time-consuming and costly to implement.
  
• Cost Implications of Inefficient Implementation: Startups often have limited financial resources, making it crucial to design an efficient cloud implementation from the outset. Inefficient architectures can lead to increased costs, which can strain the startup’s budget and hinder its growth.
  
• Limited Expertise: Startups may not have access to experienced cloud architects or developers, which can result in suboptimal design decisions and implementation challenges.

Additionally, IoMT and medical software requires:

• Strong Security Requirements: IoMT and medical software projects require robust security measures from the very beginning to protect sensitive patient data and ensure compliance with industry regulations. Implementing these security features can be complex and time-consuming.
  
• Regulatory Requirements: Medical software is subject to strict regulatory requirements, such as HIPAA and GDPR, which impose additional work on the development team. Ensuring compliance with these regulations can be a significant challenge for startups with limited resources.
  
• Formal Verification and Validation: IoMT and medical software projects require thorough documentation and testing to ensure the reliability and safety of the product. This process can be resource-intensive and may slow down the development timeline.
  
• Higher Cloud Provider Costs: Cloud providers often charge more for the security features required for IoMT and medical software, which can further strain a startup’s budget.

Cloud Architecture Strategies at the Startup Phase

The best way to start any new cloud implementation is to use an Agile approach to medical device development. Start simple, then improve through multiple interactions. The first step is to develop a High-Level Design (HLD) that defines the system’s most important features and dependencies. From there, you build a prototype with a subset of those features that can be demonstrated and tested. This iterative approach lets you get feedback at each iteration to ensure you are on the right track. For each interaction, you make incremental changes to the design and the prototype, adding more and more functionality.

Internal Architecture Planning

The same approach applies to the architecture behind the scenes. It is best to start with a single “modular monolithic” application, where the application is built as a single application in a single codebase but is broken down internally as if each component were a microservice. This allows developers to iterate quickly, refactor when needed, or even completely change the design as requirements become clearer. It also makes it easier to break down into multiple services as the complexity increases.

We avoid adding unnecessary complexity early on by:

• Focusing on just the core features to start with
• Avoiding async background processing
• Using existing cloud services to handle some of the complexity
• Breaking features into independent microservices only when needed
• Simple reporting and Robust data exports, allowing users to generate their own reports from the data

Groundwork for SOC 2 Compliance

We include the following features to ensure the system’s security and patient privacy. However, we also design them with future SOC 2 compliance in mind. It can be difficult to implement the necessary security and privacy requirements later on if proper security controls are not in place from the beginning.

Monitoring and Logging Built-In

Overlooking observability at this stage in the project can be a costly decision that leads to significant additional work later in the project. You should have a strategy for monitoring and logging that will support the ability to locate issues in development and production. Including this at the beginning of a project is much easier than adding it after the fact and lays a solid foundation for SOC 2 compliance.

I prefer to instrument the code using open standards like OpenTelemetry connected to commercial tools such as New Relic or Sentry. By using OpenTelemetry in the code, I can switch between different monitoring services or even use multiple simultaneously. I use commercial services to collect telemetry because the open-source alternatives aren’t as feature-rich without substantial configuration, which isn’t a good use of effort early in a project.

Authentication and Access Management

Any new IoMT software project must start with a plan for Authentication, Authorization, and Audit logging.

• Authentication is the process of determining who is making the request. This includes users logging in and how software components authenticate with each other. You should also enforce two-factor authentication for any account that can access data for multiple patients.
  
• Authorization is the process of determining whether the requester is allowed to make that request, including what types of data a user or software component can access and what actions they can perform. It also includes controlling access to specific records, such as users only having permission to access their own data.
  
• Audit Logging is the practice of maintaining a record of all interactions with data, including access, modification, and deletion. It’s crucial to have a well-defined strategy for identifying the types of data that require audit logs, particularly personally identifiable information (PII) or protected health information (PHI). These logs will allow you to monitor suspicious activity and ensure data is used solely for authorized purposes.

It’s important to have automated tests that verify that these are in place and are working correctly. That way, you can ensure that changes as part of a future release, do not break any necessary security controls.

Securing the Infrastructure

It is just as important to apply authentication, authorization, and audit logging to the infrastructure behind the application. The only difference is that you usually grant access to employees and contractors instead of the software users.

Because access to the infrastructure could enable access to a larger volume of data, with many access controls managed outside the software system, you should limit access to production data – both in terms of permissions and the number of accounts with access. There should be few accounts with full access, and they should not be used in day-to-day work.

Encryption

All data should be encrypted when stored or transmitted between systems. Except for PHI data, which must be encrypted. In addition, the encryption keys must be stored securely with access controls so only the necessary systems can access them to maintain the security of the encrypted data.

Automated Testing

Security, monitoring, and audit logging should all be tested with automated tests. Oftentimes, these are difficult to test manually, and bugs that affect them can be missed because they’re not directly related to the feature being implemented or tested. These automated tests can cover many complex combinations of access controls and quickly verify that all access controls work as intended for every application release.

---

Growth: Architecting for Scale & Efficiency

The growth phase of a project starts after the first product is launched. You start to scale in terms of users of the system and load on the system. To keep up, you scale the size of the development team(s) working on the project. The growth may also require you to reevaluate your priorities and strategies.

Scenario

For the growth phase, lets use Growth Inc. as an example situation:

Specific Cloud Challenges at the Growth Phase

As an IoMT company enters the growth phase, the development team faces new challenges in managing the increasing complexity of the cloud infrastructure and codebase. Here are some specific issues that often arise:

• Increased Coordination Overhead: Expanding the development team requires more coordination to keep everyone on the same page, which leads to more meetings and more project management.
  
• Accumulating Technical Debt: “Tech Debt” starts to play a significant role. Such as:
  • Architecture decisions that didn’t scale as well as planned.
  • Small pieces of inefficient code that add up to major performance issues.
  • Requirement changes that render a complex section of code unnecessary that can’t be removed without major rework.
    
• Monolithic Architecture Scalability Issues: The growing complexity of the system makes it more difficult to keep building as a monolith.

Internet of Medical Things (IoMT) and medical software again introduces some additional challenges, such as:

• Regulatory Compliance Limiting Access: Regulatory requirements for the launched product are now in effect, which limits access to production systems and data, making it more difficult to troubleshoot issues.
  
• Regulatory Approval for Changes and Rework: Many changes require regulatory approval and significant system rework introduces additional risk that can be difficult to get approved.

Cloud Architecture Strategies at the Growth Phase

Architectural Refinement

It’s important to revisit any previous architectural decisions that aren’t working as planned. The engineering teams know more than they did at the start and may find ways to improve the system in terms of performance, cost, or capabilities. In addition, user behavior may differ from the initial expectations or experiments, which may expose missing features or issues in the design that weren’t visible before.

Architecture Review

An important way to coordinate changes across all the engineering teams is to have regular Architecture Review meetings.  These meetings aim to share design documents for major changes to the system and get feedback from other teams about the design.

Embracing Microservices

It’s at this stage that we start discussing microservices. The decision to break the monolith down is driven more by how many teams will be working on the project than by scalability at this stage (you can always spin up more instances of the monolith). The focus is on making it easier for teams to work independently with fewer dependencies, so they don’t require as many meetings or coordinated releases. 

Implementing API Gateway

None of the components should expose any endpoints to the internet. Instead, a single API gateway should be created that allows a common, managed entry point into the system. From there, the API gateway should call the endpoints for the corresponding components. This makes it a lot easier to secure the system from outside access and allows uniform security rules and logging across all endpoints to be enforced.

Enhancing CICD Processes

One final component to add is Continuous Integration/Continuous Delivery (CICD). Some parts of the CICD process may have been introduced during the initial stages of the project, but here, it becomes much more important to invest a lot of effort into getting it right.

The first part, Continuous Integration, is about making it easier and more efficient for developers to create a branch, implement the ticket they are working on, get the changes reviewed, test the changes, and get them merged back into the main branch. The second part of CICD, Continuous Delivery, is about automating as much of the deployment process as possible and trying to remove manual changes that are often the cause of deployment failures.

Due to regulatory approval requirements, these CICD processes should only be released directly to production with manual review and approval, but once approved, the actual deployment should be as automated as possible.

Advancing SOC 2 Compliance

Many of the deployment, documentation, and reliability improvements implemented during this stage cover requirements of SOC 2 compliance. Audits for SOC 2 compliance can take 6-12 months to complete, so it is important to have the necessary controls in place before starting the process. 

---

Maturity: Architecting for Stability & Interoperability 

During the maturity phase of a project, the company’s growth is more consistent and predictable than before, and there are processes in place to handle continued growth. However, the scale of the whole system has grown to the point where change is incredibly slow and complex, and the project is starting to run into limitations of the original architecture and chosen technologies.

At this point, companies look to build interoperability with external partners, which requires some standardization throughout the system. Proper security controls become even more important because the system is too complex for a single person to keep track of all the parts of the system at once.

Scenario

For the maturity phase, lets use Stabilize Corp. as an example situation:

Specific Cloud Challenges at the Maturity Phase

As an IoMT company’s cloud infrastructure reaches maturity, new challenges emerge that require careful planning and management to maintain the system’s stability, security, and performance. Some of the key issues faced at this stage include:

• Architectural Complexity and Risk: Large changes to the overall architecture require work from many different teams and introduce significant risk.
  
• Cascading Failures and Amplified Outages: There are many ways for the system to fail, and often, failures in one component cascade into failures in many other parts of the system. Simple retries start to amplify outages rather than help alleviate them.
  
• Data Analysis Challenges at Scale: Analyzing data across all the independent parts of the system is incredibly difficult and requires new solutions to continue scaling effectively.

Internet of Medical Things (IoMT) development and medical software has additional challenges, especially at this scale:

• Stringent Security, Privacy and Availability Requirements: These can limit the use of third-party software and services that can’t meet those strict requirements. The third-party solutions that are available often cost much more to meet those requirements.
  
• Complex Integrations with Electronic Medical Records (EMR) Systems: Integrations with EMR systems, in particular, can be especially challenging due to various factors, including outdated standards, vendor-specific integrations, and extensive customization of data exchange formats. Our guide on IoT Cloud Integration with EMR Systems has some great advice and key considerations for EMR integrations with healthcare platforms.
  
• Compliance with Regulations and Audits: Companies may need to perform SOC 2 audits, which will uncover flaws in the system that need to be addressed. These audits are important to prove to stakeholders and customers that data is being handled securely. Some companies may also need to meet the European Union’s General Data Protection Regulation (GDPR), the California Consumer Protection Act (CCPA), or other regulatory requirements beyond SOC 2.

Cloud Architecture Strategies at the Maturity Phase

Customized Solutions

The approaches to projects at this stage become much more specific to the problem being resolved. They often require working closely with all the teams involved to find the right solution to avoid downtime and still provide the desired benefit. 

Strategic Breakdown for Large-Scale Updates

One approach we take for large-scale architectural changes is to break them down the same way we discussed breaking down the monolith into microservices previously. This might require many additional steps depending on the change being introduced but can provide a path forward by taking on the change in smaller pieces.

For example, when breaking down a service used by many other services into individual components, we break them out of that service behind the same interface as the original service. When teams are ready, they can then switch to calling the individual services directly, and finally, the obsolete endpoints can be deprecated. API Gateways and API versioning can be used to simplify this process and reduce the changes required of consumers of the service.

Enhancing System Resilience 

There are many different strategies to prevent failures within the system from cascading into bigger issues, all depending on the types and causes of the failures. 

For example, asynchronous messaging solutions can be used in place of HTTP requests and can store the request or response, preventing it from being lost even if either of the services crashes. However, this can make synchronous requests that depend on these queued messages more complex.

An alternative for requests that must remain as a synchronous HTTP request is to use a combination of different techniques to handle outages of that service, such as callers caching the last successful result and using the successful result if the system does not respond, exponential backoff on retries so the retries don’t overwhelm the affected service, and the circuit breaker design pattern. 

Data Integration Approaches

A solution for aggregating data might be to build a “data lake” by having all the key operations and data changes within the system fire events and then gather those events into a tool like Snowflake or Databricks to be queried. This solution is useful for exploratory analysis or using machine learning to generate insights from the data.

Another solution might be establishing a set of data standards for types of exposed data and having every system expose a GraphQL (or similar) endpoint that can be queried across systems. Then, create services that provide the necessary aggregated data by querying each relevant service. This second approach can require more changes to the system. Still, it can be cheaper than full-scale analytics platforms when the data is used to provide data to other parts of the system on demand or the queries being performed are predictable and known in advance.

Finalizing SOC 2 Compliance

Regarding SOC 2 compliance, many of the steps already mentioned can provide a good foundation and will have been implemented earlier in the project. What’s most important at this stage is verifying that everything follows those standards. For example, there may be user accounts without two-factor authentication enabled or applications not adequately isolated to a virtual network (vNet).

Streamlining Compliance Audits

Automated processes for auditing compliance with security and privacy standards should be enabled, such as Microsoft Defender for Cloud (formerly Azure Defender), Amazon’s AWS Security Hub, or SysDig. These tools automate the process of auditing many parts of the cloud system, which helps produce reports for audits and maintain proper security controls as new features are rolled out.

---

Final Thoughts & Key Takeaways

As your company grows, your cloud implementation objectives and requirements will evolve. Adapting your strategies to meet these changing needs is crucial for success. Understanding the specific challenges and priorities at each stage of your company’s lifecycle allows you to make informed decisions and allocate resources effectively.

Key takeaways:

1. Align your cloud strategies with your company’s current stage and anticipate future requirements.
2. Startup: Build a solid foundation in the startup phase, focusing on precise requirements, robust security, regulatory compliance, and cost optimization.
3. Growth: Scale your infrastructure, address technical debt, and maintain compliance during growth.
4. Maturity: Standardize processes, optimize performance, and ensure ongoing compliance in the maturity phase.

Applying the approaches and insights shared in this guide can help you navigate cloud implementation challenges and achieve your goals at every stage. If you or your team need expert guidance on cloud architecture, the Punch Through team is here to help you realize a scalable, connected ecosystem.

---

Related Articles

To further support you on your IoT cloud development journey, explore these additional resources: