Due Diligence of Health IT Products & Companies by Investors & Acquirers

image: davudmamedov.com 

Since the ACA began in 2010, there's been a surge of venture capital investment in and acquisition of startups and companies offering technology-based healthcare products and services. In the continuum of a venture capital investment, you’ll frequently only hear about the dollar amount invested or paid and then, a few years down the road, an announcement of a profitable exit or abysmal failure; most often the latter. 

Two things you rarely hear about these investments are 1-What kind of due diligence was performed prior to making the investment? And 2-An analysis of what went wrong when an investment doesn’t pan out successfully due to some unanticipated technical or operational issue.

What Do I Know?

Over the last 20 years, I’ve been involved with investment and acquisition of health care IT products and companies in three different capacities:

1. As an employee tasked with providing a potential investor with details about IT systems and operations

2. As a consultant charged with investigating the systems and capabilities of a potential investment

3. As a founder on the receiving end of a firm reviewing my health IT software for a possible acquisition

Given my focus on healthcare data, technology and services, I thought I’d share some ideas and experiences regarding critical areas of the information technology due diligence process which I believe investors and acquirers should complete BEFORE a decision to invest in or purchase a company is made.

Areas Where Due Diligence is Important

Architecture and Technology Stack
The architecture of the system providing the functionality being purchased has considerable impact on the quality, performance, maintainability, and overall success of the application. A poorly architected system comprised of multiple different types of databases and development languages can hamper system extensibility and functional scalability. Moreover, a hodgepodge of technologies may require support from specialized, costly resources.

Software Development Environment
The facilities and capabilities for developing and maintaining system functionality should be reviewed. The manner in which software versions are maintained, built and deployed should be well understood, controlled and hopefully documented. Moreover, the outfit should utilize an established requirements definition, design, development, testing and deployment methodology or practice.

3rd Party Software, Data and Interfaces
Review and understand how software and data originating from 3rd parties – including open source artifacts - are incorporated in the overall system. Startups (and established firms!) can be lax in their licensing and how they use 3rd party libraries and/or data. Consider the cost and legal implications of all 3rd party artifacts. Also review any interfaces to 3rd party services to understand currency and licensing aspects.

COTS Major Releases and Maintenance Schedules
If the software system uses a Commercial Off-the-Shelf product in any capacity, understand which release is being used and what newer releases and/or maintenance releases may be available. Be clear on how long the current release will be supported and the cost/timeframes for upgrading.

Testing and Model Office Environments
Some companies may not separate their development, testing, model office and production environments. This can create a host of issues. Ideally a firm should have a separate environment for each of these four necessary environments; or at least clear procedures on updates are made and how data is moved between the various environments. Look into how each environment is maintained and any costs associated with each.

Staffing & Resources
Suggest talking with the people who develop and support all software written in-house. What type of turnover exists within the development and support staff? Make sure there is a backup for any hero developer in case she gets hit by a truck.

Knowledge & Intellectual Property Management
Along with properly managed source code versions noted above, what other type of documentation and artifacts exist that can be used to understand, support and extend the software system? Who owns/maintains these artifacts? Where are they stored and who has access to them?

Support Services
How is first and second-level application support provided? Ask to see a list of completed and outstanding ‘trouble tickets’ and maintenance requests. If the company doesn’t have this, that’s a red flag in itself. Also look at 3rd party agreements with 3rd party contractors and external IT support agencies.

HIPAA Security & Privacy Risk
Have all staff been educated about HIPAA? Are business associate agreements in place for external resources? What type of data is used for testing and product demonstrations? The use of unmasked production data in test systems is a common and risky practice.

Summary/Closing
The above are just a small sampling of the types of technical due diligence that investors and acquirers of health information technology product companies should consider. The best idea with high sales projections can be rendered a huge liability if basic IT systems and operational aspects are not in place.

For more information on healthcare data, technology and services, feel free to contact me and/or follow me on Twitter.