FHIR Chat · Resource filename prefix · shorthand

Stream: shorthand

Topic: Resource filename prefix

Jose Costa Teixeira (Aug 04 2020 at 12:46):

Can we add an option to NOT add the resource type as a prefix to the file name?

Jose Costa Teixeira (Aug 04 2020 at 12:49):

or (another alternative that would better for me, not sure others) instead of file name being {type}-{id}.json, make it {type}/{id}.json and create the folder?

Jose Costa Teixeira (Aug 04 2020 at 13:00):

or even better, make it {profile}/{id}.json and create the folder?

Chris Moesel (Aug 04 2020 at 14:00):

At one time (and this may have been a long time ago), we encountered IG Publisher issues naming the files in any other way besides {type}-{id}.json. I actually had a note to look into this today (because I also wanted to explore other naming approaches) -- so I'll do that. Assuming no issues w/ the publisher, allowing user configuration of the naming scheme seems feasible -- so we can likely add it to the backlog.

Jose Costa Teixeira (Aug 04 2020 at 14:29):

note that my last suggestion is dangerous
{profile}/{id}.json would only work if you add the examples/{profile} to the ig parameters

Jose Costa Teixeira (Aug 04 2020 at 14:30):

Depending on the IGs, this may be very handy if you have several profiles on the same resource type, all those profiles being functionally different.

Jose Costa Teixeira (Aug 04 2020 at 14:31):

e.g. profiles on Composition - I don't want to have all my document examples in one single folder - rather one per document type

Jose Costa Teixeira (Aug 04 2020 at 14:36):

for reference, @Chris Moesel I did not test all of these nor look at the code, but judging from an error message, when you refer to Type/id, the Publisher wil look for these files:

{type}-{id}
{type}/{id}
{id}.{type}
{id}

Jose Costa Teixeira (Aug 04 2020 at 14:36):

.json/xml

Chris Moesel (Aug 04 2020 at 17:13):

Jose Costa Teixeira said:

for reference, Chris Moesel I did not test all of these nor look at the code, but judging from an error message, when you refer to Type/id, the Publisher wil look for these files:

{type}-{id}
{type}/{id}
{id}.{type}
{id}

I remember seeing that in the past too. And I remember trying some of those other representations and it failing miserably. I'll try some stuff out to see what happens. Templates are in the mix now, which is something that didn't exist last time I tried this.

Chris Moesel (Aug 05 2020 at 00:42):

OK. I've looked into the allowed filenames. For an extension definition w/ id MyExtension, this is the list of paths the IG Publisher says it looks for:

• StructureDefinition-MyExtension.xml
• StructureDefinition-MyExtension.json
• MyExtension.StructureDefinition.xml
• StructureDefinition/MyExtension.xml
• StructureDefinition/MyExtension.json
• MyExtension.xml
• MyExtension.json
• (and lowercase resource name variants)

I've confirmed each of these (except lowercase variants). What surprised me is that you'll note that MyExtension.StructureDefinition.xml is listed, but not MyExtension.StructureDefinition.json. Sure enough, the .xml one works and the .json one does not! I also experimented w/ using arbitrary prefixes (fail), postfixes (fail), and sub-folders (fail). So given that SUSHI exports JSON, the only choices we can give you (that will still work with IG Publisher) are:

• StructureDefinition-MyExtension.json
• StructureDefinition/MyExtension.json
• MyExtension.json

Personally, I don't recommend the last (MyExtension.json) since it is possible for an IG to duplicate ids (as long as the type is different) -- so file paths based on id alone could cause problems. That leaves us with StructureDefinition-MyExtension.json and StructureDefinition/MyExtension.json. Would others find value in SUSHI providing users the options of choosing between those two?

Jose Costa Teixeira (Aug 05 2020 at 05:40):

Chris Moesel said:

Personally, I don't recommend the last (MyExtension.json) since it is possible for an IG to duplicate ids (as long as the type is different) -- so file paths based on id alone could cause problems. That leaves us with StructureDefinition-MyExtension.json and StructureDefinition/MyExtension.json. Would others find value in SUSHI providing users the options of choosing between those two?

This is a big jump. The case for myextension.json is to have more customizable folder structures. Leaving Composition aside, here are some examples where we'd best served by not having the StructureDefinition (at least in examples):

• MedicationPrescriptions and MedicationAdministrationOrders are both profiles on MedicationRequest
• Addiction, PreExistingCondition and Condition are profiles on Condition

In these cases, the example filenames would be e.g. addiction-patientx-alcohol, and not condition-patientx-alcoholaddiction. Or addiction/patientx-alcohol

Jose Costa Teixeira (Aug 06 2020 at 06:30):

it wouldn't hurt to have in the config.yaml or somewhere a "filenames" pattern that can have a default value.
This:
filenames = {type}-{id}
(which is default)
or
filenames = {type}/{id}
or
filenames = {profileName}/{id}
(this one can be avoided with the filename override function i just suggested

Last updated: Apr 12 2022 at 19:14 UTC