abstractbaseDefinitioncopyrightdate- Values Differ
description- Values Differ
experimentalfhirVersionjurisdiction
jurisdiction[0]kindnamepublisherpurposestatustitletypeurlversion- Values Differ
| Left: | CGM Data Submission Standing Order (http://hl7.org/fhir/uv/cgm/StructureDefinition/cgm-data-submission-standing-order) |
| Right: | CGM Data Submission Standing Order (http://hl7.org/fhir/uv/cgm/StructureDefinition/cgm-data-submission-standing-order) |
| Error | StructureDefinition.version | Values for version differ: '1.0.0-ballot' vs '1.0.0' |
| Information | StructureDefinition.date | Values for date differ: '2025-03-31T13:42:59+00:00' vs '2025-09-03T21:30:51+00:00' |
| Name | Value | Comments | |
|---|---|---|---|
| abstract | false | ||
| baseDefinition | http://hl7.org/fhir/uv/cgm/StructureDefinition/data-submission-standing-order | ||
| copyright | |||
| date | 2025-03-31T13:42:59+00:00 | 2025-09-03T21:30:51+00:00 |
|
| description | 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`](https://hl7.org/fhir/R4/servicerequest.html) 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`](StructureDefinition-data-submission-schedule.html) 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 a patient or provider can also **manually trigger** a submission within an app. For example, if there is an upcoming appointment, the provider can click a button to fetch 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. | 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`](https://hl7.org/fhir/R4/servicerequest.html) 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`](StructureDefinition-data-submission-schedule.html) extension contains: - `submissionPeriod`: Quantity, with units bound to the [UnitsOfTime](http://hl7.org/fhir/ValueSet/units-of-time) 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](http://hl7.org/fhir/ValueSet/units-of-time) 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. |
|
| experimental | |||
| fhirVersion | 4.0.1 | ||
| jurisdiction | |||
| jurisdiction[0] | http://unstats.un.org/unsd/methods/m49/m49.htm#001 | ||
| kind | resource | ||
| name | CGMDataSubmissionStandingOrder | ||
| publisher | HL7 International / Orders and Observations | ||
| purpose | |||
| status | active | ||
| title | CGM Data Submission Standing Order | ||
| type | ServiceRequest | ||
| url | http://hl7.org/fhir/uv/cgm/StructureDefinition/cgm-data-submission-standing-order | ||
| version | 1.0.0-ballot | 1.0.0 |
|
| Name | L Flags | L Card. | L Type | L Description & Constraints | R Flags | R Card. | R Type | R Description & Constraints | Comments | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
 ServiceRequest | C | 0..* | DataSubmissionStandingOrder | A request for a service to be performed | C | 0..* | DataSubmissionStandingOrder | A request for a service to be performed | |||||||||
 id | Σ | 0..1 | id | Logical id of this artifact | Σ | 0..1 | id | Logical id of this artifact | |||||||||
| meta | Σ | 0..1 | Meta | Metadata about the resource | Σ | 0..1 | Meta | Metadata about the resource | |||||||||
| implicitRules | ?!Σ | 0..1 | uri | A set of rules under which this content was created | ?!Σ | 0..1 | uri | A set of rules under which this content was created | |||||||||
| language | 0..1 | code | Language of the resource content Binding: ?? (preferred): A human language.
| 0..1 | code | Language of the resource content Binding: ?? (preferred): A human language.
| |||||||||||
| text | 0..1 | Narrative | Text summary of the resource, for human interpretation This profile does not constrain the narrative in regard to content, language, or traceability to data elements | 0..1 | Narrative | Text summary of the resource, for human interpretation This profile does not constrain the narrative in regard to content, language, or traceability to data elements | |||||||||||
| contained | 0..* | Resource | Contained, inline Resources | 0..* | Resource | Contained, inline Resources | |||||||||||
 Slices for extension | 0..* | Extension | DataSubmissionSchedule extensions Slice: Unordered, Open by value:url | 0..* | Extension | DataSubmissionSchedule extensions Slice: Unordered, Open by value:url | |||||||||||
 modifierExtension | ?! | 0..* | Extension | Extensions that cannot be ignored | ?! | 0..* | Extension | Extensions that cannot be ignored | |||||||||
| identifier | Σ | 0..* | Identifier | Identifiers assigned to this order | Σ | 0..* | Identifier | Identifiers assigned to this order | |||||||||
| instantiatesCanonical | Σ | 0..* | canonical(ActivityDefinition | PlanDefinition) | Instantiates FHIR protocol or definition | Σ | 0..* | canonical(ActivityDefinition | PlanDefinition) | Instantiates FHIR protocol or definition | |||||||||
| instantiatesUri | Σ | 0..* | uri | Instantiates external protocol or definition | Σ | 0..* | uri | Instantiates external protocol or definition | |||||||||
| basedOn | Σ | 0..* | Reference(CarePlan | ServiceRequest | MedicationRequest) | What request fulfills | Σ | 0..* | Reference(CarePlan | ServiceRequest | MedicationRequest) | What request fulfills | |||||||||
| replaces | Σ | 0..* | Reference(ServiceRequest) | What request replaces | Σ | 0..* | Reference(ServiceRequest) | What request replaces | |||||||||
| requisition | Σ | 0..1 | Identifier | Composite Request ID | Σ | 0..1 | Identifier | Composite Request ID | |||||||||
| status | ?!Σ | 1..1 | code | draft | active | on-hold | revoked | completed | entered-in-error | unknown Binding: ?? (required): The status of a service order. | ?!Σ | 1..1 | code | draft | active | on-hold | revoked | completed | entered-in-error | unknown Binding: ?? (required): The status of a service order. | |||||||||
| intent | ?!Σ | 1..1 | code | Intent for CGM is #order Binding: ?? (required): The kind of service request. Required Pattern: order | ?!Σ | 1..1 | code | Intent for CGM is #order Binding: ?? (required): The kind of service request. Required Pattern: order | |||||||||
| category | Σ | 0..* | CodeableConcept | Classification of service Binding: ?? (example): Classification of the requested service. | Σ | 0..* | CodeableConcept | Classification of service Binding: ?? (example): Classification of the requested service. | |||||||||
| priority | Σ | 0..1 | code | routine | urgent | asap | stat Binding: ?? (required): Identifies the level of importance to be assigned to actioning the request. | Σ | 0..1 | code | routine | urgent | asap | stat Binding: ?? (required): Identifies the level of importance to be assigned to actioning the request. | |||||||||
| doNotPerform | ?!Σ | 0..1 | boolean | True if service/procedure should not be performed | ?!Σ | 0..1 | boolean | True if service/procedure should not be performed | |||||||||
| code | SΣ | 1..1 | CodeableConcept | Code for CGM submission standing order Binding: ?? (example): Codes for tests or services that can be carried out by a designated individual, organization or healthcare service. For laboratory, LOINC is preferred. Required Pattern: {"coding":[{"system":"http://hl7.org/fhir/uv/cgm/CodeSystem/cgm","code":"cgm-data-submission-standing-order"}]} | SΣ | 1..1 | CodeableConcept | Code for CGM submission standing order Binding: ?? (example): Codes for tests or services that can be carried out by a designated individual, organization or healthcare service. For laboratory, LOINC is preferred. Required Pattern: {"coding":[{"system":"http://hl7.org/fhir/uv/cgm/CodeSystem/cgm","code":"cgm-data-submission-standing-order"}]} | |||||||||
| orderDetail | ΣC | 0..* | CodeableConcept | Additional order information Binding: ?? (example): Codified order entry details which are based on order context. | ΣC | 0..* | CodeableConcept | Additional order information Binding: ?? (example): Codified order entry details which are based on order context. | |||||||||
| quantity[x] | Σ | 0..1 | Quantity, Ratio, Range | Service amount | Σ | 0..1 | Quantity, Ratio, Range | Service amount | |||||||||
| subject | SΣ | 1..1 | Reference(Patient | Group | Location | Device) | Patient for the CGM submission order | SΣ | 1..1 | Reference(Patient | Group | Location | Device) | Patient for the CGM submission order | |||||||||
| encounter | Σ | 0..1 | Reference(Encounter) | Encounter in which the request was created | Σ | 0..1 | Reference(Encounter) | Encounter in which the request was created | |||||||||
| occurrence[x] | Σ | 0..1 | dateTime, Period, Timing | When service should occur | Σ | 0..1 | dateTime, Period, Timing | When service should occur | |||||||||
| asNeeded[x] | Σ | 0..1 | boolean, CodeableConcept | Preconditions for service Binding: ?? (example): A coded concept identifying the pre-condition that should hold prior to performing a procedure. For example "pain", "on flare-up", etc. | Σ | 0..1 | boolean, CodeableConcept | Preconditions for service Binding: ?? (example): A coded concept identifying the pre-condition that should hold prior to performing a procedure. For example "pain", "on flare-up", etc. | |||||||||
| authoredOn | Σ | 0..1 | dateTime | Date request signed | Σ | 0..1 | dateTime | Date request signed | |||||||||
| requester | Σ | 0..1 | Reference(Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device) | Who/what is requesting service | Σ | 0..1 | Reference(Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device) | Who/what is requesting service | |||||||||
| performerType | Σ | 0..1 | CodeableConcept | Performer role Binding: ?? (example): Indicates specific responsibility of an individual within the care team, such as "Primary physician", "Team coordinator", "Caregiver", etc. | Σ | 0..1 | CodeableConcept | Performer role Binding: ?? (example): Indicates specific responsibility of an individual within the care team, such as "Primary physician", "Team coordinator", "Caregiver", etc. | |||||||||
| performer | Σ | 0..* | Reference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson) | Requested performer | Σ | 0..* | Reference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson) | Requested performer | |||||||||
| locationCode | Σ | 0..* | CodeableConcept | Requested location Binding: ?? (example): A location type where services are delivered. | Σ | 0..* | CodeableConcept | Requested location Binding: ?? (example): A location type where services are delivered. | |||||||||
| locationReference | Σ | 0..* | Reference(Location) | Requested location | Σ | 0..* | Reference(Location) | Requested location | |||||||||
| reasonCode | Σ | 0..* | CodeableConcept | Explanation/Justification for procedure or service Binding: ?? (example): Diagnosis or problem codes justifying the reason for requesting the service investigation. | Σ | 0..* | CodeableConcept | Explanation/Justification for procedure or service Binding: ?? (example): Diagnosis or problem codes justifying the reason for requesting the service investigation. | |||||||||
| reasonReference | Σ | 0..* | Reference(Condition | Observation | DiagnosticReport | DocumentReference) | Explanation/Justification for service or service | Σ | 0..* | Reference(Condition | Observation | DiagnosticReport | DocumentReference) | Explanation/Justification for service or service | |||||||||
| insurance | 0..* | Reference(Coverage | ClaimResponse) | Associated insurance coverage | 0..* | Reference(Coverage | ClaimResponse) | Associated insurance coverage | |||||||||||
| supportingInfo | 0..* | Reference(Resource) | Additional clinical information | 0..* | Reference(Resource) | Additional clinical information | |||||||||||
| specimen | Σ | 0..* | Reference(Specimen) | Procedure Samples | Σ | 0..* | Reference(Specimen) | Procedure Samples | |||||||||
| bodySite | Σ | 0..* | CodeableConcept | Location on Body Binding: ?? (example): Codes describing anatomical locations. May include laterality. | Σ | 0..* | CodeableConcept | Location on Body Binding: ?? (example): Codes describing anatomical locations. May include laterality. | |||||||||
| note | 0..* | Annotation | Comments | 0..* | Annotation | Comments | |||||||||||
| patientInstruction | Σ | 0..1 | string | Patient or consumer-oriented instructions | Σ | 0..1 | string | Patient or consumer-oriented instructions | |||||||||
| relevantHistory | 0..* | Reference(Provenance) | Request provenance | 0..* | Reference(Provenance) | Request provenance | |||||||||||
| Documentation for this format | |||||||||||||||||