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

Problem Statement

Need to know what search criteria we will input to MDT to output asthma medications. Is it just D001249 (DISEASE = Asthma) with a "may_treat" or "may_prevent" relationship? What RxNorm dose forms do we include? Do we need to include other searches?

Criteria for Success

Spot check a lot of common asthma medications and ensure they are in the list.

Additional Information

Example RxClass search.

No way to quickly compile RxClass getClassMember API URLs. This will be one of the most frequent API calls we make, so a function to handle developing the URLs will be extremely valuable

Problem Statement

[What needs to be done and why]
I used Synthea and generated a population of patients without specifying a medical module. That means it uses all medical modules. Per the instructions of MDT, I have to manually replace "MedicationOrder" in every json file of medical module with callsubmodule. Is there an automatic way to do this? Thanks

Criteria for Success

[Measureable outcome if possible]

Additional Information

[ways one might accomplish this task, links, documentation, alternatives, etc.]

Problem Statement

Different OS have different methods for writing paths. Pathlib path objects can handle this for us.

Criteria for Success

All paths work using Pathlib

Additional Information

The path to light starts with Pathlib

Problem Statement

Per Synthea documentation:

... the values in those columns must be numeric probabilities between 0.0 - 1.0

Currently, the values are 0 - 100. So I think they need to be 0 - 1 with only a tenths decimal place.

Criteria for Success

All numbers are tenths decimal place and total to 1.0 per row.

Additional Information

https://github.com/synthetichealth/synthea/wiki/Generic-Module-Framework%3A-Transitions#table

Problem Statement

If we don't put any date limits on our modules, patients in 1901 are going to be getting modern medications.

Criteria for Success

Some automated way to query FDA to link first available date of drug application to a product RXCUI or NDC.

Additional Information

See example here: https://www.accessdata.fda.gov/scripts/cder/daf/index.cfm?event=overview.process&ApplNo=075743
Original approval date = 07/01/2002

A lot of modules list this in the remarks: https://github.com/synthetichealth/synthea/blob/master/src/main/resources/modules/medications/moderate_opioid_pain_reliever.json

    "Availability dates for different drugs came from the FDA: ",
    "http://www.accessdata.fda.gov/scripts/cder/daf/",
    "Dosage information came from FDA reference sheets available at: ",
    "https://www.drugs.com/dosage/",
    "The following medications are prescribed in this module. Most opioids were invented ",
    "during or prior to WWII, but did not become widely available until after the war:",
    "1. Meperidine (Demerol)                      available after 1945      ",
    "2. Hydrocodone/Acetaminophen (Vicondin)      available after 1943      ",
    "3. Oxycodone/Acetaminophen (Percocet)        available after 1920 (est)"

Problem Statement

For the validation between the current Synthea-generated patients vs. the MDT-enhanced Synthea-generated patients (using MEPS distributions) vs. Medicaid distributions, we planned to use goodness-of-fit and post-hoc analysis tests to measure the differences between the populations.

Rationale

To meet the submission requirements of "evidence of validation".
https://drive.google.com/drive/folders/1Nx9C1n_ymsNRPrk6v4UYUtQcGLY2OihB

Criteria for Success

