Linked In Icon Twitter Icon Facebook Icon

"entertaining and informative"

GSK

Before I start – I just want to emphasize that everyone is entitled to at least one boring Blog post. Well, this is mine. Apologies up front. I did have good intentions, however. I was even going to start it off with some experiences I had in the jungles of South America...
With the new Phuse/FDA collaboration another project starts which will be open source (Working Group “Development of Standard Scripts for Analysis and Programming”). Will this project have a chance or are the barriers too high?
I’m special. In elementary school we had a program called I’m Special.
Personally I cannot understand discussions about creating standard programs or standard macros. I could only imagine very rare situations where standard programs will make more sense than standard macros.
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?
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