Method and system for transferring access to patient data between organizations

Abstract

Systems and methods provide for the transfer of access to patient data between organizations. In some implementations, one or more servers use various services (12, 14, 16, 18, 20) to transfer access to patient data from a first organization to a second organization. The server(s) may generate a user interface, receive job input data via the interface, and generate a transfer job based on the job input data. The transfer job may include list data indicating one or more patients. The server(s) may execute the generated transfer job. This execution iterates through the list data and communicates transfer commands to the server(s) services. Access to patient data associated with the patient(s) in the central database(s) indicated by the list data is transferred from the first organization to the second organization. The server(s) may generate transfer job status information regarding the status of the execution for display in the user interface.

Description

[Technical Field]

[0001] [CROSS-REFERENCE TO RELATED APPLICATIONS] This application claims the benefit of U.S. Provisional Application No. 63 / 422,173, filed November 3, 2022, which is incorporated herein by reference in its entirety.

[0002] [Technical field] The present technology relates to methods and systems for transferring access to patient data, and more particularly, to methods and systems for transferring access to patient data, such as data related to the use and / or operation of medical devices, such as respiratory pressure therapy devices, from one organization to another. [Background technology]

[0003] When an organization (e.g., a health care organization such as a home medical equipment (HME) company) acquires or merges with another similar organization, patient data, such as electronic data related to the use and / or operation of home medical devices, such as respiratory therapy devices, of the acquired organization must be merged or integrated with similar patient data of the acquiring organization so that internal systems can function properly. In this regard, the new organization typically needs access to historical data about the use and / or operation of each user of such devices, which generates / accumulates data daily for each user. Prior to such a transfer, such data from both organizations may be maintained separately in the data systems (e.g., server(s), list(s), and / or database(s)) of the managing entity. Typically, a transfer request is received from the acquired organization and / or an administrator of the acquiring organization, or the like, to transfer or enable access to the acquired organization's patient data for each patient managed by the acquired organization, thereby integrating such patient data with the acquiring organization's patient data. This may also include updating certain patient data related to the receiving organization's rules and requirements.

[0004] To accomplish such a transfer, traditional methods may involve a programmer creating and executing custom, transfer-specific database scripts to change access to the numerous components of each patient's patient data from one organization to another. However, traditional methods are time-consuming and prone to consistency issues within the patient data due to the complex organization of such data components, making them not particularly effective.

[0005] Therefore, there is a need for improved systems and methods for transferring patient access to patient data between organizations. Summary of the Invention

[0006] The system and method provides for the transfer of access to patient data between organizations.

[0007] Some implementations of the present technology may include a method on one or more servers for transferring access to patient data from a first organization to a second organization. The patient data may include therapy data for one or more patients. The method may include generating, by the one or more servers, a user interface. The method may include receiving job input data via the user interface, where the job input data may include transfer information indicating the first organization and the second organization. The method may include generating, by the one or more servers, a transfer job based on the job input data. The transfer job may include list data indicating one or more patients, where the one or more patients are associated with the first organization. The method may include executing, by the one or more servers, the generated transfer job. The executing may include iterating through the list data and, for each patient indicated by the list data, communicating a transfer command to multiple data services of the one or more servers, whereby access to patient data in a central database associated with the one or more patients indicated by the list data is transferred from the first organization to the second organization. The method may include generating transfer job status information regarding the status of the execution for display on a user interface.

[0008] In some implementations, the multiple data services may include a billing rules system, a compliance rules system, a list service, and a device type subset data system. The user interface may prompt for input of a target entity identification and a source entity identification and generate a network communication to a merger coordinator service using the input target entity identification and the input source entity identification. The merger coordinator service may receive the network communication including the entity identification and the source entity identification and query a central database to generate a list of patients associated with the source entity identification. The user interface may further prompt for input of a location of a clinical user or a source entity and generate a network communication to the merger coordinator service using the location of the clinical user or the source entity. The user interface may further prompt for input of a location of a clinical user or a target entity and generate a network communication to the merger coordinator service using the location of the clinical user or the target entity. The user interface may further prompt for input of a location of a clinical user or a target entity and generate a network communication to the merger coordinator service using the location of the clinical user or the target entity. The user interface may further prompt for input of a location of a clinical user or a target entity and generate a network communication to the merger coordinator service using the location of the clinical user or the target entity. The merger coordinator service may iteratively communicate with the patient transfer service for each patient in the list of patients. The patient transfer service may communicate with multiple data services and a central database in response to each iterative communication from the merger coordinator service to transfer access to patients on the patient list from the first organization to the second organization. The user interface may present a restart icon associated with a failed transfer, and the user interface may communicate a request to restart the failed transfer in response to activation of the restart icon. The merger coordinator service may communicate with a database to store transfer job status information. Patient data to which access may be transferred by the above execution may include therapy device data.The method may further include communicating with the one or more servers one or more control commands to the patient therapy device based on the therapy device data to modify operation of the therapy device.

[0009] Some versions of the present technology may include a system for transferring access to patient data from a first organization to a second organization. The patient data may include therapy data for one or more patients. The system may include one or more processors. The system may include one or more computer-readable storage media having program instructions that, when executed by the one or more processors, cause the system to generate a user interface. The instructions may cause the system to receive job input data via the user interface. The job input data may include transfer information indicating the first organization and the second organization. The instructions may cause the system to generate a transfer job based on the job input data, the transfer job may include list data indicating one or more patients. The one or more patients may be associated with the first organization. The instructions may cause the system to execute the generated transfer job. The execution may include iterating through the list data and, for each patient indicated by the list data, communicating a transfer command to multiple data services of one or more servers, thereby transferring access to patient data in a central database associated with one or more patients indicated by the list data from the first organization to the second organization. The instructions may cause the system to generate transfer job status information regarding the status of the execution for display on a user interface.

[0010] In some implementations, the plurality of data services may include a billing rules system, a compliance rules system, a list service, and a device type subset data system. The user interface may be configured to prompt for input of a target entity identification information and a source entity identification information, and to generate a network communication to a merger coordinator service using the input target entity identification information and the input source entity identification information. The merger coordinator service may be configured to receive the network communication including the entity identification information and the source entity identification information, and may be further configured to query a central database to generate a list of patients associated with the source entity identification information. The user interface may be further configured to prompt for input of a location of a clinical user or a source entity, and may be further configured to generate a network communication to the merger coordinator service using the location of the clinical user or the source entity. The user interface may be further configured to prompt for input of a location of a clinical user or a target entity, and may be further configured to generate a network communication to the merger coordinator service using the location of the clinical user or the target entity. The user interface may be further configured to prompt for input of a location of the clinical user or the target entity and may be further configured to generate a network communication to a merger coordinator service using the location of the clinical user or the target entity. The merger coordinator service may be configured to iteratively communicate with a patient transfer service for each patient in the list of patients. The patient transfer service may be configured to communicate with multiple data services and a central database in response to each iterative communication from the merger coordinator service to transfer access to the patient in the list of patients from the first organization to the second organization. The user interface may be configured to present a restart icon associated with a failed transfer, and the user interface may be configured to communicate a request to restart the failed transfer in response to activation of the restart icon.The patient data to which access may be transferred by execution of the generated transfer job may include therapy device data, and the system may be further configured to communicate with one or more servers one or more control commands to the patient therapy device based on the therapy device data to modify operation of the therapy device.

[0011] Some implementations of the present technology may include a method on one or more servers for transferring access to patient data from a first organization to a second organization. The patient data may include therapy data related to a patient using a therapy device. The method may include generating, by the one or more servers, a user interface for transferring access to the patient data. The method may include receiving, by the user interface, input data from the second organization, the input data may include a device identification indication for the therapy device. The method may include communicating a transfer command to multiple services on the one or more servers based on receiving the device identification indication, thereby transferring access to the patient data in a central database for the patient from the first organization to the second organization. The method may include generating an indication of the access transfer for display on the user interface.

[0012] In some implementations, the user interface prompts for input of a serial number of the therapy device and activates a search of the central database by the serial number. In response to the search, the user interface may display patient data for a patient associated with (a) the first organization and (b) a device identification indication of the therapy device. The user interface may prompt for input of confirmation of authority to request the transfer of the patient from the first organization to the second organization. The user interface may prompt for input of a clinical user of the second organization and / or a location of the second location. The user interface may display instructions for the transfer of access to the second organization. The method may further include generating a further user interface and communicating the further user interface to the first organization, where the further user interface may include displaying instructions for the transfer of access. The patient data to which access may be transferred based on the communicated transfer command may include therapy device data associated with the therapy device, and the method may further include communicating one or more control commands to the therapy device with one or more servers based on the therapy device data to modify operation of the therapy device.

[0013] Some implementations of the present technology may include a system configured to transfer access to patient data from a first organization to a second organization. The patient data may include therapy data for one or more patients. The system may include one or more processors. The system may include one or more computer-readable storage media having program instructions that, when executed by the one or more processors, cause the system to generate a user interface for transferring access to the patient data. The executed instructions may include receiving, via the user interface, input data from the second organization, the input data may include a device identification indication for the therapy device. The executed instructions may cause the system to communicate a transfer command to multiple services on one or more servers based on the received device identification indication, whereby access to the patient's patient data in a central database is transferred from the first organization to the second organization. The executed instructions may cause the system to generate an indication of the access transfer for display on the user interface.

[0014] In some implementations, the user interface may be configured to prompt for input of a serial number of the therapy device and activate a search of the central database by the serial number. In response to the search, the user interface may be configured to display patient data for a patient associated with (a) the first organization and (b) a device identification indication of the therapy device. The user interface may be configured to prompt for input of confirmation of authority to request a transfer of the patient from the first organization to the second organization. The user interface may be configured to prompt for input of a clinical user of the second organization and / or a location of the second location. The user interface may be configured to display instructions for the transfer of access to the second organization. The system may be further configured to generate a further user interface and communicate the further user interface to the first organization, where the further user interface may be configured to display instructions for the transfer of access. The patient data to which access may be transferred based on the communicated transfer command may include therapy device data associated with the therapy device, and the method may further include communicating one or more control commands to the therapy device with one or more servers based on the therapy device data to modify operation of the therapy device.

[0015] It will be appreciated that some of the aspects may form sub-aspects of the technology, and that various of the sub-aspects and / or aspects may be combined in various ways to form additional aspects or sub-aspects of the technology.

[0016] Other features of this technology will become apparent from consideration of the information contained in the following detailed description, abstract, drawings, and claims. [Brief explanation of the drawings]

[0017] The present technology is illustrated by way of example and not by way of limitation in the accompanying drawings, in which like reference numerals include like elements as follows:

[0018] [Figure 1]FIG. 1 is a system diagram illustrating the communication flow involving a transfer tool for managing data access transfer within a patient data management system in accordance with one embodiment of the present technology. [Figure 2] 2A-2C illustrate various graphical representations of an exemplary user interface that may be generated in connection with operation of the transfer tool of FIG. 1. [Figure 3] 2A-2C illustrate various graphical representations of an exemplary user interface that may be generated in connection with operation of the transfer tool of FIG. 1. [Figure 4] 2A-2C illustrate various graphical representations of an exemplary user interface that may be generated in connection with operation of the transfer tool of FIG. 1. [Figure 5] 2A-2C illustrate various graphical representations of an exemplary user interface that may be generated in connection with operation of the transfer tool of FIG. 1. [Figure 6] 2A-2C illustrate various graphical representations of an exemplary user interface that may be generated in connection with operation of the transfer tool of FIG. 1. [Figure 7] 2A-2C illustrate various graphical representations of an exemplary user interface that may be generated in connection with operation of the transfer tool of FIG. 1. [Figure 8] 2A-2C illustrate various graphical representations of an exemplary user interface that may be generated in connection with operation of the transfer tool of FIG. 1. [Figure 9] 2A-2C illustrate various graphical representations of an exemplary user interface that may be generated in connection with operation of the transfer tool of FIG. 1. [Figure 10] 2A-2C illustrate various graphical representations of an exemplary user interface that may be generated in connection with operation of the transfer tool of FIG. 1. [Figure 11] 2A-2C illustrate various graphical representations of an exemplary user interface that may be generated in connection with operation of the transfer tool of FIG. 1. [Figure 12] 1 illustrates an exemplary process for such a transfer tool, in accordance with some embodiments of the present technology. [Figure 13]FIG. 10 is another system diagram illustrating a communication flow for managing transfer of data access within a patient data management system in accordance with another embodiment of the present technology. [Figure 14] 14 illustrates various graphical representations of one exemplary user interface that may be generated in connection with operation of the system of FIG. 13. [Figure 15] 14 illustrates various graphical representations of one exemplary user interface that may be generated in connection with operation of the system of FIG. 13. [Figure 16] 14 illustrates various graphical representations of one exemplary user interface that may be generated in connection with operation of the system of FIG. 13. [Figure 17] 14 illustrates various graphical representations of one exemplary user interface that may be generated in connection with operation of the system of FIG. 13. [Figure 18] 14 illustrates various graphical representations of one exemplary user interface that may be generated in connection with operation of the system of FIG. 13. [Figure 19] 14 illustrates an exemplary process for data access transfer, such as that involved in the operation of the system of FIG. 13. [Figure 20] FIG. 1 is a block diagram of an illustrative example of a computing system. [Figure 21A] 1 shows an exemplary system in accordance with the present technology. A patient 1000 wearing a patient interface 3000 receives a supply of compressed air from an RPT device 4000. The air from the RPT device 4000 is humidified in a humidifier 5000 and delivered to the patient 1000 through an air circuit 4170. A bed companion 1100 is also shown. [Figure 21B] The RPT device 4000 is shown in use on a patient 1000 wearing a nasal mask 3000. [Figure 21C] The RPT device 4000 is shown in use on a patient 1000 wearing a full face mask 3000. [Figure 22] 3 shows an exemplary non-invasive patient interface 3000 in the form of a nasal mask. [Figure 23A]4 shows an RPT device 4000 in accordance with one form of the present technology. [Figure 23B]