• A function or a workflow that allows us to compare 3 populations easily, with flexible parameters (e.g. pick a state + rxclass category from Medicaid vs. MEPS vs. Synthea -- since Medicaid doesn't have age or gender info) & calculate goodness-of-fit.
• Also gather requirements for what's needed in the inputs for this workflow/function, and the post-hoc analysis.

SciPy has a chi-square function, which may be useful here? https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.chisquare.html

Additional Information

Some light reading from articles that performed "synthetic data validation" and MEPS validation (though neither appear to be using goodness-of-fit for their validation, but may be helpful for the writeup?):

• https://bmcmedinformdecismak.biomedcentral.com/articles/10.1186/s12911-019-0793-0
• https://journals.sagepub.com/doi/pdf/10.5034/inquiryjrnl_48.03.04

Proposal

Instead of direct API call for NDCs from a list of SBD/SCD or what ever...consider trying to use RxMix batch function and posting the list in the form data during the executeConfig.do POST requests path. This might save on the number of web requests needed to run the MDT. Noting figuring out the XML might take a bit of work but it seems doable if we only use if for for specific cases as we can copy and paste from a manual and just change the list values.

Rationale

This should reduce the number of API calls we need to make from lots to many in order to get NDCs for a few RXCUIs we have interest in

Problem Statement

If we input albuterol we get back MIN products containing albuterol by default (i.e. ipratropium/albuterol). If the user only wants single ingredient albuterol products, we should allow this.

Criteria for Success

Input albuterol and get back only single ingredient albuterol products.

Additional Information

A quick and easy way to do this might be to add a final step right before the "generate_module-type" steps that filters the DF by medication_ingredient_tty = "IN" or "MIN" depending on the user setting.

Problem Statement

Creating this as a placeholder for ongoing work on README and docs.

Criteria for Success

Both sections look professional and are easy to use for developers and users of MDT.

Additional Information

Some content is already in issues like #10.

Problem Statement

Need code to be open source as part of challenge criteria.

Criteria for Success

Add open source license to repo as approved by Synthea team. I have an email out to them asking which license is preferred and which licenses are acceptable.

Additional Information

Will wait to hear back from the challenge team.

Problem Statement

The meps_data_reader module fails if a data directory is not present in the root of the project. This module is dependent on the create_mdt_con() function in mdt_functions.py.

Criteria for Success

This issue will likely be discussed after we talk more about restructuring, but should be noted in the docs for the time being. This can be resolved with pathlib and really is part of configuration so its dependent on how we setup config for the project. In the docs we should add a line to make this directory before running the meps_data_reader.py

1. Make a data directory in the root of the project
2. Run meps_data_reader.py to load MEPS data
3. Run rxnorm_data_reader.py to load RxNorm data

Proposal

It might be good to spend a little time just documenting the current state of the work we're doing in a /docs directory or the README or something which might benefit members of this group and also serve as a foundation for part of the paper and for actual users of this tool eventually.

Rationale

Help people get up to speed and understand how to use our tool. Could also host a static site from here eventually.

Problem Statement

For our rescue inhaler, we want it to be PRN. We don't have a way to know that it SHOULD be PRN based on the data we have. So we want the user to be able to make this setting.

Similarly, we should have a flag for "chronic" to define medications as chronic.

Criteria for Success

If the "as_needed" setting is true, then all MedicationOrders generated from the module have true in as_needed within the prescription node.

Example:

"prescription": {        
"as_needed": true      
},

"chronic" is a little different because it is within the MedicationOrder node - not the prescription node.

"Prescribe_Emergency_Inhaler": {      
"type": "MedicationOrder",      
"reason": "asthma_condition",      
"codes": [        
{          
"system": "RxNorm",          
"code": "2123111",          
"display": "NDA020503 200 ACTUAT Albuterol 0.09 MG/ACTUAT Metered Dose Inhaler"        
}      
],      
"prescription": {        
"as_needed": true      
},      
"direct_transition": "Asthma_CarePlan_Selector",      
"chronic": true    
},

Additional Information

N/A

Problem Statement

Synthea (and the MDT) assign drugs to medication orders regardless of the synthetic patients' prescription history/active medication list. In order to accurately simulate prescribing patterns/standard of practice to avoid therapeutic duplications, we need to develop a feature that accounts for this decision pathway.

Criteria for Success

• Add drug class into our MDT outputs
• Maybe need a lookup table of NDCs to drug classes or ingredients, so that we can label or join Synthea's medication list with drug classes
• Find/use Synthea's medication list table and add logic to prevent therapeutic duplications

Additional Information

MITRE (company who developed and maintains Synthea) flagged this (and general contraindication logic) as an important feature they'd like to see added

Problem Statement

MEPS is an annual survey dating from 1996 to (now) 2020, and utilization patterns change over time (e.g., as new drugs become available). For our data challenge submission, we loaded MEPS 2018 data. By loading MEPS data from other years and enabling our tool to create distributions for each MEPS version, we can improve the data quality of the MDT and set the Synthea module to select the distribution based on the medication order year (e.g., when Synthea creates a med order for 2019, it can pull the MDT distribution from MEPS 2019).

Criteria for Success

• Load additional MEPS versions into the MDT database
• Add a MEPS year column to the distribution calculation partitions & MDT file outputs
• Find and use Synthea's date (actually attribute called time that is in milliseconds since 1970 or something) in their transition table to configure Synthea to use the MDT/MEPS year output for the corresponding year of the Synthea date

Additional Information

MEPS data files:
https://meps.ahrq.gov/data_stats/download_data_files_results.jsp?cboDataYear=All&cboDataTypeY=2%2CHousehold+Event+File&buttonYearandDataType=Search&cboPufNumber=All&SearchTitle=Prescribed+Medicines
https://meps.ahrq.gov/mepsweb/data_stats/download_data_files_results.jsp?cboDataYear=All&cboDataTypeY=1%2CHousehold+Full+Year+File&buttonYearandDataType=Search&cboPufNumber=All&SearchTitle=Population+Characteristics
Current versions/code used in MDT database: https://github.com/coderxio/medication-diversification/blob/main/src/mdt/database.py

At the time we built/submitted the MDT for the data challenge, 2018 was the latest version available and the file formats were difficult to work with in python (.dat). Shortly after submission, MEPS added 2019 data and started making csv and xls file formats available (last time I checked, MEPS only added these formats for 2018 forward). So the final solution may need to account for these differences based on which files we load & which formats are available.

Problem Statement

We need to analyze Medicaid prescription data to use as validation of the output of the MDT. We would hope to see similar distributions of medications across the real Medicaid patient population and the synthetic Synthea population based on MEPS distributions.

Criteria for Success

Initially, success looks like just understanding the Medicaid data and having a strategy for using it for validation.
Ultimately, success looks like being able to show that pediatric Synthea patients with asthma have similar medication distributions as real Medicaid patients in a similar age range, gender, and state.

Additional Information

Note: we would be comparing 2018 data.
https://data.medicaid.gov/State-Drug-Utilization/State-Drug-Utilization-Data-2018/e5ds-i36p

Proposal

If we want to make a command line tool argparser is part of the python standard library, however, I think we should also take a look at Click. Click would mean including a dependency but its syntax is a bit more straight forward by using python decorators.

I think using click would allow us to build a cli fairly rapidly and provide very readable syntax. Argparser is also an option, but imo the sytanx is more verbose, but this could also just me not being as familiar with it. Flask uses click as its cli.

Rationale

Food for thought

Problem Statement

We need to get the meps data down into one table so that it can be pulled into a pandas dataframe for gathering distributions.

Criteria for Success

SQL file can be read and will generate a meps_table in database using the same functions used for making the rxcui_ndc table

Additional Information

This is similar to what was done with Joey's query to generate the rxcui_ndc table in the DB. Review Kristen's pull request it looks like this SQL should get us close to what we need. Please polish this up and change it to use tables meps_prescriptions, meps_demographics....will need to add meps_regions from the code in Kristen's pull request.

Please consider removing t1 from this query we should either go RxCLass List -> Joey_Query to get NDCs to pass to MEPS or Join MEPS data to RXCUI and pass RxCLass List to this but not both as it duplicates data joins. I am open to either way but we should choose one.

"    (SELECT DISTINCT \n",
"    t1.medication_ingredient_rxcui, \n",
"    t1.medication_ingredient_name,\n",
"    REPLACE(REPLACE(\n",
"    REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE\n",
"    (REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(\n",
"    REPLACE(t1.medication_product_name, 'a', '')\n",
"     , 'b', ''), 'c', ''), 'd', ''), 'e', ''), 'f', ''), 'g', ''), 'h', ''), 'i', ''), 'j', ''), 'k', '')\n",
"     , 'l', ''), 'm', ''), 'n', ''), 'o', ''), 'p', ''), 'q', ''), 'r', ''), 's', ''), 't', ''), 'u', '')\n",
"     , 'v', ''), 'w', ''), 'x', ''), 'y', ''), 'z', ''), '[', ''), ']', '')\n",
"    AS medication_strength,\n",
"    t1.dose_form_rxcui,\n",
"    t1.dose_form_name,\n",
"    t2.dupersid,\n",
"    t2.perwt18f,\n",
"    CASE WHEN t3.sex = 1 THEN 'Male' \n",
"    WHEN t3.sex = 2 THEN 'Female'\n",
"    END AS gender, \n",
"    CASE WHEN t3.age18x < 4 THEN 'Under 4'\n",
"    WHEN t3.age18x BETWEEN 4 AND 7 THEN '4 - 7'\n",
"    WHEN t3.age18x BETWEEN 8 AND 11 THEN '8 - 11'\n",
"    WHEN t3.age18x BETWEEN 12 AND 18 THEN '12 - 18'\n",
"    WHEN t3.age18x BETWEEN 19 AND 49 THEN '19 - 49'\n",
"    WHEN t3.age18x BETWEEN 50 AND 64 THEN '50 - 64'\n",
"    WHEN t3.age18x >= 65 THEN '65 and up'\n",
"    END AS age,\n",
"    t4.states AS state\n",
"    FROM {ingred_prod_ndc} AS t1\n", 
"    INNER JOIN meps_prescribedmeds AS t2\n",
"    ON t1.medication_ndc = t2.rxndc\n",
"    INNER JOIN meps_patientdemographics AS t3\n",
"    ON t2.dupersid = t3.dupersid\n",
"    INNER JOIN meps_region_states AS t4\n",
"    ON t3.region18 = t4.region_value\n",

Proposal

Maybe you can't find exactly what you're looking for in RxClass and end up crafting the perfect list of meds with a domain expert. There should be a way to just bypass the initial RxClass API and import that list of RXCUIs to get the same output.

Rationale

I've played around with RxClass and have sometimes found that it is close but not perfect. This might be a nice feature to have.

Problem Statement

Users need to be able to filter by dose form group (DFG). DFG is a grouping of dose form (DF).

Criteria for Success

Pulling in DFG does not make the granularity of the rxcui_ndc.sql query change and I should be able to specify DFGs and only see results with those DFGs. Maybe I am also notified of which DFGs are filtered out?

Additional Information

Dose form group (TTY=DFG) is a term type that serves as a grouping of dose forms (TTY=DF) related by route of administration (i.e., Topical) or dose form (i.e., Pill). DFG, along with SCDG and SBDG term types, are meant to be used in medication application interfaces. Instead of users scrolling through a long list of drugs with many different dose forms, the DFG/SCDG/SBDG group dose forms for shorter, more manageable drug lists.

See these links:

• DFG: https://www.nlm.nih.gov/research/umls/rxnorm/docs/appendix3.html
• DF: https://www.nlm.nih.gov/research/umls/rxnorm/docs/appendix2.html

Proposal

Create a class that can be used to hold data and manage actions related to building a medication diversification "profile". Class should have at minimum a list of NDC, RXCUIs (of ttys that can be used in medication prescribing), Route Manager, Distribution Functions. Should have functions to output both correctly formatted JSON and transition table. Should be able to handle all API calls on initiation with correctly formatted input data (recommendation JSON).

Rationale

Using a class instead of a straight procedural approach will allow us to adapt the process of gathering and managing all of the information to different scenarios. Instead of running a script and ending, an object persists and can be used across different interfaces....CLT/WEB/Synthea Java integration.

Proposal

For now MDT only depends on two external libraries, pandas and requests, however, its not immediately clear that these are required. We should consider using the built in python virtual environment module venv and a requirements.txt file.

Rationale

For contribution and development its typically a good idea to pin dependencies. Pinned dependencies ensure all contributors are working with the same version of 3rd party deps and help standardize contribution to the repo.

We would need to document the process of setting up a virtualenv and using the requirements file to install deps

• python -m venv venv
• pip install -r requirements.txt

Proposal

Synthea does offer a way to populate sig and days' supply information into the Generic Module Framework JSON. I am familiar with the format (FHIR).
http://hl7.org/fhir/DSTU2/MedicationOrder.html -> see dosageInstruction node

MEPS prescription data has fields for RXQUANTY and RXDAYSUP from which we may be able to infer a sig and a days' supply.

Challenge: this information is at the prescription level, but we are aggregating at the ingredient/product level.

Are there other MEPS fields that could help us build a better sig?
How reliably are those fields filled out?
How do we aggregate the quantity vs days' supply at a product/ingredient level?
We can default to no sig if they aren't complete for a medication.

Rationale

Because it would be sweet.

Problem Statement

Synthea has observations.csv files that provide lab values for each patient.

In order to represent realistic clinical decision making in Synthea, the simulator should account for dose adjustments based on a patient's lab vales.
For example, levothyroxine dosing based on T3/T4 lab values.

Criteria for Success

• Create a feature in the MDT (or Synthea) to adjust probabilities of medication order doses based on lab values (e.g., CrCl < 60)

Additional Information

• May be able to use OpenFDA and NLP: https://open.fda.gov/apis/drug/label/
• Also use logic based on work in issue #69 to select doses

Problem Statement

MEPS is rich with other care and patient-level details such as insurance type, visit type, race/ethnicity, family, education,
employment status, health status, language(s), and medical conditions.

Criteria for Success

[Measureable outcome if possible]

Additional Information

[ways one might accomplish this task, links, documentation, alternatives, etc.]

Problem Statement

Too granular going from NDC to IN/MIN.

Criteria for Success

NDC is primary key.

Additional Information

Ask Kent to explain everything again after meeting.

Just testing Jira integration.

MDT-4

Problem Statement

In order to compare Synthea to Medicaid, we need to really understand the pediatric asthma population in Synthea. How many patients are there? What medication(s) are they taking for asthma? How old are they when they start taking those medications / get their diagnosis? How do we define the population? How many patients do you need to run the simulation with to get some significant numbers of patients? What does the asthma module actually do? What other interesting or useful things can you find out about how Synthea works?

Criteria for Success

Follow the notes in issue #10 to download and run Synthea locally. Become an expert at running Synthea and knowing how it generates pediatric asthma patient populations. Determine how we are going to define our pediatric asthma patient population in Synthea (diagnosis of childhood asthma?). Communicate with @dsfabian and @kristentaytok to ensure you aren't duplicating efforts.

Additional Information

Take notes about what you find so we can use them for the final paper. You can take notes on this issue if you want.

Problem Statement

Synthea has allergy profiles created by the drug_allergy module and a medications.csv file that provides start/stop dates.

To improve the realistic medication data in Synthea (i.e., simulate clinical decision making), the simulator needs to account for decisions to rule out certain medication therapies based on factors like allergies and drug interactions.

Criteria for Success

• Create a way for MDT (or Synthea) to adjust probabilities of medication orders based on a patient's drug allergy and active medications profiles (e.g., if a severe drug allergy then adjust the probability to 0%)

Additional Information

• By leveraging data from NLM
• Someone has created a drug interaction tool: https://github.com/uziminhas/synthea_NLM_api_demo - perhaps we can adapt, expand upon, or join forces to improve both features & integrate into Synthea

Problem Statement

MDT needs input from a user to produce output. In general, this is at least one RxClass tuple or a list of RxNorm RXCUIs or maybe a combination of one or more of both of these things depending on how fancy we are trying to get.

Would need to handle:

• Medication selection as described above (RxClass tuple or RXCUI list or combination of both) - potentially with a line for logic (i.e. 1 AND 2 AND NOT 3)
• Age range distribution Y/N
• Age ranges (if age range distribution == Y)
• Gender distribution Y/N
• State distribution Y/N
• Dose form / dose form group filters (list of names of DFs / DFGs)
• Dose form filter method (include or exclude) - include is default if blank
• Maybe a file name for the output folder / module that gets created (or some sort of default if this is left blank)

We talked about using a JSON file as a way to input this type of thing.
Could maybe alternatively use a CSV.
Could alternatively use a CLI.
Could alternatively use the UI that @dsfabian mentioned to populate some sort of input.

Criteria for Success

Input mechanism makes it fairly easy to rapidly input different combinations of medications.

Additional Information

Maybe consider what would be the most seamless way to integrate this with Synthea if desired. Perhaps JSON is the most likely approach.

Problem Statement

We will need to aggregate Synthea medications to a level where it can be compared to the Medicaid or MEPS data to see if it is similar (to Medicaid) or different (than the old Synthea simulation).

Criteria for Success

Synthea should be able to be joined to the df_output CSV in our MDT output and aggregated to the medication ingredient level for the comparison.

Additional Information

Problem Statement

Because our MedicationOrder names are named with the specific medication name, we need to instead end that medication with a reference to the attribute we assigned it to.

We will assign our medications to an attribute of <<module_name>>_medication so we can end the meds by referencing that attribute as well.

Criteria for Success

The Asthma module no longer references "Prescribe_Maintenance_Inhaler" or "Prescribe_Emergency_Inhaler" and instead references the attributes from those respective MDT submodules.

https://github.com/synthetichealth/synthea/blob/master/src/main/resources/modules/asthma.json

"Maintenance_Medication_End": {      
"type": "MedicationEnd",      
"medication_order": "Prescribe_Maintenance_Inhaler",      
"direct_transition": "Emergency_Medication_End"    
},    
"Emergency_Medication_End": {      
"type": "MedicationEnd",      
"medication_order": "Prescribe_Emergency_Inhaler",      
"direct_transition": "Childhood_Asthma_Subsides"    
},

Additional Information

https://github.com/synthetichealth/synthea/wiki/Generic-Module-Framework%3A-States#medicationend

Should probably call our modules:

• Maintenance Medication
• Emergency Medication

...which means by default they will have attributes of:

• maintenance_medication_prescription
• emergency_medication_prescription

NOTE: Also include this in the README / documentation. #47

Problem Statement

Prescription details (i.e. sig) are unreliable and should be considered a beta feature.

Criteria for Success

By default, running MDT should not result in prescription details (i.e. sig). Changing a setting in settings.yaml should turn it on. README should clearly state that this is a beta feature.

Additional Information

Relates to #20

Problem Statement

We need to think of a reliable way to name states so they are unique per medication. There should probably also be a failsafe that adds a digit to the end of the transition in the event there is a duplicate.

Does Synthea have a capitalization style guide? I prefer lower case, but I have seen lots of camel case in Synthea. We should follow what Synthea does.

Example:

• prescribe_hypothyroidism_medication
• prescribe_levothyroxine_product
• prescribe_levothyroxine0_125Oral_Tablet

Criteria for Success

Don't run into validation errors in the Synthea Generic Module Builder when testing our work.

Additional Information

Check Synthea documentation for more info.

Email response from Synthea team:

Hi Joey,
Thank you for your question. We assume you are asking about a convention for naming of states within a Synthea module, since transitions rely upon state names. There is no consistent naming convention for states within Synthea. Our team followed a standard naming convention of capitalizing the first letter and concatenating all words together with an underscore like this: Condition_Chronic_Neck_Pain. We did the same when specifying attributes and transitions, since these rely upon the state name. We suggest that whatever convention you choose for naming your states, just be consistent within the same module.
Feel free to reach out if you have further questions,
The Synthetic Data Challenge Team

Problem Statement

Researchers often want to study changes over time and developers need to account for changes in their apps to allow users to change information or have different options based on new information. And clinicians need fill and adherence information to make treatment decisions.

The MDT (and Synthea) currently model one prescription that does not end and has 100% adherence. In order to simulate realistic medication data, these dynamics of changes over time and medication adherence patterns need to be accounted for.

Criteria for Success

• Adjust Synthea's medication orders to have breaks in start/stop dates (to simulate adherence patterns)
• Add logic and a process for patients to transition between doses over time

Additional Information

• can use MEPS data (esp across years, after this ticket is complete)

Problem Statement

We will eventually need to plug our custom module(s) / submodule(s) into Synthea and be able to see how the synthetic health data output differs before and after. We need to understand how to do this and what format Synthea expects this to be in.

Criteria for Success

Run a Synthea instance locally using an existing module. Make a small change to that module (maybe change the RXCUI of a medication that was prescribed in a module/submodule?) and run Synthea again. The change to the module should be identifiable in the second output.

Additional Information

I would be particularly curious if we could find an example that uses a table-based transition.

Proposal

If users want to do multiple different runs of the MDT, they should be able to have the output of each run end up in a different folder. Maybe if there already exists a folder named the same, we add an incremental number to the end of the folder name.

Rationale

I was playing with MDT and it was annoying to have to delete all the distribution CSVs each time I ran the tool.

Problem Statement

Need to understand the Synthea Generic Module Framework documentation and mock up a document with real working JSON to use as a starting point to reverse engineer a Python solution to automate the generation of similar documents.

Criteria for Success

Validate this mockup in the online module builder tool and/or run it through a local instance of Synthea and see what happens.

Additional Information

Notes and links to the Synthea Generic Module Framework documentation here.

Problem Statement

To achieve more granular combinations of RXCUIs, will likely need the ability to generate more complex RxClass queries.

Criteria for Success

Should be able to search by 2 or more RxClass ID/rela combos + include individual RXCUIs to add to the list of RXCUIs returned by the RxClass search. Should also be allowed to not search RxClass at all and instead just input individual RXCUIs.

Should be able to EXCLUDE 1 or more RxClass ID/rela combos + exclude individual RXCUIs from the final list of RXCUIs that get sent downstream to other steps in MDT.

The above is just my interpretation - if you have other ideas of how to implement this, go for it.

Additional Information

@yevgenybulochnik should be building functionality into the settings YAML/JSON file to accommodate these inputs. Please coordinate so you are both aligned in how you are building these components.

Proposal

If a developer wants to only show distributions for the lowest 50% of strengths for a population, maybe we could give them an option to specify that in the settings?

Could pull in the FDA product column called ACTIVE_NUMERATOR_STRENGTH, split it by a semicolon (;) and then work with the strengths in that column to get the lowest (or lowest %) strengths only - by medication ingredient.

This is just a thought in progress.

Rationale

I'm wondering if the feedback we will get from clinicians is that our starting dose for these patients is too high. This could be a way to mitigate that.

Example query:
select NONPROPRIETARYNAME, PROPRIETARYNAME, ACTIVE_NUMERATOR_STRENGTH from product p where NONPROPRIETARYNAME like('%fluticasone%');

Proposal

We should reorganize the repo into an installable python package with the potential to publish to PyPi. I would suggest reorganizing as per pypi recommendations. An example branch yevgeny/restructure was created off an earlier version of the project with this setup.

packaging_tutorial/
├── LICENSE
├── pyproject.toml
├── README.md
├── setup.cfg
├── setup.py  # optional, needed to make editable pip installs work
├── src/
│   └── example_pkg/
│       └── __init__.py
└── tests/

Rationale

1. Currently the only way to consume this repo is by changing hard coded values in rx_api.py and then running this module. In a package structure, we could import functions in more unique ways and allow developers to consume the codebase in a different manner.
2. Package structure will allow us to more easily create an installable cmd line tool for inputs if we want.
3. Those using jupyter notebooks can more easily import parts of the codebase to explore functions, and contribute.
4. This directory structure allows a way to test against a currently installed python module.
5. The package itself can be installed in editable mode to help with development

Problem Statement

Synthea users may want to research medication costs and with a realistic representation of medications prescribed at the NDC level, costs from a variety of publicly-available data sources can help address these questions.

Criteria for Success

• Create a process to calculate medication costs in the MDT and add them to Synthea's medications output.

Additional Information

• Through publicly available datasets such as NADAC, Medicare or Medicaid, or MEPS

Problem Statement

[What needs to be done and why]

Criteria for Success

[Measureable outcome if possible]

Additional Information

[ways one might accomplish this task, links, documentation, alternatives, etc.]

Problem Statement

Remarks are a useful place to store information about how and why a module was created. We should maximize the utility of these remarks sections.

There is one for the overall module and many (all?) subsections have a place for remarks as well.

They are a list of strings to allow for line breaks to make things human-readable.

Example:

	"remarks": [
		"This submodule prescribes a medication",
		"which may_treat / may_prevent Hypothyroidism which has a dose form",
		"containing oral.",
		"IT IS UP TO THE CALLING MODULE TO END THIS MEDICATION BY ATTRIBUTE.",
		"All Medications prescribed in this module are assigned to the attribute ",
		"'hypothyroidism_prescription'.",
		"Dose forms:",
		"Age ranges:",
		"Gender considered: y/n",
		"State considered: y/n",
		"Source for medication information: ",
		"<Links to RxClass search pages or API endpoint?>",
		"Source for population statistics: ",
		"<Links to MEPS website?>",
		"Medications prescribed in this module:     ",
		"1. Medication 1  ",
		"2. Medication 2  ",
		"3. etc  "

Criteria for Success

We are happy with our decision.

Additional Information

See what other modules and submodules put in these sections.

Problem Statement

PR #32 removed the mdt_config.py module, the meps_data_reader.py contains an import for this config file which causes the module to break.

Criteria for Success

I believe all that needs to occur is to remove this line, I dont believe there are any dependencies to the config in this file

Problem Statement

A user can't tell the likelihood of a patient getting one ingredient over another / one product over another by just reviewing the remarks / module - they have to open each CSV and do some math.

Criteria for Success

Would like a percent added to each line of the remarks for ingredient and product sections that shows the % of MEPS population that takes that ingredient / product.

Example (dummy data - just for example):

1.  94% fluticasone
2.   3% budesonide
3.   2% beclomethasone
4.   1% mometasone

Nice to have: would like to have the percentages align right so everything lines up nicely like in the example above, but this is just me being OCD. Not sure the most effective way of doing this. There's probably a basic python string function that can accomplish this.

Additional Information

I will make a branch and point out exactly where this could be added to the JSON creation function. Since the remarks are just output to the .txt log file, we can kill two birds with one stone by making this change.

Problem Statement

Right now, we have a config.py file with a "MEPS_CONFIG" dict inside - which at the very least should probably be renamed to MDT_CONFIG or something. But we just need to have a good way to use config variables within MDT. I am already using these in a couple of the functions in the MDT utils.py file so would be good to make sure I am doing it right.

Criteria for Success

N/A

Additional Information

N/A

Problem Statement

Need to generate distribution tables in CSV format that provide the distribution of patients in:

• Age range
• Gender
• State

And percent chance that this patient would be prescribed:

• Generic medication (IN/MIN)
• Prescribable product (SCD/SBD/GPCK/BPCK)

Criteria for Success

CSV follows the rules in this documentation.

We want one transition table that determines the likelihood a patient would be prescribed a given ingredient (IN/MIN) over another based on the demographic information above. And then we want one distribution table per ingredient (IN/MIN) that contains the likelihood that a patient would be prescribed a particular product containing that ingredient (SCD/SBD/GPCK/BPCK). So for hypothyroidism, we would have something like:

1. prescribe_hypothyroidism_medication.csv (this is the IN/MIN one)
2. prescribe_levothyroxine_product.csv
3. prescribe_liothyronine_product.csv
4. prescribe_thyroid_usp_product.csv

Synthea appears to prefer zeroes instead of nulls, M/F vs Male/Female, and no spaces between the age ranges (i.e. 18-44 not 18 - 44).

Additional Information

Example mockup here.
Can leverage the SQL query Joey wrote to be a transition from IN/MIN to SCD/SBD/GPCK/BPCK to NDC.
We will need to decide on a naming convention for our transitions, but that's not necessarily a dependency for this work.