Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Agenda Outline

Agenda Item

Meeting Minutes from Discussion

Decision Link(if not child)
Management Minutes Approval


Review conventions

Naming conventions for artifacts throughout the IG:

FIlenames: <ResourceType>-<id>.<format>

Canonical Resources (Profiles, CodeSystems, ValueSets, OperationDefinitions, CapabilityStatements): url should be <base canonical>/StructureDefinition/crmi-<resource-id>

name should be CRMI<pascal-cased-profile-id>

title should be CRMI <title-cased-profile-id>

Extensions: These will be defined in the extensions pack so will follow the convention there

OperationDefinitions: Canonical resources conventions + code should be $<ig-code>.<operation-code> e.g. $crmi.release

Add a section in this IG documenting these conventions and suggesting they be adopted for other IGs (we might want to discuss this with FHIR-I)


Review status

FHIR-40922 - Define a standard extension for CQL version TRIAGED

QM IG Trackers to apply to CRMI:

FHIR-39821 - Question on Conformance Requirement 4.9 RESOLVED - CHANGE REQUIRED

FHIR-40520 - Add a date to artifactComment RESOLVED - CHANGE REQUIRED

FHIR-40509 - Define an extension on canonical to specify resource type WAITING FOR INPUT

FHIR-40487 - Surface translator version used in Libraries WAITING FOR INPUT

In addition to the canonical resource type extension, should we define, or locate, a $resolve operation or other general type search? On one of the reference implementations, you can search on url and version at the root?


Review proposed $package

Next steps are to provide examples for each of:

  • Getting an implementation guide package as a bundle
  • Getting an implementation guide package as an npm package
  • Getting an artifact package as a bundle
  • Posting an implementation guide package as an npm package (tarball)

Q: Is this in addition to or a replacement of $packge defined in QM IG?

A: Target is to reflect the same changes in QM IG STU4 (about to be published) and then QM IG STU5 (balloting January 24) would refactor to use the CRMI IG

Q: Is the intent of package to be "pre-computed" or provide dynamic content?

A: The specification should support both, it should be an implementation decision about whether and how to cache the results of the computation.

Could potentially make the presence of complete dependency information part of the "computable" profiles?


 Next agenda

 Adjourned at