mdt_functions.py and data_readers refactor

[yevgenybulochnik]

Proposal

Going along with #38 I would suggest we break apart this module. The module itself is commented out to specify function domains. We should consider creating a utils.py or common.py to house common functions that can be used anywhere in the codebase. Perhaps all functions related to the database could be housed in a db.py module. The reader modules are already broken out into meps and rxnorm readers, maybe it makes more sense to combine these into a single readers.py module. Another consideration would be to use rxnorm and meps as module names themselves this way when invoking methods they are namespaced, ie rxnom.reader() or with the db module db.create_mdt_con().

This is all mostly just food for thought, with the idea that the directory structure of the repo can provide syntactical meaning depending on how methods are imported.

Inspiration from other repos

• Flask
• Pandas
• Twisted

[Bridg109]

I agree with making rxnorm and meps files as modules and including name = main at the bottom of these so they are both runable by a clt or from within another mdt script (likely what ever rxapi.py becomes....noting this name does not make sense if directory structure is to provide meaning...so maybe just call this mdt). In my mind leaving the two readers separate might be helpful as the refresh frequency could be different for both (RxNorm is weekly/Monthly) and Meps is annually (MEPS reader is going to get alot more code as well per Kristens comment on multiple years). Maybe a /reader folder could store both which would structure us for additional data readers if wanted outside of project (NADAC as example).

Agree with both a db.py and utils.py. Also we should remove mdt_ from the start of alot of our file names.

[yevgenybulochnik]

Calling scripts from internal package functions gets a bit weird.
https://stackoverflow.com/questions/1186789/what-is-the-best-way-to-call-a-script-from-another-script
Right now the modules are really more setup like scripts, but would suggest making some adjustment to the reader methods to allow them to be consumed as scripts or functions in a cli. If a script is present in a package its typically run with python -m.