Top 5 Technical M&A Challenges for Healthcare and Life Science Customers

Introduction

During Mergers and Acquisitions (M&A) activity, Healthcare and Life Science (HCLS) customers face additional administrative challenges integrating the technical, legal, and business systems of the target and acquirer companies. For non-technical stakeholders (business administrators, financial and legal departments, private equity parties), it is important to understand the technical challenges of integrations that will impact the transition period post-close. For acquirers it is important to understand if additional contractual protections are required to mitigate risk posed by the target’s poor data privacy controls. The purpose of this blog is to provide guidance for HCLS customers on some of the technical challenges that arise during Mergers and Acquisitions (M&A). Specifically, this blog will highlight best practices for pre-close investigations of a target’s cloud usage and deployment and challenges to be aware of during post-closing integrations. The goal is for non-technical stakeholders (business administrators, financial and legal departments, private equity parties) to understand the importance of technical challenges of integration that could impact the transition period post-close. The narrative will dive into the top 5 challenges: (i) compliance, (ii) minimizing patient and customer disruption, (iii) data strategy, (iv) corporate cloud governance and (v) technical debt.

Top Five Challenges:

1. Compliance considerations

Throughout the M&A process, it is important for both businesses to consider potential antitrust issues, intellectual property disputes, compliance postures, and contractual obligations that can impact the transaction. Conducting a technology due diligence (TDD) assessment involves auditing a company’s people, product, IT infrastructure and processes. The TDD will also analyze the target’s current inventory, and compliance gaps between the target and acquirer Additionally, depending on the investment thesis (a document created by the acquirer which lays out the rationale for acquiring the target), there may be additional compliance considerations and stipulations which require a level of compliance completeness that must be met before the acquirer’s investment committee or board will approve the transaction. To ensure the target is aligned to these considerations, a gap analysis should be performed to build a post-closing integration plan detailing what compliance gaps need to be remediated before integration. For example, if the acquirer has HITRUST certifications and the target does not, the acquirer should consider attaining HITRUST certifications for the target before the two companies’ workloads are integrated. Once the technical integration is complete, it’s likely there are substantial changes to the acquirer’s workload needed, which could require another recertification.

With the growing popularity of generative AI technology in the HCLS industry, there is a likelihood that the target uses generative AI in some form. The acquirer needs to assess the target’s chosen model providers’ terms of use (or other agreements governing the target’s use of AI), especially if the target uses generative AI for core workloads or for workloads that will be integrated with the acquirer’s systems. These terms of use are commonly found within the model provider’s end user license agreement (EULA) or acceptable use policy (AUP). For example, some generative AI model providers require users to implement human review when using their models for certain use cases. The acquirer should verify that the target has been in compliance with the applicable EULAs, AUPs or other terms of use and that the acquirer can continue to comply with such agreements and terms post-closing.

Lastly, if the target is using AWS services to store or process protected health information (PHI), then the acquirer should validate that the target has entered into an AWS Business Associate Addendum (BAA) for all AWS accounts which process and store PHI. This can be accomplished using AWS Artifact. The acquirer should also confirm that the products the target runs on AWS are on the HIPAA Eligible Services Reference and, if required, listed within the services in scope for HITRUST CSF.

AWS services can help organizations improve compliance technical due diligence. AWS Audit Manager can be used to map compliance requirements to AWS usage data with pre-built and custom frameworks and automated evidence collection. Leveraging services like Audit Manager can help avoid manual efforts and help create stronger visibility across AWS accounts. To see other ways Audit Manager can help organizations with technical due diligence, please read this blog. Additionally, the whitepaper found here provides information on how AWS approaches Good Manufacturing Practice, Good Laboratory Practice, and Good Clinical Practice (GxP) related compliance and security and provides customers with guidance on using AWS products in the context of GxP. Finally, please see this blog on how to get started in preparing for an audit.

2. Minimal patient and customer disruption during acquisition and integration

To protect your new investment, a top priority should be maintaining continuity of care and quality of service throughout the acquisition and during the post-close integration period. Significant downtime or patient disruption could cause a significant backlash by end users, or worse, negative patient outcomes. Patients should experience no lapses in their medical treatment, prescriptions, appointments, etc. To achieve this, the acquirer must thoroughly review the target’s operations, services, and patient population and develop a detailed integration plan that protects ongoing patient care.

One area to not overlook is how important core services such as electronic health record (EHR) systems or alternative data lakes such as AWS Healthlake integrate with each other. The acquirer should assess compatibility of their workloads with the target company’s and pinpoint any integration challenges early on. For example, if the acquirer uses AWS Partner InterSystems for FHIR transformation as the main mechanism to enable interoperability whereas the target uses AWS partner Redox for HL7 and FHIR. Alternatively, if the acquirer or target have rolled their own solutions and created bespoke interfaces, this is subject to technical debt limitations. If systems are incompatible, or fragile to extend, consider a phased integration approach to avoid suddenly cutting off access to patient records, etc.

