chop-dbhi / omop_harvest

OMOP CDMV4 data model with OSIM2 data in Harvest
https://eig.research.chop.edu/omop/
Other
5 stars 3 forks source link

Split pedsnet_harvest off from omop_harvest #61

Open gracebrownecodes opened 10 years ago

gracebrownecodes commented 10 years ago

I think it has come time to officially divorce the two projects, because they are really separate. Although much of the development on pedsnet_harvest will probably apply to omop_harvest, enough differences exist to make the split desirable, in my opinion. Thoughts?

bruth commented 10 years ago

Depending on how much differs, this could be done one of two ways:

  1. Develop pedsnet_harvest as an app that overrides various parts of omop_harvest (templates, static files, urls, etc.)
  2. Create a fork and merge changes to ensure neither repository falls behind

(1) Is definitely preferred since there is clear separation and no redundancy between the two repositories, but we need to assess how deep the changes go. Mind listing out the changes you are aware of?

gracebrownecodes commented 10 years ago

Here are the differences I can see at the moment:

pedsnet_harvest omop_harvest
pedsnet landing page land on query page
force_script_name run at root
chop_auth w/ AD no authentication
registration no registration
data access auth by org no data access auth
query logging no query logging
deploy with cbmi_utils straight docker deploy
based on internal django_baseimage based on phusion_baseimage
db connection with ssl no ssl to database
bruth commented 10 years ago

Ok, all of that is standard stuff. It would be worth evaluating omop_harvest to delineate which parts make up the library vs. the parts that make it a deployable application. They are generally completely separate.

I see three logical repositories here:

Varify is an example of this and can be used a drop-in Django app or a standalone project. Our chop_varify application uses Varify as an app and provides a minimal set of configuration and code to customize it for our internal needs.