FHIR Chat · instances · shorthand

Stream: shorthand

Topic: instances

David Hay (Dec 16 2019 at 20:25):

Any thoughts about when sushi will implement instance generation - per https://github.com/HL7/fhir-shorthand/wiki/3.7-Instances

Chris Moesel (Dec 16 2019 at 20:57):

Hi @David Hay -- we're currently working on that. We're hoping to have something by the end of the week. It will not be 100% complete, in that it won't support the shortcut for extensions (e.g., you'll have to say extension[my-extension].valueBoolean = true instead of just my-extension.valueBoolean = true). It also won't automatically add fixed values from parent structure definitions (but it will add fixed values from parent FSH definitions).

David Hay (Dec 16 2019 at 20:58):

Oh cool! Any resource type?

Chris Moesel (Dec 16 2019 at 21:05):

Yes, as long as it is a valid R4 resource, you should be able to create an instance of it.

David Hay (Dec 16 2019 at 21:07):

I look forward to the release! (part of my interest is in using this facility as a 'back end' when generating instances in the clinFHIR Graph builder - I'm having fun getting it to create complex resources, so this might help...)

Chris Moesel (Dec 16 2019 at 21:09):

Great! Once it is released, we welcome your feedback! As you know, the FHIR Shorthand syntax is still very new -- as is any tooling around it -- so we'd be glad to have you participate in defining how it all should work!

David Hay (Dec 16 2019 at 21:11):

Will do :) . Will also be thinking about 'on line' execution of this could work - so that I can execute from a browser...

Grahame Grieve (Dec 18 2019 at 12:07):

I'm going to spend some time with Shorthand next week... but I have a number of areas where I think that the decisions are problematic. I

Grahame Grieve (Dec 18 2019 at 12:08):

I'm particularly concerned about documentation

Mark Kramer (Dec 18 2019 at 15:47):

What kind of documentation concerns, if you don't mind me asking?

Grahame Grieve (Dec 18 2019 at 19:15):

a good implementation guide has ample documentation on the elements. None of your examples have much documentation at all. Instead they're focused on readability... but that seems like a wrong focus to me - it needs to be readable in actual use, not a falsely simplified view.

I do not find the ^short documentation at all pleasing, but what happens to as the documentation becomes more intrusive? And lots of markdown.... and translations, too, which will be a big focus next year.

Mark Kramer (Dec 18 2019 at 22:42):

It's a work in progress, and open to examples, suggestions, and contributions.

Grahame Grieve (Dec 18 2019 at 22:47):

well, my first suggestion is: provide more documentation as part of the examples

Grahame Grieve (Dec 18 2019 at 22:48):

I don't find the way must-support works very nice syntactically. Listing all the fields, and then saying MS at the end.... it feels very post-fix-y

Grahame Grieve (Dec 18 2019 at 22:48):

there's not a way to put that at the start:

• MS [list]

?

Chris Moesel (Dec 19 2019 at 00:30):

Currently, every "rule" in FSH starts with a path -- so in that way, there is consistency no matter what you are doing. Part of the inspiration came from trying to draw from a familiar view -- the snapshot view, which lists path all the way to the left, then has flags, card, types to the right of the path.

Grahame Grieve (Dec 19 2019 at 00:31):

well, I follow that, but it only has one path. So... I'm not sure that's the right driver for the must-support way of doing things. The ideal should be the most natural way of expressing things for the author, right?

Chris Moesel (Dec 19 2019 at 00:32):

As for the flags, we originally had one rule per line, e.g.:

* foo MS
* bar MS
* baz MS

but after trying to mirror existing profiles that had tons of MS, we realized that approach was cumbersome, hence the multiple paths.

Chris Moesel (Dec 19 2019 at 00:33):

And yes -- the ideal should be what's most natural for the author. So... I'm not arguing that our current approach is "right" -- I'm just trying to provide the background for how we got there. ;-)

Chris Moesel (Dec 19 2019 at 00:35):

So... I think this is one of those things where we have to figure out if overall consistency (path always on the left) is what's easiest for the author, or if optimizing expressibility individually for every individual rule is what's best -- even if it means less consistency. Or something between.

Grahame Grieve (Dec 19 2019 at 00:42):

right. there's a clear rationale for doing something different in the case of multiple paths (or at least treating the presence of multiple paths as a rationale for having a different syntax if we want)

Grahame Grieve (Dec 19 2019 at 00:42):

are there other cases for multiple paths?

Chris Moesel (Dec 19 2019 at 02:11):

So far I think flags are the only multi-path constraint, but we were thinking maybe cardinality too. After Mark wrote up a profile that zeroed out a bunch of elements, we wondered if maybe it would make sense as a group too. Still up in the air (glad to hear your opinion on it). And yes, I guess it does make sense that the differentness of multi-path constraints could justify a different approach. Definitely something to consider. Is your concern that when there is a long list, the flag at the end kind of gets lost in the noise?

Grahame Grieve (Dec 19 2019 at 02:39):

yeah pretty much. I'm seeing all these paths... MS is lost in the end...

Grahame Grieve (Dec 19 2019 at 02:39):

I guess probition could be the same - mark all as 0..0

David Hay (Dec 19 2019 at 02:50):

Would it be a crazy idea to put all the documentation in a separate file? Perhaps same name with a different extension. Then - have header and path based markers for the different documentation supported...

Grahame Grieve (Dec 19 2019 at 02:54):

it has real benefits but a big down side - how the linking is done

nicola (RIO/SS) (Dec 19 2019 at 06:06):

MS can be set to true implicitly by default?!

nicola (RIO/SS) (Dec 19 2019 at 06:07):

