CodeRx

Short rant about Centers for Medicare & Medicaid Services (CMS) ASP data. First of all, it seems like the default format of this report is in Excel. Which is fine if you are a human. If you are a computer trying to programmatically extract and load this data into a database, that means you have to use something like Pandas read_excel instead of just being able to directly load the data into a database like you could do if it was in CSV format. Fortunately, they also offer a "section 508" version - which I had never heard of. Essentially it means they offer a CSV version of the file in addition to the Excel version. Section 508 refers to a 2017 final rule from the U.S. Access Board that updates accessibility requirements for information and communication technology. This makes me happy because now I can use the CSV file. HOWEVER... even starting with a CSV file, there are both extra rows at the top of the file above the header row and (super fun) an extra column with nothing in it (yay!) that I need to account for. This is just annoying more than anything, but hey - this is a rant. On top of all of this, there's not an obvious way to automate the download of these files. They are updated quarterly on apparently a random day of the month. So my best guess is just checking weekly for an update and hoping for the best. Open to other suggestions here! End rant. Follow me for more complaining about open drug data as a we pave the way to a future where nobody needs to deal with this raw data ever again. ??

Getting terminology wrong is almost a rite of passage on FHIR projects. It’s shouldn’t be. SNOMED, LOINC and ICD all predate FHIR by many decades. LOINC - 1994 SNOMED - 1965 ICD - 1860! So what’s the problem? Why is it so hard? FHIR projects tend to attract developers and sometimes product people with little or no working experience in healthcare data. Many of them come from backgrounds where words and phrases are decided on by UX and marketing people. The idea that you can’t simply “make it up” is new to them. This leads to projects being built using FHIR where terminology is not considered important at the outset. It only becomes important when the project has progressed to the stage where more knowledgeable stakeholders get involved and start asking hard questions. At which point the problem becomes costly to fix. - New resources with expertise have to be brought in - Deadlines get pushed back - Expectations reduced - Everyone is unhappy How can this be fixed? Terminology needs a big box of its own on every architectural diagram. The bigger the box the better, so it isn’t allowed to slip into the background. Your project needs terminology expertise right at the start. Someone with enough knowledge and standing to push back against the "rapid fire" developers who want to make it up on the fly. And everyone on the team needs to be educated. - A basic understanding of terminology and code systems - How to use it with FHIR - What NOT to do! Start with Grahame Grieve’s video from a 2022 FHIR meetup. It explains terminology from a FHIR perspective. https://lnkd.in/gjhTur5Q Follow that up with a read through of this post from Dylan Klein on code systems: https://lnkd.in/e9adCdte Don’t accept that getting terminology wrong is expected and ok. Consider it a project failure and a leadership failure.

From idea to working prototype in under a week using CodeRx drug data. ?? I met with the CEO of Awell for coffee a few weeks ago and he told me of a crazy idea to do an internal company hackathon with the goal of creating a feature to allow patients to snap a single photo of all their prescriptions and use AI to extract a structured med list. His team had the skills to develop the AI functionality, but were lacking drug data to power the structured extraction. After chatting for a little while, I identified a small handful of data sets that I could generate using our data platform which would give his team what they needed to do this work. 1?? Product-level information - Product-level RXCUIs, normalized descriptions, and prescribable names of all drug products in RxNorm. 2?? Product synonyms - One-to-many mappings of product-level RXCUIs to synonyms from a variety of sources, including RxNorm, NADAC, and FDA. This helps account for different ways a prescription label might be populated. 3?? NDCs to label images - Assuming a component of the AI may eventually include OCR / image recognition, this would help identify a product (maybe an OTC product or inhaler) based solely on its label image. From the label identification, the AI could trace from NDC to product-level RXCUI. 4?? NDCs to products - If the AI could extract an NDC (say from the packaging of an OTC product or maybe a prescription ear drop package), it could use this file to map that NDC to a product-level RXCUI. I provided the CodeRx data and a bit of documentation (pictured in the comments) to the Awell team in under a week, they were able to use it to create a prototype that actually works! If you have a project that would benefit from drug data, please reach out via the contact form on our website or in the comments below.

??

