coderxio / medication-diversification Goto Github PK
View Code? Open in Web Editor NEWMore realistic synthetic medication data.
License: Other
More realistic synthetic medication data.
License: Other
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
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?
Spot check a lot of common asthma medications and ensure they are in the list.
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
[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
[Measureable outcome if possible]
[ways one might accomplish this task, links, documentation, alternatives, etc.]
Different OS have different methods for writing paths. Pathlib path objects can handle this for us.
All paths work using Pathlib
The path to light starts with Pathlib
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.
All numbers are tenths decimal place and total to 1.0 per row.
https://github.com/synthetichealth/synthea/wiki/Generic-Module-Framework%3A-Transitions#table
If we don't put any date limits on our modules, patients in 1901 are going to be getting modern medications.
Some automated way to query FDA to link first available date of drug application to a product RXCUI or NDC.
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)"
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.
To meet the submission requirements of "evidence of validation".
https://drive.google.com/drive/folders/1Nx9C1n_ymsNRPrk6v4UYUtQcGLY2OihB
SciPy has a chi-square function, which may be useful here? https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.chisquare.html
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?):
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.
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
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.
Input albuterol
and get back only single ingredient albuterol
products.
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.
Creating this as a placeholder for ongoing work on README and docs.
Both sections look professional and are easy to use for developers and users of MDT.
Some content is already in issues like #10.
Need code to be open source as part of challenge criteria.
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.
Will wait to hear back from the challenge team.
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
.
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
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.
Help people get up to speed and understand how to use our tool. Could also host a static site from here eventually.
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.
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
},
N/A
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.
MITRE (company who developed and maintains Synthea) flagged this (and general contraindication logic) as an important feature they'd like to see added
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).
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.
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.
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.
Note: we would be comparing 2018 data.
https://data.medicaid.gov/State-Drug-Utilization/State-Drug-Utilization-Data-2018/e5ds-i36p
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.
Food for thought
We need to get the meps data down into one table so that it can be pulled into a pandas dataframe for gathering distributions.
SQL file can be read and will generate a meps_table in database using the same functions used for making the rxcui_ndc table
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",
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.
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.
Users need to be able to filter by dose form group (DFG). DFG is a grouping of dose form (DF).
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?
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:
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).
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.
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.
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
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.
Because it would be sweet.
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.
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.
[Measureable outcome if possible]
[ways one might accomplish this task, links, documentation, alternatives, etc.]
Too granular going from NDC to IN/MIN.
NDC is primary key.
Ask Kent to explain everything again after meeting.
Just testing Jira integration.
MDT-4
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?
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.
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.
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.
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:
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.
Input mechanism makes it fairly easy to rapidly input different combinations of medications.
Maybe consider what would be the most seamless way to integrate this with Synthea if desired. Perhaps JSON is the most likely approach.
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).
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.
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.
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"
},
https://github.com/synthetichealth/synthea/wiki/Generic-Module-Framework%3A-States#medicationend
Should probably call our modules:
...which means by default they will have attributes of:
NOTE: Also include this in the README / documentation. #47
Prescription details (i.e. sig) are unreliable and should be considered a beta feature.
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.
Relates to #20
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:
Don't run into validation errors in the Synthea Generic Module Builder when testing our work.
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
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.
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.
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.
I would be particularly curious if we could find an example that uses a table-based transition.
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.
I was playing with MDT and it was annoying to have to delete all the distribution CSVs each time I ran the tool.
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.
Validate this mockup in the online module builder tool and/or run it through a local instance of Synthea and see what happens.
Notes and links to the Synthea Generic Module Framework documentation here.
To achieve more granular combinations of RXCUIs, will likely need the ability to generate more complex RxClass queries.
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.
@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.
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.
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%');
NONPROPRIETARYNAME | PROPRIETARYNAME | ACTIVE_NUMERATOR_STRENGTH |
---|---|---|
Azelastine Hydrochloride and Fluticasone Propionate | DYMISTA | 137; 50 |
fluticasone propionate and salmeterol | fluticasone propionate and salmeterol | 50; 100 |
fluticasone propionate and salmeterol | fluticasone propionate and salmeterol | 50; 250 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate and Salmeterol | Fluticasone Propionate and Salmeterol | 55; 14 |
Fluticasone Propionate and Salmeterol | Fluticasone Propionate and Salmeterol | 113; 14 |
Fluticasone Propionate and Salmeterol | Fluticasone Propionate and Salmeterol | 232; 14 |
Fluticasone propionate | Good Sense 24 hour allergy nasal | 50 |
Fluticasone Propionate | Good Sense 24 hour allergy nasal | 50 |
Fluticasone propionate | basic care allergy relief nasal | 50 |
fluticasone propionate | FLONASE | 50 |
fluticasone propionate | CHILDRENS FLONASE | 50 |
fluticasone furoate | FLONASE SENSIMIST | 27.5 |
fluticasone furoate | FLONASE SENSIMIST | 27.5 |
fluticasone propionate | FLUTICASONE PROPIONATE | 0.5 |
fluticasone propionate | Fluticasone Propionate | 0.05 |
fluticasone propionate | FLUTICASONE PROPIONATE | 0.5 |
fluticasone propionate | FLOVENT | 50 |
fluticasone propionate | FLOVENT | 250 |
fluticasone propionate | FLOVENT | 100 |
fluticasone propionate and salmeterol | ADVAIR | 50; 100 |
fluticasone propionate and salmeterol | ADVAIR | 50; 250 |
fluticasone propionate and salmeterol | ADVAIR | 50; 500 |
fluticasone propionate and salmeterol xinafoate | ADVAIR HFA | 45; 21 |
fluticasone propionate and salmeterol xinafoate | ADVAIR HFA | 115; 21 |
fluticasone propionate and salmeterol xinafoate | ADVAIR HFA | 230; 21 |
fluticasone propionate | FLOVENT | 44 |
fluticasone propionate | FLOVENT | 110 |
fluticasone propionate | FLOVENT | 220 |
fluticasone furoate and vilanterol trifenatate | Breo Ellipta | 100; 25 |
fluticasone furoate | Arnuity Ellipta | 100 |
fluticasone furoate | Arnuity Ellipta | 200 |
fluticasone furoate and vilanterol trifenatate | Breo Ellipta | 200; 25 |
fluticasone furoate, umeclidinium bromide and vilanterol trifenatate | Trelegy Ellipta | 100; 62.5; 25 |
fluticasone furoate | Arnuity Ellipta | 50 |
fluticasone furoate, umeclidinium bromide and vilanterol trifenatate | Trelegy Ellipta | 200; 62.5; 25 |
Fluticasone propionate | 24 Hour Allergy Nasal | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Allergy Nasal | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Azelastine Hydrochloride and Fluticasone Propionate | Azelastine Hydrochloride and Fluticasone Propionate | 137; 50 |
fluticasone propionate and salmeterol | Wixela Inhub | 100; 50 |
fluticasone propionate and salmeterol | Wixela Inhub | 250; 50 |
fluticasone propionate and salmeterol | Wixela Inhub | 500; 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone propionate | RUGBY FLUTICASONE PROPIONATE NASAL | 50 |
Fluticasone Propionate | Fluticasone Propionate | 0.5 |
Fluticasone Propionate | Fluticasone Propionate | 0.05 |
Fluticasone Propionate | Fluticasone Propionate | 0.5 |
fluticasone propionate | Cutivate | 0.5 |
Fluticasone propionate | Up and Up Allergy Relief Nasal | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Up and Up allergy relief nasal | 50 |
Fluticasone propionate | allergy nasal | 50 |
Fluticasone Propionate | childrens allergy nasal | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone propionate | Signature Care Allergy Relief | 50 |
Fluticasone Propionate | signature care childrens allergy relief | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone propionate | 24 Hour Allergy Relief nasal | 50 |
Fluticasone propionate | allergy relief nasal | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | TopCare Childrens Allergy Relief Nasal 24 Hour | 50 |
Fluticasone propionate | topcare fluticasone propionate nasal | 50 |
Fluticasone Propionate | Allergy Relief | 50 |
Fluticasone propionate | Nasopro 24 | 50 |
fluticasone propionate | Childrens Nasopro | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone propionate | Equaline Fluticasone Propionate | 50 |
Fluticasone Propionate | Equaline fluticasone propionate | 50 |
Fluticasone propionate | Allergy Relief | 50 |
Fluticasone propionate | 24 hour allergy relief nasal | 50 |
Fluticasone Propionate | careone childrens allergy relief | 50 |
Fluticasone propionate | CareOne Allergy Relief | 50 |
fluticasone propionate | Beser | 0.5 |
Fluticasone propionate | Beser | |
azelastine hydrochloride, fluticasone propionate | AZELASTINE HYDROCHLORIDE AND FLUTICASONE PROPIONATE | 137; 50 |
Fluticasone Propionate | Fluticasone Propionate | 0.05 |
Fluticasone Propionate | Fluticasone Propionate | 0.5 |
fluticasone propionate | fluticasone propionate | 0.5 |
Fluticasone propionate | Good Neighbor Pharmacy Fluticasone Propionate | 50 |
Fluticasone Propionate | Good Neighbor Pharmacy Childrens Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone propionate | equate allergy relief | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone propionate | SunMark allergy relief nasal 24 hr | 50 |
fluticasone propionate and salmeterol | ADVAIR | .05; .25 |
fluticasone propionate | FLOVENT | 110 |
fluticasone propionate | FLOVENT | 44 |
fluticasone propionate | FLOVENT | 220 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 0.5 |
fluticasone propionate | FLOVENT | 50 |
fluticasone propionate | FLONASE | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate and Salmeterol | Fluticasone Propionate and Salmeterol | 232; 14 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 0.5 |
fluticasone propionate and salmeterol | Fluticasone Propionate and Salmeterol | 100; 50 |
fluticasone propionate and salmeterol | Fluticasone Propionate and Salmeterol | 250; 50 |
fluticasone propionate and salmeterol | Fluticasone Propionate and Salmeterol | 500; 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone propionate | Fluticasone propionate | 50 |
Fluticasone propionate | sound body allergy relief | 50 |
Fluticasone Propionate | Fluticasone Propionate | 0.05 |
fluticasone propionate | FLOVENT | 44 |
fluticasone propionate | FLOVENT | 110 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Allergy Relief | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone propionate | exchange select allergy relief | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone propionate | family wellness allergy relief nasal | 50 |
fluticasone propionate | FLUTICASONE | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | DG Health childrens allergy relief nasal | 50 |
Fluticasone propionate | DG Health Allergy Relief Nasal | 50 |
Fluticasone propionate | allergy relief nasal | 50 |
fluticasone propionate (glucocorticoid) | FlutiCare | 50 |
Fluticasone Propionate and Salmeterol | AirDuo Digihaler | 14; 55 |
Fluticasone Propionate | ArmonAir Digihaler | 55 |
Fluticasone Propionate and Salmeterol | AirDuo Digihaler | 113; 14 |
Fluticasone Propionate and Salmeterol | AirDuo Digihaler | 232; 14 |
Fluticasone Propionate | ArmonAir Digihaler | 113 |
Fluticasone Propionate | ArmonAir Digihaler | 232 |
fluticasone propionate | ArmonAir Digihaler | 55 |
Fluticasone Propionate and Salmeterol | AirDuo Digihaler | 55; 14 |
fluticasone propionate | ArmonAir Digihaler | 113 |
Fluticasone Propionate and Salmeterol | AirDuo Digihaler | 113; 14 |
fluticasone propionate | ArmonAir Digihaler | 232 |
Fluticasone Propionate and Salmeterol | AirDuo Digihaler | 232; 14 |
Fluticasone Propionate and Salmeterol | AirDuo RespiClick | 55; 14 |
Fluticasone Propionate and Salmeterol | AirDuo RespiClick | 113; 14 |
Fluticasone Propionate and Salmeterol | AirDuo RespiClick | 232; 14 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
fluticasone propionate | FLUTICASONE | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Azelastine hydrochloride and Fluticasone propionate | Azelastine hydrochloride and Fluticasone propionate | 137; 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
FLUTICASONE | FLUTICASONE | 50 |
FLUTICASONE | FLUTICASONE | 50 |
FLUTICASONE | FLUTICASONE | 50 |
FLUTICASONE PROPIONATE | FLUTICASONE PROPIONATE | 0.5 |
Fluticasone propionate | health mart allergy relief nasal 24 hr | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
fluticasone propionate | FLOVENT | 100 |
fluticasone propionate | FLUTICASONE PROPIONATE | 0.5 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone propionate | Core Values Allergy Relief | 50 |
Fluticasone propionate | Kirkland Signature Aller Flo | 50 |
Fluticasone propionate | Welby Fluticasone | 50 |
Fluticasone propionate | welby allergy relief | 50 |
Fluticasone Propionate | Allergy Relief | 50 |
fluticasone propionate and salmeterol | Fluticasone Propionate and Salmeterol | 100; 50 |
fluticasone propionate and salmeterol | Fluticasone Propionate and Salmeterol | 250; 50 |
fluticasone propionate and salmeterol | Fluticasone Propionate and Salmeterol | 500; 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone propionate | Berkley and Jensen Allergy Relief | 50 |
Fluticasone Propionate | Fluticasone Propionate | 0.5 |
fluticasone propionate | FLOVENT | 44 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
fluticasone propionate | FLUTICASONE | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone propionate | Harris Teeter Allergy Relief Nasal | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | FLUTICASONE PROPIONATE | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
Fluticasone Propionate | Fluticasone Propionate | 50 |
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/
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.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.
[What needs to be done and why]
[Measureable outcome if possible]
[ways one might accomplish this task, links, documentation, alternatives, etc.]
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 "
We are happy with our decision.
See what other modules and submodules put in these sections.
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.
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
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.
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.
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.
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.
N/A
N/A
Need to generate distribution tables in CSV format that provide the distribution of patients in:
And percent chance that this patient would be prescribed:
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:
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).
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.