Based on process problems I've seen at hackathons to date, my "hackathon goal" was to map Pete Kane's objectives¹ to a plan containing activities that we could execute and improve at TRI-con. The subsequent "2020 Kidney Cancer Hackathon: Results" post describes what actually happened.  Of course, I expect the plan to be iterated upon and improved as time goes on.

Objectives

After speaking to RTTP's Pete Kane, here are what I believed to be the union of our objectives:

• Do deep biological profiling for patients before the hackathon.
• Reveal new treatment paths during the hackathon
• Help set up new drug n=1 trial cases after the hackathon
• Create a journal to disseminate results

Plan

I maintained that the first three Objectives could be supported by the following activities.

1. If the patient support team (may be, but doesn't have to be, the patient or the patient's physician),
2. can provide complete original data (e.g. WES/WGS, RNA-seq, EMR),
   1. hopefully from the same vendor,
   2. and ideally including parent and/or sibling DNA,
3. which has been verified (e.g. Appendix: Mike D'Amour fastq Validation Process produces this report)
4. and has undergone “standard” pre-processing, (e.g. alignment)
5. which has been verified (e.g. multiple aligners)
6. and if the researchers have done much of their investigation before the hackathon (e.g. I reached out to Clemson before they showed up), 
7. then the hackathon can be used to review, discuss and tweak researchers' results, 
8. identify potential targets 
9. and discuss potential therapeutics
10. both of which have been verified (this step added post TRI-con)
11. and can be proposed to the FDA for approval under their n=1 protocol.
12. After step 5, results can be documented by the participating researchers and organizers (listing sources from steps 1-5 as generously donated & properly credited contributions).

My thesis was that the further down the plan the patients are, the more "FDA ready" they are likely to be.  For example, if the researchers have done the research before the hackathon, then the hackathon becomes a conference where attendees discuss n=1 research results.  If they only have unprocessed patient data, then much of the hackathon is spent doing processing and very little research.  Finally, if the data is not verified, there is a chance that the data quality is poor and if so, then the results are guaranteed to be poor.  This happened to me and It is very discouraging.  So don't try to save money upfront. 

From a patient perspective, Plans like this give potential attendees a realistic expectation of what can be done based on where they are.  It also shows them how to get the most "bang for the buck" by doing a fair amount of work ahead of time.

Appendix: Mike D'Amour's fastq Validation Process