WO2024228627A1

WO2024228627A1 - System, method and apparatus for transmitting, receiving and presenting medical device information

Info

Publication number: WO2024228627A1
Application number: PCT/NZ2024/050046
Authority: WO
Inventors: Benjamin Wilson Casse; Mark Jonathan Berry; Christopher Harding CAMPBELL
Original assignee: Fisher and Paykel Healthcare Ltd
Current assignee: Fisher and Paykel Healthcare Ltd
Priority date: 2023-05-01
Filing date: 2024-05-01
Publication date: 2024-11-07
Anticipated expiration: 2025-11-01
Also published as: AU2024266033A1

Abstract

Systems, apparatus, methods, and computer-readable media for collecting, processing, generating, transmitting, receiving and presenting / displaying information regarding medical equipment are provided. More specifically, one or more aspects of the present application relate to respiratory support equipment / devices (also known as breathing assistance equipment / devices) such as interfaces (masks, cannulae, tracheal interfaces), tubes, filters, and other components or devices comprising or comprised in respiratory support equipment / devices; particularly of the replaceable variety (also sometimes referred to as "consumables").

Description

SYSTEM, METHOD AND APPARATUS FOR TRANSMITTING, RECEIVING AND PRESENTING MEDICAL DEVICE INFORMATION

This application claims priority from US patent application 63/499,308, filed 1 May 2023, entitled “System, method and apparatus for transmitting, receiving and presenting medical device information”, which is hereby incorporated by reference in its entirety.

BACKGROUND

The present application relates to systems, apparatus, methods, and computer-readable media for collecting, processing, generating, transmitting, receiving and presenting / displaying information regarding medical equipment. More specifically, one or more aspects of the present application relate to the configuration of mobile applications for use in the selection, ordering and maintenance of medical equipment, particularly respiratory support equipment / devices or components of same.

Generally described, computing devices and communication networks can be utilized to exchange data and/or information. In a common application, a computing device can request content from another computing device via the communication network. For example, a user having access to a computing device can utilize a software application to request a content page (e.g., a network page, a Web page, etc.) from a server computing device via the network (e.g., the Internet). In such embodiments, the user’s computing device (e.g., personal electronic device) can be referred to as a client computing device and the server computing device can be referred to as a content provider. In another embodiment, the user’s computing device can collect or generate information and provide the collected or generated information to a server computing device for further processing or analysis.

Respiratory masks can be used to provide respiratory gases that are generated by a respiratory support apparatus to a user. Respiratory masks are commonly used to provide various respiratory therapies such as, but not limited to, non-invasive ventilation (NIV) therapy (for example Bilevel pressure therapy) and continuous positive airway pressure (CPAP) therapy. CPAP therapy is commonly used to treat obstructive sleep apnea (OSA) and involves providing a constant supply of pressurized air to a user's airway. The constant supply of pressurized air splints a patient’s airway open, thus reducing airway collapse and reducing apneas. Generally, CPAP therapy provides patients with air flow typically pressurized to 4-20 cmH20. Bilevel pressure therapy involves delivering an inspiratory pressure and an expiratory pressure via the mask. Additionally, nasal cannulae or unsealed tracheostomy interfaces can be used to provide respiratory therapies like high flow therapy. High flow therapy involves providing high flows of humidified air or a mixture of air and supplementary gases (e.g., O2) via an unsealed interface. The flow rates in adults are generally above 10 L/min and the flow rate is selected to try and meet or exceed peak inspiratory airflow of a patient. High flow therapy can be used to treat spontaneously breathing patients experiencing respiratory compromise. High flow therapy can also optionally include gas mixture compositions including supplemental oxygen and/or administration of therapeutic medicaments. High flow therapy is often referred to as nasal high flow (NHF), humidified high flow nasal cannula (HHFNC), high flow nasal oxygen (HFNO), high flow therapy (HFT), or tracheal high flow (THF), among other common names.

Several different categories or types of respiratory masks may be used as part of different types of therapies, including, but not limited to, full face masks, nasal masks, nasal pillows, and the like. Further, respiratory masks are typically available in a range of fixed sizes to better fit patients with differing facial geometries. Additionally, various categories or types of nasal cannulae may be used as part of different therapies. Nasal cannulae are also available in various sizes to better fit patients with differing facial sizes. Similarly different categories or types of tracheal interfaces may also be used as part of different therapies.

Typically, patients or other end users undergoing or preparing to undergo respiratory therapy (particularly home-based respiratory therapy) consult with a number of entities including, for example, sleep specialist or other doctor, as well as a mask provider, retailer, distributor, reseller, or vendor (generally referred to herein as a “dealer”). Such consultations may be utilized to determine what type of mask and related respiratory apparatus is suitable for the patient, as well as the size and any other adjustments that may be necessary for individual patient use. Consultations regarding mask and respiratory apparatus selection, configuration, fitting, etc. may be a time-consuming process. Consultations (or related activities) may be further complicated if the mask or related respiratory apparatus initially recommended is not available from a particular dealer (and / or not available to a particular patient), potentially resulting in frustration, miscommunication, and delay. This may be a relatively common scenario, since the dealer is typically acting as an intermediary between the manufacturer of the mask and the end user, meaning that both the manufacturer’s and dealer’s contingencies may affect availability of or access to a particular product(s). Contingencies of the patient themselves, like budget constraints or underlying health conditions, may also come into this.

There have been some attempts to automate aspects of medical device selection processes. However, these tend to be relatively unsophisticated and may generally be based on displaying or making available to end users relatively generic information about the relevant medical devices. This may be of little assistance, and may even exacerbate the problem of patients / end users being unable to reliably research and then source an identified mask or related respiratory apparatus.

SUMMARY

Generally described, one or more aspects of the present application relate to systems, apparatus, methods, and computer-readable media for collecting, processing, generating, transmitting, receiving and presenting / displaying information regarding medical equipment. More specifically, one or more aspects of the present application relate to respiratory support equipment / devices (also known as breathing assistance equipment / devices) such as interfaces (masks, cannulae, tracheal interfaces), tubes, filters, and other components or devices comprising or comprised in respiratory support equipment / devices; particularly of the replaceable variety (also sometimes referred to as “consumables”). Illustratively, aspects of the present application can correspond to the configuration of mobile applications, or other software components, to facilitate the selection, ordering and maintenance of respiratory masks (or other devices / components / equipment) used in accordance with one or more respiratory therapies such as for example CPAP therapy or Bilevel pressure therapy or High Flow therapy. The term respiratory masks covers both sealing masks such as for example nasal masks, full face masks, nasal pillows as well as unsealed patient interfaces such as nasal cannulae or unsealed tracheostomy interfaces.

While in this specification reference is primarily made to respiratory masks, it will be understood that the invention may equally have application to other components of respiratory support apparatus / equipment, such as those mentioned above. Still further, reference to respiratory support equipment, respiratory support devices, respiratory support apparatus, therapy equipment, therapy apparatus, or other similar terminology may be considered applicable to similar devices (at times referred to herein as “medical devices” or similar) and should not be construed to impute any particular difference in type of device or process unless expressly stated. Additionally, reference or use of any such specific terms may be considered to be equally applicable to other terms.

In accordance with one aspect of the present application, a system for managing customizing information on a mobile application is provided. The system can include one or more computing devices, such as server computing devices, having or being associated with a processor and a memory for maintaining one or more instances of mobile application configuration information in a data store. As discussed in detail below, the mobile application configuration information is configured to be provided and executed, or otherwise processed by, computing devices (e.g., individual mobile devices). Individual instances of mobile application configuration information in the data store can be associated with a unique dealer identifier. Illustratively, at least a portion of the unique dealer identifier corresponds to an identifier of a dealer of respiratory support devices. Said respiratory support devices may, without limitation, be respiratory masks, such as continuous positive airway pressure (CPAP) respiratory masks.

The system can further include one or more computing devices, such as mobile computing devices, having or being associated with a processor and a memory for executing computer-executable instructions to implement a mobile application configuration system for respiratory support devices. The mobile application configuration system can be configured to obtain dealer profile configuration information from one or more dealers; the dealer profile configuration information specifying one or more attributes (e.g., configuration selection criteria) for generation of mobile application configuration information. The mobile application configuration system can then process the dealer profile configuration information to obtain the mobile application configuration information, and store the mobile application configuration information in the data store. Illustratively, reference to a mobile computing device or end user device is not intended to be limiting to specific hardware or software computing device configurations, but is intended solely to illustrate a computing device accessible to individual patients/users for purposes of processing or executing received mobile application configuration information in the manner(s) described herein.

The term ‘end user’ may relate to a patient but can also include other individuals, hospitals, care centers, businesses or other entity types, or other classes of end user. End user devices, data, information, mobile applications etc are associated with the end user. Reference to an individual end user is not limited to a single person, but depending on the end user type may refer to an individual hospital, care centre, business or other entity type, or an individual other class of end users.

Optionally, a given dealer may provide (directly or indirectly) multiple instances of mobile application configuration information that can be maintained in the data store and provided to different requesting patients (through a mobile device). Illustratively, different versions of mobile application configuration information or distinct, different instances of mobile application configuration information may reflect different combinations of attributes (configuration selection criteria). For example, one instance of mobile application configuration information may relate to masks (or other respiratory support devices) the dealer is able to sell to patients relying on insurance to pay for their therapy; while another instance of mobile application configuration information may relate to masks (or other respiratory support devices) the dealer is able to sell to uninsured patients or those self-funding their treatment. Each of such mobile application configuration information instances may be designated by a separate unique dealer identifier.

For purposes of the present application, instances of mobile application configuration information may generally relate to distinct organization or collection of mobile application configuration information that may be provided responsive to a request. Reference to different versions of mobile application configuration information is generally utilized to identify information that has been updated, modified, reconfigured, etc., relative to a previous version and may be used herein to reference to different working examples. However, reference in general to different instances of mobile application configuration information should be construed to include mobile application configuration information that may be considered to be “versions” of a reference or base version without limitation.

For purposes of an illustrative example, a mobile application configuration system can obtain a first request transmitted from a first mobile application, the first request from the first end user device including a first unique dealer identifier. The mobile application configuration system then retrieves a first instance of mobile application configuration information (e.g. first mobile application configuration information) associated with the first unique dealer identifier from the data store. The mobile application configuration system can then transmit the first mobile application configuration information to the first end user device responsive to the first request. The first end user device can then process the received first mobile application configuration information in order to locally configure, on the first end user device, a first local instance of the mobile application. The first local instance of the mobile application can then be processed in respect of one or more respiratory support devices (and / or related information) which conform with the attributes / configuration selection criteria specified by the first mobile application configuration information and the underlying dealer profile configuration information. For purposes of illustration, one or more respiratory support devices identified or caused to be selected by the first mobile application configuration information may comprise a first subset of a plurality of respiratory support devices available from the first dealer. The processing of said first local instance of the mobile application can comprise displaying on the first end user device said one or more respiratory support devices.

For instance, said attributes / configuration selection criteria may comprise one or more categories or types of respiratory masks; and / or one or more patient attributes, such as the type of payment or insurance plan / scheme that applies to the patient. Accordingly, the one or more respiratory support devices are those which meet the relevant attributes / configuration selection criteria, such as being suited to the relevant type or respiratory therapy and / or being covered by the relevant payment or insurance plan / scheme.

With continued reference to the illustrative example, optionally, the mobile application configuration system can obtain a second request from a second end user device, the second request from the second end user device including a second unique dealer identifier. The mobile application configuration system can then obtain a second instance of mobile application configuration information (e.g., second mobile application configuration information) associated with the second unique dealer identifier from the data store. The mobile application configuration system can then transmit the second mobile application configuration information responsive to the second request. In response, the second end user device executes the second mobile application configuration information in respect of a second subset of the plurality of respiratory support devices available from the second dealer. The execution may comprise displaying one or more of said second subset of the plurality of respiratory support devices on the second end user device. In some embodiments, the first subset of the plurality of respiratory support devices and the second subset of the plurality of respiratory support devices are different.

In accordance with further aspects of the present application, a method for configuration of a mobile application associated with medical devices is provided. The method is illustratively implemented by a configuration service. In accordance with the method, the configuration service obtains mobile device configuration requests from a plurality of mobile devices such that each mobile device configuration request including a unique dealer identifier. The configuration service then identifies mobile application configuration information based, at least in part, on said unique dealer identifiers. Finally, the configuration service then transmits the identified mobile application configuration information responsive to each of the mobile device configuration requests. Illustratively, each mobile device executes the received mobile application configuration information resulting in at least one customized mobile application executed on each mobile device.

In accordance with yet other aspects of the present application, a computer- implemented method for managing a plurality of applications executed on individual mobile devices based on dealer profile configuration information is provided. The method includes, responsive to a presentation of a unique dealer identifier, selecting mobile application configuration information based, at least in part, on said unique dealer identifier. The method further includes causing individual applications on mobile devices to be modified by execution of the selected mobile application configuration information maintained in a data store.

In accordance with a further aspect of the present application, an apparatus for configuring a mobile application is provided. The apparatus includes one or more computing devices associated with a processor and a memory for executing computer- executable instructions to implement a mobile application configuration module. The mobile application configuration module is configured to transmit a request for mobile application configuration information; the request for mobile application configuration information including a unique dealer identifier associated with a dealer of respiratory support devices. The mobile application configuration module is further configured to obtain, responsive to the request, mobile application configuration information associated with the transmitted unique dealer identifier associated with the dealer. Finally, the mobile application configuration module is configured to process the obtained mobile application configuration information to cause a presentation of a subset of a plurality of respiratory support devices available from the dealer. The subset of the plurality of respiratory support devices is illustratively less than the plurality of respiratory support devices available from the dealer wherein the subset of the plurality of respiratory support devices is formed based on dealer profile configuration information.

In embodiments, the system is further configured to: receive a request for third party configuration information, the third party configuration information to configure a third party mobile application with respect to a third party subset of a plurality of respiratory support devices available from the dealer, the request comprising: selection of a third party; and, selection of a third party subset of the plurality of respiratory support devices available from the dealer to be accessible to the third party, wherein the third party subset of the plurality of respiratory support devices is the same as or a subset of the subset of the plurality of respiratory support devices; and, transmit the generated request for third party configuration information, in response to receiving the request, the system being configured to retrieve the third party configuration information, and process the obtained mobile application configuration information to configure the third party mobile application per the third party configuration information, the configured third party mobile application provides third party access to the third party subset of the plurality of respiratory support devices.

In accordance with still further aspects of the present application, a method for configuration or customization of a mobile application associated with medical devices is provided. The method may be illustratively implemented by a mobile device executing a mobile application associated with medical devices. The mobile device first transmits a mobile device configuration request, the mobile device configuration request including an individual dealer identifier. The mobile device then receives mobile application configuration information based, at least in part, on the individual dealer identifier. Finally, the mobile device processes the received mobile application configuration information, wherein processing the received mobile application configuration information results in at least one customization of the mobile application associated with the medical device.

For purposes of the present application, reference to customization of a mobile application will generally refer to resulting state(s) of an executable mobile application after the receipt and processing of mobile application configuration information relative to state(s) of a base or common mobile application prior to processing of the mobile application configuration information. Such resulting state(s) of the executable mobile application may include the modification of executable code, the addition of executable code, the removable of executable code, the modification of data utilized in the execution of the mobile application, the addition of data, the removal of data, and the like. Reference in the present application to customization, configuration, or modification is intended to refer to any combination of techniques and types that may be utilized to achieve the resulting state(s) and is not intended to be limiting. Accordingly, reference to customization, configuration, or modification singularly or in various combinations is only illustrative in nature and should apply equally to allow techniques as understood by those skilled in the relevant art.

In yet another aspect of the present application a computer-implemented method for customizing mobile applications based on medical device dealer profile configuration information is provided. The method illustratively includes responsive to a presentation of a unique dealer identifier, receiving mobile application configuration information based, at least in part, on the presentation of the unique dealer identifier. The method further includes causing processing of the received mobile application configuration information to result in a modified mobile application based, at least in part, on configuration parameters specified in the received mobile application configuration information.

According to another aspect of the invention, there is provided a system for enabling electronic access, by a user via a user electronic device, to respiratory support device information, the system comprising one or more computer devices having a processor and a memory and configured to: store a plurality of customization factors; store a plurality of customization indicators, each indicating a unique combination of two or more of the customization factors; store, against each customization indicator, customized displayable data set information; the system being configured to, based on a nominated customization indicator, retrieve the corresponding customized displayable data set information to enable a base application to be configured, using the customized displayable data set information, into a customized application on the user electronic device.

In this portion of the Summary section, which describes the data flow of the invention and in particular the efficient storage of all relevant data compared with the relatively minimal data that must be downloaded to / processed by user electronic device (i.e. “end user device”), the following terminology is used:

The “customization factors” relate essentially to the various factors (such as specified attributes / configuration selection criteria, or other variables) that have been discussed above, some of which may be prefilled in the system by the dealer (or otherwise prefilled by a third party or from a third party source, such as some regulations or statutory requirements).

The “customization indicators” broadly correspond to the “unique dealer identifiers” that have been described above, with each “customization indicator” acting as a “pointer” to a different combination of customization factors.

And the “customized displayable data set information” is information identifying and pertaining to the subset of products (i.e. respiratory support devices, such as masks; “masks” is used herein for convenience) that corresponds to each customization indicator, that is to say, to each unique combination of factors.

Thus, by reference to the customization indicators, a dealer of respiratory support devices is able to direct a user specifically to the subset of products which is relevant and applicable to that user’s situation, depending on the combination of factors that applies to that user. That combination of factors will likely be unique and distinct from the combination of factors applying to another user: for instance, an individual needing CPAP who is insured versus an individual needing CPAP who is uninsured versus an individual needing NHF who is insured versus an individual needing NHF who is uninsured. For each such combination of factors, a different specific subset of products (masks) will be applicable / available to the patient. Using the customization indicator as a “pointer” ensures each user only sees those masks which apply to them once their mobile application is configured / customized.

Equally, a user accessing the system by reference to the relevant customization indicator will generally only need to download (and / or process) on their user device data relating to the subset of products (and related information) that is relevant to them. Similarly, they will generally only need to install subsequent updates to their mobile application if these affect the subset of products that is relevant to them. Furthermore, relatively little (if any) end user data needs to be centrally stored in the system. It is sufficient for the dealer to have access to end user information, and on this basis to provide the user with the appropriate customization indicator to “point” them to the correct subset of products in the system. Thus, the system promotes privacy and security of end user data.

The system may therefore tend to maximize both accuracy / efficacy, by ensuring the user only sees products for which they are actually eligible and which are available to them through their chosen dealer; and computational efficiency by avoiding downloads / processing and subsequent software updates that are not relevant to the user’s local (customized) mobile application.

Preferably, the customization factors comprise some or all of the following: the type of respiratory disorder or illness from which the user suffers; any underlying illness(es); the type of respiratory therapy or treatment regimen applicable to the user; the type or category of mask (full-face, nasal, et cetera),- the brand (manufacturer) of mask; the model of mask; information as to mask availability; geographical information; shipping information; any applicable product policies; any applicable laws or regulations; any applicable insurance policies; any applicable budget limitations or brackets.

Preferably, the customization factors also comprise the identity of a respiratory support device dealer.

Preferably, not all combinations of two or more customization factors will have a customization indicator assigned to them. For instance, some combinations of factors may be impossible - for example, some types of respiratory therapy may only be viable with certain categories or types of mask and not others; or some combinations of factors may be against policy or laws / regulations. Other combinations of two or more factors may be mandated or imposed, such as by a third party, for instance in the form of government regulations or in the form of policies or conditions of an insurance provider (for instance a particular type of therapy, if funded by a particular insurance scheme, might only be able to be delivered by a prescribed mask or subset of masks - in which case this would be an “imposed” combination of factors).

Preferably, some factors are universal across a subset of masks. For instance, some factors may be universal to all products in a particular brand (manufacturer), universal to all products stocked by a particular dealer, or universal to all masks of a particular type or category. For example, there may be policies (such as warranty or repair policies) that apply universally for all of a manufacturer’s or dealer’s products (and insofar as dealers are concerned, at least some such factors may be stored in a “dealer profile” corresponding to each dealer as discussed further above). As another example, a dealer might not stock a particular brand at all, in which case all of the customization indicators of that dealer will have as a commonality the absence of products of that brand (and again this may be stored in the system via a “dealer profile”). As still another example, a particular type of mask may be subject to mandatory (e.g. imposed by legislation or regulations) maintenance or replacement at particular intervals.

Preferably, one or more of the dealers may have their own dedicated set of customization indicators. In that case, one of the “customization factors” may also be the identity of the dealer, meaning the “customization indicators” (combinations of factors) which include that “customization factor” will of necessity be peculiar to that dealer. Additionally, or alternatively, customization indicators which are peculiar to a particular dealer may comprise a portion of the customization indicator (such as a numerical prefix or suffix) that uniquely identifies that dealer.

Alternatively, the customization indicators may not be assigned to any particular dealer, but rather may correspond to different combinations of factors relating to product attributes, user attributes, el cetera. In that case, different dealers may be able to utilize the range of customization indicators and convey the relevant customization indicator to each of their customers as a “pointer” to the appropriate subset of products. Alternatively, the system may comprise a combination of dealer-specific and non-dealer-specific customization indicators. For instance, some customization indicators may denote relatively “common” or ubiquitous combinations of customization factors (e.g. insured CPAP patients in, say, the US), which different dealers may be able to use to “point” their customers to the appropriate subset of masks. Other customization indicators may be specifically tied to a particular dealer, such as via a portion of the customization indicator (e.g. prefix or suffix) that uniquely identifies the dealer. Thus, a given dealer may at times use the non-dealer-specific customization indicators, and at other times the dealer-specific customization indicators.

It is also within the scope of the invention for a dealer to select a non-dealer- specific customization indicator and then cause a prefix or suffix (or other portion) to be appended to it to uniquely identify that dealer.

Preferably, the dealer may obtain one or more customization indicators from the system. In the simplest hypothetical case, where a given dealer has only one customization indicator, or only a small number of customization indicators that apply to them, the dealer may simply know the customization indicator already. For instance, the dealer may have only a single customization indicator corresponding to a fixed range of products (and related information) which they wish all their customers to have access to. In this case, the dealer may simply know (such as memorize, or have written down) the code corresponding to their customization indicator, which they can then convey to their customers to allow them to customize base versions of the mobile application on their device.

However, in a more complex case, a dealer may have many possible combinations of customization factors applicable to them (for instance, if they offer products for many disease states, therapy types, and payment / insurance regimens). In this case, there may be many different customization indicators which the dealer may wish to utilize, to point particular customers to the correct subset of products and information. In such a case, the system may comprise means for the dealer to call up the customization indicator corresponding to a given combination of customization factors. For instance, illustratively, a dealer interface may enable the dealer to select (such as via checkboxes) all the applicable customization factors, and may present to the dealer the corresponding customization indicator, which the dealer can then convey to their customer. This may save the dealer from having to keep records of all customization indicators corresponding to all different combinations of factors.

Additionally, or alternatively, the dealer may have the ability to “superpose” a name/title onto each customization indicator, to identify what that indicator relates to. This way, rather than the dealer being presented on their screen with a plurality of customization indicators (such as in the form of numerical strings), the dealer is instead presented with the name/title assigned to each such indicator, which may make it much easier and more intuitive for the dealer to select the appropriate customization indicator for a given patient.

It will also be understood that it is within the scope of the present application for a customization indicator to be automatically, or partially automatically, identified by the system, rather than being actively specified or provided by the dealer. In a simple example, where the dealer has only a single customization indicator associated with them, the system may recognize the identity of the dealer initiating the “invite” to a patient or end user, and may thus automatically derive the customization indicator.

Preferably, the customized displayable data set information stored against each customization indicator includes information as to the subset of respiratory support devices (such as masks or other products) that correspond to that customization indicator.

Preferably, the customized displayable data set information further includes ancillary information relating to said subset of respiratory support devices - for instance, product information, information as to available features / services for that product, information as to any conditions or warranties, et cetera.

Preferably, the customized displayable data set information may also include “negative information”, that is to say, means (such as computer-executable instructions) to obscure from view or prevent the display of particular products due to these not being appropriate to view under that customization indicator.

Preferably, as a preliminary step the base application is downloaded onto the user electronic device, and is subsequently customized via the customized displayable data set information which is sent to the user electronic device.

Alternatively, the base application is centrally customized by the system based on the customized displayable data set information, and the customized application is subsequently downloaded onto the user electronic device.

Preferably, the system comprises more than one base application. For instance, there may be a plurality of base applications, each configured for use in a particular geographic region or country.

Preferably, the nominated customization indicator is transmitted to the system by the user electronic device.

Alternatively, the nominated customization indicator is transmitted to the system by a dealer electronic device.

Preferably, one or more of the customization factors are transmitted to the system by the dealer electronic device.

Preferably, the system is configured to gather one or more items of user input from the user; for instance via displayed questions to which the user responds, or via obtaining one or more images of the user’s face via a camera functionality on or associated with the user electronic device. This may be incorporated into the system of the invention in different ways. For instance, the requests for user input (e.g., their formatting and display) may be part of the customized displayable data set information, i.e. they may be part of the information that is called by the customization indicator when the base application is being configured. Alternatively, the requests for user input may occur at a “downstream” stage of the process, i.e. post configuration of the base application. Furthermore, the customized displayable data set information (i.e. the information downloaded to the user’s device when the base application is being configured) may include all possibly relevant products, some of which are subsequently obscured from view based on the user’s responses to the questions (or other input). Alternatively, the user input may be requested / obtained as a precursor / intermediate step, and only those products conforming to the user input may actually be downloaded to the user’s device. Thus, the user input may be incorporated in different ways (and at different stages / phases) into the protocol of the invention.

According to another aspect of the invention, there is provided a method for configuration of a mobile application for respiratory health support, the method comprising: transmitting, by a mobile device executing the mobile application, a mobile application configuration information request, the mobile application configuration request including a unique identifier; receiving, by the mobile device executing the mobile application, mobile application configuration information based, at least in part, on the unique identifier; and processing, by the mobile device executing the mobile application, the received mobile application configuration information, wherein processing the received mobile application configuration information results in at least one customization of the mobile application.

According to another aspect of the invention there is provided a system for configuration of a mobile application for respiratory health support, the system configured to: transmit, by a mobile device executing the mobile application, a mobile application configuration information request, the mobile application configuration request including a unique identifier; receive, by the mobile device executing the mobile application, mobile application configuration information based, at least in part, on the unique identifier; and process, by the mobile device executing the mobile application, the received mobile application configuration information, wherein processing the received mobile application configuration information results in at least one customization of the mobile application.