[0033] Fig. 40 shows a schematic diagram of the pneumatic circuit of an RPT device 4000 in accordance with one form of the present technology, indicating upstream and downstream directions. [Figure 23C] 40 shows a schematic diagram of the electrical components of an RPT device 4000 in accordance with an aspect of the present technology. [Figure 23D] 23D shows a schematic diagram of an algorithm 4300 implemented in an RPT device 4000 in accordance with one aspect of the present technology. In Fig. 23D, solid arrows indicate the actual flow of information, for example via electronic signals. [Figure 23E] 23D in accordance with an aspect of the present technology. [Figure 24] A humidifier 5000 is shown. DETAILED DESCRIPTION OF THE INVENTION

[0019] Before describing the present technology in further detail, it is to be understood that the present technology is not limited to particular examples described herein, as such may vary, and it is also to be understood that the terminology used in this disclosure is for the purpose of describing only the particular examples described herein, and is not intended to be limiting.

[0020] The following description is provided in connection with various examples that may share one or more common characteristics and / or features. It should be understood that one or more features of any one example may be combined with one or more features of another example or other examples. Additionally, a single feature or combination of features in any example may constitute an additional example.

[0021] FIG. 1 illustrates an example operational flow of a patient integration tool 10 for a patient data management system for transferring access to patient data from one organization to another, according to the present technology. The need for such integration can arise for a variety of reasons. For example, mergers and acquisitions between organizations may require such data transfer. Similarly, data transfer may be necessary if a patient wishes to transfer to another organization. This technology allows providers to be more productive by providing access to newly acquired patients. For example, when one organization acquires or merges with another organization, the acquiring organization's patient data must be merged or integrated to properly operate its internal systems. Typically, the acquired organization's patient data and the acquiring organization's patient data are integrated by transferring a patient's access to their patient data from the acquired organization to the acquiring organization, such as after receiving a transfer request from an administrator 11 of the related organization. In this disclosure, the organization may be referred to as a respiratory therapy provider organization, such as a home medical equipment (HME) company, or other healthcare organization, such as a physician organization, sleep lab, or integrated delivery network (IDN) (i.e., a network of healthcare providers and facilities within a specific geographic area that delivers patient care). Such patient data may also be utilized to alter patient therapy, such as, for example, when the data is utilized to communicate control commands to a patient therapy device to alter the operation of the therapy device (e.g., changing therapy settings for a therapy provided by such device). Patient data may be organized and maintained in data systems and / or data services (e.g., server(s), list(s), and / or database(s)) of a managing entity on which the patient integration tool 10 operates. As discussed in more detail herein, a tool may be viewed as a set of one or more processes or services executing on one or more processors, such as processor(s) of a server(s).This process may be implemented by software to enable such transfer(s) to and from the data system, such as by generating communication and / or control commands to the data system to execute the access transfer, and receiving inputs and providing outputs to monitor such transfers, as discussed in more detail herein. Additionally, the system may record and track data regarding such consolidation and transfer of patient records, which may generate analytics regarding trends in patient movement within and / or from a particular organization.

[0022] The present technology offers several advantages over traditional methods of transferring access to patient data (i.e., customizing and executing standalone database scripts). For example, the tool 10 of the present technology provides an efficient and effective solution for transferring access to patient data from one organization to another, thereby eliminating problems caused by the complexity inherent in traditional methods of patient data transfer processes. Additionally, the tool 10 can be configured to operate in conjunction with multiple data storage systems used by a managing entity to maintain consistent patient data across multiple systems while easily allowing acquiring organizations new access to that data. Thus, the present technology provides a solution that addresses problems associated with the complexity of organizing and managing data maintained by and within digital data systems. Furthermore, if such transferred patient data includes therapy device data (e.g., device settings and / or unique device identification information) that can be utilized to make changes to the transferred patient's therapy provider provided by the patient's therapy device, completion of the transfer via the transfer techniques disclosed herein enables the new organization to manage the operation of the transferred patient's therapy device based on the transfer, such that the new organization can operate a patient data management system to electronically communicate with the transferred patient's therapy device. Such electronic communication may include transmitting and / or receiving data to and from the therapy device. Furthermore, such communication may include communicating control commands from the system, such as over a network, to the transferred patient's therapy device(s) to remotely modify the operation of the therapy device(s) (e.g., changing therapy settings for the therapy provided by such device).

[0023] 1 , a patient integration tool 10 in accordance with the present technology may include any one or more of a plurality of services 12, 14, 16, a database 18, and a user interface(s) 20. As described in further detail below, the tool 10 described herein is configured to transfer access to patient data associated with patients of a source organization (e.g., an acquired organization) to a target organization (e.g., an acquiring organization). The components 12, 14, 16, 18, 20 of the tool 10 may be implemented in any combination of hardware or software, including software executed by multiple computer systems or servers.

[0024] The tool 10 may be configured to generate user interface(s) 20 for communicating (input / output) with a user (e.g., an administrative entity administrator) 22 regarding communication between the tool 10 and the plurality of services 12, 14, 16. Accordingly, the user interface 20 may be configured to receive user input required by the plurality of services 12, 14, 16 to execute a patient transfer process and to send system output for viewing by the user, such as the status of such transfers. For example, the user interface 20 may be configured to receive user-input data required by the plurality of services 12, 14, 16 to create and execute a transfer job (i.e., a collection of one or more patient transfers) and to output transfer job details for access by the user 22. The user interface 20 may be a graphical user interface configured to enable visualized data entry and provide data presentation. For example, the user interface may include drop-down menus and / or predetermined selection options for quick entry and access.

[0025] In some implementations, the user interface 20 may be implemented by application(s) running on either a web-based platform (server online / internet web application) and / or a mobile-based platform (mobile application), and a user may access and / or communicate with the tool's user interface over a network such as the Internet or via the Internet using a computing device including a display, input device, and communication interface. Non-limiting examples of computing devices include personal computers (laptop or desktop), mobile phones (smartphones), tablets, personal digital assistants (PDAs), or other similar devices. Typically, a computing device accesses the system directly through an Internet Service Provider (ISP) or indirectly through another network interface.

[0026] 1 , multiple services 12, 14, and 16 assist in executing a transfer job by creating a transfer job based on user input and by communicating with other systems that maintain patient data to transfer access to the patient data associated with the transfer job from the source organization to the target organization. The multiple services may include an organization merger coordinator (OMC) service 12, a patient transfer (PT) service 14, and a reporting service 16. The OMC service 12 is configured to communicate with or through a user interface 20, such as when the OMC is configured to generate a user interface. In some implementations, the OMC may be implemented with an application programming interface (API) 24 configured to receive requests from the user interface 20 and provide responses as output to the user interface 20 to facilitate communication with the OMC service 12. For example, when user 22 performs a particular input action on user interface 20 (e.g., clicking a button or icon embedded on a web page), user interface 20 can generate a communication and communicate the request to API 24 as a request for data retrieval (i.e., retrieving transfer job details), data storage (i.e., storing transfer job details), and / or the like. OMC service 12 can then interpret and act on the request via API 24. In some implementations, the request sent by user interface 20 can be a call made via XML over Hypertext Transfer Protocol (HTTP), a call made directly to API 24, and / or a call made to a wrapper around API 24.

[0027] As previously described, the user interface 20 may be operated by a user to input job transfer input data. The transfer job input data is information necessary for the OMC service 12 to execute the patient transfer process. The transfer job input data may include transfer information related to a source (or acquired) organization and a target (acquiring) organization. Such input data provided by the user 22 may be entered and sent or communicated to the API 24, for example, without limitation, as JSON, XML data, or the like, and may be communicated via an appropriate communication protocol, such as HTTP. Optionally, JSON (a data interchange format) may be used by the user interface to format the input data provided by the user 22 as a specification for the merger of patient data between the two organizations, i.e., a "merger specification."

[0028] Accordingly, the user interface 20 may be configured to input a transfer job merge specification, which may include inputting transfer information associated with the source and target organizations to merge patients from the source organization to the target organization so that the target organization gains access to the merged patient data. Specifically, as seen in the example of FIG. 2, in a transfer job creation section 26 of the home page 28, the user 22 may input various information associated with the source and target organizations to create a transfer job. To do so, the user 22 provides transfer information associated with the source and target organizations. For example, a source organization field 30 is provided, which may be populated by selecting the source organization from a source organization list box 32, as seen in FIG. 3. Additionally, grouping criteria may be selected in the user interface to target a subset of the source organization's patients to be included in the merger or transfer specification. For example, the user interface may be configured to include and select patients associated with a particular location(s) or a particular clinician(s). Similarly, in some implementations, the user interface may be configured to include and select patients associated with a particular device (e.g., a device type, such as one or more of a ventilator, a sleep diagnostic screener, and / or a CPAP device, or a particular device model). Other criteria may also be implemented. In the example of FIG. 4, the source organization clinical user field 34 and the source organization location field (not shown) may be populated by either selecting a source organization clinical user from a source organization clinical user listbox 36 and / or selecting a source organization location from a source organization location listbox (not shown). Similarly, as seen in FIGS. 5-7, the target organization field 38, the target organization clinical user field 40, and the target organization location field 42 may be populated by selecting a target organization from a target organization listbox 44, a target organization clinical user from a target organization clinical user listbox 46, and a target organization location from a target organization location listbox 48, respectively.In this regard, the user interface may be configured to input merge specifications that may specify patient transfers on a location-by-location basis (i.e., all patients at a particular location at the source organization) and / or a clinician-by-clinician basis (i.e., all patients managed by a particular clinician at the source organization) (see, e.g., Figures 2-4). Additionally, the user interface may be configured to input merge specifications that may specify a particular target location for the transferred patient and / or a particular target clinician for the transferred patient (see, e.g., Figures 5-7).

[0029] When creating a merger specification, a user can additionally specify certain types of information to transfer. Accordingly, the user interface can be configured to input one or more types of data that can be included in or excluded from the transfer. For example, the user 22 can choose to retain (or transfer) various information related to a patient during the patient transfer process. For example, as seen in FIG. 8 , the transfer creation section 26 can provide one or more selectors (e.g., check boxes or toggles), such as four toggle switches for transferring / updating insurance information, physician information, and including patients who do not or have not yet been assigned home medical equipment, among others. Examples of such selectors are shown in FIG. 8 as “Transfer Insurance” 50, “Transfer PLI” 52, “Transfer Physician” 54, and “Transfer Patients Without Equipment” 56. However, the tool 10 can be adapted to incorporate any number of toggle switches for retaining additional information related to a patient, as needed or desired to accomplish a particular transfer, given the nature of the data and the nature of storage of such data by the data system(s).

[0030] Accordingly, these exemplary toggle switches 50, 52, 54, 56 can be activated by user 22 to preserve (or transfer) information associated with the toggle switch during a transfer job. For example, user 22 can turn on insurance toggle switch 50 to transfer insurance information (e.g., insurance company name, policyholder ID, etc.) associated with the patient at the source organization to ensure the patient is properly monitored for compliance after being transferred to the target organization. Similarly, when physician toggle switch 54 is turned on, physician information (e.g., physician name, work address, etc.) associated with the patient at the source organization is transferred during the transfer job to ensure each patient's physician link is maintained. The no-device patient toggle switch 56 allows patients without a therapy device (e.g., a CPAP device) to be included during the patient transfer. The PLI (Patient-Level Integrator) toggle switch 52 can be implemented to ensure patient-level integrations from the source organization are preserved at the target organization.

