Global App Configuration for User-Specific Medical Device Compliance

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Maintaining and provisioning different versions of the same application for varying user specifications, such as location, regulatory approvals, and user preferences, leads to resource inefficiency, increased maintenance complexity, and potential errors due to multiple codebases and application binaries.

Innovation Solution

A global configuration service (GCS) provides a unified collection of application assets, mapping user specifications to a subset of assets for configuring the application on user devices, eliminating the need for multiple binaries and codebases.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If multiple versions of the application are maintained for different user specifications, then user-specific compliance and customization are improved, but storage resource efficiency and maintenance complexity deteriorate

Engineering Contradiction:
Improveuser-specific complianceVSAvoidstorage resource efficiency
Core Design Contradiction:
Adaptability or versatilityVSLoss of energy

Solution Approach 1:

The patent merges multiple application versions into a single unified application binary that contains all features. Instead of maintaining separate binaries for different user specifications (Type 1 diabetes, Type 2 diabetes, different locations), the system combines all functionality into one binary and uses configuration files to enable or disable specific features based on user needs. This significantly reduces storage space requirements while maintaining the ability to comply with different user specifications.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The unified application binary is designed to be universal and multi-functional, capable of serving multiple user types and specifications. The single binary contains all features needed for different diabetes types, locations, and user preferences, with a configuration system that activates only the relevant features for each user. This eliminates the need to create and maintain multiple specialized versions of the application.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Adaptability or versatility

If multiple versions of the application are maintained for different user specifications, then user-specific compliance and customization are improved, but maintenance complexity and error potential during updates deteriorate

Engineering Contradiction:
Improveuser-specific complianceVSAvoidmaintenance complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent merges multiple application versions into a single unified application binary that contains all features. Instead of maintaining separate binaries for different user specifications (Type 1 diabetes, Type 2 diabetes, different locations), the system combines all functionality into one binary and uses configuration files to enable or disable specific features based on user needs. This significantly reduces storage space requirements while maintaining the ability to comply with different user specifications.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The system uses configuration files with parameters that define which features are enabled or disabled based on user specifications. By changing configuration parameters rather than maintaining separate codebases, the system can adapt to different user needs (Type 1 vs Type 2 diabetes, different locations) without creating multiple application versions. This simplifies maintenance as updates only need to be applied to the single binary and configuration files.

Inventive Principle:
Principle #35Parameter changes

3Reliability

If use-case specific applications are designed for each specific goal and user set, then application functionality and regulatory compliance are improved, but device complexity and user selection difficulty deteriorate

Engineering Contradiction:
Improveregulatory complianceVSAvoidapplication variety
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The unified application binary is designed to be universal and multi-functional, capable of serving multiple user types and specifications. The single binary contains all features needed for different diabetes types, locations, and user preferences, with a configuration system that activates only the relevant features for each user. This eliminates the need to create and maintain multiple specialized versions of the application.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system uses configuration files with parameters that define which features are enabled or disabled based on user specifications. By changing configuration parameters rather than maintaining separate codebases, the system can adapt to different user needs (Type 1 vs Type 2 diabetes, different locations) without creating multiple application versions. This simplifies maintenance as updates only need to be applied to the single binary and configuration files.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentEP4323995B1Global configuration service
Publication Date: 2026.01.28 DEXCOM INC
  • EP4323995B1 patent drawingFigure 1A
  • EP4323995B1 patent drawingFigure 1B
  • EP4323995B1 patent drawingFigure 2

AI summary

Certain aspects of the present disclosure relate generally to configuring applications used in conjunction with medical devices in order to help with monitoring and improving the patient's health. Certain aspects include a method including receiving a request for assets including access information associated with a user of a computing device, the access information including feature customization information for a health intervention application and being issued by an account management service for the health intervention application, and validating that the access information is valid. The method may also include responsive to the validating, generating configuration information identifying a set of assets with which the health intervention application is to be provisioned based, at least in part, on the feature customization information included in the access information, and transmitting the configuration information to the health intervention application to configure the health intervention application with the identified set of assets.