SAS® programming in the clinical environment has a wide range of opportunities across a breadth of exposure of the entire clinical drug development cycle. Whether you are employed by a Contract Research Organization, Pharmaceutical or Biotechnology company, or as a contractor, the programming tasks are often quite similar, and at times the work cannot be differentiated by your employer. However, the higher level strategies and the direction any organization takes as an enterprise can be an important factor in the fulfillment of a SAS programmer’s career. We would like to share our experiences around the differences and similarities of interests and goals that we have experienced in our careers. The authors have a total of almost 30 years of experience within the industry with a combination of large pharmaceutical/biotech and contract research organization perspectives, from a SAS technical role and at a manager capacity.
DEFINITIONS:
In the Code of Federal Regulations [21 CFR 312.3(b)], the US Food and Drug Administration states that a sponsor means a person who takes responsibility for and initiates a clinical investigation. The sponsor may be an individual or pharmaceutical company, governmental agency, academic institution, private organization, or other organization. The sponsor does not actually conduct the investigation unless the sponsor is a sponsor-investigator. A person other than an individual that uses one or more of its own employees to conduct an investigation that it has initiated is a sponsor, not a sponsor-investigator, and the employees are investigators. [1]
A contract research organization means a person that assumes, as an independent contractor with the sponsor, one or more of the obligations of a sponsor, e.g., design of a protocol, selection or monitoring of investigations, evaluation of reports, and preparation of materials to be submitted to the Food and Drug Administration. [1]
SAS programming is an integral part of the clinical drug development cycle. Sponsors such as a biotech or pharmaceutical organization may delegate the responsibilities to a CRO and it is quite common to do just that. By definition, it is clear that any contribution to drug development, the responsibilities of the work is the same. The code of federal regulations also describes the guidance of transferring responsibilities of tasks associated with drug development. And thus, regardless of who your employer is, we as SAS programmers all have the same accountability to compliance and commitment to the safety of the research subjects.
RELATIONSHIP:
The symbiotic relationships between sponsors and CROs have become a strong reality and continue to evolve. Because a sponsor organization pays the CRO fees for their services, this can result in adaption to the best resourcing model of interest within both the organizations involved. To name a few resourcing models, there can be a traditional deliverable-based model, a FTE (full time equivalent) fixed-price model, or a hybrid of these models.
Sponsor companies are a business. They rely on the sales of their products in order to re-invest back into the research and development cycle so that unmet needs for patients can continuously be addressed. Reinvesting is quite similar within the CRO industry as they assist in the ongoing R&D cycle. In CRO, a large part of the actual revenue is the result of products from human labor. The CRO re-invests in itself, resulting in an increased continuation of service of human intellect through technology, processes and therapeutics. The CRO relies on the sponsor’s pipeline to maintain their continuity, and when a sponsor organization utilizes a CRO, they become reliant on those services.
Each sponsor and CRO has its own strategies, and in a lot of cases there are joint strategies between organizations. The requirement to be compliant is a strong mandate in our highly regulated environment. Growth is in fact a primary driver for most businesses and in the changing economic market, the overall risk assessment of value and continuation of business is vital. And let’s face it, clinical drug development is a risky business regardless of CRO or sponsor perspective.
As we consider risk across companies, let’s begin by using the analogy of diversifying your retirement portfolio. You diversify your portfolio with an individual risk assessment and then position yourself for the future based on your custom needs. Regardless of your specific investment choices, it’s always recommended that you diversify your portfolio to protect against a loss in one area.
Similarly, it’s a good practice for a sponsor not to have a single CRO take on too much of their essential work. This is so that if the continuity of the CRO falters by any means, then the sponsor company will have only a small portion of their business at risk. From a CRO perspective, it’s good to ensure that no one sponsor make up too much of their business. In this way, if something happens to one pharmaceutical or biotech company’s pipeline, only a small portion of the CRO’s business could be lost, subjecting it to the possible discontinuation, liquidation, or reduction in force. By maintaining balance, each company reduces their risks.
Relationships between sponsors and CROs exist, and have evolved into ones that are beneficial for both parties. These relationships provide an added value of return to both sponsor and CRO, and help maintain the continuity of our businesses.
THE PHARMACEUTICAL/BIOTECHNOLOGY (SPONSOR) SAS PROGRAMMER:
As mentioned above, the goals of the sponsor company are to invent new drugs/biologics (Research) for unmet medical needs, get them tested and approved by regulatory agencies as quickly as possible (Development), and sell as many as possible once on the market (Commercial). This allows the company to make enough money to develop other new drugs/biologics for other unmet medical needs, and keep the cycle going. Most SAS programmers at sponsor companies work in the Development area, analyzing clinical trials data in an effort to achieve regulatory approval, though there are a few who may work in other areas. Being part of the “middle” of the company, sponsor SAS programmers are often not in the most glorious of roles. Those in Research get recognition when the molecule they invented is later shown to be useful. Those in Commercial are out making the money the company needs to survive. It can be difficult for executives high up in the organization to realize how much work it takes to produce all those tables, figures, and listings that are needed to gain regulatory approval – as we SAS programmers know, it’s not just pushing a button!
Not too long ago, a SAS programmer in a sponsor company might have worked for years on a single molecule in a single or set of related medical conditions, with the same biostatistician, data manager, and clinical staff, from the first Phase I trial all the way through to submission to the government agency. As workload slowed down, this SAS programmer might help out on other projects or do some personal career development, but never really left their molecule. In many ways, coworkers became family, and the molecule was the baby the team was helping to grow. No one used the term “client”, and the sponsor SAS programmer worked for the benefit of the team and eventually the patient. Sponsor SAS programmers became very emotionally vested in their molecule, and in the sponsor company itself. Working mostly independently, each SAS programmer developed his/her own programming style, and was efficient albeit in a fairly isolated world. However, it was common for sponsor SAS programmers to feel “stuck”, bored, or unchallenged, and there were few opportunities to learn and share with others.
Over time, timelines have been shortened and the workload for each deliverable has increased. With this, a more fluid resourcing model has become the norm, so that now SAS programmers are commonly shifted on and off projects as needs arise. Additionally, standards have become more common, put in place to help reduce the learning curve as programmers move from project to project. Efficiency is now measured across the entire company rather than on a specific project, with the focus on how quickly someone new to a project can start being productive.
All this moving around and the need to use and understand a standard has given SAS programmers some growth opportunities. Although many SAS programmers are added to and taken away from a project during ebbs and flows, it has been found that keeping a core sponsor SAS programmer or two throughout provides some much-needed continuity and history.
In the past, the person we called a “lead” SAS programmer did the bulk of the coding and was seen as a SAS expert, but now the term “lead” has taken on more of a coordinator role. With this new definition of lead, it isn’t surprising that some of the best coders are not necessarily the best leads. Good leads know how to get work done through others. Their accomplishments and failures are the team’s accomplishments and failures, and vice versa. They can read and understand the protocol and SAP, know who to assign which tasks to, keep the team aware of timelines, fight for additional resources when needed, and jump in to do whatever work isn’t being covered by the rest of the team. A sponsor SAS programmer with these types of skills can evolve rapidly into a lead, and this is a significant step toward management and that career ladder.
So what about SAS programmers who simply want to code and aren’t interested in leadership, management, and moving up the career ladder? Well, if things continue along the current path, these more traditional SAS coder jobs are going to be less and less available at sponsor organizations. Sponsors have been looking internally for programmers who can manage the work being done by others, and outsourcing more and more coding to lower-cost SAS programmers in other parts of the country or world. SAS programmers who want only to code may be better off searching for positions at CROs or as contractors.
With outsourcing becoming more and more common, some wonder whether all sponsor SAS programming will eventually be outsourced. These authors don’t think that will happen. It makes more business sense to limit the total amount outsourced so that the sponsor maintains some key proprietary knowledge. Also, as mentioned above, sponsors are not likely to outsource too much of their business to any one CRO, since that presents a huge risk should the CRO go out of business.
Sponsor companies usually recruit only SAS programmers with a lot of experience in the industry. Salaries are usually quite good, and often there are other financial incentives such as bonuses, stock options, and retirement. It used to be that sponsor SAS programmers had the best job security, but reductions in workforce have become much more prevalent in recent years.
These reductions do not usually occur due to the lack of work, but rather the economy of outsourcing vs. internal knowledge. There seems to be a trend of moving coding work to offsite CRO SAS programmers.
CONTRACT RESEARCH ORGANIZATION (CRO) SAS PROGRAMMER:
There are different types of CROs. Some are generalists, and provide typical SAS programming work. Others are specialists, and focus on one specific type of analysis. There are similarities and differences between them, and thus between the SAS programming work that is done there.
The basic goal of a CRO is to provide superior customer service through quality, speed and value. In addition, CROs need to find ways to spend the least amount of money and still meet or exceed the client (sponsor) needs, though how this is done differs. CRO SAS programmers used to worry about job security because resource needs varied dramatically depending on the client base at any given time, however the increase of sponsor outsourcing has translated into fewer layoffs at CROs.
SAS Programming at a Generalist CRO:
In order to sell services at a lower rate than could be done by the sponsor themselves, plus pay for their own overhead, CROs have to find ways to reduce costs. One way is to pay lower salaries than offered at sponsor companies. Location is often important in helping reduce cost, and sites are often located far from major cities or even in other countries. A programmer in India or even Montana isn’t going to expect a salary as large as one in the San Francisco or New York City areas. Another way to reduce salaries is to hire less experienced staff. SAS programmers often find that CROs are the only companies who will hire them directly out of school.
In the past, a CRO was brought on to take full responsibility for some aspect of a project. For example, a company that doesn’t have staff to analyze a study would hire a CRO to do the complete study analysis. This type of outsourcing still exists today, and is used frequently by small sponsors with little or no internal SAS programming staff. Because the sponsor doesn’t have the staff to oversee the CRO, this can be referred to as “throwing it over the fence”, meaning the sponsor passes everything to the CRO to handle with little or no oversight. The CRO uses their internal SOPs to do the work, staffing the project much as a sponsor would by adding and removing resources as the project ebbs and flows.
The way a sponsor and CRO work together has evolved to meet sponsor needs in other ways. Some sponsor companies use CRO staff as if they were “virtual” sponsor employees. In these cases, the CRO SAS programmers staff follow the sponsor SOPs, work on the sponsor systems and use the sponsor tools, though most often from a distant location (where salaries are lower). The CRO and sponsor managers work to determine resource needs in advance, and the CRO provides the additional SAS programmer headcount needed by the sponsor.
Because the sponsor is the client to the CRO, the CRO SAS programmer has some additional hurdles to overcome in the areas of trust and communication. One of the reasons that a sponsor hires a CRO is to provide services for a lower cost than it would be to do the work internally, but this often causes the sponsor to be wary of the CRO’s abilities. Additionally, sponsors who are working with a CRO may not properly resource internal staff for oversight, and then the CRO SAS programmer will struggle to get from the sponsor both the information needed to do the work plus the feedback and approval of deliverables.
Working as a generalist, CROs can be a great way to get a lot of experience, since the CRO SAS programmer is likely to be exposed to a much larger variety of drugs, indications, and company standards than a sponsor SAS programmer would in the same amount of time. It’s also good for the SAS programmer who likes variety.
SAS Programming at a Specialized CRO:
Unlike the generalist CRO, some CROs are instead focused on specific niches. For example, a CRO might provide PK analysis or simulation work for the development of adaptive designs. Specialized CROs are usually hired to do a complete set of work. Because they are brought on for their expertise, these CROs use their own SOPs and expect very little oversight by the sponsor.
These types of CROs typically charge more for their services than the generalist CROs, and thus pay higher salaries because they need SAS programmers with specific types of experience. SAS programmers who have a specialty or want to develop a specialty are best suited for this environment.
CONTRACT SAS PROGRAMMER
Sponsors and CROs both often hire contract SAS programmers to fill short term resource needs. Typically a contract is for no more than 2 years, often much less. Because contractors are easy to let go, at least compared to non-contract (regular) employees, it is often much faster to hire a contractor. Additionally, contractors are expected to have enough experience to quickly get up to speed and be a productive member of the team. From a business standpoint, contract SAS programmers are good short term fixes in the ebb and flow of project workload. For the contract SAS programmer, this translates to a rather low level of job security.
Contract SAS programmers are typically paid an hourly rate rather than a salary, and that hourly rate is often higher than salaried employees at the sponsor or CRO where they work. Unlike salary employees, contract SAS programmers are paid for the actual hours worked, and those hours can add up significantly during busy times. However, contract SAS programmers do not typically receive many benefits like health insurance, vacation, and sick time, nor additional financial incentives like stock options and bonuses. Some contract SAS programmers work through agencies that supply some of these benefits, but in return keep a portion of the hourly rate. Independent contract SAS programmers receive the full hourly rate, but must market themselves.
Like CROs, contract SAS programmers can be either generalists or specialists. Specialists can command an even higher hourly rate than generalists, but specialized work can be more difficult to find.
Because contracts are generally short-term, contract SAS programmers can get a lot of experience in a short period of time relative to their counterparts at a sponsor company. Contract work is attractive to experienced SAS programmers who like variety but want the potential to earn more income than regular positions typically pay. SAS programmers who are enticed solely by the large hourly rate must realize the cost of benefits being forfeited and the likelihood of unpaid time between contracts. To reduce these risks, often you find one partner of a dual income family bringing in a regular salary and health insurance, while the other works as a contractor.
WHERE DO YOU BEST FIT?
To begin, let’s consider how each type of programmer might code the typical Adverse Event table. Adverse Event tables are very common in the industry, and often organizations will have standards and tools the SAS programmer must use to produce them. The sponsor SAS programmer, CRO SAS programmer, or contract SAS programmer assigned to the table would follow the appropriate SOPs and use these standards and tools in order to produce the table and confirm the results. For a sponsor, these SOPs and standards are internal. A CRO itself would likely have its own SOPs and tools, plus some sponsor-CRO agreements would require that the CRO use the sponsor’s SOPs and tools, thus a CRO SAS programmer would need to be familiar with multiple ways to do the same thing. A contract SAS programmer would not have their own SOPs or tools, but would be expected to follow those of the sponsor or CRO. Additionally, the CRO and contract SAS programmers often work with multiple sponsors as clients, giving them the experience of a diverse set of practices. A sponsor SAS programmer, on the other hand, is often limited to a small variety of CRO organizations and uses only their own SOPs and tools. Therefore, although the work is similar, the sponsor SAS programmer generally would use the fewest standards and tools, and the CRO SAS programmer would see the most variety in this area.
Now let’s consider involvement in the financial side of the organization. At a sponsor, the revenue comes from the sales force, so a sponsor programmer will not necessarily see this until sponsor products are marketed and sold. A CRO programmer can easily see revenue in terms of client payments vs. hours billed. A CRO programmer may be performing the same function or task as a sponsor programmer; however CRO programmers are building revenue for their organizations each day, well before the medicines reach market.
Sponsor SAS programmers usually have to account for their time only at the study level, and they are often unaware of how much time has been projected for any specific activity. Depending on the sponsor-CRO contractual agreement, CRO SAS programmers may need to keep a daily account for the hours spent on specific tasks across studies and sponsors, such as “dataset development for sponsor A study X” plus “table validation for sponsor B study Y”, and usually know the specific number of hours expected to complete a task. Contract SAS programmers are hired to provide specific services and need to account for every hour of the day spent on each activity. CRO and contract SAS programmers are concerned with maximizing “billable hours” to enable them to make more money in less time. A sponsor SAS programmer is likely shielded from the financial aspects of the company by many layers of management plus the fact that any revenue won’t be seen until a drug goes to market.
Involvement in the numerous available industry activities external to study production work, including work on industry groups such as CDISC or attending meetings/conferences like PharmaSUG, also can vary across the different types of SAS programmers. Because CROs can use these types of activities as marketing opportunities to demonstrate their talent, they want to involve their most senior SAS programmers. Sponsors, on the other hand, are likely to consider these activities as good learning experiences and encourage less experienced staff to get involved. For example, when it comes to attending a conference, often CROs only permit attendance for SAS programmers who are presenting a paper or supporting the conference as a committee member, while sponsors are more likely to include, as part of every SAS programmer’s development plan, at least one professional meeting a year. With contract SAS programmers, any time spent on industry activities is unpaid, so they are likely to focus selectively on those activities that would help them land future contracts.
Thus although a lot of the basic activities of a SAS programmer are similar, there are some differences in working for a sponsor, for a CRO, or as a contractor. To help you decide which opportunity(ies) might be good fit(s) for you, the individual SAS programmer, we’ve summarized key points:
|
Sponsor
|
CRO
|
Contractor
|
|||
|
Experience needed at hiring
|
Rarely can be low
|
Generalist: entry level possible.
Specialist: significant experience needed.
|
Must be high enough to need little oversight
|
||
|
Leadership
|
Many opportunities
|
Some opportunities
|
Few opportunities
|
||
|
% Time Coding
|
Low for leads
|
High for most
|
High
|
||
|
Standards and best practices
|
Follow own
|
Follow own + each client’s
|
Follow each client’s
|
||
|
Variety of work
|
Limited number of indications
|
High for generalists, low for specialists
|
High for generalists, low for specialists
|
||
|
Financial incentives
|
Good base salary + possible bonuses, stock, pension
|
Good regional base salary and smaller/no bonus or stock
|
High hourly rate with no bonus or stock
|
||
|
Non-monetary benefits
|
Good vacation, sick, insurance
|
Good vacation, sick, insurance
|
No vacation, sick, pay for own insurance
|
||
|
Company financials
|
Low awareness; bill at high levels
|
Medium awareness; bill at study and task level
|
High awareness; must account for each hour spent
|
||
|
Industry activities
|
Usually part of employee development costs
|
More common for senior staff
|
All out-of-pocket
|
||
It is quite common in the industry for SAS programmers to move throughout their careers into a combination of sponsor, CRO, and/or contractor roles. For example, a SAS programmer could start at a CRO, and then take a position with a sponsor in order to gain leadership opportunities. Or, a SAS programmer can earn the depth of experience of a sponsor’s best practices and take a position with a CRO to create the opportunity to experience and apply best practices across multiple sponsors. Career paths vary, and each SAS programmer can “fit” into different positions at different times. Thus a SAS programmer has a lot of options on how to develop a career path that best suits their own personal needs, wants, and desires.
Ref:http://www.pharmasug.org/proceedings/2011/IB/PharmaSUG-2011-IB05.pdf
SAS Training Institute | Learn SAS Courses & Certification With Placement Assistance 