[0031] Once all transfer information indicating the source and target organizations, including information related to the toggle switches, has been provided by the user 22, the user interface 20 displays a merger specification details page 58 for the user 22 to confirm the details of the transfer job information, such as in the exemplary format shown in FIG. 9 . Upon clicking an input icon, such as an “Add and Start Job” button 60, the user-entered information (merger specification) may be validated via a pre-transfer validation module, such as by checking one or more rules for such a merger. The user-entered information may then be communicated to the API 24, which sends requests to the multiple services 12, 14, 16 to generate and execute a transfer job based on the user input. In the case of a validation check, if the user-entered information fails the pre-transfer validation, the transfer job is not generated and thus not executed. For example, if the source organization information provided by the user 22 is the same as the target organization information provided by the user, the pre-validation fails, and the user 22 is directed to an error page displaying the error details. Once the user-entered information passes pre-transfer validation, the user-entered data is formatted as a merge specification, and the merge specification is sent to the API 24 to create transfer commands with multiple services 12 , 14 , 16 .

[0032] 1 , OMC service 12 is utilized to interpret and process requests from API 24 and complete transfer jobs based on the merger specifications. OMC service 12 is operatively connected to and capable of communicating with one or more databases, such as OMC database 18 and central database (e.g., ECO database) 62. Central database 62 stores and maintains patient data, including patient-to-organization relationships (or links). Thus, central database 62 includes multiple tables with multiple disparate data fields, each of which may include data related to a patient (e.g., demographic information, diagnosis information, therapy information, device information, compliance information, etc.), an organization (e.g., organization name, organization location, organization clinical users, etc.), etc.

[0033] Upon interpreting and processing the transfer command, the OMC service 12 may access the central database 62 to obtain the data necessary to fulfill the request. For example, the OMC service 12 may access the central database 62 (e.g., by thereby generating one or more communications) and determine which patients in the database to transfer (i.e., patients associated with the source organization as specified by the terms of the merger specification) by retrieving the necessary data related to the patients of the source organization. The OMC service 12 then organizes the retrieved data to create a patient transfer dataset for access transfer for each patient included in the merger specification. The OMC service 12 then begins execution of the transfer job by generating a transfer job based on the patient transfer dataset and issuing one or more requests to the PXS service 14 including instructions to execute the transfer of access to the patient data for each patient included in the patient transfer dataset. For example, the OMC service 12 iterates through the patient transfer dataset and, for each patient in the dataset, issues instructions to the PXS service 14 to affect the transfer of access to the patient data for each patient until the final patient in the patient transfer dataset is completed.

[0034] Thus, the PXS service 14 is operatively connected to and communicates with the OMC service 12, the central database 62, and one or more additional data systems or services (e.g., listing services) that manage / organize the storage of patient data. This enables the PXS service 14 to receive requests from the OMC service 12 and execute instructions to perform one-time transfer access of the patient's patient data. For example, upon interpreting and processing the request from the OMC service 12, the PXS service 14 may access the central database 62 to retrieve data related to the patient and assign (or update) the retrieved data to the target organization information (e.g., target clinical user, target location, etc.) specified in the merger specification so that the patient is now associated with the target organization.

[0035] Accordingly, the PXS service 14 is also operatively connected to and communicates with additional systems, such as a plurality of systems 64, 66, 68, and 70, which may be various data services. Accordingly, each of the plurality of systems 64, 66, 68, and 70 may provide additional data that may depend on the patient-organization relationship. Therefore, so that the systems 64, 66, 68, and 70 operate appropriately with respect to the patient data in the central database 62, each system is updated in light of the patient-organization transfer stored in the central database 62. Accordingly, after successfully transferring access to the patient data associated with the patient in the central database 62, the PXS service 14 sends a request to each of the plurality of internal systems 64, 66, 68, and 70 to update their systems with the transferred patient data so that the systems reflect the updated patient-organization relationship in the central database 62. Such updates may include, for example, compliance systems, billing systems, data metrics systems, listing service(s), etc. For example, the following exemplary systems may be updated based on instructions received from the PXS service 14, the PDS billing system 62, the patient list service (PLS) system 66, the Briscoe system 68, and the Sully (ACE) system 70.

[0036] For example, one system may be a PDS billing system 64 that stores and manages billing plan information associated with patients. Thus, when the PXS service 14 sends an update request, the billing plans stored in the PDS billing system 64 are updated to reflect the updated billing plans associated with the transferred patient stored in the central database 62. If any of the transferred patient's billing plans are not supported by the target organization, a new compatible billing plan may be created for such patient and stored in the PDS billing system 64 so that claims may continue to be generated for that patient. The physicians associated with the transferred patient are also updated to maintain the patient-physician relationships stored in the central database 62.

[0037] Another exemplary system may be a listing service, such as PLS system 66, that may store listings that depend on patient-organization relationships. Thus, updated patient-organization relationships associated with a transferred patient may be applied to PLS system 66 through communication with PXS service 14. The updated listing in PLS system 66 may then assist the transferred patient in being accurately accessed by the target (new) organization rather than the previous (old) organization.

[0038] Another exemplary system may be the Briscoe system 68, which manages specific patients using a common subset of HME device types, such as ventilators, in a central database and stores the relationships between such patients (e.g., ventilator patients) and organizations. Updated patient-organization relationships associated with a transferred patient may be applied to the Briscoe system 68 via PXS service 14 communications, such as when the patient wears a specific HME device of the common subset of device types (e.g., when the patient is a ventilator user). For example, the Briscoe system may be considered a device type subset data system that manages access to specific display pages for patients, such as through a listing service, to provide access to different data and various metrics uniquely associated with the subset of devices managed by the system. Such a system may manage access to pages and data for ventilated patients (e.g., ventilator users as opposed to CPAP device users, or vice versa), who have different data and metrics compared to other device users.

[0039] Like the PLS system 66, the updated patient-organization relationship within the Briscoe system 68 may allow the target (new) organization, rather than the previous (old) organization, to accurately access certain data for the transferred patient associated with a particular type of HME device.

[0040] Another exemplary system may be a compliance system, such as the Sully system 70, that stores and maintains data related to patient compliance rule(s). Insurance companies or other reimbursement entities often require evidence that a patient prescribed respiratory therapy has remained "compliant," i.e., used the therapy device in accordance with predetermined "compliance rules," before reimbursing the patient for the therapy device. Typically, compliance rules require some minimum amount of usage per session over a number of consecutive sessions, known as a compliance period. The compliance rules stored in the system 70 may be updated to reflect updated compliance rule(s) associated with the transferred patient stored in the central database 62. The central database 62 may store a base level of information regarding the compliance rule(s) associated with each patient, while the details of the compliance rules may be stored in the additional system 70.

[0041] Upon completion of each patient transfer job, the PXS service 14 communicates back to the OMC service 12 that the transfer job for a particular patient is complete. The OMC service 12 may then transmit information related to the transfer job and the transferred patient (e.g., transfer job information, updated patient information, etc.) to the OMC database 18 for storage. The OMC database 18 is configured to store data structures corresponding to the transfer job and the transferred patient. For example, the OMC database 18 may store data such as a transfer job ID, source organization, target organization, job status, job creation date, and patient ID. The OMC database 18 may be configured as any type of database, such as a relational database, a distributed database, an object database, an object-relational database, or a NoSQL database. The OMC database 18 may then be used (accessed) by the OMC service 12 to provide information to a user interface, such as responding to a request for the status of a merger specification generated in the user interface.

[0042] For example, if error(s) occur during the patient transfer process performed by PXS service 14, the service will stop the transfer of access to the patient data for the patient and communicate the error to OMC service 12 by returning details of the error. OMC service 12 may then display such information on user interface 20. As previously described, OMC service 12 may continue to send instructions from the merge specification to PXS service 14 to perform the transfer of access to the patient data for each next patient in the patient transfer dataset until all patients have been processed from the dataset.

[0043] 2, 10, and 11 are exemplary web pages that may be used to access and manage transfer jobs submitted to the OMC service 12. Such web pages may be presented to a user, such as a merger manager, via the user interface 20 described above. FIG. 2 illustrates an example of what may be the system's home page 28 after a user 22 logs into the system with established authentication credentials (e.g., username and password). Such home page 28 may allow the user 22 to view a list of transfer jobs stored in the OMC database 18. As seen in FIG. 2, the transfer job page may include multiple sections, such as a transfer job information section 72 for displaying a list of transfer jobs and a transfer job creation section 26 for enabling a user to enter information related to the source and target organizations to create a transfer job. The transfer job creation section 26 operates as described above.

[0044] As illustrated in the example of FIG. 2, the transfer job information section 72 may display a list of transfer jobs, such as having multiple columns displaying information such as source organization, source clinical user, source clinical location, target organization, target clinical location, target clinical user, and / or status. The status column 74 indicates the status of the transfer job. For example, a "Running" status indicates that the job is currently running, a "Completed" status indicates that the job completed without errors, and a "Failed" status indicates that the job completed with errors. For user convenience, the list of transfer jobs can be filtered to display only "Running" jobs or "Completed" / "Failed" jobs by filtering the transfer jobs using an input selector, such as a job toggle switch 76.

[0045] The Transfer Job Information section 74 of the home page 28 also provides input elements (e.g., buttons, icons, etc.) that the user 22 can activate to access and manage the transfer jobs displayed in this section. Each input element can request information related to its function by generating a call to the API 24 upon activation, which can then communicate with any of the services 12, 14, 16, as appropriate, to formulate and return the desired results. For example, as seen in FIG. 2 , the “Job Information” column 78 displays a clickable “i” icon 80. When the user clicks on the icon 80, the OMC service 12 receives a request from the API 24 and queries the OMC database 18 to retrieve details about the clicked transfer job stored in the OMC database 18. Next, as seen in the exemplary display of FIG. 10 , the user interface 20 generates a pop-up panel 82 that contains details of the retrieved transfer job (e.g., the number of patients transferred, etc.).

[0046] Additionally, an "Action" column 84 provides various action icons that the user 22 may activate (e.g., click) to perform specific actions for managing the transfer job. For example, if the user 22 wants to stop a currently running transfer job, the user 22 can click the "square" icon (not shown), which generates a call to the OMC API to stop the running transfer job. For "Failed" jobs, an "arrow" icon 86 and an "exclamation point" icon 88 are provided in the action column 84. As seen in FIG. 11 , the arrow icon 86 allows the user 22 to restart the failed transfer job, and the exclamation point icon 88 directs the user 22 to an error page that displays details of each error that occurred during the execution of the transfer job. Thus, when a particular icon is activated (e.g., clicked), the OMC service 12 can receive a request from the API 24 according to the purpose of the particular icon. Thus, for icon 88, when API 24 processes the request, OMC service 12 can query OMC database 18 to obtain details of any errors associated with the clicked transfer job stored in OMC database 18 and respond with the details for display on user interface 20. For the completed job shown in the example of FIG. 11, the arrow and exclamation point icons 86, 88 can be disabled by user interface 20 because the transfer job completed without error.

[0047] User interface 20 may be configured to allow user 22 to download and view details of a completed relocation job by activating (e.g., clicking) a "down arrow" icon (not shown) provided by user interface 20. For example, when user 22 clicks the icon, OMC service 12 receives a request from API 24 and sends instructions to reporting service 16 to query OMC database 18 to retrieve data related to the relocation job. Reporting service 16 may then generate a readable file (e.g., PDF or Excel) containing the retrieved data, such as formatted data, and transmit the file to the user's computing device for access by user 22.

[0048] Thus, the present technology may implement a system that enables streamlined patient data transfer. For example, referring to FIG. 12, a method 90 of such a system may enable transferring access to patient data from a source organization to a target organization. In this exemplary process of FIG. 12, at step 92, the method may include generating, by one or more servers, a user interface. At step 94, the method may include receiving job input data via the user interface. The job input data may include transfer information indicating a first organization and a second organization. At step 96, the one or more servers may generate a transfer job based on the job input data. The transfer job may include list data indicating one or more patients. The one or more patients may be associated with the first organization. At step 98, the one or more servers may execute the generated transfer job. This execution may include iterating through the list data and, for each patient indicated by the list data, communicating a transfer command to multiple data services of the one or more servers. Thus, access to patient data associated with one or more patients indicated by the list data is transferred from the first organization to the second organization. At step 100, the method may include generating transfer job status information regarding the status of the execution for display on a user interface.

