From my observation to-date, the WebAPI is intended to support both common OHDSI services, backed by a common model (CDM entities), in addition to application-specific models/services.
It is obvious that the WebAPI should depend on a CDM java/object model… As I’m unaware that such a java model for CDM exists, I believe creating a java representation could bring additional appeal to the OHDSI community. We could consider a separate java project for just the CDM object/relational mapping, and having the WebAPI depend on the java model. With that said, abstracting the model out of WebAPI could happen at a later date.
Currently, entity representations are being created in WebAPI and we already have two Concept classes (one in o.o.w.vocabulary and one in o.o.w.cohortdefinition), in addition to some logical groupings (packages like o.o.w.vocabulary, cohortdefinition,etc.).
I would propose we establish a package namespace convention for CDM entities, reusing the entities across the services.
Below are some thoughts I had sent to Frank a few days ago…
Thoughts?
From: Franken, Alexander
Sent: Thursday, January 22, 2015 5:15 PM
To: ‘Defalco, Frank [JRDUS]’
Subject: RE: Heracles / results
My only thoughts are really regarding organizing WebAPI to support both a common model (CDM entities) and common OHDSI services, in addition to application-specific models/services.
Charity created a “o.o.webapi.model” package where she put CohortDefinition. Not sure where Chris plans to put his code. I would think we want his code and Heracles to use the same CohortDefinition entity/model class. So I would vote for CDM model classes to be in some common model directory. It looks like you have CDM model objects logically grouped under “o.o.webapi.vocabulary”. What are the various logical groupings for CDM model objects? In other words, where should CohortDefinition go (e.g. o.o.webapi.cohort, the base o.o.webapi, etc.)? Where would Observation and Specimen go when the need arises? We could use the “o.o.webapi.model” package (or something like “o.o.webapi.cdm”) and move the “vocabulary” package within, or we could keep the vocabulary package and place entities without a logical grouping (if any) under the base package “o.o.webapi”. This could be consistent with your thought to put application-specific model objects at the base application package (e.g. o.o.w.t.Result).
I like your “o.o.w.applicationx” namespace idea for specific applications. I might also suggest putting application-specific services under that namespace as well.
Examples:
o.o.w.model
--------Observation
--------Specimen
o.o.w.model.cohort
--------CohortDefinition
o.o.w.model.vocabulary
--------Vocabulary
--------Concept
--------Domain
o.o.w.txnavigator.model
--------Result
o.o.w.txnavigator.service
--------TxNavigatorService
o.o.w.heracles.model
--------EntityClassNotInCDM
o.o.w.heracles.service
--------AppSpecificService
OR
o.o.w
------Observation
------Specimen
o.o.w.vocabulary
--------Vocabulary
o.o.w.txnavigator
--------Result
o.o.w.txnavigator.service
--------TxNavigatorService
o.o.w.heracles
--------EntityClassNotInCDM
o.o.w.heracles.service
--------AppSpecificService
Did that make sense? Thoughts? As I’m unaware that a java model for CDM exists, we could consider a separate JAR maven project for just the CDM object/relational mapping (potentially drawing additional appeal to OHDSI), and having the WebAPI depend on the java model.
On another note, I met Patrick today and he and Jon would like more communication to happen on the forums… You care if we post these couple of threads there?
–
Alex Franken
From: Defalco, Frank [JRDUS]
Sent: Thursday, January 22, 2015 4:06 PM
To: Franken, Alexander
Subject: Heracles / results
Alex,
I’m under a deadline to release something called tx (treatment or therapy) navigator (or some other greek name yet to be determined) for the OHDSI community. The reason I bother you with this information is that it is an application that will be perusing results of analyses running off a set of CDM data sources. While this wasn’t planned to be part of the OHDSI platform per se I don’t want to go create a whole separate service for getting at the data and so I’m going to add it to the WebAPI. This will be a good test of the plan for the OHDSI schema as a place to host app-specific tables and the WebAPI as a place for different services.
Finally the question: Do you have draft of how you plan to layout the namespace/class hierarchy to support HERACLES?
For tx navigator I was thinking something along the lines of my data entities living in:
org.ohdsi.webapi.txnavigator.Report
org.ohdsi.webapi.txnavigator.Result
org.ohdsi.webapi.txnavigator.Summary
and then of course:
org.ohdsi.webapi.service.TxNavigatorService
This application is going to be markedly simpler than HERACLES but wanted to float this past you to see if it runs contrary to the thinking your team is doing for HERACLES.
Thanks,
Frank