Linked In Icon Twitter Icon Facebook Icon

"very actual topics leading to interesting and open discussion"

Roche

At this stage in the game, I think we, as sponsors, have finally moved from “if we have to implement standards” to “how we should be implementing standards”. As it turns out, I think we can all agree that the latter is much more challenging. Standards such as CDASH, SDTM and ADaM are available for our implementation pleasure….along with a new set of challenges. Sponsors must take the data models and implementation guides and apply/integrate them into their own processes. Sounds easy enough, no?
I am a Statistical Programmer, here me roar! That statement sounds very bold and confident; however, to be honest, I am not sure what a Statistical Programmer does anymore. This post may be rehashing some previous topics about specializing or not – but I will try not to be redundant. I want to speak about Statistical Programming – proper.
Specifications are everywhere. Datasets are specified, reports are specified, systems are specified and we all have to deal with the specifications. Often enough we have to create them on our own. But how to make good specifications? Less is more, but is it still enough? What level of detail will fit our requirements?
In his recent blog, Dave Handelsman looked at open source vs. proprietary software debate and concluded that businesses should evaluate software not based on “free vs. fee” but instead on “value vs. risk”. I completely agree with Dave’s assessment. I would go a step further and conclude that open source software provides better value with less risk than proprietary software. Let’s take a closer look.
Free vs. Fee??
As our industry standard of regulatory submissions shifts towards CDISC-compliance, sponsors must adopt new processes to support the shift. With the implementation of the submission standards of SDTM, ADaM, and Define.xml, this adds up to a plethora of new processes and responsibilities. SDTM alone encompasses many of these new processes….including new tasks such as SDTM annotation of CRFs, creation of SDTM metadata specifications, programming of SDTM datasets and parallel programming/QC of SDTM datasets. This puts additional pressures on groups such as statistical programming to be able to efficiently get their work done while adhering to new data standards.
Lets face it, it does not matter how big or small the organisation you work for is, the chances are that if you are in a programming environment then there is a Good Programming Practice Guideline lurking somewhere not too far behind you. Most likely on a shelf next to long forgotten and out of date SOPs, training documents for out of date processes and manuals for software or equipment you no longer have.
People always talk about the “Standards Train.” Get on the standards train, have you missed the standards train?
In my early days as a statistical programmer – one of my greatest hesitations of starting a new job was in understanding the computing environments of the particular organization I was working for. I was confident in my programming skills, and given the extent of available experts, I would be able to understand the protocol, SAP, CRF – the data and what I needed to do to get the job done. So that left the computing environment for me to tackle and understand – as most of these are customized to some extent, but server similar purposes. I was born a Windows man...
For efficient working more and more supporting tools like SAS macro systems or graphical tools are bought or developed. But how "good" or "bad" a system is depends on the users. Will the system support the users in their work flow? Will it be more efficient than the established processes? Will the system get accepted? So how to make our users happy to support our systems?
Pages: 1 2 3