It is recommended that patients receive clear communication about changes that may disrupt uninterrupted access to their records or to their physician. Protecting sensitive patient data is also critical during an acquisition. Transparency about expanded data usage and new privacy practices can help maintain patient trust. The acquirer should validate the target’s disaster recovery and business continuity plan, and how they have achieved technical safeguards in the cloud. It is important to ensure during data migrations or new integrations that data and associated backups are immutable, and not at risk of accidental modification or deletion.

Additionally, the acquirer’s acquisition plan should ensure no disruptions to patient access to facilities, equipment, medications, devices, etc. Patient support services like billing, scheduling, and customer service should continue operating smoothly as backend systems merge. Customer service staff should be well informed to address questions and concerns. Keeping patients’ interests first and communicating transparently are critical to an acquisition that enhances, rather than detracts from, the patient experience.

Lastly, another area not to overlook is the transition of AWS account ownership structure. For example, if the target has an AWS payer account and several linked accounts, or if there’s a series of regular accounts. It is important that billing information is updated immediately to reduce the risk of an account being limited or suspended and associated downtime risks. This post within the Amazon Web Services knowledge center provides prescriptive guidance on how to migrate accounts to a new business or organization. This blog post also lays out common challenges when it comes to migrating accounts with service control policies, etc. One of the most commonly overlooked items in an acquisition is not updating billing information and enabling the correct invoicing of production systems.

3. Data Strategy: future looking and abstracting from current systems

It is important to evaluate a data strategy during an acquisition regarding integrating the data to ensure data security and data durability. A common challenge with companies that grow through acquisition is simplifying publishing and the consumption of data across their ever-expanding platform with improved confidentiality, integrity, and availability. This is compounded by systems which require a Single Point of Truth (SPOT) versus the ability to have Multiple Versions of Truth (MVOT). It is important for the acquirer and target to understand what constraints are there today, which need remediation, and which need analysis for a repeatable process for the next acquisition. Careful planning is required to integrate data between HCLS companies during M&A, because of the particular complexity and sensitivity of existing data architectures, formats, and platforms of HCLS companies. Establishing the desired level of data consolidation requires evaluating the current data landscape in each environment and determining where data will live post-merger. This will help decide if the companies’ data will remain separate or consolidated for joint customer research efforts. Additionally, as each line of business grows organically over time, data will scale accordingly; this creates the challenge of proactively designing systems that will scale cost effectively and reliably. To aid in integrating varying data sources and systems, modern data strategies implement a data mesh architecture. A data mesh architecture enables a publish-subscribe methodology that decouples data, enables seamless data sharing, and promotes federated governance. To learn more about building a data mesh architecture on AWS, reference this blog.

It is also important to identify when the acquirer, or the target, is the data processor and when it is the data controller. This ensures that personal data is handled responsibly and in line with the acquirer’s compliance policies, investment thesis and applicable privacy regulations. For HCLS customers, ransomware attacks can cause data loss and create substantial liabilities throughout the M&A lifecycle. Customers must prioritize data security, privacy policies, and patient consent. Failure to address these incidents delays the merger, incurs additional costs, and adversely impacts their ability to attract and retain customers, partners, and investors. To mitigate data exposure risks during M&A activities, companies need robust processes to safeguard PHI, prevent unauthorized access, and maintain data integrity through sensitive information protection and access control measures.

AWS provides over 200 services and offerings to help customers with data strategy challenges and creating data mesh architecture. Please reference this AWS document detailing how HCLS customers can create a data mesh on AWS.

4. Corporate Cloud Governance

Shadow IT is the use of unauthorized software, applications, devices, or services by employees within an organization without the knowledge or approval of the IT department. This concept is an increasing risk for enterprises. When acquiring a target, it is important to evaluate their entire IT footprint, not just their primary cloud. For example, an acquirer should understand if the target’s IT footprint duplicates any of the acquirer’s IT use so it can focus on third-party (3P) tool consolidation (e.g., both companies pay for an enterprise observability platform). Doing so will help simplify governance, risk and compliance of your IT footprint.

