As most Americans are hanging their flags and buntings, cleaning their grills, and planning their spots along parade routes, in anticipation of Independence Day, burn centers and hospitals across the country are gearing up for the inevitable burn-related casualties that spike during America’s favorite holiday. In 2017, there were 4 deaths and close to 13,000 reported fireworks-related injuries, and the numbers are expected to rise as many states are lifting their bans and restrictions.
It wasn’t that long ago when the average person never heard of statistics or analytics, but today, nearly everything around us is driven in some way by statistics. In the world of sports, data has been applied to baseball for quite some time, but as we’re seeing over the last decade, basketball is rising to the top as the sport most affected by the use of analytics. Sports injuries result in substantial economic loss by restricting participation, so it is no surprise that statistical analysis and medical technology are playing increasingly important roles in injury prevention and athletic performance.
Most, if not all, programmers for Navitas Data Sciences have 10 or more years of experience in SAS Programming to support biotech and pharmaceutical programming requirements.
What should you expect from a high level “A-Team” SAS Programmer? We’ve consolidated some of the wonderful feedback we’ve received from our customers and feel confident that any sponsor would appreciate the same level of expertise. Here’s what to look for in your programmer.
If you still think that Phishing is just a fancy word for attempting to catch a fish, you are one of the lucky few who haven’t experienced a fraudulent cyber-attack. But be on guard! Your turn could be coming momentarily…especially if you work in the Life Sciences industry.
Earlier this year, we talked about the advantages of hosting your SAS environment. So now that you have chosen your vendor and unless the vendor’s solution decides this for you, invariably the next question is choosing your front-end Operating System. These days it comes down to Windows or Linux…
In our last blog, The Best Major-City Areas to Live and Work in Life Sciences, we explored the benefits of living in five of the most popular large-city hotbeds of our industry, and found that 56% of DataCeutics’ programmers, data managers, and statisticians live in, and work out of these areas. The opportunities for exemplary education, premier entertainment, and ease of travel make big-city life attractive to many, but it’s not for everyone.
At DataCeutics, like at so many companies today, the bulk of our employees work remotely from their home offices. We are a Functional Service Provider of SAS Programmers, Data Managers, and Statisticians, and for us, the off-premise work environment model has worked incredibly well, for over two decades. Our programmers, data managers, and statisticians appreciate the flexibility of work hours, savings in travel time and costs, and they also get to live wherever they choose to reside.
The industry is in full agreement that currently, there is a critical gap in the landscape of the Study Data Tabulation Model (SDTM) and Analysis Data Model (ADaM) standards for handling and formatting data to allow for non-compartmental PK parameter calculations. ADNCA will be the new dataset standard that everyone will be using in the future to make PK parameters consistent, and will define how the data should be when it is submitted to the FDA…exciting stuff!
Having worked on a very large number of Statistical Analysis System (SAS) programs, I’ve discovered some better ways to do things, and am sharing some of these discoveries with you. SAS LOG files are scanned to monitor, evaluate, and improve the quality of data processes. Programmers are trained to look for ERRORS and WARNINGS in the data reports when these Quality Control (QC) scannings are performed, but all too often, they stop there.
Many SAS programmers have some SQL knowledge from working with a particular database vendor’s software before they discover that they can use SQL in their SAS programming, by simply enclosing their SQL statements inside of a PROC SQL invocation. They might wonder what the differences are between what they can do with the standard or vendor specific SQL that they already know, vs. what the corresponding capabilities are specific to SAS SQL.