Stream: implementers
Topic: Extensible Binding
Joel Francis (Sep 04 2019 at 16:44):
According to the documentation, To be conformant, codes in this element SHALL be from the specified value set. If there is no applicable concept in value set (based on human review), an alternate concept (either system/code pair, or text) may be used instead.
So I am conforming or not to use a different system/code pair ?????
Also is it worth declaring non-conformance in the usecase documentation?
Lloyd McKenzie (Sep 04 2019 at 16:56):
If you use a different system/code pair and the code represents something that isn't expressible in the bound value set, you're fine. If it's something that code be coded using the bound value set, you MUST send the code from that value set too. It's generally not possible to to tell if the instance is valid in an automated way. A person needs to look at the code you chose and figure out whether that code corresponds to a concept that could have been expressed using the bound value set.
Lloyd McKenzie (Sep 04 2019 at 16:57):
As an example, if the value set has the codes red, green & blue, you're free to send codes for black, white or yellow (which aren't covered by the value set). However, if you want to send a code for navy blue or emerald green, you could only do so if you also sent the 'blue' or 'green' codes.
Lloyd McKenzie (Sep 04 2019 at 17:02):
In a more realistic example, if you have a binding to "all LOINC codes", you would have to send a LOINC code unless you're doing a test for which no LOINC code (at any level of granularity).
Joel Francis (Sep 04 2019 at 18:39):
@Lloyd McKenzie can I use the code green but in the display use the text light green to convey the exact meaning?
Lloyd McKenzie (Sep 04 2019 at 19:08):
You could put "light green" in CodeableConcept.text. Coding.display is expected to be one of the designations for the code as defined by the code system.
Joel Francis (Sep 04 2019 at 19:39):
You could put "light green" in CodeableConcept.text. Coding.display is expected to be one of the designations for the code as defined by the code system.
Is is worth declaring FHIR nonconformance if I do decide to send light green as the code in the example above? Are there any downsides to declaring nonconformance
Lloyd McKenzie (Sep 04 2019 at 19:58):
The whole point of using a standard is interoperating. If you're going to be non-conformant, you're not going to interoperate. Declaring non-conformance is essentially saying to the community at large "I'm a special snow-flake and you need to spend extra money/effort to enable my specialness because I don't want to spend the money/effort needed to conform on my side." Can you do it? Yes. Are you likely to get a lot of systems talking to you? No. (And those who do talk to you aren't going to be terribly happy.)
Lloyd McKenzie (Sep 04 2019 at 19:58):
Moving past the theoretical color-based example, where are you seeing an extensible binding that you don't think you can conform to?
Grahame Grieve (Sep 04 2019 at 20:46):
Is it worth declaring FHIR nonconformance
Where and how would you declare that? But also, using a different code because it's not in the base value is not non-conformant
Lloyd McKenzie (Sep 05 2019 at 01:43):
The issue here is that they're wanting to use a code whose concept falls within the value set and they don't want to send that code along with their code - and that is non-conformant
Grahame Grieve (Sep 05 2019 at 01:46):
oh. right. well, we have no way to computably declare that you don't conform to the applicable rules
Joel Francis (Sep 05 2019 at 15:02):
The Practitioner.Identitifer RRI is where we see it is not granular to distinguish between the regional type of Identifiers
Lloyd McKenzie (Sep 05 2019 at 15:31):
Are you wanting to disambiguate specific regions or just different levels of regions? For the former, it should be done using system, not type. For the latter, I'm curious as to the levels you'd like to distinguish.
Aritra Kundu (Feb 12 2021 at 11:11):
@Grahame Grieve @Lloyd McKenzie
Hi All,
I am currently working on the Interoperability implementation for the US Core Profiles (US Core 3.1.0). While performing the implementyation of US Core Medication Profile, I came across with the Medication.code element where FHIR Binding value is : US Core Medication Codes (RxNorm) (extensible). However, my client maintained the NDC medication coding standard. My question to the group is:
- Is it allowable to use NDC code with the system value as: http://hl7.org/fhir/sid/ndc ? OR
- We need to convert all the existing NDC code set to Rx Norm before sending.
For question # 1, my interpretation for any extensible binding was if a code is not present in the defined Value set (recommended by FHIR for that element), we may use other VS with proper System details. Having said that, if a client does not want to do all these conversion (as it require a good amount of effort), can they use NDC code ?
For question # 2, we have an RxNorm provided API available - https://rxnav.nlm.nih.gov/RxNormAPIs.html# ; can we suggest client to use this or create a repository (kind of a translation table) and maintain it.
Requesting your assistance on this.
Regards,
Aritra
René Spronk (Feb 12 2021 at 11:20):
Extensible binding = SHALL use RxNorm, unless the medication/concept defined by NDC doesn't have a translated-equivalent in RxNorm [or rather: the 'US Core Medication Codes' value set defined in terms of RxNorm]. Then, and only then, may a NDC code be sent as the sole concept code.
Aritra Kundu (Feb 12 2021 at 13:21):
René Spronk said:
Extensible binding = SHALL use RxNorm, unless the medication/concept defined by NDC doesn't have a translated-equivalent in RxNorm [or rather: the 'US Core Medication Codes' value set defined in terms of RxNorm]. Then, and only then, may a NDC code be sent as the sole concept code.
Thank you for the response. So you are suggesting, translate all the NDC code to it's equivalent RxNorm code and share as an US Core Medication FHIR output. If we have any Drug code that is not available (or not closely matching) in RxNorm, we may use NDC as a concept code. Please confirm.
~Aritra
Michele Mottini (Feb 12 2021 at 13:27):
Correct
And put always the original NDC code in the resulting CodeableConcept
Aritra Kundu (Feb 12 2021 at 13:38):
Michele Mottini said:
Correct
And put always the original NDC code in the resulting CodeableConcept
Ok Michele. Do we have any tool / API / service available for this kind of conversion. Because it is not limited to NDC - > RxNorm, we may have other binding changes such as ICD - Snomed, CVX code updates etc.
René Spronk (Feb 12 2021 at 13:47):
(as for translations/ an API - yours is a US specific question, so those of us not in the US will remain silent on that part of your question)
Lloyd McKenzie (Feb 12 2021 at 14:18):
@Eric Haas @Brett Marquard
Michele Mottini (Feb 12 2021 at 14:20):
Do we have any tool / API / service available for this kind of conversion.
It is what is called a terminology service. I don't know of any publicly available (we have our own)
Robert McClure (Feb 12 2021 at 18:01):
NLM provides an open access API to RxNorm that provides this service. See https://rxnav.nlm.nih.gov/RxNormAPIs.html# and in particular findRxcuiById. This has been available for years and is built upon a very complete database of NDC codes.
Daniel Venton (Feb 12 2021 at 20:49):
If anybody, at any time, has the ability to convert a NDC code to a RxNorm code, doesn't that invalidate the need for every creator/sender do the conversion so that the FHIR resource contains RxNorm?
Lloyd McKenzie (Feb 12 2021 at 21:39):
The expectation is that conversion is done once - by the data source, both because that's more efficient and because the source often has more capacity to do the translation than subsequent consumers. It also ensures that searching can be performed consistently.
Aritra Kundu (Feb 15 2021 at 07:50):
Thank you for the responses.
However, this is just one scenario where it requires to convert the codeset from NDC - > RxNorm. There are many such conversion needed if we go by the USCDI guideline - https://www.healthit.gov/isa/sites/isa/files/2021-01/Draft-USCDI-Version-2-January-2021-Final.pdf
Do we need to follow all these (For Extensible Bindings) standard code conversion while exposing the FHIR API's ? Please suggest. I am unsure if we have all the standard code conversion API's available which can be used while doing the integration.
Regards,
Aritra
René Spronk (Feb 15 2021 at 08:05):
The short answer: yes. If USCDI mandates the use of certain terminologies (i.e. US Core uses a Extensibe or Required binding), then you'll have to do the conversion.
Aritra Kundu (Feb 15 2021 at 09:35):
René Spronk said:
The short answer: yes. If USCDI mandates the use of certain terminologies (i.e. US Core uses a Extensibe or Required binding), then you'll have to do the conversion.
Ok, Thanks for the confirmation.
Regards,
Aritra
Lloyd McKenzie (Feb 15 2021 at 15:21):
More specifically, you must if you need to comply with US Core. If you're not bound by the US regulation (e.g. veterinary) or you're not implementing in the US, then US Core bindings don't apply. (Though other rules may exist.)
Lin Zhang (Mar 10 2021 at 13:57):
For CodeSystem.concept.designation.use,
when following the extensibly-bound ValueSet's note/instruction (i.e.: ... The SNOMED CT concepts included in this value set - description types for SCT terms - are for use with SNOMED-CT, and not expected to be used with other code systems.), how to express others designation uses such as "synonym", "print name" and "acronym" etc? Is this question alreafy has its answer(s)? Thanks.
Lloyd McKenzie (Mar 10 2021 at 17:18):
I'm not really understanding the question. Are you asking how to define additional designations within a value set @Lin Zhang ?
Last updated: Apr 12 2022 at 19:14 UTC
