This capability statement describes the requirements for systems receiving CGM data via the $submit-cgm-bundle operation.

Any CGM Data Receiver SHALL populate its /metadata response to ensure that CapabilityStatement.instantiates includes "http://hl7.org/fhir/uv/cgm/CapabilityStatement/cgm-data-receiver".

This operation is used to submit CGM data. The input is a Bundle of type 'transaction' containing CGM data (summary reports, sensor readings, etc.) and the output is a Bundle of type 'transaction-response' containing processing results for each submitted resource, or an OperationOutcome resource for overall failures.

The response Bundle will:

• Maintain the same order as the submission Bundle
• Include status and location information for each successfully processed entry
• Include error details for any entries that could not be processed

Servers SHOULD support conditional create requests and persist client-supplied identifiers. Servers SHALL document in their developer documentation:

• Which search parameters can be used in conditional create requests
• How client-supplied identifiers are handled
• Any deduplication strategies employed

Once a Data Submitter is connected to the EHR, it can POST CGM data as a transaction Bundle to [base]/$submit-cgm-bundle.

The Bundle entry array includes any combination of

• CGM Summary PDF Reports (Profile, Example)
• CGM Summary Observation (Profile, Example)
  • Mean Glucose (Mass per Volume) (Profile, Example)
  • Mean Glucose (Moles per Volume) (Profile, Example)
  • Times in Ranges (Profile, Example)
  • Glucose Management Index (Profile, Example)
  • Coefficient of Variations (Profile, Example)
  • Sensor Days of Wear (Profile, Example)
  • Sensor Active Percentage (Profile, Example)
• CGM Devices (Profile, Example)
• CGM Sensor Readings (Mass per Volume) (Profile, Example)
• CGM Sensor Readings (Moles per Volume) (Profile, Example)

The Data Receiver can expose a standing order indicating:

• What data a Data Submitter should include in each CGM Data Submission Bundle
• How often a Data Submitter should submit CGM data
• What lookback period should each submission cover

Guiding Data Submission

This standing order is modeled as a FHIR ServiceRequest resource, which Data Submitters can query to guide their future submissions. The standing order specifyies the patient, the type of data to be submitted, and the desired frequency of submission.

DataSubmissionSchedule

The DataSubmissionSchedule extension contains:

• submissionPeriod: Quantity with unit d for days, wk for weeks, mo for months, or a for years. This indicates how often the data should be submitted.
• submissionDataProfile (1..*): canonical reference to FHIR profiles that represent the types of data to be submitted according to the specified schedule.
• lookbackPeriod (optional): Quantity with unit d for days, wk for weeks, mo for months, or a for years. This indicates the period of time the data submission should cover.

Multiple DataSubmissionSchedule extensions can be included in a single DataSubmissionRequest resource if the Data Recipient prefers a different schedule for different data types.

It's important to note that submissions can also be manually triggered by a patient or provider within an app. For example, if there is an upcoming appointment, the provider can click a button to manually trigger submission of the most up-to-date results. Out-of-band communication between the app developer and the clinical provider system can also be used to establish preferred submission schedules.

A continuous glucose monitoring (CGM) sensor device. This corresponds to the CGM sensor, not a reader or app used to capture or transmit the data.

A continuous glucose monitoring (CGM) sensor reading represented in mass units.

A continuous glucose monitoring (CGM) sensor reading represented in molar units.

An observation representing a summary of continuous glucose monitoring (CGM) data.

A PDF report containing a summary of continuous glucose monitoring (CGM) data.

An observation representing the times in various ranges from a continuous glucose monitoring (CGM) summary. Value: Percent of time, with at least two decimal places of precision.

The Coefficient of Variation (CV) value from a continuous glucose monitoring (CGM) summary.

A base profile for standing orders that indicate data submission requirements. This profile can be used as-is for general data submissions or inherited by more specific data submission profiles.

Key aspects of this profile:

• Specifies what data should be included in each submission
• Defines how often data should be submitted
• Indicates the lookback period each submission should cover

This profile uses the DataSubmissionSchedule extension to capture detailed submission requirements.

The number of days the continuous glucose monitoring (CGM) device was worn during the reporting period.

The Glucose Management Indicator (GMI) value from a continuous glucose monitoring (CGM) summary.

The mean glucose value from a continuous glucose monitoring (CGM) summary, represented in mass units.

The mean glucose value from a continuous glucose monitoring (CGM) summary, represented in molar units.

The percentage of time the continuous glucose monitoring (CGM) sensor was active during the reporting period.

Schedule and type of data to be submitted

Temporary code system for CGM summary observations.

Codes to identify content associated with this IG

Mapping concepts from the CGM Summary code system to LOINC codes.

This example represents a standing order for continuous glucose monitoring (CGM) data submission. It specifies an order to submit data about Patient 123 once every two weeks, with each data submission including a summary of the CGM data and a PDF report of the CGM summary. This ensures the patient's CGM data is routinely available for clinical review.