Stream: terminology
Topic: Inactive codes
Grahame Grieve (Nov 11 2016 at 03:56):
@Robert McClure @Rob Hausam I have to write up how to determine inactive codes for the following US code systems:
- RxNorm
- NCI Metatheasuarus
- CPT
- NDFRT
- NDC
- UNII
- CVX
Rob Hausam (Nov 11 2016 at 15:17):
Yes. Some of them will be a bit interesting. The NDC Directory from FDA doesn't include everything (like older pre-SPL products). FDB and Multum expend considerable resources trying to compile NDC codes for their respective databases, and it isn't perfect (although gradually getting better). I expect that we'll need to do comparisons between release files to determine which codes have been made inactive in some cases (like CPT?), as that may not be part of the publication.
Grahame Grieve (Nov 11 2016 at 20:29):
are you saying that inactive codes are not in the release files? then that's all we need to say
Rob Hausam (Nov 15 2016 at 04:39):
yes - that's true for some of them
and I guess you're right - we don't really have to do anything with it beyond that
Grahame Grieve (Nov 15 2016 at 07:03):
so to which of them does that apply?
Lloyd McKenzie (Sep 12 2017 at 14:25):
Why does valueset expansion contain the notion of "inactive" when CodeSystem.concept does not? And why is expansion.contains.inactive not marked as a modifier?
Grahame Grieve (Sep 12 2017 at 15:25):
Legacy on the first. We need to talk about this
Rob Hausam (Sep 12 2017 at 21:32):
Yes, we should talk about this. Declaring that a concept is "inactive" means that (at least theoretically) you can't use it for new data instances, but it doesn't modify the meaning that it originally had (to whatever degree of clarity that was specified).
Lloyd McKenzie (Sep 12 2017 at 22:59):
So if systems throw away the "inactive" element, that doesn't change the meaning of the codes inclusion in the value set? @Grahame Grieve do you want a change request or should we have more discussion here first?
Grahame Grieve (Sep 12 2017 at 23:09):
it's still in the value set. It still means the same thing. 'inactive' is an instruction about it's use. I lean to it not being a modifier
Peter Jordan (Sep 12 2017 at 23:17):
Just a couple of uses cases to consider: firstly the relevant concept has been used in an endpoint system, secondly a user expects to see a concept in a dropdown list, because they've selected it before, but it no longer appears because it's now inactive. In NZ we're beginning to discuss these issues with those planning to implement SNOMED CT and, in primary care, it's never been a concern with the Read Code system that's being replaced. Thus far, it's proving easier to use the term 'deprecated' than inactive. It's very hard to sell the idea that a concept that's in an EHR is inactive.
Lloyd McKenzie (Sep 12 2017 at 23:30):
I presume if inactive codes are included in the expansion (based on the ExpansionProfile) that means they should not be treated as errors when validating - correct?
Lloyd McKenzie (Sep 12 2017 at 23:32):
Should we add "inactive" to CodeSystem.concept?
Grahame Grieve (Sep 12 2017 at 23:33):
depends on context of validation
Grahame Grieve (Sep 12 2017 at 23:34):
we chose not to add inactive because CodeSystem has properties
Peter Jordan (Sep 12 2017 at 23:35):
The spec allows inactive codes to be included , or excluded, when requesting value set expansions whether or not an Expansion Profile is used. In terms of the Code System resource, it's a property of the code that can be requested via the lookup operation.
Lloyd McKenzie (Sep 13 2017 at 04:06):
It has properties, but how do you know which property means "inactive"? How does a tool take an arbitrary code system and generate an expansion from it if it doesn't know what property means "inactive"?
Lloyd McKenzie (Sep 13 2017 at 04:07):
Are we expecting a "magic" property name? (And if so, where is that documented)
Peter Jordan (Sep 13 2017 at 04:31):
For SNOMED CT http://hl7.org/fhir/snomedct.html . No magic, but it is specific to individual code systems as not all of them permit deactivation/deprecation of codes.
Lloyd McKenzie (Sep 13 2017 at 14:44):
A code system that doesn't support it wouldn't value the property, but it seems like something that should have a standard computable way to express for those that do.
Grahame Grieve (Sep 13 2017 at 16:59):
they are all different in this regard
Lloyd McKenzie (Sep 13 2017 at 18:02):
They're all different in that there's no way they could populate an active/inactive boolean (regardless of what properties they have)?
Grahame Grieve (Sep 13 2017 at 18:13):
don't know. @Ted Klein opinions?
Rob Hausam (Sep 14 2017 at 04:12):
I think you can make a binary determination of whether a code is active or inactive in any code system that I know of (or can conceive of), even if the native code system propertyies don't use those terms
but there frequently are additional statuses, like deprecated (which would be a subtype of active)
Jenni Syed (Sep 14 2017 at 04:29):
the initial reaction earlier offline was that the existing system url remains and means the same thing, since they're not changing existing codes (they will eventually add more)
Jenni Syed (Sep 14 2017 at 04:29):
ie: from what I understand ndf-rt/1 == med-rt/1
Jenni Syed (Sep 14 2017 at 04:30):
and med-rt will be a superset of ndf-rt
Rob Hausam (Sep 14 2017 at 08:18):
I'm not sure if med-rt is truly a superset, but it could be. I think I need to see it first to know for sure how they're doing it.
Ewout Kramer (Sep 14 2017 at 18:56):
I'd like to add that I had trouble handling "inactive" when I was trying to implement a light-weight terminology service in the .NET API. Not being thoroughly versed in the domain, it's certainly possible that the confusion originates from a lack of knowledge on my side, but I did put my questions down in GF#13208 and GF#13220. Maybe the resolutions to these items may help others like me to get their heads around this.
Rob Hausam (Sep 14 2017 at 19:01):
Thanks, Ewout. We can try to prioritize these trackers for discussion and resolution on an upcoming Vocab call (and can invite you to join when they are on the agenda). We do need to make this clearer and move toward more consistent usage.
Grahame Grieve (Aug 10 2018 at 01:09):
I'm looking at GF#13208 which says that we should be specific about how inactive is done in HL7 code systems...
Grahame Grieve (Aug 10 2018 at 01:10):
well, ok, we should. But currently, it is done by setting the property http://hl7.org/fhir/concept-properties#inactive to true. But why? Why not use
http://hl7.org/fhir/concept-properties#status = retired
Grahame Grieve (Aug 10 2018 at 01:11):
as is apparently documented at build.fhir.org/codesystem.html#status
Grahame Grieve (Aug 10 2018 at 01:15):
actually.. this is a UTG question, really. @Russ Hamm @Ted Klein - UTG should use the status property... yes?
Rob Hausam (Aug 10 2018 at 01:52):
HL7 V3 doesn't use "inactive" as a value for status. I agree that "status = retired" is the correct way to do it. V2 (as of 2.9 uses "deprecated or inactive" and "retired", as well as "backwards-compatible use only". Using the status property consistently makes sense.
Ted Klein (Aug 10 2018 at 01:53):
Oh good grief, I thought that WAS how it was being done - a property "status" with the primary values Active and Retired. We also have used this in the past for Deprecated, and Backwards (for the v2 notion of backwards compatibility only). That having been said, I don't know how we currently deal with different codes for the same concept, where one code is Retired and the other is Active. This is not a concept status, it is a code status.
Grahame Grieve (Aug 10 2018 at 02:02):
we don't have that variation anywhere in the FHIR eco-system as far as I know, and the status codes are for the concept. I will update the code to do this consistently.
Rob Hausam (Aug 10 2018 at 02:14):
The case of multiple codes (usually two) for a V3 concept came up before, where in FHIR only one of them was being displayed. I'm not sure what we ended up doing with that. Usually only one of the codes is active, so it's probably not much (if any) of a problem, but I know that at least in the past there were one or more (but very few) instances where more than one code was active for the same concept - and in those cases dropping the "extra" ones doesn't seem to be good.
Grahame Grieve (Aug 10 2018 at 03:46):
ok sorted. all consistent now
Grahame Grieve (Aug 10 2018 at 03:46):
@Russ Hamm it's likely I copied the same confusion into the UTG code, so please check that we're using status consistently
Last updated: Apr 12 2022 at 19:14 UTC