[0049] 13 illustrates an exemplary individual patient transfer system 110 for transferring access to patient data associated with a particular patient from one organization (e.g., a therapy provider organization) to another organization (e.g., a therapy provider organization) in accordance with another embodiment of the present technology. Similar to the patient integration tool 10 described above, the individual patient transfer system 110 includes multiple services 112, 114, 116, 118, a database 120, and a user interface 122. The individual patient transfer system 110 described herein, as described in more detail below, is configured to transfer access to patient data for a particular patient. The system components 112, 114, 116, 118, 120, 122 may be implemented in any combination of hardware or software, including software executed by multiple computer systems or servers.

[0050] A user interface 122 is provided by the system, such as by an AVW service on a device or server(s) of the system, for communication between a user (e.g., a data administrator) and the multiple services 112, 114, 116, 118. The user interface 122 serves to collect user-input data necessary for the multiple services 112, 114, 116, 118 to execute a patient transfer for a patient and to transmit system output for viewing by a user. For example, the user interface 122 may be configured to capture user-input data necessary for the multiple services 112, 114, 116, 118 to transfer access to a patient's patient data and to output patient transfer details stored in the database 120. The user interface 122 may be a graphic user interface that facilitates data entry and data presentation. The user interface 122 may include data selectors, such as drop-down list boxes, for quick entry and access.

[0051] The user interface 122 may be implemented as a standalone application on both a web-based platform (online / internet web application) and / or a mobile-based platform (mobile application), and a user may access this user interface over the internet using a computing device that includes a display and input device. Non-limiting examples of computing devices include personal computers (laptop or desktop), mobile phones (smartphones), tablets, personal digital assistants (PDAs), or other similar devices. Typically, a computing device accesses the system directly through an internet service provider (ISP) or indirectly through another network interface.

[0052] 13 , multiple services 112, 114, 116, and 118 facilitate transferring access to a patient's patient data (one at a time) from a current organization to a target (or destination) organization. The multiple services include individual patient transfer (IPT) service 112, patient transfer (PT) service 114, report service 116, and patient note (PN) service 118. The IPT service 112 is operatively connected to and in communication with each of the PT service 114, report service 116, and PN service 118. The IPT service 112 is also operatively connected to and in communication with a user interface 122. Specifically, an API 124 can be utilized to interpret and process requests from the user interface 122 to facilitate communication with the IPT service 112. For example, when a user takes a particular input action (e.g., clicking a button or icon embedded on a web page), the user interface 122 can specify a request to the API 124 for data retrieval (i.e., retrieving transfer patient details), data storage (i.e., storing transfer patient details in the IPT database), and / or the like. The API 124 can then interpret the request, and the API 124 sends a transfer command to the IPT service 112 to perform the specified function. Such input data provided by the user can be captured and sent to the API 24 as a request for, for example, but not limited to, JSON, XML data, and communicated via an appropriate communication protocol, such as HTTP. In the present disclosure, JSON (a data interchange format) is used to format the input data provided by the user.

[0053] Achieving the transfer of access to the patient's patient data from the current organization to the target organization may require several steps. One step may be to query the central database 62 to determine whether a patient record exists based on the device identification designation of the device associated with the patient. Another step may be to transfer access to the patient's patient data from the current organization to the target organization, such as if a patient record exists in the central database 62 as a result of the query.

[0054] To effect the query procedure, as seen in FIG. 14 , a user can enter the serial number and / or device number of the therapy device associated with the patient into serial number field 126 and device number field 128, respectively, embedded in web page 130. In some implementations, this query may require both (serial number and device number) as a basis for validation or error reduction. Additionally, or alternatively, entering a patient name may be required to proceed with the query. The user can then click the “Search” button 132. When the Search button is clicked, the AVW service (which may provide the user interface 122) determines whether the patient's device is currently being used by a patient at another organization by querying the database 62. Thereafter, after confirmation by the search, the Save button 148 shown in FIG. 16 can be activated (e.g., clicked) and the IPT service 112 can be used to activate the transfer. In this regard, after the AVW confirms the presence of the patient device with the AVW service, the API 124 may send a transfer command, including input data (e.g., device identification instructions provided by the user), to the IPT service 112. In the case of a transfer, the user interface 112 may present the user with a screen or page for the user to consent, as appropriate. For example, as seen in FIG. 15, pop-up pages 134, 136 may be presented so that the user can agree to indemnify or hold harmless the system provider in the event of a dispute and confirm the patient to be transferred. Once consent is given by the user, the user interface 122 may redirect the user to a separate patient transfer page 138, which displays the patient information for the user to confirm, as seen in FIG. 16.

[0055] Thus, the second stage of the patient transfer process may be performed using the individual patient transfer page 138. The individual patient transfer page 138 includes two main sections: a patient information section 140 and a user input section 142. As seen in FIGURE 16, the patient information section 140 displays patient information retrieved from the central database 62 during the first stage of the patient transfer process, such as the patient's name, the patient's date of birth, etc.

[0056] The user input section 142 may be configured to capture input data provided by a user, which may include a clinical user of the target organization and a location of the target organization, which may be provided by selecting from a target clinical user listbox 144 and a location of the target organization listbox 146, respectively.

[0057] As described above, after the user provides user input indicating the target organization, the user can click the "Save" button 148 to send the user input to the API to send a transfer command to the IPT service to execute the patient transfer process.

[0058] Thereafter, as described above, the IPT service 112 can perform functions similar to the OMC service 12 of the patient integration tool 10. For example, the IPT service 112 communicates with the PT service 114 by processing the transfer command received from the API 124 and sending it to the PT service 114. The PT service 114 then performs the transfer of access to the patient's patient data from the current organization to the target organization. Thus, the functionality of the PT service 114 can be identical to the functionality of the PXS service 14 of the patient integration tool 10 described above. For example, the PT service 114 can access and retrieve the central database 62 of records related to the patient and update the retrieved records to reflect that the patient is now linked to the target organization. The PT service 114 can then send requests (or instructions) to each of the multiple systems 64, 66, 68, 70 to update records related to the patient to reflect the new patient-organization relationship for the patient. The multiple internal systems may include a PDS billing system 64, a patient list service (PLS) system 66, a Briscoe system 68, and a Sully system 70, which may be the same systems previously described with respect to the operation of the patient integration tool 10. After updating the central database 62 and the multiple systems 64, 66, 68, 70, the PT service 114 may communicate to the IPT service 112 that the patient transfer process is complete by returning transfer details (e.g., patient information, target organization information, etc.) to the IPT service 112. Upon receiving instructions from the IPT service 114, the IPT service 112 accesses an IPT database 120 to save and store the transfer details for retrieval and review by a user via a user interface 122. The IPT database 120 may be comprised of any type of database, such as a relational database, a distributed database, an object database, an object-relational database, or a NoSQL database.

[0059] After the patient transfer process is completed by the PT service 114, the report service 116 may access the central database 62 and retrieve information related to compliance rules and therapies associated with the transferred patient to generate a "Compliance and Therapy" report. The compliance and therapy report may be generated as a readable file, such as a PDF file, and stored by the IPT service 112 in a database, such as a report bucket 150 (shown in FIG. 13 ), for access and viewing by users at the previous organization via the user interface 122.

[0060] Additionally, the PN service 118 may interpret and process requests received from the IPT service 112 and perform the functions necessary to complete the patient transfer process. For example, the PN service 118 may access the central database 62 and store user-entered information (e.g., indemnification and patient transfer confirmation) related to legal consents collected from the user interface 122. The PN service 118 may then generate notes using the consent information collected from the user interface 122 and store the notes in the central database 68 for display on the user interface 122 upon request.

[0061] Once the patient transfer process is complete, the user interface 122 may then redirect the user to a confirmation page 152 containing information related to the transferred patient, as seen in Figure 17. If error(s) occur during the patient transfer process performed by the PT service 114, the report service 116, and / or the PN service 118, the services will stop the patient transfer process and communicate to the IPT service 112 that an error has occurred by returning error details that the user interface 122 may display or otherwise present to the user.

[0062] As illustrated in FIG. 18 , the system may provide a user interface and associated functionality that permits the display of a transfer page 154. Such a user interface display may be generated by the system to allow a user to view transferred patients saved and stored in the IPT database 120. The transfer page 154 may display a list of transferred patients 156, such as with multiple sections or columns displaying information such as the transfer type and the transfer event. For example, the transfer type column 158 indicates whether the patient is transferring in or out. For example, a transfer type of “outbound” indicates that the patient is transferring out of the organization, while a transfer type of “inbound” indicates that the patient is transferring into the organization from another organization. Thus, when a user at the target organization accesses the transfer page 154, patients designated as “outbound” at the source organization are instead designated as “inbound” patients at the target organization. Optionally, the transfer page may further include a user interface control, such as a button, that allows the user to trigger the system to export a copy of the transferred patient list, such as to a file.

[0063] On the transfer page 154, the user interface 122 allows the user to access only the "inbound" patient's profile; therefore, access to the "outbound" patient's profile is denied. However, the transfer page 154 provides functionality by which the user may continue to view compliance and therapy-related information associated with the "outbound" patient. For example, a report link 158 may be clicked to invoke the API 124 and send a request to the IPT service 112. Upon interpreting and processing the request, the IPT service 112 may access the report bucket 150, retrieve reports associated with the "outbound" patient, and display the reports in the user interface 122 for the user to review.

[0064] Thus, the present technology may implement a system that enables streamlined patient data transfer. For example, referring to FIG. 19 , a method 160 of such a system may enable transferring access to patient data from a source organization to a target organization. In the exemplary process of FIG. 19 , at step 162, the method may include generating, by one or more servers, a user interface for transferring access to the patient data. At step 164, the method may include receiving, by the user interface, input data, the input data including a device identification indication for the therapy device. At step 168, the method includes communicating a transfer command to multiple services of the one or more servers based on receiving the device identification indication, thereby transferring access to the patient's patient data from the first organization to the second organization. At step 168, the method includes generating an indication of the access transfer for display in the user interface.

[0065] 20 is a block diagram of an illustrative example of a general computing system 1200. The systems of the technology disclosed herein may be implemented using a computing system. Furthermore, the computing system 1200 may include a set of executable instructions to cause the computing system 1200 to perform the methods disclosed herein. The computing system 1200 may operate as a standalone device or may be connected to other computing systems or peripheral devices, for example, using a network 1224 or other connection.

[0066] 20 , computing system 1200 may include a processor 1202, such as a central processing unit (CPU), a graphics processing unit (GPU), or both. Additionally, computing system 1200 may include a main memory 1204 and a static memory 1206, which may communicate with each other via a bus 1226. As shown, computing system 1200 may also include a video display unit 1210, such as a liquid crystal display (LCD), an organic light-emitting diode (OLED), a flat-panel display, a solid-state display, or a cathode ray tube (CRT). Additionally, computing system 1200 may include an input device 1212, such as a keyboard, and a cursor control device 1214, such as a mouse. Computing system 1200 may also include a disk drive unit 1216, a signal-generating device 1222, such as a speaker or remote control, and a network interface device 1208.

[0067] 12, disk drive unit 1216 may include machine-readable or computer-readable media 1218 on which one or more sets of instructions 1220, e.g., software, may be embedded, encoded, or stored. Furthermore, instructions 1220 may embody one or more of the methods or logic described herein. In particular embodiments or aspects, instructions 1220 may reside, completely or at least partially, within main memory 1204, static memory 1206, and / or processor 1202 during execution by computing system 1200. Main memory 1204 and processor 1202 may further comprise computer-readable media.

[0068] According to various embodiments or aspects, the methods described herein may be implemented by a software program tangibly embodied in a processor-readable medium and executed by a processor. Further, in exemplary, non-limiting embodiments or aspects, implementations may include distributed processing, component / object distributed processing, and parallel processing. Alternatively, a virtual computing system process may be constructed to implement one or more of the methods or functions described herein. Treatment Device of Any Embodiment

[0069] As previously mentioned, patient data managed by the above-described access transfer system may include data regarding the use and / or operation of home medical equipment or respiratory therapy devices, examples of which may be considered in connection with examples discussed in more detail in the following sections.

[0070] In one form, such a device may treat and / or monitor respiratory disorders. One such device may be a respiratory therapy device (RT), such as the RPT 4000, which supplies a flow of pressurized air to the patient 1000 via an air circuit 4175 connected to the patient interface 3000. The air flow may be pressure-controlled (for respiratory pressure therapy) or flow-controlled (for flow therapy, such as high flow therapy HFT). Thus, an RPT device may also be configured to function as a flow therapy device, such as when using a patient interface that does not employ a seal that seals with the patient's respiratory system. In the following description, an RT or RPT device may be considered with reference to FIGS. 21A-24. 4.2 Patient Interface