BRIEF DESCRIPTION OF THE DRAWINGS

Various features will now be described with reference to the following drawings. Throughout the drawings, reference numbers may be re-used to indicate correspondence between referenced elements. The drawings are provided to illustrate examples described herein and are not intended to limit the scope of the disclosure. FIG. 1 depicts a schematic diagram of a network environment including a plurality of computing devices associated with end users, a plurality of computing devices associated with one or more dealers, and a networkbased configuration service in which various embodiments according to the present application can be implemented.

FIG. 2 is a block diagram illustrative of components of an end user computing device having a mobile application in accordance with embodiments of the present application.

FIG. 3 is a block diagram illustrative of components of an interface component service provided by a network-based configuration service in accordance with aspects of the present application;

FIG. 4 is a block diagram illustrative of components of a mobile application configuration service provided by a network-based configuration service to provide mobile application configuration information to mobile devices in accordance with aspects of the present application;

FIG. 5 is a block diagram illustrative of components of a dealer profile service provided by a network-based configuration service to facilitate the generation of dealer profiles for use in generating mobile application configuration information in accordance with aspects of the present application;

FIGS. 6A and 6B are simplified block diagrams of the environment of FIG. 1 illustrating the generation of dealer profiles and the provisioning of mobile application configuration information in accordance with aspects of the present application.

FIG. 7 is a flow diagram illustrative of a mobile application configuration routine implemented by a network service in accordance with illustrative aspects of the present application;

FIG. 8 is a flow diagram illustrative of a mobile application configuration routine implemented by a network service in accordance with illustrative aspects of the present application;

FIG. 9A depicts an end user device that includes a common mobile application including an interface for receiving a manual entry of a unique dealer identifier; FIG. 9B depicts an end user device associated with a dynamically configured mobile application including a sequence of interfaces for facilitating the selection of a respiratory mask;

FIG. 9C depicts an end user device associated with a dynamically configured mobile application including a sequence of interfaces for facilitating end user health checks associated with the use of a respiratory mask;

FIG. 10A-10C are schematics depicting data flow through the system in accordance with illustrative aspects of the present application;

FIG. 11 is a schematic illustrating the different “entry points” at which mobile application information and unique dealer identifiers may arise or come into being in the system according to illustrative aspects of the present application.

FIGS. 12A and 12B are schematics showing the schema of Figure 11 in combination with a database of the configuration service in accordance with illustrative aspects of the present application;

FIGS. 13, 14 and 15 are schematics showing different schema whereby the configuration service may effect customization / configuration of a base mobile application using mobile application configuration information, in accordance with illustrative aspects of the present application;

FIGS. 16 - 19 are schematics showing various steps pertaining to customization of a mobile application, in accordance with illustrative aspects of the present application;

FIGS. 20 - 30 are screenshots depicting implementation of an exemplary embodiment of the system of the present application;

FIGS. 31 - 32 are schematics showing further exemplary protocols for generation and conveying of an identifier according to exemplary embodiments of the present application.

FIGS. 33 and 34 are simplified block diagrams showing the generation of access rights for a third party by an end user;

FIGS. 35 and 36 are schematics showing access to databases granted to a third party by an end user; and,

FIG. 37 is a schematic showing various databases and attributes.

FIG. 38 is a block diagram showing various databases within a configured mobile application.

DETAILED DESCRIPTION

One or more aspects of the present application relate to systems, apparatus, methods, and computer-readable media for collecting, processing, generating, transmitting, receiving and presenting / displaying information regarding medical equipment. More specifically, one or more aspects of the present application relate to the configuration of mobile applications for use in the selection, ordering and maintenance of medical equipment. Illustratively, aspects of the present application can correspond to the configuration of mobile applications, or other software components, to facilitate the selection, ordering and maintenance of medical equipment, such as respiratory masks or other respiratory support devices. The respiratory support devices can include, but are not limited to, breathing tubes, filters, etc. For illustrative purpose and convenience, reference will primarily be made herein to “masks” or “respiratory masks” for use in accordance with one or more respiratory therapies such as for example CPAP therapy, Bilevel pressure therapy or high-flow therapy.

In the present application the term mobile application relates to an application on an end user device. The end user device may be ‘mobile’ in the sense of a mobile phone, for example a small, portable and light weight device hand held device, but may also relate to other types or sizes of user devices, for example laptop computers, desktop computers, tablets or other computer devices.

As described in greater detail below, a common or base mobile application may be initially distributed to end users. The common or base mobile application is illustratively provided such that it is only executable without incorporation of any customization or configuration information corresponding to specified attributes / configuration selection criteria / preferences of any particular distributor, reseller, vendor, etc. (referred to generally as a dealer) of respiratory support devices (such as respiratory masks), other respiratory or medical consumables, or ancillary services such as information or maintenance services pertaining to such devices or consumables. By utilizing unique dealer identifiers provided by individual dealers to individual end users, post distribution of the common or base mobile application, each individual end user’s mobile application can be dynamically configured by a configuration service such that the resulting dynamically configured mobile application (relative to the common or base mobile application) is configured for specific use by the individual end user based on dealer-specified attributes / configuration selection criteria / preferences, and / or other customizable data selected by individual dealers. To this end, the configuration service can illustratively provide executable code, instructions, data, or otherwise cause the activation of previously implemented executable code or data or the addition, modification, or removable of such previously implemented executable code or data.

Generally described, there are numerous approaches for providing information to end users regarding selection, fitting, maintenance, and use of medical devices, such as respiratory masks and other respiratory support devices. In some scenarios, a medical device manufacturer may provide and distribute the medical devices directly to end users, such as the patient utilizing the medical device. In such scenarios, the manufacturer may maintain greater control in terms of product offerings, sizing, etc. that are provided to end users. Accordingly, in such scenarios, the manufacturer can provide support and information regarding the medical devices they are supplying with a relatively high degree of control and accuracy. However, manufacturers typically do not deal directly with end users as they are not in the sales / distribution business. Rather, a medical device manufacturer may wish to implement a sales and distribution network that can include various entities (e.g., distributors, resellers, vendors, etc.) or other intermediary entities that provide medical devices and support for end users. These entities may work individually, or collectively, and will be referenced generally as “dealers” for purposes of illustration.

In some typical sales and distribution scenarios, individual dealers may incorporate different product lines, product offerings, product policies, product configurations, sizings, etc. that are offered to customers. Such differences in the product offerings and associated supporting information may be based on individual dealer preferences/restrictions/circumstances, governmental restrictions/requirements, manufacturer preferences/restrictions/circumstances, and the like. Additionally, individual dealers may also have individualized programs for financial compensation, reimbursement, delivery, replacements etc. Accordingly, in such typical sales and distribution scenarios, the medical device manufacturer may have greater challenges providing the same level of information or support to end users due to the differences in the offerings created by different dealers. A corollary of this is that in such typical sales and distribution scenarios, end users may have more difficulty obtaining accurate information as to availability of, eligibility for, and conditions around, particular medical device offerings. There are more parties involved, each with constraints, policies, etc., which increases the potential for miscommunication, disparity or error.

Some approaches to providing users with information regarding medical devices, such as respiratory masks (or other consumables) used in accordance with one or more respiratory therapies, involves the utilization of a mobile device to access information provided by a content source, such as a network service hosted by, or on behalf of a medical device manufacturer or the dealer. In one example, a mobile device may be configured with a mobile application that generates interfaces for end users that can include information for sizing or proper fit selection, and other kinds of maintenance, as well as related services and features. In another example, a mobile device may be configured with a more generic browser application that can request and display content from a content provider, such as the medical device manufacturer or the dealer. Such conventional approaches can further include processes that may utilize authentication and authorization or information, such as by the use of access codes or passwords, to limit access to the network service or information provided by the network service.

Some approaches to information delivery systems, such as the approaches described above, are limited to approaches that are based on a direct relationship between the manufacturer and the end user, namely the medical device manufacturer having direct control over product offerings, sizing, variations, etc. More specifically, for implementations utilizing mobile applications, manufacturers typically do not need to provide different configurations of mobile applications with pre-configured content or processing rules if the manufacturer has a direct relationship with the end user. Alternatively, manufacturers may simply rely on supplemental individualized content request processing infrastructure (e.g., a network service) that is hosted by the manufacturer (or on their behalf) and provides individualized content for display on individual mobile applications or browser applications responsive to transmitted content requests.

In other approaches, when the manufacturer utilizes a sales and distribution network with various dealers in a dealer network environment, a mobile application approach is typically not utilized in view of the potential variance in product offerings, support, service, information, etc. that each individual dealer (e.g., vendor, distributor, reseller, etc.) may provide or wish to provide. For example, a common mobile application provided by a manufacturer may include information for medical devices that may not be offered by a specific dealer to a specific end user or may be missing such information for medical devices that are offered by a specific dealer. Accordingly, an end user accessing the single mobile application may not be able to complete desired tasks, such as ordering, servicing, maintenance, etc., or to access information that is accurate or relevant.

Additionally, a common mobile application may require additional computing device resources, such as memory or network bandwidth, to maintain, update or execute the mobile application. In some instances, updates (and other processing) may be computationally expensive if the range of medical devices offered by the manufacturer is extensive or complex. If it were desired to utilize a mobile application to provide information in these situations, it would likely be necessary to create individualized mobile applications on a per dealer basis and distribute these to the individual end user based on which dealer is associated with the individual end user. An alternative might be for manufacturers or dealers to attempt to implement a browser application-based solution that provides individualized content request processing infrastructure that is hosted by the manufacturer or individual dealer to provide individualized information. However, both of these approaches may tend to be complex, inefficient, and ineffective, as the extent of variability between different dealers means a potentially large number of contingencies must be accounted for in any such mobile application or browser-based solution. This may entail significant technical issues, such as scaling, updating, variable network performance, and the like. There may also be inefficient usage of computing device resources, such as processing resources, memory resources, network bandwidth resources, and the like. Further, any network services provided by, or on behalf of, the manufacturer or dealer could require greater technical complexity, such as to do with content updates or to do with browser-based content request processing methodology. Additional deficiencies or inefficiencies may also be present.

Such approaches are therefore not well suited for providing end users with dealer specific product information (and / or ancillary information).

To address at least some portion of the above-described deficiencies, the present application includes multiple aspects related to the generation of medical device information corresponding to dealer specified profiles. Such medical device information is illustratively implemented in conjunction with mobile applications that can be hosted and customized on individual mobile devices. Illustratively, individual end users first access a common (or “base”) mobile application that can be distributed to a plurality of end users. The distribution of the common mobile application can be illustratively achieved without the need to identify any particular end user that will be accessing the common mobile application or any particular dealer. In this regard, the common mobile application, as initially distributed to a plurality of end users, is not unique with regard to particular dealer preferences/attributes/restrictions/circumstances/requirements, etc. or customized in a manner related to an individual end user. Thus, the common mobile application can be made readily available and widely distributed to sets of end users. Such distribution of the common mobile application may be characterized as distribution that can be independent of the end user that will be executing the mobile application and dealer(s) that may be providing or otherwise distributing the medical device or related accessories.

For purposes of the present application, reference to a common or base application relates to an application (e.g., a mobile application) provided to end users without active customization based on any particular dealer or end user (in the sense of any user- specific or dealer-specific preferences/attributes/restrictions/circumstances/requirements, etc.). As previously discussed, reference to customization of a mobile application will generally refer to resulting state(s) of an executable mobile application after the receipt and processing of mobile application configuration information relative to state(s) of the base or common mobile application prior to processing of the mobile application configuration information. Such resulting state(s) of the executable mobile application may include the modification of executable code, the addition of executable code, the removable of executable code, the modification of data utilized in the execution of the mobile application, the addition of data, the removable of data, and the like. Reference in the present application to customization, configuration, or modification is intended to any combination of techniques and types that may be utilized to achieve the resulting state(s) and is not intended to be limiting.

In some embodiments, one or more manufacturers (or other entity) may support multiple versions of a common application applicable to different sets of end users, such as to account for external criteria. Such external criteria can include, but are not limited to, different common applications according to differing hardware requirements or capabilities of the end user computing devices, different operating systems or interfaces, different communication networks or protocols, different regulatory or administrative requirements (such as from country to country), and the like. In such embodiments, each version of the common application can be further configured based on instances of mobile application configuration information provided by a network service.

Individual dealers (e.g., vendors, resellers, distributors, etc.) within a dealer network can engage with a network service to establish dealer profiles related to customization preferences/attributes/restrictions/circumstances/requirements which, in use, will be processed

by, or incorporated into, the common mobile applications initially provided to the end users, such as customers of respiratory masks or other consumables such as tubes, filters, etc., offered and distributed by the individual dealers. The network service is illustratively hosted by, or on behalf, of a manufacturer and may be generally referred to as a “configuration service”. Such customization preferences, attributes, restrictions, circumstances, requirements, or other similar information (at times referred to herein by the collective term “customization preferences”) can include a selection of medical devices (e.g., respiratory masks or other consumables) that are available for sale/distribution by the dealer, medical device service/maintenance preferences, patient health or medical condition check preferences, ordering preferences, payment or financial arrangement preferences, and the like.

The network service can then provide or make accessible unique dealer identifiers that correspond to the generated configuration information (this being derived from the abovediscussed “preferences”). Such unique dealer identifiers can be provided according to different distribution techniques and in various tangible formats (e.g., physical formats, electronic formats, etc.). The unique dealer identifiers can be provided or distributed to a selection of end users, such as the customers of the individual dealer. Based on the dealer preferences (in the sense used above), the configuration service can generate instances of mobile application configuration information that can be utilized to modify or update the common mobile application in accordance with the dealer specific preferences. The network service can then provide end user devices specific instances of mobile application configuration information via the unique dealer identifiers, to enable the base applications on the end user devices to be configured / customized in accordance with the configuration information.

Thereafter, end users can engage with dealers for purposes of viewing, selecting, ordering, receiving, and maintaining medical devices, or other activity through a customized mobile application generated as will now be illustratively described. Starting with the common mobile application, end users are provided a unique dealer identifier (e.g., a unique dealer code, a unique image associated with a dealer, a QR code, etc.) that is entered (such as via typing, scanning, etc.) into the common mobile application by the end user and transmitted to the configuration service via a communication network. The configuration service, responsive to the transmitted unique dealer identifier, identifies relevant mobile application configuration information and provides it (such as in the form of configuration data, meta data, a script file, or in any other suitable format) to the common mobile application located on the end user mobile device from which the unique dealer code was transmitted. In response, the common mobile application incorporates the returned mobile application configuration information such that the mobile application is configured in accordance with the dealer specified preferences from which the configuration information is derived. The end user can subsequently access the customized mobile application for product viewing, ordering, fitting, troubleshooting, or other interactions.

