Medications prescribed before they were actually available

[dehall]

Review from physicians has highlighted inconsistencies in the modules, where many medications are being prescribed before those medications were actually available.

For example, the Lung Cancer module prescribes Cisplatin (FDA approved in the US in 1978) and Paclitaxel (first isolated in 1971, and FDA approved in 1993) with no date restrictions.

In addition to preventing drugs from being prescribed before actually available, the modules should take into account the medications previously available and used, and the impacts of those different drugs.

[mikeghen]

Is there a data source somewhere that has a list of drugs and the years they were approved?

[jawalonoski]

Well, at least for the United States I think you can find that information in here [I have not verified this]:

https://www.fda.gov/Drugs/InformationOnDrugs/ucm079750.htm

[spiros]

For the UK, you can use the Medicines and Healthcare products Regulatory Agency: http://www.mhra.gov.uk/spc-pil/ or the British National Formulary: https://www.medicinescomplete.com/mc/bnf/64/ although I unsure on completeness and concordance with US prescribing.

[damondouglas]

I think this may help as well for the US: https://www.fda.gov/Drugs/InformationOnDrugs/ucm129662.htm. For example, I remember Multaq was approved 7/1/2009 and it shows this in the Orange Book: https://www.accessdata.fda.gov/scripts/cder/ob/results_product.cfm?Appl_Type=N&Appl_No=022425

There is of course a time period between the initial approval date and when utilization begins in the real world. Perhaps a setting in the configuration file such as 3 months would be a safe bet on when we would see patients starting to use the medication. I'd argue that utilization depends more on economic factors rather than clinical.

[floer32]

Would it be sensible to have this be an input option and users can pick what to put for it? With the one(s) pointed out above as defaults or starting-points

Asking as I’d like to contribute a PR

[damondouglas]

@hangtwenty having served on Pharmacy & Therapeutics committee meetings, I like your idea because certain healthcare entities will have formulary review cycles. The P&T committees I've served on met monthly (this is typical) but there may be time needed to prepare monographs to submit for approval.

[floer32]

Interesting, so yeah the timeline would be part of the config

This could be handled in a conceptually similar way to the existing JSON input support. It’d be a new (and probably small) schema, but I could make sure it feels cohesive with the existing code and config.

I think I would also implement some Gradle tasks to help with getting the data, since seemingly this will be optional extra data.

How’s this for a plan:

1. Figure out the configuration schema. I would sketch this using OpenAPI, a very declarative and straightforward thing to collaborate on.
2. Identify the MVP of features within that. I’d imagine MVP is just a drug and an availability date, so essentially filtering out the drug from times before that.
3. Code the Java parts of the implementation, using fake hand coded data for testing at first. Will code it in a way that we know we can extend towards the other features.
4. Gradle/Etc to handle getting data for this.
   • Data Wrangling is necessary. I have my preferred tools (like Miller CLI tool, and Pandas) but they are not JVM. Maybe I can do the wrangling the way I know how to, and it can be a separate repo (and that repo could also publish/host the massaged data artifacts, if licensing allows).
5. Bringing it together, testing Gradle+JSONConfig+Java changes together, ironing out any kinks.
6. Docs and finish MVP

Does that sound practical @damondouglas @jawalonoski @spiros @mikeghen @dehall ?

[floer32]

Thinking about it, there will at least be one new repository for the data grabbing + wrangling + publishing/versioning. I can also put other WIP artifacts there like the OpenAPI schema.

So would it also make sense to write the new Java implementation code there, and that way it can be an optional dependency of Synthea? A plug-in.

I could imagine other plugins once the interface is figured out. Maybe there will be other FOSS ones. But maybe most importantly, a plug-in setup could allow users to add their own peculiar behaviors and take some burden off of flexibility/complexity within Synthea itself? Could be good...

Maintainers: would that separation be better or worse for you?

[jawalonoski]

Some initial thoughts:

• This would be a substantial pull request. I'm not sure how much work you're willing to put in, but I think it will be a lot to get this done.
• If you wanted a separate repo for data manipulation, that is fine, but this main repo needs some documentation (at a minimum in the wiki) on how and where the data is sourced from for citation purposes.
• If there is only a single default data set it needs to be US based. Apologies for all our international users.
• I've considered plug-ins, or at least defining some Java interfaces so users could write their own implementations in different spots. My take is that these interfaces have to be pretty specific to certain behavior (e.g. patient behavior in selecting a hospital). I suppose medication selection can be another behavior users could override.
• One issue that would need to be tackled would be how to tie the medication selection into the current modules. We also have to take into account how most users (who are not programmers) look at the modules using the module-builder (code) (app) -- when browsing a model how will users know what medications are being prescribed? Functionality would need to be added there.
• Another issue would be how would authors of new disease modules (again, often not programmers) add or update the medications they wanted to prescribe? Module builder again.
• A third issue will be medication costs. There is currently a medication cost file in src/main/resources/costs/medications.csv that needs to be included or separately maintained.

[dehall]

My only concern is I would want to make sure that this results in a net increase in realism. As already mentioned, we could find a list of when each medication was introduced, and it would be easy to conditionally pick one by date, or just not put those into records prior to that date. The problem is that different medications, or a lack of a certain medication, should impact the patient in different ways. If a disease module in Synthea only represents the course of one single type of medication, but a new generic system replaces that medication with a different one, is that patient's record still going to be realistic?

[jawalonoski]

@dehall That is a good point. We always said that if we wanted realism in the treatment, we'd have to have different modules for each disease every few years, so the standard of practice, procedures, and medications would update as the decades went by. But we always said we wouldn't do that for the foreseeable future for the sake of simplicity/maintainability. Is there a happy medium between year-by-year modules and medication availability? I don't know the answer to this question, and the answer probably depends on each disease.

[shabiel]

I also need to point out that RxNorm does not cover medications that got on the market and then off it before RxNorm was introduced; plus finding RxNorm codes for medications that are not on the market anymore is doable but not easy. You will want to consult me or the NLM RxNorm help for more information on how to do that properly.

…

--Sam

On Mon, Apr 1, 2019 at 9:56 AM Jason Walonoski ***@***.***> wrote: @dehall That is a good point. We always said that if we wanted realism in the treatment, we'd have to have different modules for each disease every few years, so the standard of practice, procedures, and medications would update as the decades went by. But we always said we wouldn't do that for the foreseeable future for the sake of simplicity/maintainability. Is there a happy medium between year-by-year modules and medication availability? I don't know the answer to this question, and the answer probably depends on each disease. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.