Continuous Glucose Monitoring, published by HL7 International / Orders and Observations. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/cgm/ and changes regularly. See the Directory of published versions

Home

Official URL: http://hl7.org/fhir/uv/cgm/ImplementationGuide/hl7.fhir.uv.cgm				Version: 1.0.0
IG Standards status: Trial-use			Maturity Level: 2	Computable Name: ContinuousGlucoseMonitoring

Introduction

The Continuous Glucose Monitoring Implementation Guide provides a standardized approach for sharing Continuous Glucose Monitoring (CGM) data between actors. This Implementation Guide (IG) focuses on enabling the exchange of CGM data, including high-level reports and raw glucose observations, to support collaborative glucose management. The requirements for this guide were initially developed in the Argonaut Project with input from patients, providers, CGM device vendors, app developers, and EHR systems, and later in collaboration with the HL7 Orders and Observations Work Group.

User Stories

Patient Connects a CGM App to a Provider's Electronic Health Record (EHR)

Sarah, a type 1 diabetes patient, is switching to a new doctor. She has been using a CGM device and a patient app that stores her CGM data on her phone or in an app backend server. The app supports secure health data exchange standards compatible with the CGM IG. Sarah authorizes the app to connect with her new provider's EHR, using her patient portal credentials to grant access to the phone app. The app then sends Sarah's CGM reports from the past 3 months to the new provider's EHR using FHIR, ensuring her new doctor can access her recent CGM history for informed decision-making.

Provider Connects to a Patient's CGM Data During a Patient Encounter

Dr. Johnson treats Michael, a type 2 diabetes patient struggling with glucose management. Dr. Johnson's practice uses "CloudCGM", a fictional cloud-based diabetes management platform that supports the CGM IG. Michael has a patient account in the CloudCGM platform, and a "Sharing Code" appears in his account settings. During a clinic visit, Dr. Johnson launches the CloudCGM SMART on FHIR app inside the EHR, entering the sharing code that Michael reads aloud. This process establishes a linkage between Michael's records in the two systems. CloudCGM is now able to submit data every week into Dr. Johnson's EHR, with results appearing in the native interface and easily incorporated into visit notes.

Patient Shares CGM Data with a Research Study

Dr. Patel is the principal investigator for a longitudinal research study. Participants are recruited from multiple diabetes management platforms that support the CGM IG. The study protocol allows participants to share CGM data after completing an informed consent process. For consented participants, the diabetes management platforms submit a weekly data feed to a study server under Dr. Patel's control. The standardized format and exchange protocols enable an efficient, multi-platform study focused on collecting raw glucose readings as part of the data package.

Actors

CGM Data Submitter

The data submitter is a software system that manages CGM data. It typically incorporates a patient-facing app and sometimes a clinician-facing EHR-integrated app and cloud service.

This IG also refers to Data Submitters as "apps" or "diabetes management platforms".

CGM Data Receiver

The data receiver is a software system that receives and stores the CGM data submitted by the data submitter.

This IG also refers to Data Receivers as "EHRs".

Must Support

The following Must Support (MS) expectations for system capabilities are an initial draft to guide early implementations. The spec recognizes that actor-based MS may be needed in a future release.

The MS flag requires that data submitters must be capable of sending the element, and data receivers must be able to parse it without error. While receivers must process the element, they may choose to ignore the data if it does not apply to their use case, but they must not reject a resource solely because it contains it. For supported profiles, MS elements indicate which resource types and elements a submitter needs to be capable of submitting.

Must Support Expectations for the CGM Data Submission Bundle

The CGM Data Submission Bundle profile defines resource type and Observation profile entries. They are all labeled as MS except for two pairs of Observation profiles that have molar and mass units options. However, any conformant implementation must support at least one option for each pair of options.

Nominal Workflow

1. App Authorization: The Data Submitter completes an authorization process (e.g., SMART App Launch or SMART Backend Services Authorization) to securely access the EHR system.

