Page History

...

1. Provide a place for universal specification of Shareable/Publishable/Computable/Executable profiles that R4 IGs can use
   1. These profiles are currently defined in R5 as the harmonization of all the profiles in various R4 IGs (CPG, QM, eCR, etc)
   2. The definitions in R5 will be moved here (pending publication tooling support for that) and removed from the base spec until they are solidifed in this IG
      1. NOTE: This might make the CRMI IG a multi-version IG (R4 and R5)
   3. This would include profiles as appropriate for any CanonicalResource
      1. StructureDefinition, StructureMap
      2. ValueSet, CodeSystem, NamingSystem, ConceptMap
      3. Questionnaire, ActivityDefinition, PlanDefinition, Library, Measure
      4. ObservationDefinition, SpecimenDefinition, MedicationKnowledge, etc... (These are stretch goals)
   4. Narrative representation? Liquid templates for these (although the publisher will do this for most of these already (StructureDefinition for example)
2. Provide a space for universally applicable guidance and extensions in support of content management and the content development lifecycle
   1. Using CQL
   2. Canonical versioning schemes/support
   3. Best practices for canonical resource management
   4. Best practices for versioning and dependencies, in particular terminology (the version manifest)
   5. Guidance and discussion about FHIR packages in general and how we are making use of that mechanism for artifact packaging and distribution
   6. Provide resource-level generalizations of artifact evaluation operations
      1. $data-requirements
      2. $apply? - CPG
      3. $evaluate
      4. $evaluate-measure? - QM
      5. $care-gaps? - QM
      6. $cql
3. Support packaging for artifacts (via the $data-requirements and $package operations)
   1. Detail for each resource type what elements are considered "dependencies" and what elements are considered "components"
   2. Define behavior when satisfying a capability request (e.g. request for an executable ValueSet when the server only has a computable ValueSet. The server could error, or the server could perform an expansion to compute the executable)
   3. Include postman collections for test cases for the services
   4. Guidance for clients to make use of the $data-requirements operation to determine what resources need to be downloaded in order to evaluate a particular artifact
4. Support services related to content management
   1. Artifact Repository
      1. Primary use case is delivery to consumers
      2. Secondary use case is for artifact repositories to share information between them
         1. Specifically, support for the notion of an international publisher, with national publishers that subscribe to updates from the international repository
      3. Authoring repository
         1. Specifically the more involved operation definitions that are part of authoring repository as opposed to the simpler versions that would only be in an artifact repository
            1. Artifact repository focused on sharing/distributing content
            2. Authoring repository participates with the client in the authoring process and so takes some of the business logic associated with content development as part of the implementation of operations (such as revise/draft/release, etc.)
   2. Artifact Terminology Service
   3. Include postman and thunderclient collections for test cases for the services
5. Support authoring processes such as:
   1. Review
      1. Who did the review, when did it happen, what were the comments, where do they apply in the measure, what is the outcome of the review? 
      2. artifactComment extensions are for internal commments
      3. ArtifactAssessment comments are for external comments
   2. Approval
   3. Endorsement
6. Define a Parameters profile for common parameters
   1. manifest
   2. dataEndpoint
   3. prefetchData
   4. data
   5. terminologyEndpoint
   6. contentEndpoint
   7. Describe how that parameters profile can be used to provide common handling for these parameters

Workstreams:

1. Generalize all content to be artifact level instead of measure-specific - Bryn
2. Work out dependency tracing semantics for each resource type (so a table that shows for each resource and element what dependencies are possible to trace) - Brian Kaney
3. Build out test cases for the services - Brian Kaney
4. Finalize approach and semantics for version manifest (should it be a design-time only artifact, or should there be run-time capability? Or potentially both) - Bryn
   1. For example, if you're computable, you could still use a version manifest, but if you're executable, it implies version dependencies have all been resolved
5. Finalize authoring vs publishing repository operations - Adam