Ontology Mapper Team Minutes

6/17/08

Present on Call: Rob, Ketty, Brent, Nick A., Paul Norris, Prakash, Davera, Maggie, Liat, Stuart, John Holmes, William

Today we would like to welcome Ketty Mobed to our group!  Ketty will be responsible for documenting the Basic Science lifecycle and she will act as our interface to Boris Bastian.

1)     We talked about the lifecycle paper and reviewed Liat’s template for the Use Cases.  It was decided that complex workflows should also include a high level Data Flow Diagram drawn in Visio as well.  (The Visio diagrams should be converted to JPG before insertion into the document.)

2)     Maggie will contact Kevin Haynes to get him started on his task

3)     Davera will assist Maggie with the high level document edits.

4)     Database design status: The basic database design has been completed (good job Marco and Prakash!).  We now know how our system will interface with i2b2 and how the maps will be stored.  We also have a functioning Proof-Of-Concept (POC).

5)     The database design will now switch to a more traditional top-down design following our successful POC work and the above mentioned database integration with i2b2.  We will now examine the UI diagrams in the grant proposal and define the database serializations required to support those UIs.  We will then integrate that work with our POC results and then Prakash will map out the use of Archetype and Aggregate Rules and Marco will finish off the paper.

6)     Our current database design has 2 basic principles that look interesting to me:

1) The current design has very little impact on the current code base of i2b2 to make integration easier.  We are layered between the fact table (built during ETL) and the CRC (Clinical Research Chart) data mart which i2b2 uses to permission users.   Our system will become a new Cell within i2b2 called the Ontology Mapper Cell although we may refocus on a more generic solution if our grant is approved.

2) Our system reads data from the Observable Fact Table and writes data to a new fact table called the Map Data Fact Table.  So we will Not support transitive mappings of data.  For example, we would not support mapping data from terminology A to B and then from B to C.  You would be required to map from A to B and from A to C.  This is good because every mapping results in less specific data and transitive mappings would water down the results too much.  Mappings are only supported from the source data set.

Thanks everyone, please send your workflow diagrams and use case templates (for the lifecycle doc) to Maggie as they are completed.

Regards,

Rob