...
Agenda Outline | Agenda Item | Meeting Minutes from Discussion | Decision Link(if not child) | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Management | Minutes Approval | ||||||||||
| Methodology | 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
QM IG Trackers to apply to CRMI:
| 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 |
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? | ||||||||||
| Management | Next agenda
| ||||||||||
| Adjournment | Adjourned at |
...