2. Establish EHR Patient ID: After successful authorization, the Data Submitter determines the "logical id" of the patient's Patient resource within the EHR's FHIR Server. The logical id can be discovered through authorization context (e.g., SMART's launch/patient context), through FHIR patient search, or using an out-of-band (OOB) process.

3. Learn Submission Preferences: The Data Submitter determines the EHR's CGM data submission preferences by:

a. Querying the EHR FHIR server for a specific ServiceRequest resource that contains the CGM data submission standing order or

b. Learning the submission schedule through an out-of-band process.

1. Submission Triggers: The Data Submitter determines when to submit data by:

a. Scheduled Submission Interval: Based on the standing order obtained from the submission preferences, the Submitter initiates scheduled submissions of CGM data at the specified intervals.

b. One-Time Orders: The Submitter may also support manual triggers, such as an in-app button, allowing users to initiate on-demand submissions of CGM data.

1. Prepare FHIR Bundle: When a submission is triggered (either scheduled or a one-time order), the Data Submitter prepares a FHIR Bundle containing the relevant CGM data, conforming to the specified profiles and requirements.

2. POST Bundle to EHR: The Data Submitter issues a POST request to send the prepared FHIR Bundle to the EHR.

This workflow ensures that the Data Submitter is authorized, respects the EHR's submission preferences, and securely transmits CGM data in a standardized format. The combination of scheduled submissions and manual triggers provides flexibility, ensuring that the EHR receives up-to-date CGM data as needed.

Establishing Connections

Patient App to EHR

In this workflow, a patient-facing app connects directly to the EHR using the EHR's authorization capabilities (e.g., SMART on FHIR). The app acts as a client and undergoes an authorization process, where the patient approves the app to access their EHR, granting it write scopes. This process ensures that both the patient and the source EHR system agree to allow the app to write data using an appropriate access token.

Technical Details

• If SMART on FHIR is being used, relevant scopes include:
  • launch/patient: patient app will already know who the patient is, and only requires a corresponding ID from the EHR
  • offline_access: establish persistent access for long-term submissions
  • Data Scopes:
    • patient/Patient.r: it may still be desirable to cross-reference patient demographics, e.g., to confirm a match
    • patient/ServiceRequest.rs?code=cgm-data-submission-standing-order: helps the app learn the EHR's data submission preferences
    • patient/DiagnosticReport.cu?category=LAB: submit a summary report
    • patient/Observation.cu?category=laboratory: submit a summary observation or sensor reading
    • patient/Device.cu: submit device details associated with a sensor reading

Provider App to EHR

For provider-facing apps, the app can be integrated directly into the EHR's user interface using the SMART on FHIR EHR launch workflow. EHRs widely support this workflow, allowing apps to run within the EHR's screen real estate. The EHR-integrated app might represent a device manufacturer or an independent diabetes management platform. The app can retrieve the patient's ID and demographics from the EHR in real-time using the FHIR Patient API.

In-band or out-of-band processes can correlate the patient with a data record in the app's backend system.

Examples include but are not limited to:

1. A patient-facing companion app connects to the EHR using SMART on FHIR as described in "Patient App to EHR" above, establishing a record linkage via API.
2. A patient-facing companion app sends a push notification to the patient, asking if they want to establish a record linkage.
3. A patient-facing companion app generates a sign-up code that the provider enters into the EHR.
4. The provider has an appropriate data-sharing agreement with the app, allowing the app to match its patient list against EHR-sourced demographics.

Technical Details

• SMART on FHIR scopes that enable this scenario include:
  • launch/patient at linkage time
  • If using patient-level authorization at submission time
    • "Data Scopes" listed above
    • offline_access
  • If using user-level authorization at submission time
    • "Data Scopes" listed above, with the level of user/
    • offline_access
  • If using system-level authorization at submission time
    • "Data Scopes" listed above, with the level of system/
    • No need for offline_access because short-lived access tokens are available at any time via client credentials grant

CGM Data Submission: Bundles

☛ See Example Bundle

☛ See Full Data Profile

☛ See $submit-cgm-bundle Operation Definition

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 Indicator (Profile, Example)
  • Coefficient of Variation (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)

Note: Unlike standard FHIR transactions, where servers must process all entries as a single unit, the $submit-cgm-bundle operation allows servers to selectively accept and persist only a subset of the submitted resources.

Technical Details

• CGM Data Submitters SHALL:
  1. POST a CGM Data Submission Bundle to [base]/$submit-cgm-bundle
• CGM Data Receivers:
  • SHALL advertise support for CGM Data Submission by including http://hl7.org/fhir/uv/cgm/CapabilityStatement/cgm-data-receiver in their CapabilityStatement.instantiates
  • SHALL Support the $submit-cgm-bundle operation at the server level
  • SHALL include a status code for each entry in the response Bundle, indicating whether the entry was accepted
  • MAY choose to store only a subset of resources in a submitted bundle
  • SHOULD ensure that accepted submissions are available for read/search immediately after submission, but MAY subject these submissions to additional ingestion workflow steps
  • MAY respond with an HTTP status code 429 (Too Many Requests) if a client is submitting data too frequently
  • SHALL document their support for conditional create operations in their developer documentation, including:
    • Whether conditional create requests are supported
    • Which search parameters can be used in conditional create requests
    • How client-supplied identifiers are handled
    • Any deduplication strategies employed
  • SHOULD implement strict validation and allow-listing rules for incoming $submit-cgm-bundle transaction Bundles, including, but not limited to:
    • Permitting only POST operations for resources.
    • Allowing only CGM-relevant resource types (e.g., Observation, Device, Patient, DiagnosticReport, ServiceRequest).
    • Ensuring that all submitted resources pertain to the patient context established during authorization.
    • Rejecting bundles that contain disallowed operations or resource types.

    Warning: Accepting and processing arbitrary transaction Bundles without appropriate validation presents a security risk. Implementers must carefully consider the operations and resource types they will accept.

Handling Duplicate Submissions

When submitting CGM data, there are two complementary approaches for handling potential duplicates:

1. Client-Controlled Deduplication With Conditional Create
   • Clients MAY include ifNoneExist elements in Bundle.entry.request
   • Clients MAY adopt any strategy for generating Identifiers, including strategies to create identifiers based on the instance data deterministically.
   • Example of Bundle.entry.request.ifNoneExist: identifier=https://client.example.org|123
   • Servers SHOULD support conditional create requests
   • Servers SHOULD persist client-supplied identifiers to support this pattern
   • When a server supports conditional creates, it:
     • SHALL document which search parameters can be used
     • SHALL document how client-supplied identifiers are handled
     • SHALL respond according to the FHIR Conditional Create specification:
       • 201 (Created) if the resource was created
       • 200 (OK) if there was one match that prevented creation, with the location header populated
       • 412 (Precondition Failed) if multiple matches were found
   • When a server does not support conditional creates, it:
     • SHOULD NOT create resources for Bundle.entry elements that have the ifNoneExist element and, for each of these entries, respond with a status 400 in the response Bundle.
     • SHOULD create resources for other Bundle.entry elements according to other applicable rules.
2. Server-Side Deduplication
   • Servers MAY implement additional deduplication logic
   • When duplicates are detected, servers SHOULD either:
     • Return a 200 OK status indicating the submission was processed but not stored
     • Return a 201 Created status with a location header pointing to the existing resource
   • Servers SHALL document their deduplication strategy in their developer documentation

CGM Data Submission: Standing Orders

☛ See Example Order ("Send a summary every two weeks")

☛ See Full Data Profile

The Data Receiver can expose a standing order indicating:

• What data a Data Submitter should include in each CGM Data Submission Bundle
• How often should a Data Submitter 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 specifies the patient, the type of data to be submitted, and the frequency of submission.

DataSubmissionSchedule

The DataSubmissionSchedule extension contains:

• submissionPeriod: Quantity, with units bound to the UnitsOfTime value set (allowing s, min, h, d, wk, mo, a) indicating how often the data should be submitted (e.g., every 2 weeks, every month).
• 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 units bound to the UnitsOfTime value set (allowing s, min, h, d, wk, mo, a) indicating the period of time the data submission should cover (e.g., past 30 days, past 3 months).

While the value set supports granular units like seconds, minutes, and hours, CGM data submission schedules typically involve longer durations such as days, weeks, or months. Multiple DataSubmissionSchedule extensions can be included in a single DataSubmissionRequest resource if the Data Recipient prefers a different schedule for different data types.

Out-of-band communication between the app developer and the clinical provider system can also be used to establish preferred submission schedules. Note that a patient or provider can also manually trigger a one-time submission within an app, and the CGM Data Submission One-Time Order profile can be used for these on-demand data requests.

Technical Details

• CGM Submitters SHOULD respect the Receivers' submission preferences
• CGM Receivers MAY reject:
  • An entire submission Bundle (e.g., if the frequency of submissions is too high)
  • Any subset of a submission Bundle (as documented above)

CGM Data Submission: One-Time Orders

The mechanism for transmitting one-time orders from EHR to CGM Data Submitter is left out-of-band in this version of the specification. Implementation approaches may include direct API calls triggered by automated logic or explicit user actions. CGM Data Receivers and Submitters SHOULD document their supported out-of-band mechanisms in their developer documentation. Future versions may provide an in-band option based on implementation experience.

☛ See Example Order ("Request data for all of 2024")

☛ See Example Order ("Request data for last 30 days")

☛ See Full Data Profile

The Data Receiver can expose a one-time order indicating:

• What data a Data Submitter should include in the CGM Data Submission Bundle
• The absolute time period for data collection

Guiding Data Submission

Like the CGM Data Submission Standing Order, this one-time order is modeled as a FHIR ServiceRequest resource. This profile is used to request CGM data for on-demand data requests rather than ongoing scheduled submissions. For example, a provider can fetch the most up-to-date results for an upcoming appointment.

DataSubmissionOneTimeSpec

The DataSubmissionOneTimeSpec extension contains:

• timePeriod: A FHIR Period data type specifying the absolute start and end dates/times for data submission (e.g., January 1, 2024, to December 31, 2024).
• submissionDataProfile (1..*): canonical reference to FHIR profiles that represent the types of data to be submitted.

While the value set supports granular units like seconds, minutes, and hours, CGM data submission schedules typically involve longer durations such as days, weeks, or months.

Data Chunking for Large Time Periods

While one-time orders can specify any time period (including a patient's entire history), it's usually better to break large requests into meaningful chunks. Chunking makes data size manageable and summary statistics more relevant. Receivers can control chunking by sending individual requests for yearly or monthly periods where the analysis period is more meaningful.

SMART Health Links for CGM Data Sharing

The Data Submission protocol defined above enables standardized integration between CGM data sources and receiving systems, such as EHRs. However, there are situations where tight integration is not feasible or desired. SMART Health Links (SHLinks) provide a complementary method for sharing CGM data and reports among patients, caregivers, clinicians, and other authorized parties. SHLinks enable users to easily share selected subsets of CGM data as needed, providing an always-up-to-date data feed without the need for direct system integration between the sharing parties. Specific scenarios where SHLinks provide value include:

• Sharing with parties that cannot or do not integrate with the Data Submission protocol, such as schools, camps, temporary caregivers during travel, etc.
• Allowing patients granular control over what specific data is shared and with whom, beyond just provider-patient contexts.
• Providing a simple, accessible sharing method for non-technical users like patients and caregivers.
• Enabling temporary data sharing for finite needs like referrals, research studies, or consultations.

This IG ensures comprehensive interoperability that accommodates diverse real-world requirements across the CGM data-sharing landscape by defining a tightly orchestrated Data Submission API and a more loosely coupled SHLinks capability.

Actors

SHLink Creator: A system that can generate SHLinks containing CGM data and reports, acting as a SHLink Sharing Application.

SHLink Receiver: A system that can receive and process SHLinks containing CGM data and reports, acting as a SHLink Receiving Application.

Workflow

1. The SHLink Creator allows the user to select the desired CGM data and reports to share and the time period to include. Options include:
   • Data to include: CGM Summary, CGM Sensor Readings, CGM Devices
   • Time period: Past 2 weeks, 1 month, 3 months, etc.
   • Link expiration time, if any

2. The SHLink Creator generates a SHLink containing the user-selected content, encrypted with a unique key.

3. The user shares the SHLink with the intended recipient(s), who use a SHLink Receiver to stay up-to-date by periodically accessing the shared data.

4. The shared data conforms to the CGM Data Submission profiles, promoting interoperability and accessibility across different systems and platforms.

Relationship with the PHD Implementation Guide

This Implementation Guide is designed to complement the Personal Health Device Implementation Guide (PHD). PHD provides a foundational framework for mapping device-level data into FHIR, with a focus on information flows into and through a Personal Health Gateway. It intentionally specifies no interpretations of the data or assumptions about what data is important. It provides no interpretation of the mapped data or guidance on actions to be taken with the data once it has passed beyond the Gateway. In contrast, CGM focuses on a downstream clinical workflow, specifically the submission of summary reports, key statistical metrics, and underlying measurements to a clinical system, such as an EHR.

A system can therefore use PHD as a guide for ingesting discrete sensor data, and CGM as a guide for sharing discrete results, generating summary observations, and producing clinical reports. For systems that originate data from a PHD-compliant gateway, it is possible to construct glucose Observations that conform to the profiles in both guides. The mapping between the PHD and CGM CodeSystem requirements is a point of further study.

Note on Categories

This guide does not mandate specific Observation.category and DiagnosticReport.category values for CGM data. The appropriate categorization of CGM data will be addressed in future versions of this specification.

IG Dependencies

This guide is based on the FHIR R4 specification and relies on other implementation guides, including:

Refer to the Validation Page for the complete list of dependencies.

Global Profiles

There are no Global profiles defined

Copyrights

This publication includes IP covered under the following statements.

• The UCUM codes, UCUM table (regardless of format), and UCUM Specification are copyright 1999-2009, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved. https://ucum.org/trac/wiki/TermsOfUse
  Show Usage
  • Unified Code for Units of Measure (UCUM): Bundle/cgmDataSubmissionBundle, CGMSensorReadingMassPerVolume... Show 19 more, CGMSensorReadingMolesPerVolume, CGMSummaryCoefficientOfVariation, CGMSummaryDaysOfWear, CGMSummaryGMI, CGMSummaryMeanGlucoseMassPerVolume, CGMSummaryMeanGlucoseMolesPerVolume, CGMSummarySensorActivePercentage, CGMSummaryTimesInRanges, DataSubmissionSchedule, Observation/cgmSensorReadingMassPerVolumeExample, Observation/cgmSensorReadingMolesPerVolumeExample, Observation/cgmSummaryCoefficientOfVariationExample, Observation/cgmSummaryDaysOfWearExample, Observation/cgmSummaryGMIExample, Observation/cgmSummaryMeanGlucoseMassPerVolumeExample, Observation/cgmSummaryMeanGlucoseMolesPerVolumeExample, Observation/cgmSummarySensorActivePercentageExample, Observation/cgmSummaryTimesInRangesExample and ServiceRequest/cgmDataSubmissionStandingOrderExample
• This material contains content from LOINC. LOINC is copyright © 1995-2020, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and is available at no cost under the license. LOINC® is a registered United States trademark of Regenstrief Institute, Inc.
  Show Usage
  • LOINC: Bundle/cgmDataSubmissionBundle, CGMSensorReadingMassPerVolume... Show 21 more, CGMSensorReadingMolesPerVolume, CGMSummaryCoefficientOfVariation, CGMSummaryDaysOfWear, CGMSummaryGMI, CGMSummaryMeanGlucoseMassPerVolume, CGMSummaryMeanGlucoseMolesPerVolume, CGMSummaryObservation, CGMSummaryPDF, CGMSummarySensorActivePercentage, CGMSummaryTimesInRanges, DiagnosticReport/cgmSummaryPDFExample, Observation/cgmSensorReadingMassPerVolumeExample, Observation/cgmSensorReadingMolesPerVolumeExample, Observation/cgmSummaryCoefficientOfVariationExample, Observation/cgmSummaryDaysOfWearExample, Observation/cgmSummaryExample, Observation/cgmSummaryGMIExample, Observation/cgmSummaryMeanGlucoseMassPerVolumeExample, Observation/cgmSummaryMeanGlucoseMolesPerVolumeExample, Observation/cgmSummarySensorActivePercentageExample and Observation/cgmSummaryTimesInRangesExample
• This material derives from the HL7 Terminology (THO). THO is copyright ©1989+ Health Level Seven International and is made available under the CC0 designation. For more licensing information see: https://terminology.hl7.org/license.html
  Show Usage
  • Observation Category Codes: Bundle/cgmDataSubmissionBundle, Observation/cgmSensorReadingMassPerVolumeExample... Show 9 more, Observation/cgmSensorReadingMolesPerVolumeExample, Observation/cgmSummaryCoefficientOfVariationExample, Observation/cgmSummaryDaysOfWearExample, Observation/cgmSummaryExample, Observation/cgmSummaryGMIExample, Observation/cgmSummaryMeanGlucoseMassPerVolumeExample, Observation/cgmSummaryMeanGlucoseMolesPerVolumeExample, Observation/cgmSummarySensorActivePercentageExample and Observation/cgmSummaryTimesInRangesExample
  • diagnosticServiceSectionId: Bundle/cgmDataSubmissionBundle and DiagnosticReport/cgmSummaryPDFExample

Package Downloads

This is an R4 IG. None of the features it uses are changed in R4B, so it can be used as is with R4B} systems. Packages for both R4 (hl7.fhir.uv.cgm.r4) and R4B (hl7.fhir.uv.cgm.r4b) are available.

---

Acknowledgments

This Implementation Guide was developed with the input and collaboration of numerous individuals and organizations. The project's initial collaboration space can be found on Confluence: FHIR Write - CGM.

Primary Editors:

• Josh Mandel (SMART Health IT, Microsoft)
• Eric Haas (Health eData Inc)

Key Contributors:

• Mikael Rinnetmäki (Sensotrend)
• Brett Marquard (WaveOne Associates)
• Marti Velezis

This guide benefited greatly from the foundational work and diverse perspectives brought forth during the Argonaut Project, including contributions from CGM device vendors, application developers, Electronic Health Record (EHR) system providers, patient advocates, and clinicians. Their collective insights were invaluable in shaping the requirements and solutions presented in this guide.