Hook for implicit ID generation

[jgsuess]

Our project would like to reduce the onus of creating and explicitly setting the ID value, and we are aware that Sushi sets defaults, but uses the Name: as the value. We would like to

• use kebab-case
• have postfixes derived from
• Sushi constructs (e.g. Profile being -pr) for most types
• or special conditions on instances (e.g. Example being -ex for instances with Usage: #example)

We would also like to enforce that the filenames are matching these identifiers (a type of linting).

Since this is pretty specific and opinionated, we would like a hook that sushi will invoke with TS code that is committed along with the project.

Could you:

• point us to the respective entrypoint in the source where the current direct derivation is happening, so we can change it experimentally?
• comment on this proposal?

Alternatively, and more comfortably, we could see a facility where these factors are driven by a table like the one below and a set of clauses in FHIRPath.

Below is some of our thinking.

Moniker Extension Strategy:

Primary Table – FSH Declarations:

Maps FSH declarations (e.g., Profile, Extension, Instance) to short, lowercase monikers (e.g., pro, ext, ins).
See the table below:

Declaration	Creates…	Data Type	Moniker
Alias	An alias for a URL or OID	expression	ali
CodeSystem	A code system	name	cs
Extension	An extension	name	ext
Instance	An instance	id	ins
Invariant	An invariant	id	inv
Logical	A logical model	name	log
Mapping	A mapping	id	map
Profile	A profile	name	pro
Resource	A custom resource	name	res
RuleSet	A set of rules that can be reused	name	rs
ValueSet	A value set	name	vs

Secondary Table – Usage-Based Instance Types:

For Instance declarations, a secondary extensible table assigns monikers based on the Usage attribute or known patterns.
Examples include:

• SearchParameter with Usage = #definition → sp
• Any instance with Usage = #example → ex
• This table is designed to be extensible to accommodate new instance types of interest.

Rationale:

• Disambiguation:
  Assigning unique, descriptive IDs and filenames helps human users quickly identify the purpose and type of each file, especially in large projects with many similarly named resources.

• Brevity and Clarity:
  The usage-based moniker system ensures that identifiers remain concise while still conveying meaningful information about the resource type or purpose.

• Extensibility:
  The secondary table allows for future growth and adaptation to new FHIR resource types or project-specific conventions.

[cmoesel]

Hi @jgsuess. I apologize for the extremely late reply on this. It somehow got past my radar!

We experimented with the idea of SUSHI "plugins" back in 2022 (in fact, the plugins branch is still available). In the end, we decided not to move forward with it because we and others in the FHIR community had security concerns. Since FHIR offers an auto-build server with self-registration, support for project-defined executable hooks would basically allow people to inject arbitrary code that gets executed server-side. Although there are mitigation strategies for such things, the risk/reward tradeoff was deemed insufficient.

Your other idea about allowing user-defined tables to define the strategy for assigning ids is an interesting one -- and doesn't carry the same security concerns as code injection would. This would also allow for SUSHI to provide a few pre-set strategies that people could choose from (if they didn't want to define their own).

If this is something you're still interested in and if you have the resources to work on it, I think we'd be glad to accept a pull request that implements something like that.