Stream: terminology
Topic: SNOMED CT in FHIR specifications
Grahame Grieve (Oct 07 2016 at 00:49):
Does anyone disagree with this statement:
"When publishing value sets in the core FHIR specification, SNOMED CT expansions should not include inactive concepts"
with a follow up question: if a SNOMED CT value set enumerates an inactive concept, does the build tool ignore these, or throw an error?
Michael Lawley (Oct 07 2016 at 01:18):
I would argue that if inactives should be excluded, then the ValueSet definition should explicitly exclude them
Reuben Daniels (Oct 07 2016 at 01:19):
I agree with Michael regarding explicit exclusions
Grahame Grieve (Oct 07 2016 at 01:27):
why did you define the capability in ExpansionProfile then?
Reuben Daniels (Oct 07 2016 at 01:31):
Are expansion profiles in use for publishing value sets in the core FHIR spec?
Grahame Grieve (Oct 07 2016 at 01:31):
yes they are now, and I was going to use them to do what IHTSDO wants
Reuben Daniels (Oct 07 2016 at 01:35):
In that case, if it's clear which expansion profile is being used to produce the expansion for the FHIR core spec, then I don't feel as strongly about explicit exclusions in the value set definition. However, some policy or guidance may be necessary for implementers expanding the value set separate to the FHIR spec.
Robert McClure (Oct 10 2016 at 14:01):
(sorry, I've been out...) From the VSD spec:
6.2.2 ActiveOnly
Definition: include only ACTIVE Concept Representations in the Value Set Expansion Code Set
Description: This attribute flag indicates if “only active” Concept Representations should be included in the resulting Value Set Expansion Code Set when executing the CLD query. An active Code System Version concept is identified by the “activity status” which is meant to indicate if the concept may be used for data collection and recording at the time the Code System Version is the currently active Code System.Usage Notes: The default is "FALSE" which means that all concepts that match the CLD in the Code System version used to determine the Value Set Expansion Code Set will be returned. Any Code System concept attribute that represents activity status should be ignored if ActiveOnly = FALSE. If a Code System has no concept attribute that represents activity status, then all concepts should be considered to have an activity status = “ACTIVE”. It is assumed that a concept activity status of “DEPRECATED” or “RETIRED” or “INACTIVE” all represent a status that is NOT ACTIVE. This attribute is to be implemented independent of “LockedDate” such that if LockedDate is set, then this attribute defines if only active concepts or all are placed into the Value Set Expansion Code Set.
Data Type: BL Cardinality: 1..1
In VSAC the behavior is to only include ACTIVE concepts and we have a work-around to include INACTIVE concepts in an expansion. The plan is to implement the use of "ActiveOnly" as part of our expression-based CLD work. Also, when one or more specific inactive concepts are needed in the expansion, you can define a clause of the CLD to include a specific code from a specific code systyem version. Then that code is always in the expansion.
Grahame Grieve (Oct 10 2016 at 23:11):
thanks for that. you'll be glad to know that FHIR works the same way
Grahame Grieve (Oct 10 2016 at 23:12):
but I don't believe it actually answers my original question
Michael Lawley (Oct 10 2016 at 23:46):
I think it comes down to the conceptual definition of the ValueSet. If this includes inactive codes then fine, but if it doesn't, then that should be explicitly expressed as part of the ValueSet definition.
My understanding of the 'active only' capability from expansion profiles is when the client has additional requirements relating to context of use.
Michael Lawley (Oct 10 2016 at 23:48):
So, ultimately, I disagree with the statement. If the ValueSet doesn't itself exclude the inactives, then I'd like to understand an explicit justification for why the core spec should exclude them.
Grahame Grieve (Oct 10 2016 at 23:49):
cause IHTSDO asked me to do that, though I don't believe I have that written down
Grahame Grieve (Oct 10 2016 at 23:50):
given that these are almost all example value sets, I don't have a strong feeling either way
Robert McClure (Oct 12 2016 at 18:00):
@Michael Lawley The Content Logical Definition part of a value set definition defines what codes are in the expansion. ACTIVEONLY is an attribute of the CLD. I'm completely confused by your confusion about if actives are in or out - it should be explicelty stated in every CLD. Graham has said FHIR does it this way. So I suppose to use your words "the conceptual definition" of the value set expansion content will clearly say include or don't include inactives based on the code system version to be used. Given that you are referring to an expansion profile, ActiveOnly is in the wrong place?
Grahame Grieve (Oct 12 2016 at 19:32):
sounds like agreement to me, @Robert McClure and @Michael Lawley. As things stand, I have 2 choices for implementing the policy: setting active-only in all the value sets (and policing that everyone does all the time) or setting active-only in the expansion profile I use.
Grahame Grieve (Oct 12 2016 at 19:32):
if you don't think that the expansion profile should be able to say active-only, then that's something to discuss
Grahame Grieve (Oct 12 2016 at 19:33):
but I don't feel as though I'm closer to agreement about my first question: what should our policy be?
Michael Lawley (Oct 12 2016 at 21:52):
@Robert Barkovich McClure I was trying to separate intent from the expression of the intent. I'm not familiar with a formal definition of CLD, so I avoided the term.
Michael Lawley (Oct 12 2016 at 21:58):
Grahame, I'd be happy with a policy that inactives shouldn't be in the generated docs, but I would encourage an approach that involved including that constraint in the CLDs where appropriate, but also incorporating a check on all expansions during the generation phase to catch any omissions
Rob Hausam (Oct 12 2016 at 22:38):
well, right now, as has been mentioned, includeInactive in FHIR (related to but obviously not the same as ActiveOnly in VSD) is only present in the ExpansionProfile and the $expand operation
you can't say anything about the activity status directly in the CLD (ValueSet.compose) in FHIR (it's not in the base ValueSet resource or the "standard" valueset extensions) - again, that's obviously different from VSD
the default behavior of FHIR and VSAC (include only active concepts) is different from the default specified in VSD (ActiveOnly = false)
so do we need to consider aligning these more closely?
it might not be necessariy to do that as it all should be readily transformable, but more consistent behavior could helpf reduce confusion
Grahame Grieve (Oct 12 2016 at 22:42):
would be a filter in FHIR ValueSet
Rob Hausam (Oct 12 2016 at 22:57):
also, @Robert McClure's quote from VSD that "It is assumed that a concept activity status of “DEPRECATED” or “RETIRED” or “INACTIVE” all represent a status that is NOT ACTIVE" makes me realize that we probably have an issue with "deprecated"
the "deprecated" status in V3 (and the similar "discouraged" status in LOINC) is intended to represent concepts that are still considered to be "active", but are recommended not to be used (at least for new development) and, in V3, are flagged for future inactivation
this also came up in the context of the FHIR certification test on a question that I wrote - for that we were in agreement (at least at the time) that the "deprecated" codes were still considered as "active" for determining the contents of the value set expansion
but the VSD spec states it otherwise
and, whichever way we decide, we probably haven't yet stated it clearly enough in FHIR what the behavior is supposed to be
Rob Hausam (Oct 12 2016 at 23:04):
@Grahame Grieve right - we should be able to use a filter on a status property to exclude inactive concepts, although that's probably not as straightforward as you would like for it to be
but I don't see a way to do the reverse of explicitly including inactive concepts without using the includeInactive parameter (which isn't part of the CLD)
Grahame Grieve (Oct 12 2016 at 23:05):
yes, HL7 is clear that deprecated != inactive. Rob M can just align with that.
Grahame Grieve (Oct 12 2016 at 23:05):
agree that life is never as simple as we'd like it to be
Rob Hausam (Oct 12 2016 at 23:06):
agree - but we just published VSD with it the other way :-(
Grahame Grieve (Oct 12 2016 at 23:09):
other way in which regard?
Rob Hausam (Oct 12 2016 at 23:11):
in regard to VSD explicitly stating (in the quote Rob M. gave) that the assumption is that a concept activity status of “DEPRECATED” represents a status that is NOT ACTIVE
Grahame Grieve (Oct 12 2016 at 23:11):
oops. we will ignroe than and get VSD revised in the future
Rob Hausam (Oct 12 2016 at 23:12):
yes, that seems to be what we need to do
Robert McClure (Oct 13 2016 at 18:33):
Yes, we need to change VSD it seems. @Rob Hausam can you enter a STU issue for that here http://www.hl7.org/dstucomments/showdetail.cfm?dstuid=189
Rob Hausam (Oct 14 2016 at 20:42):
Done.
http://www.hl7.org/dstucomments/showdetail_comment.cfm?commentid=1109
Grahame Grieve (Oct 16 2016 at 02:37):
Discovered issue.. IHTSDO have asked me to ensure that the FHIR build process only uses codes from SNOMED international. I've just done the infrastructure work to do that, and discovered that the following valuesets from the main FHIR build use SCT-US specific content:
Grahame Grieve (Oct 16 2016 at 02:37):
consistency-type, entformula-type, supplement-type, texture-code
Grahame Grieve (Oct 16 2016 at 02:38):
all of these are on NutritionOrder. @Eric Haas @Rob Hausam I am not sure what to do about this...?
Grahame Grieve (Oct 16 2016 at 10:12):
discovered issue around includeInactive: GF#12279
Rob Hausam (Oct 16 2016 at 15:28):
@Grahame Grieve A lot of new nutrition content was added to the US extension and hasn't made it (yet) into the International Edition. If you can't use content from the US (and other) extensions, then I guess you'll have to pull these value sets. But maybe this is something that we can work out further in Wellington and come up with a satisfactory solution.
Grahame Grieve (Oct 16 2016 at 20:43):
what kind of solutions could there be?
Michael Lawley (Oct 16 2016 at 23:00):
defintely agree on renaming includeInactive to excludeInactive
Grahame Grieve (Oct 17 2016 at 04:52):
also, FYI: http://hl7-fhir.github.io/snomedct-usage.html
Eric Haas (Oct 17 2016 at 17:40):
we have to take em out. I'll let margaret know
Rob Hausam (Oct 17 2016 at 17:53):
Since the page states "Note that this page only lists those codes used by the international FHIR specification", then we do have to remove them. But we may need some further thinking and policies about when and how we can use codes from national (and potentially other) extensions. The simplest answer I'm sure is "in appropriate realm specific IGs" - and if that's adequate to meet the needs, then there's probably not an issue.
Grahame Grieve (Oct 17 2016 at 19:49):
IHTSDO have said that we can leave them in, for now at least. So no need to take them out for STU3
Grahame Grieve (Oct 17 2016 at 19:50):
where do we say that?
Rob Hausam (Oct 17 2016 at 19:52):
the second sentence in the SNOMED CT in FHIR page
http://hl7-fhir.github.io/snomedct-usage.html
Grahame Grieve (Oct 17 2016 at 19:53):
ah ok. well, we can change that.
Rob Hausam (Oct 17 2016 at 19:56):
right, we can change it
interesting that they said we can leave them in
that sounds good - presumably we need to identify when extension content is included (and/or the edition used)?
Grahame Grieve (Oct 17 2016 at 20:02):
they said we could leave them in for now, as a procedural issue.
Grahame Grieve (Oct 17 2016 at 20:03):
I didn't ask for permanent approval
Last updated: Apr 12 2022 at 19:14 UTC