In alternative embodiments, the unique dealer identifier (which may be in any suitable format, such as a unique dealer code, a unique image associated with dealer, QR code, etc.) may, rather than being transmitted by the common mobile application, be processed locally on the end user device / common mobile application (or processed in another suitable manner upon being received by same. Following said processing, and as a distinct step, a query may then be sent to the configuration service via the communication network for the configuration information. Optionally, sending of said query may only be enabled if the unique dealer identifier has, during processing, been confirmed as being valid and authentic. A further possible variation is that the transmission of the unique dealer identifier and subsequently mobile application configuration information occurs from / to the end user device, via an external device or alternative application.

Yet a further possible variation is that the mobile application is at least partly preconfigured prior to download by the end user. For instance, starting with the generic or base version of the mobile application, a preconfigured (or partly preconfigured) instance of the mobile application may be generated for a particular patient (end user), based on the dealer’s “preferences” as well as those of the end user. The end user may be provided with a link to said preconfigured instance of the mobile application. Using the link, the end user may download to their phone said preconfigured instance of the mobile application. The mobile application may then be used for further steps, such as mask sizing, selection, ordering, reordering, etc. In such a variation, there is still a step of configuration of a base version of the mobile application, but rather than occurring at the end user’s device this occurs as a preliminary step, at a/the central server.

Although aspects of the present application will be described with regard to illustrative examples or embodiments, computing devices, algorithms and the like, one skilled in the relevant art will appreciate that the disclosed embodiments are illustrative in nature and should not be construed as limiting. Additionally, although the illustrative examples of the present application will be described with regard to respiratory masks (and more particularly CPAP respiratory masks), one skilled in the art will appreciate that such examples are illustrative in nature and should not be construed as limiting.

One or more aspects of the present application may equally be utilized in relation to medical devices more generally, including other types of components for respiratory devices (such as, without limitation, nasal cannulae, tracheostomy interfaces, medical tubes, filters, etc.- whether configured for CPAP therapy, high-flow therapy, or other types of respiratory therapy or respiratory support), other types of medical devices or components other than those used for the treatment of respiratory issues, and entire medical devices, apparatuses or systems (whether for respiratory treatment or other) comprising multiple components.

Furthermore, while the illustrative examples discussed herein focus on an individual user wishing to browse / purchase medical devices on their own behalf in an in- home / homecare context, the present application may also find application in a hospital setting. In such a case, the hospital (or relevant department / personnel) would be the end user, and the dealer would usually be the medical device manufacturer. The “dealer profile” would act as a filter for different therapies or hospital policies. The mobile application would hide unnecessary devices (such as masks) that are not relevant to the specific therapy or policy.

In some examples the end user is hospital, care center, business or other entity, or other class of end user, which has multiple staff. In such examples, the end user device may be one device, or multiple devices. The device or multiple device may include an application hosted centrally by the hospital etc and which is accessible by multiple people. In such cases, each person may be provided access to the central server via separate devices.

FIG. 1, is a block diagram of an environment or system 100 that includes a plurality of computing devices (e.g., end user devices 102) accessible by one or more individuals (not illustrated), one or more dealer computing devices (e.g., dealer devices 104) associated with dealers (not illustrated) and a configuration service 110 according to one embodiment.

As described above, reference to entities as dealers corresponds to one or more distribution/sale networks for the distribution / sale of medical devices (such as respiratory masks) provided by a manufacturer (not illustrated); and the configuration service 110 is hosted by, or on behalf of, the manufacturer or the dealers. The environment 100 includes a plurality of end user devices 102A, 102B, 102C utilized by individuals, said end user devices (102A, 102B, 102C - collectively indicated by 102) being configured to interface with the configuration service 110 to obtain specialized mobile application configuration information that facilitates the configuring / customization / modification (the terms being interchangeably used herein) of the mobile application locally on each end user device (102A, 102B, 102C). The terms customize, configure, customization, configuration are used interchangeably herein. Such configuration allows an end user to use the configured / customized mobile application to view (and acquire information on, and effect other actions such as requesting maintenance of) medical devices that are relevant to them. For instance (without limitation) the mobile device may be configured with mobile application configuration information which identifies the specific inventory carried by a corresponding dealer and which may be available to an identified user under the insurance or payment plan, policy or arrangement that applies to them. The mobile application configuration information corresponds to one or more preferences or attributes specified by an individual dealer, which are illustratively transmitted to the configuration service 110. By way of illustration, at least some subset of the end users associated with the user devices 102 are associated with different individual dealers. Accordingly, based on a specific association, and more particularly based on the transmitted unique dealer identifier, the configuration service 110 can provide different configuration information to individual end user devices 102.

It will be understood that a given dealer may have more than one unique dealer identifier associated with them, with each of the dealer’s unique dealer identifiers pointing to different specific instances mobile application configuration information. This reflects the fact that different combinations of the various attributes / preferences specified by the dealer (and / or other relevant parameters) are possible. For instance, a first subset or class of end users (dealing with the relevant dealer) may be eligible for a first subset medical devices for CPAP therapy that may be covered by a premium insurance plan. A second subset or class of end users (also dealing with the relevant dealer) may also be eligible for a second subset of medical devices for CPAP therapy associated with difference financial criteria, such as a basic insurance plan, or individual payment. Still another end user (also dealing with the relevant dealer) may require devices for high-flow therapy. Each of these scenarios will likely affect which subset of the range of medical devices the dealer is able to offer to a particular class of end users. For instance, the end user may be a hospital. The hospital may be eligible for a particular subset of medical devices or other products that the dealer is able to offer. The dealer selects a unique dealer identifier pointing to specific mobile application configuration information which reflects the combination of the various attributes / preferences specified by the dealer (and / or other relevant parameters) relevant to the hospital.

The dealer may customize which of its products it wants a particular end user (for example a hospital) to see, for example for marketing purposes or, in the case of a hospital, based on the therapy types the hospital provides or the types of equipment it requires. The dealer sends the relevant unique identifier relating to the particular product range and the end user can use the unique identifier to open up a customized version of the application that only shows the subset of products the dealer wants that end user to see. This can be useful, for example, when the dealer is presenting a product range to an end user so the end user can see information on the corresponding product range. As such, each individual end user (or classes of end users) may receive or otherwise access the common mobile application (without preconfiguration) but be provided different unique dealer identifiers by a dealer. Each unique dealer identifier can then be provided by (or in connection with) each end user to a configuration service that facilitates the resulting configuration or customization of the base mobile application. Some preferences / attributes may be common to all of the instances of mobile application configuration information associated with a given dealer - for instance, limitations on the brands the dealer stocks and / or sells (if a given dealer doesn’t stock Brand A medical devices at all, this will be reflected across all of that dealer’s instances of mobile application configuration information); or the dealer’s contact information or other administrative information. Other preferences / attributes will vary depending on end user specifics / circumstances.

As previously discussed, the format of the unique dealer identifiers can take several different forms and be generated in different manners for distribution. In one embodiment, the unique dealer identifiers may be static in nature in that the unique dealer identifiers may be generated in a manner independent of the end user request (pre-generated or generated in response to a request). In other embodiments, the unique dealer identifiers may be dynamic in nature by incorporating some temporarily based data related to the request and may be generated in response to a request. In one embodiment, the dealer identifier can include multiple portions. For example, where a dealer has multiple sets of mobile application configuration information associated with them (each indicated by a different unique dealer identifier), a first portion of the identifier (assuming it is a numerical code) may be a number indicating the dealer and a second portion of the identifier may be an indicator of the particular combination of circumstances that apply to the end user, and thus the particular subset of medical devices that should be displayed to them. For instance, said circumstances may relate to the type of illness the end user suffers from, their insurance status, any other relevant personal attributes, their location, etc. Also included might be technical information such as timestamps, network addresses, and the like.

However, this is not intended to be limiting, and other configurations of the unique dealer identifier(s) and of the protocol more generally are within the scope of the invention. For instance, instead of (or in addition to) having a plurality of unique dealer identifiers covering various contingencies for each dealer, it is within the scope of the present application for the system to comprise logic for dynamically determining attribute specification based on inputted criteria; that is to say, a partial template for creating instances of mobile application configuration information is stored in the system, but is only completed once the end user (or dealer, or other relevant party) inputs further information enabling the system to generate a full, bespoke, instance of mobile application configuration information that is then provided to the end user device. Said further information may be requested / obtained as part of the protocol of the invention, or it may be obtained separately by the dealer or other relevant party, such as by provision of forms to be filled in by the end user.

Furthermore, in some embodiments, the unique dealer identifier(s) may not cover all contingencies / circumstances that may apply to a particular end user. In such cases, the unique dealer identifier(s) may function to point to subsets of dealer products which are broadly appropriate for the end user, though not necessarily fully customized to them. In such cases, a degree of manual (e.g., verbal) qualification or explanation may be required by the dealer, for instance to clarify that one or more of the results (products) displayed to the end user are not in fact available to them.

As discussed above, in some embodiments the dealer may direct the end user to a version of the mobile application that is already configured or partially configured; for instance when a dealer has prepared a bespoke configuration of the mobile application for a particular end user (or class of end users) that is tailored to that user’s individual and specific circumstances. As noted above, in such cases configuration of a / the base application still takes place, but rather than occurring at the end user device it might instead occur at a/the central server, for example. With continued reference to FIG. 1 , the end user devices 102 can in general be any personal electronic device or other computer device - illustratively, they may be provided by a laptop or tablet computer, personal computer, wearable computer, server, personal digital assistant (PDA), hybrid PDA/mobile phone, mobile phone (e.g. smartphone), electronic book reader, controller, digital media player, watch, glasses, a home or car device, Internet of Thing (“IoT”) devices, virtual reality or augmented reality devices, wearable accessories, and the like. Still further, the individual end user devices 102 can represent devices or components that have alternative purposes, but have been configured to function as an individual end user device as described herein. For example, the individual end user device can correspond to a security device, appliance, or medical device that is configured to provide access to a mobile application as described herein. For purposes of illustration, reference to the actions of a user or end user refers generally, without limitation, to an individual that accesses a computing device (e.g., an end user computing device 102) in the manner described herein. Such “end users” can include individuals that are the intended user of the medical equipment or one or more individuals acting on their behalf.

While the term “mobile device” is referred to in places in this specification it will be understood that, unless the context demands otherwise, the aspects of the present application can equally be implemented via any personal electronic device operated by the end user. Consistently with this, it will be understood that, while the terminology “mobile application”, “mobile application configuration application”, and “mobile application configuration system” is used in the present specification, this relates to the application being hosted on the end user device, whether that device is provided by a mobile device or some other personal electronic device or computer device.

As described above, the environment or system 100 includes a plurality of dealer devices 104 or network of devices utilized by one or more dealers that are involved in the direct interface with end users for the ordering, fitting, servicing, maintenance, etc. of the respiratory masks (or other medical devices, as mentioned above), generally referred to as dealers 104 or service providers with respect to relationships with the end user. The term “dealer” as used herein is not intended to be limited to any specific category of role or function within a respiratory mask supply chain and is intended to generally cover any of one of the variety of entities described above and additional entities not expressly illustratively identified herein.

The dealer devices 104 may include any number of different computing devices capable of communicating with the network 106, via a direct connection or via an intermediary.

As will be explained in greater detail below, the dealer devices 104 include (or at least are configured to, in use, be associated with) additional applications or functionality, such as browser applications, mobile applications, software applications, or interface components that facilitate the inputting of information by / on behalf of dealers. In some embodiments, the dealer devices 104 may further include communication functionality for providing users with unique dealer identifiers. In some embodiments, the dealer devices 104 can be provided by a plurality of computing devices associated with the dealer, such as a set of computing devices accessible to a plurality of individuals that are associated (e.g., employees) with the individual dealer.

Network 106 may be any wired network, wireless network, or combination thereof. In addition, the network 106 may be a personal area network, local area network, wide area network, cable network, fiber network, satellite network, cellular telephone network, data network, or combination thereof. In the example environment of FIG. 1 , network 106 is a global area network (GAN), such as the Internet. Protocols and components for communicating via the aforementioned types of communication networks are well known to those skilled in the art of computer communications and thus, need not be described in more detail herein. While each of the user devices 102, the dealer devices 104, and the configuration service 110 are depicted as having a single connection to the network 106, individual components of the user devices 102, the dealer devices 104, and the configuration service 110 may be connected to the network 106 at disparate points. Accordingly, communication times and capabilities may vary between the components of FIG. 1. Likewise, although FIG. 1 is illustrated as having a single network 106, one skilled in the relevant art will appreciate that the environment 100 may utilize any number or combination of networks.

In accordance with embodiments, the configuration service 110 is a logical representation of one or more network based services that may be executed or implemented to provide functionality described herein. Reference to the configuration service 110 therefor represents or references functionality by one or more of the illustrative services, without requiring any specific implementation or instantiation of any particular grouping of service.

By way of illustration the configuration service 110 includes one or more dealer profile services 116 for processing interactions with individual dealers, communicating via the dealer devices 104, to obtain dealer profile configuration information specifying one or more attributes / preferences (i.e. configuration selection criteria) which are stored as dealer profiles in a data store(s) of the configuration service 110, such as in the dealer profiles data store(s) 118. This information is then used to generate mobile application configuration information, which is stored in the data store(s) of the configuration service 110, such as in mobile application configuration data store(s) 120.

The configuration service 110 further includes one or more mobile application configuration services 114 for processing interactions with user devices 102 to provide specific mobile application configuration information responsive to a submitted unique dealer identifier. As described in further detail below, the configuration service 110 includes an interface component 112 that can be configured to receive the various requests described herein. The interface component 112 may also access or provide access to one or more third party information sources that can be utilized (not shown).

Although the various services 112-116 associated with the configuration service 110 are illustrated as single components, each individual service 112, 114, 116 may be implemented in a number of different instantiated components, including physical computing devices, one or more virtualized resources, or a combination thereof. Accordingly, reference to individual services 112, 114, 116 should not be limited to any particular computing device implementation, although illustrative architectures for implementation of a service in accordance with a server computing device is provided herein for illustrative purposes.

The configuration service 110 further can include a number of data stores for maintaining different information. The data stores include one or more dealer profile data stores 118 for maintaining the dealer profiles associated with individual dealers 104 and corresponding dealer profile configuration information (e.g., specified attributes / preferences / configuration selection criteria, and other relevant variables pertaining to the dealer such as any restrictions/limitations/regulations of that dealer). The data stores can also include mobile application configuration data stores 120 for maintaining mobile application configuration information, such as executable code, data files, instructions, that are utilized to cause the modification of a mobile application. Although illustrated as individual data stores, the data stores 118 and 120 can correspond to multiple data stores, distributed data stores, or variations thereof. Still further, as understood by one skilled in the relevant art, reference to data store in the present application generally includes any variety of hardware components and / or software applications for maintaining and providing data; including databases, data files, or memory units, and including for example memory of computing devices in a cloud-based network. It will be appreciated by those skilled in the art that the system 100 may have fewer or more components than are illustrated in FIG. 1. Thus, the depiction of the environment 100 in FIG. 1 should betaken as illustrative. For example, in some embodiments, components of the configuration service 110 may be executed by one or more virtual machines implemented in a hosted computing environment. A hosted computing environment may include one or more rapidly provisioned and released computing resources, which computing resources may include computing, networking or storage devices, servers or a cloud hosted server network. Additionally, while such components are illustrated as being logically grouped in FIG. 1 , one skilled in the relevant art will appreciate that it is possible for the configuration service 110 to be implemented in multiple geographic areas. Additionally, not all geographic areas hosting portions of the configuration service 110 will necessarily have all the same components or combination of components. For instance, different geographic areas may each be associated with a distinct configuration service 110, that is to say, a server configured to effect the invention across a particular geographic region (vis-a-vis dealers and / or end users in that region). Thus, it is within the scope of the invention for there to be a plurality of configuration services 110, each one dedicated to a particular geographic area or region, such as a country.

Illustratively, interactions between end users, dealers, and network service providers may be associated with the computing device communications between end user devices 102, dealer devices 104, and the configuration service 110. In some of the description, an interaction or action may be attributed to an individual end user or individual dealer without specific reference to a computing device. Such interaction may be considered to be attributable or facilitated through a computing device (as appropriate when taken into context) even if reference to a computing device is not explicitly mentioned.

FIG. 2 depicts one embodiment of an architecture of a computing device that may be considered an illustrative end user device 102, such as a personal computer, tablet computer, smartphone, or other device, that can generate and transmit content and process content requests in the manner described above, such as the end user device 102A, 102B, or 102C illustrated in FIG. 1. FIG. 2 is illustrative of the general framework of an end user device 102 that can be utilized to host a mobile application provided to the user for purposes of accessing information or providing communications related to respiratory masks (or other respiratory support devices or medical devices), generally referred to as a mobile application. The general architecture of the end user device 102 depicted in FIG. 2 includes an arrangement of computer hardware and software components that may be used to implement aspects of the present application. As illustrated, the end user device 102 includes a processing unit 202, a network interface 204, a computer readable medium drive 206, an input/ output device interface 208, an optional display, and an input device, all of which may communicate with one another by way of a communication bus (not illustrated). In various embodiments, components such as the display and/or the input device may be integrated into the computing device, or they may be external components that are coupled to the end user device 102.

The network interface 204 may provide connectivity to one or more networks or computing systems, such as the network 106 of FIG. 1. The processing unit 202 may thus receive information and instructions from other computing systems or services via a network. The processing unit 202 may also communicate to and from memory 210 and further provide output information for an optional display via the input/output device interface 208. The input/output device interface 208 may also accept input from the optional input device, such as a keyboard, mouse, digital pen, etc. In some embodiments, the end user device 102 may include more (or fewer) components than those shown in FIG. 2.

The memory 210 may include computer program instructions that the processing unit 202 executes in order to implement one or more embodiments. The memory 210 generally includes RAM, ROM, or other persistent or non-transitory memory; and can include multiple memory blocks (e.g., flash drives) and / or distributed (cloud-based) memory. The memory 210 may store an operating system 214 that provides computer program instructions for use by the processing unit 202 in the general administration and operation of the end user device 102. The memory 210 may further include computer program instructions and other information for implementing aspects of the present disclosure. For example, in one embodiment, the memory 210 includes an interface application 212 for facilitating communications with network 106. Additionally, the memory 210 can include a network application 216, such as a browser application or other customized application, for accessing and generating information. The memory 210 can illustratively include a mobile application 218 that corresponds to a separate application that can be customized according to mobile application configuration information and may provide information and services regarding respiratory masks and/or other consumables.

Although mobile application 218 is illustratively shown as a single feature in FIG. 2, in preferred embodiments an initial, “common” or “base” version of the mobile application 218 is firstly downloaded to the end user device 102; and is subsequently customized / configured locally on the end user device 102 in the manner described herein, to conform with the relevant dealer profile configuration settings (and any other relevant factors affecting customization, such as end-user-specific factors). However, this is not intended to be limiting and other protocols may be within the scope of the invention. For instance, in some embodiments a base version might not be downloaded; instead, an already-configured version of the mobile application might be downloaded to the end user device in the first instance.

Illustratively, a fully configured or customized mobile application 218 is distinguishable from the generic network application 216 in that the mobile application 218 does not require network connections with a network service to obtain and render content. The mobile application 218 can retain information for display to a user, provide various interfaces responsive to user interaction, and retain user interaction information without requiring network-based communications to be operable, such as typical interactions utilized by network applications. Although mobile application 218 is referred to as a “mobile” application such terminology should not be construed as limiting in the type of computing device that may be considered an end user device 102 or requiring the end user device 102 to execute any specific operating environment (or type of operating environment).

FIG. 3 depicts one embodiment of an architecture of an illustrative server for implementing the interface component application 112 of the configuration service 110 as described. The general architecture of the interface component service 112 depicted in FIG. 3 includes an arrangement of computer hardware and software components that may be used to implement aspects of the present disclosure. The components of the interface component service 112 may include physical hardware components, one or more virtualized components or a combination thereof. Additionally, the components of the interface component service 112 or the functionality attributed by the interface component service 112 may be implemented in a virtualized environment. Such virtualized environments may be provided by the manufacturer, the dealer, or by a third-party entity, such as a computing service provider that can host physical computing devices for instantiating software modules that may be persistent or temporary in nature for purposes of implementing the functionality depicted in the illustrative architecture for the interface component service 112. Accordingly, reference to the interface component service 112 corresponds to implementations without limitation to physical computing device resources, virtualized computing device resources, or a combination thereof.

As illustrated, the interface component service 112 includes a processing unit 304, a network interface 306, a computer readable medium drive 308, and an input/output device interface 309, all of which may communicate with one another by way of a communication bus.

The network interface 306 may provide connectivity to one or more networks or computing systems, such as the network 106 of FIG. 1. The processing unit 304 may thus receive information and instructions from other computing systems or services via a network. The processing unit 304 may also communicate to and from memory 310 and further provide output information for an optional display via the input/output device interface 309. In some embodiments, the interface component service 112 may include more (or fewer) components than those shown in FIG. 3.

The memory 310 may include computer program instructions that the processing unit 304 executes in order to implement one or more embodiments. The memory 310 generally includes RAM, ROM, or other persistent or non-transitory memory. The memory 310 may store an operating system 314 that provides computer program instructions for use by the processing unit 304 in the general administration and operation of the interface component service 112. The memory 310 may further include computer program instructions and other information for implementing aspects of the present disclosure. For example, in one embodiment, the memory 310 includes a user device configuration processing component 316 that is configured to process requests for mobile application configuration information from end user devices. The memory 310 includes a dealer profile processing component 318 for processing requests for generation of dealer profiles that can be utilized in the provisioning of mobile application configuration information as described herein.

FIG. 4 depicts one embodiment of an architecture of an illustrative server for implementing a mobile application configuration service 114 as described. The general architecture of the mobile application configuration service 114 depicted in FIG. 4 includes an arrangement of computer hardware and software components that may be used to implement aspects of the present disclosure. Similarly to the components of the interface component service 112, the components of the mobile application configuration service 114 may include physical hardware components, one or more virtualized components or a combination thereof. Additionally, the components of the mobile application configuration service 114 or the functionality attributed by the interface component service may be implemented in a virtualized environment. Such virtualized environments may be provided by the manufacturer or by a third-party entity, such as a computing service provider that can host physical computing devices for instantiating software modules that may be persistent or temporary in nature for purposes of implementing the functionality depicted in the illustrative architecture for the mobile application configuration service 114.

As illustrated, the mobile application configuration service 114 includes a processing unit 404, a network interface 406, a computer readable medium drive 408, and an input/output device interface 409, all of which may communicate with one another by way of a communication bus. The components of the mobile application configuration service 114 may be physical hardware components or implemented in a virtualized environment.

The network interface 406 may provide connectivity to one or more networks or computing systems, such as the network 106 of FIG. 1. The processing unit 404 may thus receive information and instructions from other computing systems or services via a network. The processing unit 404 may also communicate to and from memory 410 and further provide output information for an optional display via the input/output device interface 409. In some embodiments, the mobile application configuration service 114 may include more (or fewer) components than those shown in FIG. 4.

The memory 410 may include computer program instructions that the processing unit 404 executes in order to implement one or more embodiments. The memory 410 generally includes RAM, ROM, or other persistent or non-transitory memory. The memory 410 may store an operating system 414 that provides computer program instructions for use by the processing unit 404 in the general administration and operation of the mobile application configuration service 114. The memory 410 may further include computer program instructions and other information for implementing aspects of the present disclosure. For example, in one embodiment, the memory 410 includes a mobile application request processing component 416 that is configured to process requests for configuration information based on unique dealer identifiers, such as a unique dealer code provided by a dealer through a dealer device 104 to a user device 102. The memory further includes a mobile application configuration component 418 for selecting and processing mobile application configuration information to be provided to a user device 102. Similar to previous descriptions, reference to the mobile application configuration service 114 corresponds to implementations without limitation to physical computing device resources, virtualized computing device resources, or a combination thereof.

FIG. 5 depicts one embodiment of an architecture of an illustrative server for implementing the dealer profile service 116 as described. The general architecture of the dealer profile service 116 depicted in FIG. 5 includes an arrangement of computer hardware and software components that may be used to implement aspects of the present disclosure. As previously discussed, the components of the dealer profile service 116 may include physical hardware components, one or more virtualized components or a combination thereof. Additionally, the components of the dealer profile services 116 or the functionality attributed by the interface component service may be implemented in a virtualized environment. Such virtualized environments may be provided by the manufacturer or by a third-party entity, such as a computing service provider that can instantiate software modules that may be persistent or temporary in nature for purposes of implementing the functionality depicted in the illustrative architecture for the dealer profile service 116.

As illustrated, the dealer profile service 116 includes a processing unit 502, a network interface 504, a computer readable medium drive 506, and an input/output device interface 508, all of which may communicate with one another by way of a communication bus. The components of the dealer profile service 116 may be physical hardware components or implemented in a virtualized environment.

The network interface 504 may provide connectivity to one or more networks or computing systems, such as the network 106 of FIG. 1. The processing unit 502 may thus receive information and instructions from other computing systems or services via a network. The processing unit 502 may also communicate to and from memory 510 and further provide output information for an optional display via the input/output device interface 508. In some embodiments, the dealer profile service 116 may include more (or fewer) components than those shown in FIG. 5.

The memory 510 may include computer program instructions that the processing unit 502 executes in order to implement one or more embodiments. The memory 510 generally includes RAM, ROM, or other persistent or non-transitory memory. The memory 510 may store an operating system 514 that provides computer program instructions for use by the processing unit 502 in the general administration and operation of the dealer profile service 1 116. The memory 510 may further include computer program instructions and other information for implementing aspects of the present disclosure. For example, in one embodiment, the memory 510 includes a dealer profile configuration processing component 516 that is configured to obtain “preference” and specification information provided by individual dealers, via the dealer devices 104, and store such information. Similar to previous descriptions, reference to the dealer profile service 116 corresponds to implementations without limitation to physical computing device resources, virtualized computing device resources, or a combination thereof.

Turning now to FIGS. 6 A and 6B, illustrative interactions between end users, dealers and a manufacturer, as embodied in communications between an end user device 102, dealer device 104 and configuration service 110 will be described. For purposes of the present application, the illustrations of FIGS. 6A and 6B will be described with regard to a single end user device 102B interacting with the configuration service 110 and dealer device 104 to obtain configuration information for a mobile application on the end user device 102B.

With reference to FIG. 6A, an illustrative interaction for creation of dealer profiles through communications generated by dealer device 104 will be described. Although only a single dealer device 104 is illustrated in FIG. 6A, the configuration service 110 may repeat the interaction with a plurality of dealer devices 104, in which individual dealer devices 104 can correspond to different dealers. Still further, the interactions in FIG. 6A will be illustrated with regard to the generation of an individual unique dealer identifier responsive to the creation of the dealer profile. In some embodiments, as described above, the creation of a dealer profile may result in the generation of multiple unique dealer identifiers or at least some portion of the interactions described herein may be repeated by the same dealer to create multiple unique dealer identifiers.

For purposes of the interaction illustrated in FIG. 6 A, it is assumed that a dealer has established a business relationship with a manufacturer to sell or otherwise distribute the medical devices, such as CPAP respiratory medical devices, and the dealer is capable of providing, at least in part, the related services to one or more end users. Still further, it is assumed in the illustration of FIG. 6A, that an individual dealer has registered or otherwise engaged with the system allow for the interactions illustrated in FIG. 6A. Registration will typically involve the dealer providing certain basic information such as name, location, and details of products offered. At (1), the dealer device 104 can request access to the configuration service 110 and transmit dealer profile configuration information to the configuration service 110. While schematically depicted as a single step, it will be understood that in preferred embodiments the dealer may add to, or amend, their dealer profile configuration information as and when appropriate (with corresponding amendments being made to the mobile application configuration information, and to affected end user devices via updates). Such interactions by the dealer device 104 with the configuration service 110 may be embodied as interactions corresponding to network applications (e.g., a browser application) or a custom applications implemented on a computing device, such as a personal computing device, tablet computing device, mobile device and the like. The dealer profile configuration information can be utilized to establish dealer profiles including, or otherwise related to, dealer preferences, specifications, or attributes related to the dealer, available medical devices (e.g., range of products), terms and conditions, interactions with end users, etc. As discussed in greater detail below, at least some of these factors may in turn make reference to or be contingent on attributes of the end users; for instance the range of products a dealer is able to supply to an end user may vary based on the end user’s disease state, insurance status, or other factors). The information included in the resulting dealer profiles will illustratively form the basis of mobile application configuration information generated by the configuration service 110, which in turn will enable customization of mobile applications 218 (FIG. 2) on end user devices 102.

Individual dealers, using a dealer device 104 can, through the configuration service 110, establish dealer profiles that include dealer profile configuration information relating to that dealer’s product range, preferences, restrictions, conditions, etc. As noted above, that dealer profile configuration information will inform how the common mobile applications initially distributed (directly or indirectly) to customers of the individual dealer are subsequently customized. Such interaction (between the dealer device 104 and the configuration service 110) can include accessing various interfaces to enter data, transmitting formatted data, or other forms of data communication. In one example, the dealer profile configuration information can include information related to a selection of respiratory support devices (or other medical devices, particularly consumables) that are available for sale/distribution by the dealer. One skilled in the relevant art will appreciate that the dealer profile configuration information can include a single attribute specification, multiple attribute specifications or logic for dynamically determining attribute specification based on dynamic criteria. Accordingly, the identified examples herein should not be construed as limiting as to all possible customization preferences or specifications.

In one example, individual dealers, such as through dealer devices 104, may select different medical device models for sale to limit the information the mobile application (once configured / customized) provides to end users, different sizing information, different branding / trade names, or different features / attributes of available medical devices that will be offered for sale or distribution. In this regard, the dealer profile configuration information may include information that specifies a subset of respiratory masks that are made available by a given dealer for selection by an end user through a customized mobile application 108 executed on an end user device 102. Additionally, or alternatively, the dealer profile configuration information may also include information that specifies a subset of respiratory masks that will not be presented to the end user through the customized mobile application 108.

Illustratively, the dealer profile configuration information can identify or include what data is downloaded to the end user device 102 as part of the mobile device application customization / configuration processes described herein. Alternatively, or additionally, the dealer profile configuration information can include selection information that can be processed by the mobile application or end users device such that it activates or makes available data already present on the “base” or common version of the mobile application. Still further, additionally or alternatively, the dealer profile configuration information can also include filtering information that causes the deletion, de-activation or other obfuscation of data previously configured on the “base” or common mobile application but that will not be utilized as part of the customization of the “base” or common mobile application for a particular dealer and / or for a particular end user.

For purposes of illustration, the type of interaction and data collection between the dealer devices 104 and the configuration service 110 can, at least in part, comprise receipt of information that corresponds to the desired configuration of the mobile application for the end user devices 102. In one aspect, as previously described, the input received from the dealer devices 104 includes a selection of a subset of respiratory masks that corresponds to the inventory (e.g., mask range / types/ categories / brands) carried by the dealer. The subset of respiratory masks may also be specified by regional preferences / availability or governmental approval criteria which may govern, at least in part, which respiratory masks may be made available (e.g., the subset of respiratory masks). In some embodiments, the specification of a subset of respiratory masks may include a static selection of inventory, such as via drop-down menus, listing, etc. In other embodiments, the specification of a subset of respiratory masks may include dynamic selection criteria that is executed at the time dealer profile configuration information is requested (described below).

In one aspect, as previously described, the input received through the dealer devices 104, may specify dealer profile configuration information identifying different types of end user (i.e. patient or different class of end user) compliance data, general or specific end user health data or other medical condition check preferences initiated by, or facilitated through, the mobile application. Illustratively, this can include types of government mandated checks, insurance provider mandated checks, and the like. The individual dealers 104 may determine how information is collected (e.g., fillable form or free text) and various security/authentication associated with the collected data. The inputs from the dealer devices 104 can also specify logging information and data transmission intervals for transmitting logged data to the configuration service 110.

Illustratively, the post-configured mobile application 218 may be configured to provide general or generic usage data related to the medical device, the mobile application, etc. Such general or generic user data may be explicitly manipulated to remove or exclude identifying information or mitigate the possibility of general or generic data being attributable to individual end users. Accordingly, the dealer profile configuration information can specify data or protocols for anonymizing one or more aspects of the collected data. This can include substitute identifiers, scrambling codes, encryption, and the like. This may mean that the system / configuration service 110 need not obtain access to, and / or store, user- specific information (or at the very least that it only requires relatively little such information); this can largely remain with the dealer. At the same time, the dealer is still able, via the unique dealer identifier, to grant the end user access to the specific subset of products that are applicable to that user. This compartmentalization of information may have benefits in terms of computational efficiency, but also in terms of privacy (potentially including in terms of complying with applicable privacy laws) as well as in terms of end user confidence in the integrity of the protocol and of the anonymity and confidentiality of their information.

In still other aspects, as previously described, the input received from individual dealers, through dealer devices 104, may specify dealer profile configuration information in the form of ordering preferences (or requirements or limitations or conditions, etc.) or payment or financial arrangement preferences (or requirements or limitations or conditions, etc.) related to ordering the medical devices. The dealer profile configuration information can specify/identify attributes that can specify or limit types of financial arrangements that will be supported by the dealer. For example, the dealer profile configuration information can include a specification or authorization of different types of supported third party reimbursement mechanisms used in the procurement, supply, and/or maintenance of respiratory masks (e.g., government provided insurance reimbursement, private insurance reimbursement, self-funded arrangements, etc.). Again, in some embodiments these various financial arrangements will affect the range of products that are appropriate for displaying to the end user, and thus each arrangement may be allocated a separate unique dealer identifier to enable it to act as criterion pointing to the appropriate subset of products.

In still other aspects, as previously described, the input received though dealer devices 104, can specify dealer profile configuration information in the form of how ordering information is processed and transmitted. In this aspect, the mobile application 218 may be configured (when being locally customized / configured on the end user device 102) such that information transmission may be formatted or include dealer specific information to facilitate processing of the order. For example, the dealer profile configuration information can include dealer specific codes or labels, addresses, contact information, payment information, formatting information, etc. to facilitate ordering functionality with the individual dealer.

In still further aspects, as previously described, the input received through the dealer devices 104, can specify dealer profile configuration information in the form of preferences/selection of data formatting, data structures, or protocol of transmission to facilitate subsequent interaction/compatibility with additional ordering processing or financial systems. Such specifications can also include information related to the protocols, authentication mechanisms, authentication information, encryption protocols and keys, and other network information that may be utilized to establish specific communication channels with the configuration service 110 or dealer devices 104. Additionally, the ordering information can identify end user configurable fields, predefined fields, or unmodifiable fields associated with the collection and processing of data. For example, the mobile application may be modified such that specific address information cannot be changed or that proposed changes to address information are limited to a region associated with the individual dealers.

Based on the dealer preferences embodied in dealer profile configuration information, the configuration service 110 can generate configuration information that can be utilized to the modify or update the common mobile application in accordance with the dealer specific preferences to result in a customized or configured mobile application as referenced herein.

At (2), the configuration service can select any default information and services that may be included in the dealer profile. In one example, the default information can include information that is associated with the respective dealer but is not provided as part of (i.e. is separate from or additional to) the dealer profile configuration information. Such default information can include billing information, product selection information, contact information, and the like. This default information can be collected or generated as part of a separate process, such as registration of the dealer. In another example, the default information can further include information that may not be unique to an individual dealer but specified by other entities, such as the manufacturer, government agencies, shipping companies, and the like. The collection or generation of default information can limit the manual specification of the dealer profile configuration information utilized in the creation of the dealer profile. However, this is not intended to be limiting and in other embodiments, all such information may be entered by the dealer as dealer profile configuration information. At (3), the configuration service 110 processes the received dealer profile configuration information and any default information to form a dealer profile. At (4), the configuration service 110 stores the dealer profile configuration information and generates mobile application configuration information that will be utilized to modify or update individual mobile applications. Illustratively, the generated mobile application configuration information can include any combination of executable code and data that results in the modification of mobile applications (illustratively on end user devices 102, though potentially externally of end user devices) in accordance with the dealer profile configuration information. As noted elsewhere in this specification, a given set or instance of dealer profile configuration information can give rise to multiple sets or instances of mobile application configuration information. This is because different combinations of factors (collectively forming the dealer profile configuration information) may correspond to different subsets of the dealer’ s products, such that one end user (to whom one combination of factors applies) is eligible to view a different subset of the dealer’s products than another end user (to whom another combination of factors applies).

For example, some aspects of the mobile application configuration information can include executable scripts that remove or filter out some portion of the content that can be provided to users via the mobile application 218. Other aspects of the mobile application configuration information can include data or information utilized by the mobile application, such as billing codes, address information, shipping information, and the like. Still other aspects of the mobile application configuration information can include the generation of commands or codes that enable specific features previously provided through the mobile application, including decryption of code or content, or disable one or more features (or modify the content and functionality of such features).

At (5), the configuration service 110 can then generate unique dealer identifiers that correspond to the generated mobile application configuration information. Illustratively, the unique dealer identifiers correspond to a unique or semi-unique code, image or other information that can be provided to individual users as described herein. The unique dealer identifiers may be scanned or manually entered into the mobile application on an end user device.

Optionally, the unique dealer identifiers can include one or more dynamically determined portions that may be determined or calculated at various times, including prior to receiving a request from end user devices 102 (see FIG. 6B) or responsive to a request from an end user device 102. As noted above, a given end user may require a specific mobile application configuration depending on the specific combination of factors that applies to them. This mobile application configuration will be denoted by the unique dealer identifier. As such, the process may illustratively entail finding out (such as by user input) the particular combination of factors that apply to a given end user, and then generating a dynamic portion of the unique dealer identifier that corresponds to that specific combination of factors. (The unique identifier may also have a static portion which corresponds, illustratively, to the particular dealer). Once generated, the unique dealer identifier can then be provided to the end user, who uses it to configure their mobile application to enable them to view the subset of products and information which applies to them.

