Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set version based on sushi-config.yaml in FSHOnly projects #1456

Merged
merged 2 commits into from
Apr 18, 2024

Conversation

jafeltra
Copy link
Collaborator

Fixes #1380

This PR adds back support for using the version specified in sushi-config.yaml in Structure Definitions, Value Sets, and Code Systems as a default value in FSH Only projects. If the version is set with a rule, that will overwrite the version from the config file. This is only done in the case where FSHOnly is set to true in the config file because the IG Publisher will set the version when it is used.

Because status is already set using the value in sushi-config.yaml as a default in all projects, this should restore the functionality that was removed in SUSHI 3.x. As a reference, I was looking at PR #1143, which removed this functionality originally.

@jafeltra jafeltra removed the request for review from mint-thompson April 16, 2024 17:33
Copy link
Member

@cmoesel cmoesel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good and works well. I wish we had thought to do this for FSHOnly back when we removed it for better alignment with the IG Publisher!

As I did this, I had one thought for us to consider. If someone defines an Instance with #definition usage, and the resource they are creating an instance of has status and/or version, should we also apply it there for FSHOnly projects? I don't think SUSHI 2.x did that, so this would be new. We auto set the url in these cases now, so it might make sense to auto-set status and version -- but I can't decide for sure. What do you think?

This is approved either way, because I think if we decide to propagate those into instances, it should be a separate PR anyway.

@jafeltra
Copy link
Collaborator Author

jafeltra commented Apr 17, 2024

We auto set the url in these cases now, so it might make sense to auto-set status and version -- but I can't decide for sure. What do you think?

Oh I think I like that idea, especially since status is usually (always?) required. Defaulting status might make sense to do for all projects for consistency with the other exports, but version might be best for FSHOnly projects.

I was trying things out and happened to make an instance of a CapabilityStatement, which also has fhirVersion with cardinality 1..1. I wonder if we should try to include that from the configuration if there's a fhirVersion element.

@jafeltra
Copy link
Collaborator Author

I created #1457 to separately consider adding defaults for other values.

@jafeltra jafeltra merged commit 28c325f into master Apr 18, 2024
14 checks passed
@jafeltra jafeltra deleted the set-version-in-fshonly branch April 18, 2024 15:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support propagation of version, status, publisher to FSH-Only IGs
2 participants