[0071] 22 , a non-invasive patient interface 3000 in accordance with one aspect of the present technology may include any of the following functional aspects as needed: a seal-forming structure 3100, a plenum chamber 3200, a positioning and stabilizing structure 3300, a ventilation port 3400, a connection port 3600 for connecting to an air circuit 4170, and a forehead support 3700. In some forms, the functional aspects may be provided by one or more physical components. In some forms, a single physical component may provide one or more functional aspects. In use, the seal-forming structure 3100 is positioned to surround an entrance to the patient's airways to facilitate the delivery of pressurized air to the airways. 4.3 RPT device

[0072] In accordance with one embodiment of the present technology, an RPT device 4000 includes mechanical and pneumatic components 4100, electrical components 4200, and is programmed to execute one or more algorithms 4300. The RPT device 4000 may have an outer housing 4010 formed in two parts: an upper portion 4012 and a lower portion 4014. In one form, the outer housing 4010 may include one or more panel(s) 4015. The RPT device 4000 may include a chassis 4016 that supports one or more internal components of the RPT device 4000. The RPT device 4000 may include a handle 4018.

[0073] The air pressure path of the RPT device 4000 may include one or more air path items, such as an inlet air filter 4112, an inlet muffler 4122, a pressure generator 4140 (e.g., a blower 4142) capable of supplying pressurized air, an outlet muffler 4124, and one or more transducers 4270, such as a pressure sensor 4272 and a flow sensor 4274.

[0074] One or more air path articles can be arranged in a movable, unitary structure called a pneumatic block 4020. The pneumatic block 4020 can be located within the outer housing 4010. In one form, the pneumatic block 4020 is supported by or formed as part of the chassis 4016.

[0075] The RPT device 4000 may include a power supply 4210, one or more input devices 4220, a central controller 4230, a therapy device controller 4240, a pressure generator 4140, one or more protection circuits 4250, a memory 4260, a transducer 4270, a data communication interface 4280, and one or more output devices 4290. The electrical components 4200 may be mounted on a single printed circuit board assembly (PCBA) 4202. In the alternative, the RPT device 4000 may include two or more PCBAs 4202. 4.3.1 Mechanical and Pneumatic Components of RPT Devices

[0076] The RPT device 4000 may include one or more of the following components in an overall unit: In the alternative, one or more of the following components may be arranged as separate units. 4.3.1.1 Air filter(s)

[0077] An RPT device 4000 in accordance with one form of the present technology may include an air filter 4110 or multiple air filters 4110.

[0078] In one form, the air inlet filter 4112 is located at the beginning of the air pressure path upstream of the pressure generator 4140 .

[0079] In one form, an air outlet filter 4114, for example an antibacterial filter, is located between the outlet of the pneumatic block 4020 and the patient interface 3000. 4.3.1.2 Muffler(s)

[0080] An RPT device 4000 in accordance with one form of the present technology may include a muffler 4120 or multiple mufflers 4120.

[0081] In one form of the present technology, an inlet muffler 4122 is placed in the pneumatic path upstream of a pressure generator 4140 .

[0082] In one form of the present technology, the outlet muffler 4124 is placed in the pneumatic path between the pressure generator 4140 and the patient interface 3000. 4.3.1.3 Pressure generator

[0083] In one form of the present technology, pressure generator 4140 for supplying compressed air is a controllable blower 4142. For example, blower 4142 may include a brushless DC motor 4144 having one or more impellers housed within a helical structure. Pressure generator 4140 may be capable of producing, for example, a supply or flow of about 120 liters / minute of air at a positive pressure ranging from about 4 cmH2O to about 20 cmH2O, or in other forms up to about 30 cmH2O.

[0084] The pressure generator 4140 is under the control of the therapy device controller 4240 .

[0085] In other forms, pressure generator 4140 can be a piston-driven pump, a pressure regulator connected to a high pressure source (eg, a compressed air container), or a bellows. 4.3.1.4 Transducer(s)

[0086] The transducer may be internal to the RPT device or external to the RPT device. An external transducer may be located on or form part of the air circuit, for example, a patient interface. An external transducer may be in the form of a non-contact sensor, such as a Doppler radar motion sensor, that transmits or transfers data to the RPT device.

[0087] In one form of the present technology, one or more sensors 4270 are positioned upstream and / or downstream of the pressure generator 4140. The one or more transducers 4270 are constructed and positioned to generate data indicative of a corresponding attribute of the airflow, such as flow rate, pressure, or temperature, at that point in the airflow.

[0088] In one form of the present technology, one or more sensors 4270 are positioned proximate the patient interface 3000.

[0089] In one form, the signal from the transducer 4270 may be filtered, for example, by low pass, high pass, or band pass. 4.3.1.5 Check valve

[0090] In one form of the present technology, a non-return valve 4160 is located between the humidifier 5000 and the pneumatic block 4020. The non-return valve is constructed and arranged to reduce the risk of water flowing upstream from the humidifier 5000, for example to the motor 4144. 4.3.1.6 Air Circuit

[0091] The air circuit 4170 according to one aspect of the present technology is a conduit or tube constructed and arranged to allow air flow to travel between two components, such as the pneumatic block 4020 and the patient interface 3000, in use. 4.3.1.7 Oxygen delivery

[0092] In one form of the present technology, supplemental oxygen 4180 is delivered to the air circuit 4170 and / or patient interface 3000 at one or more points in the pneumatic pathway, such as upstream of the pneumatic block 4020. 4.3.2 Electrical Components of the RPT Device 4.3.2.1 Power supply

[0093] In one form of the present technology, the power supply 4210 is located inside the outer housing 4010 of the RPT device 4000. In another form of the present technology, the power supply 4210 is located outside the outer housing 4010 of the RPT device 4000.

[0094] In one form of the present technology, the power supply 4210 powers only the RPT device 4000. In another form of the present technology, the power supply 4210 powers both the RPT device 4000 and the humidifier 5000. 4.3.2.2 Input Devices

[0095] In one form of the present technology, the RPT device 4000 includes one or more input devices 4220 in the form of buttons, switches, or dials that allow a person to interact with the device. The buttons, switches, or dials may be physical devices or software devices accessible via a touchscreen. The buttons, switches, or dials may in one form be physically connected to the external housing 4010, or in another form may communicate wirelessly with a receiver electrically connected to the central controller 4230.

[0096] In one form, input device 4220 may be constructed and arranged to allow a human to select values ​​and / or menu options. 4.3.2.3 Central Controller

[0097] In one form of the present technology, the central controller 4230 is a processor suitable for controlling the RPT device 4000, such as an x86 INTEL processor.

[0098] A central controller 4230 suitable for controlling an RPT device 4000 in accordance with another form of the present technology includes a processor based on an ARM Cortex™ M processor from ARM Holdings, Inc. For example, an STM32 series microcontroller from ST MICROELECTRONICS, Inc. may be used.

[0099] In accordance with another alternative form of the present technology, another central controller 4230 suitable for controlling the RPT device 4000 includes a member selected from the ARM9-based 32-bit RISC CPU series. For example, the STR9 series microcontroller from ST MICROELECTRONICS may be used.

[0100] In one particular alternative of the present technology, a 16-bit RISC CPU may be used as the central controller 4230 of the RPT device 4000. For example, a processor from the MSP430 series of microcontrollers manufactured by Texas Instruments may be used.

[0101] In another form of the present technology, the central controller 4230 is a dedicated electronic circuit. In another form, the central controller 4230 is an application specific integrated circuit (ASIC). In another form, the central controller 4230 includes separate electronic components.

[0102] The central controller 4230 is configured to receive input signal(s) from one or more transducers 4270, one or more input devices 4220, and the humidifier 5000.

[0103] The central controller 4230 is configured to provide output signal(s) to one or more of the output device 4290, the therapy device controller 4240, the data communication interface 4280, and the humidifier 5000.

[0104] In some forms of the present technology, the central controller 4230 is configured to implement one or more methodologies described herein, e.g., one or more algorithms 4300, represented as a computer program stored in a non-transitory computer-readable storage medium, such as the memory 4260 or other memory described herein. In some forms of the present technology, the central controller 4230 may be integrated with the RPT device 4000, as described above. However, in some forms of the present technology, some methods may be performed by a remote device or server, such as the server described above. For example, a remotely located device or server may determine control settings to send to a ventilator or other RT device, e.g., by detecting breath-related events and identifying them by type by analyzing stored data, such as from any of the sensors described herein.

[0105] Although the central controller 4230 may include a single controller that interacts with the various sensors 4270, data communication interface 4280, memory 4260, and other devices, the functions of the controller 4230 may be distributed across multiple controllers. Thus, the term "central" as used herein is not meant to limit the architecture to a single controller or processor controlling other devices. For example, alternative architectures may include a distributed controller architecture with two or more controllers or processors, which may, as needed, electronically (wired or wirelessly) communicate directly or indirectly with the previously mentioned finger sensors or a server that communicates with the finger sensors, such as to implement any of the methods described herein. This may include, for example, a separate local (i.e., within the RPT device 4000) or remote controller that executes several algorithms 4300, or two or more local or remote memories that store several algorithms. Furthermore, when expressed as a computer program, the algorithms may include high-level, human-readable code (e.g., C++, Visual Basic, other object-oriented languages, etc.) or low-level / machine-level instructions (e.g., assembler, Verilog, etc.). Depending on the function of the algorithm(s), such code or instructions may be written into a controller, such as an ASIC or DSP, or may be a run-time executable ported to a DSP or general-purpose processor, specially programmed to perform the tasks required by the algorithm(s). 4.3.2.4 Clock

[0106] The RPT device 4000 may include a clock 4232 connected to the central controller 4230 . 4.3.2.5 Therapy Device Controller

[0107] In one form of the present technology, the therapy device controller 4240 is a therapy control module 4330 that forms part of the algorithm 4300 executed by the central controller 4230.

[0108] In one form of the present technology, the therapy device controller 4240 is a dedicated motor control integrated circuit. For example, in one form, the MC33035 brushless DC motor controller manufactured by ONSEMI is used. 4.3.2.6 Protection circuit

[0109] An RPT device 4000 in accordance with the present technology may include one or more protection circuits 4250.

[0110] One form of the protection circuit 4250 according to the present technology is an electrical protection circuit.

[0111] One form of protection circuit 4250 in accordance with the present technology is a temperature or pressure safety circuit. 4.3.2.7 Memory

[0112] In accordance with one form of the present technology, the RPT device 4000 includes memory 4260, such as non-volatile memory. In some forms, the memory 4260 may include battery-powered static RAM. In some forms, the memory 4260 may include volatile RAM.

[0113] Memory 4260 may reside on PCBA 4202. Memory 4260 may be in the form of EEPROM or NAND flash memory.

[0114] Additionally or alternatively, the RPT device 4000 includes a removable form of memory 4260, for example a memory card made in accordance with the Secure Digital (SD) standard.

[0115] In one form of the present technology, memory 4260, such as any of the memories described above, functions as a non-transitory computer-readable storage medium on which are stored computer program instructions representing one or more methodologies described herein, such as one or more algorithms 4300. 4.3.2.8 Transducers

[0116] The transducer may be internal to the RPT device 4000 or external to the RPT device 4000. The external transducer may be located, for example, on the air delivery circuit 4170, for example, at the patient interface 3000, or may form part of the air delivery circuit 4170. The external transducer may be in the form of a non-contact sensor, such as a Doppler radar motion sensor, that transmits or forwards data to the RPT device 4000. 4.3.2.8.1 Flow rate

[0117] The flow transducer 4274 according to the present technology can be based on a differential pressure transducer, such as the SDP600 series differential pressure transducer from SENSIRION, Inc. The differential pressure transducer is in fluid communication with the pneumatic circuit, one of the pressure transducers being connected to a respective first point and second point of the flow restricting element.

[0118] In one example, the central controller 4230 receives a signal representing the total flow Qt from the flow sensor 4274. 4.3.2.8.2 Pressure

[0119] The pressure transducer 4272 according to the present technology is positioned in fluid communication with the pneumatic path. One example of a suitable pressure transducer 4272 is a HONEYWELL ASDX series sensor. An alternative suitable pressure transducer is GE's NPA series sensor.