At (6), the configuration service 110 provides or makes available a result of the creation of the dealer profiles, including the generated unique dealer identifiers. For example, the configuration service 110 can transmit one or more unique dealer identifiers to the dealer devices 104 for subsequent delivery or distribution to end users as described herein. The delivery/distribution of the unique dealer identifiers can occur via a platform, interface or communication means that is the same as, or related to, the mobile application. For instance, the “base” version of the mobile application can be configured to receive the original communication (containing the unique dealer identifier), which may then, with or without further end user prompting, trigger the customization steps. Alternatively, the unique dealer identifiers may be transmitted, distributed or posted via an independent process (e.g., email distribution or uploading to a shared memory repository). Also, the unique dealer identifiers may be received by, and/or subsequently conveyed by, entities other than the dealers themselves. For instance, an authorized third-party intermediary may receive the unique dealer identifiers from the configuration service and subsequently convey these to the appropriate end users.

In an embodiment, the dealer may generate an “invite” using the system, and cause this to be transmitted to the end user device. The “invite” is a communication, alert or message that lets the end user know that, by interacting with the invite in the manner specified (such as clicking on a link provided), they will be able to view the dealer’s products that are relevant to them. Within the invite, such as embedded within the link, is a code that designates the dealer - this may be referred to as an “invite ID”, and cross-identifies or links the invite with the particular dealer. The “invite ID” may be generated automatically, based on the dealer being logged into their account when generating the “invite”. Upon the “invite” being received by the end user device, and being actuated such as by the end user clicking on the provided link, the system may then automatically retrieve the code or “invite ID”, from which (wholly or in part) the system may identify how to customize the mobile application. In some versions of this example, the code or “invite ID” may include additional information over and above the identity of the dealer; for instance, the code or “invite ID” may cross-reference (directly or indirectly) to the appropriate mobile application configuration information. For instance, the dealer may, when preparing the “invite”, specify or make known to the system the relevant “attributes” pertaining to the invite (such as disease type, user insurance status, etc.) and this may be reflected in the code or “invite ID”, which the system, upon retrieving the code or “invite ID” can use to determine the appropriate mobile application configuration information.

Thereafter, individual end users can engage with individual dealers for purposes of ordering and receiving medical devices through the individual dealer. With reference to FIG. 6B, an illustrative interaction for provisioning individual end user devices 102 with configuration information for the common mobile application resident on the end user device 102 will be described. Although only a single user device 102B is shown actively communicating with the system in FIG. 6B, the configuration service 110 may repeat the interaction with a plurality of user devices including 102A, 102C, in parallel or sequentially. It is assumed for purposes of the illustrations of FIG. 6B, individual user device 102B has been provided or otherwise acquires the common mobile application (e.g., the mobile application 218 prior to a customization or configuration process). In one example, the base mobile application may be provided via the configuration service 110 via a network connection based on a request transmitted from the end user device 102. In another example, the common mobile application may be preloaded on an end user device 102, such as with an initial delivery/ distribution and may not need to be separately downloaded or provided. In still another example, the common mobile application may be available for download to the end user device 102B from a third-party application provider.

At (1), the dealer device 104 provides a unique dealer identifier (e.g., a unique dealer code) to the end user, such as via a transmission to the end user device 102B. In some embodiments, the unique dealer identifier may be provided electronically, such as by data transmission (e.g., email, short message services, near field communications, etc.). In other embodiments, the unique dealer identifier may be provided without computing device interaction, such as by printed communications, physical postings, oral communications, etc. In other embodiments, the unique dealer identifiers may be provided by entities other than the dealer, such as the manufacturer or third-party intermediaries or information services. In accordance with this alternate embodiment, one or more unique dealer identifiers may be posted or distributed via Web pages or other communication network-based resources. As previously described, in still other embodiments, the unique dealer identifier can include one or more dynamically determined portions that may be utilized as part of a unique dealer identifier and may be determined or calculated at various times, including prior to receiving a request from end user devices 102 or responsive to a request from an end user device 102.

At (2), the end user device 102B obtains the unique dealer identifier, such as via manual entry, scanning, etc. Illustratively, the common mobile application on the end user device 102B may generate interfaces for obtaining manual entry or transfer of the unique dealer identifier, which may be in the form of a code. In another embodiment, the common mobile application may receive information or otherwise interact with other components of the end user device 102B, such as a camera application, bar code reader, near field communication application, etc. that may be operable to provide a unique identifier to the common mobile application without requiring additional manual input from an end user. It is also possible, in alternative embodiments, for the unique dealer identifier to, at this stage of the process, be obtained and processed by the end user device (102) independently of the common mobile application.

At (3), the user device 102B transmits a request for mobile application configuration information to the configuration service 110. Illustratively, the request can include the unique dealer identifier that was previously provided. Alternatively, the request may be based on the unique dealer identifier but without including the unique dealer identifier per se. In other embodiments, the request process can include an exchange of multiple communications between the user device 102B and configuration service 110. By way of illustrative embodiments, in one aspect, a user intending to use the respiratory mask may be manipulating the end user device 102B for purposes of transmitting the request for mobile application configuration information or otherwise accessing the end user device 102B. In other embodiments, different individuals may be providing inputs or otherwise accessing the end user device 102B. For e, in a hospital setting, one or more technicians or service personnel may manipulate an end user device 102 on behalf of a patient. The end user device 102 may be a mobile device controlled by the end user. The end user device 102 may be a separate computing device that is not controlled by the patient, but is manipulated by the hospital staff on behalf of the patient.

At (4), the configuration service 110, responsive to the transmitted unique dealer identifier (and / or the transmitted configuration request), identifies relevant mobile application configuration information. In one embodiment, the configuration service 110 can select mobile application configuration information that has been precompiled. In other embodiments the configuration service 110 can dynamically generate at least some portion of the mobile application configuration information, such as by dynamically updating medical device availability information, etc. As previously discussed, in some examples, at least a portion of the unique dealer identifier may be dynamically generated, and the same is true of the mobile application configuration information. While in some examples the configuration service 110 may have all possible combinations of factors (and corresponding mobile application configurations) pre-programmed, in other examples the configuration service 110 may be configured to dynamically identify the products corresponding to a given combination of factors, as and when that combination of factors is presented to it; and accordingly to dynamically generate the mobile application configuration information.

At (5), the configuration service 110 provides mobile application configuration information to the requesting end user by providing the mobile application configuration information to the end user device 102B. In response, at (6), the common mobile application incorporates the returned mobile application configuration information such that the mobile application becomes configured / customized in accordance with the dealer specified “preferences” (stored as dealer profde configuration information by the configuration service 110), as well as in accordance with any other relevant parameters, circumstances or variables (of the dealer and / or of the end user) that are stored or that have been inputted.

As will be described in greater detail below, in some embodiments (not shown), the software application 108 can process additional inputs unique to the end user (or applicable to the end user). Such additional inputs can be manually entered, provided via the configuration service 110 (such as via a user profile) or accessed from one or more data sources local to the end user device 102. Accordingly, in some embodiments, the customization or configuration of the mobile application 218 can consider both dealer specified configuration information and end user information. Illustrative embodiments of such multi-informational configuration will be further described below.

The end user can subsequently access the customized mobile application for ordering, fitting, troubleshooting, etc. The customized mobile application will display to the end user the subset of products that are appropriate for them, in view of the dealer-specified preferences / parameters and any relevant end-user-specific parameters. Likewise, for any functionalities relating to product troubleshooting / reordering / maintenance, the customized mobile application will display these functionalities to the user in a tailored manner factoring in any relevant dealer preferences / parameters (for instance minimum intervals between component servicing / replacement) and any relevant end-user-specific parameters.

It will be understood by one skilled in the art that different interactions with the configuration service 110 by different end user devices, such as illustrative end user devices 102A or 102C, may result in different mobile application configuration information being provided to the respective end user device 102A, 102C. In one example, if end users associated with respective end user devices are associated with different dealers, the individual end users would be provided different unique dealer identifiers. Accordingly, different mobile application configuration information may be provided by the configuration service 110 based on differences in the dealer profile configuration information provided by each respective dealer.

As previously indicated, a dealer may repeat at least a portion of the process illustrated in FIG. 6A to cause generation of multiple instances of mobile application configuration information, each associated with a unique dealer identifier, based on different dealer profile configuration information. Alternatively, or additionally, the configuration service 110 may automatically or semi-automatically generate multiple instances of mobile application configuration information (and thus unique dealer identifiers) based on obtained dealer profile configuration information. For example, the configuration service 110 may facilitate the generation of multiple unique dealer identifiers without the need for the dealer to repeat the process of inputting dealer profile configuration information. For instance, a given set of inputted dealer profile configuration information may correspond to multiple combinations of factors, each of which corresponds to a different “patient scenario” and thus is allocated a different unique dealer identifier. Accordingly, end users associated with a common dealer may be provided with different unique dealer identifiers.

In response, different mobile application configuration information may be provided by the configuration service 110 based on differences in the dealer profile configuration information and / or differences in the combinations of factors to which each unique dealer identifier corresponds. Thus, the dealer (and indeed multiple dealers) are able to point different end users to different subsets of products by giving to each end user the appropriate unique dealer identifier. Through the customization of mobile applications on end user devices 102, individual dealers can customize their product offering to their various customers, to ensure each customer (end user) only sees the products (and related information) that actually apply to them. Each unique dealer identifier corresponds to the circumstances that apply to that end user - e.g., type of illness / respiratory therapy, type of payment plan / insurance scheme, etc. Furthermore, aspects of the present application enable this customization to be provided via a common mobile application distribution and individualized mobile application customization approach, without dealers having to set up their own distinct data stores and interfaces.

In this regard a first end user device and a second end user device may correspond to two distinct end user devices 102 interacting with the configuration service 110 to obtain different mobile application configuration information as described herein. For example, in one illustrative embodiment, a common mobile application associated with a first end user device 102A and a second end user device 102B may be subsequently modified by different mobile application configuration information to present, on the first versus the second end user device, different subsets of medical devices (e.g., respiratory masks) or different configurations of subsets of medical devices. In one example, the individual end users associated with the end user device 102A and end user device 102B may be presented with different unique dealer identifiers based on interactions with different dealers. In another example, the end users may be presented with different unique dealer identifiers corresponding to a common dealer that has elected to provide different unique dealer identifiers to different end users, to increase the level of customization in what each user sees on their end user device (102A, 102B). The different dealer identifiers may correspond to and be selected/presented based on geographic criteria, funding sources, previous use/orders, disease type, respiratory therapy type, and other applicable factors or combinations of factors.

Turning now to FIG. 7, a routine 700 for mobile application configuration processing will be described. Routine 700 is illustratively implemented by an illustrative end user device 102 implementing a common mobile application that will be configured as described herein. For purposes of routine 700, it is assumed that a dealer has provided a unique dealer identifier to an end user or directly to the end user device 102. As described above, individual dealers or other entities can utilize a variety of interactions for providing unique dealer identifiers to end users or end user devices. Some such interactions can include interaction via dealer devices 104 and end user devices 102. However, not all such interactions require interaction via dealer devices 104 and end user devices 102. Furthermore, as also noted above, it is within the scope of the present application for the unique dealer identifier to be provided to the end user not by the dealer but by, for instance, the configuration service 110, or via some other channel.

At block 702, the end user device 102 obtains the unique dealer identifier. Illustratively, the unique dealer identifiers correspond to a unique or semi-unique code, image or other information that can be provided to individual end users or end user devices 102 as described herein. The unique dealer identifiers may be scanned, manually entered, etc. As an example, in FIG. 9A a common mobile application (e.g., “base” mobile application that has not yet been customized / configured) on an end user device 900 generates an interface 902 for receiving a manual entry of a unique dealer identifier. However, such examples are not intended to be limited and various aspects of the present application can encompass different means or protocols by which the unique dealer identifier can be received and / or transmitted. For instance, it is within the scope of the present application for this to be effected via the user clicking on a URL on their end user device 102; or by scanning a QR code on their end user device 102. Such actions may have the effect of obtaining the unique dealer identifier, and / or transmitting the request for mobile application configuration information. In some embodiments this may be achieved via the common mobile application; however, in other embodiments it may be effected independently of the common mobile application.

At block 704, the end user device 102 transmits a request for mobile application configuration information to the configuration service 110 with an associated unique dealer identifier. Responsive to the transmitted request, the configuration service 110 identifies relevant mobile application configuration information. In one embodiment, the configuration service 110 can associate mobile application configuration information that has been precompiled with the unique dealer identifier transmitted from the end user device at block 704. In other embodiments the configuration service 110 can dynamically generate at least some portion of the mobile application configuration information, such as dynamically updating medical device availability information, etc.

At block 706, the end user device 102 obtains mobile application configuration information from the configuration service 110. As described above, the mobile application configuration information can include any combination of executable code and data that result in the modification of the mobile application on the end user device in accordance with the dealer profile configuration information associated with the unique dealer identifier. For example, the mobile application configuration information can include executable scripts that remove or filter out some portion of the content that can be provided to users via the mobile application; and / or can include data or information utilized by the mobile application, such as billing codes, address information, shipping information, and the like. As previously described, the dealer- specified configurations / specifications / preferences can include, but are not limited to, the brands and / or mask types the dealer stocks / retails (and possibly also information as to current stock levels); and any applicable policies or parameters relating to mask reordering or maintenance, such as minimum time intervals and whether the mobile application is configured to automatically prompt the end user, or wait for the end user to actuate any such steps themselves. Furthermore, the dealer- specified configurations / specifications / preferences can also include user-specific details, such as (without limitation) the type of respiratory therapy the user requires, and the type of insurance plan they are under (or whether they are self-funded) - all of these may be further filters which define the specific subset of masks that it is appropriate to show to the user. Alternatively, or additionally, such userspecific details may be inputted independently of the dealer-specified configurations / specifications / preferences.

At block 708, the common mobile application incorporates the obtained mobile application configuration information such that the mobile application becomes configured / customized in accordance with the relevant dealer profile configuration information (and / or any user-specific details or information). The user can subsequently access the configured / customized mobile application for ordering, fitting, troubleshooting, etc.

At block 710, the user device 102 renders / displays any preconfigured user interfaces for interaction with the user and processes user input at block 712. (In some embodiments, in addition to or instead of interfaces, the user device 102 may also display specific information (e.g., blocks of informational text for the end user) at this stage). For purposes of the present application, the rendering and display of interfaces may be achieved utilizing functionality provided by the operating environment and hardware components of the mobile device. Blocks 710 and 712 can repeat. The interactions can include various interfaces and activities related to the presentation of medical devices available for use/distribution/sale, ordering information, maintenance and servicing of medical devices, patient health checks, information gathering, and the like. As previously discussed, the process can also include the deployment of one or more user interfaces that facilitates proper selection and fitting of the subset of respiratory masks, including measurement of patient attributes (e.g., facial features), sizing information and suggestions/recommendations for sizing and adjustment. The inclusion of one or more such interfaces or content utilized to generate and render the interfaces may be provided in the dealer profile configuration information and may accordingly affect the subset of masks that are displayed to a user per the relevant instance of mobile application configuration information. Alternatively, or additionally, the content associated with the one or more such interfaces may be employed distinctly, such as via a subsequent information exchange that occurs subsequent to the protocol of the present application.

For example, the user interfaces can correspond to user input interfaces configured to collect end user preferences or end user attributes that can be utilized as inputs to provide recommendations/suggestions for specific respiratory masks that may be selected by an end user, information regarding how respiratory masks may be sized or adjusted, and the like. FIG. 9B depicts an end user device 910 associated with a dynamically configured mobile application including a sequence of interfaces 910A, 91 OB, 910C for facilitating respiratory mask selection and sizing. The sequence includes individual interfaces 912, 914, 916 that includes information/questions for identifying respiratory mask attributes, conducting sizing which may use camera functionality, and identifying recommended/suggested respiratory masks.

Options to include / skip Mask Fitting Applications:

The configuration service may include functions, for example software applications, for mask sizing, or at least providing size recommendations to the end user. These functions may include mask fitting software which utilizes cameras available to the end user device to capture images of the face of the end user to assist with mask sizing, for example the application may capture facial scans and determine facial dimensions from the facial scans for mask fitting. Such functions may be activated or deactivated as part of the configuration of the mobile application. For example, if the configuration service is aware of the end user facial dimensions or mask sizes, then this data may be stored in a database accessible by the configuration service. If the data is available, then mask fitting applications may be deactivated as part of the mobile application configuration since the system already has mask fitting data available for the patient.

In other examples, mask fitting applications may be integrated as part of the mobile application customization. The mobile application may also include mask sizing data. The mobile application may be customized to allow the end user to select whether to use existing facial dimensions which have already been acquired and stored in the system, or to select to execute the mask fitting application. The mobile application may also be configured to prompt the end user to initiate mask fitting software to run a mask fitting sequence in a number of situations: for example after a predetermined time period has expired from the last mask fitting; if the user wishes to order a new mask type (for example under nose, or nostril mask); or if the user does not have mask fitting measurements stored in the system.

The mobile application may be customized to execute mask fitting software automatically on initial customization of the mobile application after the end user has accepted the invite. If the system already has mask fitting data stored for the end user, the mobile application may present an option to the end user to skip the mask fitting sequence. The system may refer to a mask fitting sequence (and dimensions obtained therefrom) which the user has previously executed, and use these dimensions for the purpose of determining the appropriate size of a new mask. In this regard, the mask fitting sequence may obtain facial dimensions relevant not just to one type of mask, but for all (or multiple) types of masks, to be able to use this information for subsequent mask selection/sizing without requiring the user to rescan their face.

Other software applications may be included in the configured mobile application. In another example, and as noted above, the mobile application can be configured with specified dealer profile configuration information in the form of different medical device service/maintenance preferences such as timing information for the selection of when the mobile application will initiate an inspection or check of medical devices (e.g., a series of user interfaces designed to elicit an inspection of respiratory masks), such as frequency of the inspections/checks, substance of the inspections/checks and whether the inspection/ check is initiated automatically, upon manual request or a combination thereof. Accordingly, the mobile application can generate various interfaces associated with this configuration of the mobile application. FIG. 9C depicts an end user device 920 associated with a dynamically configured mobile application including a sequence of interfaces 920A, 920B, 920C for facilitating the end user health checks associated with use of a respiratory mask. The sequence includes individual interfaces 922, 924, 926 that includes information for identifying a respiratory mask, conducting checks/inquiries, and facilitating additional ordering/replacements.

It will be understood that the configuration depicted in FIG. 9C is merely exemplary, and that one or more aspects of the present application encompass a range of different “exit points”, that is to say, means or protocols via which orders, requests, commands or communications (“communications”) can be sent to the dealer (or other relevant third party). F or instance, said communications could be conveyed via various channels such as SMS or email. Also, instead of the protocol depicted in FIG. 9C, a QR code associated with the respiratory mask could be utilized. Furthermore, instead of the protocol depicted in FIG. 9C, the mobile application could be integrated with an online facility of the dealer, such as on a Web site or online store, via which communications (such as reordering) take place. In still another example, the mobile application can be configured with specified dealer profile configuration information identifying different types of end user (e.g., patient) compliance data, general or specific end user health data or other medical condition check preferences initiated by, or facilitated through, the mobile application. Illustratively, this can include types of intervals for compliance data logging, types of health inquiries and intervals for initiating such health inquiries, government mandated checks, insurance provider mandated checks, and the like. The dealer profile configuration information generated/provided by the individual dealers 104 can include a specification as to how end user information is collected (e. g. , fillable form or free text) and various security/authentication protocols or procedures associated with maintaining the collected data on the end user device 102 or transmitting collected data to another computing device. Accordingly, the mobile application can generate various interfaces associated with this configuration.

In still another example, the mobile application can be configured with specified dealer profile configuration information in the form of ordering preferences or payment or financial arrangement preferences related to ordering the medical devices. Accordingly, the mobile application can generate various interfaces associated with this configuration.

In accordance with aspects of the present application, different “entry points” for the customized mobile application may be provided. In the example of FIG 7, the unique dealer identifier is obtained; based on this, mobile application configuration information is requested and obtained; and then the “base” version of the mobile application on the end user device is configured / customized in accordance with the received mobile application configuration information. Different versions of, or variations on, this are possible. For example, a dealer (directly or indirectly) may send to an end user device 102 a message comprising a link which causes the preinstalled “base” or “common” version of the mobile application on the end user device to launch a page or screen requesting input of the unique dealer identifier (which may also be sent by the dealer, together with or separately from the message). In another example, the link sent by the dealer to the end user device 102 may trigger a download of the “base” or “common” version of the mobile application, followed immediately by customization of the mobile application. In still another example, the link sent by the dealer to the end user device may cause download of an already-configured (customized) version of the mobile application; in this case the “base” version may exist on the system but may not be downloaded to the end user device as such.

Turning now to FIG. 8, a routine 800 for mobile application configuration processing will be described. Routine 800 is illustratively implemented by the configuration service 110 for implementing configuration of a mobile application as described herein. At block 802, the configuration service 110 receives a dealer identifier from an end user device 102 along with a request for associated mobile application configuration information.

Responsive to the transmitted request, at block 804, the configuration service 110 identifies relevant mobile application configuration information. In one embodiment, the relevant mobile application configuration information has been precompiled and is stored, in its entirety, at the configuration service 110. In other embodiments, the configuration service 110 can dynamically generate some portion of the mobile application configuration information, such as by dynamically updating medical device availability information, etc. As described above, the mobile application configuration information can include any combination of executable code and data that results in the modified (i.e. customized / configured) mobile application in accordance with the dealer profile configuration information.

The dealer profile configuration information can correspond to customization “preferences” (including restrictions / limitations / conditions / criteria / requirements) which can include a selection of medical devices that are available for sale/distribution by the dealer, medical device service/maintenance preferences, patient health or medical condition check preferences, ordering preferences, payment or financial arrangement preferences, and the like. As also described above, a dealer may establish (or the system may automatically or semi- automatically establish, either ahead of time or on an ad hoc basis) multiple sets of mobile application configuration information, each pointing to a different subset of the dealer’s masks. For example, two end users (engaging the dealer) with different medical situations or circumstances may be given two different unique dealer identifiers by a dealer, each pointing to a different set of mobile application configuration information, which in turn leads the respective end user devices to display a different subset of masks on the end user devices upon configuration / customization of the mobile applications on the end user devices. At block 806, the configuration service 110 transmits responsive mobile application configuration information. For example, some aspects of the mobile application configuration information can include executable scripts that remove or filter out some portion of content that can be provided to users via the mobile application. Other aspects of the configuration information can include data or information utilized by the mobile application, such as billing codes, address information, shipping information, and the like.

At block 808, the routine 800 terminates. However, as described previously, the interactions can include various interfaces and activities related to the presentation of medical devices available for use/distribution/sale, ordering information, maintenance and servicing of medical devices, patient health checks, information gathering, and the like.

It will be understood from the foregoing that aspects of the present application encompass numerous possible “entry points” for end-user-specific data / information (such as health conditions, therapy protocol, and insurance coverage or funding situation). One option is that the dealer may determine these user-specific details ahead of time and provide the end user with a corresponding unique dealer identifier that is processed to customize the mobile application so that it will be configured to provide information, such as the identification of a curated (tailored to the user) set or subset of respiratory masks selected by the dealer.

By way of illustrative examples, the dealer may know (or find out) that a particular end user requires CPAP therapy, and is fully insured; and may provide them with a unique dealer identifier that corresponds to these initial parameters. This unique dealer identifier may already exist in the system, or it may be generated on a case-by-case basis, such as by entering supplementary user-specific information and causing a unique dealer identifier to be generated accordingly. Another option is that the mobile application configuration information is configured to, in use, obtain this information from the user. For instance, as discussed above, the mobile application configuration information may be configured to actuate user interfaces on the end user device which elicit the relevant information from the end user, based on which the mobile application is configured / customized. Still another option is that such user interfaces are displayed to the user post configuration / customization of the mobile application, and act to modify (such as obscure from view) some of the information displayed to the user.

FIGs. 1 OA, 1 OB and 1 OC are schematics depicting how data is organized in the system according to one or more exemplary embodiments. As noted earlier, the “customization factors” 1026 referred to in this embodiment relate essentially to a plurality of variables that have been discussed above. Such customization factors can illustratively include, but are not limited to specified attributes, configuration selection criteria, user-specific parameters, dealer specific parameters, and the like. The “customization indicators” 1028 referred to in this embodiment essentially correspond to combinations of customization factors that can be then represented or mapped to “unique dealer identifiers.” Specifically, individual rows in the combinations illustrated in table 1028 correspond to a selection of factors from the plurality of factors identified in table 1026 with each “customization indicator” acting as a “tag” that uniquely corresponds to a particular combination of the “customization factors” 1026.

Accordingly, as with the unique dealer identifiers discussed above, the “customization indicators” 1028 are provided (directly or indirectly) to end user devices 102 and serve to instruct how to configure the base mobile application on each end user device 102 to result in a customized mobile application (as described herein). Illustratively, customization indicators can act as inputs that can be processed to make a determination of whether specific respiratory masks will be displayed and associated information made accessible. Illustratively, the processing of the customization indicator 1028 information can be achieved using programmatic approach, such as a rules-based system. For example, a programmatic approach might indicate that one or more factors may be deterministic of whether information for a specific respiratory mask will be displayed. Similarly, one or more factors may be deterministic of whether information for a specific respiratory mask will not be displayed. In other embodiments, one or more machine learned algorithms may be trained to process a specified customization indicator 1028 (including values for customization factors indicated in the individual customization indicator). In such examples, the customization factors 1026 indicated in the customization indicator 1028 may be at least partly dynamic in nature. For example, a machine learned algorithm may process a large set of inputs, including the customization factors underpinning a particular customization indicator, and generate confidence values indicative of whether individual respiratory masks are relevant and should be displayed. One skilled in the relevant art will appreciate that various other exemplary processing routines could be implemented as well.

The “customized displayable data set information” 1030 is information identifying and pertaining to the subset of products (e.g., respiratory support devices, such as masks; the term “masks” is used herein for convenience) that corresponds to each customization indicator, that is to say, to each unique combination of factors. While in FIGS 10A, 10B and 10C the “customized displayable data set information” is illustratively depicted as being an indication (Y/N) of whether each of Masks 1 - X is available for each customization indicator 1028, this is not intended to be limiting and the “customized displayable data set information” could comprise a range of other product-related information. As previously discussed, the customization factors 1026 and/ or customization indicators 1028 (i.e., combinations of factors) may variously be inputted / established ahead of time (such as being comprised in the dealer profile), or may be inputted on an ad hoc basis to effect further customization, for instance when a bespoke “patient scenario” arises (being a patient having a combination of factors that is unique, or semi-unique, to them). As also noted further above, in some embodiments one or more user interfaces may be employed as a means of gathering end-user-specific information - such user overlays may be actuated as part of the system of the present application, or “downstream” of it.

