For the "why" of this Hackathon please see the Rationale and Detailed Objectives page.

Date and Time

December 1st - December 5th

Starting with breakfast everyday at 8AM

Location

Countway Library at Harvard Medical School 

10 Shattuck Street

Boston, MA 02115

Conference Room 319A

Individuals

  • Michael McDuffie (BCH / CBMI HMS , Boston)
  • Michael Mendis (i2b2 Partners, Boston)
  • Lori Phillips (i2b2 Partners, Boston)
  • Gustavo Lopes (The Hyve / IMI / TraIT, The Netherlands)
  • Florian Guitton (Imperial College, London, UK)
  • Terry Weymouth (University of Michigan, Ann Arbor)

Goals

Design and code an approach to reintegrate i2b2's cohort discovery and ontology management code.

Agenda

Day 1

  • Personal introductions
  • Intro to tranSMART Architecture for Michael / Lori (McDuffie)
  • Intro/history to i2b2 (Mendis)
  • Presentation on current API direction (Gustavo)
  • Discuss best way to run i2b2 alongside tranSMART
  • API Discussion
  • Set obtainable goals for rest of hackathon

Day 2-4

  • API Discussion
  • Hacking with morning and evening status updates

Day 5

  • Recap 
  • Explicit plan for followup work
  • Discuss future work in both projects

Pre-Meeting Prep

  • Working i2b2 1.7 Demo (Public demo may be enough)
  • Working i2b2 1.7 instance with minimal number of cells running against a local tranSMART DB, with the schema from i2b2 1.7 copied over to replace any overlapping schema held by tranSMART.
  • Working development version of 1.2 on a new branch on our laptops
  • Environment to test our integrated code
  • JIRA / Wiki (Probably use tranSMART Foundation's)
  • Develop complex test data sets to exercise i2b2 use cases, like dates and modifiers

Main points of discussion

  1. Identify compulsory i2b2 components that we need to stand up alongside tranSMART in order to achieve or goals (i.e. which cells)
    1. (some background; basic i2b2 documentation)
  2. Outline software interface between i2b2 and tranSMART
  3. User interface to take advantage of these components for ontology representation
  4. User interface to take advantage of these components for cohort generation
      1. Include/Exclude
      2. Dates/Visits/Encounters
      3. Modifiers
      4. Temporal queries (i2b2 1.7 functionality)
      5. Any other functionality we identify in our discussions
  5. i2b2 plugins and tranSMART compatibility
  6. Discuss future of both projects and how we can keep the code from getting too far away from each other

Programming Tasks

A. Create communication layer between tranSMART and i2b2 using XML messaging.
B. Create UI components for generating Ontology tree and conducting cohort discovery. This should be modular/abstract enough to allow for the easy addition of interface components that correspond to new i2b2 services.
C. (Reach Goal) Start work on a new communication layer that will allow the streaming of data from CRC to external applications like tranSMART.

Minimum Success Criteria

A. Display ontology tree communicating with the the i2b2metadata services.
B. Create complex query using nodes from tree plus options for

  • Logical operators (AND/OR boxes)
  • Include/Exclude
  • Modifiers

C. Use the patient sets created above for Summary Statistics and Advanced Workflows.



 

 

  • No labels

8 Comments

  1. Kees van Bochove

    Michael Tommie McDuffie Gustavo Lopes I am also quite interested in how the 'consent ontology' that Paul presented works exactly. Would it be possible to put that on the agenda of the workshop, or is that a topic that would be diagonal to this? If that is more about configuration than coding, I could try to meet with Paul in parallel to learn more about this and how we can apply it in TraIT and other projects.

  2. Michael Tommie McDuffie

    Kees van Bochove Paul Avillach It's as simple as loading the consent like any other fact about a patient. Whether or not they want to be recontacted for future studies is stored the same as their tumor subtype or if they have a sample in a biobank. Some of the facts may need to be computed as a part of the ETL process though. As an example a patient may consent to be contacted within 2 years of their initial consent so we could build a fact for them that is a flag of whether or not we can contact them.

    1. Kees van Bochove

      Michael Tommie McDuffie OK but I got somehow the impression that there is also a way to enforce the loaded consent, as a sort of access rights restriction logic. Or do you simply include the relevant consent facts as query panels when building the query?

      1. Michael Tommie McDuffie

        That is correct, There is no automatic consent management restrictions at current.

  3. Keith Elliston

    Please update the tranSMART logo with the correct logo for v1.2.  Rudy Potenzone (rudy.potenzone at transmartfoundation.org) can provide it in whatever format you need.

     

    1. Michael Tommie McDuffie

      Updated! Sorry about that Keith.

  4. Keith Elliston

    creation

    This should be Cohort Discovery, not creation.

    1. Michael Tommie McDuffie

      Fixed! Thanks Keith.