CRMI-feedback.md

Internal

• Convert back to use sushi (the longer we wait, the more difficult it will be)
  • Create a branch off master where FSH was removed (e.g. master-fsh)
  • Work on parity with IG Publisher in this branch
  • Promote master-fsh to master

Issues

• Add support to definitional resource types that are not currently canonical in R4:
  • In the definitional resource:
    • Add extensions: canonical-url, canonical-version (these already exist as: valueUri, valueString)
    • Add searchParam: url -> extension[canonical-url], version -> extension[canonical-version]
  • In any referencing resources:
    • Add extensions valueUri as needed (e.g. ActivityDefintion.extension[productDefinition])
    • Add invariant (e.g. can't have both ActivityDefinition.productReference and extension[productDefinition])
    • Can enhance/replace existing searchParam as needed?
      • if yes, enhance as needed (e.g. ActivityDefinition product to use Reference and extension[productDefinition])
      • if no, add new SearchParam (e.g. ActivityDefintion productDefinition)
• Align Artifact Library with the results of $package operation
• Align the concepts of "CRMI scope" and "FHIR Package (NPM) scope"
• Align artifact url guidance (e.g. is it based on id or name; if id, what is the CRMI guidance around name)?
• Confirm guidance around naming of operations (should they include a prefix, crmi.package or not?)
• Add CRMI operation profiles (canonical, versionable, manifestible, etc)
• Align CRMI operations to use CRMI operation profiles
• Align around using FHIR/REST for authoring lifecycle
  • Is this in tension to using IG Publisher project -based content (e.g. in git)?
  • Do we support both FHIR Package and FHIR REST APIs for publishing content?
• Add guidance on immutability of resources
  • Default guidance (e.g. all except id and meta?)
  • ResourceType -specific guidance (is this needed?)
• Add guidance on how to deal with non-canonical, non-definitional resources -- e.g. test scenarios and examples