Prepare for Your Medical Affairs Website: 3 Tech Tips

Here are some more basics for pharmaceutical companies and pharma marketing agencies that are beginning a medical affairs website project.

I sometimes joke that we’re plumbers at Workbox. Or maybe electricians. What I mean is that we build the stuff that you don’t always see but makes websites work. From that perspective, we’ll cover some of the issues that we’ve seen folks neglect or not consider up front when building a medical affairs website. Identifying and defining these issues early in the process will make your IT team, security team and dev partners very  happy – and definitely save time and money.

1. Domain, Directory, URL. This might sound obvious, but med affairs teams sometimes forget to tell their IT department or website developer what they’d like the actual URL or domain for the site to be. Here are the most typical types of domains or URLs that we’ve seen (we’ll use wbxpharma.com as the company’s main website domain):

1.1. Subdomain – Example: medicalaffairs.wbxpharma.com. The “medicalaffairs” part is the subdomain. It appears before the main domain (just like “www”). This is handy because you can create a whole separate site, and your IT team can create and manage the subdomain through their DNS service. Easy.

1.2. New domain – www.wbxpharmamedaffairs.com. This is a whole new domain. This technique is also handy because your IT team can purchase the domain for you, then you and your dev partner are off to the races. Also, easy.

1.3. Directory URL – www.wbxpharma.com/medaffairs/. This is the simplest way to create a URL. It can be done using your content management system and doesn’t require your IT team to get involved. This is best if your company only has a few products or just a small amount of medical affairs content.

2. Email delivery from forms. If you build a form on your site and want a confirmation, “thank you” or other type of email to be sent upon form completion, you should tell your IT team and/or web development partner about it right away.

Here’s why: Very few email delivery features on a web server are HIPAA/PHI compliant. However, you could possibly send HCP professional data via email (if it’s done right), but not PHI data.

Additionally, not all website platforms have email delivery set up for the web server by default. And if they do, you still might run into identity or security issues that could get your domain blacklisted (on top of HIPAA issues if your web server is not HIPAA-compliant).

So, discuss any form functionality with your IT team and dev team – before you get a final proposal from your vendors!

3. Form data storage. This is a biggie and can be a challenge. Or it can be very easy (at least for you). Really, we’re talking about data collected from (mostly) HCPs. A few options:

3.1. Veeva – Build an API and drop all your data into Veeva! This is what the cool kids do. And, it’s simple for the med affairs team because you won’t be doing the hard stuff. Your IT team and your dev partner will – but they’re built for this kind of stuff. Give them a chance to shine! Middleware could be something lightweight (Node.js, Python Flask, AWS Lambda). They’ll know what that means. 🙂

3.2. Amazon S3 – Again, there’s a good chance your company is already using something along these lines. A solid dev partner can work closely with your IT folks to make this work.

3.3. Other solutions – There are a few other ways to handle this, but the best solution is to leverage what your company already uses.

Note: We’ve encountered IT departments that have built great in-house data solutions (or have great SaaS partners) and are just waiting to help!