Calling all clinicians who code! Check out this unique conference and consider signing up to be a speaker. Really looking forward to this as Kevin Maloy, MD is constantly putting out high quality tutorials and hosting meetups about extremely practical examples of healthcare technology. A conference like this feels like the natural evolution of his great work.

Wanted to share a well-thought-out, data-driven analysis of pharmacy closures in 2024 by Benjamin Jolley in his insightful Ramblings of a Pharmacist Substack. 2275 pharmacies have closed so far in 2024. 1100 entrepreneurs have had their dreams of pharmacy ownership crushed in 2024. His methodology exposes the difficulty in tracking pharmacy closures due to the amount of manual effort required to track them down. Some of this is due to the nature of the data source (pharmacies are not under any obligation to de-list their location with NCPDP, so closed pharmacies may linger on the list for a while). Without access to clean data, a lot of manual leg work is required. 40 hours of work along with a pre-existing network of pharmacists to help crowd-source a data cleanup project. Not everybody has the same enthusiasm or resources as Benjamin, but we're glad he shares this data with us. Check out this article (?? link in comments) and please subscribe to Benjamin's Ramblings of a Pharmacist Substack!

New Substack article this week! ?? We're building a data mart to make it easier for anyone to know drug packaging details like how much drug product is in a given drug package, inner-outer NDC mappings, and detailed discrete data about packaging contents. Link in the comments. ??

How is a flu shot like a can of Diet Coke? Have you ever been browsing the shelves in grocery store and wondered if it was a better deal to get the 12 pack or the 2 liter (for instance)? Usually, they have the price broken down **per ounce** at the bottom of the price tag so you can easily compare the two. In order to do this, you need to know the total pack size (144 oz for the 12 pack). Just like pop (former Midwesterner here ??♂?) is available in 12 packs of 12 oz cans / single 2 liter bottles / etc, flu shots are available for pharmacies to purchase in 10 packs of 0.5 mL pre-filled syringes / single 5 mL multi-dose vials / etc. For drug products (like the flu shot), there is no good source of (discrete, easily machine-readable) public information for how much drug product is in any given drug package. In other words, there's no easy way to know that the NDC representing the carton in this image contains a total of 5 mL of influenza vaccine. Sure you could pay a lot of money for a license to commercial drug information database to provide this information, but there should be a cheaper (or free) alternative. Unlocking this data point could also make it easier for anyone working with drug pricing, drug equivalency, and basic drug information. ?? This is exactly what we're trying to solve with our next data mart. Newsletter article coming soon with more details. Stay tuned here or subscribe to us on Substack to get the article in your inbox as soon as it's published. PS - Sorry for the long hiatus. Have been busy building. We're back with some content! ??

Okay, hot take and maybe I'm crazy, but hear me out - running through the logic, every pharmacy in the country should be live on Carequality/Commonwell already. 1. Pharmacies want access to clinical history from providers to understand allergies/contraindictions, have the problem list, and see the full set of prescriptions a patient has 2. Clinical history from providers is available via Carequality, Commonwell, etc, but requires treatment purpose of use and reciprocity 3. Pharmacies are already giving away medication dispense history to providers via Surescripts Medication History, but cannot pull medication history from other pharmacies via that mechanism. 4. The "price" of being able to pull clinical data from providers is reciprocity (pharmacies contributing back unique clinical data) 5. If pharmacies are not being paid by Surescripts for med dispense history today, then they can get meds, allergies, problems, and all sorts of clinical data "for free" by giving the same data they're already pushing through Surescripts, but via HIEs What am I missing? Why are there not a million pharmacies on the nationwide networks?

Excited to share news about something we've been working on for a while now. It's a big first step towards making open drug data more accessible to people that could benefit from using it. This strategic partnership provides users of Tuva Health's open-source healthcare data analytics platform an easy option to translate NDCs to RxNorm product codes (RXCUIs), and then classify those product codes using ATC 1-4 classes. Using open drug data transformed using open-source data pipelines (?? SageRx), we can solve fundamental problems like "which medication product is represented by this NDC?" and "what type of medication is it?" for analysts that only have NDC-level data to work with. Really looking forward to growing this partnership and building out other data offerings that are beneficial to analysts, researchers, and startups working with medication data.