Stream: terminology
Topic: deprecated codes
Grahame Grieve (Dec 05 2017 at 21:04):
GF#14118 relates to the appearance of codes in FHIR expansions that are deprecated
Grahame Grieve (Dec 05 2017 at 21:06):
I believe that the issue here is that the build ExpansionProfile does not set activeOnly to true.
Grahame Grieve (Dec 05 2017 at 21:07):
I understand vocab to be saying that it should. I can't think of any reason not to do that - can any one else? @Rob Hausam @Ted Klein @Robert McClure @Brian Postlethwaite
Robert McClure (Dec 05 2017 at 22:29):
I see that @Brian Postlethwaite has a comment on the GF but simply removing deprecated codes is not a general solution, some value set expansions will want deprecated codes included. Yes, we need to implement ActiveOnly and yes, the default should be TRUE so exopansions only have active codes based on the code system version reqested (latest as defualt.) But the GF is really pointing out something different that doing all that will not solve. It is unclear to me when looking at the web page for a FHIR code system is what codes are in what version. Look at V2 0360 (http://build.fhir.org/terminologies-systems.html) and you can how bad this can be. I'd like to see a display (there is more than one solution) that makes clear what codes are in what version.
But this is really about what is returned in an expoansion and I'd also like to see that a value set expansion would include some way (I have some ideas for this too - none a re perfect) to identify if the code is depricated based on the requested code system version (only true when ActiveOnly = F). This might be best done by providing (optionally?) what code system version the code is last active in (assuming that "active" would send the version requested.)
Grahame Grieve (Dec 06 2017 at 01:38):
well, several issues there:
- the vs codes are shown when they are deprecated (see http://build.fhir.org/v2/0006/2.4/index.html)
Grahame Grieve (Dec 06 2017 at 01:38):
- I thought that in v2, deprecated = not active
Grahame Grieve (Dec 06 2017 at 01:39):
- I could enhance the build infrastructure to indicate inactive - I don't think I'm obsessively filling that out. But even if I do, that doesn't help with the task...
Rob Hausam (Dec 06 2017 at 03:52):
Yeah, there are several issues. What we said for GF#14118 is that we need to indicate the V2 code system and value set versions that are being displayed in the build and ensure that the content shown is consistent with that based on the tables project results. Representing multiple versions of the code systems and value sets is a separate but related issue. That will add complexity. It's certainly going to be needed for UTG, but may not actually be needed in the FHIR build - could representing only the latest versions suffice for that? I checked both v2.8.2 and v9, and they don't really define what "deprecated" means, but 2.9 explicitly describes statuses for "active code", "deprecated or inactive" and "retired" (as well as "backwards-compatible use only" and "new in this release"). The first three seems mostly consistent with V3, but I think that "deprecated or inactive" is misleading and confusing, as "deprecated" items (whether fields, codes or whatever) have always been considered to still be "active" (but recommended not to use) until they are actually retired (or removed, which I believe means the same). So this is kind of a mess (probably not a big surprise).
To summarize, I think my suggestion is that for the build we consider representing only the latest versions of the V2 table code sytems/value sets (2.9 for those that currently exist and the latest active version where they don't) and declare those versions explicitly, and in the expansions include both the active and deprecated codes (with the deprecated codes labeled as such), but do not include the retired (removed) codes - and that should be consistent with activeOnly = true. This interpretation of activeOnly is somewhat different from how Rob M. described it above, but I think it is consistent with longstanding HL7 understanding and practice (happy to be corrected if not, though).
Rob Hausam (Dec 06 2017 at 13:26):
The above suggestion is essentially a straw man with the intent of making it simple enough to be feasible for the current FHIR build. I'm happy to do something better if we decide what that is. However we do it, I think the version labeling probably should be the range of versions in the V2 standard where the particular version of the V2 table code system/value set applies. As I recall, that should be essentially the same way that it was done in the V2 tables project - e.g., 2.4+, 2.1-2.3.1, etc.
Grahame Grieve (Dec 06 2017 at 20:21):
so the latest source I have is 2.8. Everything is based on that. I don't think we have any inactive codes in v2.
Robert McClure (Dec 07 2017 at 13:08):
I went back and looked at more V2 code systems and indeed there is a good job for human review on the code status history. 0360 is odd and we should talk about why there seems to be two views of it.
Yes depricated means not active now but some expansions will need to include depricated codes for historical record retrieval. We may need to meet to fully define and clarify what all the statuses mean but I've always assumed there really are only two - Active: For use now; Depricated/Retired: Active in the past but not for use now or in the future. Code systems should always include Depricated/Retired codes in every release but they are not active. No one should be using them but of course, some may and some IGs could even say it's ok to use them for some period of time - I think that is hedging the process with no benefit but apparently others disagree. In any case, if we need multiple other code status, then fine. But ActiveOnly has a clear meaning to me and I hope everyone else and it's a flag that has a binary and simple use - include active only, or include everything in the CLD. Also remember you can include a specific code system version of a code (like when it was last active) by LOCKING a CLD clause to an older code system version so the expansion will contain that code tied to the older code system version.
What I'd like to see in our value set expansions is to use the latest code system version the code is active in, the default being the code system version used for the expansion "overall" (ie: for all codes not depricated in that version, or not LOCKED.) The expansion should include the code system version identifier AND the status for each code included.
When reterning, or displaying a code system, we should have current status, date added, date status was set. I understand this would not provide as much info as RF2 and for those few codes that have gone in, and out, of active status more than once, we'd loose that. But I'm not so worried about it unless others think we need full histories.
Rob Hausam (Dec 07 2017 at 16:37):
Actually, I think that the operational meaning and general understanding of 'deprecated' is "still active, but discouraged from any further use", or something very close to that - at the very least it is explicitly distinct from 'retired'. Here's the current description of our understanding as described in the v2.9 ballot ch. 2C p. 19:
d) Status is a field which notes the activity status of particular codes. Where blank, it indicates
that the code is Active. A 'D' in this column indicates that the code has been deprecated,
either in this 2.9 ballot or at some time in the past, and an 'R' in this column indicates that the
code is Retired and should not be used. In keeping with modern good vocabulary practices
codes will no longer be removed from tables and code systems, they will be marked as Retired
instead.
Note that it says "should not be used" about 'retired', but not 'deprecated'. I'm not certain that in the prior v2 versions it was always clearly understood and practiced this way, but this seems to be the latest and best understanding of it that we have.
Grahame Grieve (Dec 07 2017 at 20:20):
Rob is right about deprecated. deprecated codes are clearly active.
Grahame Grieve (Dec 07 2017 at 20:21):
as for expansions carrying status.... we have consistently declined to come up with a canonical list of status codes.... so it's not easy (or efficient) to carry status on expansions. Nor is it clear to me what kind of status information is relevant to carry on expansions
Michael Lawley (Dec 12 2017 at 04:40):
What about active/inactive in expansions? This is a clear boolean and very useful to include. Currently Ontoserver does this with an extension, but it's pretty verbose for what I would consider an 80% case
Grahame Grieve (Dec 12 2017 at 05:58):
we have a boolean flag for this
Yunwei Wang (Dec 12 2017 at 18:13):
@Michael Lawley You can use ValueSet.expansion.contains.inactive
Michael Lawley (Dec 12 2017 at 22:11):
well now, how did I miss that!
Last updated: Apr 12 2022 at 19:14 UTC