[0120] In use, the signal from the pressure transducer 4272 is received by the central controller 4230. In one form, the signal from the pressure transducer 4272 is filtered before being received by the central controller 4230. 4.3.2.8.3 Motor Speed

[0121] In one form of the present technology, a motor speed sensor 4276 is used to determine the rotational speed of the motor 4144 and / or blower 4142. A motor speed signal from the motor speed transducer 4276 may be provided to the therapy device controller 4240. The motor speed transducer 4276 may be, for example, a speed sensor such as a Hall effect sensor. 4.3.2.9 Data communication systems

[0122] In one form of the present technology, a data communications interface 4280 is provided and connected to a central controller 4230. The data communications interface 4280 may be connected to a remote external communications network 4282 and / or a local external communications network 4284. The remote external communications network 4282 may be connected to a remote external device 4286. The local external communications network 4284 may be connectable to a local external device 4288.

[0123] In one form, the data communication interface 4280 is part of the central controller 4230. In another form, the data communication interface 4280 is separate from the central controller 4230 and may include an integrated circuit or processor.

[0124] In one form, the remote external communications network 4282 is the Internet. The data communications interface 4280 may be connected to the Internet using wired communications (e.g., via Ethernet or fiber optics) or wireless protocols (e.g., CDMA, GSM, LTE).

[0125] In one form, the local external communications network 4284 utilizes one or more communications standards, such as Bluetooth or consumer infrared protocol, and can communicate with any of the sensors described herein, as needed.

[0126] In one form, the remote external device 4286 is one or more computers, such as a cluster of computers and / or servers connected to a network, as described herein. In one form, the remote external device 4286 may be a virtual computer rather than a physical computer. In either case, such a remote external device 4286 may be available to appropriately authorized personnel, such as a clinician.

[0127] The local external device 4288 may be a personal computer, a mobile phone, a tablet, or a remote control. 4.3.2.10 Output Devices (including displays and alarms, as appropriate)

[0128] The output device 4290 according to the present technology can take the form of one or more of a visual, auditory and tactile unit. The visual display can be a liquid crystal display (LCD) or a light emitting diode (LED) display. 4.3.2.10.1 Display Driver

[0129] The display driver 4292 receives as input characters, symbols or images intended to be displayed on the display 4294 and converts them into commands that cause the display 4294 to display them. 4.3.2.10.2 Display

[0130] Display 4294 is configured to visually display characters, symbols, or images in response to commands received from display driver 4292. For example, display 4294 may be an eight-segment display, in which case display driver 4292 converts each character or symbol (e.g., the digit "0") into eight logic signals that indicate whether each of the eight segments is activated to display the particular character or symbol. 4.3.3 RPT Device Algorithm 4.3.3.1 Preprocessing Module

[0131] The pre-processing module 4310 of the present technology receives raw data as input from a transducer 4270 (e.g., a flow sensor 4274 or a pressure sensor 4272) and performs one or more processing steps to calculate one or more output values ​​that are used as input to other modules (e.g., a therapy engine module 4320).

[0132] In one form of the present technology, the output values ​​include interface or mask pressure Pm, respiratory flow Qr, and leak flow Ql.

[0133] In various forms of the present technology, the pre-processing module 4310 comprises one or more of the following algorithms: pressure compensation 4312, ventilation flow estimation 4314, leak flow estimation 4316, respiratory flow estimation 4317, ventilation determination 4311, target ventilation determination 4313, respiratory rate estimation 4318, and backup rate determination 4319. 4.3.3.1.1 Pressure compensation

[0134] In one form of the present technology, a pressure compensation algorithm 4312 receives as an input a signal indicative of the pressure in the pneumatic path near the outlet of the pneumatic block 4020. The pressure compensation algorithm 4312 then estimates the pressure drop in the pneumatic circuit 4170 at the patient interface 3000 and provides as an output the estimated pressure Pm. 4.3.3.1.2 Ventilation flow estimation

[0135] In one form of the present technology, a ventilation flow estimation algorithm 4314 receives as input an estimated pressure Pm in the patient interface 3000 and estimates the ventilation flow Qv of air out of the ventilation ports 3400 in the patient interface 3000. 4.3.3.1.3 Leakage flow rate estimation

[0136] In one form of the present technology, a leak flow estimation algorithm 4316 receives as input the total flow Qt and the ventilation flow Qv and estimates the leak flow Ql. In one form, the leak flow estimation algorithm 4316 estimates the leak flow Ql by calculating the average value of the difference between the total flow and the ventilation flow Qv over a period of time long enough to include several respiratory cycles, for example 10 seconds.

[0137] In one form, the leak flow estimation algorithm 4316 receives as input the total flow Qt, the ventilation flow Qv, and the estimated pressure Pm within the patient interface 3000, calculates the leak conductance, and estimates the leak flow Ql by determining the leak flow Ql as a function of the leak conductance and the pressure Pm. The leak conductance is calculated as the quotient of the low-pass filtered non-ventilation flow equal to the difference between the total flow Qt and the ventilation flow Qv, and the low-pass filtered square root of the pressure Pm, where the low-pass filter time constant has a value long enough to include several respiratory cycles, e.g., about 10 seconds. The leak flow Ql can be estimated as a function of the product of the leak conductance and the pressure Pm. 4.3.3.1.4 Respiratory flow estimation algorithm

[0138] In one form of the present technology, the respiratory flow estimation algorithm 4317 receives as inputs the total flow Qt, the ventilation flow Qv, and the leak flow Ql, and estimates the respiratory flow Qr of air to the patient by subtracting the ventilation flow Qv and the leak flow Ql from the total flow Qt.

[0139] In another form of the present technology, the respiratory flow estimation algorithm 4317 provides a value as a surrogate for respiratory flow Qr. Possible surrogates for respiratory flow include: - 1000 respiratory movements of the patient's chest, - the current drawn by the pressure generator 4140; - motor speed of pressure generator 4140, -Patient transthoracic impedance 1000 is included.

[0140] A proxy value for respiratory flow may be provided by a transducer 4270 within the RPT device 4000, such as a motor speed sensor 4276, or by a sensor external to the RPT device 4000, such as a respiratory motion sensor or a transthoracic impedance sensor. 4.3.3.1.5 Ventilation Determination Algorithm

[0141] In one form of the present technology, a ventilation determination algorithm 4311 receives as input the respiratory flow Qr and determines a measured Vent that is indicative of the current patient ventilation.

[0142] In some implementations, the ventilation determination algorithm 4311 determines an actual value of ventilation Vent that is an estimate of the actual patient ventilation.

[0143] In one such implementation, the measured value of ventilation Vent is half the absolute respiratory flow Qr and is optionally filtered by a low-pass filter, such as a second-order Bessel low-pass filter with a corner frequency of 0.11 Hz.

[0144] In one such implementation, the measurement of ventilation Vent is an estimate of total alveolar ventilation (i.e., non-anatomic dead-space ventilation), which requires an estimation of anatomical dead-space. Patient height (or arm span in cases of severe skeletal deformities) can be used as a good predictor of anatomical dead-space. Total alveolar ventilation is equal to the actual measured value of the actual patient ventilation, e.g., as determined above, minus the product of the estimated anatomical dead-space and the estimated spontaneous breathing rate Rs.

[0145] In other embodiments, the ventilation volume determination algorithm 4311 determines a measured value of the ventilation volume vent that is approximately proportional to the actual patient ventilation. In such an embodiment, the peak respiratory flow rate Qpeak is estimated over the inspiratory portion of the cycle. This procedure, along with many other procedures involving sampling of the respiratory flow rate Qr, results in a measured value that is approximately proportional to the ventilation, provided that the shape of the flow waveform does not change much (here, two breaths are considered to have a similar shape if the respiratory flow waveforms, normalized by time and amplitude, are similar). Simple examples include the median of the positive respiratory flow rates, the median of the absolute values of the respiratory flow rates, and the standard deviation of the flow rates. Any linear combination of any order statistics of the absolute values of the respiratory flow rates using positive coefficients, and in some cases, using both positive and negative coefficients, is approximately proportional to the ventilation volume. Another example is the average value of the respiratory flow velocity at the intermediate KK ratio (time) of the inspiratory portion, where 0 < K < 1. If the shape of the flow velocity waveform does not change, there are any number of measured values that are exactly proportional to the ventilation volume.

[0146] In other forms, the ventilation volume determination algorithm 4311 does not rely on the ventilation flow rate Qr, but rather determines a measured value Vent of the current patient ventilation, which serves as a proxy for the ventilation, obtained from a suitable sensor attached to the patient 1000, such as the oxygen saturation (SaO2) or the partial pressure of carbon dioxide (PCO2). 4.3.3.1.6 Target Ventilation Volume Determination

[0147] In one form of the present technology, the central controller 4230 takes the measured value vent of the current ventilation as an input and executes one or more target ventilation volume determination algorithms 4313 to determine the target value Vtgt of the ventilation measurement.

[0148] In some forms of the present technology, the target ventilation volume determination algorithm 4313 does not exist, and the target ventilation volume Vtgt is predetermined, for example, by hard-coding it into the configuration of the RPT device 4000 or by manually inputting it via the input device 4220.

[0149] In other forms of the present technology, for example adaptive servo ventilation (ASV) therapy (described below), the target ventilation determination algorithm 4313 calculates the target ventilation Vtgt from a value Vtyp indicative of the patient's 1000 typical recent ventilation.

[0150] In some forms of adaptive servo ventilation, the target ventilation Vtgt is calculated as a high percentage of the typical recent ventilation Vtyp, although this percentage may be less than 80%, 100%, or 85%, 95%, or 87%, 92%.

[0151] In other forms of adaptive servo-ventilation, the target ventilation Vtgt is calculated as a unit multiple slightly greater than the typical recent ventilation Vtyp.

[0152] The typical recent ventilation Vtyp is the value around which the distribution of actual values ​​of the current ventilation Vent over multiple time instants on a given time scale tends to converge, i.e., the actual central tendency of actual current ventilation Vent over recent history. In one implementation of the target ventilation determination algorithm 4313, the recent history is on the order of several minutes, but in any case must be longer than the time scale of a Cheyne-Stokes rise-fall cycle. The target ventilation determination algorithm 4313 can use any of a variety of known central tendency measures to determine the typical recent ventilation Vtyp from the actual current ventilation Vent. One such measure is the output of a low-pass filter on the current ventilation Vent measurement, with a time constant equal to 100 seconds. 4.3.3.1.7 Respiratory rate estimation

[0153] In one form of the present technology, a respiratory rate estimation algorithm 4318 receives as input the patient's 1000 respiratory flow Qr and generates an estimate of the patient's spontaneous respiratory flow Rs.

[0154] The respiratory rate estimation algorithm 4318 can estimate the spontaneous respiratory rate Rs when the patient 1000 is breathing spontaneously, i.e., when the RPT device 4000 is not delivering a "spare breath" (described below). In some forms of the present technology, the respiratory rate estimation algorithm 4318 estimates the respiratory rate over periods of less than 4 cmH2O, in certain embodiments, when servo assist (defined as pressure support minus minimum pressure support) is low, as such periods are more likely to reflect spontaneous respiratory effort.

[0155] In some forms of the present technology, the respiration rate estimation algorithm 4318 estimates respiratory flow during sleep breathing, since the respiratory rate during these periods can be substantially different from the respiratory flow during wakefulness. Anxiety typically causes a higher respiratory rate than during sleep. While a patient is concentrating on their breathing process, the respiratory rate typically is lower than the normal awake or sleep respiratory rate. Patent Application No. PCT / AU2010 / 000894, disclosed as WO2011 / 006199, is incorporated herein by reference and can be used to identify periods of wakefulness breathing from the respiratory flow Qr.

[0156] In some forms of the present technology, the respiration rate estimation algorithm 4318 estimates the spontaneous breathing rate Rs as the reciprocal of one of various well-known statistical measures of central tendency for the breath duration Ttot over the time period of interest. It is desirable for such measures to reject, or at least be robust to, outliers. One such measure, the trimmed mean, discards a percentage of the lowest and highest K sorted breath durations and calculates the mean for the remaining breath durations, making it robust to outliers. For example, if K is 0.25, this corresponds to discarding the upper and lower quartiles of the breath duration Ttot. The median is another reliable measure of central tendency, but may not produce satisfactory results when the distribution is strongly bimodal. The simple mean, while sensitive to outliers, can also be used as a measure of central tendency. An initial interval filtering phase may be used in which consecutive time intervals corresponding to impossible breath rates (e.g., greater than 45 breaths / min or less than 6 breaths / min) are excluded from the mean calculation as outliers. Another filtering mechanism that can be used alone or in combination with interval filtering is to exclude any breaths that do not belong to a sequence of N consecutive spontaneous breaths, where N is some small integer (e.g., 3), and to exclude early and late breaths in a sequence of four consecutive spontaneous breaths, e.g., the first and last breaths in a sequence of four breaths. The rationale for this latter mechanism is that the first and last breaths in a series of spontaneous breaths, and generally the early and late breaths, may be abnormal. For example, the first spontaneous breath may be the result of arousal, while the last spontaneous breath may be longer due to reduced respiratory drive and a preparatory breath terminating the spontaneous breath sequence.

