FHIR valueset Page

Welcome to "ValueSet" discussion page. Please put any comments about this page here. Contents will be reviewed periodically.

NICTIZ, ART DECOR input

Suggested changes to FHIR resources

• ValueSet.description -> looking for a way to make this multi-language (example: epSOS valuesets). Shouldn't need multiple instances of a valueset (with the same codes) just to be multi-language.
  • GG: well, wouldn't that apply to name as well? Is there a real use case for this? How many value sets will get multiple descriptions? (agree not to have multiple instances - would be an extension)
  • LM: Translations isn't in the 80%. Hard to argue that the majority of software applications support this. However, I expect we'll have a standard extension on the "string" data type that allows identification of both the language of the base (primary) string and a bunch of translations to other languages.

• ValueSet.identifier -> how does this relate to the URL identifier for a ValueSet? E.g. When we use http://hl7.org/fhir/valuesets/body-site, is the identifier "body-site" by convention? If companies having valueset repositories merge, what happens to the references? Are we always using the identifier (no problem) or the actual URL reference (might change and then result in duplicates/clashes).
  • GG: I think that the identifier is the thing that is stable and the target of a reference from a coded value. The literal URL is too unstable (i.e. when repositories merge!). I will document this better if there's agreement
  • LM: identifier needs to be globally unique, so "body-site" wouldn't fly. Not sure I buy the argument that the URL is too unstable though. We use it for other identifiers.

• ValueSet.version -> should be a timestamp, why not make it "instant"
  • GG: huh? how can it be an instant? All the snomed value sets have granularity of day, I don't think we can force it past that
  • LM: HL7 convention is date. That's the 80%. There are rare cases where value sets change multiple times a day. If you absolutely must do that, use a must-understand extension.

• ValueSet.date -> rename to functional name like "statusChanged"
  • GG: well, really? how any other ways could you read date?
  • LM: Naming rules are "go short unless you need to go longer to avoid confusion". So we'd need to know what the expected confusion here is.

• ValueSet.expansion.contains also needs an "abstract" element.
  • GG: well, the notion is that it's abstract if there's no code. Code system used to be like that, but ended up needing code for abstract concepts (v3, yay). Does an expansion have a use case for this?
  • LM: I agree with the "omit the code in expansion for value set". However, should probably add explanation of this.

• ValueSet.expansion.contains why is system not 1..1 (compose & define have system 1..1)? Is that for "just" returning display, not code/codesystem? Should there then not be a rule that IF a code is given, the system is 1..1
  • GG: yes, if there's no code, there might just be a label for a category that has no formal meaning. So no system too. Agree that there should be an invariant about this
  • LM: Where would such a label come from? Expansion is algorithmic. There should be no human-generated content added.

• ValueSet.Compose.Include is used for both inclusion and exclusion criteria. Would "Selection", "Codes", "CodedConcepts" or "ConceptCollection" be a better name?
  • GG: how about "Rules"?
  • LM: "Content"?
  • actually, it's "conceptSet" - just the diagram isn't picking this up. I'll correct it

• Suggestion to add elements for CTS2 "official release date" and "expiration date".
  • GG: well, what are their definitions?
  • LM: And is that in the 80% that most systems track and care about?

• Were IHE SVS1, SVS2 and DECOR valuesets (extension of SVS1) considered, instead of introducing a new ValueSet resource?
  • GG: references? but no, they weren't considered, we didn't know about them
  • LM: Given the need to be consistent across all resources, couldn't have used them anyhow. However mapping between them makes sense.

• Suggestion to rename valueset status "testing" to "experimental", because "testing" can cause confusion with IHE's "DSTU" testing phase.
  • GG - seems reasonable

ValueSet ART DECOR/FHIR comparison

• status codes:
  • cancelled (=withdrawn)
  • deprecated (=superseded)
  • draft (=draft)
  • final (=production)
  • new ("to become draft, do not look at yet, alpha version")
  • rejected (=withdrawn)
  • Not in DECOR: testing
  • Not in DECOR: review
    • GG: is the difference between new and draft useful?

• dates
  • effectiveDate (more or less the creation date, may be changed but is used to reference this version, maps to "version" in FHIR)
  • officialReleaseDate (not currently used)
  • expirationDate (not currently used)
  • Generally speaking: FHIR traces last status change, so e.g. after going "superseded", the date of publication is lost. There's one "date".
    • GG: yes, this is a good point. Suggestions?

• ValueSet composition
  • Inclusion/exclusion by means of "all", "descendant", "system", "children", not supported by DECOR for lack of usecases.
    • GG: we use "system". The use case is pretty straightforward. I'm not sure about the difference between "all", "descendent" and particularly "children", but we need at least one of all and descendent - all codes subsumed by another code is definitely a use case.
  • Generally speaking: not enough to cover CTS2, but too much for the FHIR practical principles.
  • Only usecase is valueset composition: set of coded concepts from one or more codesystems, existing valueset + new coded concepts, existing valueset + nullflavors
    • GG: ? - don't understand the last two

Suggested changes to FHIR Profile resources

• ValueSet and Resource metadata (status, notably) is modelled differently, why?
  • GG: They are supposed to be the same - will review
• Constraints on elements are expressed using ocl/xpath, but for common constraints (like unit, currency, min/max value etc) this is more complex than necessary, so here, to adhere to FHIR principles, the simple cases should become simple, so introduce specific constraints for: unit, currency, minInclude, maxInclude, fractionDigits, minLength, maxLength, value (see ART DECOR element/property).
  • GG: We didn't really intend for them to be done by xpath, but not more stuff to go in profile.... are all these really required?
  • LM: Well, xpath needs to be supported. So it's really a data entry/display question. For validation, it'll all have to get turned into xpath. Having these other things exposed as explicit elements is really a question of the 80%. Do most systems that capture profiles/templates/etc. capture these rules discretely? If so, that's a case for them to be discrete in Profile.

Profile ART DECOR/FHIR comparison

• DECOR always inlines the binding in the element definitions, why is this a separate structure in Profile for FHIR?
  • GG: well, we expected to be reusing bindings - and we do current re-use about 10% of them