While a due diligence effort involving a healthcare IT company will be focused on the same issues as a company in any industry, there are additional areas that must be investigated.

Many of these issues revolve around the requirements of the Health Insurance Portability and Accountability Act (HIPAA), which mandates various security and privacy requirements for “covered entities” and “business associates.” Generally speaking, a covered entity is a healthcare provider, clearinghouse or insurance plan. HIPAA defines a business associate as “a person or entity that performs certain functions or activities that involve the use or disclosure of protected health information on behalf of, or provides services to, a covered entity.”

“Protected health information,” or PHI, includes data elements such as patient name, address, identifiers such as Social Security Number, patient account number, medical record numbers, etc.

One focus of HIPAA is the security of PHI “in motion” and “at rest.” PHI must be encrypted at all times, whether it is being emailed, uploaded to a website, viewed in a web browser or simply sitting in a database. HIPAA also restricts data access to users on a “need to know” basis. These factors have serious implications for the design and operation of software and other technology in the healthcare space.

An acquiring company or investor must be conscious of the issues around HIPAA when conducting an IT due diligence engagement. The effort and cost to address shortcomings when it comes to systems that deal with PHI can be significant. Systems that don’t properly protect PHI can open the provider of the system up to significant potential fines and penalties under HIPAA, not to mention serious damage to its reputation.

Some specific areas of investigation in a healthcare IT due diligence effort include the following.

• Does the technology staff have experience working with PHI? If not, is there a healthcare domain expert available who is providing guidance to the technology team? Has the technology staff received HIPAA training to sensitize them to the relevant issues?
• How has the encryption of PHI been addressed in the company’s tools and systems that utilize this data? Are all network and Internet connections encrypted (using SSL, for example)? Is any data sent over an unsecured protocol, such as standard FTP?
• Are the databases encrypted? This is an area where many companies fall short, as it can be expensive and/or difficult to accomplish PHI encryption while at rest in a database.
• Do the software products provide for the flexibility to display PHI only to those employees that have a need to know? Does the software provide audit capability to indicate which users have viewed specific PHI?
• Do employees copy or use PHI on their laptops, external hard drives or USB / thumb drives? Are the laptop hard drives and external storage devices encrypted? Lost or stolen unencrypted laptops are probably the leading cause of a HIPAA breach. If the laptop is encrypted, however, no breach has occurred even if a device is lost or stolen.
• If PHI is stored on a company network, are the network drives encrypted? Are appropriate access rights set up so network users have access only to the PHI that they need for their work?
• Are remote access systems such as VPNs properly encrypted? Does the target company have a written policy against storing PHI on laptops and other devices not provided by the company?
• Is PHI transmitted to mobile devices? If so, how is it encrypted? What policies and capabilities are in place in the case of a lost mobile device? Can the device be remotely wiped to ensure there is no chance of PHI being lost along with the device?
• You should pay particular attention to how user logins and passwords are stored in systems. Is there proper security and encryption in place? It doesn’t matter if PHI is encrypted in the system if a user login and / or password can easily be obtained and used.
• If the target company utilizes outside services such as a web hosting company or email provider, does the third party understand HIPAA issues?

HIPAA is complicated, and this article merely scratches the surface of the issues involved. The main takeaway is that there are special considerations involved in a due diligence effort involving a healthcare IT company. These issues can be easily missed by even a seasoned IT expert without healthcare experience. Therefore, it’s critical that an investor utilize an experienced healthcare IT professional when evaluating a technology company that deals with PHI.

In addition to the PDF version of the eBook available on this site, the IT Due Diligence Guide is now available for the Amazon Kindle. You can purchase it here.

In too many M&A transactions, even those related to software and technology companies, IT due diligence is, at best, an afterthought. I’ve even been involved in deals valued in the high eight figures where IT due diligence accounted for, maybe, 1-2% of the overall due diligence effort. There is no doubt that financial and legal due diligence are critical, but IT concerns too often receive insufficient consideration. This article will explore the top 10 reasons to conduct IT due diligence when acquiring a company.

1) Be Sure the Technology is Real