In FIGs. 10A, 10B and IOC, a larger set of data that may be centrally processed and maintained according to aspects of the present application is schematically indicated at 1020. Specifically, data 1020 may represent a plurality of potential customization indicators 1028 that may have been specified by one or more dealers. In contrast, individual instances of mobile application customization information that needs to be provided to the end user device 102 (not shown) for customizing the base mobile application 218 on the end user device 102 is schematically indicated by the bold line 1022.

More specifically, the centrally-stored data 1020 can include a plurality of customization factors 1026, a plurality of customization indicators 1028, each corresponding to a different combination of the customization factors 1026, and, for each customization indicator 1028, corresponding customized displayable data set information 1030, being information as to the subset of masks / products that is relevant for that customization indicator

1028, in other words that is relevant to that combination of factors 1026. The customized displayable data set information is indicative of the processing of the customization indicators, which can include whether to display information regarding respiratory mask information, whether to not display information regarding respiratory mask information or otherwise customize information related to the display of respiratory masks information.

In contrast, the data 1022 provided to individual end user devices 102 for customizing the mobile application 218, in some embodiments, may be limited solely to the customized displayable data set information corresponding to the customization indicator 1028 (mapped or correlated to a unique dealer identifier) that the end user has been given (directly or indirectly) as an entry point to the customization process(es) described herein. The customization indicator, when processed as described herein, indicates only that subset of masks (and related information) which are actually relevant to the end user (also referred to herein as “customer” or “patient”), and thus only downloads that subset of information corresponding to respiratory masks (and related information) and causes the modification or update of the “base” or “common” application therewith, to yield the customized / configured mobile application on the end user device 102.

Thus, it will be appreciated that one or more aspects of the system 100 promotes computational efficiency in that only a small portion of the centrally-stored data needs to be processed by the user electronic device - both in terms of initial downloading / processing when configuring the “base” / “common” mobile application and in terms of subsequent updates. One or more aspects of the system 100 also promotes computational efficiency in that dealers need not each establish and maintain their own individual mobile application; rather, they can tap into the centrally-stored data. More particularly, they can use the relevant customization indicators indicate the subsets of respiratory masks (in the centrally stored database) which apply to, and thus should be displayed to, a given end user.

In some embodiments, it may be adequate for the customization indicators 1 - N (as shown in FIG. 10A) to be used by different dealers. For instance, the customization indicators 1028 may denote combinations of factors that are relatively common / ubiquitous, and thus frequently apply to customers of different dealers. One illustrative example of a common / ubiquitous combination of factors (e.g., “patient scenario”) might be a CPAP patient who is insured under a default or standard insurance policy, which may render them eligible for a predetermined range of masks. Thus, a customization indicator corresponding to this combination of factors can be processed on the patient’s end user device such that their mobile application is customized or configured to display that predetermined range of masks.

In addition to the above, such customization or configuration may also be tied to additional information provided by individual dealers, such that the same combination factors (e.g., CPAP patient who is insured under a default or standard insurance policy) may yield different customization of the mobile application based on the factors attributable to the individual dealers. In such cases, it may be desired or appropriate for at least some of the customization indicators 1 - N to be dealer-specific. Illustratively, this may be achieved via the dealer identifier (such as a numerical sequence identifying a particular dealer) being included as a “customization factor”, with the effect that all customization indicators that include the dealer identifier as a factor will of necessity be unique to that dealer. This is schematically illustrated in FIG. 10B. “Factor D” is the customization factor denoting the identifier. Correspondingly, in the “combinations” table, i.e. the table of customization indicators, indicators number 6 and 7 are shown. It will be seen that indicators number 6 and 7 both represent a combination of Factors 1 and 5 - in other words, they represent the same “patient scenario” (e.g., a CPAP patient who is insured). However, indicator 6 further includes the factor that the dealer is DI (“F(D1)”), while indicator 7 includes the further factor that the dealer is D2 (“F(D2)”). Thus, dealers 1 and 2 each have a unique customization indicator for their own use, even though these indicators denote the same “patient scenario”.

Also shown in FIG. 10B are customization indicators number 10 and 11. These now represent different “patient scenarios” - a combination of Factors 1 and 5 and, respectively, 16 and 63. For instance, customization factors 1 and 5 might denote a CPAP patient with an underlying diabetes condition; with factor 16 denoting that the patient is a smoker while factor 63 denotes that the patient is self-funding their device maintenance costs (this is given by way of illustrative example only). Again, the dealer identifiers (“F(D1)” and “F(D2)”) serve to uniquely tie customization indicators number 10 and 11 to, respectively, dealers 1 and 2. This may be advantageous in situations in which customization factors may be more unique or specific to individual dealers, and provides flexibility for the mobile application 218 to be uniquely customized according to requirements or preferences of a particular dealer (or even to a particular customer). Such customization may be completed in a manner that is independent of, or otherwise agnostic to, the number of common applications that are customized or configured. It might also be advantageous where the factors defining the “patient scenario” are themselves relatively ubiquitous, but the dealer wishes to superpose onto this a further factor, such as the dealer’s specific refund or warranty policy.

A variation on this is schematically shown in FIG. 1 OC, which is similar to FIG. 1 OB but further illustrates that one or more relevant customization indicators 1028 may be “tied” to dealer 1 or dealer 2 - Dl(6), D2(7), Dl(10), D2(l 1). A more generalized version of this is that the prefix (or suffix, or other portion, or even non-numerical portion) of the relevant customization indicator might correspond to a particular dealer’s unique identifier. For instance, the numbering protocol of the customization indicators might be “DDDD- XXXX”, with “DDDD” uniquely identifying a particular dealer (e.g. always 0001 for dealer 1), and XXXX indicating the particular combination of customization factors.

In accordance with another embodiment, a “hybrid” embodiment can include scenarios in which one or more customization indicators are “generic” or “shared” and that are not directly associated to a particular dealer or are otherwise not required to be selected or configured by any particular dealer, while other customization indicators are allocated to particular dealer. For instance, those customization indicators which correspond to ubiquitous combinations of factors may be “generic” or “shared”, such that multiple dealers can use them; while customization indicators, corresponding to combinations of factors which are “bespoke” or “tailored” for a particular dealer (or even to a particular customer of a particular dealer), may be peculiar to that dealer, and may be denoted as such as illustrated in Figures 1 OB and C.

From the foregoing, it will be understood that the invention has a number of advantageous aspects. For one thing, the fact that the various customization factors can be combined together in as many combinations / variations as required means that there can potentially be as many customization indicators as there are customer scenarios / circumstances. This may mitigate against displaying respiratory masks which do not actually apply, or are not actually available to, a particular end user. Rather, the dealer can provide the end user with the particular customization indicator that applies to that specific end user... The end user’s mobile application 218 on their end user device is then configured in accordance with the relevant customization indicator, that is to say, the “customized displayable data set information” tied to that customization indicator is used to customize / configure the mobile application. This means the customer only sees those products (and any related information) that are relevant and / or available to them.

This advantageously overcomes the prior art limitation of customers being given generic information about masks (e.g. via websites), with no, or insufficient or inadequate, filtering or customization specific to the customer (and / or to the dealer or other relevant party), potentially resulting in the customer researching, shortlisting or selecting masks which are not in fact available to them (and / or available from their dealer), in turn leading to confusion, frustration, inefficiency, and wasted time on the customer’s and / or dealer’s part.

A related advantage of the system is that individual dealers do not need to create their own applications or platforms to accurately and reliably display to customers their product range. Rather, they can tap into the system’s central data store, with its comprehensive product inventory, and use the customization indicators as an “overlay” to direct each customer to the specific subset of products that is appropriate for (and available to) them.

Furthermore, the architecture of aspects of the present application has advantages to do with computational efficiency. The relevant factors (Factor 1 - Factor X) (e.g., dealer attributes / preferences, brand and product information, type of customer payment plan or insurance plan, type of respiratory therapy, et cetera), and the relevant combinations of these factors (customization indicators 1 - N, in other words combinations 1 - N of customization factors 1

- X) are centrally stored in the system, in one or more data stores on one or more suitably configured computer devices.

Also centrally stored in the system is the “customized displayable data set information” corresponding to each customization indicator 1 -N; such as (without limitation) information as to whether each product of a range of products is available for that customization indicator. Thus, for a customization indicator relating to CPAP therapy, nasal high-flow masks will generally not be available, and vice versa; and this will be reflected in the respective “customized displayable data set information”. Furthermore, a customization indicator relating to CPAP therapy for an insured patient may indicate that, for instance, masks 2 - 4 are available, while a customization indicator relating to CPAP therapy for an uninsured patient (such as a patient relying solely on state funding / subsidies) may indicate that, for instance, only mask 3 is available; and potentially a customization indicator relating to CPAP therapy for a self-funded patient may indicate that, for instance, masks 2 - 6 are all available

- or some subset of these, if a further factor of Factors 1 - X indicates that the self-funded patient has budget limitations. (As discussed earlier, in some embodiments some of this data may also be dynamically generated, rather than being stored ahead of time).

The data centrally stored (or generated) in this manner is schematically indicated by 1020. It will be appreciated that this data may be extensive and take up significant space. Accordingly, because in some embodiments, only a subset of data (schematically indicated by 1022 - FIGS 10A, 10B, IOC) that is relevant to a particular end user needs to be provided to the end user device 102 for processing, this approach creates additional efficiencies with at least regard to data management, data transmission, data processing and the like. In some embodiments, other information - the remainder of 1020 - not relevant to the subset 1022 can be filtered or processed in a manner that does not require transmission to the end user device 102. This may entail significant advantages in computational and bandwidth efficiency. Specifically, the customer initially downloads a “base application” - this is a “skeleton” version of the application, having the general layout of the application but not yet populated with data (or only populated with relatively minimal data).

Once the customization indicator (indicator 1 - N) that is relevant to the particular customer is identified, being the particular combination of customization factors (Factors 1 - X) that apply to the customer, that customization indicator points to the relevant “customized displayable data set information” - being information as to the particular products that are / are not available to the customer. A base version of the mobile application 218 (FIG. 2) (as described herein) can then be customized per the “customized displayable data set information”, such that at least one of the controls, information displayed, interaction, functionality, etc. is modified according to the customization. For example, the customized mobile application may be customized such that only those products (and related information) relevant and available to the customer are displayed on the end user device 102. Illustratively, customization per the “customized displayable data set information” can involve downloading data relating to the relevant products (and related information) from the central data store. Additionally, customization can further involve the displaying (or, as the case may be, prioritizing or obscuring) of pre-existing information already included in the base mobile application as maintained on the end user device 102.

By way of non-limiting example, the base mobile application may include a number of particularly popular masks, on the assumption that many or most customers (users) will be eligible to see these. But if the individual customer’s “customized displayable data set information” indicates that one or more of these masks are not suitable for the customer, the “customized displayable data set information” will include computer- executable instructions to obscure (remove from view) those masks in the customized mobile application 218. Furthermore, one skilled in the art will appreciate that any of the aspects data 1020 may routinely need to be updated - for instance, as a particular dealer adds or removes products from their range, as product availability and pricing fluctuates, as regulations regarding mask usage change in different countries, as insurance or funding policies change, et cetera. Such updates will be effected in the central data store(s) of the system, for instance periodically or on an ad hoc basis. The same applies for any changes to customization factors and / or customization indicators that may be inputted from time to time, for instance to reflect changing dealer circumstances or bespoke “patient scenarios”. It will be appreciated that, just as the volume of centrally stored data (1020) may be significant, so the updates thereto may be frequent and computationally expensive.

However, since the mobile application 218 on each end user device 102 may only be provided with the relevant subset (1022) of data, generally speaking only updates related to that particular subset (1022) need to be effected on the user’s device. Advantageously, this means that the mobile application does not need to run updates relating to products not included in the relevant subset (1022). This may significantly reduce the number of update alerts / prompts the user receives, improving computational efficiency. It may also improve functionality / usability of the mobile application - not only in terms of user convenience (viz. avoiding the inconvenience of frequent and potentially irrelevant updates), but also by preventing the mobile application from potentially being “blocked” (prevented from operating properly) by outstanding updates which relate to products outside of the relevant subset (1022).

FIG. 11 is a schematic illustrating, in simplified form, the different “entry points” at which mobile application information (MACI) and unique dealer identifiers (UDIs) may arise or come into being in the system according to illustrative aspects of the present application. For simplicity, FIG. 11 is discussed herein with reference to a single dealer; however, it will be appreciated that the same schema can apply to a plurality of dealers using the customization service.

At a first time, “tl” as indicated at 1101 (time being schematically indicated by line 1120), for instance during or around the time when a dealer is establishing their dealer profile, the dealer may enter into the system a first set of their dealer attributes / preferences 1104, that is to say their “dealer profile configuration information”. Illustratively, “X” such dealer attributes / preferences may be entered, being attributes / preferences 1 - X. For instance, at this stage the dealer may add in relatively simple, predictable or ubiquitous attributes / preferences, such as relating to their address, their shipping protocols, any brands / product lines they stock or do not stock, etc. Illustratively, at tl there may also be entered attributes / preferences 1106 pertaining to end users of respiratory therapy devices - such as different disease states, therapy types, insurance plans, underlying diseases, etc. Illustratively, “X” of these user attributes / preferences may be entered as well (where “X” may be the same number or a different number as the “X” dealer attributes / preferences), being user attributes

/ preferences 1 - X. These user attributes / preferences may be entered distinctly from the dealer attributes / preferences, or they may be entered (or at least partly entered) as part of the dealer attributes / preferences. For instance, the dealer may, as part of their attributes / preferences 1104, specify the range of diseases states / therapy types they cater to, as well as any attributes / preferences relating to insurance / payment plans or policies, etc.

Based on the information as to attributes / preferences (aka “factors”) 1104 and 1106 entered at time tl (1101), a first set of mobile application configuration information (MACI) 1102 can be generated. This may, depending on the type of attributes / preferences and other factors, occur automatically, semi-automatically (such as based on information previously entered by the dealer), and / or may require at least some manual input from the dealer.

As discussed above, the MACI is in effect information as to how the mobile application should be customized / configured for various different combinations of the input attributes / preferences 1104, 1106. Each MACI corresponds to the particular range of products and other information that would be available / applicable to an end user having one of the possible combinations of the input attributes / preferences 1104, 1106. Thus, illustratively, an end user having OSA, needing a CPAP device, being fully insured, having diabetes as an underlying condition and living in Australia (each of these notionally being an “attribute / preference” 1104, 1106) will correspond to a specific MACI and will thus see on their mobile application, once configured, the specific range of products and other information that apply to / are suitable for their circumstances. Another end user having a different combination of factors 1104, 1106 will (or at least may) correspond to a different specific MACI and thus will (or at least may) see a different specific range of products and other information once their mobile application is customized / configured per that MACI.

Illustratively, the number of MACIs can include the total possible combinations of input attributes / preferences 1104, 1106. However, in other embodiments, the number of MACIs can be a number less than all the total possible combinations. Some specific combinations may not be practically possible, such as where a particular type of mask is not suited for treating a particular disease; where particular rules, regulations or prohibitions apply; or where a dealer does not supply a particular brand or product or cater to a particular disease type or a particular insurance plan or insurance provider. Furthermore, it is possible for a given MACI to apply to more than one distinct combination of input attributes / preferences 1104, 1106 - for instance because two (or more) different combinations of factors 1104, 1106 are serviced by an identical range of products. Thus, there may in practice be fewer, even far fewer, MACIs than there are possible combinations of factors 1104, 1106. Illustratively, FIG. 11 shows 100 MACIs (MACH - MACH 00). Practically speaking, a given dealer may require, for instance, 10 or 20 MACIs (or even fewer than this) to account for the different circumstances applying to the customers (end users) they service.

As discussed further above, each MACI 1102 corresponds to a unique dealer identifier (UDI) 1116. The UDI is what is supplied (directly or indirectly) to the end user to enable configuration / customization of a “base” version of the mobile application on the end user device according to the MACI 1102 that applies to that end user. As discussed elsewhere, the UDIs 1116 may take different forms. For instance, each UDI may comprise a first portion corresponding to a particular dealer, and a second portion corresponding to the subset of products corresponding to the MACI that UDI is tied to. Alternatively, one or more of the UDIs may be “agnostic” as to dealer, i.e. not be linked to a particular dealer, in which case multiple dealers can potentially make use of that UDI. Some or all of the UDIs 1116 corresponding to the tl MACIs 1102 may be created and stored in the system substantially at the same time as the MACIs 1102. Alternatively, some or all of the UDIs 1116 be created and stored at some later time, such as when a given MACI is actually required or triggered by an end user having a combination of factors corresponding to that MACI; prior to which the MACI may sit latently in the system, without an accompanying UDI.

At time t2, illustrated at 1103, subsequent to tl (1101), further dealer attributes / preferences 1110 and / or user attributes / preferences 1112 may be inputted into the system. Said further attributes / preferences 1110, 1112 may, for instance, relate to new brands / product lines the dealer has begun stocking; or new insurers or insurance policies they now recognize; new underlying diseases or comorbidities; newly developed therapy regimes; etc.

These new factors 1110, 1112 mean there are now additional possible combinations of factors - both of the new factors 1110, 1112 in their own right, and of and the new factors plus the existing factors 1104, 1106, which are pulled in as schematically indicated by 1114. Thus, the system must add further MACIs 1108 corresponding to these additional possible combinations of factors (with the further MACIs 1108 again denoting the range or subset of products and information that is applicable to each of the additional combinations of factors). As above, while in theory the number of new MACIs 1108 is equal to the number of combinations of (some or all of) factors 1104, 1106, 1110, 1112, in practice the actual number of MACIs 1108 commercially required will likely be far fewer. In Figure 11 additional MACIs 101 to 1000 are depicted, for purposes of illustration.

As before, each of the new MACIS 1108 will need to be designated by a UDI 1118. The additional UDIs 1118 may be created substantially at the time of creation of the additional MACIs 1108, or at a later time, such as when a given MACI is triggered. Thus, subsequent to t2, the full set of MACIs in the configuration service is 1102 plus 1108, and the full set of UDIs in the configuration service is 1116 plus 1118.

One embodiment of the process associated with a subsequent time period, e.g., time period t2 (1103), can include embodiments in which a dealer has a client having a unique or bespoke combination of circumstances, said combination not being described by a MACI in the system. If one or more of said individual circumstances is not yet entered as an attribute / preference in the system, the first step taken will be to enter it, per 1110 and / or 1112. This may be done by the dealer; alternatively, in some examples it may be done by the end user, such as via suitably configured user interfaces. After said one or more individual circumstances have been entered into the system, one or more MACIs incorporating that new circumstance may be generated, along with one or more corresponding UDIs, the appropriate one of which may then be conveyed to the end user to allow them to configure / customize their mobile application and view the subset of products and information that is appropriate for that end user. Alternatively, all the underlying circumstances may already be present in the system, but not the specific combination thereof. In this case, the system may be prompted to create a MACI, and a corresponding UDI, fitting the specific combination of circumstances / factors that has arisen.

In some examples, the MACIs 1102 and the UDIs 1116 may be added / removed over time, such as when new attributes / preferences arise (and / or new combinations of same), or when, due to commercial factors, regulatory changes, or other factors, one or more MACIs become redundant. FIGs. 12A and 12B show the schema of FIG. 11 combined with an overall product database 1200 as would be used in the system of the present application. The database 1200 stores all product information (and related information) relating to the entire range of products offered by a manufacturer or manufacturers, prior to any filters, factors or criteria (such as dealer identity, disease state, or insurance type) being applied. In other words, the database is an inventory of all potentially available products.

Illustratively, the products may be categorized in the database 1200 (category A, B, C), for instance by product type, products meeting a particular regulatory standard or approval or associated with an insurance category, or any number of other criteria.

As discussed above, the MACIs each correspond to one particular combination of the input factors 1104, 1106, 1110, 1112. Thus, MACH might illustratively correspond to a fully insured OSA sufferer needing a CPAP mask and residing in Australia (while this example comprises a combination of 4 factors, it will be understood that a given scenario may comprise more, or fewer, factors). A specific subset of the inventory of products in the database 1200 will be applicable to / appropriate for an end user having this combination of factors. As indicated in Figure 12A, this specific subset of products in the overall inventory

is associated with MACH, such that MACH is in effect a “pointer” to those products. In turn, UDI1 is used as a “pointer” to MACH. UDI1 is supplied directly or indirectly to the end user device 1220 and is then used by (or on behalf of) the end user to “point” to the relevant MACI (MACH), which in turn identifies the particular subset of corresponding products (and other information). The end user’s base mobile application on the end user device 1220 is then configured / customized accordingly, such that the end user is able to browse, select, purchase, etc. that particular subset of products and other information.

FIG. 12B shows the same schema applied to a different MACI, MACI2. MACI2 corresponds to a different combination of input factors 1104, 1106, 1110, 1112 - for instance, a self-funded (uninsured) OSA sufferer needing a CPAP mask in the USA. MACI2 serves to pinpoint that subset of products (and related information) in the overall database 1200 for which an end user meeting this combination of factors is eligible. Thus, when the corresponding UDI (UDI2) is subsequently used to effect customization of the mobile application on that end user device 1220, MACI2 will cause the customized mobile application to display that subset of products and related information, which the end user can then browse, select, purchase, etc.

In further embodiments, the same schema can be applied to a different MACI, MACI3. MACI3 corresponds to a different combination of input factors - for instance, a hospital in New Zealand. Hospitals may be eligible for a full range of products or may be eligible for a limited range of products based on certain criteria, for example government funding levels. MACI3 serves to pinpoint that subset of products (and related information) in the overall database 1200 for which the end user (i.e. the hospital) meeting this combination of factors is eligible. Thus, when the corresponding UDI (for example, UDI3) is subsequently used to effect customization of the mobile application on that end user device, MACI3 will cause the customized mobile application to display that subset of products and related information, which the end user can then browse, select, purchase, etc.

Such a schema has computational and other advantages, as has been discussed above with reference to FIGs. 10A-10C and elsewhere. In essence, using each MACI to “tag” or identify the specific subset of products corresponding to it means that the overall database 1200 can be vast, but each individual user device need only to be directed to, and to download / interact with, that specific subset of products (and related information) which is applicable to that end user.

In some examples, the system includes practical means for enabling dealers to readily identify and access the attributes / preferences and MACIs / UDIs they require access to. For instance, a dealer interface of the system may comprise a searchable (and selectable) list of attributes / preferences, which a dealer may use to select the particular combination of factors they are looking for and find the corresponding MACI (and thus UDI). Said list may have the most ubiquitous or common attributes / preferences at the top, or in a separate list, for easy reference. Furthermore, a dealer’s most commonly used MACIs (and / or UDIs) may be saved for future reference. In another example, it may also be possible for a dealer to search by a combination of end products, rather than by a combination of underlying factors. For instance, the dealer may wish to identify a MACI(s) and UDI(s) corresponding to all of Brand A’s products, and some subset of Brand B’s products (e.g. only B’s CPAP masks), regardless of what underlying factors those MACIs correspond to. Still further, an additional or alternative solution may be for the system to enable a given dealer to assign a name/title to one or more of the UDIs they use; this name/title may be superposed on the original UDI on the dealer’s display, giving the dealer an easy reference-point to orient themselves as to which UDI corresponds to which combination of factors. An example of this is shown in FIG. 26.

As noted further above, in some embodiments the UDI is transmitted through the system automatically. For instance, an “invite” (i.e. communication, message, alert) created or caused to be created by a dealer may contain or have embedded within it a code or “invite ID” identifying at least the identity of the dealer. The identity of the dealer can be automatically detected by the system if the dealer is logged into their account when creating (or causing to be created) the “invite”. When the end user interacts with the “invite”, the system may retrieve the code or “invite ID” and, based at least partly on this, identify the appropriate mobile application configuration information for customizing the end user device. The above- discussed “practical means for enabling dealers to readily identify and access the attributes / preferences and MACIs / UDIs they require access to” may complement this. For instance, when the dealer selects a given set of attributes as shown in FIG. 26, their selection may form part of the code or “invite ID” that subsequently gets transmitted together with the invite. Upon subsequently retrieving the code or “invite ID”, the system may use this information to identify the mobile application configuration information appropriate for that particular case.

FIGS. 31 and 32 exemplify this. FIG 31 exemplarily depicts a relatively simple version (generally indicated by 5000), for instance where the dealer only has one set of MACI associated with them. The dealer 5004 is logged into the system 5002, and is uniquely identified as dealer 123, and this is their dealer ID. The dealer 5004 generates, or causes generation of, an “invite” 5008 to be sent to a patient’s end user device. The system recognizes that the invite originates from dealer 123. The invite appears on the end user device 5010. In this example, the invite is in the form of a URL for the end user to click on. Embedded or contained in the invite is an “invite ID” 5012. In this example the invite ID 5012 is depicted as being embedded in the URL itself; however, this is not intended to be limiting. Exemplarily, the invite ID 5012 is made up of an invite number 5014, which is a number identifying this specific invite, and the dealer ID 5016, which identifies the dealer (dealer 123) from whom the invite originated. At the appropriate time, such as when the end user clicks on the URL, the system retrieves the dealer ID 5016 from the invite ID 5012. The system then queries 5018 the stored MACIs 5006 to identify the MACI that corresponds to the dealer ID 5016. The system then uses 5020 this MACI to cause the application to be customized on the end user device, such that a customized version of the mobile application 5022 is presented on the end user device.

FIG. 32 exemplarily depicts a similar but more complex version, notably where dealer 123 has different MACIs for different combinations of attributes (such as user attributes, dealer attributes, etc.). FIG. 32 is generally similar to FIG. 31. The difference is that, in the course of or shortly prior to generating (or causing to be generated) the “invite” 5008, the dealer selects or specifies the attribute or set/combination of attributes that apply to this particular patient (and invite). Selection of the attribute or set/combination of attributes can for example take place via a drop-down menu of the kind shown in FIG. 26. In this example, each attribute or set/combination of attributes has associated with it an attribute ID (shown in FIG. 32 as 666). The subsequently-generated and sent “invite” 5008 is accordingly tagged with (such as having embedded therein) both the dealer ID and the attribute ID (the system can automatically detect these, and tag the “invite” with them). Similarly to FIG. 31, in this example the URL 5012 that is displayed on the end user device 5010 has within it both the invite number 5014, the dealer ID 5016, and, in this example, also the attribute ID 5024.

