Stream: implementers
Topic: RXNorm --> NDC
Mohammad Wahid (May 28 2020 at 17:58):
As a a payer, we're storing our medication details in NDC as part of the claims processing. From what I have read, USCDI is mandating that the medication "Applicable standard" should follow " RXNorm, January 6, 2020 full release update. If so, then this means that will have to translate the NDCs to RXNorm?
Michele Mottini (May 28 2020 at 18:00):
Yes
Cooper Thompson (May 28 2020 at 21:59):
Or... "maybe"? The regulatory texts (including ONC Cures, MU3, and the CMS Cures rule) have always been very unclear with regard to terminology requirements. It is silent on areas like historical data, patient-entered data, data from other trading partners, research data that doesn't have standard codes yet, etc. As with a lot of regulatory text, you kinda just have to interpret it for yourself, or ask the regulatory bodies for clarification. Mapping NDC to RxNorm may be reasonable, but in general, mapping data you don't own can be risky. Getting the correct terms from the source of truth is an option that ensures you accurately communicate the data, but that can involve re-implementing your existing data connections.
Overall the ONC Rule and USCDI requirements were pretty well put together and did a good job striking a balance between being specific where appropriate, but open-ended where necessary. Though the open-ended areas make HIT developers nervous because sometimes we have to pick one of the many possible interpretations (e.g. what to do about 15-year old historical data received from a system that has gone out of business that was used by a health system that was acquired and merged a few times...), and live in fear that maybe we picked wrong. Though we try very hard to do the reasonable thing and meet the spirit of the regs.
Michele Mottini (May 28 2020 at 23:07):
The ONC regulation says that you have to conform to FHIR R4 US Core - that allows only RxNorm, doesn't it? (The CMS regulation does not mandate that, so you have wiggle room there I guess)
Lloyd McKenzie (May 29 2020 at 00:24):
Note that if your source of truth is an NDC code you can (and should) send that too.
Robert McClure (May 29 2020 at 17:35):
My interpretation is that you SHALL send the mapped RxNorm code and certainly SHOULD also send the original NDC code as an additional coding. You can get mapping of NDC to RxNorm via an RxNorm API. If you know the NDC is currently active, you use ndcproperties, or if you are unsure or know the NDC is no longer active, you use ndcstatus and one of the returned properties will be the RxNorm mapped to that NDC.
Cooper Thompson (May 29 2020 at 17:53):
I guess I know the lab area better than meds, but are there scenarios where meds just don't have RxNorm codes? E.g. meds in clinical trials?
Cooper Thompson (May 29 2020 at 17:54):
And patient-reported, where the specific drug or ingredient isn't specified?
Nathan Hall (Jun 01 2020 at 14:02):
It is possible that meds will not have an rxnorm, yes, specifically custom medications, compounds made in pharmacy, et. al.
Cooper Thompson (Jun 01 2020 at 16:48):
So should this be a US Core JIRA? We can't require RxNorm for MedicationStatement. It should probably be must-support 0..1, not must-support 1..1 as it is now. @Brett Marquard @Eric Haas
Brett Marquard (Jun 01 2020 at 16:51):
Isn't the binding extensible?
Lloyd McKenzie (Jun 01 2020 at 17:06):
How does extensible make a difference?
Brett Marquard (Jun 01 2020 at 17:08):
E.g. meds in clinical trials?
Brett Marquard (Jun 01 2020 at 17:10):
Per binding strength
To be conformant, the concept in this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
Cooper Thompson (Jun 02 2020 at 20:22):
And I guess for patient-entered, or whatever other reason, you could use the Data Absent Reason extension.
Last updated: Apr 12 2022 at 19:14 UTC