SAIL defines federated learning as follows: "researchers use rich data from many sources to improve models for patient care and cures without having to move or expose data. Additionally, hospitals have full control of how their data is used and accessed." 

Here's the Experiment's flow. 

• Query: Rarekidneycancer.org plays the role of a hospital.  Praxis (who is running the hackathon) provided a query to run against rarekidneycancer.org's full (private) genome.  The (private) query had access to all rarekidneycancer.org's data.  The query result is a Normalized subset of the Normal and Tumor RNA data.
• Query Result: Rarekidneycancer.org persisted the (public) query result on github.  Analogous to a blockchain "smart contract", a "Stupid contract" is associated with the query result.  The contract details allowed use and is the standard legal boilerplate for data sharing on github.
• Peer Processing: At the hackathon, several parties will process the rarekidneycancer.org query result using data from TCGA and GTEX.  They will post more (public) results on Github.  The details of correct results posting are delineated by Praxis on their platform.

Linitations: On the minus side, one key limitation is the "stupid contract".  However since it is -my- contract (I believe) this approach meets all elements of SAIL's definition.  Another key limitation is the amount of data we are allowed to store on github.  Github won't allow us to upload the > 1 terrabyte of data associated with just one genome. 

Benefits:One the plus side, note also that all stages of the architecture are clearly decoupled, yet co-ordinated.  Also, there are no data sharing costs on rarekidneycancer.org's side, since the results are stored on github.  Hopefully, this approach will improve patient outcomes not just for me, but for patients in upcoming hackathons.