The system queries 5018 the stored MACIs to identify the MACI that corresponds to both the dealer ID 5016 and the attribute ID 5024 - although, in some variations, querying 5018 may only be based on the attribute ID 5024 and not the dealer ID 5016, depending on the protocols discussed elsewhere herein. As noted above, in this example dealer 123 has multiple MACIs, corresponding to different attributes or combinations of attributes. Hence why in this example the system queries the stored MACIs not only according to the dealer ID, but also according to the attribute ID. At 5020, having identified the MACI corresponding to the dealer ID and attribute ID, the system causes the mobile application on the end user device 5022 to become customized according to the identified MACI.

FIGs. 13 - 15 are schematics showing different schemas whereby a unique dealer identifier (UDI) can be used to customize / configure, in accordance with the corresponding MACI, a “base” version of a mobile application on an end user device. In FIG. 13, the end user device initially comprises a base version 1304 of the mobile application. The configuration service 1302, on receiving a request for configuration information (said request including or associated with the relevant unique dealer identifier), retrieves and transmits to the end user device the relevant MACI 1308, which causes the customization / configuration 1306 of the mobile application on the end user device. In FIG. 14, when the request (including or associated with the UDI) is conveyed to the configuration service 1402, this causes to be downloaded to the end user device a base version 1404 of the mobile application, along with MACI 1408 which almost instantaneously customizes / configures the base mobile application 1404 into a customized / configured version 1406. In Figure 15, a base version 1504 of the mobile application is, when the configuration request (including or associated with the UDI) is received by the configuration service 1502, customized / configured locally at the customization service 1502 using the MACI 1508, after which the customized / configured 1506 version of the mobile application is sent to the end user device.

FIGs. 16 - 19 are schematics exemplifying various steps and protocols relating to mobile application customization in accordance with aspects of the present invention. As illustrated in FIG. 16, on the left-hand side an overall database 1602 is shown. This contains an overall inventory of products (also referred to herein as “masks”) and services potentially available from a manufacturer(s). At 1604 and 1606 are two different dealer profiles, corresponding to two different dealers, Dealer A and Dealer B. The dealer profiles 1604, 1606 may store information as to which of the manufacturer’s products and services (as contained in the overall database 1602) each dealer offers or has available, as well as other dealer attributes/restrictions/preferences/etc. Illustratively, Dealer A 1604 offers products/services 1 and 2 from the overall database 1602, while Dealer B 1606 offers products/services 2 and 3 from the overall database 1602. The information in the dealer profiles 1604, 1606 is used as the basis of one or more instances of mobile application configuration

1 application (MACI - not shown in Figure 16) for each dealer 1604, 1606. The MACI is formed as discussed further above. In a simple case, the MACI simply corresponds to the available products / services specified in the dealer profiles 1604, 1606; however, as explained above, in more complex cases there may be multiple MACI, each corresponding to different combinations of information within the dealer profiles 1604, 1606 (and potentially other information). Each MACI (not shown in Figure 16) is associated with a unique dealer identifier (UDI). Illustratively, Figure 16 shows one UDI (1608, 1610) for each of the two dealers 1604, 1606, respectively. Thus, an end user (customer) dealing with Dealer A will receive the UDI 1608; and an end user (customer) dealing with Dealer B will receive the UDI 1610. The UDIs will subsequently be used to customize a “base” mobile application on each end user’s end user device, as explained further above.

FIG 17 shows one example of such customization. At 1702, the UDI is entered (in this case typed in as a numerical code on the user device, specifically on an input interface on the “base” version of the mobile application). At 1704, the configuration service retrieves corresponding dealer profile information 1706 and mobile application configuration information (MACI) 1708. At 1710, the MACI 1708 is used to configure / customize the mobile application on the end user device.

FIG. 18 shows an example of how a pair of configured / customized mobile applications 1820, 1822 may display information that ultimately results in respective end users each selecting a particular mask (of the subset of masks that is available to them). Again, configuration / customization of the respective mobile applications 1820, 1822 has been achieved using the respective dealer profiles and MACI of Dealers A and B (notionally indicated by 1810, 1812), as described with reference to Figures 16 and 17. Mobile application 1820 has been configured / customized in accordance with Dealer A’s dealer profile and associated MACI, and mobile application 1822 has been configured / customized in accordance with Dealer B’s dealer profile and associated MACI. Illustratively, this means that mobile application 1820 is now loaded with one subset of masks, while mobile application 1822 is now loaded with another subset of masks. At 1830 and 1832, the respective users are taken through a mask selection process that guides them through one or more steps to help determine which of the respective subset of masks is best suited to their needs. This results, in 1840 and 1842, in the respective end users being presented with a suggested mask that is best for them. Note, steps 1830, 1832, 1840, 1842 may be part of the protocol of the present invention, or may be provided as a separate, “downstream” process. FIG. 19 shows an example of how a pair of configured / customized mobile applications 1920, 1922 may display information / instructions / prompts relating to a “mask health check” protocol. Again, configuration / customization of the respective mobile applications 1920, 1922 has been achieved based on the respective dealer profiles 1910, 1912 (and associated MACI - not shown) of the respective dealers (Dealer A and Dealer B); wherein each dealer profile 1910, 1912 corresponds to a subset of products / services in an overall database 1902. In this example, the configured / customized mobile applications 1920, 1922 relate to a specific mask that has been selected by or for the respective end users - illustratively, a branded Vitera mask for both end users.

At 1930, 1932 a “mask health check” routine is initiated on the respective mobile applications 1920, 1922. For mobile application 1920, initiation 1930 takes the form of a button or icon on an interface of the mobile application 1920, which the end user clicks. For mobile application 1922, initiation 1930 takes the form of a pop-up notification on an interface of the mobile application 1922, which the end user interacts with. For both mobile applications 1920, 1922, the initiation 1930, 1932 (and any associated actions by the end user) actuates a mask check routine 1940 which is displayed on an interface of the mobile application 1920, 1922. Illustratively, the mask check routine 1940 comprises one or more questions as to the state of the end user’s mask (and / or a component thereof), such as whether a cushion of the mask has signs of discoloration, is leaking, or has lost its shape. Based on this, the outcome of the mask checking routine 1940 may comprise one or more of: a recommendation that the mask or a component of same be replaced; a timeframe within which the mask or component of same should be replaced; a draft order for a replacement mask or component of same (which can be approved by the end user on the mobile application interface); or the automatic placement of an order for the mask or component of same.

Automatic reordering may be a further advantage of the present application in its own right, in that it may obviate the need for the end user to spend time contacting the dealer (or in some cases the hospital), as well as obviating the need for the dealer (or hospital) to spend time responding to the end user’ s query and communicating with the end user to action a simple reorder request. Rather, the reordering process may be automated or semi-automated via the mobile application; for instance, once the user has made the reorder request, this may appear on a dashboard of the dealer (or hospital), optionally with the end user’s key statistics / information, and optionally even with a proposed response / action (such as “approve the user’s request”). The present application may also have similar advantages in respect of other actions / transactions / processes, beyond just reordering. For instance, the user may access information on matters such as mask maintenance, fitting, adjustment, etc. via the app, rather than reaching out in person to the dealer (or hospital) to ask such questions, which is time-consuming for both the user and the dealer (or hospital), particularly if the question is a commonly-asked one. Such information may form part of the data the mobile application is customized / configured with on the end user device.

FIGs. 20 - 30 are illustrative screenshots showing implementation of an exemplary embodiments of the system of the present application. In FIG. 20, a user of the system, such as a dealer, can enter their basic information, the screen interface 2000 such as contact details and the like. Such basic information is part of the dealer’s “dealer profile configuration information”.

FIGs. 21 - 24 show various interfaces (2100, 2200, 2300, and 2400) that can be presented on a computing device for purposes of the creation of a “dealer card”, which is how, in this embodiment, a part of the system is conceptualized. Each “dealer card” in essence specifies which one or more masks are enabled (i. e. visible / available to an end user), and which are disabled (not visible / available to an end user) for that particular “dealer card” - see FIG. 24.

In this respect, the exemplary embodiment of FIGs. 20 - 30 is a somewhat simplified means of implementing the invention of the present application, in that the dealer directly specifies which subset of products are included / excluded for each “dealer card”. However, as discussed above, in other embodiments the dealer could alternatively (or additionally) enter underlying information (such as which disease states, insurance types, and

/ or brands they do / do not cater for), and this underlying information (being in effect further “dealer profile configuration information”) could then, automatically or semi-automatically, be converted to “mobile application configuration information” corresponding to visible / invisible subsets of products. Both of these protocols are within the scope of the present application.

Referring to FIG 21, each “dealer card” is given a title by the dealer creating it, which is convenient for subsequently allowing the dealer to identify / find that same card for reuse, as shown for instance in FIG 26. The dealer card also includes the dealer’s basic information, as well as their logo and the like.

Embodiments of the system include functionality to provide options for users, such as a dealer or a physician or an insurer or a care centre, to select what components of their basic information, for example contact details, branding, and the like, is provided to the end user. Such functionality is useful, for example, when users want to restrict access to certain parts of their basic information. For example, in the case of a dealer, the dealer may wish to make some basic information, for example contact telephone numbers, available to selected end users, i.e.to some end users but not others. For example, for some end users a dealer may wish to provide email contact details, telephone contact details, and a contact name. For other end users, the dealer may wish to provide email contact details only.

In one embodiment the dealer is provided with options to enter their basic information as part of the dealer’s “dealer profile configuration information” as described above during the process of generating a dealer card. In some embodiments, after accessing the system, the dealer’s information may be prepopulated, for example based on an existing dealer profile. In other embodiments the dealer’s information may be required to be entered in to the system. The dealer may be provided with options to edit the basic information as part of the process for generating a dealer card. By way of example, the information that the dealer can edit (such as show/hide) may include some or all of the profile information shown at fig 21. For instance, the dealer could choose to only populate some of the fields; and / or the screen shown at figure 21 could have “show/hide” buttons next to each item of information. Optionally these may be set to “show” by default, but the dealer can click the “hide” button to hide that piece of information.

During the dealer card generation process, the system may present a screen for receiving dealer basic information for display to end users with access to the dealer card. The screen may includes multiple fields, including: Organisation Name; Logo; address; contact email address; contact telephone number; contact staff member. Other data fields may be included.

The dealer may select which data fields to populate for the current dealer card. For example, for corporate customer end users, the dealer may provide a contact staff member. For individual personal customer end users the dealer may not provide a contact staff member. For one class of end users, the dealer may choose to provide a contact telephone number and a contact email address. For other classes of end users the dealer may provide a contact email address only. This functionality allows a dealer to customize the basic information which is provided to the end user. This customization can occur on a dealer card by dealer card basis (and / or on an end-user by end-user basis) to provide further customization to the dealer cards. The result of the customization process is that only data provided by the dealer present within the end user’s configured version of the app.

In some embodiments, the basic information may be preloaded into the selection screen. The dealer may then delete any information which it does not with to provide to the end user. In other embodiments the dealer may deselect the information which it does not wish to provide to the end user. This deselection may not delete the information but label the information in order that the application recognizes that the information should not be presented to the user.

In some embodiments the system may impose restrictions, or rules, on customization. For example some data fields are mandatory and others are optional. For example, Organisation name and address may be mandatory information fields. Address and contact number may be optional information fields. These rules could be imposed by the system on a "universal" level - for instance at least the dealer name must be entered. For other rules, these could be imposed by one user to another, per a "rules tree". So an admin user (or a head office etc) could impose rules for other members of the group or company.

In some embodiments, dealer organizations may set basic information criteria within a “master card”. The “master card” may be included in dealer cards of its entities but maybe locked entirely from editing. Other “master cards” may have certain information which is locked from editing, for example organization name and email contact address, and other information fields which is unlocked and which may be edited, for example contact telephone number. Management of access rights to determine whether or not a dealer may edit information, or whether a certain dealer information field is required may be managed by the system. This management structure creates a "rules tree", i.e. that a company with a head office and many branches may impose some fixed info and then some editable info (and may also impose mandatory/optional fields). This creates a hierarchical structure about rules being set within a company for its members.

Further referring to FIG 21, each “dealer card” has associated with it a unique “code” (being the “unique dealer identifier” discussed above). This can be in the form of a QR code, a numerical code (which can be customized, as shown in FIG 22), or another suitable form.

In use, the “code” / “unique identifier” is sent or provided by the dealer to the end user (i.e. the dealer’s individual customer), to enable the end user to access the customized version of the mobile application that corresponds to that particular dealer card, i.e. that shows (and / or doesn’t show) that subset of products / information specified against that dealer card. FIG. 23 illustrates an interface 2300 in how the “code” (here a QR code) might be conveyed to an end user.

As shown in FIG. 25, a given dealer can set up a plurality of different “dealer cards”, each one having a unique title and each one designating a specific subset of products that are enabled / disabled (i.e. shown / not shown to the end user, in use). As mentioned above, setting up multiple unique “dealer cards” in this way is effectively a “shorthand” manner of setting up a plurality of sets of “mobile application configuration information” corresponding to multiple combinations of factors. For instance, the second and third options in the dropdown menu relate, respectively, to mask options for a patient who is insured versus uninsured (self-funded). As another example, the fifth and subsequent options in the dropdown menu relate to masks available to end users in different geographical locations - either because of regional bylaws / regulations, and / or because different local branches of a dealer have different ranges / stock available for purchase.

As shown in FIGs. 26 and 27, in use a dealer selects which “dealer card” they wish to invite an end user to; and an invitation is sent to the contact details of that end user. Though not shown, this invitation will include the “code” / “unique dealer identifier” corresponding to that dealer card, which the end user will use, in the manner described further above, to gain access to the appropriately-configured customized version of the mobile application on their end user device. On the customized version of the mobile application, they will be able to view those masks which are “enabled” for that particular dealer card (and will be prevented from viewing any “disabled” masks). The user can then progress through any related steps, such as, for example, mask sizing, to select, size and ultimately place an order for their preferred mask.

As shown in FIGs. 28 - 30, the dealer can view and edit, on their dashboard, a list of patients to whom invites have been sent, along with their respective status and details about, for instance, any orders that have been placed.

Multiple Entity Cards:

An end user typically deals with a number of different entities in relation to their respiratory care. The end user may be connected to a number of different entities in relation to their respiratory care, including: a dealer of medical equipment (DME); physician; insurance company; sleep lab; homecare providers; etc. Each of these entities play a role in the overall care of the end user. The information for the multiple entities may be integrated into the mobile application configuration for the end user.

The entity information may be stored in a database accessed by the customization service. The entity information may be stored as an “entity card”. The “entity card” may include the entity name, entity contact details, address, etc. end user. The “entity card” may be generally similar in principle to the “dealer card” discussed further above, except that the relevant entity may be a dealer or it may be any of the other above-mentioned entity types. When the end user’s mobile application is customized, all of the “entity cards” of the entities relevant to that end user (or those of the entity cards which have been provided by the relevant entities) may form part of the information that is on the customized application. One benefit of the mobile application being configured in this way is that the end user is provided with the details of all parties relevant to her respiratory care in one location, i.e. on the mobile application.

In one implementation, the information for entities connected with the end user is identified during the configuration process by the configuration service, and the relevant entity cards are incorporated at the same point in time into the customized version of the mobile application. For example, this information may be provided as part of the end user attributes. During the configuration process initiated by one of the entities, such as for example the dealer, if the customization service knows who the end user’s physician is, then when creating MACI, the customization service can include the physician in the customization of the end user’s mobile application. In effect the physician entity card may be added to the specific customization of the end user mobile application. In effect, this would be another variable that the dealer (as the initiator of the customization process) specifies within the attributes when creating the invite. So that, when the patient accepted the invite, their mobile application would be customized to include the physician’s entity card (as well as the dealer’s card). The same may be included for the sleep lab entity card, the insurance company entity card etc. So a single configuration (that is to say, a single invite causing a single configuration event) could contain within it one, two, or all three of the entity cards and entity information. This implementation with the entity cards of multiple entities being contained within a single invite initiated by one of those entities may be particularly viable if the entities are related (i.e. the customization service has relationships with the entities), for example a dealer arm and a physician arm. In a further implementation, the relevant entities may each individually “invite” the end user to customize their mobile application with their entity card. In such cases, each entity would send an invitation to the end user. On opening the invitation the invitation triggers customization of the end user’s mobile application to include that particular entity card. This may be implemented by the entity pre-approving their entity details to be provided to the end user with the customization service. The invite from the entity generates a communication to the customization service from the end user device when it is opened, which subsequently triggers the customization service to update the end user customization to include the entity card. This implementation may be particularly viable if, for example, all of the entities involved in an end user’s care are unrelated to each other and do not know each other’s details, such that it is more viable for each entity to separately send and invite to provide the end user with their entity card.

These multiple “entity cards” can be stored in the system in a “phone book” of sorts. So the user can have a “wallet” of the cards of the different entities. The customization may allow one of each type (the latest physician, dealer, etc). The system may also allow expired or relaced entity cards to be stored within the customized mobile application

In some examples the system may only permit one ‘entity’ card of each type, e.g. physician, dealer, etc. These active card may be allocated an ‘entity slot’. End users may have authority to choose which card is active in the entity slot, for example the dealer slot or the physician slot or any of the other slots. Only dealer cards can override dealer cards in the same slot, only physician cards can override physician cards. The end user may be able to confirm whether or not they want to override.

Multiple entity configurations

In addition to different entities inviting the end user to view their entity cards (which as discussed above just display that entities basic information), the invites from the respective entities may also contain other configuration information that may substantively impact what the end user’s customized mobile application contains or does not contain, or displays or does not display. The end user may receive separate invitations from multiple entities, each triggering an updated customization of the mobile application. This causes the mobile application to get progressively customised / ‘overlaid’ with the configurations of each entity as the separate invites are received, (t is also within the scope of the invention for this to be achieved via a single, integrated, invite, if one of the entities (the party generating the invite to the end user) is familiar with the relevant configuration requirements of one or more of the other entities and can include these in the same invite.

Potentially, two entities may send invites that have conflicting configuration rules (or, in the case of an integrated invite, the entities’ rules may be in conflict at the point when the invite is being generated). The system may be configured to resolve this in a rules-based manner. For example the version that gives the patient the most information dominates; or a particular entity dominates (e.g. the physician’s config dominates over the dealer’s). Or, in particular, the end user’s preferences dominate. This could be on a case-by-case basis (asking the end user every time there’s a configuration conflict) or it could be in accordance with some pre-set rules or preferences of the end user.

In further implementations, connections with various entities, or invitations by entities, may include particular attributes which influence customization of the end user application. For example, for masks, a dealer may have mask range including masks A B C and D, all of which are available to the end user under an initial mobile application configuration. If the user receives an invitation from her physician, the physician may only endorse masks A C and D. Mask B not being endorsed by the physician. In this situation, the physician attributes, when combined with the various other attributes associated with the end user by the customization service, causes mask B to be removed from the end user mobile application. Effectively, mask B has been deleted as an option for the end user because the end user is now associated with the physician and the physician does not endorse mask B. Similar customizations of the end user mobile application may occur when connections are established with other entities via the customization service. If the end user updates their physician, that is to say, if the end user accepts an invite from a different physician that is associated with a different configuration peculiar to that physician, then depending on the attributes of the new physician, the customization of the end user’s mobile application may be updated, which may result in mask B becoming available and other masks being removed from selection.

End user sending an invite to a third party

In the embodiments described above the end user mobile application is configured / customized according to unique dealer identifiers (e.g., a unique dealer code, a unique image associated with a dealer, a QR code, etc.) associated with the end user. As described, the end user’s mobile application is configured by a configuration service such that it is configured for specific use by the individual end user based on dealer-specified (or other entity-specified) attributes / configuration selection criteria / preferences, and / or other customizable data selected by individual dealers. To this end, the configuration service can illustratively provide executable code, instructions, data, or otherwise cause the activation of previously implemented executable code or data or the addition, modification, or removal of such previously implemented executable code or data.

Configuration / customization of the end user mobile application may limit the masks or equipment “enabled” for a user within the mobile application. On the customized version of the mobile application, an end user will be able to view those masks which are “enabled” in accordance with the mobile application configuration information indicated by the dealer and/or other service provides i.e. entities (e.g. physician, insurance company, etc) (and will be prevented from viewing any “disabled” masks). One or more aspects of the present application may equally be utilized in relation to medical devices more generally, including other types of components for respiratory devices (such as, without limitation, nasal cannulae, tracheostomy interfaces, medical tubes, filters, etc - whether configured for CPAP therapy, high-flow therapy, or other types of respiratory therapy or respiratory support), other types of medical devices or components other than those used for the treatment of respiratory issues, and entire medical devices, apparatuses or systems (whether for respiratory treatment or other) comprising multiple components. On the customized version of the end user application the devices and content made available to the end user by the dealer (or other entity), via the selection of the unique dealer identifier (or unique identifier associated with another relevant entity - “unique dealer identifier” as used herein is to be understood as encompassing this), are visible to the end user.

The configuration of mobile applications also provides various functions to the end user within the mobile application. With the mobile application the end user may select, order and maintain medical equipment, particularly respiratory support equipment / devices or components of same.

Further embodiments enable the end user to grant access to selected features of the mobile application to third parties. The features may include information and/or functionality. This may have the effect of granting the same or limited access to the mobile application to the third party. Access to selected information may include: providing the third party with access to the end user’s reminder list, for example reminders for when components are due for replacement; providing access to product lists available to the end user; providing access to product information; providing access to contact information, for example for the dealer. Access to selected functions may include: providing the third party with access rights to order replacement or new components on behalf of the end user; or providing access to other functionality. The end user can delegate some actions or responsibilities to third parties; for instance, they may wish to automatically redirect replacement/reordering reminders to their caregiver so the caregiver can take responsibility for checking the condition of the mask and reordering if needed.

Such embodiments enable end users to outsource or share parts of their healthcare with others, such as doctors, hospitals, other dealers, caregivers, or family, via the mobile application.

This feature of granting access to third parties may be implemented by enabling the end user to invite a third party to selected access of the mobile application. The invitation may be in form of a unique third party identifier (UTPI). The UTPI is supplied (directly or indirectly) to the third party. In one example the UTPI enables configuration / customization of a “base” version of the mobile application on the third party device. The UTPI is similar to the UDI but the UTPI is related to a specific mobile application configuration information (MACI) specific to the third party, including any settings the end user may choose to impose vis-a-vis the third party’s access rights. The configuration of the third party mobile application typically relates to a reduced version of the end user mobile application from the end user inviting the third party. The third party mobile application is generally configured the same as the end user mobile application, or a reduced version of the end user mobile application. The end user typically may not provide access rights to the third party that the end user does not have within the end user mobile application. The third party mobile application typically includes the same or fewer features, for example data, products, software applications), compared with the end user mobile application. The UTPI may take different forms. For example the UTPI may take the form of a unique third party code, a unique image associated with a user, a QR code, etc.

Turning now to FIGS. 33, 34, 35, 36 illustrative interactions between end users, third parties and a configuration service, as embodied in communications between an end user device 3310, third party device 3330 and configuration service 3320 will be described. For purposes of the present application, the illustrations of FIGS. 33, 34 and 35 will be described with regard to a single third party device 3330 interacting with the configuration service 3320 and end user device 3310 to obtain configuration information for a mobile application on the end user device.

With reference to FIG. 33, an illustrative interaction for creation of third party mobile application configuration through communications generated by end user device 3310 will be described. Although only a single third party device 3330 is illustrated in FIG. 33, the configuration service 3320 may repeat the interaction with the user device to generate third party profiles for a plurality of third party devices.

For purposes of the interaction illustrated in FIG. 33, it is assumed that the end user already has an mobile application associated with the configuration service and that the end user device has a mobile application with a specific configuration. It is assumed in the illustration of FIG. 33, that the end user has registered or otherwise engaged with the system to allow for the interactions illustrated in FIG. 33. Registration will typically involve the end user providing certain basic information such as name, username, password.

At (1) of FIG. 33, the end user device 3310 requests access to the configuration service 3320. Such interactions by the end user device 3310 with the configuration service 3320 may be embodied as interactions corresponding to network applications (e.g., a browser application) or a custom application implemented on a computing device, such as a personal computing device, tablet computing device, mobile device and the like.

The end user has a particular configuration of mobile application which is recognised by configuration service 3320. The end user’s mobile application configuration is defined by a mobile application configuration information (MACI) as described above. The MACI defines how the end user mobile application should be customized / configured and is dependent on the various combination of input attributes / preferences of the dealer and potentially other services linked to the end user and the input attributes / preferences of the end user. The MACI associated with end user device 3310 is known by configuration service 3320. As described the MACI associated with the user device may be stored in a database or other storage by configuration service 3320.

FIG. 35 and FIG. 36 represent the features associated with mobile application configuration information (MACI). The example of FIG. 35 includes database 3520. Database 3520 includes multiple information. The information may include different information types. For example, one type of information stored in the database may be product information 3521 including an entire range of products offered by a manufacturer or manufacturers, prior to any filters, factors or criteria. In other words, the database is an inventory of all potentially available products. Another information type may be end user reminders. The database 3522 may include reminders generated for the end user. For example, reminders to order replacement mask - possibly based on the usage period of the mask, or reminders to schedule an appointment with a physician to monitor the end user’s respiratory condition. Another information type may be payment information details. The database may include payment information details 3523. Payment information may include end user payment information. This may include bank details. Further information types may include contact information, for example dealer contact information including dealer name, dealer address, dealer telephone number, dealer staff names, etc.

Database 3520 may, in fact represent multiple databases. These databases may or may not be stored on a single memory device. The databases may be stored remotely and separately. The databases may have separate access rights. For example, different information types may be stored in a single database (i.e. information 3521 3522 3523 are all stored within a single database). The different information types may be stored in different parts of a single database (i.e information 3521 3522 3523 are stored within separate parts of a single database). Or different information types may be stored in different databases (i.e. information 3521 3522 3523 may be stored in separate databases). Further databases may include additional information or features or applications. For example databases may include account information. Databases may include therapy data, for example therapy usage and/or therapy data.

