Consolidation in Healthcare – What can we learn from it in IAM?
A few months ago, I wrote a few blogs about trends in Healthcare and why these were making Identity a top of mind issue in the Healthcare sector.
As we continue to work with clients in Healthcare, we are seeing that many of the trends we had identified are at play before our eyes, and from this experience, we see patterns that may very well apply to other industry verticals outside of Healthcare, and as you would suspect, we are myopically focused on what these means to identity.
The main trend in healthcare that we see is Consolidation. It is happening at all levels. Healthcare organizations are growing through M&A - and the intensity of activity seems to be increasing in 2012. This triggers the consolidation of different medical offices, hospitals and long-term care centers into a larger healthcare system. And with this comes the need to consolidate clinical, financial and ancillary systems to achieve consistency and economies of scale.
In turn, this trend has translated into intense M&A activity in the Healthcare IT space – examples such as the acquisitions done by AllScripts, Siemens Healthcare, GE Healthcare Systems in recent years. In a way, these acquisitions are forcing consolidation and standardization across EMR, EHR, PACS, Pharmacy and other systems. Healthcare CIOs are really busy working with their Clinical Informatics team, and their vendors to figure out which systems they should standardize on (regardless of whether or not the Healthcare organization is embarking on M&A activity itself).
What does this mean to IAM then?
As I once explained in a prior blog, IAM is relatively new as a discipline, managed as a program in healthcare. For many organizations, Chief Information Security Officers are in their first or second year at the job, since it was just created. And as such, many organizations are struggling with how to scale their IAM platforms (in the event they even had one) to keep up with the consolidation and growth that the organization is likely experiencing.
IAM budgets in Healthcare are very tight, which makes keeping up with these trends particularly challenging and exciting at the same time.
So what is an identerati to do?
- If your organization is embarking on an M&A and business application consolidation strategy, you should view IAM as an enabler, rather than a barrier for the organization to execute this strategy. IAM will be front and center of the action. Therefore, you should have a defined IAM program with a governance model in place
- You need to have a practical data or application classification methodology which can help you figure out which system or application needs to be integrated with IAM first and to what degree (i.e. automated vs. manual provisioning, local or externalized authentication, local or externalized authorization). We recommend that you define an “application grid” in which you map risk levels to a set of IAM integration requirements that the application will need to satisfy. This will help you devise a scalable and repeatable way to bring applications under governance. I recommend to customers that they define a risk/assurance level approach to classifying and tackling applications. This way it is easier to manage the IAM-fication of applications at a program level.
- When it comes to managing access, truly consider roles-based model. Managing at a granular level may not be practical, and is certainly not scalable. Often, organizations think that they are not ready to adopt roles management when in fact they need them badly. I discussed this topic in a past blog. But if you need to integrate new medical staff offices and hospital into the consolidated EMR or EHR system, your IAM program will be better served by mapping the new organizations to existing roles that are defined and likely integrated with the IAM access request, approval and provisioning system. To make decisions as to how the mapping should be done or whether new templates or roles are needed, involve the business stakeholders! Avoid, at all costs, having IT make decisions about who should have what access in the application, let alone approve such access. IT is a facilitator not an owner. There are some corollaries to this point that are worth discussing:
- If you end up being too granular, you won’t scale – it will be hard for end users to manage access for their users (i.e. managers will get confused), and it will be really hard for the IAM program to scale and not lose momentum.
- Are you really that unique? For many organizations, defaulting to a myriad of access permutations is typically given as justification since "the organization is that unique". In my experience working with hundreds of organizations, I have found quite the opposite: most organizations, particularly in similar industry verticals have a lot in common, and rather than managing access by exception, would be much better off managing by roles.
- If you are really that unique, do you need to be? Having to accommodate so many access permutations to systems may be indicative of bigger business issues which will likely result in increased complexity, which will be contrary to the desired state of an M&A growth strategy. To be agile in integrating and consolidating, you will need to divide and conquer, and that means you have to define common business processes that can be manageable and that can scale. IAM is no exception. So feel free to challenge the business when you see complexity getting out of hand.
- The more permutations you need to manage the more fun your auditors will have when assessing the effectiveness of your access controls, particularly for highly visible, highly sensitive systems.
In summary, a risk/assurance application categorization model along with a pragmatic roles-based access control model for managing user access to applications are the key elements in helping your IAM program achieve scalability, and this is not exclusive to an industry vertical.