Stream: shorthand
Topic: Defining aliases for codes?
John Silva (Sep 15 2020 at 19:07):
I've run into a need to have code values defined in the aliases.fsh file so that I can use them in different FSH files. Maybe there's a better way to do this; I'm open to ideas.
So, I have a FSH file, e.g. for LowBloodSugar.fsh, and in that file I'm defining the ValueSet of SCT codes I want to use for it and then also referencing those same SCT codes in the ConceptMap defined in this same file and also in a PlanDefinition.useContext entry. I then need to create a CodeSystem.fsh file that has these codes, as well as other SCT codes used in other <use case>/.fsh files so that the CodeSystem JSON resource file generated by SUSHI has a consistent set of code values.
I was hoping to define these codes in the aliases.fsh file and then refer to them in both the <use case>.fsh file and the CodeSystem.fsh file but it doesn't seem I can use an alias on the 'right hand side'. For example:
in aliases.fsh
Alias: SCT = http://snomed.info/sct
Alias: $LowBloodSugar = 12345. (assume this is the correct SNOMED CT code)
in LowBloodSugar.fsh
ValueSet: LowBloodSugar
Title: "LowBloodSugarVS Valueset"
- SCT#$LowBloodSugar
But when I run this through SUSHI the $LowBloodSugar string is directly copied to the output ValueSet-LowBloodSugar.json file.
Jean Duteau (Sep 15 2020 at 19:50):
Aliases currently can only be used to define URLs. To do what you want, you need the Macro capability that is in a future version of FSH.
Chris Moesel (Sep 15 2020 at 20:01):
@Jean Duteau is correct, Alias: is defined to only work as an alias for URL values. So you're looking for a way to reference a code by a friendlier handle than just using the code itself? For example, you don't want to say SCT#12345 in multiple places -- you'd rather say SCT#$LowBloodSugar because it's easier to remember and more descriptive? Is that the idea? (Like Jean said, it's not possible now, but I want to be sure we understand the use case so we can consider for future versions).
I don't think I quite followed the bit about CodeSystem though -- as CodeSystem is usually used to define codes from code systems not yet represented in FHIR. SNOMED already have a CodeSystem representation in FHIR, so I don't fully understand how/why you would be defining a new CodeSystem with SNOMED codes... But I expect I'm misunderstanding someting.
John Silva (Sep 15 2020 at 20:10):
@Chris Moesel - yes, the use case is because these codes need to be used in multiple places and without aliases (especially a $ alias which seems to have better error reporting) the code can be mistyped in different places and not noticed. For example, in our <use case>.fsh file we define ValueSet's ConceptMap's, PlanDefinition's, etc. and there are references to the SCT code in at least 3 places already that have to be kept consistent.
(the thing about the CodeSystem.fsh is because we're trying to work around what appears to be a bug in HAPI with code:in searches so we're trying to define a subset of the code system we're using to see if we can get around this problem. I've asked about this in the hapi channel but haven't seen any responses yet.)
Chris Moesel (Sep 15 2020 at 20:21):
Thanks for the context @John Silva. Wanting to avoid unintentional mistakes and mismatches certainly makes sense.
RuleSets allow you to repeat whole rules, but since you want to use this code in different contexts, I don't think RuleSets (or even the upcoming "parameterized" RuleSets) would help you. That's unfortunate.
So you probably really do want something very much like the alias. We restrict aliases to URLs to help ensure maintainability and implementability. Knowing aliases are only valid where URLs can be accepted helps reduce scope and enhance error checking. I don't think we'd want to expand alias to allow arbitrary substitution of any value, but we could probably consider if it might make sense to allow it to hold a code value. I'll add this to our issue tracker so we don't lose sight of it.
Chris Moesel (Sep 15 2020 at 20:25):
Last updated: Apr 12 2022 at 19:14 UTC