[0157] In some forms of the present technology, the respiration rate estimation algorithm 4318 makes an initial estimate of the spontaneous breathing rate Rs using an initial estimation period to allow subsequent processing in the therapy engine module 4320 to begin, and then continuously updates the estimate of the spontaneous breathing rate Rs using longer estimation periods to improve statistical robustness. For example, the estimated initial period may be 20 minutes of moderate spontaneous breathing, but the estimated period may then be gradually increased to some maximum duration, such as 8 hours. Rather than using a rolling window of this duration, the estimation may use a low-pass filter of the breathing duration with a gradually longer response time (or, more precisely, a gradually lower corner frequency) as the session progresses.

[0158] In some forms, suitably processed short-term (e.g., 10 minute) observations of central tendency, such as trimmed means, may be input into a suitable low pass filter to provide an estimated Rs that varies over the hourly or longer time scale. The advantage is that it is not necessary to store and process vast amounts of breath duration data, as may occur if a trimmed mean needs to be calculated over a moving window of breath duration data spanning hours or days.

[0159] In some forms of the present technology, respiratory rate measured over a short period of time, particularly within a single breath, may be used in place of respiratory duration in the central tendency measurements described above, and may give substantially similar but different results. 4.3.3.2 Therapy Engine Module

[0160] In one form of the present technology, the therapy engine module 4320 receives as inputs one or more of the pressure Pm in the patient interface 3000, the patient's airflow Qr, and an estimate of the intrinsic breathing rate Rs, and provides one or more therapy parameters as outputs. In various forms, the therapy engine module 4320 includes one or more of the following algorithms: phase determination 4321, waveform determination 4322, inspiratory flow limitation determination 4324, apnea / hypopnea determination 4325, snoring detection 4326, airway patency determination 4327, and therapy parameter determination 4329. 4.3.3.2.2 Waveform determination

[0161] In one form of the present technology, the therapy control module 4330 controls the pressure generator 4140 to provide a therapy pressure Pt that varies as a function of the phase of the patient's respiratory cycle according to a waveform template. 4.3.3.3 Therapy Control Module

[0162] In accordance with one aspect of the present technology, a therapy control module 4330 receives therapy parameters as input from a therapy parameter determination algorithm 4329 of the therapy engine module 4320 and controls the pressure generator 4140 to deliver airflow in accordance with the therapy parameters.

[0163] In one form of the present technology, the therapy parameter is a therapy pressure Pt, and the therapy control module 4330 controls the pressure generator 4140 to provide a gas flow such that the mask pressure Pm at the patient interface 3000 is equal to the therapy pressure Pt. 4.5 Terminology

[0164] For purposes of this disclosure, in some aspects of the technology, one or more of the following definitions may apply. In other aspects of the technology, alternative definitions may apply. 4.5.1 General

[0165] Air: In certain forms of the present technology, air may refer to atmospheric air, while in other forms of the present technology, air may refer to a combination of other breathable gases (e.g., oxygen-rich atmospheric air).

[0166] Respiratory pressure therapy (RPT): Air is delivered to the entrance of the airways at a positive therapeutic pressure, usually relative to the atmosphere.

[0167] Continuous Positive Airway Pressure (CPAP) Therapy: Respiratory pressure therapy in which the therapeutic pressure is nearly constant throughout the patient's respiratory cycle. In some forms, the pressure at the entrance to the airways increases slightly during exhalation and decreases slightly during inhalation. In some forms, the pressure varies during different respiratory cycles of the patient (e.g., increasing in response to the detection of signs of partial upper airway obstruction and decreasing when no indication of partial upper airway obstruction is present).

[0168] Patient: A person (whether or not suffering from a respiratory illness) Automatic Positive Airway Pressure (APAP) Therapy: A CPAP therapy that can automatically adjust therapeutic pressure between minimum and maximum limits, for example, between breaths, depending on the presence or absence of signs of an SDB episode. 4.5.2 Aspects of the respiratory cycle

[0169] Apnea: According to some definitions, an apnea is said to have occurred when the flow rate falls below a predetermined threshold for a period of time, e.g., 10 seconds. Obstructive apnea is said to have occurred when some airway obstruction does not allow airflow despite the patient's efforts. Central apnea is said to have occurred when apnea is detected due to reduced or absent respiratory effort despite a patent airway.

[0170] Respiratory rate or respiratory rate (Rs): The rate at which a patient spontaneously breathes, usually measured in breaths per minute.

[0171] Duty cycle: The ratio of inspiration time Ti to total breathing time Ttot.

[0172] Exertion (breathing): The effort of a spontaneously breathing person to breathe.

[0173] Expiratory portion of the respiratory cycle: the period from the start of expiratory flow to the start of inspiratory flow.

[0174] Flow limitation: This is considered a condition in a patient's breathing where an increase in patient effort does not result in a corresponding increase in flow rate. If flow limitation occurs during the inspiratory portion of the respiratory cycle, the flow limitation can be referred to as inspiratory flow limitation. If flow limitation occurs during the expiratory portion of the respiratory cycle, the flow limitation can be referred to as expiratory flow limitation.

[0175] Hypopnea: Flow is reduced but does not cease. In one form, hypopnea is said to have occurred if flow is reduced below a threshold rate for a sustained period. In one form in adults, hypopnea can be considered if any of the following occur:

[0176] (i) A 30% decrease in patient breathing for at least 10 seconds and an associated 4% desaturation; or (ii) A decrease in patient breathing (but less than 50%) for at least 10 seconds and an associated desaturation or arousal of at least 3%.

[0177] Inspiratory portion of the respiratory cycle: The period from the start of the inspiratory flow to the start of the expiratory flow is taken as the inspiratory portion of the respiratory cycle.

[0178] Patency (Airway): The degree to which the airway is open, or the extent to which the airway is open. The patient's airway is open. Airway patency may be quantified, for example, with a value of 1 for an open state and a value of zero (0) for a closed (occluded) state.

[0179] Positive end-expiratory pressure (PEEP): The pressure in the lungs above atmosphere that exists at the end of expiration.

[0180] Peak flow (Q peak): The maximum value of flow during the inspiratory portion of the respiratory flow waveform.

[0181] Respiratory flow / airflow, patient airflow / airflow (Qr): These synonyms may be understood to refer to the estimate of respiratory flow by an RPT device, as distinct from "true respiratory flow" or "true respiratory airflow," which are the actual respiratory flows experienced by the patient, usually expressed in liters per minute.

[0182] Tidal Volume (Vt): The volume of air inhaled or exhaled during normal breathing in the absence of extraneous exertion.

[0183] (Inspiration) Time (Ti): The duration of the inspiratory portion of the respiratory flow waveform.

[0184] (Expiratory) Time (Te): The duration of the expiratory portion of the respiratory flow waveform.

[0185] (Total) Time (Ttot): The total duration between the start of one inspiratory portion of the respiratory flow waveform and the start of the next inspiratory portion of the respiratory flow waveform.

[0186] Upper Airway Obstruction (UAO): Includes both partial and total upper airway obstruction. This can be associated with a state of flow limitation in which flow increases slightly or may even decrease as the pressure difference across the upper airway increases (Starling resistance behavior).

[0187] Vent: An actual measurement of the total amount of gas exchange taking place by a patient's respiratory system. Measurements of ventilation may include either or both inspiratory and expiratory flow per unit of time. When expressed as volume per minute, this amount is often referred to as "minute ventilation." Minute ventilation is sometimes simply expressed as volume and is understood as volume per minute. 4.5.3 RPT Device Parameters

[0188] Flow: The instantaneous volume (or mass) of air delivered per unit time. Flow and ventilation have the same volume or mass dimensions per unit time, but flow is measured over a shorter period of time. Flow may be nominally positive for the inspiratory portion of the patient's respiratory cycle, and therefore negative for the expiratory portion of the patient's respiratory cycle. In some cases, reference to flow refers to a scalar quantity (i.e., a quantity with magnitude only). In other cases, reference to flow refers to a vector quantity (i.e., a quantity with both magnitude and direction). The symbol Q is followed by the flow rate. "Flow" is sometimes simply referred to as "flow." Total flow rate Qt is the flow rate of air exiting the RPT device. Ventilation flow rate Qv is the flow rate of air exiting the ventilation port to expel exhaled gases. Leak flow rate Ql is the flow rate of accidental leakage from the patient interface system. Respiratory flow rate Qr is the flow rate of air entering the patient's respiratory system.

[0189] Leak: The term "leak" is taken to mean an unintended flow of air. In one example, a leak can occur as a result of an imperfect seal between the mask and the patient's face. In another example, a leak can occur at the elbow to the circumference.

[0190] Pressure: Force per unit area. Pressure can be expressed in a range of units including cmH2O, g?f / cm2, and hectopascals. 1 cmH2O is 1 g?f / cm2, or approximately 0.98 hectopascals. Unless otherwise stated, pressure is given in cmH2O herein. Pressure at the patient interface is labeled Pm, and treatment pressure is labeled Pt, which indicates the target value that the mask pressure Pm should currently achieve. 4.5.4 Ventilator terminology

[0191] Adaptive Servo Ventilator (ASV): A servo ventilator that has a variable, rather than fixed, target ventilation that can learn from some characteristics of the patient, such as the patient's breathing characteristics.

[0192] Backup Rate: A ventilator parameter that sets the minimum number of breaths (typically breaths per minute) that the ventilator will deliver to the patient if not triggered by spontaneous breathing effort.

[0193] Cycled: The end of the inspiratory phase of a ventilator. When a ventilator delivers breaths to a spontaneously breathing patient, at the end of the inspiratory portion of the breathing cycle, the ventilator is said to be cycled because it stops delivering breaths.

[0194] Expiratory Positive Airway Pressure (EPAP): The base pressure to which varying pressures are applied within a breath to produce the desired interface pressure that the ventilator attempts to achieve at a given time.

[0195] Positive End-Expiratory Pressure (EEP): The desired interface pressure that the ventilator attempts to achieve at the end of the expiratory portion of exhalation.

[0196] IPAP: The maximum desired interface pressure that the ventilator attempts to achieve during the inspiratory portion of the breath.

[0197] Pressure Support: A measure of the increase in ventilator pressure during inspiration over that during expiration, generally referring to the difference in pressure between peak and base pressure during inspiration (e.g., PS = IPAP - EPAP). In some situations, pressure support refers to the difference the ventilator attempts to achieve, rather than the difference it actually achieves.

[0198] Servo-ventilator: a ventilator that measures patient ventilation, has a target ventilation, and adjusts the level of pressure support to move patient ventilation toward the target ventilation.

[0199] Servo Assist: Subtract the minimum pressure support from the pressure support.

[0200] Spontaneous / Timed (S / T): A pattern in which a ventilator or other device attempts to detect the onset of a breath in a spontaneously breathing patient. However, if the device fails to detect a breath within a predetermined period, the device automatically initiates breath delivery.

[0201] Swing: A term equivalent to pressure support.

[0202] Triggered: A ventilator is said to do so when it delivers breathing air to a spontaneously breathing patient and is triggered at the start of the respiratory portion of the breathing cycle by patient exertion.

[0203] Typical Recent Ventilation: The typical recent ventilation Vtyp is the value around which recent ventilation measurements over a given time scale tend to cluster, i.e., a measure of the central tendency of ventilation measurements over recent history.

[0204] Ventilator: A mechanical device that provides pressure support while a patient performs some or all of the breathing process.

[0205] Other notes A portion of the disclosure of this patent document contains material that is entitled to copyright protection. The copyright owner has no objection to the copying by anyone of this patent document or the patent disclosure for purposes of disclosure in the Patent and Trademark Office patent file or records, but reserves all copyright rights therefor for all other purposes.

[0206] Unless otherwise clearly indicated from the context and unless a range of values ​​is provided, it is understood that each intervening value, to the tenth of the unit of the lower limit, between the upper and lower limits of the range, and for any other stated or intervening value in the stated range, is encompassed by the technology. The upper and lower limits of these intervening ranges, independently included in the intervening range, are also encompassed by the technology if they specifically exceed the limits in the stated range. If the stated range includes one or both of these limits, then ranges exceeding either or both of these stated limits are also encompassed by the technology.