It is also within the scope of the invention that the original MACI stored by the system in respect of the end user relates only to one of the databases, e.g. database 3521. The other databases 3522, 3523, may be outside the scope of the MACI, but may be accessible by the system such that the end user, when creating the third-party invite, can call up and select from these databases to allow the third party to view information from them. This is discussed further below.

Referring to FIG. 35 (and as described above), mobile application information (MACI) represents information as to how the mobile application should be customized / configured for an end user, based on input attributes / preferences of a dealer 3506, potentially other relevant entities, and the end user 3504. As described above the MACI represents the specific mobile application configuration specific to the user. The configuration limits access to information and features depending on the input attributes and preferences.

In the example of FIG. 35, for an end user, the system receives a specific combination of input factors, being end user attributes 3504 and dealer attributes 3506. This specific combination of input factors defines the subset of information and features that the end user is permitted access to. Thus, when the corresponding UDI is subsequently used to effect customization of the mobile application on that end user device, MACI will cause the customized mobile application to display that subset of information and features, which the end user can then browse, select, purchase, etc. In the example of FIG. 35, within the entire database of a first information type 3521, the end user is provided access to a subset of that first information type 3524, based on the combination of end user attributes 3504 and dealer attributes 3506. Within the entire database of a second information type 3522, the end user is provided access to a subset of that second information type 3525, based on the combination of end user attributes 3504 and dealer attributes 3506. Within the entire database of a third information type 3523, the end user is provided access to a subset of that first information type 3526, based on the combination of end user attributes 3504 and dealer attributes 3506.

The specific MACI associated with the end user is stored in MACI database 3510. A unique dealer identifier (UDI) is associated with the MACI and on receipt of the UDI, the configuration service provides a mobile application to be configured in accordance with the defined access of the end user.

After access to the configuration service is provided to the end user, the end user may make a request to provide access to a subset of the features of the end user configured mobile application to a third party. The configuration service receives the request from the end user at (2) of FIG. 33.

The request may include contact details for the third party, for example a telephone number. This contact telephone number may be used by the configuration service to authorize the third party and/or to provide access information, for example a Unique Third Party Identifier (UTPI).

The request may include details of access the end user wishes to provide to the third party (3) of FIG. 33. The request may be defined in terms of providing third party attributes / preferences (aka “factors”) 3508.

The access provided to the third party by the end user is a subset of the access provided to the end user. This means that the third party mobile application may include some or all of the features of the end user’s mobile application. As described above, the configuration of the end user mobile application is determined by the configuration service using the combination of user attributes 3504 and dealer attributes 3506. The configuration service generates a configuration for the third party mobile application using a combination of user attributes 3504, dealer attributes 3506 and third party attributes 3508. The result of the combination of attributes generates a subset of the configuration of the end user mobile application.

Referring to FIGS. 35 and 36, within the entire database of a first information type 3521, the end user is provided access to a subset of that first information type 3524, based on the combination of end user attributes 3504 and dealer attributes 3506. On receiving the third party attributes, the system generates configuration information for the third party, and (via an invite) the third party is provided access to a subset of that first information type 3627. In the example of FIG. 36, 3627 is a subset of first information 3524 accessible by end user, which is a subset of the total first information type 3521. In the example of the first information type being products, for example respiratory masks, the subset 3627 includes all masks included in the end user subset 3526, meaning that the third party has visibility of all masks visible to the end user. 3628 is a subset of second information 3525 accessible by end user. In the example of the second information type being end user account data, for example payment data, the subset 3628 includes some, but not all, payment data included in the end user subset 3525, meaning that the third party has visibility of less of the financial data than the end user. An example use case here may be that the end user is willing to share a reduced set, but not all, of her payment data with the third party. For example the end user may share his purchase history, but not her bank account details. 3629 is a subset of third information 3526 accessible by end user. In the example of the third information type being reminders generated by the system. The subset 3629 includes a reduced set of reminders compared with those provided to the end user 3526, meaning that the third party has visibility of some but not all of the reminders for the end user. An example may be that the system provides reminders to the end user to replace the mask and also provides reminders to the end user to contact the physician for a respiratory check. In examples where the third party is provided access to some of the reminders, the third party may be provided with reminders for replacing the mask on behalf of the end user but not the reminders for the check up with the physician.

The specific configuration of the third party’s mobile application is generated at (4) of FIG. 33 using the combination of user attributes 3504 dealer attributes 3506 and third party attributes 3508. The particular configuration of the third party mobile application (defining the information and functionality provided to the third party) is defined by Mobile application third party configuration identifier (MATPCI) stored in database 3610. The MATCPI may be linked in the database to the MACI for the relevant end user. Contact details associated with the third party may also be linked to the MATPCI.

At (5) of FIG. 33, the configuration service 3320 can then generate a unique dealer third party identifier (UTHI) that corresponds to the generated mobile application third party configuration information. Illustratively, the unique dealer third party identifier corresponds to a unique or semi-unique code, image or other information that can be provided to third parties as described herein. The unique third party identifiers may be scanned or manually entered into the mobile application on a third party device.

At (6) of FIG. 33, the configuration service 3320 provides or makes available the generated unique third party identifier. For example, the configuration service 3320 can transmit generated unique third party identifier to the third party device 3330 and/or the configuration service 3320 can transmit generated unique third party identifier to the end user for subsequent delivery or distribution to the third party device. The delivery/distribution of the unique third party identifier can occur via a platform, interface or communication means that is the same as, or related to, the mobile application. For instance, the “base” version of the mobile application can be configured to receive the original communication (containing the unique third party identifier), which may then, with or without further end user prompting, trigger the customization steps. Alternatively, the unique third party identifier may be transmitted, distributed or posted via an independent process (e.g., email distribution or uploading to a shared memory repository). Also, the unique third party identifier may be received by, and/or subsequently conveyed by, entities other than the end users themselves. For instance, an authorized third-party intermediary may receive the unique third party identifier from the configuration service and subsequently convey these to the appropriate third parties.

In an embodiment, the end user may generate an “invite” using the system, and cause this to be transmitted to the third party device. The “invite” is a communication, alert or message that lets the third party know that, by interacting with the invite in the manner specified (such as clicking on a link provided), they will be able to view / access aspects of the end user’s application that are relevant to them, for example mask types, therapy data, reminders, etc. Within the invite, such as embedded within the link, may be a code that designates the end user - this may be referred to as an “invite ID”, and cross-identifies or links the invite with the particular end user. The “invite ID” may be generated automatically, based on the end user being logged into their account when generating the “invite”. Upon the “invite” being received by the third party device, and being actuated such as by the third party clicking on the provided link, the system may then automatically retrieve the code or “invite ID”, from which (wholly or in part) the system may identify how to customize the mobile application. In some versions of this example, the code or “invite ID” may include additional information over and above the identity of the third party; for instance, the code or “invite ID” may crossreference (directly or indirectly) to the appropriate mobile application configuration information. For instance, the end user may, when preparing the “invite”, specify or make known to the system the relevant “attributes” pertaining to the invite and this may be reflected in the code or “invite ID”, which the system, upon retrieving the code or “invite ID” can use to determine the appropriate mobile application configuration information.

Thereafter, third parties can engage with the mobile application on behalf of or instead of the end user (to the extent of the information, or subset of information, to which the third party has been granted access by the end user). With reference now to FIG. 34, an illustrative interaction for provisioning individual third party device 3430 with configuration information for the common mobile application (such as resident on the third party device) will be described. Although only a single third party device 3430 is shown actively communicating with the system in FIG. 34, the configuration service 3420 may repeat the interaction with a plurality of third party devices in parallel or sequentially. It is assumed for purposes of the illustrations of FIG. 34, individual third party device 3430 has been provided or otherwise acquires the common mobile application (e.g., the mobile application prior to a customization or configuration process). In one example, the base mobile application may be provided via the configuration service 3420 via a network connection based on a request transmitted from the third party device 3430. In another example, the common mobile application may be preloaded on third party device 3430, such as with an initial delivery/distribution and may not need to be separately downloaded or provided. In still another example, the common mobile application may be available for download to the third party device 3430 from a third-party application provider.

At (1) of FIG. 34, the third party device is provided with the unique third party identifier (UTPI) (e.g., a unique third party code), for example by the user device 3410, or the configuration service 3420. The third party may be provided with the UTPI from the user device 3410, or from the configuration service 3420, or from a third party intermediary, such as via a transmission to the third party device 3430. In some embodiments, the unique third party identifier may be provided electronically, such as by data transmission (e.g., email, short message services, near field communications, etc.). In other embodiments, the unique third party identifier may be provided without computing device interaction, such as by printed communications, physical postings, oral communications, etc. As previously described, in still other embodiments, the unique third party identifier can include one or more dynamically determined portions that may be utilized as part of a unique third party identifier and may be determined or calculated at various times, including prior to receiving a request from third party devices 3430 or responsive to a request from third party device 3430.

At (2) of FIG. 34, the third party device obtains the unique third party identifier, such as via manual entry, scanning, etc. Illustratively, a common mobile application on the third party device 3430 may generate interfaces for obtaining manual entry or transfer of the unique third party identifier, which may be in the form of a code. In another embodiment, the common mobile application may receive information or otherwise interact with other components of the third party device 3430, such as a camera application, bar code reader, near field communication application, etc. that may be operable to provide a unique identifier to the common mobile application without requiring additional manual input from the third party. It is also possible, in alternative embodiments, for the unique third party identifier to, at this stage of the process, be obtained and processed by the third party device independently of the common mobile application.

At (3) of FIG. 34, the third party device 3430 transmits a request for mobile application configuration information to the configuration service 3420. Illustratively, the request can include the unique third party identifier that was previously provided. Alternatively, the request may be based on the unique third party identifier but without including the unique third party identifier per se. In other embodiments, the request process can include an exchange of multiple communications between the third party device and configuration service 3430. At (4) of FIG. 34, the configuration service 3420, responsive to the transmitted unique third party identifier (and / or the transmitted configuration request), identifies relevant mobile application configuration information. In one embodiment, the configuration service 3420 can select mobile application configuration information that has been precompiled, for example the configuration service matches the UTPI received from the third party device to MATPCIs stored in a database to identify the mobile application configuration associated with the received UTPI. In other embodiments the configuration service 3420 can dynamically generate at least some portion of the mobile application configuration information. In some examples, at least a portion of the unique third party identifier may be dynamically generated, and the same is true of the mobile application configuration information.

At (5) of FIG. 34, the configuration service 3420 provides mobile application configuration information to the requesting third party by providing the mobile application configuration information to the third party device 3430.

In response, at (6) of FIG. 34, the common mobile application incorporates the returned mobile application configuration information such that the mobile application becomes configured / customized in accordance with the requests by the end user.

Some benefits of the allocation of access to third parties by providing a customized mobile application are that an end user may delegate various actions etc to third parties. For example, the end user may delegate reminders, may provide therapy data, or may provide healthcare contact details to third parties.

In example embodiments, the end user selects a subset of data, from at least one database (DB) available in the mobile application, for a third party recipient to see. Based on this, a “unique identifier” is generated that corresponds to the selected subset of data. An invite is sent to the third party, the invite being associated with the “unique identifier”. Upon the third party accepting or actioning the invite, a generic version of “a viewing app” is customized to display the selected subset of data.

The selected subset of data is selected from one or more of: the dealer/mask DB; a patient medical data DB; a patient therapy data DB.

The databases may be separate

The databases may all be sub-DBs of an umbrella DB

The unique identifier may be generated by the configuration service

The unique identifier being unique for each third party recipient Each third party recipient having a recipient ID associated with them, and the recipient ID forming part of or being associated with the unique identifier

The unique identifier incorporates the unique dealer identifier

The generic version of the viewing app being customized by the configuration service.

The selected subset of data being selected from the dealer/mask DB, and the viewing app being the dealer/mask app.

A plurality of “unique identifiers” and invites are generated/sent, each corresponding to a type of data

These all customizing the same “viewing app” at the third party end

These each customizing a separate “viewing app” for the respective type of data One of the viewing apps is the dealer/mask app for viewing the dealer/mask data.

A preliminary step of the patient logging in to the configuration service.

Re-using Invitations:

The mobile application configurations may be specific to individual third parties or may be provided to multiple third parties. For example, an end user may wish to provide the same access rights to more than one third party. In the event that multiple third parties are provided the same access, the same UTPI may be provided to multiple third parties. Multiple third party contact details may be stored against the UTPI and MATPCI in the customization service database.

Each invite may be unique to an individual third party. A benefit of generating unique invitations (UTPI) for individual third parties is that an end user can then manage them individually (e.g. revoke them) since they are each identified by their unique invite code. Also as a practical matter each invite currently only has one activation.

UTPI may be sent directly to third party devices by the customization service, and/or sent directly to the end user to forward on to the third parties.

Different Types of Configuration Service:

A. Multiple data types via the manufacturer app:

In some of the examples described the customization service is hosted or provided by a manufacturer. The customization service allows dealers to configure a common mobile application to make it applicable to different and specific end users. The common mobile application may be configured using customization preferences, attributes, restrictions, circumstances, requirements, or other similar information (at times referred to herein by the collective term “customization preferences”). .As described, the configuration results in certain information or features of the common mobile application being made available to the specific end user, and other information or features being disabled or made non-visible to the specific end user. For example, customization allows a dealer to identify a selection of medical devices (e.g., respiratory masks or other consumables) that are available for sale/distribution by the dealer, medical device service/maintenance preferences, patient health or medical condition check preferences, ordering preferences, payment or financial arrangement preferences, and the like. As described, systems enable end users to invite third parties to limited access customization of the mobile application. Such systems enable an end user to invite a third party to have access to certain information or features to which the end user has access. This allows the end user to provide third parties with access to a configured mobile application, but to specifiy what the third party is allowed to see. Such systems provide further customization of the mobile application for the third party. In further embodiment, the third party may also be allowed to provide further, restricted access to further parties.

Although examples are described with reference to manufacturers and dealers, in terms of product catalogues, sales, etc, further embodiments enable further information to be made available via the mobile application. In one embodiment, therapy data may be made available through the mobile application. In an example, therapy data, for example end user therapy data including end user usage of a respiratory system and the therapy data associated with the end user use, may be provided to (or accessible by) the manufacturer or other party hosting the customization service. The therapy data may be stored in a separate database. In a further embodiment, medical data, for example medical history, diagnosis, etc may be made available through the mobile application. Such medical data may be provided to the manufacturer or other party hosting the customization service. The medical data may be stored in a separate database.

Within the specific customization of the end user mobile application, the end user may be provided with access to her medical data and therapy data, based on any required access rights. The system may facilitate the end user granting access to her medical data and/or therapy data (or a subset thereof) in addition to, or instead of, product related data. In some implementations, the data from the other databases may be part of MACI applying to the end user’s original configuration. In other implementations, such data may not be part of the original MACI, and may only be included or referenced in the subsequent invite (and associated MATPCI) generated and sent to the third party.

FIG. 37 shows a customization service, for example hosted by a manufacturer, including multiple data types in different databases. In the example of FIG. 37, the manufacturer has access to multiple databases relevant to the end user: product database 3722 includes manufacturer product data and product related information, for example contact information, product pricing information, financial information for the end user; medical database 3724 includes information about end user medical condition; therapy database 3726 includes data relating to end user therapy, for example usage and therapy results. Access to data in databases 3722 3724 3726 may be made available via the customization service. The customization service makes data within the various databases available to a third party based on a combination of end user attributes 3702; dealer attributes 3704 including limitations and restrictions imposed by the dealer on what information is made available to the end user; third party attributes 3706 including limitations and restrictions imposed by the end user on what information is made available to the third party.

The allocation of access to a third party may be subject to patient-governed controls / management. E.g. the patient having to approve the sub-invitee ahead of time or granting/selecting an option for a general “sub-invitee” authorisation , or having controls that let the patient suspend the sub-invitee or revoke their access. Such limitations may be applied, for example via control attributes 3708, which may relate to privacy restrictions generally applied to medical data or therapy data.

In such embodiments, data types from different databases, sources or organisations may be made available through the mobile application by being provided through the manufacturer or other company providing the customization service.

B. Multiple data types through a master application

In some other examples, the customization service may be hosted by a separate organization, for example a health department (or any other suitable organization), providing a master mobile application. In such embodiments, manufacturers, dealers, medical services, healthcare professions, and other related services may provide end user data via the master application. Typically, the end user would hold an account with the organization managing the master mobile application as well as accounts with all the separate organisations managing the end user’s health, for example the manufacturers, dealers, medical professionals, sleep lab, etc. The end user can link the master account to their accounts with the individual organisations.

During customization, the end user can select which of the accounts she wants to make available through the master application and the customization service will provide a suitable customization for the end user mobile application to provide access to those accounts within the mobile application. The end user may invite third parties and provide access to data within databases of those accounts via the customization process described. In summary, where the invite to the third party includes data from multiple different databases, one implementation is that this is accomplished through the same configuration service as the dealer configuration service described earlier in this specification, but that dealer configuration service is communicative with other databases such that, via the dealer configuration service, the user can specify data from the various databases (the dealer database and the other databases) which the third party is to have access to. And the third party may then use the dealer application described above (or a modified version of it) to access the data they have been allowed to see.

Another implementation is that the third party invite is accomplished through a separate configuration service (i.e. master configuration service, or standalone configuration service) from the dealer configuration service described above. This separate configuration service may have access to the dealer database described above, plus one or more other databases, or only to the other databases. From these databases, the end user selects what data they want the third party to see via the separate configuration service. The third party may then use a master application, related to the separate configuration service, to access the data they have been allowed to see. (And the end user may also use this master application to create the settings for the third party, and generate (or request generation of) the invite to the third party).

FIG. 38 shows a representation of a master application 3800, the master application 3800 may serve as a single application for a user to access multiple healthcare information and engage with healthcare support entities. For example, the dealer databases 3812 and information may be accessible via the master application 3800. Therapy databases and information 3814 may be accessible via master application 3800. Medical database and information 3816 may be accessible via master application 3800. Each database may be managed separately by different entities. The user may have different access rights to data in the different databases. When allocating access to a third party, the end user may be able to configure access rights separately for the third party in each of the separate databases. For example, MACIDD for configuration of the dealer database would not be affected if the end user granted access rights to the therapy data, which is managed by a different MACI, MACITD.

In one implementation each of the databases may be managed by a separate entity. This example allows the end user to maintain independent relationships with separate entities, for example dealers, medical centres, therapy management etc but be able to access data centrally via a master application 3800. The MACI for each of the entities may be generated by the entity itself and via end user interaction with that entity. In other implementations the master configuration service may generate MACIs on behalf of each of the entities based on engagement between the end user and the configuration service.

The overall configuration of the mobile application will control user access to the data in the various databases. The overall configuration of the mobile application is a combination of the MACIs for each of the databases / entities. Configuration of the mobile application may be implemented in different ways, for example the master application customized by a central customization service, could generate a single Unique Identifier to identify the entire configuration of the mobile application. The single unique identifier accounts for the MACIs of each of the entities to configure a single configuration. In other examples, the users could independently receive separate identifiers from each entity. The user may provide the separate identifiers to the master configuration service and the configuration service adjusts the configuration of the mobile application based on the individual identifiers.

Third party access may be granted through interactions of the end user with the separate entities, for example via entity specific communication channels, or interactions of the end user with the central application.

In some embodiments, the third party mobile application is not configured in the same sense as the original patient app. Instead, the third party may install a general or generic application but the configuration service would restrict the features or parts of the end user information that the third party has access to, so generating a limited access application for the third party. Such embodiments could use the same process of generating a MATPCI and UTPI but, rather than the mobile application being specifically configured for the third party, the third party is provided a general or generic version of the mobile application but with controlled access to certain data fields or feature fields depending on the access provided to the third party by the end user. Interactions by the end user device with the configuration service may be embodied as interactions corresponding to network applications (e.g., a browser application) or a custom applications implemented on a computing device, such as a personal computing device, tablet computing device, mobile device and the like. The end user may interact with the configuration service via functionality within the mobile application. Within the mobile application, the end user may navigate to interfaces that can be presented on a computing device for purposes of creating requests for third party access to the end user data and functionality and for the creation of third party attributes relating to the access and functionality the end user wishes to delegate / provide to the third party.

The end user mobile application may be configured to limit the options for end user requests to those permitted. For example, options outside the scope of end user access may be inactive or not presented at all.

Via an end user device, an end user can select which features (for example information or functions) of their specific configuration, they wish to make available to a third party. These features may relate to the full feature range within the end user mobile application configuration, or a subset of the feature range within the end user mobile application configuration. Additionally, or alternatively, the end user may select features of their specific configuration that will not be made available to the third party.

Illustratively, the third party configuration information can identify or include what data is downloaded to the third party device as part of the mobile device application customization / configuration processes described herein. Alternatively, or additionally, the third party configuration information can include selection information that can be processed by the mobile application or third party device such that it activates or makes available data already present on a “base” or common version of the mobile application. Still further, additionally or alternatively, the third party configuration information can also include filtering information that causes the deletion, de-activation or other obfuscation of data previously configured on the “base” or common mobile application but that will not be utilized as part of the customization of the “base” or common mobile application for a particular third party.

For purposes of illustration, the type of interaction and data collection between the user device 3310 and the configuration service 110 can, at least in part, comprise receipt of information that corresponds to the desired configuration of the mobile application for the third party device 3330. In one aspect, as previously described, the input received from the end user device 3310 includes a selection of a subset of information available to the end user via the end user mobile application configuration to be made available to the third party.

The end user is still able, via the unique third party identifier (UTPI), to grant the third party access to the specific subset features available to the end user within the mobile application. This compartmentalization of information may have benefits in terms of computational efficiency, but also in terms of privacy (potentially including in terms of complying with applicable privacy laws) as well as in terms of end user confidence in the integrity of the protocol and of the anonymity and confidentiality of their information.

Based on the end user preferences embodied in end user profile configuration information, the configuration service 3320 can generate configuration information that can be utilized to the modify or update the common mobile application in accordance with the end user preferences to result in a customized or configured mobile application being made available to a third party, as referenced herein.

Importantly, the access allowed to be granted by the end user to the third party is within the configuration of the end user mobile application. Meaning that the end user may only provide access to features (i.e. data and functionality or other features) that it has access to within the configuration of the end user mobile application.

Updates to Settings after the Application has been Customised:

Data within the databases of the customization service or attributes of various parties may be updated from time to time. For example, a manufacturer may update its product range, a dealer may offer new mask types, a physician may update its contact details, an insurer may update its policy, etc. These updates may be relevant to a particular end user but only made after the end user has accepted an invitation and installed a customized mobile application.

In some examples, when the end user installs a customized mobile application (upon accepting the dealer’s invite), the mobile application is customized based on the various preferences and data stored in the databases at that time.

In one example, the end user device operates the mobile application as initially customized. The end user device is not notified when settings, preferences, or data at the customization service are updated. Also the end user device does not initiate updates to its configuration, for example it does not “ping” the customization service to request updates. In such examples, within the mobile application, if the end user runs a mask selection application (or other application) to select a mask to order from a dealer via the mobile application, if their mask selection (or whatever the outcome is at the end of using the app) is not in conflict with the latest product range offered by the dealer, there’s no issue. The dealer receives an order for a mask through the mobile application system and can proceed to fill the order. However, if there is a conflict - for example, if the user selects a mask that the dealer has since withdrawn from its catalogue - then the system will only realise that for the first time when the dealer receives a request for that (invalid) selection from the end user via the mobile application system. At that point, a conflict resolution procedure is executed by the dealer. The conflict resolution may be one of the following:

The system sends the Dealer a message to resolve the conflict between the dealer’s latest configuration and the previous configuration installed at the end user device;

And / or potentially the end user receives a message within the mobile application;

The system may be configured to automatically offer (or even provide) a ‘backup’ mask, i.e. a predetermined alternate for the unavailable mask that was chosen. This “backup” mask may be defined by the dealer within its initial configuration.

In some examples, the configuration service updates configurations of mobile applications if settings, attributes or data are updated after an end user has installed a customized mobile application. For example, if a dealer’s settings change, or product range changes. The system may provide the end user with an updated customized mobile application by providing an updated invite to the end user, conveying the updated settings. The updated invite may be a new UDI (or new UTPI) associated with a new MACI (or new MATPCI) or may use the same UDI but the configuration associated with the UDI has been updated since the original configuration.

In an example, if a dealer updates its product range (i.e. defining new dealer attributes), within the system, on the dealer’s viewing panel, those end users whose configurations would now be outdated and need to be renewed (i.e. whose mobile application configurations have now been superseded by more recent settings) may be flagged to the dealer. For example, those end users may be put into a category or colour-coded in a visible display. The system may provide the dealer with a “group select” function to select them all and resend (unique) invites to each.

In a further example, a new invite (UDI) could be automatically generated and triggered by an event. For instance, if the system detects that the end user has selected a mask that is no longer offered, this could (in addition to the “conflict resolution” steps above) trigger an action for the system to send a new invitation to the end user so the configuration of the end user’s mobile application also gets updated for next time.

In further examples, invites may have an expiry time, e.g. 30 days. After which the end user would need to request a new one. This request may be triggered automatically by the mobile application. This expiry can sometimes help avoid conflicts. E.g. patient A is sent an invite, but it times out after 30 days as they did not accept it, they then want to find a mask so they request a new invite (this could be a new configuration to the configuration of the previous invite they received), they accept that invite and size and select a mask. That mask may be one that is new to the newer configuration but which was unavailable to the old configuration. But the patient doesn’t need to know this and the transition was seamless from their point of view. The expiry and uniqueness of the invites give the dealer/entity flexibility and control over how they handle and deal with their customers.

In some examples, the mobile application may automatically request an updated invitation at a set time period after installation. For example, after installation, the mobile application may automatically send an update request to the configuration service after 30 days. This process continues time after time and so the mobile application gets regularly reconfigured to receive an up to date configuration. In other examples, the mobile application automatically requests an updated invitation each time the end user logs into the mobile application. This ensures that the end user is always using an up-to-date configuration.

Potentially, at the dealer end (or “inviting party” end more generally), the dealer could also get a warning if they are about to make a settings change that will render certain invites out of date. Along the lines of “this change will cause X end users invites to become outdated.” Since the dealer might have numerous “configuration categories”, and might routinely make changes to settings within those categories, on their viewing panel they might see a breakdown of categories, versions, and the patients within each of those, i.e. the end user who were sent (and/or accepted) an invite when the respective version was current (and hence that version is what those end users now see on their phone, if they downloaded it). E.g.: OSA config insured ver 1.1: Veronica, Anna

