Stream: terminology
Topic: NDC 11 Codes
Joseph Athman (Oct 29 2018 at 16:10):
Has there been any more work done on what the correct handling of an NDC 11 value is supposed to be in FHIR? Should we place the NDC 11 value within a unique value set? It feels wrong for my company to create a unique value set for such a commonly used set of values, but the FHIR NDC value set is very clear it is for NDC 10 values only: http://hl7.org/fhir/ndc.html.
Lloyd McKenzie (Oct 29 2018 at 16:16):
@Melva Peters ?
Joseph Athman (Oct 31 2018 at 23:18):
Anyone else have insight in to what we should be doing here?
Grahame Grieve (Nov 01 2018 at 00:59):
@Rob Hausam ?
Rob Hausam (Nov 01 2018 at 01:24):
This is an interesting issue which has come up and been discussed several times, but without actually reaching a firm conclusion (as I recall). The issue, of course, is that the official published NDC codes are 10 digit (with dashes in 3 different arrangements), but what most (or probably all) drug database vendors and many others use for practical reasons is the unofficial normalized 11-digit format (without dashes). The documentation for RxNorm here in 6.0 Normalizing NDC codes in RxNorm describes this. I think it also may help provide the solution, as I believe we can potentially use the non-proprietary RxNorm distribution of "normalized NDC codes" as the source for a FHIR "11 digit NDC" code system (if it's considered separate from RxNorm proper) and value set. We would need to figure out how this is published and made accessible. That's my take on it at this point.
Robert McClure (Nov 01 2018 at 15:05):
I agree with @Rob Hausam that the RxNorm normalization NDC is the best openly available source for US NDC codes. NLM has stated they feel this is true. If we decide this is true (I suspect this would be something vocab + US Realm needs to jointly decide), then we need to figure out how we use it. If we can be very clear regarding what we exactly want distributed, perhaps we could get NLM to host this for us within VSAC as a value set. I understand it is a code system so perhaps we could also get this into UMLS but I suspect not, since they - correctly - see this as addition information provided with RxNorm (so it's already there. So if we can get it in as a value set in VSAC perhaps we could then use that to host it inside UTG as the code system?
Rob Hausam (Nov 01 2018 at 15:11):
I agree that it would be ideal for VSAC to provide and host a value set for this (once we’ve worked out the code system details).
Grahame Grieve (Nov 01 2018 at 18:07):
so what should the code system URI be?
Robert McClure (Nov 02 2018 at 20:22):
@Grahame Grieve, always with the hard questions... In the past, when we've run into this sort of situation we occasionally decide this is an HL7 code system because we are taking data obtained elsewhere and crafting our specific view of it. Then we are responsible for keeping it up to date. I don't think NLM will publish it as a code system, it's linked content to rxnorm. But perhaps we can get them (me) to publish it as a value set, and then we use the value set to update our republishing of the content as a code system. I'm sure others - @Ted Klein - will have an opinion.
Rob Hausam (Nov 02 2018 at 20:33):
I was going to check to see if the way that RxNorm publishes it it could be considered as part of the RxNorm code system itself (http://www.nlm.nih.gov/research/umls/rxnorm) and then we can create a value set for the 11-digit NDC codes from that. I didn't get a chance to check that out yet. But I think they would be publishing these as coded attributes (mappings) of the RxNorm codes rather than as separately identifiable codes themselves, so there's a good chance that it won't be quite that easy. But I think that's pretty much what Rob M. is also suggesting, and maybe that can work.
Ted Klein (Nov 02 2018 at 21:08):
I always argue against reimplementing external content as our own internal code system, as this obligates us to take on the burden of maintenance and currency. Right now the entire reason for having 'stubs' for external code systems that we have some enumerated (e.g. SNODENT subset) in HL7 is to help alleviate that burden - but this does not make the burden go away. The external sources occasionally update the content, and we have not funding or good processes in HL7 to stay on top of this. Sequestering such material at least provides the information so we can periodically check to see if it is still current and OK Therefore I would suggest that we have such an external 'stub' for the external code system, and import the codes that are needed, much as we have done in the case of the Dental content in V3. This may require some MOU to make happen, not sure.
Grahame Grieve (Nov 02 2018 at 21:15):
so what HL7 needs to do is to define the URL for NDC 11 letter codes. We can also choose to publish the actual code system, but I don't see that as at all necessary in the short term. So let's just decide on the URL please.
Grahame Grieve (Nov 02 2018 at 21:16):
I don't think the RxNorm URL is appropriate, because we say CUI of type SAB, and I don't think we should change that
Grahame Grieve (Nov 02 2018 at 21:17):
note that if we do decide to publish an actual code system for implementer convenience, we can choose to do so via the package fhir.tx.support, which I am maintaining though FHIR foundation as a way to publish code systems we don't maintain but which the terminology servers need to support for various reasons
Rob Hausam (Nov 02 2018 at 21:28):
It would probably be best if we could get a url for this from NLM. But if we can't have that, then maybe an HL7 url like http://hl7.org/fhir/sid/us-ndc-11.
Rob Hausam (Nov 02 2018 at 21:29):
I thought about a terminology.hl7.org url, but I'm not sure if we are intending to use those for external code systems this way (guessing not).
Ted Klein (Nov 02 2018 at 21:33):
Hmmm...so a good question here. In most cases, we do not want to make a URL at terminology.hl7.org for external code systems except where the external organization is one of those that cannot figure out how to spell URL, LOL. That having been said, if we are creating a URL in hl7;org/fhir, then I would think that it would be better to put it at terminology.hl7.org instead...all this having been said, I still want to get the package/IGpublish stuff working to generate the browsable content at terminology.hl7.org this month if possible, certainly no later than next month...
Rob Hausam (Nov 02 2018 at 21:44):
Have we set up any kind of separate space for external code systems in terminology.hl7.org? I'm not thinking that I've heard of anything, but I wonder if we want to do something different than terminology.hl7.org/CodeSystem if it's external? This is just a thought, but maybe something like http://terminology.hl7.org/CodeSystem/ext/us-ndc-11?
Ted Klein (Nov 02 2018 at 22:29):
That is yet to be discussed. There is a separate Git folder for maintenance (but all the product families have their own there as well). WE have a few choices, the first and most obvious that comes to mind is http://terminology.hl7.org/external/CodeSystem etc, but there may be better options. Thoughts?
Grahame Grieve (Nov 02 2018 at 22:30):
if we give it a URL in terminology.hl7.org, then we have to create a code system resource, though it can have content = not-present
Rob Hausam (Nov 02 2018 at 22:32):
I'm fine with that url variation, too. A content not-present code system makes sense and shouldn't be a problem.
Ted Klein (Nov 02 2018 at 23:16):
That is exactly what I'm thinking Grahame...we will have quite a few code system resources in UTG for all of the external code systems in V3 that must be generated into the coremif that have no content in v3...these things are what I am talking about when I refer to 'stubs'...
Ted Klein (Nov 02 2018 at 23:18):
Right now we have two different options: 1) all code systems go into terminology.hl7.org/CodeSystem, and the ones that are NOT maintained by HL7 (whether or not they have content, most do not) are listed in the List manifest as external in the "external" area (not sure how to render this yet tho...). 2) we have a separate path for these as terminology.hl7.org/external/CodeSystem (or something like that)
Ted Klein (Nov 02 2018 at 23:18):
I am ambivalent about which of these two ways to go, and open to other suggestions as well
Grahame Grieve (Nov 03 2018 at 19:31):
Should not have a seperate path on the end point
Robert McClure (Nov 04 2018 at 05:37):
I learned the Olivier Bodenreider today that the 11digit format generates some non-unique codes and so there may be some issues. We'll need to do some investigating.
Rob Hausam (Nov 04 2018 at 06:00):
I'd like to hear where Olivier believes this will be non-unique. From my understanding of the algorithm for transforming to 11 digits I don't believe that would be the case (unless the officially published NDC codes may also in some cases be non-unique, which I suppose is possible). I definitely am interested in hearing the details from Olivier and would like to see any examples where this is an issue.
Grahame Grieve (Nov 06 2018 at 06:01):
whatever, this doesn't mean it's not a code system?
Rob Hausam (Nov 06 2018 at 06:14):
Agree. But of course we do have the rule that "Within a code system definition, all the codes SHALL be unique". So if the algorithm to convert to the 11 digit codes (by padding the three segments with zeros to their full length) does have an issue with non-uniqueness, then we'll have to determine how to address that.
Grahame Grieve (Nov 06 2018 at 06:20):
well, we know of some that a non-conformant
Grahame Grieve (Nov 06 2018 at 06:21):
anyway, it seems like the URL is going to be http://terminology.hl7.org/CodeSystem/ndc-11
Joseph Athman (Nov 07 2018 at 03:20):
I really appreciate all of the discussion here and driving towards a solution. I think this will really help interoperability.
Frank McKinney (Oct 18 2019 at 15:50):
Hi Joe, Rob, all. I'm working on a prescription-related implementation guide for use in the US (CARIN Alliance's consumer realtime pharmacy benefit check - RTPBC), and also need to specify use of normalized NDC11s. We're working with the Pharmacy and Finl Mgmt WGs, and Melva pointed me to this thread.
I spent a few minutes on the FHIR / terminology pages looking to see if a code system URL has been established as discussed here, but didn't find anything. I could definitely just be missing it...
This is something we'll definitely need, so I'm happy to do anything I can to be of help
Rob Hausam (Oct 21 2019 at 22:24):
It's been quite a while, but appreciate you re-engaging on this, @Frank McKinney, as we obviously dropped the ball on this collectively and we do need to arrive at a solution. In FHIR R4, which was released shortly after our previous discussion, we now have code system supplements. But, according to our rules a supplement can't define any new codes, so that won't work for what we are wanting to do here. It seems that under the present (normative) rules we must create a new url and code system (that is not a supplement) if we want to use these codes in Coding.code (which we do). So then I think we're still at the question of who will own and manage this new code system for use of these codes in FHIR. Is Grahame's suggestion above of http://terminology.hl7.org/CodeSystem/ndc-11 still the best candidate (I'm assuming likely so)? That, of course means that HL7 will be the owner. Terminology servers that already support RxNorm should be able to relatively easily support this new code system as well, with the content being obtained from the regular RxNorm distribution. @Grahame Grieve @Ted Klein @Robert McClure @Joseph Athman
Frank McKinney (Oct 23 2019 at 17:10):
Melva suggested I create a tracker item for this, which I did here...
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=25045
@Rob Hausam @Grahame Grieve @Robert McClure @Joseph Athman @Melva Peters @Ted Klein
Rob Hausam (Oct 27 2019 at 22:02):
Thanks, @Frank McKinney. It's on the to-do list.
Frank McKinney (Nov 22 2019 at 16:30):
Hi @Rob Hausam . Quick question: An imp guide that I'm writing is on track to ballot in January and needs to include NDC11s.
Until this URL is in place, what would be the right way to reference it in my IG? I want to do it in a way that indicates we'll be using the new URL but won't cause publishing issues due to it's not existing yet.
And this is probably a dumb question, but I want to be clear in my understanding... Will HL7 create just the code system url (http://terminology.hl7.org/CodeSystem/ndc-11), and then I'll need to define a ValueSet in my profile that refers to it... which I'll then bind to in my MedicationRequest profile?
Thanks for your help!
Rob Hausam (May 27 2020 at 12:19):
This question has come up again and we do need to get it resolved. The tracker was looked at again on Jan. 23 and flagged at that time for review by HTA, but I haven't heard anything subsequently. So the main question now is, I think, can we go ahead and create and publish this as a code system using http://terminology.hl7.org/CodeSystem/ndc-11 as the system url? Or is there an alternative plan? @Julie James @Carol Macumber @Reuben Daniels @Ted Klein @Robert McClure @Grahame Grieve @Frank McKinney (I've likely left out some others who could or should be tagged, but this should be a good start)
Ted Klein (May 27 2020 at 12:53):
Strongly suggest we get this on the agenda for today's HTA call.
Rob Hausam (Jun 25 2021 at 15:34):
I'm resurrecting this old thread to to inform everyone that there has been further progress on this. We came up with a different solution to support the NDC 10 and 11 digit codes using a new code-type property. Grahame has completed the additional implmentation for that on tx.fhir.org. Here's an example: http://tx.fhir.org/r4/CodeSystem/$lookup?system=http://hl7.org/fhir/sid/ndc&code=00409371801. You should now be able to create value sets that contain only 11-digit or 10-digit codes, using the code-type property. The NDC content on tx.fhir.org is currently out of date, but I'm hoping to update that today.
Last updated: Apr 12 2022 at 19:14 UTC
