Contact Information vs. Protected Information in CRM

I was recently asked a question by one of our customers at major health insurance company. She asked, “Can we join our 8 million membership records with our Dynamics CRM contacts?”

Think about it. How nice would it be to have your CRM prospect database updated with millions of
new individuals, including their birthday, spouse information, maybe even some demographic data for target marketing? With mobility solutions you could have potential customers a smart phone away. Too good to be true?

Most of our customers establish “Contact” databases during the first phase of their CRM implementation. Decision makers, human resource administrators, influencers and referrals. Those contacts are made up of data that may have come from business cards or existing electronic documents, maybe even a purchased list of marketing leads. But as with most things in the healthcare industry, there are rules. The point of this post isn’t to cover what is and is not Protected Health Information (PHI) and covered in the HIPAA and HITECH legislation. To be honest, most lawyers in the industry seem to have different takes on that subject.

From a CRM perspective, we do draw a line between the two types of information. When the data originates in the healthcare realm, we store that information via entities related to, but not included in the Contact record. This allows us to implement security that is consistent with HIPAA or a company’s existing systems access policies. For example:

A contact: John Smith, CEO of Acme Corp. is listed as the primary decision maker in his Contact record in CRM. Sales reps use that information during the normal sales and marketing process. But John Smith is also a member of his company’s Group Health Insurance Plan. He also has an Accidental Death & Dismemberment Policy through a subsidiary of the Health Plan Carrier.

While we have 3 distinct records we may want to manage, or at least relate, in CRM – two of those contain protected information. We can create  “Member” and “Policy” entities and use security to limit access to those records to only the users that need it in the administration of the policies and plans.

  • Contact (Visible to all CRM users)
    • Member Record 1 (PROTECTED)
      • Policy Record 1 (PROTECTED)
    • Member Record 2 (PROTECTED)
      • Policy Record 2 (PROTECTED)

An alternative model, that utilizes form-level security at the Contact level, would be:

  • Contact (Visible to all CRM users)
    • Member data (visible to specific security roles)
      • Policy Record 1 (PROTECTED)
      • Policy Record 2 (PROTECTED)

OK, now my disclaimer: All use of data in the healthcare realm is managed according to, not only federal and state legislation, but also legal contracts and company policies. The above is only to illustrate two of many CRM configuration options.