Stream: shorthand
Topic: Instance generation
David Hay (Jan 07 2020 at 18:12):
Do aliases work in instance generation? Adding an Alias seems to produce an empty resource (resourceType only)
Instance: drDoolittleGP InstanceOf: Practitioner Alias: extQualStatus = http://hl7.org.nz/fhir/StructureDefinition/practitioner-qualification-status * extension[0].url = "http://hl7.org.nz/fhir/StructureDefinition/nzethnicity" * extension[0].valueCodeableConcept.coding[0].system = "https://standards.digital.health.nz/codesystem/ethnic-group-level-4" * extension[0].valueCodeableConcept.coding[0].code = #32114 * extension[0].valueCodeableConcept.text = "Manihiki Islander"
Nick Freiter (Jan 07 2020 at 18:32):
In general, SUSHI will expect the rules about an instance to immediately follow the declaration of the instance. In this example the Instance drDoolittleGP is declared, but then instead of getting a list of rules like it expects, SUSHI gets the Alias, so it doesn't associate those rules with the Instance you are declaring. I think if you try like this:
Alias: extQualStatus = http://hl7.org.nz/fhir/StructureDefinition/practitioner-qualification-status Instance: drDoolittleGP InstanceOf: Practitioner * extension[0].url = "http://hl7.org.nz/fhir/StructureDefinition/nzethnicity" * extension[0].valueCodeableConcept.coding[0].system = "https://standards.digital.health.nz/codesystem/ethnic-group-level-4" * extension[0].valueCodeableConcept.coding[0].code = #32114 * extension[0].valueCodeableConcept.text = "Manihiki Islander"
You should get the resource being generated correctly, and that Alias is still defined and can be used within the definition of the Instance.
Chris Moesel (Jan 07 2020 at 19:01):
@David Hay -- did SUSHI report any errors when you put the alias between the Instance metadata and the Instance rules. I think @Nick Freiter was correct in his analysis, but I would have expected SUSHI to spit out an error about those rules.
David Hay (Jan 07 2020 at 19:07):
No error when around the wrong way - but it did work ok when I re-ordered it - thanks!
And for my next question :)
This line:
* extension[0].valueCodeableConcept = systemEthnicity#32114 "Manihiki Islander"
results in
{
"url": "http://hl7.org.nz/fhir/StructureDefinition/nzethnicity",
"valueCodeableConcept": {
"coding": [
{
"code": "32114",
"system": "https://standards.digital.health.nz/codesystem/ethnic-group-level-4"
}
]
}
}
Shouldn't the text element be present? And is it possible to emit the code display using the shorthand?
Chris Moesel (Jan 07 2020 at 20:35):
Yes, it should put in the text. That looks like a bug. It's probably because we share some some of the code between setting codes in instances and fixing codes in profiles -- and in profiles we purposefully omit the text because usually you wouldn't want a fixed code to _require_ specific text/display.
Chris Moesel (Jan 07 2020 at 20:36):
One question we have to answer though, is when you set a CodeableConcept as you did above, would you expect that text to be reflected in the CodeableConcept.text, in the CodeableConcept.coding.display, or both?
David Hay (Jan 07 2020 at 20:37):
Actually, display makes more sense I guess. Better to set the text explicitly...
Jose Costa Teixeira (Jan 07 2020 at 21:13):
Where is the syntax for instances creation?
David Hay (Jan 07 2020 at 21:18):
I just copied what I was using for profiles - just used the InstanceOf keyword... There is more info apparently, but the IG is currently down...
Chris Moesel (Jan 07 2020 at 21:21):
There is some documentation on the wiki: https://github.com/HL7/fhir-shorthand/wiki/3.7-Instances
Note that referring to slices by name (in instances) does not currently work and referring to extensions still requires the extension. prefix (as opposed to the shorter syntax in some of the wiki examples).
Jose Costa Teixeira (Jan 07 2020 at 21:22):
ok i just had one question. Array index- are they necessary?
Chris Moesel (Jan 07 2020 at 21:22):
If you leave out the index then it assumes index [0].
Jose Costa Teixeira (Jan 07 2020 at 21:23):
i mean for the others as well
Chris Moesel (Jan 07 2020 at 21:23):
Yeah, if you want to do anything other than the first one, then you need the indexes. Are you suggesting that if we see a path repeated we could just assume to increment the index?
Jose Costa Teixeira (Jan 07 2020 at 21:25):
name: - family: Costa given: Jose - family: Sanches given: Jose
Chris Moesel (Jan 07 2020 at 21:26):
That would be interesting, but we could run into trouble when you have two array elements in the same path. For example, what would we do with this?
* name.given = "Steven" * name.given = "Brian"
How do we know if the second one should be name[0].given[1] or name[1].given[0]?
Jose Costa Teixeira (Jan 07 2020 at 21:27):
not that syntax, look at my syntax above
Jose Costa Teixeira (Jan 07 2020 at 21:28):
(I understand you may already have some syntax pattern, apologies if I am rocking the boat, but whenever possible, YAML should allows simple syntax, right?)
Chris Moesel (Jan 07 2020 at 21:28):
Oh, I see... I missed your follow-up when I was writing that... People have suggested something like a YAML syntax before. There were mixed opinions. We played with it a little early on and it felt like it didn't add a lot of value over JSON. But I think we could revisit it at some point.
Chris Moesel (Jan 07 2020 at 21:29):
It's certainly a lot less typing!
Jose Costa Teixeira (Jan 07 2020 at 21:33):
just take it as input. I think things like [indexes] make it less short-handy.
Jose Costa Teixeira (Jan 20 2020 at 15:36):
Instance: PatientPia InstanceOf: Patient Id: pia Title: "Patient Pia" * name[0].family = "AnyWoman" * name[0].given[0] = "Pia"
This generates an empty patient resource, no names. Am I missing something obvious?
David Hay (Jan 20 2020 at 17:24):
If you remove the Id: it seems to work...
Chris Moesel (Jan 21 2020 at 14:08):
Instances don't support the Id metadata field. So I think that's choking up the parser. We have a separate bug to figure out why sometimes the parser fails silently.
Since this is an instance, and id is a field on Patient, you can accomplish what you want via a normal instance setter:
* id = "pia"
I think we didn't support a separate Id: metadata field because we thought that whatever you put after Instance: could be / would be used as the id -- since instances don't really have anywhere to put a name (so we'd re-use it as id). That said, it looks like we don't actually do that (export the name as the id)... So, this seems like a good thing to discuss:
- Should we support a separate
Id:field? - If so, what does the _name_ after
Instance:signify? Just a handle for referencing it from other FSH instances? - Or should we treat the name (after
Instance:) as the id and leave it at that?
David Hay (Jan 21 2020 at 17:42):
Interestingly, this extension definition does have Id: and seems to work fine (the SD has both a name and an id field, both populated with 'hpiLocation-established'. Is there a list of 'FSH metadata' and what they do in the spec? (I couldn't find it)
Extension: hpiLocation-established Id: hpiLocation-established Description: "The period over which the location is open" //These files were generated by a script * extension 0..0 * value[x] only Period
Jose Costa Teixeira (Jan 21 2020 at 21:31):
Oh, I see... I missed your follow-up when I was writing that... People have suggested something like a YAML syntax before. There were mixed opinions. We played with it a little early on and it felt like it didn't add a lot of value over JSON. But I think we could revisit it at some point.
on this: not sure if relevant but besides less typing, it is easier on the eyes and easier on diff's for example
Chris Moesel (Jan 21 2020 at 22:12):
Interestingly, this extension definition does have Id: and seems to work fine (the SD has both a name and an id field, both populated with 'hpiLocation-established'. Is there a list of 'FSH metadata' and what they do in the spec? (I couldn't find it)
Right -- Extension supports both a name and an id because FHIR StructureDefinition has discrete fields for each. Unfortunately, the same can't be said for instances -- there is no obvious place to put the _name_ of an instance within the instance itself.
The potential metadata fields really depend on what you're writing; what is available is based on the thing you're defining (e.g., Profile vs Extension vs ValueSet vs CodeSystem vs Instance). So... there is no one set of FSH metadata fields -- although we try to provide consistency where we can. Currently, I think that you'd need to go to the appropriate section of the documentation for each type of FSH thing to see what its available metadata fields are for it. We could potentially update the Keywords part of the documentation to list where each is valid, however.
Last updated: Apr 12 2022 at 19:14 UTC