if element is in a profile, doesn't it mean MS?

Grahame Grieve (Dec 19 2019 at 06:26):

not necessarily. You might make constraints etc on an element that only some implementers will choose to support

nicola (RIO/SS) (Dec 19 2019 at 15:07):

At least looking into us-core it is 20/80?

Chris Moesel (Dec 19 2019 at 16:30):

Would it be a crazy idea to put all the documentation in a separate file?

I don't think that would be crazy, and in fact, we considered that as an approach for internationalization as well. This would allow you to have "translation" files for each language you want to support. If FSH did support something like this, I expect that maybe it should allow the author to choose whether or not they want their primary language descriptions inline w/ the constraints or if they want them outboarded to a separate file (or a mix -- such as shorts with the constraints but definitions in a separate file).

Mark Kramer (Dec 20 2019 at 14:01):

Documentation = FSH documentation vs. class (profile, element, extension, example) documentation. Just want to make sure each stays in separate swim lane (pun intended). Since _class_ documentation and localization is an area of concern, I think we should determine the grammar sooner rather than later. Let's flesh this out on the wiki.

Mark Kramer (Dec 20 2019 at 14:54):

See if you like this: https://github.com/HL7/fhir-shorthand/wiki/2.6-Localization

David Hay (Dec 20 2019 at 17:00):

Could the external documentation be markdown? And perhaps a separate file for each language (with a convention for the name perhaps -
{profile name }_{language code} - eg NZPatient_en-nz or NZPatient_en-au for our Australian brethren?

Within the file we could either snaffle one of the existing delimiters for the path or use a made up one = %%{path}^element - eg %%Patient.name^short

Mark Kramer (Dec 25 2019 at 20:59):

Yes, you can use markdown. Thus far, we have tried to stay away from dictating either file names or file contents, under the theory that different users may have individual preferences. I am kind of tilting toward extending the path grammar to include a language for strings and markdowns. It's very modular that way.

Grahame Grieve (Dec 25 2019 at 21:17):

or file contents

isn't fixing file contents the point?

Mark Kramer (Jan 06 2020 at 17:28):

Yes, contents in terms of the language, sure. But we don't say what items go into which files. For example, you could put all profiles in one file, each profile in separate files, or mix examples with profiles, etc.

Alex Goel (Jan 14 2021 at 20:55):

Hi, @Fred Marsh and I are trying to generate an example instance from the following FSH file, but our only getting our final result reference instead of all 4 in the generated file. Any idea why?

Alias: LNC = http://loinc.org
Instance: eCCDiagnosticReport
InstanceOf: http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note
Title: "eCC Diagnostic Report"
Description: "Example eCC Diagnostic report using US Core"
Usage: #example
* id = "eCCDiagnosticReport0"
* identifier.use = #usual
* identifier.type = http://terminology.hl7.org/CodeSystem/v2-0203#MR "Medical Record Number"
* identifier.system = "http://hospital.example.org"
* identifier.value = "eCCDiagnosticReport0"
* status = #final
* category = LNC#LP7839-6 "Pathology"
* code = LNC#60568-3 "Pathology Synoptic report"
* subject = Reference(q201)
* effectiveDateTime = "2021-01-14"
* performer = Reference(pathpract1)
* result = Reference(Adrenal.Bx.Res.129_3.002.011.RC1_sdcFDF1.FormInstanceVersionURI.2157)
* result = Reference(Adrenal.Bx.Res.129_3.002.011.RC1_sdcFDF.f96d3fea-62b3-47e9-8443-f199c2f946f0.ver1.49275.100004300)
* result = Reference(Adrenal.Bx.Res.129_3.002.011.RC1_sdcFDF1.FormInstanceVersionURI.43324)
* result = Reference(Adrenal.Bx.Res.129_3.002.011.RC1_sdcFDF1.FormInstanceVersionURI.56271)

Generated file:

{
  "resourceType": "DiagnosticReport",
  "id": "eCCDiagnosticReport0",
  "meta": {
    "profile": [
      "http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note"
    ]
  },
  "identifier": [
    {
      "use": "usual",
      "type": {
        "coding": [
          {
            "code": "MR",
            "system": "http://terminology.hl7.org/CodeSystem/v2-0203",
            "display": "Medical Record Number"
          }
        ]
      },
      "system": "http://hospital.example.org",
      "value": "eCCDiagnosticReport0"
    }
  ],
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "code": "LP7839-6",
          "system": "http://loinc.org",
          "display": "Pathology"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "code": "60568-3",
        "system": "http://loinc.org",
        "display": "Pathology Synoptic report"
      }
    ]
  },
  "subject": {
    "reference": "q201"
  },
  "effectiveDateTime": "2021-01-14",
  "performer": [
    {
      "reference": "pathpract1"
    }
  ],
  "result": [
    {
      "reference": "Adrenal.Bx.Res.129_3.002.011.RC1_sdcFDF1.FormInstanceVersionURI.56271"
    }
  ]
}

Alex Goel (Jan 14 2021 at 20:57):

We confirmed SUSHI is reading whatever * result is last

David Pyke (Jan 14 2021 at 20:59):

you need to create an array result[0], result[1], etc.

ryan moehrke (Jan 14 2021 at 21:13):

or result[+], result[+], result[+], etc. :p

David Pyke (Jan 14 2021 at 21:14):

IF they upgraded :p

ryan moehrke (Jan 14 2021 at 21:18):

but who wouldn't upgrade when there's all these features

Alex Goel (Jan 15 2021 at 14:47):

Thanks! That worked!

Last updated: Apr 12 2022 at 19:14 UTC