OSA config insured ver 1.2: Tom, Tim

OSA config self-paid ver 1.1: Jennifer

HF config insured ver 1.1: Bob, Graham

HF config insured ver 1.2: James

HF config self-paid ver 1.1: Thomas

End users falling under some or all of the non-latest versions could be mass-selected such that the dealer can send re-invites to all relevant end users in one go.

In further examples, the system may automatically / dynamically update configurations of the mobile application, where if subsequent configurations updates are made by the dealer, physician, insurer, or any other party relevant to the customization of an end user application, these are automatically reflected on the end user’s customized application without a re- invite being needed.

This may be via the end user device constantly / routinely “pinging” the system for updates;

Or pinging it at intervals, s/a every time the app is opened (or every X times).

Or before a selection/sizing workflow is started.

At least some elements of a device of the present application can be controlled - and at least some steps of a method of the present application can be effectuated, in operation - with a programmable processor governed by instructions stored in a memory. The memory may be random access memory (RAM), read-only memory (ROM), flash memory, distributed memory, or any other memory, or combination thereof, suitable for storing control software or other instructions and data. Those skilled in the art should also readily appreciate that instructions or programs defining the functions of the present application may be delivered to a processor in many forms, including, but not limited to, information permanently stored on non-writable storage media (e.g. read-only memory devices within a computer, such as ROM, or devices readable by a computer I/O attachment, such as CD-ROM or DVD disks), information alterably stored on writable storage media (e.g. floppy disks, removable flash memory and hard drives) or information conveyed to a computer through communication media, including wired or wireless computer networks. In addition, while one or more aspects of the present application may be embodied in software, the functions necessary to implement the invention may optionally or alternatively be embodied in part or in whole using firmware and/or hardware components, such as combinational logic, Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs) or other hardware or some combination of hardware, software and/or firmware components.

As used herein, a phrase referring to “at least one of’ a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover: a, b, c, a-b, a-c, b-c, and a-b-c.

Various modifications to the implementations described in this disclosure may be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other implementations without departing from the spirit or scope of this disclosure. Thus, the claims are not intended to be limted to the implementations shown herein, but are to be accorded the widest scope consistent with this disclosure, the principles and the novel features disclosed herein.

Certain features that are described in this specification in the context of separate implementations also can be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation also can be implemented in multiple implementations separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Depending on the embodiment, certain acts, events, or functions of any of the processes or algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all described operations or events are necessary for the practice of the algorithm). Moreover, in certain embodiments, operations or events can be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially. The various illustrative logical blocks, modules, routines, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, or as a combination of electronic hardware and executable software. To clearly illustrate this interchangeability, various illustrative components, blocks, modules, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware, or as software that runs on hardware, depends upon the particular application and design constraints imposed on the overall system. The described functionality can be implemented in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.

Conditional language used herein, such as, among others, “can,” “could,” “might,” “may,” “e.g.,” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without other input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment. The terms “comprising,” “including,” “having,” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list.

Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.

Unless otherwise explicitly stated, articles such as “a” or “an” should generally be interpreted to include one or more described items. Accordingly, phrases such as “a device configured to” are intended to include one or more recited devices. Such one or more recited devices can also be collectively configured to carry out the stated recitations. For example, “a processor configured to carry out recitations A, B and C” can include a first processor configured to carry out recitation A working in conjunction with a second processor configured to carry out recitations B and C.

As used herein, the terms “determine” or “determining” encompass a wide variety of actions. For example, “determining” may include calculating, computing, processing, deriving, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Also, “determining” may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like. Also, “determining” may include resolving, selecting, choosing, establishing, and the like.

As used herein, the term “selectively” or “selective” may encompass a wide variety of actions. For example, a “selective” process may include determining one option from multiple options. A “selective” process may include one or more of: dynamically determined inputs, preconfigured inputs, or user-initiated inputs for making the determination. In some embodiments, an n-input switch may be included to provide selective functionality where n is the number of inputs used to make the selection.

As used herein, the terms “provide” or “providing” encompass a wide variety of actions. For example, “providing” may include storing a value in a location for subsequent retrieval, transmitting a value directly to the recipient, transmitting or storing a reference to a value, and the like. “Providing” may also include encoding, decoding, encrypting, decrypting, validating, verifying, and the like.

As used herein, the term “message” encompasses a wide variety of formats for communicating (e.g., transmitting or receiving) information. A message may include a machine readable aggregation of information such as an XML document, fixed field message, comma separated message, or the like. A message may, in some embodiments, include a signal utilized to transmit one or more representations of the information. While recited in the singular, it will be understood that a message may be composed, transmitted, stored, received, etc. in multiple parts.

As used herein, the term “correspond” encompasses a range of relative relationships between two or more elements. Correspond may refer to equality (e.g., match). Correspond may refer to partial-equality (e.g., partial match, fuzzy match, soundex). Correspond may refer to a value which falls within a range of values.

As used herein “receive” or “receiving” may include specific algorithms for obtaining information. For example, receiving may include transmitting a request message for the information. The request message may be transmitted via a network as described above. The request message may be transmitted according to one or more well-defined, machine readable standards which are known in the art. The request message may be stateful in which case the requesting device and the device to which the request was transmitted maintain a state between requests. The request message may be a stateless request in which case the state information for the request is contained within the messages exchanged between the requesting device and the device serving the request. One example of such state information includes a unique token that can be generated by either the requesting or serving device and included in messages exchanged. For example, the response message may include the state information to indicate what request message caused the serving device to transmit the response message.

As used herein “generate” or “generating” may include specific algorithms for creating information based on or using other input information. Generating may include retrieving the input information such as from memory or as provided input parameters to the hardware performing the generating. Once obtained, the generating may include combining the input information. The combination may be performed through specific circuitry configured to provide an output indicating the result of the generating. The combination may be dynamically performed such as through dynamic selection of execution paths based on, for example, the input information, device operational characteristics (e.g., hardware resources available, power level, power source, memory levels, network connectivity, bandwidth, and the like). Generating may also include storing the generated information in a memory location. The memory location may be identified as part of the request message that initiates the generating. In some embodiments, the generating may return location information identifying where the generated information can be accessed. The location information may include a memory location, network location file system location, or the like.

As used herein a “user interface” (also referred to as an interactive user interface, a graphical user interface, a GUI, or a UI) may refer to a network-based interface including data fields and/or other controls for receiving input signals or providing electronic information and/or for providing information to the user in response to any received input signals. A UI may be implemented in whole or in part using technologies such as hyper-text mark-up language (HTML), FLASH™, JAVA™, .NET™, web services, and rich site summary (RSS). In some embodiments, a UI may be included in a stand-alone client (for example, thick client, fat client) configured to communicate (e.g., send or receive data) in accordance with one or more of the aspects described.

While the above detailed description has shown, described, and pointed out novel features as applied to various embodiments, it can be understood that various omissions, substitutions, and changes in the form and details of the devices or algorithms illustrated can be made without departing from the spirit of the disclosure. As can be recognized, certain embodiments described herein can be embodied within a form that does not provide all of the features and benefits set forth herein, as some features can be used or practiced separately from others. The scope of certain embodiments disclosed herein is indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

WHAT IS CLAIMED IS:

1. A system for managing customizing information on a mobile application, the system comprising one or more computing devices having or being associated with a processor and a memory for maintaining mobile application configuration information in a data store, wherein a first and second instance of the mobile application configuration information in the data store are associated, respectively, with a first and second unique dealer identifier, wherein at least part of the first and second unique dealer identifier corresponds, respectively, to a first and second dealer of respiratory support devices; one or more computing devices having or being associated with a processor and a memory for executing computer-executable instructions to implement a mobile application configuration service for respiratory support devices, wherein the mobile application configuration service is configured to: obtain, from one or more dealer devices, inputs corresponding to dealer profile configuration information, the dealer profile configuration information specifying one or more attributes for generation of mobile application configuration information; generate the mobile application configuration information based on processing the dealer profile configuration; store the generated mobile application configuration information in the data store; obtain a first request from a first end user device, the first request from the first end user device including the first unique dealer identifier; obtain the first instance of mobile application configuration information associated with the first unique dealer identifier from the data store; transmit the first instance of mobile application configuration information responsive to the first request, wherein the first end user device processes the first instance of mobile application configuration information with respect to a first subset of a plurality of respiratory support devices available from the first dealer; obtain a second request from a second end user device, the second request from the second end user device including the second unique dealer identifier; obtain the second instance of mobile application configuration information associated with the second unique dealer identifier from the data store; and transmit the second instance of mobile application configuration information responsive to the second request, wherein the second end user device executes the second instance of mobile application configuration information with respect to a second subset of the plurality of respiratory support devices available from the second dealer, wherein the first subset of respiratory support devices and the second subset of the plurality of respiratory support devices are different.

2. The system of Claim 1, wherein the first subset of the plurality of respiratory support devices are determined according to a funding source associated with the first end user.

3. The system of Claim 1, wherein the first subset of the plurality of respiratory support devices is determined according to a selection of respiratory support devices associated with geographic criteria.

4. The system of Claim 1, wherein at least one of the first instance of mobile application configuration information and the second instance of mobile application configuration information include configuration information operable to configure an initiation of a respiratory support device inspection process.

5. The system of Claim 1, wherein the first instance of mobile application configuration information includes configuration information operable to configure an initiation of a respiratory support device selection routine, the respiratory support device selection routine associated with one or more of the respiratory support devices of the first plurality of respiratory support devices.

6. The system of Claim 1 , wherein the first unique dealer identifier and the second unique dealer identifier correspond to a single dealer.

7. The system of Claim 1 , wherein the first unique dealer identifier and the second unique dealer identifier correspond to two distinct dealers.

8. The system of Claim 1, wherein the mobile application configuration service is further operable to utilize at least one of default or pre-determined information to form the mobile application configuration information maintained in the data store.

9. The system of claim 1, wherein execution of the first and second instance of mobile application configuration information with respect to, respectively, a first and second subset of the plurality of respiratory support devices available from the first and second dealer, includes presentation of the first and second subset of the plurality of respiratory support devices on, respectively, the first and second end user device.

10. The system of claim 1, wherein each of the first and second end user device executes a respective instance of mobile application configuration information to modify a base version of the mobile application on the respective end user device to display a customized version of the mobile application on the respective end user device.

11. A method for configuration of a mobile application associated with medical devices, the method comprising: obtaining, by a configuration service, mobile application configuration information requests from a plurality of mobile devices, the each of the mobile application configuration information requests including a unique dealer identifier; identifying, by the configuration service, mobile application configuration information corresponding to each request based, at least in part, on the respective unique dealer identifier; and transmitting, by the configuration service, the identified mobile application configuration information responsive to each of the mobile application configuration information requests, wherein each mobile device processes the received mobile application configuration information to display a customized mobile application on the mobile device.

12. The method of Claim 11, wherein the at least one customized mobile application includes a processing routine for selection of a subset of a plurality of medical devices.

13. The method of Claim 12, wherein the subset of the plurality of medical devices are selected according to a funding source.

14. The method of Claim 12 wherein the subset of the plurality of medical devices are selected according to geographic criteria.

15. The method of Claim 11, wherein the at least one customized mobile application includes a processing routine for an initiation of a medical device inspection process.

16. The method of Claim 11, wherein the at least one customized mobile application includes a processing routine for a transmission of collected data.

17. The method of Claim 16, wherein the at least one customized mobile application includes at least one of security or authorization information associated with the collected data.

18. The method of Claim 11 , wherein a dealer of medical devices is associated with a single unique dealer identifier.

19. The method of Claim 11 , wherein a dealer of medical devices is associated with a plurality of unique dealer identifiers.

20. A computer-implemented method for managing a plurality of mobile applications executed on a plurality of end user devices based on mobile application configuration information maintained in a data store, the method comprising: responsive to a presentation of a unique dealer identifier, selecting mobile application configuration information based, at least in part, on individual dealer identifiers; and causing the mobile application on the end user device in association with which the unique dealer identifier was presented (“the presenting mobile application”) to be modified by execution of the selected mobile application configuration information.

21. The method of Claim 20, wherein the presenting mobile application is modified by a customized processing routine for selection of a subset of a plurality of medical devices.

22. The method of Claim 20, wherein the presenting mobile application is modified by a configuration of a communication channel for communicating with a dealer.

23. The method of Claim 20, wherein the presenting mobile application is modified by configuration of a data logging process.

24. The method of Claim 20 further comprising obtaining dealer profile configuration information from one or more dealers, the mobile application configuration information being based at least in part on the obtained dealer profile configuration information.

25. The method of Claim 20 further comprising identifying default information for inclusion in the mobile application configuration information.

26. The method of Claim 25, wherein the default information corresponds to an attribute of the one or more dealers.

27. An apparatus for configuring a mobile application, the apparatus comprising: one or more computing devices associated with a processor and a memory for

Ill executing computer-executable instructions to implement a mobile application configuration system, wherein the mobile application configuration system is configured to: transmit a request for mobile application configuration information, the request for mobile application configuration information including a unique dealer identifier associated with a dealer of respiratory support devices; obtain responsive mobile application configuration information associated with the transmitted unique dealer identifier associated with the dealer; and process the obtained mobile application configuration information to configure the mobile application with respect to a subset of a plurality of respiratory support devices available from the dealer, wherein the subset of the plurality of respiratory support devices is less than plurality of respiratory support devices available from the dealer, wherein the subset of the plurality of respiratory support devices is formed based on dealer profile configuration information.

The system of Claim 27, wherein the dealer profile configuration information corresponds to a funding source.

The system of Claim 27, wherein the dealer profile configuration information corresponds to a selection of respiratory support devices according to geographic criteria.

30. The system of Claim 27, wherein the obtained mobile application configuration information includes configuration information operable to configure an initiation of a respiratory support device inspection process.

31. The system of Claim 27, wherein the obtained mobile application configuration information includes configuration information operable to configure a transmission of end user data.

32. The system of Claim 27, wherein the obtained mobile application configuration information includes configuration information operable to configure an initiation of a respiratory support device selection routine, the respiratory support device selection routine associated with one or more of the respiratory support devices of the subset of the plurality of respiratory support devices.

33. The system of claim 27, further configured to: transmit a request for third party configuration information, the third party configuration information to configure a third party mobile application with respect to a third party subset of a plurality of respiratory support devices available from the dealer, the request comprising: selection of a third party subset of the plurality of respiratory support devices available from the dealer to be accessible to the third party, wherein the third party subset of the plurality of respiratory support devices is the same as or a subset of the subset of the plurality of respiratory support devices; and, in response to the request, the system being configured to retrieve the third party configuration information, and process the obtained mobile application configuration information to configure the third party mobile application per the third party configuration information, the configured third party mobile application provides third party access to the third party subset of the plurality of respiratory support devices.

34. The system of claim 27 wherein the mobile application configuration information includes configuration information operable to configure the mobile application with respect to at least one end user feature associated with respiratory support devices, the subset of a plurality of respiratory support devices available from the dealer being an end user feature associated with respiratory support devices.

35. The system of claim 34, wherein the at least one end user feature associated with respiratory support devices further includes at least one of: a respiratory device ordering routine; a respiratory device maintenance routine; patient medical information; patient therapy information; physician information.

36. The system of claim 27, wherein the system is further configured to: transmit a request for third party configuration information, the third party configuration information to configure a third party mobile application with respect to at least one third party feature associated with respiratory support devices, the request comprising: selection of at least one third party feature associated with respiratory support devices to be accessible to the third party, wherein the third party feature is a subset of the at least one end user features associated with respiratory support devices; and, in response to the request, the system being configured to retrieve the third party configuration information, and process the obtained mobile application configuration information to configure the third party mobile application per the third party configuration information, the configured third party mobile application provides third party access to the third party subset of the at least one end user features associated with respiratory support devices.

37. A method for configuration of a mobile application for medical device selection, the method comprising: transmitting, by a mobile device executing the mobile application, a mobile application configuration information request, the mobile application configuration request including a unique dealer identifier; receiving, by the mobile device executing the mobile application, mobile application configuration information based, at least in part, on the unique dealer identifier; and processing, by the mobile device executing the mobile application, the received mobile application configuration information, wherein processing the received mobile application configuration information results in at least one customization of the mobile application.

38. The method of Claim 37, wherein the at least one customization of the mobile application includes a processing routine for selection of one or more of a plurality of medical devices.

39. The method of Claim 38, wherein the plurality of medical devices corresponds to a funding source.

40. The method of Claim 38, wherein the plurality of medical devices corresponds to a selection of medical devices according to geographic criteria.

41. The method of Claim 37, wherein the at least one customization of the mobile application includes an initiation of a medical device inspection process.

42. The method of Claim 38, wherein the at least one customization of the mobile application includes a transmission of data associated with at least one of the mobile application or medical device.

43. The method of Claim 42, wherein the at least one customized mobile application includes an anonymization of the transmitted data.

44. The method of Claim 37, wherein a medical device dealer is associated with a single unique dealer identifier.

45. The method of Claim 37, wherein a medical device dealer is associated with a plurality of unique dealer identifiers.

46. The method of claim 37, further comprising: transmit a request for third party configuration information, the third party configuration information to configure a third party mobile application with respect to a third party subset of the at least one customization of the mobile application., the request comprising: selection of a third party subset of the at least one customization of the mobile application, wherein the third party subset of the at least one customization of the mobile application is the at least one customization of the mobile application; and, transmitting the generated request for third party configuration information, and in response to the request, the system being configured to retrieve the third party configuration information, and process the obtained mobile application configuration information to configure the third party mobile application per the third party configuration information, the configured third party mobile application providing third party access to the third party subset of the at least one customization of the mobile application.

47. A computer-implemented method for customizing a mobile application based on medical device dealer profile configuration information, the method comprising: responsive to a presentation of a unique dealer identifier, receiving mobile application configuration information based, at least in part, on dealer profile configuration information associated with the unique dealer identifier; and causing processing of the received mobile application configuration information to result in a customized mobile application based, at least in part, on configuration parameters specified in the received mobile application configuration information.

48. The method of Claim 47, wherein the customized mobile application includes a customized processing routine for selection of one or more of a subset of a plurality of medical devices.

49. The method of Claim 47, wherein the customized mobile application includes a configuration of a communication channel.

50. The method of Claim 16, wherein the customized mobile application includes at least one of a transmission of medical device patient data or logging of medical device patient data.

51. The method of Claim 47 further comprising obtaining the unique dealer identifier via an input device associated with a mobile device executing the customized mobile application.

52. The method of Claim 47 further comprising obtaining individual patient information corresponding to patient declaration information.

53. The method of Claim 47, wherein the customized mobile application includes a customized processing of orders with the dealer.

54. A computer-implemented method for customizing a mobile application based on medical device dealer profile configuration information, the method comprising: responsive to receipt of a unique dealer identifier, retrieve mobile application configuration information based, at least in part, on dealer profile configuration information associated with the unique dealer identifier; andcausing processing of the received mobile application configuration information to result in a modified mobile application based, at least in part, on configuration parameters specified in the received mobile application configuration information.

55. The method of Claim 54, wherein the modified mobile application includes a customized processing routine for selection of one or more of a subset of a plurality of medical devices.

56. The method of Claim 54, wherein the modified mobile application includes a configuration of a communication channel.

57. The method of Claim 54, wherein the modified mobile application includes at least one of a transmission of medical device patient data or logging of medical device patient data.

58. The method of Claim 54 further comprising obtaining the individual dealer identifier via an input device associated with a mobile device executing the customized mobile application.

59. The method of Claim 54 further comprising obtaining individual patient information corresponding to patient declaration information.

60. The method of Claim 54, wherein the modified mobile application includes a customized processing of orders with the dealer.

61. The method of Claim 54 further comprising transmitting the modified mobile application to an end user device.

62. The method of Claim 54, wherein causing processing of the received mobile application configuration information includes causing, at an end user device, processing of the received mobile application configuration information.

63. The method of Claim 54, wherein causing processing of the received mobile application configuration information to result in a modified mobile application includes automatically causing processing of the mobile application configuration information upon receipt at an end user device.

64. The method of Claim 54 further comprising receiving a base mobile application for use in generating the modified mobile application.

65. The method of Claim 54, wherein the mobile application configuration information is based, at least in part, on dealer specified attributes.

66. The method of Claim 54, wherein the mobile application configuration information is based, at least in part, on user specified attributes.

67. The method of Claim 54, wherein the mobile application configuration information is based on attributes provided at a first time instance.

68. The method of Claim 54, wherein the mobile application configuration information is based on attributes provided at a second time instance, the second time instance subsequent to the first time instance.

69. A computer-implemented method for customizing a mobile application based on medical device dealer profile configuration information, the method comprising: responsive to input of a unique identifier, receiving mobile application configuration information based, at least in part, on dealer profile configuration information associated with the unique identifier; and causing processing of the received mobile application configuration information to result in a customized mobile application based, at least in part, on configuration parameters specified in the received mobile application configuration information.

70. The method of Claim 69, wherein the customized mobile application includes a customized processing routine for selection of one or more of a subset of a plurality of medical devices.

71. The method of Claim 69, wherein the customized mobile application includes a configuration of a communication channel.

72. The method of Claim 69, wherein the customized mobile application includes at least one of a transmission of medical device patient data or logging of medical device patient data.

73. The method of Claim 69 further comprising obtaining the unique identifier via an input device associated with a mobile device executing the customized mobile application.

74. The method of Claim 69 further comprising obtaining individual patient information corresponding to patient declaration information.

75. The method of Claim 69, wherein the customized mobile application includes a customized processing of orders with a dealer.

76. A method for configuration of a mobile application for respiratory health support, the method comprising: transmitting, by a mobile device executing the mobile application, a mobile application configuration information request, the mobile application configuration request including a unique identifier; receiving, by the mobile device executing the mobile application, mobile application configuration information based, at least in part, on the unique identifier; and processing, by the mobile device executing the mobile application, the received mobile application configuration information, wherein processing the received mobile application configuration information results in at least one customization of the mobile application.

77. A method according to claim 76 wherein the mobile application configuration information includes configuration information operable to configure the mobile application with respect to at least one end user feature associated with respiratory health support, that at least one end user feature being included in the customized mobile application in a first configuration.

78. A method according to claim 77 wherein the configuration information operable to configure the mobile application with respect to at least one end user feature corresponds to system preferences.

79. The method of claim 76 or 77, wherein the at least one end user feature associated with respiratory health support includes at least one of: a plurality of respiratory support devices available from a dealer; a respiratory device ordering routine; a respiratory device maintenance routine; respiratory heath maintenance routines (i.e. reminders for check ups etc); patient medical information; patient therapy information; physician information.

80. The method of claim 77 wherein the at least one end user feature includes data stored in one or more databases.

81. A method according to claim 77, further configured to: generate a request for a third party configuration information, the third party configuration information to configure a third party mobile application with respect to a third party subset of the at least one end user features; the step of generating the request comprising the steps of: selecting a third party subset of the at least one end user features, wherein the third party subset of the at least one end user features is the same as or a subset of the subset the at least one end user feature included in the customized mobile application in the first configuration. ; and, transmit the generated request for third party configuration information.

82. A system for configuration of a mobile application for respiratory health support, the system configured to: transmit, by a mobile device executing the mobile application, a mobile application configuration information request, the mobile application configuration request including a unique identifier; receive, by the mobile device executing the mobile application, mobile application configuration information based, at least in part, on the unique identifier; and process, by the mobile device executing the mobile application, the received mobile application configuration information, wherein processing the received mobile application configuration information results in at least one customization of the mobile application.

83. A configurable computer-implemented application for respiratory health support, the application configured to carry out the steps of: transmitting, by a mobile device executing the application, an application configuration information request, the application configuration request including a unique identifier; receiving, by the mobile device executing the application, application configuration information based, at least in part, on the unique identifier; and processing, by the mobile device executing the application, the received application configuration information, wherein processing the received application configuration information results in at least one customization of the application.

84. An apparatus for configuring a mobile application, the apparatus comprising: one or more computing devices associated with a processor and a memory for executing computerexecutable instructions to implement a mobile application configuration system, wherein the mobile application configuration system is configured to: receive a request for mobile application configuration information, the request for mobile application configuration information including a unique dealer identifier associated with a dealer of respiratory support devices; obtain responsive mobile application configuration information associated with the received unique dealer identifier associated with the dealer; and process the obtained mobile application configuration information to configure the mobile application with respect to a subset of a plurality of respiratory support devices available from the dealer, wherein the subset of the plurality of respiratory support devices is less than plurality of respiratory support devices available from the dealer, wherein the subset of the plurality of respiratory support devices is formed based on dealer profile configuration information.

85. The system of claim 84, further configured to: receive a request for third party configuration information, the third party configuration information to configure a third party mobile application with respect to a third party subset of a plurality of respiratory support devices available from the dealer, the request comprising: selection of a third party subset of the plurality of respiratory support devices available from the dealer to be accessible to the third party, wherein the third party subset of the plurality of respiratory support devices is the same as or a subset of the subset of the plurality of respiratory support devices; and, in response to the request, the system being configured to retrieve the third party configuration information, and process the obtained mobile application configuration information to configure the third party mobile application per the third party configuration information, the configured third party mobile application provides third party access to the third party subset of the plurality of respiratory support devices.

86. A method for configuration of a mobile application for medical device selection, the method comprising: receiving, by a mobile device executing the mobile application, a mobile application configuration information request, the mobile application configuration request including a unique dealer identifier; receiving, by the mobile device executing the mobile application, mobile application configuration information based, at least in part, on the unique dealer identifier; and processing, by the mobile device executing the mobile application, the received mobile application configuration information, wherein processing the received mobile application configuration information results in at least one customization of the mobile application.

87. The method of claim 86, further comprising: receiving a request for third party configuration information, the third party configuration information to configure a third party mobile application with respect to a third party subset of the at least one customization of the mobile application, the request comprising: selection of a third party subset of the at least one customization of the mobile application, wherein the third party subset of the at least one customization of the mobile application is the at least one customization of the mobile application; and, receiving the generated request for third party configuration information, and in response to the request, the system being configured to retrieve the third party configuration information, and process the obtained mobile application configuration information to configure the third party mobile application per the third party configuration information, the configured third party mobile application providing third party access to the third party subset of the at least one customization of the mobile application.

88. The system of any one of claims 33, 36, or 85, wherein the request for third party configuration information further comprises a selection of a third party.

89. The method of claim 87, wherein the request for third party configuration information further comprises a selection of a third party.