A financial or legal expert simply can’t tell if a target company’s product is real. You can’t rely on a PowerPoint presentation or even a product demo. It’s too easy to create something that looks great but doesn’t do what it’s expected to do. Ideally you will have an expert in the target company’s specific technology review source code, product plans, etc. At a bare minimum, you need to have a technical person sit in on a demo and ask questions, but that’s no substitute for a source code review.

2) Determine the Technology’s Compatibility

Even if the technology is real, you need to know if it’s compatible with the acquiring company’s technology. If the target company uses leading edge or proprietary technology, it may not integrate easily, if at all, with the acquiring company’s legacy systems. This can have serious ramifications for the integration of the companies, the maintainability of the software and the retention of key employees at the target company.

3) Establish the Technology’s Scalability

If you determine that what you’re acquiring is real and is generally compatible with the acquiring company’s technology, it’s important to consider the scalability of the technology. How will the software or systems behave if the number of customers doubles, or increases tenfold? Will the technology expand gracefully with a low marginal cost, or will significant growth require a large investment in new servers or other hardware? In the worst case scenario, a complete re-architecture of the technology may be required. Even if this doesn’t kill the deal, it represents a cost that needs to be uncovered and may impact the terms of the transaction.

4) Uncover Licensing Risks

It’s not uncommon to find that a startup or small technology company has not properly licensed all of its production or development software. It’s not always intentional – in the frenzy of getting a product developed and into the market, any number of administrative tasks can fall by the wayside. Whatever the reason, at some point the fact that additional licensing costs are due will come to light. You want it to be before the transaction closes, not after closing or the expiration of any holdback period for reps and warranties.

5) Explore the Compatibility of Company Cultures

IT due diligence includes interviews with some or all of the target company’s technology staff. Through these interviews, you can get a good feel for the personalities involved. Will they work well in a larger organization, if that describes the acquiring company? If these are important employees, you may need to put employment agreements or retention bonuses in place to be sure the key players remain post-transaction.

6) Determine the Appropriateness of Current Levels of Resources

Many smaller companies scrape by with minimal resources when it comes to things like networking and other IT infrastructure. Has the target company put off making needed investments in order to artificially inflate profitability? Are you confident that your legal or financial experts would notice?

7) Identify Opportunities for Cost Savings

By the same token, technical knowledge is needed when it comes to determining a realistic level of synergies in the transaction. Don’t assume that simply because both the acquiring and target companies have data centers, you’ll be able to combine them after the deal occurs. Are you sure the technical platforms are compatible? Can you evaluate the skill sets of the target company’s IT staff to determine if there is any overlap with the acquiring company’s staff?

8) Discover Hidden Gems

It’s not unheard of that the technology staff at a company is working on projects that the senior management of the company isn’t aware of. These experimental projects aren’t likely to end up in the target company’s CEO’s PowerPoint of company products. The right technical expert can make the connections between these “secret projects” and the strategy and technology of the acquiring company.

9) Verify that the Technology Can be Supported

This broad area includes basic things, such as whether or not the target company has a clean copy of the source code for their technology, or whether they own the rights in the first place. These issues come up more often than you might think. Even if there is s viable copy of software source code and all ownership rights are in order, are the people who wrote the software still employed by the target company? Don’t expect any of this information to be volunteered – you have to look for it and you can’t make any assumptions.

10) Reveal Important Integration Issues

Let’s face it – most transactions that get to the point of a serious due diligence effort eventually close. After the deal is done, the real work of integration begins. IT due diligence provides a critical opportunity to get a head start on the identification of issues, planning for solutions and development of an execution plan for the integration of the target company.

These are just some of the most important reasons to conduct an effective IT due diligence effort. The IT Due Diligence Guide provides the questions to ask to get at this information as well as an explanation of the answers you receive. Having a technology expert on the due diligence team is the best solution, but when that’s not possible, the IT Due Diligence Guide can go a long way towards increasing your appreciation of the IT concerns involved in your transaction.

As you can see, we’ve just added a blog to the website.

I’ll use this blog to discuss IT due diligence issues that are in the news, and I’ll also respond to questions and comments on the subject.

If you have a question about IT or software due diligence, send me an email at jhoffman@itduediligenceguide.com.