FHIR Chat · FHIR Shorthand · fhir/infrastructure-wg

Stream: fhir/infrastructure-wg

Topic: FHIR Shorthand

Mark Kramer (Sep 17 2019 at 19:06):

Document for discussion in Q4 today... FHIR-Shorthand-v3.docx

Chris Moesel (Sep 17 2019 at 19:40):

Mark had dialed me in on Skype so I could listen in and participate -- but I think when he connected to HDMI, it killed his mic -- so I cannot hear anything. So if he tries to ask me a question, that is why I will not respond!

Josh Mandel (Sep 17 2019 at 19:41):

Gah, that's a good theory

Chris Moesel (Sep 17 2019 at 19:41):

THank you!

Ewout Kramer (Sep 17 2019 at 19:55):

On the subject of naming, Rick suggested naming the FSH compiler SUSHI ("Sushi Unshortens Short Hand Inputs") ?

Mark Kramer (Sep 17 2019 at 20:27):

On the subject of naming, Rick suggested naming the FSH compiler SUSHI ("Sushi Unshortens Short Hand Inputs") ?

https://en.wikipedia.org/wiki/Recursive_acronym

Chris Moesel (Sep 17 2019 at 20:50):

The only thing I don't like about Rick's clever SUSHI acronym is that I didn't think of it myself! Jealous of those mad backronym skills!

Mark Kramer (Sep 18 2019 at 13:24):

Here's an update on the FHIR Shorthand FHIR-Shorthand-v3.docx

Mark Kramer (Sep 18 2019 at 15:38):

I have a bare-bones PSS for FHIR Shorthand here: https://confluence.hl7.org/display/FHIRI/FHIR+Shorthand. Is there a quarter today to discuss it? (I will not be here Thursday or Friday).

Ewout Kramer (Sep 18 2019 at 15:39):

Maybe Today Q4. @Rick Geimer ?

Ewout Kramer (Sep 18 2019 at 15:40):

Mm.... @Rick Geimer seems to be double booked that quarter - we don't have a chair :-(

Mark Kramer (Sep 19 2019 at 16:53):

Can someone who has permissions create a repo on https://github.com/HL7 for FHIR Shorthand?

Josh Mandel (Sep 19 2019 at 17:20):

HL7/fhir-shorthand OK?

Mark Kramer (Sep 19 2019 at 20:29):

yep, that would be great. Thanks, @Josh Mandel . Can you give me and @Chris Moesel the appropriate level of commit rights? I appreciate it.

Josh Mandel (Sep 19 2019 at 20:43):

Created https://github.com/HL7/fhir-shorthand and a team at https://github.com/orgs/HL7/teams/fhir-shorthand to manage it. @Chris Moesel is a Team maintainer an should be able to add @Mark Kramer .

Chris Moesel (Sep 19 2019 at 20:52):

Thanks, @Josh Mandel. I can't add @Mark Kramer, as it looks like he's not in the HL7 organization on GitHub. I don't have permissions to add him to the organization, and it won't let me add him to the team until he's in the organization.

If you have permissions to do so, his GitHub username is markkramerus.

Grahame Grieve (Sep 19 2019 at 20:54):

he doesn't have to be in the organization

Chris Moesel (Sep 19 2019 at 21:01):

When I try to add him, GitHub disables the selector so I can't -- and a message says "Not a member of this organization".
pasted image

Lloyd McKenzie (Sep 19 2019 at 21:31):

Mark, I'm assuming that at some point you've agree to the usual committer rules (abide by chapter 16, monitor committers/announce). You should now have an invitation

Eric Haas (Sep 19 2019 at 21:32):

It’s seems we are back to slicing by fixed value instead of pattern using this. It seems simpler that way when using this form.

Grahame Grieve (Sep 19 2019 at 21:33):

I don't understand why that is

Grahame Grieve (Sep 19 2019 at 21:34):

@Chris Moesel looks like you're trying to add him to the team, not the repo

Grahame Grieve (Sep 19 2019 at 21:34):

her's already added to the repo