[0207] Additionally, when one or more values ​​are described herein as being implemented as part of the technology, it is understood that these values ​​may be approximated unless otherwise stated and may utilize any suitable significant figures to the extent that actual technical implementation may permit or require.

[0208] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art. Although any methods and materials similar or equivalent to those described herein can be used in the practice or testing of the present technology, a limited number of exemplary methods and materials are described herein.

[0209] Although particular materials are described as being suitable for use in the construction of components, obvious alternative materials having similar properties may be substituted. Further, unless otherwise specified, any and all components described herein are understood to be manufacturable and therefore may be manufactured collectively or separately.

[0210] It should be noted that as used herein and in the appended claims, the singular forms "a," "an," and "the" include their plural equivalents unless the context clearly dictates otherwise.

[0211] All publications mentioned herein are incorporated by reference to disclose and describe the methods and / or materials to which they are addressed. The publications mentioned herein are provided solely for their disclosure prior to the filing date of the present application. Nothing herein should be construed as an admission that the present technology is not entitled to antedate such publication by virtue of prior patent. Further, the publication dates provided may be different from the actual publication dates, which may need to be independently confirmed.

[0212] Moreover, in interpreting this disclosure, all terms should be interpreted in the broadest reasonable manner consistent with the context. The terms "comprises" and "comprising" should be interpreted as referring to elements, components, or steps in a non-exclusive sense, indicating that a described element, component, or step may be present in, utilized in, or combined with other elements, components, or steps not specifically recited.

[0213] The headings used in the detailed description are for the convenience of the reader and should not be used to limit the content found in the disclosure or claims as a whole. These headings shall not be used in interpreting the scope of the claims or the claim limitations.

[0214] Although the technology herein has been described with reference to particular embodiments, it should be understood that these embodiments are merely illustrative of the principles and applications of the technology. In some cases, terms and symbols may indicate specific details unnecessary for the practice of the technology. For example, although the terms "first" and "second" are used, unless otherwise specified, these terms are not intended to indicate any order but are used to distinguish between separate elements. Furthermore, although the process steps in the method may be described or illustrated in an ordered manner, such an order is not required. Those skilled in the art will recognize that such an order can be changed and / or aspects can be performed simultaneously or even synchronously.

[0215] It is therefore to be understood that numerous modifications may be made in the illustrative embodiments and that other arrangements may be devised without departing from the spirit and scope of the present technology.

[0216] While the present invention has been described with reference to specific implementations, it will be apparent to those skilled in the art that the present invention is not limited to the details of the illustrative implementations described above, and that the present invention can be embodied with various changes and modifications without departing from its scope. Therefore, the present embodiments are to be considered in all respects as illustrative and not restrictive, the scope of the present invention being indicated by the appended claims, rather than by the foregoing description. Accordingly, all changes that come within the meaning and range of equivalency of the claims are intended to be embraced therein. In other words, any modifications, variations, or equivalents that are within the scope of the basic underlying principles and whose essential attributes are claimed in this patent application are intended to be covered. Furthermore, readers of this patent application should understand that the terms "comprising" or "comprise" do not exclude other elements or steps, and that the terms "a" or "an" do not exclude a plurality, and that a single element, such as a computer system, processor, or another integrated unit, may fulfill the functions of several means recited in the claims. Any reference signs in the claims should not be construed as limiting the respective associated claims. When used in the specification or claims, terms such as "first," "second," "third," "a," "b," "c," etc. are introduced to distinguish between similar elements or steps and do not necessarily describe an order or chronology. Similarly, terms such as "top," "bottom," "above," and "below" are introduced for descriptive purposes and do not necessarily denote relative positions. It should be understood that terms used in this manner are used interchangeably under appropriate circumstances, and that embodiments of the present technology can operate in accordance with the present technology in other orders or in other direction(s) than those described or illustrated above.

Claims

1. 1. A method of one or more servers for transferring access to patient data from a first organization to a second organization, the patient data including therapy data relating to one or more patients, the method comprising: generating, by the one or more servers, a user interface; receiving job input data via the user interface, the job input data including transfer information indicating the first organization and the second organization; generating, by the one or more servers, a transfer job based on the job input data, the transfer job including list data indicating the one or more patients, the one or more patients being associated with the first organization; executing, by the one or more servers, the generated transfer job, the execution including iterating through the list data and, for each patient indicated by the list data, communicating a transfer command to a plurality of data services of the one or more servers, whereby access to the patient data in a central database associated with the one or more patients indicated by the list data is transferred from the first organization to the second organization; generating transfer job status information regarding the status of the execution for display on the user interface.

2. The method of claim 1 , wherein the plurality of data services includes a billing rules system, a compliance rules system, a list service, and a device type subset data system.

3. 3. The method of claim 1, wherein the user interface prompts for input of target entity identification information and source entity identification information, and generates a network communication to a merger coordinator service using the input target entity identification information and input source entity identification information.

4. The method of claim 3 , wherein the merger coordinator service receives the network communication including the entity identification information and the source entity identification information, and queries the central database to generate a list of patients associated with the source entity identification information.

5. 5. The method of claim 3, wherein the user interface further prompts for a location of a clinical user or the source entity, and generates a network communication to the merger coordinator service using the location of the clinical user or the source entity.

6. 6. The method of claim 3, wherein the user interface further prompts for input of a location of a clinical user or the target entity, and uses the location of the clinical user or the target entity to generate the network communication to the merger coordinator service.

7. 7. The method of claim 3, wherein the user interface further prompts for input of a location of a clinical user or the target entity, and generates the network communication to the merger coordinator service using the location of the clinical user or the target entity.

8. The method of claim 4 , wherein the merger coordinator service communicates with a patient transfer service iteratively for each patient in a list of patients.

9. 9. The method of claim 8, wherein the patient transfer service communicates with the plurality of data services and the central database in response to each iterative communication from the merger coordinator service to transfer access to patients on the patient list from the first organization to the second organization.

10. 10. The method of claim 1, wherein the user interface presents a restart icon associated with a failed transfer, and the user interface is configured to communicate a request to restart the failed transfer in response to activation of the restart icon.

11. The method of any one of claims 3 to 10, wherein the merger coordinator service communicates with a database to store the transfer job status information.

12. 12. The method of claim 1, wherein the patient data to which access is transferred upon execution includes therapy device data, and the method further comprises communicating with one or more servers one or more control commands to a patient therapy device based on the therapy device data to modify operation of the therapy device.

13. 1. A system for transferring access to patient data from a first organization to a second organization, the patient data including therapy data relating to one or more patients, the system comprising: one or more processors; one or more computer-readable storage media having program instructions that, when executed by the one or more processors, cause the system to: generating a user interface; receiving job input data via the user interface, the job input data including transfer information indicating the first organization and the second organization; generating a transfer job based on the job input data, the transfer job including list data indicating the one or more patients, the one or more patients being associated with a first organization; executing the generated transfer job, the execution including iterating through the list data and, for each patient indicated by the list data, communicating a transfer command to a plurality of data services of the one or more servers, whereby access to the patient data in a central database associated with the one or more patients indicated by the list data is transferred from the first organization to the second organization; generating transfer job status information regarding the status of the execution for display on the user interface.

14. The system of claim 13 , wherein the plurality of data services includes a billing rules system, a compliance rules system, a list service, and a device type subset data system.

15. 15. The system of claim 13, wherein the user interface is configured to prompt for input of target entity identification information and source entity identification information, and to generate a network communication to a merger coordinator service using the input target entity identification information and input source entity identification information.

16. 16. The system of claim 15, wherein the merger coordinator service is configured to receive the network communication including the entity identification information and the source entity identification information, and further configured to query the central database to generate a list of patients associated with the source entity identification information.

17. 17. The system of claim 15, wherein the user interface is further configured to prompt for input of a location of a clinical user or the source entity, and further configured to generate a network communication to the merger coordinator service that includes the location of the clinical user or the source entity.

18. 17. The system of claim 15, wherein the user interface is configured to further prompt for input of a location of a clinical user or the target entity, and to generate the network communication to the merger coordinator service using the location of the clinical user or the target entity.

19. 19. The system of claim 15, wherein the user interface is further configured to prompt for input of a location of a clinical user or the target entity, and to generate the network communication to the merger coordinator service using the location of the clinical user or the target entity.

20. 20. The system of any one of claims 16 to 19, wherein the merger coordinator service is configured to communicate iteratively with a patient transfer service for each patient in the list of patients.

21. 21. The system of claim 20, wherein the patient transfer service is configured to communicate with the plurality of data services and the central database in response to each recurring communication from the merger coordinator service to transfer access to the patient in the list of patients from the first organization to the second organization.

22. 22. The system of claim 13, wherein the user interface is configured to present a restart icon associated with a failed transfer, and wherein the user interface is configured to communicate a request to restart the failed transfer in response to activation of the restart icon.

23. 23. The system of any one of claims 13 to 22, wherein the patient data to which access is transferred by the execution of the generated transfer job includes therapy device data, and the system is further configured to communicate with one or more servers one or more control commands to a patient therapy device based on the therapy device data to modify operation of the therapy device.

24. 1. A method of one or more servers for transferring access to patient data from a first organization to a second organization, the patient data including therapy data relating to a patient using a therapy device, the method comprising: generating, by the one or more servers, a user interface that transfers access to the patient data; receiving, by the user interface, input data from the second organization, the input data including a device identification designation for the therapy device; based on receipt of the device identification indication, communicating a transfer command to a plurality of services of the one or more servers, whereby access to the patient data for the patient in a central database is transferred from the first organization to the second organization; generating an indication of the transfer of access for display on the user interface.

25. 25. The method of claim 24, wherein the user interface prompts for entry of a serial number of the therapy device and activates a search of the central database by the serial number.

26. 26. The method of claim 25, wherein in response to a search, the user interface displays patient data for a patient associated with (a) the first organization and (b) the device identification designation for the therapy device.

27. 27. The method of any one of claims 24 to 26, wherein the user interface prompts for input of confirmation of authority to request transfer of the patient from the first organization to the second organization.

28. 28. The method of any one of claims 24 to 27, wherein the user interface prompts a clinical user of the second organization and / or the second location to input a location.

29. 28. The method of any one of claims 24 to 27, wherein the user interface displays the indication of the transfer of the access to the second organization.

30. 28. The method of any one of claims 24 to 27, further comprising generating a further user interface and communicating the further user interface to the first organization, the further user interface including a display of the indication of the transfer of access.

31. 31. The method of any one of claims 24 to 30, wherein the patient data to which access is transferred based on the communicated transfer command includes therapy device data associated with the therapy device, and the method further includes communicating one or more control commands to the therapy device with one or more servers based on the therapy device data to modify operation of the therapy device.

32. 1. A system for transferring access to patient data from a first organization to a second organization, the patient data including therapy data relating to one or more patients, the system comprising: one or more processors; one or more computer-readable storage media having program instructions that, when executed by the one or more processors, cause the system to: generating a user interface for transferring access to the patient data; receiving, by the user interface, input data from the second organization, the input data including a device identification designation for the therapy device; communicating a transfer command to a plurality of services of the one or more servers based on the received device identification indication, whereby access to the patient data for the patient in a central database is transferred from the first organization to the second organization; generating an indication of the transfer of access for display on the user interface.

33. 33. The system of claim 32, wherein the user interface is configured to prompt for input of a serial number of the therapy device and activate a search of the central database by the serial number.

34. 34. The system of claim 33, wherein in response to the search, the user interface is configured to display patient data for a patient associated with (a) the first organization and (b) the device identification designation of the therapy device.

35. 35. The system of any one of claims 32 to 34, wherein the user interface is configured to prompt for input of confirmation of authority to request transfer of the patient from the first organization to the second organization.

36. 36. The system of any one of claims 32 to 35, wherein the user interface is configured to prompt a clinical user of the second organization and / or the second location for input of a location.

37. 37. The system of any one of claims 32 to 36, wherein the user interface is configured to display the indication of the transfer of the access to the second organization.

38. 38. The system of any one of claims 32 to 37, wherein the system is further configured to generate a further user interface and communicate the further user interface to the first organization, the further user interface configured to display the indication of the transfer of access.

39. 38. The system of any one of claims 32 to 37, wherein the patient data to which access is transferred based on the communicated transfer command includes therapy device data associated with the therapy device, and the system is further configured to communicate one or more control commands to the therapy device with one or more servers based on the therapy device data to modify operation of the therapy device.

Images