Capital S Consulting
Medical Affairs CRM Your Scientific Team Owns
Your MSLs' KOL interactions, medical information requests, and adverse event intake belong in a system with a queue, a record, and a firewall. That is what we build
KOL Interactions Do Not Belong In Spreadsheets
Most medical teams inherit their tooling rather than choose it. The KOL list is a spreadsheet, the interaction notes are in somebody's personal notebook, and medical information requests arrive in a shared inbox nobody owns, while compliance expects every scientific exchange to be documented and retrievable. We replace that with a system your medical team shapes: the KOL model, the interaction types, and the workflows built around how your team works, with the commercial separation designed in from the start. It is one piece of a rare disease launch platform and it runs on the same foundation as our pharmaceutical CRM work
What The Medical Team Inherits
Nearly every pre-launch medical affairs group we meet is running some version of the same four tools. They hold up until the KOL network grows, or the first MSL changes territories
KOL Lists In Excel
One spreadsheet per therapeutic area, versioned by filename. Engagement tier lives in a column that means something slightly different to each person maintaining it
Interaction Notes In OneNote
Scientific exchange history sits in personal notebooks. When an MSL moves off a territory, the relationship record leaves with them and the next hire starts cold
Medical Information In A Shared Inbox
MIRFs arrive as email and get answered by whoever opens the message first. No queue, no due date, no audit trail, and no way to see what was asked twice
Adverse Events Forwarded By Hand
Intake depends on someone remembering to forward the message to safety inside the reporting window. That is an exposure, not a process
Connected to Commercial, Behind a Firewall
Medical and commercial sit in one Salesforce environment without the separation thinning out. The two sides pass work back and forth and share the same provider records, while the medical detail stays on the medical side
The Field Can Submit To Medical
A commercial rep takes a question they are not permitted to answer and submits a medical information request from their own screen. It routes to the medical team member assigned to that therapeutic area, and the rep sees that the request was received and closed, nothing more
One Queue, With Aging Visible
Medical information requests and adverse event reports arrive in a queue with owners, due dates, and a full trail. Medical leadership sees what is open, what is aging past its window, and how turnaround is tracking, without asking anyone for a status update
Shared Provider Records, Separate Medical Detail
Both sides work from the same provider records, so nobody maintains two versions of the same physician. Scientific exchange notes, KOL tiering, and medical information detail stay invisible to commercial, enforced by sharing rules and permission sets rather than by policy
The Medical Affairs Build, Piece By Piece
Each build is scoped to what your medical organization does today on Salesforce Life Sciences Cloud. This is the full range we deliver, and a first phase usually uses four or five of them
KOL Data Model And Tiering
Key opinion leaders logged with specialty, institutional affiliation, research interests, and engagement tier, on a data model that still works when the network outgrows what a spreadsheet can hold. Your medical team identifies the KOLs and sets the tiering criteria. We build the system they are tracked in
Scientific Interaction Tracking
Medical and scientific interactions logged by field medical staff, with scientific exchange documented on the record itself. Interaction types and the fields on each one are configured to your medical team's preferences rather than fixed by a template. Structured enough to report on, light enough that MSLs still use it in month six. If logging a visit takes longer than the drive home, it does not get logged
Field Medical Planning
Territory and coverage planning views for the MSL team. Medical leadership sees coverage the way sales leadership sees territories: who is assigned where, which institutions have gone quiet, and where the tier-one KOLs sit relative to the people responsible for them
Medical Information Request Handling
MIRF capture, routing rules, and a standard-response library housed in Salesforce, with responses sent from the platform so the question and the answer live on one record. Later, once commercial exists, field reps submit MIRFs from their side of the environment and the medical team works them in the same queue
Adverse Event And Product Complaint Intake
Intake captured wherever it appears, whether that is an MSL visit, a medical information call, or a rep interaction, and routed to the right function inside the reporting window. Your validated pharmacovigilance and safety database stays your system of record. The intake routing is the integration point
Non-Promotional Scientific Communications
Approved-content email and multi-step campaigns to providers, run from your marketing platform (Customer.io through its native Salesforce connector, for example) with engagement reflected back on the CRM record. Medical communications stay non-promotional and stay separate from commercial sends
The Commercial Firewall
Role-based access active from day one, then the full commercial and medical separation configured when the commercial organization enters the environment. Call plans do not surface medical interaction detail. Scientific exchange notes do not leak into targeting. The platform enforces the boundary rather than a policy document nobody reads
Expanded Access Support
Expanded access programs usually run through a third-party partner, so the patient's identity stays with the partner and out of your systems. We capture provider inquiries from your intake channels and route them into the partner's intake process, with your medical team keeping sight of the queue without holding PII. When the program winds down, the transition to commercial is planned up front so nothing identified has to move into your environment
AI-Assisted Trend Detection
Logged MSL interactions and submitted medical information requests are scanned over a time window you choose, so themes in field medical activity, recurring scientific questions, and adverse event signals show up as a summary instead of waiting for someone to read every record
The Relationship Record Cannot Start Over At Launch
In a rare indication the treating community may be a few dozen physicians nationally, and your MSLs have been in scientific exchange with them for years. Interaction history, inquiry patterns, and the questions still open should not restart when the commercial organization arrives. That history is one of the most valuable assets the firm owns at launch, and it is also the one most likely to be sitting in somebody's personal notebook. Because a rare disease medical model rarely resembles anyone else's, the system is shaped to your therapy and your team rather than fitted to a template. This sits inside our wider rare disease CRM work
Why Medical Leadership Teams Work With Us
The Build Follows Your Medical Model
Your KOL model, your tiering criteria, your interaction types, and the workflows your team already runs on. We configure around them instead of asking a medical organization to adopt somebody else's process. Two medical teams in the same therapeutic area rarely want the same screens
Compliance Separation Is Structural
The commercial firewall, adverse event intake routed inside the reporting window, and audit trails an inspector can follow belong in the initial security model. Retrofitting a firewall onto an org that never had one is the expensive version of this project
Connected To Commercial, And Kept Running
Field reps submit medical information requests into your queue, and non-promotional engagement comes back on the provider record. After go-live we run and refine the system under life sciences managed services, for as long as the program runs
Frequently Asked Questions
Can we run this medical-only, without a commercial CRM in the same environment?
Yes. The Salesforce environment can start medical-only and stay that way for as long as your organization needs: KOL records, interaction logging, medical information requests, adverse event intake, and the security model that holds the firewall.
If a commercial organization comes into the environment later, medical does not restart and nothing has to be migrated between two platforms. The two sides share provider records while the medical detail stays on the medical side.
Should we use Veeva or Salesforce for medical affairs?
Both work, and the right one depends on how much of your process is standard. Veeva ships medical affairs workflows out of the box, which suits a team that wants to adopt an established process and is prepared to work inside it. Salesforce is the better fit when your medical model is specific to your therapeutic area, when you want medical and commercial in one platform with a firewall between them, or when you are not ready to sign multi-year terms.
We wrote a longer breakdown of that tradeoff in our piece on medical affairs CRM on Salesforce. We will also tell you when Veeva is the better call for your situation.
How do medical information requests get routed?
MIRFs are captured as records rather than emails, then routed by therapeutic area, request type, and urgency to the person qualified to answer. Each one carries a due date and a full audit trail. The standard-response library sits in Salesforce, so common questions get answered from approved content instead of rewritten each time.
Once the commercial organization is in the environment, field reps submit MIRFs from their side and the requests arrive in the same medical queue. The rep sees that the request was received and closed. The rep does not see the medical response detail.
Does adverse event intake replace our safety database?
No. Your validated pharmacovigilance system stays the system of record for safety data, and we do not try to replace it. What we build is the intake and the routing in front of it. An adverse event or product complaint gets captured at the point it comes up, whether that is an MSL visit, a medical information call, or a commercial interaction, and routed to safety inside the reporting window.
The integration point is the handoff. The CRM shows that the event was captured and passed along, with a timestamped trail. The safety database does what it is validated to do.
What does an MSL see day to day?
Their KOLs, their territory coverage, their interaction history, and their open medical information requests. That is most of the home screen. An MSL opens the app before a visit to see what was discussed last time and what the physician asked for, then opens it after to log the interaction.
Everything else, including tiering analytics, coverage reporting, and MIRF turnaround, is built for medical leadership and stays out of the field medical view. Field tools get crowded fast, and a crowded tool is an unused tool.