Governance strategy is a core point of contention when merging companies together. There are permissions management strategies owned by each company, as each designs its own policies to define access to IT infrastructure depending on internal compliance requirements. Coming to an early agreement on the necessary governance standards across the full unified business post-close mitigates potential risks to the integration timeline and ensures security best practices are in place. For HCLS customers, corporate cloud governance is important given the sensitive nature of data that HCLS customers typically manage (e.g., patient data). Access controls need to be in place to ensure the right teams follow a principal of least privilege by only giving a user/entity access to specific data or resources needed to complete a required task. Additionally, team structures often shift during acquisitions, so clearly defining how cross-team collaboration will look long term is important to consider. Cloud governance also includes cloud cost management strategy, including building cost-tracking mechanisms and ensuring there are key owners of the cloud operations cost. A final consideration in corporate cloud governance strategy is to stay up-to-date on data sovereignty requirements. These specifications can be both internally defined for end users or externally defined by the government structures of the nation where data is collected. A change in governance must be weighed under the requirements of the Health Insurance Portability and Accountability Act Privacy Rule and General Data Protection Regulation’s data minimization principle. What is acceptable at a company of <200 employees may not be justifiable at a company with 2000 employees. As the size of the overall business scales out, operational and technical safeguards need to be added to adhere to governance and data sovereignty requirements.

There are options in the AWS cloud to create a single pane of glass for cloud governance (for more information, see the recent collaboration between AWS Audit Manager and MetricStream CyberGRC). Another solution is leveraging AWS Trusted Advisor to get a baseline of whether both companies have a strong governance posture to begin with, and fill any gaps strategically.

5. Technical debt

Growth through M&A increases the likelihood of acquiring technology which is designed and built in a manner the acquirer’s engineering team does not agree with or uses technical stack they’re not experienced with. This is typically called technical debt, and sometimes referred to as code debt. This requires additional remediation costs to upscale an out-of-date, unfamiliar, or difficult to maintain tech stack. Estimating and understanding a company’s technical debt and modernization needs is an important consideration for future time and cost implications, bringing infrastructure up to speed. Beyond the cost of updating a tech stack, technical debt also puts reliability, scalability, and product expansion plans at risk. It can cause delays in the rollout of new features as teams struggle to innovate and bring the older tech stack up to speed simultaneously.

A few considerations with tech debt for the HCLS industry include:

• Create an inventory of the tech debt and understand deprecated or outdated code languages and code dependencies in use. For example, an outdated version of java running in workloads being integrated into acquirer’s systems indirectly increases their attack plane and security risk. It is important for the acquirer to understand risks from code with Common Vulnerabilities and Exposures (CVE) and the appropriate remediations steps.
• Understand what data is being transferred and how that data is protected, such as through encryption in transit and at rest. Ensure deprecated mechanisms such as TLS 1.0 are not being used and that the level of encryption is suitable for your industry. This is required for HCLS industries to keep sensitive health information private and encryption is essential in protecting medical data and patient information.
• Identify the feasibility of tech stack maintenance, and what burden the acquirer will inherit from the target’s workloads. It can be difficult to extend to site reliability engineering policies and monitoring processes if systems are tightly coupled. It is important to conduct a gap analysis to understand if existing employees’ skill sets can adequately maintain and extend to inherited technology or if employees need to be retrained or new employees hired.
• Investigate how tightly coupled technical debt is. Depending on this investigation, the acquirer and target put time into modernizing their technology to simplify future integrations, or acknowledge it has reached the end of its life and that replacement systems are needed to be scoped and built. As companies accumulate more and more technical debt over time, the cost of remediation scales accordingly. If the target’s architecture is more advanced than the acquirer, the acquirer will need to inherit this technology and maintain it if the documentation and skill-sets are not present.
• Understand the long-term commitments within each company’s tech stack. Investigate if there are any expiring contracts with 3P IT providers or cloud agreements within the target’s cloud footprints. Identify how the scope of these agreements compare to the acquirer’s. For example, within the AWS cloud there are AWS reservation instance for EC2 compute which provides up to 72% discount with a capacity reservation for 1- or 3-year compute commitment. It is important to understand these timelines before initiatives to modernize are finalized and implemented. Also, evaluate if there are any exit clauses within 3P contracts that may be rolled into the acquirer.

Companies can leverage AWS to help alleviate tech debt with purpose-built managed service offerings focused around serverless technology that allows for AWS to handle the undifferentiated heavy lifting that comes with hosting, capacity, version upgrades, etc. This can help technology teams focus on their business differentiators.

Conclusion

In this blog we identified the top challenges with M&A activity and post-closing integration in the HCLS industry. This overview identifies how the acquirer can align their business goals and what to watch out for in terms of risks to the post-closing integration timeline, agility of systems and pace of innovation. To further understand how AWS can help with M&A, please reference the Executive Insights page to learn about programs available and perspectives from leaders on the intersection of business and technology.

About AWS Mergers & Acquisitions Advisory

The AWS Mergers & Acquisitions Advisory (AWS M&A Advise) and AWS Private Equity Investments, Mergers and Acquisitions (AWS PE iM&A) Teams are groups of subject matter experts at AWS that provide a suite of complimentary advisory engagements to AWS customers engaged in M&A transactions. Please reach out to the teams through your organization’s aligned AWS Account Manager with this link.