I haven’t blogged for ages, mostly through laziness. The last four working days I’ve been working on a particular problem which I thought was worthy of a write up. I’ve been retro-fitting unit tests to some of my old code, for a number of reasons – mainly the fact that you run the risk of
As stated in a previous post I’ve been strongly considering the possibilities for cloud based hosting, looking at AWSÂ and Heroku for Node.js apps. Those both have a free offering, but this is limited in its scalability, without starting to invoke charges. On top of Node, I need a MongoDb instance, a Git server, Test
I’ve dropped my SEND encoding into MySQL tables for now so I can drive my SEND file creation from data right “from the horses mouth” so to speak – a business layer which interprets the regulatory framework exactly as expressed in the SENDIG in an iterative manner. I’m now ready to consume that data from
Coming at SEND from a preclinical background has been a strange experience. One of the most unusual things about it, from my perspective, is the use of SAS transport files to convey data. Why wrap deliveries up in an arcane binary format where you have to jump through hoops to consume the data? I guess
The Standard Exchange for Non-clinical Data or SEND format is currently gaining traction within the pharmaceutical industry, largely thanks to its adoption by the US Food and Drug Administration (FDA) as a format for submitting data. In many respects this is a very good thing. There is a distinct lack of standardisation in organisations dealing