# Measure Repository Service - Quality Measure Implementation Guide v2.0.0-ballot

## Measure Repository Service

### Overview

This page documents the use cases and conformance expectations of a measure repository service to support authoring, publishing, and distribution of FHIR-based quality measure specifications as described in this implementation guide.

The measure repository service described here is a specific case of the more general knowledge repository service and is built upon operations and capabilities defined in the [Canonical Resource Management Infrastructure Implementation Guide (CRMI IG)](http://hl7.org/fhir/uv/crmi).

This implementation guide is not prescriptive about authentication or authorization, but strongly recommends that these capabilities be addressed through standard mechanisms, as described in [FHIR standard security mechanisms](https://www.hl7.org/fhir/security.html).

### Measure and Library Management

Quality measures (QMs) and libraries are specific types of knowledge artifacts, and share common attributes with other knowledge artifact types and are expected to conform to general artifact management principles defined in [CRMI Knowledge Artifact Management](). This section describes how general artifact management is applied to quality measures and libraries.

#### Lifecycle

Quality Measure and libraries following a general, high-level workflow for content development: draft, active, and retired as defined in [CRMI Artifact Lifecycle]()

#### Identity

Measure and library identity directly follows [CRMI Artifact Identity guidance]()

#### Versioning

As a best practice, measure and library versions SHOULD follow semantic versioning. This approach is summarized in [CRMI Artifact Versioning.]()

#### Metadata

In addition to identity, lifecycle, and versioning, measure and libraries typically have additional metadata such as descriptive content, documentation, justification, and source. This is especially true of **published** measures and libraries, which make this type of information available to enable consumers to find, understand, and ultimately implement the content. In FHIR, measures and libraries generally follow the [Metadata Resource](https://hl7.org/fhir/clinicalreasoning-knowledge-artifact-representation.html#metadata) pattern.

### Shareable Measure Repository

The ShareableMeasureRepository capability statement defines the minimum expectations for a measure repository that provides basic access to shareable measure content. It describes the minimum required functionality for sharing FHIR-based measure content.

A ShareableMeasureRepository:

1. SHALL Represent basic Library information, as specified by the[CRMIShareableLibrary](http://hl7.org/fhir/uv/crmi/STU1/StructureDefinition-crmi-shareablelibrary.html)profile, which includes url, identifier, version, name, title, type, status, experimental, date, publisher, contact, description, useContext, and jurisdiction.
1. For computable libraries, SHALL represent computable Library information, as specified by the[CRMIComputableLibrary](http://hl7.org/fhir/uv/crmi/STU1/StructureDefinition-crmi-computablelibrary.html)profile.
1. For executable libraries, SHALL represent executable Library information, as specified by the[ELMLibrary](http://hl7.org/fhir/uv/cql/STU2/StructureDefinition-elm-json-library.html)profile.
1. For published libraries, SHALL represent publishable Library information, as specified by the[CRMIPublishableLibrary](http://hl7.org/fhir/uv/crmi/STU1/StructureDefinition-crmi-publishablelibrary.html)profile.
1. SHALL Represent basic Measure information, as specified by the[CRMIShareableMeasure](http://hl7.org/fhir/uv/crmi/STU1/StructureDefinition-crmi-shareablemeasure.html)profile, which includes url, identifier, version, name, title, type, status, experimental, date, publisher, contact, description, useContext, and jurisdiction.
1. For computable measures, SHALL represent computable Measure information, as specified by the[CQMComputableMeasure](StructureDefinition-cqm-computablemeasure.md)profile.
1. For published measures, SHALL represent publishable Measure information, as specified by the[CQMPublishableMeasure](StructureDefinition-cqm-publishablemeasure.md)profile.

The CQMShareableMeasureRepository capability statement captures these requirements formally.

### Publishable Measure Repository

The PublishableMeasureRepository capability statement expresses additional functionality that is provided in support of providing published FHIR quality measures including additional searching and packaging capabilities.

A PublishableMeasureRepository:

1. SHALL support library packaging: Library/$package operation
1. SHALL support library requirements analysis: Library/$data-requirements operation
1. SHALL support measure packaging: Measure/$package operation
1. SHALL support measure requirements analysis: Measure/$data-requirements operation
1. SHOULD support measure search using additional publishable metadata
1. SHOULD support library search using additional publishable metadata
1. SHOULD support minimum measure write capability (Publish, Retire, Archive)
1. SHOULD support minimum library write capability (Publish, Retire, Archive)

The CQMPublishableMeasureRepository capability statement captures these requirements formally.

##### MeasureReports

A PublishableMeasureRepository:

1. MAY support representation of test cases using the[CQMTestCase](StructureDefinition-cqm-testcase.md)profile.
1. MAY support retrieval of test cases by server-specific id through the MeasureReport/read interaction
1. MAY support searching of test cases by the measure search parameter
1. MAY support including test cases in measure packages.
1. MAY support test case packaging:[MeasureReport/$cqm.package](OperationDefinition-cqm-package.md)operation

### Authoring Measure Repository

The AuthoringMeasureRepository capability statement defines additional capabilities that are required to support content authoring workflows in a shared environment. For systems that do not exchange in progress content, or support external review/approval processes, these capabilities are not required to be exposed.

For libraries and measures, an AuthoringMeasureRepository:

1. SHALL support**Submit**: Post a new library in draft status
1. SHALL support**Revise**: Update an existing library in draft status
1. SHALL support**Draft**: Draft a new version of an existing library in active status
1. SHALL support**Release**: Update an existing draft library to active
1. SHOULD support**Clone**: Clone a new library based on the contents of an existing library(regardless of status)
1. SHOULD support**Withdraw**: Delete a draft library
1. SHOULD support**Review**: Review and provide comments on an existing library (regardless of status)
1. SHOULD support**Approve**: Approve and provide comments on an existing library (regardless of status)

The [CRMIAuthoringArtifactRepository](http://hl7.org/fhir/uv/crmi/STU1/CapabilityStatement-crmi-authoring-artifact-repository.html) capability statement captures these requirements formally, while the following sections provide a narrative description of them.