Grahame Grieve (Sep 19 2019 at 21:35):

@Eric Haas is this in the wrong context:

it’s seems we are back to slicing by fixed value

?

Eric Haas (Sep 19 2019 at 23:32):

(deleted)

Josh Mandel (Sep 19 2019 at 23:54):

To clarify behavior here: you can add members to a repository individually or as part of a team. I was suggesting adding Mark as part of the team to keep management in one place but that only works if he's part of HL7 organization to start. Which he should be :-)

Grahame Grieve (Sep 20 2019 at 00:11):

I've never bothered; I just add people to the repo directly

Grahame Grieve (Sep 20 2019 at 00:11):

is this the right place to discuss the syntax?

Grahame Grieve (Sep 20 2019 at 00:11):

I want to hammer on the syntax for defining mapping statements - that is, for ElementDefinition.mapping

Josh Mandel (Sep 20 2019 at 00:43):

Let's start here and migrate to a new stream when when the volume is apparent (i.e., next week ;-))

Chris Moesel (Sep 20 2019 at 01:45):

It’s seems we are back to slicing by fixed value instead of pattern using this. It seems simpler that way when using this form.

@Eric Haas -- no, that's not the intent at all; if an example seemed to suggest that I apologize. In fact, the point is that an author should be able to express their intent and the language/compiler handles to details -- building the structure definition according to current best practices.

Chris Moesel (Sep 20 2019 at 01:50):

As for where design discussions take place, @Mark Kramer and I are working on determining the best place/approach/format for those discussions -- but until then, I think here (or another stream) is fine. I love Zulip -- but we will probably need some more structure to catalog and enumerate the features, language design around said features, etc. Maybe Confluence? Maybe GitHub? Open to suggestions.

Grahame Grieve (Sep 20 2019 at 03:00):

the best discussions use github issues and zulip and weave them together

Mark Kramer (Sep 20 2019 at 12:40):

:+1: ... I'd like to try to draft the documentation prior to doing heavy coding. In addition to github issues on the fhir-shorthand repo, and this channel, folks can take swings at the documentation (physically a few .md files)

Grahame Grieve (Sep 20 2019 at 12:40):

sure.

Grahame Grieve (Sep 20 2019 at 12:41):

to repeat, though, I am interested in operationalising mapping early.

Grahame Grieve (Sep 20 2019 at 12:42):

In principle, I think, it would be an object, something like

Mapping: MY SCT Mapping
URL: http://something
Object: Some reference
* AllergyIntolerance = "asdasdnasd"
* AllergyIntolerance.code = "asdasdad"

Grahame Grieve (Sep 20 2019 at 12:43):

where Object refers to a profile you've described elsewhere (or a canonical url from the spec) but I don't know how slicing would work

Mark Kramer (Sep 20 2019 at 12:46):

@Grahame Grieve I don't know how you are thinking about this, but in a mapping I would suspect there is a source, target, and transformation. I don't see those things in your example. Can you explain?

Grahame Grieve (Sep 20 2019 at 12:47):

for mappings in the structure definition, we don't fix the syntax of the target; instead we say that the URL defines the syntax of target + transform as needed.

Grahame Grieve (Sep 20 2019 at 12:47):

so just source + target (we break out the transform explicitly elsewhere, and if you want want something good about that, we have all the tools you could dream of)

Grahame Grieve (Sep 20 2019 at 12:47):

source = target

Grahame Grieve (Sep 20 2019 at 12:48):

where source is a profile you defined

Grahame Grieve (Sep 20 2019 at 12:48):

I think that's the context anyway

Mark Kramer (Sep 20 2019 at 12:49):

Oh, I totally misunderstood that you were referring to the mappings in SD. We briefly looked at the mapping statements in US Core, and rendered them as:

Mapping: argonaut-dq-dstu2 [Argonaut-DQ-DSTU2](http://unknown.org/Argonaut-DQ-DSTU2)
Mapping: rim [RIM Mapping](http://hl7.org/v3)
Mapping: cds [CDA (R2)](http://hl7.org/v3/cda)

Grahame Grieve (Sep 20 2019 at 12:51):

so that fragment matches StructureDefinition.mapping not ElementDefinition.mapping, yes?

Mark Kramer (Sep 20 2019 at 12:51):

The former

Grahame Grieve (Sep 20 2019 at 12:52):

ok. so comment is deferred to the language string subsection?

Mark Kramer (Sep 20 2019 at 12:56):

I recommend

Mapping: argonaut-dq-dstu2 [Argonaut-DQ-DSTU2](http://unknown.org/Argonaut-DQ-DSTU2) "This is the mapping to Argonaut"
Mapping: rim [RIM Mapping](http://hl7.org/v3)  "And the rim"
Mapping: cds [CDA (R2)](http://hl7.org/v3/cda) "Or CDA"

Stylistically, it will fit with some other grammar we're thinking about.

Grahame Grieve (Sep 20 2019 at 12:57):

I guess we hope that comment doesn't get too long. At least it's not - yet? - markdown

Grahame Grieve (Sep 20 2019 at 12:59):

anyway, what about ElementDefinition.mapping?

Mark Kramer (Sep 20 2019 at 13:01):

Both external markdown and internationalization (localization) need to be accounted for. I don't know how exactly that would work.

Mapping: argonaut-dq-dstu2 [Argonaut-DQ-DSTU2](http://unknown.org/Argonaut-DQ-DSTU2)  [EN](mymarkdown.md)

Either multiple files for localization, or maybe, inside a single file? This doesn't look right yet :(

Mark Kramer (Sep 20 2019 at 13:13):

ElementDefinition.mapping would be very similar, but we have to work out if keywords or constraints are appropriate in. That's still fuzzy.

Grahame Grieve (Sep 20 2019 at 13:40):

I guess the first question for me about ElementDefinition is whether you add element mappings as the elements are defined in the profile, or whether you split out the mapping to it's own section, one mapping per section

Chris Moesel (Sep 20 2019 at 13:58):

When I did a test implementation of USCore Patient using experimental FSH syntax, I did the following within the Profile definition:

* extension(USCoreRaceExtension) maps to argonaut-dq-dstu2 Patient.extension

(That's a real mapping from US Core Patient). It doesn't cover language or comment since US Core didn't use those. But... it was just a quick "how might this look" exercise.

Chris Moesel (Sep 20 2019 at 14:01):

Realizing that there might be a lot of mapping statements, and you don't want to lose the signal (actual constraints) to the noise (mappings), I also wondered if they should all be grouped together in their own section. I was thinking you could put them all at the bottom of the profile definition in FSH, but they also could certainly be their own first-class entity in FSH (allowing you to define them even in a separate file if you want).

Chris Moesel (Sep 20 2019 at 14:02):

I think that's exactly the type of discussion we want to have. The same goes for short, definition, and purpose -- how do we support those so they're in the context of the profile -- but without overshadowing the actual structural information? It's a good question.

Grahame Grieve (Sep 20 2019 at 14:07):

I do feel like it's better to group them, but then that raises the question of correlating to the right element (if you're slicing...). But i think you have that problem anyway in the format you defined

Grahame Grieve (Sep 20 2019 at 14:07):

and yes, documentation is a problem. and it's need to support multi-lingual

Chris Moesel (Sep 20 2019 at 17:37):

Our prototype syntax had a way of addressing slices (similar to FHIRPath, it would be slice(sliceName) or some prefer slice[sliceName]) -- so I imagine that's how you'd correlate to a sliced element (unless I'm misunderstanding). E.g.,

* component.slice(SystolicBP) maps to rim outBoundRelationship[typeCode=COMP]

Grahame Grieve (Sep 20 2019 at 17:38):

and where would this fit?

Chris Moesel (Sep 20 2019 at 18:15):

I'm not sure. That's why we want the community's help! ;-) That was just an example syntax to get the conversation started. But since you asked, here are a few potential approaches:

Chris Moesel (Sep 20 2019 at 18:16):

I just took the first few elements of US Core patient for this one (so the example is real).

Chris Moesel (Sep 20 2019 at 18:16):

Option A: mapping statements adjecent to constraint statements

Profile:    USCorePatientProfileMappingOptionA (us-core-patient-a)
// Snipping out metadata irrelevant to this discussion
Mapping: argonaut-dq-dstu2 [Argonaut-DQ-DSTU2](http://unknown.org/Argonaut-DQ-DSTU2)
* $root maps to argonaut-dq-dstu2 Patient
* extension(USCoreRaceExtension) MS 0..1
* extension(USCoreRaceExtension) maps to argonaut-dq-dstu2 Patient.extension
* extension(USCoreEthnicityExtension) MS 0..1
* extension(USCoreEthnicityExtension) maps to argonaut-dq-dstu2 Patient.extension
* extension(USCoreBirthSexExtension) MS 0..1
* extension(USCoreBirthSexExtension) maps to argonaut-dq-dstu2 Patient.extension
* identifier MS 1..*
* identifier maps to argonaut-dq-dstu2 Patient.identifier
* identifier.system MS 1..1
* identifier.sytem maps to argonaut-dq-dstu2 Patient.system
* identifier.value MS 1..1
* identifier.value maps to argonaut-dq-dstu2 Patient.value

Chris Moesel (Sep 20 2019 at 18:16):

Option B: same as option A, but + indicates it pertains to last element

Profile:    USCorePatientProfileMappingOptionB (us-core-patient-b)
// Snipping out metadata irrelevant to this discussion
Mapping: argonaut-dq-dstu2 [Argonaut-DQ-DSTU2](http://unknown.org/Argonaut-DQ-DSTU2)
* $root maps to argonaut-dq-dstu2 Patient
* extension(USCoreRaceExtension) MS 0..1
  + maps to argonaut-dq-dstu2 Patient.extension
* extension(USCoreEthnicityExtension) MS 0..1
  + maps to argonaut-dq-dstu2 Patient.extension
* extension(USCoreBirthSexExtension) MS 0..1
  + maps to argonaut-dq-dstu2 Patient.extension
* identifier MS 1..*
  + maps to argonaut-dq-dstu2 Patient.identifier
* identifier.system MS 1..1
  + maps to argonaut-dq-dstu2 Patient.system
* identifier.value MS 1..1
  + maps to argonaut-dq-dstu2 Patient.value

Chris Moesel (Sep 20 2019 at 18:17):

Option C: puts all the mapping statements at the end of the definition

Profile:    USCorePatientProfileMappingOptionC (us-core-patient-c)
// Snipping out metadata irrelevant to this discussion
Mapping: argonaut-dq-dstu2 [Argonaut-DQ-DSTU2](http://unknown.org/Argonaut-DQ-DSTU2)
* extension(USCoreRaceExtension) MS 0..1
* extension(USCoreEthnicityExtension) MS 0..1
* extension(USCoreBirthSexExtension) MS 0..1
* identifier MS 1..*
* identifier.system MS 1..1
* identifier.value MS 1..1
* $root maps to argonaut-dq-dstu2 Patient
* extension(USCoreRaceExtension) maps to argonaut-dq-dstu2 Patient.extension
* extension(USCoreEthnicityExtension) maps to argonaut-dq-dstu2 Patient.extension
* extension(USCoreBirthSexExtension) maps to argonaut-dq-dstu2 Patient.extension
* identifier maps to argonaut-dq-dstu2 Patient.identifier
* identifier.sytem maps to argonaut-dq-dstu2 Patient.system
* identifier.value maps to argonaut-dq-dstu2 Patient.value

Chris Moesel (Sep 20 2019 at 18:18):

// Option D: same as C but new syntax to cut a lot of the repetition

Profile:    USCorePatientProfileMappingOptionD (us-core-patient-c)
// Snipping out metadata irrelevant to this discussion
* extension(USCoreRaceExtension) MS 0..1
* extension(USCoreEthnicityExtension) MS 0..1
* extension(USCoreBirthSexExtension) MS 0..1
* identifier MS 1..*
* identifier.system MS 1..1
* identifier.value MS 1..1
* maps to argonaut-dq-dstu2 [Argonaut-DQ-DSTU2](http://unknown.org/Argonaut-DQ-DSTU2)
  - $root -> Patient
  - extension(USCoreRaceExtension) -> Patient.extension
  - extension(USCoreEthnicityExtension) -> Patient.extension
  - extension(USCoreBirthSexExtension) -> Patient.extension
  - identifier -> Patient.identifier
  - identifier.sytem -> Patient.system
  - identifier.value -> Patient.value

Chris Moesel (Sep 20 2019 at 18:18):

Option E: similar to D but with mapping as a separate entity

Profile:    USCorePatientProfileMappingOptionE (us-core-patient-c)
// Snipping out metadata irrelevant to this discussion
* extension(USCoreRaceExtension) MS 0..1
* extension(USCoreEthnicityExtension) MS 0..1
* extension(USCoreBirthSexExtension) MS 0..1
* identifier MS 1..*
* identifier.system MS 1..1
* identifier.value MS 1..1

Mapping:  USCorePatientToArgonaut
Source:   USCorePatientMappingOptionE
Target:   argonaut-dq-dstu2 [Argonaut-DQ-DSTU2](http://unknown.org/Argonaut-DQ-DSTU2)
* $root -> Patient
* extension(USCoreRaceExtension) -> Patient.extension
* extension(USCoreEthnicityExtension) -> Patient.extension
* extension(USCoreBirthSexExtension) -> Patient.extension
* identifier -> Patient.identifier
* identifier.sytem -> Patient.system
* identifier.value -> Patient.value

Chris Moesel (Sep 20 2019 at 18:19):

I know none have mapping comments (US Core didn't provide any) -- but this is really more about placement of the mapping statements than the full syntax...

Chris Moesel (Sep 20 2019 at 18:22):

Now that I've written them all out, I kind of like E. Or something like it. Fully separating out mapping from structure/constraints makes it much cleaner.

Grahame Grieve (Sep 20 2019 at 19:00):

yes I like E best.

Grahame Grieve (Sep 20 2019 at 19:00):

slice(sliceName)

it we make it just :sliceName then it will match the way we already do slicing in element id

Chris Moesel (Sep 20 2019 at 19:15):

if we make it just :sliceName then it will match the way we already do slicing in element id

Yep. I think we need to figure out our preferences regarding where we borrow syntax from and when. If we borrow from element id rules, we get component:SystolicBP, but if we borrow from FHIRPath, we get component.slice(SystolicBP) (although it's not a perfect match since FP requires the SD as the first arg). If we borrow from CIMPL, it's more like component[SystolicBP]. I think we're going to want to find the right balance between familiar-to-people-who-breathe-SDs and intuitive-to-people-who-are-normal-human-beings.

Chris Moesel (Sep 20 2019 at 19:17):

In this case, I'd be fine w/ component:SystolicBP -- although I do wish it popped out a bit more. It's easy to miss the : when you're reading it, especially if it's in a long path.

Mark Kramer (Sep 20 2019 at 19:20):

Good discussion! I like the CIMPL syntax because the square brackets indicates a choice in multiple contexts:
value[Quantity] // type choice
component[SystolicBP] // slice choice
CodeableConcept.Coding[1] // array choice

Chris Moesel (Sep 20 2019 at 19:23):

That approach would also follow on to extensions (when referencing a locally defined one or an external one):
extension[USCoreRaceExtension]
extension[http://hl7.org/fhir/StructureDefinition/bodySite]

Lloyd McKenzie (Sep 20 2019 at 19:39):

E is good for mappings but I like B for adding documentation

Brian Postlethwaite (Sep 20 2019 at 19:42):

What was the target of that content? A StructureMap, or back into the StructureDefinition/ElementDefinition.mapping property?

Chris Moesel (Sep 20 2019 at 19:52):

@Brian Postlethwaite -- the current discussion is strictly on populating the StructureDefinition.mapping and ElementDefinition.mapping properties.

Grahame Grieve (Sep 21 2019 at 01:42):

I think all translatable strings should be in a separate section such that translation to another language is simple by adding an alternative section in another file. Language translation is a high priority for me in the next 2 cycles based in implementer feedback

Mark Kramer (Sep 21 2019 at 15:49):

I'm beginning to migrate designs and examples to the Github wiki: https://github.com/HL7/fhir-shorthand/wiki. For example, the code samples on mapping are now here: https://github.com/HL7/fhir-shorthand/wiki/Mapping-Shorthand. I think using the wiki will give us the ability to structure our conversations better. Does that make sense?

Grahame Grieve (Sep 21 2019 at 15:50):

do we want to assign a file extension to the DSL? .fish?

Mark Kramer (Sep 21 2019 at 15:50):

I've been assuming .fsh

Grahame Grieve (Sep 21 2019 at 15:51):

that'll work

Mark Kramer (Sep 21 2019 at 15:51):

No major collisions with other file types, I checked.

Mark Kramer (Sep 22 2019 at 00:00):

I would like to separate the MustSupports from the other parts of the definition. To increase the reuse of the structure. I wonder if we should introduce the concept of a template that just does the MS flags.

Grahame Grieve (Sep 22 2019 at 00:01):

I think that MustSupport isn't the only thing in that category. It's kind of like mapping - a mapping profile

Grahame Grieve (Sep 22 2019 at 00:01):

examples?

Grahame Grieve (Sep 22 2019 at 00:01):

maxLength?

Grahame Grieve (Sep 22 2019 at 00:06):

alias?

Grahame Grieve (Sep 22 2019 at 00:06):

but also I think that it makes sense to do MS as part a normal profile as well

Eric Haas (Sep 22 2019 at 23:55):

I would like to separate the MustSupports from the other parts of the definition. To increase the reuse of the structure. I wonder if we should introduce the concept of a template that just does the MS flags.

What does this mean? Are we going to split the SD into multiple files?

Lloyd McKenzie (Sep 23 2019 at 03:53):

No. I think Mark would like us to encourage defining separate profiles where mustSupport and structural elements are defined separately. However, in practice, usage notes, overridden descriptions are just as much of an issue. The real question is how to encourage projects that are focused on their own requirements to consider and design to allow downstream reuse.

Mark Kramer (Oct 09 2019 at 15:35):

Update on FHIR Shorthand: The very drafty specification is here: https://github.com/HL7/fhir-shorthand/wiki. The spec is still in flux, and feedback is welcome. Right now, the spec is split up between ~25 wiki pages, which is hard to digest. The best way to stimulate discussion and review, and build a team around FSH, might be through a weekly dedicated call. My question is -- should we schedule a FHIR Shorthand call to discuss the spec? Would you attend? The other option is to wait until we have a mock-up how FSH would look for a small-ish IG. That might be more digestable. Should we start a weekly call now, or wait a few weeks to a month, until a more complete example is ready? Other ideas or approaches?

David Hay (Oct 09 2019 at 19:14):

Is there an application (ideally web based) that can produce the Profile / IG from an FSH file (accepting that it is very drafty) ? My interest is to be able to generate FSH files from the clinFHIR Logical Modeler, which can then be used to create a 'real' profile / IG...

Chris Moesel (Oct 09 2019 at 19:25):

@David Hay -- that's the plan, but we don't have an application ready yet. We're starting something, but also trying to be sensitive to the fact that the syntax will change a lot! Right now, we're thinking the open source reference implementation will be written in TypeScript (which compiles to JavaScript) -- so that gives us many integration possibilities (server-side, browser-side, etc).

David Hay (Oct 09 2019 at 19:26):

Sounds good! I'll watch with interest. Happy to be a tester when you're ready...

Ward Weistra (Oct 10 2019 at 08:49):

Thanks @Mark Kramer, and I would be interested in joining that call to stay up to date. How do you want feedback on the wiki? I don't think I can edit or PR on the repo.

For now I'll list some questions here:

• https://github.com/HL7/fhir-shorthand/wiki#desiderata > Point 4 is missing a link around (see this example fr¬om the September 2019 ballot)
• https://github.com/HL7/fhir-shorthand/wiki/8.-Tools speaks of SUSHI (FSH -> FHIR) and SASHIMI (FHIR -> FSH), the pages under it have SUSHI for FSH -> FHIR and Hatchery which does FHIR -> FSH
• I got from the WGM discussions that round tripping would likely not be possible, because 'you would lose the intent of the author' (didn't fully get the details). I assume you might not end up with exactly the same FSH file after a round trip? But you would always end up with the same StructureDefinition after a round trip? Maybe some words can be added on this in the Wiki.
• Is a FSH Tank roughly the FSH content + configuration file of one IG/Package / Simplifier project?

Mark Kramer (Oct 10 2019 at 11:49):

Hi @Ward Weistra -- thank you for the feedback.

• I'm looking into who can configure the repo. It doesn't look like I can add you.
• We are playing with names and bad puns, hence the inconsistency between Sashimi and Hatchery. I think Hatchery is more descriptive: Hatchery -> FSH -> Sushi -> StructureDef. We've called our "smart slicing" algorithm "Ginzu" (get it?)...
• Regarding round trips, we have introduced an escape syntax that in theory should allow round tripping from any SD. Anything that we can't render in "core FSH" could be addressed in the escape syntax. If you take a "wild-type" SD and run Hatchery, you should get FSH that subsequently can be round-tripped without further changes. In other words, FSH -> SD -> FSH should preserve the structure of FSH.
• FSH Tank is exactly as you describe... FSH content plus configuration that can produce an IG, and the content of one repository. I think it equates to a FHIR package (@Chris Moesel can correct me if I'm wrong).
• FSH Farm is a collection of FSH Tanks. :grinning:

Ward Weistra (Oct 10 2019 at 11:54):

I had to Google a few, but appreciate it :) The FSH Tank too.

Michel Rutten (Oct 10 2019 at 15:28):

@Mark Kramer @Chris Moesel Did you already decide on reference compiler implementation approach? i.e. would you prefer grammar specification & ANTLR, or manual development?

Mark Kramer (Oct 10 2019 at 15:29):

We plan on formally describing the FSH grammar in ANTLR4

Chris Moesel (Oct 10 2019 at 15:34):

Right. We will define a former grammar using ANTLR4 .g4 files (similar to FHIRPath and CQL). We'll then use that to generate JavaScript or TypeScript targets (TypeScript support is offered by a 3rd party plugin, so we need to test it first). The reference implementation will likely use the listener-style targets to parse the documents into in-memory models of the relevant information.

Mark Kramer (Oct 10 2019 at 16:41):

Can someone with great power set up a weekly recurring conference call for FHIR Shorthand? I lack the authority. The proposed time is Thursdays 9-10 Eastern US time. FHIR-I is the sponsor, and the call in (at least for now) is Skype: https://meet.mitre.org/mkramer/K383VJGC . I would greatly appreciate it!

Lloyd McKenzie (Oct 10 2019 at 17:42):

Done - notices should go out for the 17th

Mark Kramer (Oct 10 2019 at 17:43):

thank you, Lloyd!

Mark Kramer (Oct 10 2019 at 17:44):

@Ward Weistra The call is set for Thursdays at 9 am Eastern US time.

Michel Rutten (Oct 10 2019 at 18:21):

Thanks, ANTLR sounds good.

Mark Kramer (Oct 28 2019 at 20:29):

Architecture by overburdening an analogy... FSH-Workflow.PNG :grinning:

Mark Kramer (Oct 31 2019 at 12:47):

Reminder of FHIR Shorthand call at 9 am Eastern US time, today (15 minutes from now): https://meet.mitre.org/mkramer/K383VJGC

Ward Weistra (Oct 31 2019 at 16:07):

Put the weekly returning call in my agenda now, had to miss today.

Mark Kramer (Nov 06 2019 at 18:56):

The FHIR Shorthand group is meeting again tomorrow (Thursday) at 9 am Eastern US Standard Time. Please note that the US just went off Daylight Savings time, so your local time might now be 1 hour different than last week. We have a couple of agenda items in mind: (1) Update on our progress for DevDays (a talk and hands-on demo are planned), (2) overview of first steps in the reference implementation, (3) Questions on whether to support defining local codes and code systems, (4) Translation/Localization design, (5) anything else in the spec that participants want to discuss.

Ward Weistra (Nov 14 2019 at 15:09):

@Chris Moesel I know you were planning to simplify this still, but how did you run SUSHI again on a folder/fsh file? With https://github.com/TypeStrong/ts-node? ts-node ./someFile.ts ./fishTankFolder ?

Chris Moesel (Nov 14 2019 at 16:07):

So you need to global install ts-node first:

npm install -g ts-node

ts-node basically just compiles the typescript to js first and then runs it (that's why there's a little lag when you run it).

Then:

ts-node src/app.js ./fishTankFolder

Chris Moesel (Nov 14 2019 at 16:09):

But the actual CLI code (app.js) isn't merged to master yet, so you'd need to do this all on the basic-cli branch. If you wait an hour or two, I think that branch will get through review and be merged. Furthermore, I expect we'll have a way to use it that doesn't require ts-node.

Grahame Grieve (Nov 24 2019 at 06:03):

@Chris Moesel @Mark Kramer I caught some of the FISH presentation at DevDays - thanks

Grahame Grieve (Nov 24 2019 at 06:04):

I have several questions, but... why don't we use words for the keywords that are more aligned to the documentation in the specification. e.g. "from"... I would like that to the "boundTo" - it's both more specific and also directly connected to the standard

Mark Kramer (Nov 25 2019 at 13:36):

@Grahame Grieve - It's possible, and I'm not married to any of the reserved words. I feel that the readability is slightly better with "Element X (selected) _from_ ValueSet Y", rather than "Element X (is) _bound to_ ValueSet Y". Currently, there are no camel-case reserved words. If you want to review the list of Keywords and reserved words, and suggest alternatives, you are very welcome to do so.

PS - We could also try to appeal to the ADL/OpenEHR crowd using "matches" instead of "only" when it comes to restricting types :grinning_face_with_smiling_eyes:

John Moehrke (Nov 25 2019 at 15:44):

I get the interest in using the same words... but, it would seem that shorthand is for a different audience, therefore it should appeal to that audience and have a clear technical mapping to core FHIR structure Definition. right?

Grahame Grieve (Nov 25 2019 at 16:05):

that's what I think. I think that "from" is ambiguous. is that a requirements source thing?

Grahame Grieve (Nov 25 2019 at 16:05):

I'll look at the whole list

Chris Moesel (Nov 25 2019 at 16:44):

I think from mainly just comes from natural language. Perhaps it's the crew I hang around with -- but I usually hear people use phrases like "pick a code from this value set" or "the value should be a code from the US Core Race value set".

This terminology ("from" a value set) is also used in the Terminologies documentation, so there is some precedence. For example, it's pretty prominent in the description of strengths (emphasis mine):

required: To be conformant, the concept in this element SHALL be from the specified value set.
extensible: To be conformant, the concept in this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
preferred: Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
example: Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.

Of course, there are also references to binding all over the place -- so it really is a question of what Shorthand users would prefer and/or find most natural.

Chris Moesel (Nov 25 2019 at 16:46):

That said, I think @Grahame Grieve's point is a good one. If we do diverge from keywords that have already been established in the FHIR spec or community, we should have a good reason for doing so. Let's not just introduce new keywords for the heck of it!

Mark Kramer (Nov 26 2019 at 20:51):

I want to let every know that we have established a separate stream for FHIR Shorthand # shorthand. Let's conduct future discussions there.

Ward Weistra (Nov 27 2019 at 16:47):

That's #shorthand

Last updated: Apr 12 2022 at 19:14 UTC