KR20230142486A - Network-based medical device control and data management system - Google Patents

Abstract

A new method for controlling the operation of medical devices and related systems is provided. Devices collect and relay sensor data streaming over a secure Internet connection, but they can also collect this data locally, such as cached data. When certain events occur, the device also relays the collected cache data. Device data is received by a network data system that analyzes the data and controls the operation of the device and other network devices based on this analysis. A medical device may include multiple zones that perform various data collection functions and undergo various data relay processes. The system can separate protected health information from commercial users who may have access to specific analytics data. In aspects, the system interacts with a third-party database, such as a customer relationship management system, when generating analytics data. In aspects, a machine learning process is used to improve the operation of such systems.

Description

Network-based medical device control and data management system

Cross-reference to related applications

This application claims the benefit of U.S. Provisional Patent Application No. 63/134,951, entitled SECURE MULTI-FUNCTIONAL MEDICAL APPARATUS CONTROL AND DATE MANAGEMENT SYSTEMS, filed January 7, 2021, currently co-pending September 24, 2021 Priority is claimed on U.S. Patent Application Serial No. 17/484,760, entitled NETWORK-BASED MEDICAL APPARATUS CONTROL AND DATA MANAGEMENT SYSTEMS, filed on the same date. This application is incorporated by reference in its entirety into the above-mentioned priority application.

Technology field

The present invention relates to medical devices configured for use in professional medical device data networks, systems for controlling such devices, and networks formed between such devices and systems.

Medical devices play an increasingly important role in healthcare. WHO estimates that the global market includes 2 million different types of devices distributed across more than 22,000 categories. Modern medical devices collect information from sensors, implement different levels of treatment/therapeutic support, or both. These devices can display relevant information or provide alerts to users, such as “health care providers” (“HCPs”). For example, US20200288988 (Abiomed, Inc.) discloses a system for measuring flow within a blood vessel with an internally inserted catheter-based heart pump, without relying on measurement of the current drawn by the motor driving the heart pump. The pump is coupled to a signal generator that generates a signal representing the pump turbine speed by reflecting the fluid flow speed within the blood vessel and is coupled to another component that calculates the blood flow speed from the turbine rotation speed.

Medical device data is increasingly available in connected computer networks/systems, such as hospital information systems and electronic medical records (“EMR”). However, electronic data systems currently on the market operate with a limited number of users, process limited types of data, or perform limited analyzes or actions based on such data, limiting the adoption of such systems. Nonetheless, there is increasing sophistication in managing and using data collected from medical device networks (sometimes referred to as the “internet of medical things” (abbreviated “IoMT”)).

As described herein, all of the physical and data components of a complex, integrated modern medical treatment environment are combined, managed, and managed in a secure, compliant, and effective manner that is usable by the various users who interact with these systems. The development of a comprehensive and effective medical device data management and control system requires the application of significant creative ingenuity. These inventive systems and related methods are provided herein.

Composition, Terms and Abbreviations

This section provides guidelines for reading this disclosure. The target audience (“reader”) of this disclosure is anyone with general skill in practicing the techniques discussed or used herein. The reader is sometimes called a 'skilled person', and these skills are sometimes called 'skilled people'. Terms such as “understood,” “known,” and “common meaning” refer to the general knowledge of those skilled in the art.

The term "non-contrary" means not inconsistent with the present disclosure, logic or validity based on the knowledge of those skilled in the art.

Disclosed herein are several different but related exemplary embodiments (“embodiments”) of the invention (“instances,” “facets,” or “embodiments”). The invention includes all aspects that are described individually and can be reached by any combination of these individual aspects. The breadth and scope of the present invention should not be limited by any exemplary embodiments. No language in this disclosure should be construed as indicating any element/step essential to the practice of the invention unless such requirement is explicitly stated. Any aspect that is not contradictory may be combined with any other aspect.

Without contradiction, all technical/scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art, regardless of the narrower examples or explanations provided herein (including any terms first introduced in a citation). However, embodiments characterized as including elements, steps, etc. related to the specific description provided herein are separate embodiments of the invention. Without being contradictory, the disclosure of any aspect using known terms to which the terms in this disclosure are narrowed, by way of example or otherwise, refers to the relevant aspects for which such terms are alternatively interpreted using the broadest reasonable interpretation of those skilled in the art. Starts implicitly.

Without being contradictory, “or” means “and/or” herein regardless of whether “and/or” is sometimes included (e.g., “A, B or C” and “A, B and/or”). Phrases like "C" are (1) all A, B, and C; (2) A and C; (3) A and B; (4) B and C; (5) A only; (6) B only; and (7) simultaneously disclose aspects that include only C (and also support subgroupings such as “A or B”, “A or C”, etc.).

Not to be contradictory, “also” means “also or alternatively.” Without contradiction, “herein” and “herein” mean “in this disclosure.” The term “i.a” (“ia” or “ia”) means “among others” or “above all.” “Also known” is abbreviated as “aka” or “AKA” (and may indicate that the terms are synonymous even if the terms are not known in the art). “Elsewhere” means “elsewhere here.”

For brevity, symbols are used where appropriate. For example, “&” is used for “and” and “~” is used for “about.” Symbols such as < and > are given general meanings (e.g., “≤” means “less than” and “≥” means “more than”). The slash "/" can indicate "or" ("A/B" means "A or B"), as the context suggests, or it can identify a synonym for an element.

If "(s)" is included after an element or step, it indicates that at least one element exists and the step is performed. For example, “element(s)” refers to one element or two or more elements, each of which is understood to be an independent aspect of the invention.

The use of the abbreviation “etc.” (or “etc.”) in connection with a list of elements/steps refers to any or all suitable combinations of the mentioned elements/steps to achieve the function(s) of such elements/steps as known in the art. or known equivalents of the mentioned elements/steps. Terms such as “and combination” or “or combination” in relation to listed elements/steps mean a combination of any or all of those elements/steps. “Suitability” means acceptable or appropriate element(s)/step(s) to perform a particular function or achieve a particular state(s)/result(s), generally to the intended function/characteristics/results. It means effective, practical and not harmful/harmful.

Non-contradictory headings (e.g., “Organizations, Terms and Abbreviations”) and subheadings are included for convenience and do not limit the scope of any aspect(s). Non-contradictory aspect(s), step(s) or element(s) described under one heading may be applied to other aspect(s) or step(s)/element(s) herein.

A range of values is used to represent each value that falls within a range within the order of the size of the smallest endpoint of the range, without having to explicitly write each value in the range. For example, the range 1-2 mentioned is 1.0, 1.1, 1.2, … 1.9 and 2.0 are implicitly initiated respectively, and 10-100 is 10, 11, 12, … 98, 99, and 100 are implicitly disclosed, respectively. All non-contradictory scopes include the scope's endpoints, regardless of how the scope is described. For example, “between 1 and 5” includes 1 and 5 in addition to 2, 3, and 4 (and all numbers between those numbers within the order of magnitude of that endpoint, for example, 1.0, 1.1, … 4.9, and 5.0). is included. For the avoidance of doubt, all numbers within a range are included in the range (for example, the range 2-20 includes 18.593), regardless of the order of magnitude of the numbers.

An approximate term (e.g., “about”, “~”, or “approximately”) refers to (1) a set of related values, or (2) when exact values are difficult to define (e.g., due to measurement limitations). says Without contradiction, every exact value provided herein simultaneously/implicitly discloses the corresponding approximate value and vice versa (e.g., a disclosure of “about 10” would mean exactly 10 in this embodiment/description). provides explicit support for the use of ). The range described as approximate value(s) includes all values encompassed by each approximate endpoint, regardless of expression (e.g., “about 10-20” is equivalent to “about 10 - about 20”). have the same meaning). The range of value(s) encompassed by an approximate term generally depends on the context of disclosure, significance or operability, statistical significance, understanding of the art, etc. In the absence of guidance herein or in the art, terms such as “about” should be interpreted as +/- 10% of the indicated value(s).

Sometimes lists of aspects, elements, steps and functions are used for brevity. Unless specified, each member of each list should be viewed as an independent entity. Each aspect defined by any individual member of the list can and often will have characteristics that are less obvious than aspects characterized by other members of the list.

Without contradiction, the terms “a”, “an” and “the” and similar referents include both the singular and the plural of the referenced elements, steps or aspects. Without contradiction, singular terms herein imply the plural and vice versa (i.e., disclosure of an element/step implicitly discloses corresponding use of such/similar elements/steps and vice versa). ). Thus, for example, a passage relating to an aspect comprising step X supports corresponding aspects comprising multiple steps X. In a non-contradictory paragraph, sentence, aspect or claim, a referent such as “a” for one element/step or characteristic and “one or more” for another element/step or characteristic may be used. Mixed use does not change the meaning of these referents. Thus, for example, if a paragraph describes a configuration consisting of “X” and “one or more Y,” that paragraph should be understood as providing disclosure of “one or more X” and “one or more Y.”

Without contradiction, “significant” and “significantly” refer to a result/characteristic that is statistically significant (e.g., p≤0.05/0.01) using one or more appropriate test(s)/test(s) in a given context. means. “Detectable” means measurably present or different using known detection tools/techniques. The abbreviation "DOS" (or "DoS") means "detectable or significant." Without contradiction as suggested above, the term "appropriate" means that it is generally appropriate, acceptable, or sufficient under the circumstances, does not cause or deliver significant negative/harmful effects, and performs its intended function at least generally or substantially all of the time. means providing.

For any value herein that is not accompanied by a non-contradictory unit of measurement (e.g. 50 for weight or 20 for length), the units previously provided for the same element/step or element/step of the same type apply or , in the absence of such disclosure, the most commonly used units relating to these elements/steps in the art will apply.

Without contradiction, the terms “comprising,” “containing,” “consisting of,” and “having” mean “including, but not limited to,” or “including, without limitation.” Non-contradictory use of terms such as constituting and comprising in relation to elements/steps refers to including a detectable number or quantity of elements or detectable performance of a number of steps/steps (regardless of other elements/steps). it means.

For the sake of brevity, a description of an aspect “constituting” or “comprising” an element in relation to a collection/whole (e.g. a device/composition) simultaneously implies a detectable quantity/number or of the whole/collection. More than 1%, more than ~5%, more than ~10%, more than ~20%, more than ~25%, more than ~33%, more than ~50%, more than ~51%, more than ~66%, more than ~75%, ~ More than 90%, more than ~95%, more than ~99%, or more than ~100% of the element, or essentially the entire/collection consists of the element (i.e., the collection essentially consists of the referenced elements). Likewise, methods described as including steps related to effectiveness/outcome are implicitly defined as ~1% or more, ~5% or more, ~10% or more, ~20% or more, or ~25% or more of the steps/effort performed; Effects representing more than ~33%, more than ~50%, more than ~51%, more than ~66%, more than ~75%, more than ~90%, more than ~95%, more than ~99%, or more than ~100% >1%, >5%, >10%, >20%, >25%, >33%, >50%, >51%, >66%, >75% of the stage. Implicitly provides support for reference steps that provide at least, ~90% or more, ~95% or more, ~99% or more, or both. Explicitly listing the percentage of elements/steps associated with an aspect is not intended to limit or deny such implicit disclosure.

When used in connection with a step of a method without being contradictory, terms such as “comprising” provide implicit support for performing that step once, twice or more, or until the relevant function/effect is achieved.

The term "one" means a single type, a single repetition/copy/thing, or both, of the recited element or step. For example, “a” component of a device/configuration may mean one type of element (which may exist in numerous copies, as is the case for components of a device/configuration), one unit of the element, or both. Likewise, "one" component, "single" component, or "only component" of a system generally means one type of element (which may exist in multiple copies), one instance/unit of the element, or both. Additionally, “one” step of a method generally means performing one type of action (step), one repetition of a step, or both.

The term "part" means that two or more copies/instances or more than 5% of the listed collection/total are or consist of an element. With respect to a method, some mean that more than 5% of the effectiveness, effort, or both are comprised of or attributable to steps (as in, for example, “some of the method is performed by step Y”) or that the steps are Indicates that it is performed more than once (e.g., as in “step X is repeated several times”). “Mainly,” “mostly,” or “mostly” means detectably greater than 50% (e.g., mostly including, mainly including, etc. means more than 50%) (e.g., most of element The containing system consists of more than 50% of element X). The term "generally" means at least 75% (e.g., generally consisting of, generally associated with, generally including, etc. means at least 75%) (e.g., generally consisting of step method means that 75% of the effort or effectiveness of the method is due to step X). "Substantially" or "almost" means more than 95% (e.g., almost entirely, consisting substantially of, etc. means more than 95%) (e.g., a vowel composed almost entirely of the element means that at least 95% of the elements are elements X).

Any embodiment described with respect to optional element(s)/step(s), without contradiction, also includes one, some, most, generally all, substantially all, essentially all, or All provide implicit support for the corresponding aspect(s) that is lacking/step(s) is not performed with respect to the relevant aspect. For example, disclosure of a system containing element X also implicitly supports systems without element X. Consistently changing the tense or expression of a term (for example, using “comprises predominately” instead of “predominately comprises”) does not change the meaning of the term/phrase.

Without being contradictory, all methods provided herein can be performed in any suitable order regardless of presentation (e.g., a method comprising steps A, B, and C in the order C, B, and A; B and A and C can be performed simultaneously). Without being contradictory, the elements of the device/construction may be assembled in any suitable manner by any suitable method. In general, any methods and materials similar or equivalent to those described herein can be used in the practice of the embodiments. The non-contradictory use of ordinal numbers such as "first", "second", "third", etc. is intended to distinguish each element rather than to indicate a specific order of elements. Any element, step, component or feature of the embodiments and all modifications thereof, etc., without contradiction, are within the scope of the present invention.

Elements related to functionality may be described as “means” for performing a function in a configuration/device/system or as “steps” for performing part of a method, and in some parts of this disclosure, the disclosed means(s)/step(s) and "Equivalent" refers to an equivalent known in the art to achieve the associated referenced function. However, no element of the disclosure or claims constitutes a “means-plus-function” unless such intent is clearly indicated by use of the term “means for” or “steps for.” It should not be construed as limited. Terms such as "configured to" or "adapted to" are not meant to be construed as "functional," but rather are constructed, designed, or designed to achieve a particular performance, characteristic, attribute, etc., using the teachings provided herein or in the art. , describes the element(s)/step(s) to be selected or adapted.

All references (e.g., publications, patent applications, and patents) cited herein are herein incorporated by reference as if each reference was individually and specifically indicated to be incorporated by reference and set forth herein in its entirety. Without being contradictory, any suitable principle, method or element of this reference (collectively, the “teachings”) may be combined with or adapted to the aspects. However, citation/incorporation of a patent document is limited to its technical disclosure and does not reflect any opinion regarding its validity, patentability, etc. In case of conflict between this disclosure and the teachings of these documents, the contents of this disclosure will control with respect to aspects of the invention. Numerous references are incorporated herein to concisely consolidate known information and to assist those skilled in the art in applying the embodiments to their practice. Although efforts have been made to include the most relevant references for this purpose, the reader will understand that not every aspect of every reference cited applies to every aspect of the invention.

Additional Terms, Concepts, and Acronyms

The following explanation of specific terms and terms is provided to assist the reader in understanding the present invention. Additional abbreviations may be provided only in other parts of the disclosure, and abbreviations well known in the art may not be provided herein.

Without being contradictory, "improved" herein means detectable or detectable, such as increased with respect to favorable outcomes, characteristics, etc. and decreased with respect to negative outcomes, characteristics, etc., or decreased with respect to required time spent, required costs/energy, etc. It means significantly better. Terms such as “enhanced,” “improved,” and the like are used synonymously herein without being contradictory. Without contradiction, “causing” means causing directly or indirectly. For example, “triggering” the engine of a system/device to perform an analysis could be done by choosing to put the system into operation, after which the engine would automatically and repeatedly, periodically, execute command(s). ) or in response to the presence of a detected (usually pre-programmed) condition(s).

A “system” of the present invention refers to (1) memory component(s) comprising a computer-readable medium containing pre-programmed instructions to perform the function(s) and (2) instructions to cause the function(s) to be performed. It includes a collection of electronic devices/devices consisting of interrelated/interacting components/devices, including a computer/processing unit capable of reading/executing. The system of the present invention is often referred to as a network data system (“NDS”), where the NDS controls the operation of a networked device, MAC-DMS, to connect the system to other systems (e.g., NDS, MA or OND, etc.). distinguishes it from a reference to a system). The reader can identify where the term system is used to describe an NDS through context.

Individuals/entities who access/utilize NDS, either directly or through a network device, are referred to as “Users”. In aspects, users are characterized by the “class” of role/occupation they belong to (eg, manager, researcher, or HCP). For example, “Administrator” is a type of user. Specifically, an administrator is an individual, team, or organization associated with the NDS owner, typically responsible for managing, building, or maintaining one or more functions/modules or systems.

The system/NDS receives subject-related data from one or more, typically multiple, subject-related medical devices that are networked with the NDS. A medical device (“MA”) includes hardware and facilitates or performs task(s) related to the diagnosis, treatment, prevention, mitigation, or recovery of a disease or condition (including symptoms thereof) in a subject, such as a human patient; Includes or is associated with sensors that detect patient-related data, device data, or both; It is an electronic medical device that can relay such data directly or indirectly to the NDS.

MAs often diagnose, treat, or otherwise detect or control a "subject's" condition. A “subject” may be any type of mammal (e.g., a companion animal). In aspects, the subject is or includes a human patient. In aspects, the patient is a patient diagnosed as suffering from one or more critical (potentially life-threatening) conditions, such as a brain condition, heart condition, lung condition, or other organ/organ system condition. Without contradiction, “subject” and “patient” hereby implicitly support each other.

A “group” or “network” of Medical Devices (MAs) is, for example, all MAs networked with an NDS, or in one location (site, group of sites, facility, metropolitan area, region (e.g., county or similar area), state). /one or more associated by one or more characteristics, such as being in, or belonging to any MA in a province, interstate/interregional (e.g., New England), country, international region (e.g., EU), or continent means any collection of types MA. "entity" is an organization (e.g. a corporation or other company) recognized as having legal rights under the laws of one or more countries or international organizations. An entity is an entity An entity is “independent” if it is recognized as a separate entity under applicable law. Independent entities generally do not have common control/ownership.

A MA is a computerized medical device (e.g., a medical device that includes computer(s)). Terms such as "computing unit", "computer", etc. generally refer to a device that includes a physical computer-readable medium and a processor to process ("read") information on such medium. The media may also include information data and functional information (modifiable/programmable computer executable instructions (CEI)). These instructions involve special engines and perform functions. The processor(s) read (e.g., generate “output”) the CEI to allow the corresponding function(s) to be performed. In aspects, a “computerized device”, such as a “computer” or “other network device” (“OND”), may include, for example, a mobile computing device (e.g., a smartphone), a desktop computer, This may be a laptop computer, tablet device, etc. Other network components (e.g., systems) include more complex processing or memory components, as described elsewhere. A functional data structure used in a system/network can be an interface (the set of operations supported by the data structure), an implementation (including the internal representation of the data structure, defining the code/algorithms used to operate the data structure, or both), or a combination of these. It can be included.

Computerized devices that communicate with each other form a data network (“network”). Generally, all references to a “network” herein refer to a network that, in operation, includes an NDS and multiple MAs, and optionally has other components (e.g., OND, CRM database, etc.). Such a network is one aspect of the invention. In some cases, the term network is used to describe another network (e.g., a network/MA group). Readers will be able to determine when the term network is used to refer to a network other than the network that includes NDS and MA.

In operation, components of a network (e.g., an NDS:MA network) use a common communication protocol, typically over a digital interconnect, on a recurring basis, typically on a regular or ongoing basis, for the purpose of sharing data, functions, or other resources. ) interact/communicate. A network typically includes physical components such as routers, switches, etc., which are discussed elsewhere.

The components of a network are sometimes described as "clients" and "servers." Clients and servers are usually remote from each other and usually interact through communication/data networks. The relationship between client and server is created by computer programs that run on each computer and have a client-server relationship with each other. In some embodiments, a server transmits data, e.g., an HTML page, to a user device for the purpose of displaying data and receiving user input from a user interacting with the device acting as a client. . Data generated on the user device, for example the results of user interactions, may likewise be relayed to the server.

A system component may be/include a computer, but typically the system/NDS has capabilities far exceeding the memory and processing power of a typical general purpose laptop, cell phone, etc., as well as special instructions to perform specific processes described herein. Includes /system. In aspects, the system component includes a remote/virtual computing unit, such as a cloud memory or cloud processing unit. However, other network devices (ONDs) may include laptops, cell phones, etc. in aspects.

The computer units of NDS, MA and other network components perform various functions. A “function” or “function” is a computer-implemented operation performed by the NDS or other component of the network based on both pre-programmed computer readable and executable instruction(s), e.g., in response to input(s). A function may also describe the result of a method step(s). The step(s) of this method/element of this function(s) may include algorithms, methods, etc. described below. In general, the functionality may be performed by both the unit(s)/component(s) of the NDS/device and the associated method steps.

An "engine" ("engine" or "data engine") is designed to perform specified function(s) based on computer executable/readable instructions ("CEI"), typically contained in memory (and which constitute the engine). It is a configured computer/processor executable software program/application. Generally, an engine processes input(s) and produces output(s). The engine may be implemented on computer(s) at one or more locations. In aspects, the various components of the engine are installed and running on one or more computer(s); Multiple instances of the Engine are installed and running on more than one computer; It could be both. The operation of the engine performs a function, and the function may be performed by the engine. These aspects are implicitly described by any explicit description of an engine or function (e.g., a description of a system/component containing an engine to perform a function(s) may describe the steps for performing the function. (s) implicitly discloses the method of inclusion). An engine that receives user input and provides output to the end user can be called an “application.” An engine may be described as, or form part of, a "program", code", or "algorithm". An engine/program can be any form of programming language, including a compiled or interpreted language, or a declarative or procedural language. code); and can be deployed in any form, including as a stand-alone program, or as a module, component, subroutine, or other unit suitable for use in a computing environment. A program may correspond to a file in the file system, but , this is not necessarily the case. A program/engine may contain other programs or data (e.g., one or more scripts stored in a markup language document), a single file dedicated to that program, or several coordinated files (e.g., one or more modules, A computer program/engine may be stored on a single computer, located at one site, or distributed across multiple sites and interconnected by a data communications network. The program/engine can also be described as "instructions" or "computer-implemented instructions", "processor-implemented instructions", "computer-readable instructions", "computer-implemented data engine", etc. there is.

The term "module" or "module" generally refers to a mechanical component of a computer system (e.g., network interface card, processor(s), etc.) and engine(s) that together perform function(s). /refers to a combination of electrical or other physical/non-software component(s). Without contradiction, terms such as module implicitly disclose that combination of “processor and engine” containing computer-readable instructions for performing the indicated functions. Use of the terms “Engine” or “engine” in any embodiment, without being contradictory, implies that the referenced function(s) is performed by a module and vice versa. Reveal. Accordingly, without being contradictory, any disclosed “Engine” or “engine” implicitly supports the corresponding module including physical components (e.g., processor(s) and memory component(s)).

The term "Unit" or "unit" generally refers to the structural element(s) of a computer device, system, or component that is an engine or module, and is not intended to contradict, is impliedly disclosed, and thus refers to the structural element(s) of a computer device, system, or component that is an engine or module. Or it can be replaced by a module.

The term “controller” may apply to any engine, unit, module, device, component, system, etc. that directly or indirectly controls the operation of another device, engine, system, unit, etc., even if not always described as such. Thus, for example, the engine of a system that creates applications that control the operation of networked devices may also be described as a controller of these other devices. Engines, processors, and other elements of systems and devices may also be described as "components" of such systems, devices, etc. An engine may also include components such as algorithms, subprograms, etc.

Sometimes step(s) of function(s) or function(s) of engine(s) are described herein using pseudocode/algorithms. For brevity, the pseudocode is written on one line using indicators in the following order: (1) Arabic numerals, (a) lowercase letters, (I) uppercase Roman numerals, (A) uppercase letters, and (i) lowercase Roman numerals. In some cases, it is presented to provide a hierarchical structure. For example, the pseudocode for the algorithm is:

START

(1) DECLARE A = 10

(2) INPUT B

(3) IF B > 0

(a) WHILE A ≤ 10

(I) IF A ≠ 0

(A) DECLARE C = A * B

(II) ELSE

(A)PRINT C

(b)DECREMENT A (A = A-1)

END

START, (1) DECLARE A = 10, (2) INPUT B, (3) IF B >0: (a) WHILE A ≤ 10: (I) IF A ≠ 0: (A) DECLARE C = A * B, (II) ELSE: Can be written as (A) PRINT C, (b) DECREMENT A (A = A-1) and END.

The way the engine is encoded depends on the selection of human-readable instructions provided to the system/computer that allow manual modification and control of the functions and functions of the computer/system to perform the functions. Each Engine is/is a special device containing a physical medium containing physically encoded process/computer executable instructions to perform specific steps that provide special technical effects when read/executed by the processor(s). It works. These technical effects include transforming data in ways that cannot reasonably be done by humans (e.g., by sorting and displaying portions of that data simultaneously to different, independent types of stakeholders), thereby improving system efficiency (e.g. For example, medical device control speed, device data transfer speed, etc.) or controlling the operation of a therapeutic medical device.

“Input” generally refers to data provided to the NDS, Device, etc. from an external source (e.g., an associated medical device, a user providing information to a networked device, an external database, or a combination thereof (“CT”)). do. An “output” may be any device or component that displays or relays data to a user or other devices/components of the device/system/network or applies data-based activities (e.g., controlling a medical device). In some cases, output that is not pure data is called an output application.

“Interface” in the context of data input/output may be any suitable interface between a user and a computer, network or system (e.g., the NDS of the present invention). In aspects, the term “interface” refers to a user interface implemented in the form of a web page or similar medium that can be viewed/navigated on multiple devices over the Internet (e.g., using standard web browser(s)). Used to refer to a “web interface” or “software interface”). These interfaces typically include preprogrammed layouts that are specific to the user, user class, or both. A device that displays/accesses an interface, such as a special web interface, can be considered a device on the network. In aspects, a device accessing a network includes fixed/specialized interface hardware. Likewise, network devices are also called devices/interfaces; However, without contradiction, disclosing one of these aspects implicitly discloses the other aspect and vice versa.

Terms such as “data” and “information” are used interchangeably herein and are limited to a particular form only when indicated by an explicit definition/statement or clear context. Interrelated data may be described as a “record” or “record.” Records will often have attributes (characteristics) and values (measurements/properties). Records may be structured, semi-structured or unstructured depending on the context, as described below. A collection of records can be called a "dataset." A collection of datasets in memory can be called a "data store."

A “schema” is an organization of data, usually created by applying constraints/structures to a collection of less ordered data to form a new collection of ordered, structured data from the “base” data. Other data collections, such as data stores, are discussed elsewhere. “Representation” is a similar data organization, but is generally used specifically in relation to data specifically designed for or associated with instructions for display in a graphical user interface or other visual output (e.g., printing). Representations can also include information about objects, systems, devices, processes, etc. that exist in structured/hierarchical or otherwise interacting or connected relationships (e.g., medical devices or devices associated with a particular hospital, geographical area, user class, independent entity, etc.). grouping of data from) can be provided.

Data generated and transmitted in the network/system of the present invention includes CEI (e.g., instructions for a processor that causes the MA to change settings related to the patient's treatment) or non-functional data (e.g., sensor measurements). It can be characterized by functional data that Without being contradictory, data may be relayed, transmitted, etc. through any suitable mode/mechanism, and the terms relay, transmit, transfer, etc. are used interchangeably unless otherwise specified. The terms upload and download may be used in relation to the direction of data flow into (into) or (out of) a referenced system, device or other source.

Electronic information relayed between components or over a network is typically relayed in packets, which may include identification data, source data, destination data, size data, persistence information (time remaining for disposal), as known in the art and discussed elsewhere. Time to Live (TTL)), configuration data (e.g. flags), etc. Packets can be organized into “streams”. Data may also be relayed through frames/chunks or other known units/formats. Accordingly, the use of such terms may be considered exemplary herein, and such forms are generally interchangeable with or replaceable with other formats of data suitable for data transmission, storage, or both.

Terms such as “authenticated” or “authenticated” describe data or function(s) that are configured to be accessible only by a specific user, user type (class), device, or CT, and are typically defined as such data/function(s). One or more features designed to limit access (e.g., firewalls, authentication protocols such as password access restrictions, biometric access restrictions, or other forms of identification restrictions) are applied.

“Regulation” means any law, treaty, regulation, rule, guideline, code of conduct, standard, ruling or similar guidance (for example, applicable to healthcare applications, disease diagnosis, etc.). A “Regulatory Authority” (RA) is an entity that promulgates, supervises or enforces regulations. Terms such as “regulatory requirements” (abbreviated “RR”) have the same meaning as “regulations”.

Terms such as “machine learning” (“ML”) and “artificial intelligence” (“AI”) refer to the application of one or more machine learning models to information, typically the action of one or more machine learning model(s) by a computer. means any suitable method/system for effecting modification. ML/AI methods may involve managers in training, coaching, or both aspects.

In general, any method described herein can be adapted to provide a corresponding system/NDS and vice versa. Accordingly, disclosure of any method simultaneously and implicitly discloses a corresponding system capable of performing the indicated functions, and disclosure of an NDS containing an engine/module simultaneously and implicitly discloses a corresponding method comprising steps of performing the functions corresponding to the module. Starts implicitly. Thus, without contradiction, terms such as “system” implicitly mean the corresponding “system or (i.e. and/or) method” and terms such as “method” likewise refer to the corresponding “method or (i.e. and/or) system” is implicitly initiated.

The table below lists additional abbreviations frequently used in this disclosure and provides explanations for related elements.

abbreviation Terms brief explanation M.A. medical device Medical devices that relay data, including sensor data, to the system/NDS. MAG MA Group A group of related MAs in aspect(s) (e.g., controlled by the same independent entity) MZMA Multi-zone MA An MA comprising two or more operating zones, subject to separate security units/rules or different regulatory statuses, having different communication capabilities and performing different MA functions. MA-D MA data Data generated by MA and relayed to NDS NDS network data system The system of the present invention receives MA-D from a networked MA, analyzes this data, and delivers output based on the analysis to a networked MA/OND. MAC-DMS MA Control and Data Management System An NDS that controls the operation of the MA in one or more manner(s), such as changing the application of medical/diagnostic functions during operation. NDS-AD NDS analysis data That is, information generated by NDS based on MA-D. Also known as “analytics data” or “analysis.” CDSS Clinical Decision Support System (or CDS System) Units that are not regulated as SaMD and that analyze data (e.g., data within an EMR) and perform tasks (e.g., provide prompts, reminders, or information) to help HCPs implement clinical protocols, guidelines, etc. engine. DR data storage Discrete collections of stored/persistent data, for example, databases (DBs), data lakes (DLs), enhanced data lakes, and data warehouses. MLM machine learning module Engine/unit that applies ML processes, models, or analyzes to NDS function(s). NTCRM Non-transitory computer-readable media Media containing CEI that is not largely, generally, or entirely transient (“transient” meaning that it cannot be reused, transmitted, or both). CEI computer executable instructions Instructions (e.g. code) stored in PTRCRM and executed (ran) by the processor/computer. PTRCRM A physical, transportable, reproducible, computer-readable medium. A physical, transferable, reproducible, computer-readable medium. For example, a transmissible and reproducible signal with physical effects that executes function(s), flash memory, RAM, or NTCRM, but excludes transient signals. HCP healthcare provider People involved in the provision of healthcare, often through the use of MA. PHI Personal/Protected Health Information Information about patient(s) subject to one or more patient privacy law(s)/RR(s) (e.g., US HIPAA). SAMD / SaMD Software as a medical device Software intended for use for medical purpose(s) to which RR(s) applies EMR electronic medical records Electronic records containing patient-specific, medically-related data. Internet Explorer independent entity A legally separate entity (i.e., neither controls nor is commonly controlled by another referenced entity) SMAD Streaming MA-D MA data relayed in streaming fashion from network component(s) MA-CD MA cache data MA-D, at least initially stored in MA's computer memory SUMAD Semi-atypical MA-D MA-D can be characterized as semi-unstructured data SDP Streaming data processor/engine/or unit NDS component that receives and analyzes SMAD separately from other engines (e.g. analysis units/engines) SO System Owner/Operator The entity(ies) that owns or controls NDS. ONDI Other network devices (OND)/interfaces An interactive computer device or web/network interface that receives NDS-AD from a non-MA NDS. Without contradiction, ONDI is used interchangeably with OND. CRMS Customer Relationship Management (CRM) System A computer system, typically managed by an entity, specifically configured to perform functions related to managing interactions with customers of goods/services (e.g., Salesforce ^TM CRM). S/F and S(s)/F(s) Step/Function Method step(s) and function(s) of the NDS/computer unit/engine U/F Unit(s)/Function(s) The unit(s) of functions performed by the NDS or device (e.g. MA) or by the method they perform.

Table 1 - Pharmacological selection (not alphabetical)

In some cases, the description of some of these abbreviations is repeated in the following portions of the disclosure to aid readability.

The systems, methods, and devices/devices disclosed herein have many properties and aspects, including, but not limited to, those described in the Summary of the Invention (“Summary”) or specified by reference. This summary is not intended to be all-inclusive, and the scope of the invention is not limited by or limited to the aspects, features, elements, or embodiments provided in this summary. Rather, this summary is provided to illustrate the essence of the invention by providing a description of aspects that illustrate some of the key features and characteristics of these systems, methods, and devices. Any aspect of the device/system or method described in this section may be combined with any other aspect of this section or any other section.

There is a significant amount of patent disclosure related to the idea of a medical device data management system that makes both the physical and data components of a complex, integrated, modern medical treatment environment, safe, compliant, and usable by a variety of users interacting with such systems. This reflects that the development of a comprehensive and effective medical device data management and control system that can be combined, managed, and utilized in an effective manner will require the application of significant creative ingenuity. Such inventive systems and related methods are provided herein.

In one aspect, the present invention provides a computer-implemented method for controlling the operation of medical devices and other devices in a network, comprising: (1) providing a data network, the data network being (a) capable of remote control; , a collection of optionally operable, Internet-connected medical devices, each medical device comprising (I) a medical device that converts information regarding one or more physiological states into processor-readable medical device data (MA-D); one or more sensors, MA-D, for detecting one or more patient-related physiological states of any associated patient, (II) an output engine for selectively relaying data via secure Internet data communication, (III) optionally MA-D a medical device memory component containing processor-executable instructions for storing, analyzing and relaying MA-D, and evaluating the connection between the medical device and the network; (IV) a medical device processor executing the instructions of the medical device memory component; (b) a MAC-DMS, comprising: (I) a MAC-DMS that reads computer readable instructions to analyze data and perform functions, (II) a streaming data processing engine, (III) ) a MAC-DMS memory component including a cache MA-D processing engine, (IV) an analysis unit, and (V) processor executable instructions and one or more data stores, wherein the one or more data stores are configured to analyze with at least a portion of the MA-D the providing, comprising the MAC-DMS, comprising the MAC-DMS memory component, the MAC-DMS comprising an enhanced data lake for storing at least a portion of data separately and under different access conditions; (2) allowing each operating medical device to repeatedly collect sensor data from the patient; (3) allowing each operating medical device to automatically and repeatedly evaluate whether a secure network connection is available, where (a) if a secure and reliable network connection is available, data containing the MA-D is sent to the MAC-DMS; or (b) if a secure and reliable network connection is not available, (I) storing the MA-D in the medical device memory component as a cache MA-D until a secure and reliable network connection becomes available. and (II) relaying the cache MA-D to the MAC-DMS via secure Internet data communication when a secure and stable network connection becomes available; (4) The MAC-DMS processor uses the Cache MA-D processor to (a) receive the Cache MA-D when the Cache MA-D is relayed from the medical device to the MAC-DMS, and (b) receive the Cache MA-D. determining whether D is suitable for analysis by an analysis engine, storage in at least one of the one or more repositories, or both; (5) causing the MAC-DMS processor to use the analysis engine to perform one or more analysis functions on the MA-D stored in the enhanced data lake upon user request, upon the occurrence of preprogrammed conditions, or both. ; and (5) causing the MAC-DMS processor to relay one or more outputs to one or more medical devices via secure Internet communication, wherein the one or more outputs include (a) an analytical data output, (b) (I) a medical device in the data network; (II) controls the operation of one or more medical device functions on one or more of the devices, (II) the functions of one or more other network devices on one or more of the other network devices of the data network, or (III) the operation of both (I) and (II). The one or more output applications, including instructions to: (c) cause to be relayed, including a combination of (a) and (b). In more specific aspects, this method includes (1) an MA-D where the MA-D conforms to a preset semi-structured data format; (2) System/MAC-DMS includes an output engine that selectively relays data via secure Internet data communication; (3) The streaming data processing engine automatically and continuously receives and processes relayed MA-Ds from the medical device, and performs an initial analysis on the received streaming MA-Ds to determine whether one or more pre-programmed conditions are present in the streaming MA-Ds. acts as a controller for one or more of the medical device, one or more other network devices, or both by determining whether one or more of these conditions exist and, if one or more of these conditions exist, performing one or more of a limited set of preprogrammed initial functions; , the initial function includes relaying instructions to control the operation of one or more medical devices, one or more other network computerized devices, or both; (4) the analytics engine performs one or more analytics functions based at least in part on analytics data stored in the enhanced data lake, upon request from a user, upon the occurrence of preprogrammed conditions, or both; (5) the network includes at least three computerized other network devices, each different network device having (a) (I) a network device processor, (II) a network device memory component, and (III) a remotely controllable graphical user interface. and (b) is associated with a user assigned to at least one class of users, wherein the class of users is (I) a health care provider authorized to access the patient's protected health information, and (II) receiving the patient's protected health information. and a commercial user subject to restrictions, and the method further includes transmitting output to at least one other device among other network devices.

In another aspect, the present invention (1) allows an NDS to automatically and continuously receive and process relayed MA-D from a plurality of medical devices authorized to receive MA-D, and perform initial analysis on the received streaming MA-D; Determine whether one or more pre-programmed conditions exist in the streaming MA-D, and if one or more such conditions exist, perform one or more of a limited set of pre-programmed initial functions to determine whether the medical device, one or more other network devices, or Both operate as one or more controllers, the initial function of which includes relaying instructions to control the operation of one or more medical devices networked with the NDS, one or more other networked computer devices networked with the NDS, or both. a streaming data processing unit; (2) an NDS memory component containing processor-executable instructions and one or more data stores, which automatically stores at least a portion of the MA-D and stores at least a portion of the analysis data separately from the MA-D and under different access conditions than the MA-D; (a) governance rules for sorting and managing the stored data; (b) predetermined data formatting standards applicable to at least some of the stored data; or (c) ( the NDS memory component comprising both a) and (b); (3) an analytics engine that performs one or more analytics functions based at least in part on analytics data stored in the enhanced data lake, either upon user request, upon the occurrence of preprogrammed conditions, or both; (4) a cache MA that analyzes the cache MA-D when received by the medical device and determines whether the cache MA-D should be stored in the MAC-DMS memory component, analyzed by the analysis engine, or both; -D processing engine; and (5) an analytical data controller that relays one or more outputs via secure Internet communications to one or more medical devices, one or more other networked computerized devices, or both, wherein the one or more outputs include (a) analytical data outputs; (b) (I) one or more medical device features on one or more of the networked medical devices, (II) one or more other network devices on one or more of the other network devices that are networked with the NDS, or (III) (I) ) and (II) one or more output applications containing instructions that control the operation of both (e.g. MAC-DMS).

In another aspect, the present invention provides (1) a plurality of remotely controllable, selectively operable, Internet-connected medical devices, each of which (a) detects one or more patient-related physiological conditions and is capable of detecting one or more of such one or more patient-related physiological conditions; One or more sensors that convert information about a physiological state into processor-readable medical device data (MA-D), the MA-D comprising the MA-D conforming to a preset semi-structured data format. , (b) an output engine that selectively relays data over secure Internet data communications, (c) a medical device memory that optionally stores the MA-D and includes processor-executable instructions for one or more medical device computer-implemented data engines. Component, (d) a medical device processor that executes the instructions of the medical device memory component, and (e) (I) automatically and repeatedly checks for the availability of a secure and reliable Internet connection during operation, and (II) a secure and reliable Internet connection; (III) relay at least a portion of the MA-D to one or more intended recipient Internet-connected devices or systems over such a secure and reliable Internet connection, if one exists, and (III) if a secure and reliable Internet connection does not exist, a secure and reliable Internet connection; causing at least some of the MA-Ds to be stored in the medical device memory component as cache MA-Ds until an Internet connection is established or re-established, and then relaying at least some of the cache MA-Ds to one or more recipient Internet-connected devices or systems. the plurality of medical devices, including a network state engine; (2) (a) a system processor that reads computer-readable instructions to analyze data and perform functions; (b) automatically and continuously receiving and processing MA-D relayed from the medical device and performing an initial analysis on the received streaming MA-D to determine whether one or more pre-programmed conditions are present in the streaming MA-D; , if one or more of these conditions exist, acts as a controller for one or more of the medical devices by performing one or more of a limited set of preprogrammed initial functions, the initial functions being relaying instructions to control the operation of the one or more medical devices. Streaming data processing engine/engine including; (c) a MAC-DMS comprising processor executable instructions and one or more data data stores, wherein the one or more data stores automatically store at least a portion of the MA-D and have access conditions separate from and different from the MA-D; the MAC-DMS, which additionally stores at least some of the analysis data; (d) an analytics engine that performs one or more analytics functions based at least in part on analytics data stored in the enhanced data lake, either upon user request, upon the occurrence of pre-programmed conditions, or both; (e) a cache MA that analyzes the cache MA-D when received by the medical device and determines whether the cache MA-D should be stored in the MAC-DMS memory component, analyzed by the analysis engine, or both; -D processing engine; and (f) a network device controller (analytical data controller) that relays one or more outputs via secure Internet communications to one or more medical devices, one or more other network computerized devices, or both, wherein one or more outputs are: (I) analytical data; Print; (II) one or more output applications containing instructions that control the operation of one or more medical device functions on one or more of the medical devices in the data network; or (III) both (I) and (II), including the network device controller.

In another aspect, the present invention provides an Internet-based data network comprising the features described in the preceding paragraph and further comprising at least three other computerized network devices (“ONDs”), each of the other network devices being (a) ( I) a network device processor, (II) a network device memory component, and (III) a remotely removable graphical user interface, (b) associated with a user assigned to at least one user class, where the user class is (I) (II) health care providers authorized to access patient protected health information, and (II) commercial users who are restricted from receiving patient protected health information, and (II) the streaming data processing engine may optionally, when a condition is detected by the streaming data processing engine, Relaying output to one or more other network devices, the MAC-DMS relays output applications based on or including analysis data to the OND, or both.

In another aspect, the present invention provides a network according to either or both of the preceding two paragraphs, wherein the NDS/MAC-DMS is operated by one or more medical device-related entities and entities independent of the MAC-DMS-related entities. Provides access to customer relationship management, including (a) customer relationship management information, including information regarding the sale of a medical device to one or more medical device-related entities, and (b) relaying customer relationship management information to a MAC-DMS processor. MAC-DMS processor combines customer relationship management information with analytics data and relays the combined information to the end user's other network devices.

In another aspect, the present invention provides (1) a plurality of remotely controllable, selectively operable, Internet-connected medical devices, each of which (a) detects one or more patient-related physiological conditions; One or more sensors that convert information about one or more physiological states into processor-readable medical device data (MA-D), the MA-D comprising a MA-D that conforms to a preset semi-structured data format. at least one sensor, (b) an output engine to selectively relay data over secure Internet data communication, (c) a medical device that optionally stores MA-Ds and includes processor-executable instructions for one or more medical device computer-implemented data engines. a device memory component, (d) a medical device processor that executes the instructions of the medical device memory component, (e) automatically and repeatedly checks for the availability of a secure and reliable Internet connection during operation (I) and (II) a secure and reliable Internet connection; (III) relay at least a portion of the MA-D to one or more intended recipient Internet-connected systems over such a secure and reliable Internet connection, if a connection exists, and (III) if a secure and reliable Internet connection does not exist, a secure and reliable Internet connection; A network that causes at least some of the MA-Ds to be stored in the medical device memory component as cache MA-Ds until a connection is established or reestablished, and then relays at least some of the cache MA-Ds to one or more recipient Internet-connected devices or systems. the plurality of medical devices, including a state engine; (2) (a) a MAC-DMS processor that reads computer-readable instructions to analyze data and perform functions; (b) automatically and continuously receiving and processing MA-D relayed from the medical device and performing an initial analysis on the received streaming MA-D to determine whether one or more pre-programmed conditions are present in the streaming MA-D; , if one or more of these conditions are present, operates as a controller of the medical device, one or more other network devices, or both by performing one or more of a limited set of preprogrammed initial functions, the initial functions of the one or more medical devices a streaming data processing engine including relaying instructions to control operations; (c) a MAC-DMS memory component including one or more MAC-DMS implementation engines and processor executable instructions for one or more data stores, wherein (I) each data lake management zone manages a different data lake; an enhanced data lake comprising a plurality of data lake management zones associated with zone access rules, (II) a first relational database, and (III) a second relational database; (d) one or more one or more MA-D memory acquisition engines that analyze the MA-D based on pre-programmed criteria and log the MA-D to one or more data lake management areas, (e) upon the occurrence of a pre-programmed condition, upon request by a user; , or both, as the case may be, an analytics engine that performs one or more analytics functions based at least in part on analytics data stored in the enhanced data lake; (f) analyzing analysis data based on one or more pre-programmed conditions and based on such pre-programmed conditions (I) analysis data generated directly from the MA-D of a first relational database, (II) a second relational database; analytic data generated from data contained in the enhanced data lake, and (III) an analytic data memory ingestion engine that records the analytic data in one or more data lake management areas of the enhanced data lake, (g) ingested into a first relational database. a data store inspection engine that collects information about the data being collected, the data being collected in a second relational database, or both, and relaying such information to one or more graphical user interfaces accessible by one or more system administrators; and (h) A network device controller that relays one or more outputs via secure Internet communications to one or more medical devices, one or more other networked computerized devices, or both, wherein one or more outputs include (I) analytical data outputs; (II) (A) the functionality of one or more medical devices on one or more of the medical devices on the data network, (B) one or more other network devices on one or more of the other network devices on the data network, or (C) (A) and (B) one or more output applications containing instructions that control the operation of both; or (III) a combination of (I) and (II).

In another aspect, the present invention provides a method of treating a medical condition of a patient in a patient population, the method comprising: (1) providing a data network comprising a MA and an NDS/MAC-DMS, each of which With the features described in previous aspects of this section, the steps of: (2) causing each medical device in operation to repeatedly collect sensor data from a patient associated therewith; (3) automatically and repeatedly evaluating whether each medical device is capable of a secure network connection, and (a) if a secure and reliable network connection is available, transmitting data containing the MA-D via secure Internet data communication; (b) if a secure and reliable network connection is not available, (I) medically relaying the MA-D until a secure and reliable network connection becomes available; (II) storing the cache MA-D in the device memory component, and (II) relaying the cache MA-D to the MAC-DMS via secure Internet data communication when a safe and stable network connection is available; (3) The MAC-DMS processor automatically uses the streaming data processing engine to (a) receive relayed streaming MA-D from medical devices, and (b) provide information about the relayed streaming MA-D received from each medical device. performing an initial analysis, and (c) if the initial analysis identifies one or more pre-programmed conditions in the streaming relay MA-D, causing it to perform one or more of a limited set of pre-programmed initial functions, wherein the initial functions are one or more the steps comprising relaying instructions to control the operation of a medical device, one or more other network devices, or both; (4) The MAC-DMS processor uses the Cache MA-D processor to (a) receive the Cache MA-D when the Cache MA-D is relayed from the medical device to the MAC-DMS, and (b) receive the Cache MA-D. determining whether D is suitable for analysis by an analysis engine, storage in at least one of the one or more data stores, or both; (5) causing the MAC-DMS processor to automatically store at least some of the MA-Ds in the enhanced data lake; (6) cause the MAC-DMS processor to use the analytics engine to perform one or more analyzes on at least a portion of the analytics data stored in the enhanced data lake upon request by a user, upon the occurrence of preprogrammed conditions, or both; As a step, the analysis engine (a) performs the analysis using the analysis data generated from the medical device by the MA-D when performing the analysis, and (b) analyzes the MA-D of each medical device using (I) the previously collected data. Comparing the MA-D analysis data, (II) to a preprogrammed standard, or (III) to both (I) and (II); (7) causing the MAC-DMS processor to relay one or more outputs via secure Internet communication to one or more medical devices, one or more other network devices, or both, wherein one or more outputs are (a) (I) related to a patient; a medical device, (II) another network device related to healthcare provided in connection with a patient, or (III) output analytical data related to the patient's care relayed to both (I) and (II), (b) (I) ) the functionality of one or more medical devices on one or more of the medical devices in the data network, (II) the functionality of one or more other network devices on one or more of the other network devices in the data network associated with the healthcare provider associated with the patient, or (III) (I) and (II) one or more output applications comprising instructions to control the operation of both, or (c) a combination of (a) and (b).

In another aspect, the present invention relates to (1) a high security area comprising a collection of directly interoperable components, wherein the high security area (a) in operation applies medical treatment to a patient and, through received electronic control instructions; (b) one or more controllable treatment components, (b) a high security zone memory component comprising a computer-readable medium containing instructions for a plurality of computer implemented instructions to control the operation of one or more high security zone components, (c) one or more high security zone components. a computer processor component that executes computer implemented instructions contained in a high security zone memory component to transmit electronic instructions to one or more therapeutic components to control the operation of the therapeutic components, (d) (I) (i) a media zone component and (ii) receive electronic communications from local physical inputs, and (II) analyze communications received from mid-zone components to ensure that only communications that comply with one or more validation standards can control the operation of high-security zone components. (III) a communications component that relays electronic communications to (i) a mid-zone component and (ii) a local medical device output, and (e) limits access to the high-security zone memory component to authorized users only. (f) a high security area, wherein the high security area lacks any capability for direct Internet communication; and (2) a medium security zone comprising a second collection of interoperable components, wherein the medium security zone component is configured to: (a) (I) the performance of one or more treatment components in the high security zone, (II) one of the patients involved; or (III) one or more sensors measuring one or more physical conditions of both (I) and (II) as medical device data (MA-D), (b) (I) one or more medium security areas; (c) a computer-readable medium containing instructions for a plurality of computer-implemented instructions that control the operation of the component, and (II) an intermediate security zone memory component containing a component for storage of the MA-D, (I) secure and A network health engine that evaluates whether reliable Internet gathering is possible and (A) if such a connection is possible, (i) relays the MA-D to one or more intended Internet recipient devices and (ii) one or more remote control devices via secure Internet communications; (B) a network state engine, which stores the MA-D as cache data in the middle zone secure memory component, if such a connection is not possible, and (II) receives data from the remediation component and remedies it. A medical device (MA) comprising a medium secure area comprising a computer processor component executing computer implemented instructions contained in a medium secure area memory component comprising an inter-device communication engine sending electronic instructions to the component.

Exemplary embodiments of the invention are illustrated in the drawings provided with this disclosure. These aspects depicted in the drawings are described briefly in this section and in more detail elsewhere. Without being contradictory, features/steps illustrated in any figure may be combined with element(s)/step(s) of any other figure(s). The drawings should be viewed generally in component form of the overall embodiment(s) of the invention, but it should be understood that not all features illustrated are necessary for each embodiment.
1 shows a simplified network connection between a medical apparatus (MA) and a Network Data System (NDS/system).
Figure 2 is an overview of a simplified network of MAs and their relationships to NDS according to one example embodiment.
3 is a simplified layout of the MA network level including data communication to the NDS and several MA subnetworks identifiable by MA group according to an example aspect.
4 is an overview of an example process for processing MA data collection in offline periods according to one aspect.
Figure 5 provides a description of a scenario further illustrating the collection and possible processing of cache data, according to one embodiment, with reference to example physical components and locations.
6 illustrates a MA/NDS network including a MA network, NDS, and ONDI according to an example NDS/method.
7 provides an example data management process within a network system memory unit according to one aspect.
8 illustrates applying different data zones to an NDS data storage/memory unit (eg, enhanced data lake), according to one aspect.
9 provides an overview of an example network including a MA group and an NDS, illustrating physical device components operating within the network according to one embodiment.
Figure 10 illustrates data flow and processing within an exemplary network of the present invention.
11 illustrates a data processing method that can be used in components of a multi-zone medical apparatus (MZMA).
Figure 12 provides an overview of the components of MZMA in a network with NDS according to aspects and illustrates data flow management through these components.
13 illustrates an example data flow from NDS through another example MZMA.
14 illustrates selected physical components of an MZMA and data control within an example MZMA.
15 illustrates example physical components of an example MZA and data flow control between the MZMA and NDS.
Figure 16 illustrates a secure process for updating the operating system or other software of the MZMA portion through step-by-step data exchange with the MZMA and NDS components.
Figure 17 illustrates a network consisting of MAs in different operating states relaying and receiving functional data from the NDS.
18 is an example of the relationship of various user entity interfaces receiving analytics data from NDS (NDS-AD) through a special user class display including user classes classified into NDS-AD.
Figure 19 is a schematic diagram reflecting the application of different but overlapping NDS architectures for different regions/countries.
Figure 20 shows an overview of MA data processing over time and according to time-dependent rules.
21 illustrates the application of various user class-level and individual user level event alerts/alarms in an example network.
Figure 22 shows an example network including several machine learning modules (MLMs) managed by a master MLM.
Figure 23 illustrates data flow into, within and from the streaming data processor component of the System/NDS and optional processing and analysis of streaming data prior to ingestion into NDS memory.
Figure 24 is another example network showing data flow through various parts of the network, including two relational databases forming part of the NDS data store, each subject to a data quality monitoring dashboard.
Figure 25 is an example of a semi-unstructured dataset containing device performance data that can be relayed from MA to NDS.
26 is another example dataset containing patient sensor data.
Figure 27 is an additional example semi-unstructured dataset containing device (MA) alarm (performance) data.
Figure 28 is an additional example semi-unstructured dataset containing MA system/software information.

For convenience, key features/portions (e.g., method steps/functions and system units) are not only described individually in this section, but are sometimes described in combination with other aspects, features, embodiments, elements, etc. As indicated elsewhere, any particular aspect, embodiment, function, feature or unit may be combined or applied to any other aspect, embodiment, etc., or, where appropriate, any described step, aspect, element, etc. may be replaced. Aspects, stages, characteristics, etc. can be replaced.

In one aspect, the present invention relates to a system (respectively, a “network data system” (NDS)) comprising modules, units, engines or components that perform the functions of such modules, units, engines or components, and /Securely receive, analyze, store, manage, and apply machine apparatus data (MA-D) from multiple MAs in a data network with NDS, and generate analysis data from these MA-Ds (NDS-AD) and relaying the relevant output to such NDS-AD or MA, other network device (OND), or both, generally via secure Internet communication. In aspects, these associated outputs include output application(s) that control one or more aspects of MA operation, OND operation, or both (if the NDS is MAC-DMS). For example, output may include registering an alarm on the MA/OND, changing the graphical display of the MA/OND, or changing the therapeutic or diagnostic component(s) of the MA with which the subject interacts. In aspects, the MA in the network includes a multi-zone MA (MZMA) that includes separate components under separate performance, security, or communication settings with different zones of the device, such that the MZMA can be configured to communicate over the Internet. Facilitates device security when communicating with NDS. In aspects, the MA collects cache data (MA-CD) under certain conditions, such as when Internet communication is not possible, and then relays the MA-CD to the NDS, which determines whether the MA-CD should be stored in the data store of the NDS. , determines whether it should be used to create an NDS-AD, or both.

In aspects, the NDS performs real-time (“RT”) or near-real-time (“NRT”) function(s) associated with such MA-Ds and MAs, generally to facilitate medical treatment through or in connection with such MAs. Do, promote or perform. In aspects, the NDS may access separately located and at least partially remotely controllable MA group(s) and data therefrom. In aspects, a method includes collecting data transferred from such MA group(s) (“MAG(s)”), storing data from such MAG(s), and storing data transferred from such MAG(s). Analyzing or evaluating to generate an analysis (NDS-AD), and executing function(s) based on this analysis. In aspects, the function(s) may provide NDS-AD, instructions, or both to network component(s), such as the MA(s) of the MAG(s), other device(s) of the network (ONDs), or both. Includes communication. MA in a network is generally repetitive and often substantially continuous communication with a system (NDS), facilitated through commonly known or described secure Internet-based communication methods.

In aspects, the MAG of the network with the NDS is 2 or more (e.g., 3 or more, 5 or more, 7 or more, 10 or more, 12 or more, 20 or more, 30 or more, 50 or more) or approximately 100 or more independent entities (IEs), where the NDS identifies each entity associated with each MA, executes MAG-specific instructions, separates data based on MAG associations, or a combination thereof (CT). Includes the ability to identify communications with each specific MA in the network and relay data.

MA collects data regarding the diagnosis or treatment of a subject's disease. For example, the MA may include sensor(s) that collect sensor data (including measurements of physical phenomena such as device performance, patient physiological state, or both) during operation. This “sensor data” is a component of data collected by the MA (i.e., MA data (or “MA-D”)). The MA also typically has (1) device/local memory (including physical, transferrable, and reproducible computer readable medium (PTRCRM)) and (2) the MA stores the MA-D, relays/transmits the MA-D, or or a processor/processing function/unit for executing the device CEI, which may include functions for performing both. MA-Ds that are stored at least occasionally in these MA local memories are also referred to as "cache data", even if such data is later relayed from the MA to the NDS.

The MA in the network may include device display unit(s) (e.g., including graphical user interface(s) (GUI(s)) or other interface/output device/component). In aspects, the output of the NDS for the MA depends on the class of user(s) associated with the MA.

The MA in the network typically includes data relay unit(s) that transmits the MA-D from the MA to the NDS. In aspects, in operation the MA(s) sometimes, most of the time, usually all the time, or substantially always, stream (or stream and real-time) time MA data (“streaming MA-D” or “SMAD)”. is collected and relayed to NDS. Like other MA-Ds, SMADs may include MA sensor data, device performance data, device identification data, patient identification data, or combinations thereof). In aspects, cache data, when relayed, is also relayed as a data stream. In aspects, cache data is transmitted with real-time (RT) SMAD (“RT-SMAD”). In aspects, cache data may be relayed separately from RT-SMAD.

MA-D can contain semi-unstructured, structured or unstructured data. In aspects, some, most, or at least generally all of the MA-D relayed by the MA includes semi-unstructured data. In aspects, using semi-unstructured data measurably or significantly improves the speed of the NDS, the uptime of the NDS, or both (e.g., by reducing the incoming data load/processing burden).

In aspects, some, most, generally all, substantially all, essentially all, or all of the MA-D is sensor data. In aspects, some, most, generally all, or all instances of the MA-D include additional data (non-sensor data). In aspects, the MA-D includes device status/performance data (data regarding one or more aspects of MA operation/operability, such as power state, pump speed, etc.). This data may be referred to as “device data.” In aspects, most, generally all, substantially all, essentially all, or all of the MA-D is sensor data combined with device performance data or other device data. In aspects, some, most, generally all or all device performance data provides indirect information about the patient condition (e.g., movement of the device or device component, such as rotation, device pressure, etc.) may provide indirect information about one or more programmed physiological parameters of the patient).

The MA in the network may use security feature(s) such as incoming data security units, physical tamper-evident detection or blocking measures, etc. to ensure that only authenticated information can modify the MA operation(s). These components are known and discussed elsewhere.

In operation, the MA relays data to the NDS/System some of the time, most of the time, usually all of the time, or practically all of the time. In aspects, in operation, most of the time, generally all the time or substantially all of the time, the MA(s) are in substantially continuous communication with the NDS via the Internet or other WAN/SDWAN connection.

An NDS typically includes (1) an NDS memory unit/component (“Memory”) containing a PTRCRM containing data stores (DR(s)) that receive and store MA-Ds, and (B) read NCEIs; /executes (2) NDS CEI (NCEI) containing encoded/pre-programmed instructions for the functions (engine) performed by the NDS processor (2). The NDS(s) may be configured to, for example, (3) NDS data input units/engines (e.g., selectively and automatically receive data from MAs (and generally (4) NDS analysis unit(s)/engine(s) (e.g., MA-D and an engine that analyzes possible other input(s) and uses this analysis to direct the performance of the NDS application(s)/function(s) (e.g., via controller function(s)), (5) MA -An NDS data evaluation unit/engine that evaluates whether the D is approved for use by an analysis function or determines how the MA-D may be used by such a function (and, optionally, one or more data harmonization) (6) pre-programmed factors/rules (e.g., based on confidentiality and healthcare compliance rules, MA and other network devices and interfaces); ; ONDI), an NDS output engine/unit/processing system to automatically filter MA-D, analysis, or both, and (7) an NDS data relay unit/engine. The NDS data relay engine/unit may generally provide (A) information about the MA that is specific to such MA, the patient involved, or both, and is generally adaptable to receive via the security unit of such MA; and (B) Securely relays information, including MA-D, analysis, or both, to one or more other network devices/interfaces (ONDI) over the Internet. Optionally, NDS can perform (8) identification of cached data, analysis of cached data; or may further include an NDS cache data analysis function that includes special instructions for processing cache data and generates a cache NDS analysis based on application of the functions to data stored in the NDS memory/DR(s), for example. there is. In aspects, the cache data complements RT-SMAD; RT-MMAD reconstructs missing or missing data streams; It is used to verify incomplete, suspicious, or damaged RT-SMAD.

In aspects, some, most, typically all or all of the MAs in the network are mobile MAs that may occasionally lose connectivity to the network (e.g., the Internet) and thus cannot be relayed to the NDS by an RT-SMAD (SMAD). You can have a period of time. In aspects, analyzing both SMAD and cache data allows for DOS improvement of subject care.

Data related to ONDI may include, for example, information from multiple MAs associated with two or more Independent Entities (IEs) or NDS-ADs derived from MAs owned/controlled by two or more IEs. In aspects, this information may be combined with an information external system/data repository, such as CRM.

NDS typically includes ONDI, MA, and other devices/interfaces ( e.g., an accessible web portal) or a combination thereof. These features also allow NDS/methods to be applied simultaneously to multiple types of MA, multiple patient states, multiple patient types, and multiple MA states, thereby increasing the robustness of the application of these NDS/methods and the data derived from and by these systems. expands (e.g. when simultaneously collecting data from study classes of individuals/groups and patients in clinics) and further allows application of these NDSs/methods at national and even international levels. The facilitation step(s)/function(s) performed/included in the method by the NDS may also include data queuing and prioritization methods (applied to inbound/terminated MA-D, as discussed elsewhere). You can.

Data in DR in NDS can be subject to multiple “levels” of identification, management, security, and access based on data characteristics. NDS' functional data/CEI can be used to filter, modify, direct, and otherwise manage the distribution of data generated or received by NDS (e.g., exclude PHI from data provided to commercial users such as device salespeople). and to ensure compliance with regulatory requirements (RR). In aspects, the NDS may output different NDS-generated data sets (analysis data/analysis or NDS-AD), MA-D, output based on NDS-AD/MA-D, or a combination thereof. Can be delivered simultaneously to the MA and various other network devices/systems, including devices assigned to users/classes. In aspects, the data relayed by the NDS depends on the RR and user needs/roles applicable/related to different roles/classes of users. In aspects, the NDS accommodates multiple individual or class level alarms/alerts set at the local/user level, NDS/class level, or both.

A network's MA may include one or more protection features against unauthorized modification or tampering. For example, in aspects, the MA includes tamper-resistant component(s)/system (e.g., engine, sensor, etc.) that limits/inhibits or stops MA performance when tampering is detected. In aspects, the MA may include a sensor that registers or relays an alarm (e.g., by registering a physical auditory, visual, or audiovisual alarm with the MA; by sending an alarm message to NDS, ONDI, or both; or a combination thereof); Includes components, engines, systems, etc.

In aspects, the MA is characterized as a “multi-zone MA (MZMA),” comprising a set of two or more components or systems with different levels of interaction with the network, different levels of interaction with the patient, or different levels of device security. (e.g., the MZMA may include a first therapeutic component, a first zone comprising components involved in critical care/life support functions, such as cardiovascular or pulmonary life support/therapy functions, It is more limited in terms of incoming data than the second component, which may for example be involved in other types of therapeutic applications or diagnostic/monitoring applications).

In aspects, the MA may be directly controlled by the NDS (MAC-DMS) in one or more aspects, such as directly applying medical therapy, displaying a course of treatment for the HCP, or providing a recommended course of treatment for the HCP.

The NDS may include a machine learning module (MLM) for each type of device, condition treated, patient type, etc., and in aspects, a master MLM(s) for managing multiple overlapping MLMs for the patient(s). ) may further be included. In aspects, the NDS/method provides a relationship between the MA's data upload and the performance of an analytics function, such as an MLM, such that, for example, (1) it takes (2) There are typically more (e.g., 5 or more, 10 or more, or 25 or more) data collection cycles that contribute to analyzable data collection performed in a period, and (2) can be repaired or otherwise compensated for by the NDS. There is a step(s)/function(s) to restart the data collection cycle's contribution to data collection if a problem is detected in the missing data collection cycle.

Additional aspects of these and other features of the systems, networks, and methods of the present disclosure are described in particular detail in the following sections of the disclosure.

A. Medical Devices (MA) and MA Group (MAG)

A network may contain multiple group(s) of MAs (sometimes called a network), with each MA group ("MAG") containing one or more types of MA(s), with each type of MA typically operating When associated with more than one type(s) of patient/subject, type(s) of treatment/diagnosis/application, or a combination thereof.

In aspects, the network includes five or more MAs in communication with an NDS, and in aspects the network includes a network in communication with an NDS (one or more, two or more, three or more, five or more MA types). 20+, ~100+, ~200+, ~500+, ~1000+, ~5000+ MAs (MA units) (e.g. 100-1000 MAs, 100-10,000 MAs, or 100-100,000 MA).

In aspects, the network includes two or more MAGs (e.g., 3 or more, 5 or more, 7 or more, 10 or more, 12 or more, 15 or more, 20 or more, 25 or more, 35 or more or 50 or more MAGs), each MAG comprising, for example, ~5 or more MAs (e.g., 10 or more, 20 or more, 25 or more, 50 or more, or 100 or more MAs) . In aspects, some, most, generally all, substantially all or all of the MAGs may have primary control of an independent entity (IE) distinct from the system owner/system operator. It is under. In aspects, the network may be comprised of five or more MAGs (e.g., 5-100, 5-100, 50 or 10-40 MAGs). “Primary control” means ultimate responsibility for the operation of the MA (e.g., by owning ownership of the MA, assuming responsibility for the treatment/diagnosis of the subject(s), or both) do.

In aspects, SO is the owner of the NDS. In aspects, the SO is operated by an operator entity or individual. In either case, the SO may employ people to manage aspects of the NDS, who may be referred to as “administrators,” “administrators,” “system administrators,” etc. In aspects, one or more IEs associated with the MAG allow the SO to receive data from the MA, control aspects of MA operation, or both. In aspects, the MA, NDS, or both are provided with electronic contract function(s) including, for example, means for establishing such access rights. In aspects, this electronic contract functionality is programmable and updateable.

In other aspects, some, most, typically all or all entities that own an MA in the network retain complete control over the MA but are authorized by the SO to use the NDS (and typically the SO may use the NDS). Grant SO permission to access IE-related PHI, such as MA sensor data, to enable operation).

In aspects, some, most, typically all or all of the MAs in the network are MAs initially controlled by the SO (e.g., manufactured or sold/granted/transferred to the current IE owner by or for the SO). is MA). In some of these aspects, the SO-imposed functionality in terms of NDS interactions in the MA is established prior to transfer of ownership (e.g., the ability to collect or transmit data in one or more of the standards described herein) and is established over a majority of the network, typically All, substantially all or all are maintained in MA. These aspects allow for specific configurations of elements (e.g., most, generally all, or substantially all MA-D, NDS-AD, etc. formats). However, in other aspects, this functionality is also or alternatively accomplished by IE grant(s) of authority to the SO to control aspects of MA operation. In aspects, the operational component is achieved by both measurements (e.g., the SO sets the initial configuration when taking possession of the device, but must later update it according to IE permissions).

The connection of MAs owned/managed by separate IEs (each other) generally ensures that the confidentiality of the MA-D obtained from the MA associated with each other IE is protected from access by users associated with the other IE (as well as other unauthorized imposes additional data management requirements (ensuring that it is not disclosed to unauthorized entities/individuals). Accordingly, the NDS associated with these multiple IE-owned MAGs may include protocols at the MA and NDS levels where MA-Ds and NDS-ADs derived from different IE MAGs are identified as being associated with the applicable IE. Methods for “tagging” data are known and described elsewhere. These methods can, for example, send packets to a MA-D that identifies the source of the MA at one or more levels (such as a specific device level, device type level, device capability state level, IE level, or other levels such as region or district level). May include adding information. In aspects, an engine, unit, or function applied/performed at the device level, system level, or both, may also be provided to each MA to which it belongs (e.g., hospital care group, hospital, hospital system, town, metropolitan area, county, state/ Other levels of association that can define MAGs (such as fat, etc.) are also identified.

In aspects, the MA(s) in the network may exist as standalone medical device(s) (e.g., independent medical devices). In aspects, two or more MAs form a MAG that describes some of the MAs of the network. A MAG can define a location (e.g., a site), a subnetwork (e.g., an entity MAG, such as a hospital or clinic network), or a geographic location (e.g., a city, county, state, region, country, or continent). MAG), or, for example, by a patient group (e.g., a patient group containing patients diagnosed with a shared condition). In aspects, the MAG may be modified after initial creation. For example, one or more MAs may be added or removed from a group, or one or more MAs may be transferred from one MAG to another MAG. In aspects, a MA may belong to MAG 2, 3, 5, or MAG, for example, where multiple MAG categories are described in the network (e.g., a MAG defined by a MA owned by an IEX, area may belong to the MA of Y, or both if these MAGs overlap). In aspects, the characterization/grouping of MA(s) may vary over time and in real-time, such as grouping of MAs based on patient status, e.g., groups of patients sharing one or more physiological parameters in common. , these parameter(s) change over time and thus the grouping of related MAs changes over time. In aspects, one or more MAs may belong to multiple collections (e.g., belong to both a site group and a patient group) at any single point in time. To identify MAs from MAG(s), NDS is a protocol for associating each MA with its associated MAG(s) based on MA-D, which reflects the behavior of the MA, associated subjects, location, IE family, MA type, etc. /Can contain a CEI containing rules. For example, the MA could add this information to the MA-D and the NDS could include a CEI that specifically identifies this information. In aspects, this information may be identified as a type of attribute/value pair in a semi-unstructured MA-D.

In aspects, each MA in the network can be controlled at least partially remotely; That is, in some respects most, typically all or each MA may be connected to a device from a location that is remote/non-local to the device, such as a Network Data System (NDS), other network interfaces/devices (e.g., HCP devices, IE has at least one function, at least about 2, at least about 3, at least about 4, or for example at least about 5 functions, which can be operated from the administrator interface or both or other ONDI(s) .

In embodiments, some MAs in a network may be classified as fixed appliances or devices (e.g., MAs that, once established, typically or substantially always operate at a single location). In aspects, some, most, generally all, substantially all, or all MAs in the network are mobile medical devices. Mobile MAs are designed to be mobile in healthcare environments such as hospitals, ambulance care, etc., e.g. suitable for light mobility and portability (e.g. wheeled push devices, handheld devices, robotic mobile devices, vehicle-based devices, etc.). is an adaptable, structured, and ready MA. In aspects, the mobile MA(s) include wireless Internet or another type of wireless Internet access/telemetry functionality (e.g., the ability to transmit data over a cellular network, Bluetooth, etc.). In aspects, the network may include a combination of fixed and mobile MAs. In aspects, some, most, generally all or all mobile MAs relay MA-Ds only to the NDS most of the time, generally all the time or via a wireless secure Internet communication protocol such as Wi-Fi.

A network may include one or more types of MAs of any suitable type(s). In aspects, some, most, generally all, substantially all, or all of the MAs are critical care MAs. In aspects, MA supports maintenance of the cardiovascular, pulmonary, nervous or gastrointestinal systems or organs such as heart maintenance, lung maintenance, liver maintenance, kidney maintenance, etc. In aspects, the MA comprises a heart pump. In aspects, the MA comprises an extracorporeal membrane oxygenation (ECMO) device. In aspects, the MA of the network includes both ECMO and cardiac pump devices.

According to aspects, the MA includes two or more heterogeneous types of MA. In aspects, the NDS may be used by each MA-D when uploading data from an MA, when downloading data to an MA, or both (e.g., by reading the device type that identifies the MA-D relayed by each MA-D). The MA determines the device type involved. According to aspects, heterogeneous MAs may share one or more characteristics in common, such as a primary medical purpose (eg, cardiovascular or pulmonary support). In aspects, at least some, most, or generally all of the heterogeneous MAs of the network provide unique functions, such as support of other organs or physiological systems (e.g., cardiovascular, pulmonary, or nervous system support). In aspects, the heterogeneous MAs may each provide a MA-D associated with one or more of the same measurement elements, such as a specific physiological parameter(s) (e.g., blood pressure, heart rate, etc.). According to aspects, the heterogeneous MA provides a MA-D for shared physiological parameter(s) such that the MA-D resulting from such a device is also at least partially in a shared/common format (e.g., a semi-atypical MA-D). D contains similarly formatted value/attribute pairs for blood pressure, oxygen level, heart rate, etc. According to an alternative aspect, the heterogeneous MA also or alternatively provides MA-D for the shared physiological parameter(s) in different formats. In such cases, data harmonization can be performed in the NDS using known methods to “integrate” MA-data from different types of MA to produce a combined NDS-AD. These processes are discussed in more detail elsewhere.

MA can be associated with all types of medical procedures, medical workflows, etc., and can, for example, provide intervention or monitoring support for any medical condition. In aspects, the MA may be a component of an outpatient related medical device. In aspects, the MA may be a device designed to be operated by trained medical personnel within an existing medical facility, such as a hospital or clinic. In aspects, one, some, most, generally all or all MAs of the MA network are associated with critically ill life support, such as supporting functions of the cardiovascular system (heart), pulmonary system (lungs), brain, or kidney(s). . In certain aspects, at least most of the MAs in the network are associated with critical life support functions (e.g., respiratory, cardiovascular, or neurological support/treatment). In aspects, the MA is an implantable medical device. In aspects, the MA is a medical device that resides within the cardiovascular system, pulmonary/respiratory system, brain, or kidney(s) of the subject(s) during operation. In more specific aspects, the one or more MA(s) is an implantable medical device that is implanted in the heart, such as a device similar to one of the known Impella® heart pump devices (Abiomed, Inc.). In other aspects, the MA is a device that includes components placed internally in the subject or interfaces with components implanted therein but includes external components, such as the Breethe OXY-1 system (Abiomed, Inc.). In aspects, the network includes a heart pump and ECMO (eg, Impella® and Breethe™ devices).

In aspects, most, generally all, substantially all, or all MAs in the network are in substantially continuous communication with the NDS during operation. For example, in aspects, the MA of one or more group(s) in the network is averaged at least about 50% of the time, at least about 65% of the time, at least about 75% of the time, at least about 80% of the time, at least about 85% of the time, and about 90% of the time. is in continuous communication with the NDS for at least 92.5% of the time, at least about 95% of the time, at least about 97% of the time, at least about 98% of the time, or even at least about 99% of the time, daily, weekly, monthly, quarterly, or annually. In aspects, the MA is active at least about 50% of the average time, at least about 65% of the time, at least about 75% of the time, at least about 85% of the time, at least about 90% of the time, at least about 95% of the time, or at least about 97% of the time, or at least about 98% of the time. More than %, or even about 99% or more, is a mobile MA that transmits RT-SMAD to NDS via wireless communication protocol on a daily, weekly, monthly, quarterly or annual basis.

In aspects, “continuous communication” means less than every minute (e.g., less than every 30 seconds, less than 15 seconds, less than 10 seconds, less than 5 seconds, less than 2 seconds, less than 1 second, less than or equal to every 0.5 seconds). refers to the upload, download, or both upload and download of an analyzable/actionable amount of data for a period of time (less than or equal to ~0.25 second or ~0.1 second or less). “Substantially continuous” communication means that the MA achieves this level of communication almost all of the time it is in operation (i.e., at least 95% of the time it is in operation). In aspects, substantially continuous or continuous communication includes, generally consists of, essentially consists of, or consists of streaming communication (discussed elsewhere). An “analyzable/actionable” amount of data refers to an amount of data sufficient to perform one or more analytical functions/processes, one or more operational functions (e.g., controlling the operation of one or more other components of the network, such as MA(s), etc.) it means.

In exemplary embodiments, the MA includes at least two different MA types, wherein the MA type includes a first type of medical device that performs pulmonary treatment task(s) and a second type of medical device that performs one or more cardiovascular treatment task(s). 2 types of medical devices, wherein the operation of the NDS includes a machine learning module (“MLM”) on the MA-D received from both the first type of medical device and the second type of medical device to generate a machine learning generated NDS-AD. ) includes applying. In aspects, the machine learning NDS-AD includes predicted patient-specific physiological parameters related to therapeutic tasks performed by the MA(s). In aspects, the NDS automatically or conditionally distributes these predicted patient-specific physiological parameters to MA(s) of one or both of two different MA types, to another network device (OND), or to a combination thereof. It is pre-programmed to deliver.

In aspects, the user includes research user(s), and one or more MA(s), OND(s), or both in the data network are associated with one or more research user type(s). In these aspects, the NDS/MAC-DMS may, for example, receive input from the MA(s) associated with the study user(s), and (b) the MAC-DMS may respond to the MA(s) of at least some of the study users associated with the MA(s). D can be combined with MA-D obtained from a medical device associated with a healthcare provider to form a mixed data set, and (c) MAC-DMS can perform analysis/analysis functions on the mixed data set. In aspects, this mixed data or mixed data function/application (or research data/research data application output(s)) is specifically identified upon output separately from other NDS-AD/output(s). In aspects, such output is provided only to user devices associated with the study class user(s) (e.g., researchers participating in a clinical trial). In aspects, other user(s), such as practicing HCP(s), may choose to receive output, analysis, etc. based on composite data, purely on study data, or both. Such identification may be accomplished through packet/data tagging, as known and described elsewhere herein. For example, in aspects, the NDS includes a CEI for adding such tag(s) and the MA(s)/OND(s) includes a CEI for identifying such tag(s).

I. MA Subject/User Interaction Component

The MA is capable of interacting with users/subjects, such as collecting data from subjects via sensors, collecting data from users via direct data input into the MA or associated user interface, applying treatment to subjects, providing treatment direction to HCPs, monitoring/diagnosing (detection) of conditions, etc. It may be characterized as being based on a component that interacts with.

One. sensor

In aspects, some, most, generally all or all MAs of the network include sensor(s), are associated with sensor(s), or both. Sensor(s) is typically a device(s) in a device(s)/system(s) that senses condition(s) related to a patient's physiological state, device performance/state, other physical state, or a combination thereof. It is component(s). Sensor(s) may include, for example, a sensing component/device that detects subject-related physiological state(s) and converts information regarding such physiological state(s) into processor-readable data (MA-D). there is. As discussed elsewhere, a variety of sensor technologies are known and applicable to aspects.

In aspects, one, some, most, generally all or all sensor(s) of or associated with the MA or one or more type(s) of MA(s) are sensors that are in contact with the body, such as wearable sensors. In aspects, one, some, most, generally all or all sensor(s) of or associated with the MA may be deployed, for example, in an organ, blood vessel, lung or other internal tissue/system of a patient to detect the patient's condition. , is an internal sensor.

A sensor associated with a MA may be a sensor that is separate from the MA but relays information about the MA, the patient with which the MA is associated, or both to other device(s) or network(s) that can be reviewed by the MA or the user.

The sensor(s) may be any suitable sensor(s) known in the art, and typically the characteristics of the sensor(s) associated with the subject will determine the extent to which the subject's condition is to be prevented, treated or diagnosed through the MA(s). It will vary depending on the characteristics. Examples of sensors include pulse oximetry monitors, respiration monitors, temperature monitors, blood oxygen monitors and other oxygen level monitors, heart rate monitors, blood pressure monitors, arterial pressure monitors, brain activity monitors, response monitors (e.g., response monitors), and capnography. Monitors, blood flow sensors, blood/tissue/urinary glucose monitors, biosensors (e.g., pathogen biosensors), other urine monitors, other fluid monitors, position monitors, movement/motion monitors/accelerometers, electromyography (EMG), spirometers, and others. Included are airflow monitors, electroencephalograms (EEG), other electrical vital signs monitors, gas exchange monitors, force sensors/inertial sensors, sleep monitors, skin condition monitors, electrocardiogram monitors, and any other physiological or health monitors known in the art. . In aspects, the sensor(s) may also sense ambient/environmental data. Examples of sensors are for example Wilson CB, accessed at https://encyclopedia.pub/2084. Sensor 2010. BMJ. 1999;319(7220):1288. doi:10.1136/bmj.319.7220.1288 and Sergio L. Stevan, "Sensors for Health Monitoring", described in the Scholar Community Encyclopedia. Sensors typically include a computer interface that converts sensor readings into measurement value(s) that can be relayed to a computer processor using common device data relay standards or other data relay standards.

In aspects, the MA(s) may include sensor(s) (e.g., ultrasound and MRI machines, PET and CT scanners, and Diagnostic MA(s) may be classified as diagnostic MA(s) that interact primarily, substantially only, or solely with the subject (including, for example, cameras), probes, and other sensor-based devices).

In aspects, the MA(s) is a therapeutic device that includes sensor(s) in addition to therapeutic component(s). In aspects, one, some, most, generally all, substantially all or all sensor(s) in the treatment device are associated with provisioning/attempted provisioning of a treatment effect related to device performance. In aspects, the MA will include one or more sensors that detect at least one condition of the patient when the MA-D is operating. In aspects, each MA comprises at least about 2, at least about 3, at least about 5, at least about 8, or at least about 10 sensors, such as at least about 15 or at least about 20 sensors; , at least about 2, at least about 3, at least about 5, at least about 8, at least about 10 conditions (e.g., physiological parameters), for example, at least about 15 or at least about 20 conditions. Alternatively, parameters, e.g., ~30 or more, 40 or more, or 50 or more conditions/parameters may be detected.

2. treatment component

In aspects, the MA(s) comprise therapeutic component(s). A “therapeutic component” is a MA component(s) associated with causing, promoting or maintaining a therapeutic effect in a subject (when operating to prevent, alleviate, treat or cure disease(s) or condition(s)). In aspects, the MA(s) is a critical care device involved in treating or preventing a disease or condition associated with life support (e.g., preventing imminent risk of death), normal brain function, basic mobility/material quality of life, etc. . Examples of such MAs include, for example, medical ventilators, incubators, defibrillators, anesthesia machines, heart-lung machines, suction devices, pressure devices, irrigation/flushing devices, ECMO devices, pumps (e.g., infusion pumps, heart pumps, etc.) , biopsy devices, surgical devices (e.g., spinal surgery devices, cardiac surgery devices, etc.), shunts or other pressure relief devices, ventricular assist devices, pacemakers, tissue/organ or blood vessel/luminal thermoregulation devices, balloon pumps, etc. Vascular/arterial opening/modulating devices, catheters, stents, syringe pumps, infusion devices, sutures, valves, analgesic pumps, blood transfusion devices, organ function replacement or replacement devices, circulatory access devices (ports, lines, etc.), other circulatory devices, etc., and Includes catapult. In aspects, the treatment component may be performed on a subject via surgery or other physical manipulation (e.g., medical lasers, dissection devices, suction devices, punch biopsies and other biopsy devices, ablation devices, clamps, high-frequency ultrasound, temperature modulation devices, etc.). Modify body parts.

In aspects, the therapeutic or diagnostic component or both are partially or fully remote controlled, robotic or robot-assisted, computer system controlled, etc.

3. motion control

In aspects, the MA includes operational control(s) that controls one or more aspects of MA operation. Such controls may include, for example, control over the treatment component(s) (e.g., pump speed, flow rate, pressure, etc. depending on the treatment component), control over the diagnostic/monitoring component(s), or both. Motion controls may also include display controls, alarm/alert controls, or software/data controls (e.g., ports for downloading/transferring or uploading data, interactive interfaces, data entry devices, touch screens, etc.). In aspects, most, generally all or substantially all operational control(s) are controlled by aspects of the MA computer operating system/software (e.g., engine(s)). In aspects, some, most, or generally all motion control(s) of the MA are remotely controllable motion controls. In aspects, some, most or generally all of the motion control(s) are controlled by the NDS output(s).

4. MA display/output unit(s)

The MA may include output unit(s), such as display unit(s). The display unit may be any suitable device/component for visually displaying information to a user, such as a computer monitor/screen, etc. In aspects, a display unit may include or interact with it (eg, a touch screen device). The MA display unit can also relay or receive information in audio format. In this respect, the term display can be interpreted to mean “sensory output.” Some, most, generally all or all of the MA display units may sometimes, most, generally always or always be subject to remote control, especially NDS control.

In aspects, the MA display unit may be separate from the MA. In this respect, the MA display unit may be supplemented or replaced by a web/software interface, and thus references to interface and display unit are often interchangeable herein, are not contradictory, and include substitutions of these terms. are considered to provide implicit disclosure of corresponding aspects. The MA display unit may be a physical component of the MA. The display unit is capable of displaying the NDS-AD and related information (e.g., recommendations for treatment, treatment directions, procedures, prediction of vital signs that can serve as markers for assessing the progress of the condition, etc.) there is. The MA output unit may include components for output, including audio output (instructions, alarms, or both), motion output, etc.

In aspects, the MA display unit(s) may display some, most, generally all or all states, patient states, as well as one, some or several types of NDS-ADs to the user (e.g., three or more) of the device operations. , 4 or more, 5 or more, 7 or more, 10 or more, 12 or more, 15 or more, or 20 or more NDS-AD information features/data points). Examples of data characteristics include, but are not limited to, character formats (e.g., alphanumeric, mixed alphanumeric), coded and uncoded data, and languages (e.g., English, Spanish, French, German, Arabic, Korean). , Chinese, Japanese, etc.), slashes, dashes, asterisks, exponents (or for example subscript and superscript characters), units, symbols, flowcharts, diagrams, graphical data, tabular data, images, etc. It can be. NDS-AD provides recommended treatment steps, predicted vital signs or other sensor measurements (e.g., based on machine learning modules (MLMs)), system status, software update status, and MA-D monitoring by other users of NDS. It may include status, etc. The MA display unit may be part of a combined input/display unit, such as a graphical user interface (GUI).

II. MA Computerized/Computer System Components

The MA includes computational components that can receive sensor data and relay sensor data or other MA-D (e.g., device status/performance MA-D) to the NDS.

One. MA-MEMU/DM (MA memory unit(s))

MA typically includes memory component(s)/unit(s), system or component (which may be referred to as “MA-Memory”, “Device Memory” (“DM”) or MA-MEMU). MA-Memory typically includes CEI and other data (e.g., MA-D) included in the PTCRM. The DM can store any suitable MA-D, including data received from the sensor(s) over time, such as minutes, hours, days, weeks, months, or years, depending on memory size, demand, etc. In aspects, data storage in the DM may be performed selectively, automatically, or conditionally (e.g., upon preprogrammed condition(s), such as the availability of a secure and stable network connection to relay the data to the NDS). in response) or a combination thereof. In aspects, the DM also stores data from other input(s), such as data entered into the MA from the user, subject's data associated with the EMR/EHR, internal device operation data, etc. In aspects, the DM is adapted to store data generated external to the MA, such as NDS-AD or other output passed to the MA, such as recommended treatment step(s). The DM also typically includes a CEI for the operation of the software control components of the MA, which may be some, most, typically all, or at least substantially all of the therapeutic components, diagnostic components, display functions, alarm/warning functions or data reception/relay. May include engine(s) for controlling aspects of the operation of the function/MA. MA-Memory/DM can be any suitable type of memory, including, for example, hard drive memory, flash memory, etc. The size of the DM will vary depending on the MA's data load (e.g., number of sensors, sensor operation speed, complexity of the MA's software/operating system, number of measured data points, etc.), data transmission protocol, MA usage conditions, etc. In aspects, the DM may include a capacity of, for example, 512 MB or more, 1 GB or more, 2 GB or more, 4 GB or more, 8 GB or more, 10 GB or more, 15 GB or more, 20 GB or more, 50 GB or more, or 100 GB or more. In aspects, the DM is supplemented with local external hard drive/flash drive memory, local associated computer memory, etc. In aspects, DM may include cloud memory separate from NDS memory. Sensor data or other MA-D contained in DM, even temporarily, is characterized as "cache data". Cache data is discussed elsewhere.

2. MA processor

The MA also includes processor unit(s)/processor(s) that execute the device CEI (MA-CEI) stored in the DM. The MA may include any suitable number of processor(s), each of which is any suitable type of processor(s) (e.g., a processor unit(s) comprising a single processor or multiple processors operating together). am. In aspects, the MA processor is mostly, substantially only, or included only in the MA. In aspects, at least some MA processing functions are performed external to the MA. In aspects, the MA(s) include two or more physically separate and independently operating processing units, at least one of which, in aspects, is a multi-processor processing unit (e.g., a multi-core processor). Includes.

In general, the processor of the MA and other network device(s) is typically based on a logical combination of the states of one or more different switching elements, such as logic gates, with optional changes in state (output) reporting means and state functions; Any suitable type and number of states (e.g., binary states suitable for the application of binary code machine language) or other suitable states (e.g., for quantum computers, DNA computers, or other alternative computing platforms). May include switching elements (e.g., electronic circuits). These basic switching elements can be combined to create more complex logic circuits, including registers, adder-subtractors, arithmetic logic units, floating point units, etc. Examples of processor elements/processors include application specific integrated circuits (ASICs), digital signal processors (DSPs), neural network processors (NNPs), and digital signal processing devices (DSPDs). ), programmable logic device (PLD), field programmable gate array (FPGA), and CT. MAs and other network devices may include one, some, or several of these types of processor systems/components.

The MA processor may have any suitable processor functionality or characteristics. In aspects where the data processing needs for the MA are relatively limited (e.g., in devices with only one or a few sensors that collect simple data measurements and typically do not collect image data), a low-power processor may be used to: Can be used with some, most or all MA processor(s). In aspects, some, most, generally all or all of the MA(s) of the network include, most, generally, or only such low power/limited capacity processors, which, in aspects, advantageously In some cases, DOS may be associated with better power performance (e.g. longer battery life, etc.). For example, in aspects, the MA may include a low-power processor that may have a microampere per megahertz (μA/MHz) rating of less than -200, such as less than -150, or less than -100. In aspects, the MA processor may have a μA/MHz rating of less than or equal to ˜70, such as less than or equal to ˜50 or less than or equal to ˜40 (e.g., by including an ARM processor featuring 35 μA/MHz performance). In aspects, the battery life of such devices may, on average, typically or substantially exceed 3 years, such as at least 4 years, at least 5 years, at least 6 years, at least 7 years, or at least 8 years. It may be longer (e.g., ~10 years). In aspects, the energy demand of such a processor is about 2 to 10 volts, such as -3 to 9 volts, -3-6 volts, or -3-5 volts. In aspects, the processing speed of the low-power MA processor is also relatively limited (e.g., ~50 KHz to ~100 MHz, e.g., ~100 KHz to ~50 MHz, ~250 kHz to ~20 MHz, or ~500 KHz to ~10 MHz, e.g. , operates from ~1.5 MHz to ~75 MHz, ~2 MHz to ~50 MHz, or ~2.5 to 100 MHz). In aspects, some, most, generally all or all of the processor(s) of the MA may be a microcontroller, system on chip (SoC)/embedded processor, or Includes both. In aspects, such processors may be considered secondary or peripheral processors having less processing power than the primary processor unit(s) in one or more respects (e.g., processing speed). For example, in aspects, the main MA processing function is responsible for all MA processor operations not performed by a secondary/peripheral processor, such as a microprocessor, SoC, FGPA, etc., which may be associated with only one zone/portion of the MZMA. do. In aspects, most, generally all or substantially all of the MA processor functionality is performed via a single processor, which in aspects is a microprocessor. In aspects, the MA includes two or more, three or more, or four or more separate processor components, one component serving as a primary/main MA processor (which may be a multi-processor processing system or a single processor) and , other components act as specialized processors for specific data/functions (e.g., microprocessors in a very limited component/part/area of MZMA). For example, in aspects, the MA includes a main processor and two or three special processors, which may be, for example, FGPA, microprocessors, embedded processors, etc. In aspects, the MA includes one or more high-performance processors (processors operating at speeds of 100 MHz or faster, typically 250 MHz or faster, and often 500 MHz or faster). In aspects, the high-performance MA processor includes graphics processing unit(s) (GPU), such as, for example, an NVIDIA/ATI GPU. In aspects, the MA processor is or includes a field programmable gate array (FPGA), digital signal processor (DSP), or application specific integrated circuit (ASIC). In aspects, the high-performance MA processor includes a multi-core (e.g., dual core, quad core, etc.)/parallel processing capable architecture, such as an Intel or Xeon core processing unit. In aspects, the MA processor(s) may include master processor(s) and slave processor(s), both of which, in aspects, may be associated with a common bus. In aspects, operating software for a parallel processing capable MA processor includes OpenMP or other multi-platform shared memory parallel programming API. In aspects, the number of cores of the multi-core MA processor is -10 or more, such as -20 or more, -50 or more, -100 or more, -200 or more, -500 or more, or -1,000 or more. . In aspects, the MA processor may include coprocessor(s) (e.g., PCIe card(s)). In aspects, a MA processor may include CPU(s) and GPU(s), and in aspects may include a plurality of CPU core(s) and GPU core(s). The processor (e.g., CPU) cache size of the MA processor may be, for example, an L1, L2, or L3 cache size, or a larger cache (e.g., L4). The bus characteristics of the MA processor may include PCI Express 1.0, 2.0, 3.0, etc. (e.g., AGP, PCI-X, VLB, etc.). Exemplary processing memory for a high-performance MA is, for example, 32 GB (DDR2-667 FB-DIMM memory) or 8 GB dual-channel memory (e.g., DDR2 667/800), a memory controller (e.g., Intel 5000X chipset), Any other suitable configuration may also be used.

CEIs executed by the MA/network device processor(s) and stored in the CRM include assembler instructions, instruction-set-architecture (ISA) instructions/CEIs, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setup data, and aggregates. Configuration data for circuits, or object-oriented programming languages such as Smalltalk, C++, Java, Visual Basic, Python, etc., and procedures such as the "C" programming language, database-driven programs (e.g., SQL), or similar or other suitable programming languages. May include any programming language. In aspects relating to functions performed by an MA or other network component, the computer readable program instructions/CEI may run entirely as a standalone software package on the applicable MA/device, or may execute in part on the MA/network device, or It can be run entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to another computer (e.g., NDS) through any type of network, including a local area network (LAN) or wide area network (WAN)/wide packet switched network, or an external computer. A connection may be made (e.g., via the Internet using an Internet service provider). In aspects, electronic circuitry comprising, for example, programmable logic circuitry, a field programmable gate array (FPGA), or a programmable logic array (PLA) may be used to perform the step(s)/function(s) of the method/NDS (S( To perform s)/F(s)), CEI can be executed by personalizing the electronic circuitry using the state information of the CEI.

MA processor(s) typically process electrophysiological signals relayed from sensors. When the sensor data is complex (image data, waveform data, etc.) or the load requirements are high, the MA's MA processor can utilize parallel processing, distributed processing, or both, and typically handles sensor errors, device errors, external events, e.g. It will include processing functions to protect against power outages, power surges, etc. Examples of MA processing systems (e.g., parallel or distributed processors) and related principles, some of which may be adapted to practice herein, include, for example, US5464435, US5734106, US6185460, and US7013178. US7758567, US10252054, US10499854, US7446295, US20060009921, US20060206882, US20120226331 and US5607458.

3. MA relay component(s)/unit(s)/engine(s)

In operation, the MA in the network transmits device information including the MA-D from the MA to the NDS/MAC-DMS. The component responsible for data relay of the MA may feature a “relay unit” (aka RELAYU or device data relay unit (DDRU)). A MA relay unit may include software, hardware, or software and hardware components and may utilize/utilize or incorporate aspects of other units/components of the MA. The MA relay unit(s) typically transmit MA to the NDS selectively, automatically, or selectively automatically.

In aspects, the MA-D is transmitted from the MA relay unit to the NDS via the Internet. In general, the MA relay unit may operate selectively, automatically, or selectively automatically (e.g., attempt to relay data continuously or periodically if it chooses to do so). For example, an MA may not relay data if certain conditions are met, such as when the MA is offline (secure/reliable network not available), updating, testing, not operating, etc. MA relay units typically relay MA-D or other MA data over secure Internet data communications. In aspects, the MA relay unit relays MA-D or other MA data to the NDS in a substantially continuous/streaming manner whenever the MA processor determines that a secure and reliable network connection to the NDS is possible. In aspects, if such a connection is not available, the MA processing unit(s) executes a CEI on the DM to allow the MA to evaluate whether there is a stable and secure connection with the NDS/network. The DM's CEI may also include instructions regarding how data is relayed, where it is relayed, when it is relayed, etc. In some cases, the MA processing unit may automatically and repeatedly perform functions/algorithms (START, (1) IF operational, (a) REPEAT UNTIL not operational, (I) SEND GET request for channel/socket to NDS, (II) OPEN/RECEIVE NDS response, (A) IF NDS response received, (i) CHECK for secure and reliable channel, (*) IF secure and reliable channel present, (#) SEND MA-D, (**) ELSE , (##) STORE Cache MA-D, (***) END IF, (B) ELSE, (i) STORE Cache MA-D, (C) END IF, and END). .

In aspects, each operation MA automatically and repeatedly evaluates whether a secure network connection is available, and (a) if a secure and reliable network connection is available, transmits data containing the MA-D substantially over secure Internet data communication; automatically relays to NDS/MAC-DMS in a continuous manner; (b) if a secure and reliable network connection is not available, (I) store the MA-D as a cache MA-D in the medical device memory unit until a secure and reliable network connection is available and (II) When a connection is available, the cache MA-D is relayed to MAC-DMS through secure Internet data communication. Techniques for assessing the availability of communication channels are known. A typical method is “pinging” the server (here NDS) (e.g., via ICMP transport methods known in the art). For example, a system similar to Microsoft's Network Connection Status Indicator (Windows) could be used by periodically attempting to connect/ping the NDS. In aspects, the system, such as an XML/HTTP request, forms a message to which the server responds with a status code calculated by performing a number of checks to determine whether the required NDS subsystem is online (e.g., streaming processing engine, etc.). It can be routinely relayed to NDS using . Cloud-based server monitoring systems are also publicly available and can be used to monitor cloud-based NDS servers (e.g. Anturis service, CloudStats service, etc.), e.g. NDS hosted on major commercial cloud platforms such as Azure, AWS or Google. there is.

In aspects, some, most, generally all, essentially all, substantially all, or all MA-relays MA-D are semi-structured/semi-unstructured data. In aspects, some, most, generally all, essentially all, substantially all or all of the MA-Relay MA-Ds are in a known/established format that allows such data to be processed more quickly in DOS by NDS/MACMDS. Follow.

The MA relay unit includes either a direct communication medium (a physical connection facilitated by a communication cable, for example, a coaxial cable line, a fiber optic line, an Ethernet connection, etc.) or via a wireless/remote communication means such as Wi-Fi, Bluetooth, etc. You can use/interact with it. In aspects, the MA relay unit will include a network interface, such as a NIC (network interface card/controller). In aspects, the MA relay unit may also or alternatively include or interact with a modem/router, such as a cable modem, DSL modem, router, switch, etc. Accordingly, the MA relay unit may include components such as a Wi-Fi transmitter/receiver module (aka wireless transmitter).

Processor functions that can be considered components of a MA relay unit include appropriate processor functions operating at the application protocol layer (e.g., FTP or WWW protocol), TCP layer, IP layer, and hardware layer (e.g., Ethernet card). Protocols, such as TCP/IP, can be used to convert the data into a format ready for transmission. An input unit (discussed elsewhere) typically transforms the incoming data in a similar way but in the "opposite direction".

Suitable MA relay units/relay unit components are known. Accordingly, in aspects, the MA includes means for relaying MA data/MA-D (meaning any suitable collection of relay unit components/systems described herein or equivalents in the art) and methods described herein. It may include steps for relaying MA data/MA-D, which means using any of the described MA-D/MA data relay method or equivalents thereof.

Ready-to-transmit data may be transmitted in any suitable format. In aspects, the transmitted data is packaged and transmitted in a packet, e.g., a TCP/IP format packet. In aspects, different components of the network communicate only sometimes, most of the time, generally, essentially, substantially or via packet communication. Accordingly, in aspects, the network may be characterized as a packet switched network (PSN). In aspects, most, generally all, substantially all or all communications from the MA are conveyed only to the NDS/MAC-DMS during normal operation.

Data packets typically contain, for example, data routing information, sequencing/relationship information, source information, information related to packet data error detection/correction (checksum, parity bits or cyclic redundancy information), and time to live/hop limit information. , packet length information, packet priority information, payload information (related to queuing/prioritization), or an arbitrary CT. The packet also typically contains a payload portion (primary or (contains actual relay data) and trailer portion (which may similarly contain information related to error correction, etc.) MA-relay packet payload information typically includes sensor information SMAD and MA-D classification/identification information (device MA-D containing other information such as address, user class, device type, location information, patient/subject type, device status, or arbitrary CT) and other data classification information (e.g., cache data/SMAD classification) In aspects, the packet header, payload, or both may include authentication information to enable packet firewalls, filters, and other routing/streaming/security units to operate at least in part, e.g. ,Packet information may include allowed IP addresses, allowed packet types, allowed port numbers, and other authentication-related information.

The MA relay unit can transmit data at any suitable rate. In aspects, the MA relay units of a portion, most, generally all or all MAs of the network may transmit using Gigabit Ethernet or Infiniband standards known in the art. In aspects, some, most, generally all, substantially all, or all MAs in the network relay data at one of these speed standards. In aspects, the MA relay unit transmits data continuously or nearly continuously as described elsewhere. In aspects, the MA relay unit transmits MA data most of the time, generally all the time, or at least substantially all of the time, on a streaming basis, a real-time basis, or both.

In aspects, the MA-D transmitted by the MA relay unit to the NDS is sensor data. In aspects, some, most, generally all or all of the MA-D relayed or transmitted by the MA relay unit in operation is real-time data (RT-MA-D), such as real-time sensor data, stored data, which also Also known as locally stored sensor data or locally stored data (MA-CD/cache data), such as both RT-MA-D and MA-CD. In aspects, MA-D, such as SMAD and cache data, includes structured data. In aspects, the MA-D is mostly, generally, or only substantially unstructured data. In aspects, the MA-D relayed by most, generally all, substantially all or all MAs includes both structured and unstructured data, on average, most of the time or all of the time. In one aspect, the MA-D transmitted by the MA relay unit includes image and non-image sensor data from the MA, the MA environment (e.g., MA GUI), or both. In aspects, the MA relay unit may be characterized as comprising or operating in conjunction with a wireless transmitter capable of relaying the MA-D via Wi-Fi or a similar wireless transmission mode.

4. MA input component(s)/unit(s)/engine(s)

The MAs in the network receive data input to the MA through sensors from the NDS, from local/direct inputs, from other devices/interfaces/sources, etc. (e.g., from the EMR). The component(s) that handle data input into the MA may feature MA input unit(s) (MA-INPU(s)). The MA input unit may comprise physical components, for example, network card(s) for receiving data, or other data receiving hardware, for example a modem. In aspects, this MA input unit may include or interact with a user through an interface or input device such as a keyboard, touch screen, voice interface, eye gaze/tracking interface, etc. In aspects, the MA-INPU may be a digital interface that receives digitally transmitted data. In aspects, the MA input device includes or interacts with an input device (e.g., a touch screen or keyboard input device, gesture-based or voice input system/device). The MA input unit is a unit(s)/engine(s) that converts received packets into device usage data, such as commands for device display, device control, device alarm/warning, or combinations thereof (CT). May contain software/operating system elements associated with it. In aspects, the MA input unit is comprised somewhat, mostly, generally or entirely of components that also function as an output unit (e.g., the MA may include network/interface card(s), modem(s), port(s) , buses, etc., which serve as input/output component(s) for the MA). The input/output component(s)/system(s) of the MA or other devices on the network (including NDS) may include engine(s) for encoding data into appropriate communication media/medium (e.g. for internal device or network communication). )/components, which will vary depending on the communication channel (e.g., Wi-Fi vs. Ethernet), receiving system(s)/capability, suitable communication language/code, etc. The engine(s) will typically ensure or apply time communication and other code (e.g., packet headers) for identification, data type, authentication, etc., for example to facilitate synchronization. The input engine/function is typically configured to automatically send acknowledgment message(s) to the NDS (e.g., in response to an NDS ping or status query), either periodically, automatically, or conditionally. The I/O system of a network device/system is generally suitable for packet-switched communications, circuit-switched communications, or both. In aspects, most, and generally all or all, network communications are conducted via a packet switched protocol and the I/O component/engine is adapted to apply/interpret the packet switched protocol, such as statistical multiplexing. In other aspects, the MA input unit may include specialized engine(s) to process one or more aspect(s) of data reception, such as protocol(s) for processing received data packets.

5. MA Security Engineer(s)/Unit(s)

In aspects, some, most, generally all or all MAs of the network further include a system for maintaining data security (MA security unit). The MA security unit (aka MA-SECURU) may be considered or associated with an MA input unit. The MA security unit may perform different function(s) related to data security. Typically, these features include a firewall function that limits data flow to the MA's software/operating system or memory to only certain authorized data inputs. The MA security unit component(s)/engine(s) may include/perform user authentication functions/engines (e.g., password or biometric authentication protection for logging in to the MA or CT, such as a two-factor authentication function). . The MA security unit may include authentication for network access, either separate or integrated with MA local access, and may include any of these authentication methods. Authentication information may need to be partially or fully updated at one or both levels when event(s) (e.g., security breach, loss of authentication, etc.) occur, over time, or both.

Authorization/user authentication components/functions that may be part of a security unit applied at the local (device) level, network level, or both include, for example, pre-shared key/device authentication/recognition, password/code authentication, biometrics, knowledge, etc. based authentication, use of a key fob/device or authentication application (e.g., running on a mobile device), behavioral/psychometric authentication, or any CT (e.g., 2-factor or 3-factor authentication method) ) may be included. Other authentication methods, principles, etc. that are adaptable to these aspects include, for example, US5684951, US6421943, US5832209, US6263432, US7904956, US7991902, US5999711, US5613012, Nos. US5742756, US6289344, US6594759, US6675153, US6711681, EP1115074, US7434257, US20020032661, US20200286055, US20020184161, No. US20200329051, No. US20200267147, No. US20200311285 US6910041, US7080037, US7685173, US7366913, US7178163, US7664752, US8365254, US8024794, US20080183625, and US8646027.

In aspects, each MA may include a mechanism to limit the characteristics and operating conditions of the MA that can be remotely controlled. In aspects, each MA may include a mechanism to limit user access to features of the MA based on a user profile. In embodiments, each MA may restrict data input (e.g., data received by the MA-INPU) based on one or more established security rules/protocols and data output based on one or more established security rules. (e.g., data transmitted by the MA relay unit) may be further restricted. In aspects, at least some, most, generally all or all data entering or exiting the MA is subject to one or more layers of data security. In aspects, each MA has an independent device security system. In aspects, the MA group may include a shared device security system. In a further aspect, the MA network may include a shared device security system.

In aspects, the MA security system identifies the user's access level to information included in the incoming MA-D data or analysis transmitted by the NDS relay unit, rules for redaction or exclusion of the information based on the user/customer access level, and Data corrections can be applied. These rules may operate on behalf of or in conjunction with NDS functions, such as filtering functions, routing functions, NDS security units, or any combination thereof.

In aspects, the MA security unit includes one or more physical components dedicated or at least substantially, at least mostly or generally dedicated to security functions. For example, the MA security unit may be an embedded processor(s) (or a computer/subcomputer comprising processor(s) and memory - e.g., a system-on-a-chip ("system-on-a-chip") as known in the art. "SoC") devices/components, or other multi-function integrated circuits), which may perform various security-related functions (e.g., launch challenge and response authentication functions, firewall functions, or both). These devices may include code for, for example, a cryptographic engine that provides data encryption functions. Dedicated processors and other components (including most, typically all or all MA processors) must be physically secured, for example, shielding such as metal shields, and protected when tampering is detected (or by a user with sufficient credentials/authentication). (if not detected and mitigated within a pre-programmed period of time), tamper-only/mitigation features/components, e.g. can be subject to tamper sensors, which erase the data (typically by overwriting all or all binary/machine data with zeros). Examples of such devices include 8-bit, 16-bit, or 32-bit embedded processors to 8-bit microcontrollers, and the MA may include similar devices or a combination of these devices that can perform security functions. Such devices may also include, for example, 128 to 512 kb of flash code storage and high-speed SRAM, for example, 32 to 256 kb. In aspects, the MA security unit may log access to the MA for future reference, for example by a user or NDS owner/operator (SO).

In aspects, including an embedded processor or microcontroller in the MA allows such functions to be performed by the primary MA processing unit (e.g., the MA microprocessor may perform most, generally all, or substantially all of the MA computer operations and computer control operations). power consumption, operating heat, or both can be detected or significantly reduced compared to comparable devices that are controlled by the device. In aspects, one, some, most, generally all or all microcontrollers, embedded processors, SoCs, combinations thereof, etc. of the MA may operate at less than 10 watts, e.g., less than 7 watts, less than 5 watts, Or use less than ~3 watts of power. In aspects, an external processor, such as a microprocessor, embedded processor, etc. (with respect to the primary MA processor) exhibits an average power usage of less than 10 Watts, less than -7 Watts, less than -5 Watts, or less than -3 Watts.

The engine(s) encoded in the associated memory and executed by these processors may include cryptographic protocols such as DES, triple DES, SHA-1, AES, and RSA cryptographic methods/engines (cryptographic accelerator(s)). Without being contradictory, a non-contradictory disclosure of any aspect herein relating to any such device (SoC, microprocessor or other embedded processor or integrated circuit) may implicitly refer to such other components or other equivalent means in the art (e.g. For example, it provides support for functionalities, structures, power usage or operational characteristics such as arbitrary CTs). In aspects, the MA includes microcontroller(s) or similar devices, such as a specialized embedded processor, SoC, etc. In aspects, one, some, typically all or all microcontrollers, embedded processors, SoCs, etc. are separate from the primary MA processor and have lower processing power than the primary processor. In aspects, some, most, or generally all processors of the MA integrate analog components necessary to control non-digital electronic systems that may be in or associated with the MA.

In aspects, the MA may include or utilize one or more microcontrollers, for example, about 2 or more, about 3 or more, about 4 or more, about 5 or more, or about 10 or more microcontrollers; This means that it can perform one or more data protection functions. In aspects, such microcontroller limits data input only to recognizable data, e.g., data that meets a set predefined identification threshold indicating that the data is of an approved data type (e.g., data that meets a set expected value). may be within a range, be an expected numeric or alphabetic character, contain appropriate units, be formatted in a set expected format, and so on. MA may also be used (on average or for most or generally for all operating periods (e.g. days or years)) for the initial detection or control of sensor(s), for example independently of security functions, or at least most of the time. It may include SoC, microprocessor, embedded processor, etc. as part of the overall MA processing function that performs functions separate from the security function. The majority of MAs, typically all or all microcontrollers, provide real-time responses to events in the associated/embedded system controlled by the microcontroller(s). In aspects, some, most, generally all or all of the microcontroller or similar processor suspends microcontroller processing of the normal or current instruction sequence and performs any processing necessary based on the interrupt source before returning to the original instruction sequence. It includes an interrupt system that starts an interrupt service routine (ISR) or "interrupt handler"). In aspects, some, most, generally all or all functions related to the performance of the microcontroller (microcontroller engine(s)/function(s)) are encoded/stored in primary MA memory rather than in a separate microcontroller memory. do. In aspects, the microcontroller will execute encoded code/engine in both microcontroller associated independent memory and primary MA memory. In aspects, most, generally all, substantially all or all of the microcontrollers of most, generally all, or all MA(s) may include an analog-to-digital converter (ADC), a digital-to-analog converter (DAC) (e.g. For example, it may include a DAC or CT that allows the processor to output analog signals or voltage levels. In aspects, most, generally all or all of the microcontrollers may support, for example, Inter-Integrated Circuit (I²C), Serial Peripheral Interface (SPI), Universal Serial Bus (Universal Serial Bus), etc. USB), Ethernet, RS232, or CT, or any similar protocol/means known in the art, in one or more digital formats. In aspects, most, generally all or all of the microcontrollers of the MA are programmable, and in aspects, most, generally all or all of the microcontrollers are programmable in Python, Java, C It can be programmed in object-oriented languages such as versions. In aspects, most, and generally all or all, microcontrollers include a CMOS configuration. In aspects, most of the MAs or some, most, generally all or all of the MAs in the network are RISC (reduced instruction set) or CISC microcontrollers. In aspects, some, most or all of the microcontrollers in the network may be configured to control, for example, no more than five, no more than three, no more than two, or only one function (e.g., a specific sensor, MA). It is a special-purpose computer that performs (detection or measurement of sensor data from a sensor data source or data flow control within a MA, etc.) and typically runs a corresponding number of software applications. In aspects, one, some, most, generally all, essentially all, or all of the microcontrollers include dedicated input(s), a display unit (e.g., an LED display), or both.

The MA security device may include one or more firewall functions. A “firewall” can be considered a security device, system, or component that monitors/analyzes data transmission/flow, such as network traffic. Like other data filters or data curators, firewalls filter incoming data flows (traffic), outgoing data flows/traffic, or both, typically based on a set of established/pre-programmed standards/rules. Firewalls can be placed at the hardware level of the device/system, the software level of the device/system, or both to protect against unauthorized/malicious traffic. Depending on its settings, a firewall can protect a single system, a group of systems, systems, or an entire network. Firewalls of the present disclosure include software firewalls (e.g., host firewalls) (e.g., performed by a primary microprocessor or other primary processing unit of the MA's computer system), hardware firewalls (e.g., appliance firewalls) (e.g., a microcontroller or embedded processor firewall or a separate but related device firewall) or both.

In aspects, the firewall functionality of the security unit may include one or more packet filtering firewalls. In aspects such a firewall includes a protocol for checking packet data against access control list(s), and a protocol for dropping/blocking unauthorized transit packets or forwarding authorized packets, or both. In aspects, most, generally all or substantially all of the MA firewall functionality is comprised of packet filter(s), such as a stateless packet filter firewall. In aspects, the security system will include one or more other types of firewalls in addition to or instead of stateless packet filter firewall(s) (aka “packet firewalls”). Other types of firewalls known in the art and discussed elsewhere that may be used in security units include stateful packet inspection (SPI), proxy server firewalls (e.g., outgoing/transit data transmitted over the Internet), ), circuit level gateway, or any CT/combination. In aspects, the security unit includes a deep packet inspection firewall, which includes some, most, generally all, substantially all or all incoming packets, TCP handshaking, URL filtering, or any ACT. Analyze all, substantially all or all payload content. In aspects, the firewall of the security unit performs both surface and deep packet inspection in an ordered manner, based on packet analysis, or both. In aspects, the firewall function(s) also perform anti-virus scanning/protection functions, spam filtering functions, application control functions, or a combination thereof. In aspects, the firewall function may terminate secure sockets layer (SSL), transport layer security (TLS) connections, or both.

In aspects, the MA security unit also includes an intrusion prevention NDS (IPS) (e.g., performs signature tracking and anomaly detection to prevent threats from entering the data stream). In aspects, a security unit, such as MA-SECURU, periodically or alternatively isolates the incoming code based on triggers of other security unit(s)/engine(s)/function(s) (U/Fs). Includes a sandboxing function to execute, execute, and inspect.

Non-contradictory aspects of the MA security unit discussed herein may be applied to the NDS security unit (described below) and vice versa. For example, features of the firewall component of the MA security unit may also be components of the NDS security unit.

In some aspects, the MA security unit(s) include an anti-tampering detection function that signals the NDS when a prohibited tampering event occurs in the MA. In aspects, when such a signal is received by the NDS, the NDS may, in aspects, set up a new communication rule associated with this MA, and also in aspects, notify the appropriate user, e.g., a user local to the MA ( For example, it may alert you to the presence of a tampering event (via network access device(s) (NAD(s))) or take other actions as indicated elsewhere (e.g. locking system usage, deleting data, etc.) ).

III. Multi-Zone MA (MZMA)

In aspects, at least some MAs in a network (or a majority of a network, typically all or all MAs) are subject to separate security protocols or security units (“zones”), perform different MA functions, and have different MA functions. Subject to regulatory status and comprising a collection of two or more components or components/sub-devices, each having different communication functions. Such MA may be characterized as a “multi-zone” MA (“MZMA”) (or multi-component MA (“MCMA”)). Intercommunication or interconnection of sections/components of the MZMA may be achieved through any suitable component(s), method or means. In aspects, the majority of the MZMA, typically all or most of the sections/components, generally all or all of the physical components, software components, or both, are housed within a single hardware housing of the MA. In aspects, the components of the MZMA communicate via a direct cable/wire connection relaying data (e.g., using a later version of RS-232, RS-422, RS-485 or Ethernet protocol/standard). In aspects, data relaying/communication between zones or zone components is managed via wireless communication methods known in the art (e.g., Bluetooth or optical/laser data transmission). In aspects, multiple components/regions of the MZMA share component(s)/function(s) (eg, power or display functionality, etc.).

In aspects, two or more zones of the MZMA may include separate dedicated zone-specific processing functions or applications. In aspects, two or more zones of the MZMA may include different processing functions, be under the control of one or more different processors, or utilize some or all of one or more different processors or spheres. As a non-limiting example, in one aspect, one or more sections of the MZMA may include one or more section-specific microprocessors and one or more other sections may include a system-on-chip (SoC). According to some aspects, zones may share processor(s) or processing function(s). In aspects, a zone may share both processor(s) or processing function(s) while also containing separate dedicated and zone-specific processing functions or applications, e.g., one or more processors may be shared and one or more Processors may be zoned.

One, some, most, generally all or all MAs of the network may contain more restricted areas/portions and less restricted areas/portions. In aspects, the more restricted area/portion is associated with a treatment component(s) (e.g., a critical care component) and the less restricted area/portion is associated with a treatment component(s) (e.g., a critical care component) that is less critical to subject monitoring, diagnosis, or patient safety/condition. s), or any combination thereof (CT). In one exemplary embodiment, the MZMA includes very limited therapeutic application components that provide critical life support system treatment functions, includes physical anti-tampering protection, and includes a MA CEI that is largely, substantially, or only locally modifiable. do. In aspects, only packets/data related to control of treatment components may be relayed from the NDS to highly restricted areas/components. In aspects, packets/data associated with control of a therapeutic component or packets/data permitted to pass to a highly restricted zone/portion of the MZMA may be transmitted through two or more firewalls (e.g., a less restricted zone/full MA firewall and a zone of the MZMA). It must be transmitted through a microcontroller security unit that controls interconnection communication. In aspects, the highly restricted portion/zone may include an anti-tampering detection/protection system, a user authentication system, or both. In aspects, all data relayed from a highly restricted area/component is first relayed to a less restricted area/component, which then relays this MA-D to the NDS (e.g., fewer areas/components are connected to the Internet). (if it is the only part of the MA that allows communication). In embodiments, at least a portion of the MA includes a majority, but only substantially all, patient monitoring/diagnostic component that includes a processing unit capable of receiving system update availability or a pull request sent to the NDS (or Also includes MA CEI, which can only be modified through a confirmed request). In aspects, the highly restricted portion of the MZMA will include backup functionality that allows the MZMA to operate independently of a less restricted portion/zone of the MZMA (e.g., when the highly restricted portion is engaged in critical life support activities). .

In aspects, most, generally all or all portions/zones of the MZMA are associated with the same subject, e.g., a first zone treating the subject in a first manner and a second zone providing one or more types of device data, sensors, Detect data or other data associated with the subject. In aspects, one or more portions of the MZMA are housed in a single unit housing. Sections of the MZMA may assist in performing therapeutic or diagnostic tasks supporting the same physiological condition/system (e.g., cardiovascular). In aspects, sections of MZMA focus on different state/subject systems. In aspects, zones of the MZMA are associated with monitoring or applying different medical device applications. In aspects, each portion of MZMA has a different regulatory status. For example, the highly restricted portion of the MZMA may be regulated by the US FDA as a Class 2 medical device or a Class 3/PMA medical device, and the less restricted portion may be regulated as a Class 1 device (a lower level of regulation).

In aspects, a network includes a plurality of MZMAs, each MZMA of the network including two or more separate components contained in two or more separate zones, each component configured to (a) be processed by a processor of at least one other component; (b) (I) receive information from different sensors, (II) perform different therapeutic/preventive or diagnostic medical operations, or (III) ) receive information from different sensors and perform different therapeutic/preventive or diagnostic medical tasks, and at least one component of each MZMA is different from at least one other component of the MZMA with one or more other parts of the data network. Receives level interaction. For example, component(s) in the first zone of the MZMA may have more security and less direct or no direct communication with the data network, while component(s) in the second zone may generally or under certain conditions (e.g., relays data on a regular basis, but only receives data when traversing a firewall or in response to a request/pull signal sent from a Zone 2 MZMA component(s)) can

In some cases, at least one component of at least one of the MZMAs in the network is associated with the application of a therapeutic/preventive medical task (without being contradictory, references herein to therapeutic and preventive tasks implicitly provide support for each other) ), this at least one component of MZMA does not communicate directly with the data network. In aspects, at least one component of at least one of the MZMAs in the network (1) is associated with the application of a therapeutic medical operation, a preventive operation, or both, (2) is in communication with an NDS/MAC-DMS, and (c) Only a preset amount of input from the NDS/MAC-DMS is accepted, and changes to the operating system, software or approved formats of the NDS/MAC-DMS of the relevant zone or at least one component of the MZMA must be made locally by the authorized operator of the MZMA. Approval is required.

The reader will recognize that MZMA is an independent aspect of the invention (i.e., separate from aspects of the invention that include NDS). In this regard, the present invention provides a medical device comprising two or more zones subject to different levels of interaction with an associated data network, for example the Internet or other network, wherein the two or more zones are connected to the network. Different rules/restrictions apply in terms of interaction with and generally areas associated with critical components of patient care are restricted from communication with the network/Internet (e.g. these areas cannot receive information directly from external networks/Internet). (or in some cases may send information directly to the network/internet). In aspects, such MZMA or its limited components are subject to only manual updates/modifications or updates via the network/Internet via pushes/requests for such updates by authorized users. In aspects, the most sensitive components of such devices are subject to only manual updates. In aspects, this MZMA is subject to various security components (e.g., anti-tampering protection) discussed in this disclosure. Other features/aspects described herein in relation to MZMA may also be incorporated into MZMA that may operate independently of MZMA (e.g., on another server, on the Internet, on another medical device, on another computer, on another network, etc.). .

B. System(s) (NDS) and Network

One or more MA(s), usually a group(s) of MA(s) and an operating NDS, form a network. As mentioned elsewhere, the network may also include or interface with other devices/components, such as CRMS, other ONDI, devices/systems hosting EMR, etc. The network formed by MA and NDS can become a defined part of a broader network, such as the Internet.

In aspects, the NDS may control one or more aspects of the operation of some, most, generally all, or all MAs of the network. Such NDS may feature a MA Control and Data Management System (“MAC-DMS”). The MAC-DMS may also optionally control some or most operational aspects of some, most, generally all or all ONDIs of the network. In general, and not inconsistently, any aspect described herein with respect to a network/NDS may also apply to a MAC-DMS and each disclosure of an NDS/network also includes the corresponding aspect wherein the referenced NDS/network is a MAC-DMS. is implicitly initiated.

Components of the network may be interconnected through any suitable method/means. In aspects, most, generally all, or at least substantially all components of the network will be connected via Internet communications. In aspects, certain portions of the network may be excluded from Internet communications, e.g., the medical device (MA) portion of the network, such as therapeutic components associated with directly applying therapy to a patient (e.g., a limited portion of the MZMA). zone) may be excluded from Internet communications. Components of a network may be distinguished/connected through connection points (e.g., node(s)). Nodes in the network that are under some level of control by the SO, the IE, or both are the connection points between the entity MA(s) (which may be characterized as IE MAGs) and the NDS, screening/filtering points (e.g. It may contain node(s) for entities that act as firewalls (and local MAs, NDSs, or other security units at the intervention level) or both. In aspects, communications between some, most, generally all or all components of the network are encrypted (e.g., communicated via a VPN or other form of encrypted tunnel). In aspects, some communications are not encrypted, but some data (e.g., PHI, device control application(s), etc.) is encrypted or has a higher level of encryption/security than other data relayed on the network between network devices. Applies.

In aspects, the network may be classified as a wide area network (WAN). In aspects, the network may be classified as or include a software-defined WAN (SDWAN) or cloud-based WAN. In aspects, a WAN includes a plurality of LANs (e.g., an entity LAN, a facility LAN, or a LAN associated with a user class or group of users within a class, e.g., a group of researcher users associated with a different research organization entity).

In aspects, the owner/operator of the NDS/MAC-DMS(SO) is a different entity than the owner of some, most, generally all, substantially all or all of the MAs in the network. In aspects, the NDS may feature access to an MA or group of MAs, for example, through granting access to receive or relay data from/to the network MA(s) from the MA owner(s). In aspects, the NDS may include electronic contract functionality related to the connection of a MA owned by an IE (in relation to the NDS owner), which may include contractual terms and conditions (intellectual property, software or data) for access to the NDS by the MA. Presents, negotiates, implements, maintains, updates and otherwise manages the terms and conditions (including terms related to ownership and modification, confidentiality, patient safety, legal compliance, liability, performance guarantees, financial terms, etc.). In aspects, this electronic contract functionality may be selectively or conditionally updatable (e.g., renewable when a term expires or device/NDS terms change).

The NDS includes components/systems/functions to handle incoming and outgoing communications with the MA and optionally ONDI (e.g., capable of receiving and transmitting data), and the NDS also provides data storage, as discussed elsewhere. and data processing function(s). In aspects, the NDS communicates with any one or more MAs individually or as a group or as a group of MAs, such as communicating with any two or more MAs at a time or with any two or more MA groups (MAGs) at a time. May include the ability to communicate. NDS may include any suitable combination of hardware, software, etc. In aspects, most, generally all, substantially all or all NDS components are cloud-based resources, such as cloud-based memory, cloud-based processor functionality, etc.

In aspects, the NDS relay of information to the MAC-DMS controls the operation of the MA based on NDS-AD (e.g., comparison of NDS-AD with pre-programmed standards/rules or algorithms). NDS-AD can be used to generate control data, which can characterize output applications or commands, as well as to relay information NDS-AD that can also be passed on to MAs and other network devices/interfaces (ONDI). can be used For example, an informational NDS-AD includes predicted physiological data for a subject, generated by the NDS, for example, through MA-D analysis of a similarly positioned subject, optionally with reference to other medical data. can do.

The control application/controller(s) of the NDS may control the MA display, other sensory MA functions (e.g., alarm playback), or control therapeutic or diagnostic components of the MA/MA portion/component. As such, the NDS may feature a MA Control and Data Management System (“MAC-DMS”). Although the term NDS is frequently used herein, in general embodiments NDS may also be classified as a MAC-DMS and the reader will understand that use of the term NDS herein implicitly discloses the embodiment in which the NDS is a MAC-DMS. will be.

I. NDS components

To better describe the possible components of NDS(s) and their operation, several optional components are discussed in the following sections.

One. NDS Memory System/Component(s)/Unit(s)

The NDS includes one or more memory unit(s) (“Memory” or “NDS-MEMU”) capable of maintaining MA-D, NDS-AD and CEI for operation of the NDS. An NDS memory unit may include any suitable type of PTRCRM contained in one or more structures (one or more drives, media banks, etc.). In aspects, most, and generally all or all, NDS memory is comprised of data store(s) (DR(s)). In aspects, the NDS is one or more queryable (queryable) comprising input from MA-D, NDS-AD, optionally other input sources (e.g., connected CRMS(s)), or any combination thereof. /Contains searchable DR(s). In aspects, the NDS may include two or more types of memory/DR that are functionally distinct, physically distinct, or both. For example, in aspects the NDS may have a Streaming Data Processor that is operably or physically separate from the primary memory of the NDS, for example by being separated from most, typically all or all of the DR(s) of the NDS. Processor (SDP) and associated memory units. The portion of NDS memory that makes up most or all of the DR can be described as the "primary memory" of NDS. As discussed below, NDS memory units/systems, such as NDS primary memory, may be divided into different physical components, different functional areas/regions, or both.

In aspects, some, typically all, or all NDS memory units (also referred to as NDS-MEMUs) may include a clustered NAS infrastructure (e.g., NAS pods), each of which is typically connected to a master NAS device. Includes network-attached storage (NAS) infrastructure, such as individual storage devices (including individual storage devices, forming interconnected memory devices/media). In aspects, some, most, generally all or all NDS memory units may be deployed on a cloud computing platform/paradigm (e.g., a Service/Storage (DaaS) platform or an Infrastructure as a Service (IaaS) or Platform as a Service (PaaS) platform. ) DR/data storage as a platform is based on memory and includes processing and other functions in addition to memory support functions. In aspects, cloud-based NDS memory is based on a distributed system, a scalable on-demand (or autonomous) system, or both. In aspects, a distributed file system that forms some, most, and typically all or all of the NDS memory stores data across many individual servers. In some aspects, most, generally all, or substantially all of the NDS memory is not distributed. In aspects, NDS memory and associated NDS input unit functionality includes redundant storage of data in a distributed memory system.

The hardware components of an NDS memory unit (or a memory unit of another device in the network) may use any suitable type of memory medium. In aspects, the memory may include dynamic RAM or flash memory. In aspects, the memory may be disk-based storage memory or a hybrid structure of disk-based storage and DRAM/flash memory (e.g., using DRAM or flash disk storage for “colder” data used for “hotter” data). Includes.

Typically, memory unit(s), such as NDS memory, may include firmware, kernel(s) and/or applications. The kernel has modules for memory management, scheduling and process management, input/output and communication, or the operating system communicates with the hardware modules/components (e.g. memory units, networking interfaces, ports and buses) of the associated computing device/system. It may be an operating system that includes device drivers that allow it to do so. An application may be one or more user space software programs, such as a web browser or email client, as well as any software libraries used by such programs. Memory can also store data used by these and other programs and applications.

The data storage/memory unit(s) of the NDS or other network device may include a data storage array, which may include a drive array controller configured to manage read and write access to a group of hard disk drives, solid state drives, etc. or may be in a data storage array. The drive array controller, alone or in conjunction with NDS component(s) (server device(s)), manages backup or redundant copies of data stored in data storage/memory units (DR(s)) to prevent DR/drive failure(s). , data failures, etc., for example, may be configured to protect against failures that prevent the NDS component(s) from accessing portions/units of memory/data storage. As discussed elsewhere, DR(s) include data store(s) in any suitable form, including any suitable database(s), such as a well-known structured query language (SQL) database. can do. Various types of data structures can store information (e.g., analytics data) in these databases, including but not limited to tables, arrays, lists, trees, and tuples. Additionally, the database or other DR(s) of data storage may be monolithic or distributed across multiple physical devices.

In aspects, the NDS memory unit(s) include cloud-based memory including an Internet-scale file system (e.g., Google File System (GFS)). Examples of cloud-based storage systems with these and other features discussed herein include Amazon Simple Storage Service (S3), Nirvanix Cloud Storage, OpenStack Swift, and Windows Azure Binary Large Object (Blob) storage. NDS-MEMU may include a file management system/layer, in which memory units (e.g., Hadoop Distributed File System (HDFS)) or data sets are likely to be consumed by applications directed by a mapping function (mapper). Defines part or most of the architecture for different levels of data management (similar systems with the ability to partition and replicate to higher nodes). These file systems typically include configurable data set replication capabilities to detect or significantly minimize the impact of component/device failures on the NDS-MEMU hardware architecture or operating system/software. In aspects, the U/F of NDS memory unit(s) may include a data management system (DMS), which may also include a DBMS. In aspects, the U/F of the NDS memory unit(s) includes an executable tool for DoS to distribute computational load between components of the memory, and may serve as an API for the memory, data inspection, data Other U/Fs may be included or associated, such as data auditing or data visualization functions for NDS memory. NDS processor(s) typically also include a query system to extract information from the DR.

In aspects, a portion of the data in a DR of an NDS, e.g., a significant amount of data, or a significant amount of data in a DR, may be modeled in non-relational model(s) (e.g., documents, graphs, key values, and non-tabular forms (e.g., nontabula) and other models used to provide efficient storage and access to data sets. In aspects, some, most, or generally all data in the DR may be characterized as being stored in a NoSQL DR, e.g., MongoDB, Hadoop HBase, Apache Cassandra, Couchbase, etc. In aspects, DR uses both NoSQL and Hadoop functions/structures optimized for batch processing. For example, you can use HBase (a NoSQL DR architecture) on top of HDFS to provide low-latency features in Hadoop. Other file systems that can perform similar memory and memory-related functions effectively in a distributed, multi-server environment may be used. In general, a distributed memory system consists of a master node that stores data and a file/data system chunk server that stores actual chunks on multiple nodes, which are generally replicated and fault-tolerant/fault tolerant. It will be included in a way. A data management system (DMS) will typically also include a checksum function or similar functionality to check data integrity and correction/alert mechanisms associated with it. Other tools available in DMS may include the MapReduce framework or similar parallel, distributed, and cluster-based data management algorithms such as Hadoop, Apache Spark, etc. In aspects, the NDS input unit may store data from at least 250 nodes/stream, at least 500 nodes/stream, at least 1000 nodes/stream, at least 5000 nodes/stream, or at least 10,000 nodes/stream. can be processed simultaneously. In aspects, this processing includes performance of the initial conversion, such as ~40 seconds or less, ~30 seconds or less, ~10 seconds or less, ~5 seconds or less, or ~1 second or less (e.g., ~0.33 seconds or less, ~ associated with a collection latency of less than 0.1 seconds or less than ~0.05 seconds).

As discussed elsewhere, in aspects the data collection paradigm involves taking data from a source, manipulating it to suit the properties or business requirements of a destination system, and then extract, transform, and load it into that system. and load; ETL) procedures can be used. In other aspects, as discussed elsewhere, the transformation or data collection structure requirements are minimal (e.g., requiring less than 10, less than 9, or less than 8 transformations/structures). Since NDS analysis functions operate based on transformations applied to DR stored data, data collection is primarily, generally or only substantially, based on extract, load, and transformation (ELT) methods.

Data storage (“DR”) can be classified based on how data is received (collected), stored, and accessed/utilized (consumed) primarily, substantially, or solely in/from DR. Known examples of DR include databases, data warehouses, and data lakes. In general, each DR in the device or NDS memory can be distinguished from other DRs in the overall memory of the device/NDS based on these different characteristics. For example, a skilled person can distinguish between data lake DR and database DR based on the structure of the DR, the type of data stored in the DR, etc.

Terminally, here, the database is a database containing about 5 or more, typically 7 or more, 8 or more attributes and values consisting of ~3 or more, 5 or more, 10 or more, 50 or more or ~100 or more records. DR refers to a relational dataset containing more than, or about 10 or more (e.g., ~12 or more, 15 or more or ~20 or more) interrelated data points, typically tables, It will contain high-level structures such as stored queries, etc. Databases typically store data in tables, columns, and rows (records and fields in a table). Databases are generally controlled by a database management system (DBMS), with relational database management systems (RDBM) and object-oriented databases being common. Most databases used in NDS memory are typically hierarchical (not flat). Examples of databases (DBs) that may be used in aspects include Microsoft SQL, Oracle, Microsoft Access, and Redshift databases. In aspects, the NDS has one or more, and in aspects two or more, relational databases that collect assembled datasets including MA-D, analysis data, output, etc., in a database hierarchy, as described elsewhere. Includes. Therefore, in some cases, the NDS includes multiple queryable DRs, for example, one or more DL/EDL DRs and one or more relational database (RDB) DRs. NDS may also include other memory components, such as active memory components (e.g., network RAM), separate instructions for initial analysis of data performed on incoming data before or during collection with DR. Can be used to perform analysis on (typically a limited set of step(s)/functions, e.g., relative sets of 50 or fewer, 30 or fewer, 20 or fewer, 12 or fewer, 8 or fewer, or 5 or fewer relative sets. limited to S(s)/F(s)).

A “data warehouse” is typically defined by its size, storage time, information sources (a data warehouse pulls from multiple sources and integrates this data), structure, and functionality (for example, whether it is simply recording transactions), It is distinguished from a database by (rather than optimizing information processing). A data warehouse receives related data from multiple sources and, like a database, requires applying a structure (schema) or establishing a structure (schema) before storing this data, which can occur over a long period of time. Components of a data warehouse may feature data marts.

Databases and data warehouses can feature write/write schema systems that require data to be collected in a specific format, converted to a specific format, or both before being stored in DR. In aspects, some or most of the DR content in the NDS, some or most of the DR in the NDS, or both are not write/write schema systems. In aspects, NDS primary memory includes a mix of write/write schema and write/write non-schema DR.

In aspects, some, most, or generally all of the primary NDS memory unit may be a data lake (“DL”), an enhanced data lake (“EDL”) (discussed below), or one of these. It is made up of combinations. A non-contradictory reference to DL or EDL provides implicit support for an aspect (although there are aspects of EDL that are distinct from true DL) that contain a memory structure of that type. In aspects, DL/EDL is structured NDS-MEMU may include a structured portion (a data storage area adapted/configured to, or at least allocated to, maintaining structured records, such as in a database), or the NDS-MEMU may include a physically or functionally separate structured DR portion. This may include, for example, database(s), a data warehouse, or a data mart (e.g., as a component of memory that would otherwise have a DL/EDL structure). In aspects, at least some or most of the NDS memory, generally all or all of the NDS memory, is configured with a cloud data warehouse, such as Amazon Redshift, Google BigQuery, Snowflake, and Microsoft Azure SQL Data Warehouse.

a. data lake

In aspects, an NDS memory unit (e.g., a primary NDS-MEMU) includes, primarily includes, or consists essentially of a data lake DR, an EDL DR, or a DR, including a system that includes elements of both systems. Or, it is generally configured.

In this disclosure, a data lake (“DL”) is a memory structure that allows data in a format not permitted in a data warehouse, database, or similar write/write DR scheme. Data in a DL typically has about 2-4, 2-5, 2-6 or about 2-7 levels of data relationships (e.g. attributes and value; attribute-value-data type; attribute-value-data type-source; or attribute-value-data type-source-time series). DL/DLLR may generally be characterized as primarily, generally, or exclusively using the extract-load-transform (ELT) data processing methodology. In aspects, the DL may store data in native formats (i.e., raw data and unstructured data). In native/true DL, there are no data silos/sorting (heterogeneous data such as structure, type, etc. are all maintained in a unified DR). DL typically receives data from inputs such as data pipelines, stores data immediately regardless of data structure, and supports DL access/application platforms (e.g., Apache Hadoop, Apache Spark, relational database management system (RDBMS)). /SQL or CT) (for example, applying the Hudi or Parquet data format).

Data in a DL structure may be included in one or more electronic data storage devices or structures that hold the stored data, which may be a dedicated device, a cloud-based/on-demand/distributed memory resource, or a CT. In a true DL, data can be stored at least from the way it was received by the DL (excluding, for example, identifier metadata tags applied to some DLs), through the application of a schema, the behavior of a query, or both, or from an application, NDS, or other network. stored and maintained in unmodified format until any subsequent consumption, use or interpretation by a device or network user. In aspects, the DL/EDL resides in a cloud infrastructure (e.g., a private cloud or a public cloud providing infrastructure-as-a-service (IaaS)). In aspects, NDS-Memory includes, primarily, generally, or entirely consists of data lake servers, each data lake server being considered a data lake server node, and all data lake server nodes connected to each other to form a mesh topology structure. forms. An example of a programmable, automatically scalable cloud-based system for DL or EDL cloud memory applications that can dynamically allocate or deallocate memory resources in a parallel and distributed manner, and can be implemented using Hadoop or parts thereof (e.g. There is Microsoft Azure Data Lake Service, which provides applications such as YARN), Spark, and SQL-like query engine(s) (SCOPE/U-SQL). Other applications applicable to DL/DLLR systems known in the art include Hive, Map Reduce, HBase, Storm, Kafka, and R-Server. Other alternative DL management systems in the art include IBM® Watson ^™ or DeepDive ^™ systems.

In aspects, the data in the DL/EDL of the NDS(s) includes a sufficient amount of associated metadata, has undergone a sufficient amount of processing or enhancement, or both such that the data is stored on a specific device (e.g., belonging to or produced by a specific MA), a specific type of MA (e.g., and ECMO or heart pump), a specific entity, a specific MA or group of entities, a specific HCP, or other such specifically identifiable source or characteristic. It may be identifiable. In certain additional aspects, the data in the DL/EDL of the NDS(s) includes sufficient identifying information that can be linked to a particular physiological state, condition, patient or other such specifically identifiable source or characteristic.

In aspects, DL/EDL supports at least about 1 trillion, at least 2 trillion, at least 3 trillion, at least 5 trillion, at least 10 trillion, at least about 20 trillion, or at least about 50 trillion files (file sizes up to 1 petabyte). You can save it. In aspects, the DL/EDL has a capacity of at least 20 petabytes, at least 50 petabytes, at least 100 petabytes, at least 250 petabytes, at least 500 petabytes, or at least ∼1000 petabytes (e.g., about 1-500 petabytes). petabytes, approximately 2-400 petabytes, approximately 3-300 petabytes, or 5-250 petabytes). In aspects, the average or median data latency of DL/DLLR or the latency for most, generally all or substantially all data transfers is -10 minutes or less, -5 minutes or less, -3 minutes or less, -2 minutes or less, ~1 minute or less, 40 seconds or less, 30 seconds or less, 15 seconds or less, 10 seconds or less, 5 seconds or less, or ~3 seconds or less (e.g., about 2-2,000 seconds; 3-1,500 seconds; 3-1,200 seconds; 3-900 seconds; 4-400 seconds; 4-240 seconds; 3-300 seconds; or about 5-300 seconds). In aspects, the average operability of the DL/EDL or primary, normal or substantial operating level for a month, quarter or year is greater than -98%, greater than 99%, greater than 99.5% or greater than -99.9% (e.g. For example, as reflected in memory vendor SLA measurements or other similar measurements).

In aspects, latency in terms of collection, most applications, or both associated with DR may be in most cases, generally all cases, substantially all cases, or on average in the order of seconds or minutes (e.g., ~200 seconds or less). , 150 seconds or less, 90 seconds or less, 60 seconds or less, 40 seconds or less, 30 seconds or less, 20 seconds or less, 10 seconds or less, 5 seconds or less, or ~1 second or less (e.g., about 0.5 seconds or less, 0.1 seconds or less) or less, or about 0.01 seconds or less)).

In aspects, NDS memory also includes a data warehouse component, where the DL or EDL is used as the initial storage/staging area. In these aspects, data flows to the NDS memory from a network input (e.g. primarily MA)/data pipeline to the DL or EDL and then some (usually less than most, e.g. For example, less than about 33%, less than -25%, less than 15%, less than 10%, or less than -5% of the data received in any relevant period (month, quarter, or year) is relayed to the data warehouse. In aspects, a hybrid data warehouse/data lake platform or management tool, such as the commercial SNOWFLAKE™ memory management application, constitutes part of the NDS memory. In aspects, the NDS memory includes a massively parallel analytical database/DR, which, in aspects, can support near real-time results for complex SQL queries (interactive query functionality), but typically stores data prior to storage in such DR. Filter or convert into highly structured data.

In aspects, the DL/EDL may include event-related data or data trends (e.g., medical procedure event data, patient symptom data, patient outcome data, condition progression data, medical complication data, adverse event data, device performance events, patient response events). and other memory structures such as graph databases that store data, etc. However, in other aspects, NDS memory does not have a graph database, reserving memory for other memory architectures and detectably or significantly reducing the complexity of data collection (DoS).

In aspects, the memory unit includes a data compression capability wherein in aspects the DoS enhances the data storage capability of the memory unit. In aspects, data compression functionality is applied automatically or on-demand after collection (and similar decompression is used when the compressed data is accessed/consumed). In aspects, compression provides capacity improvement of at least -2 to 1, at least -3 to 1, at least -5 to 1, or at least -10 to 1.

The DL of the NDS of the present invention is typically dependent on a query application (e.g., using the query/search component of any of the aforementioned platforms), and the resulting data can be used for presentation, further analysis, or processing, as discussed elsewhere. For both, it optionally depends on a schema to organize the resulting data. Aspects of data lake technology, applications, etc. that can be adapted to DL/EDL applications include, for example, US20200380169, US20180373781, US20190370263, US20200210896, US20200193057, US10846307, US10706045. No. US10572494 Nos. US10545960, US10795895, WO2018236341, CN111221526, CN111460236, CN111221887, CN111221785 and IN919CHE2015A. Additional aspects related to the application of somewhat enhanced DL (time series metadata and other unspecified enhancements may be applied to facilitate query application) are described in US20180082036.

b.EDL

In aspects, the NDS memory unit(s) include, mostly/primarily consist of, essentially consist of, or generally consist of enhanced data lake (“EDL”) DR(s). “EDL” generally refers to (1) data stored in an EDL in a DR organized into governance zones, structured DR zones, or both; (2) impose minimum rescue requirements on some, most, generally all or all incoming and stored data; (3) It differs from “true DL” in that it does both (1) and (2). In aspects, when EDL DR collects data into an EDL, the collection process(s)/function(s)/unit(s)/engine(s) may (a) collect any abnormalities about the data prior to storing it in the EDL DR; Use improvement processes (e.g., data review and correction processes); (b) impose new metadata tags on the incoming data, impose one or more structural requirements on the incoming records (records), or both, so that, for example, there are ~7-8 records stored in the EDL; Contains more than one data attribute; (c) characterize data and target/locate records/data to EDL into one of multiple data governance zones according to different policies; or (d) any combination thereof. Despite this imposition of improved data structures on EDL data, EDL also has (a) the ability to receive unstructured/semi-unstructured heterogeneous data; (b) storing different types of data in a single integrated collection; (c) configure schema data to read by default, generally, or only; or (d) any combination thereof.

“Ingestion” is understood in the art as the process(es) of receiving and storing data/records in a memory system/device, such as a DR, and the process(es) associated therewith. Properties that can be assigned to data/records in the EDL collection process include, for example, data type (e.g. video, text, etc.), feature and associated attribute data (e.g. MA type feature/attribute data), time series May contain data or query response tags/elements. In aspects, the EDL collection process includes most, typically all or all MA-Ds: (1) MA-D source data, (2) event-related (log) data, (3) cache-to-RT MA data characteristics, ( Associated with one, some, most, or all of the following: 4) alarm data, (5) MA operational state data, (6) MA-D type data, (7) privacy/RR requirement indicators, and (8) MA entity owner data. It is necessary to become Imposing these requirements on the data during the EDL collection process is intended to distinguish EDLs from actual DLs and seriously or imperceptibly impair/delay SMAD's needs for collection, querying processes, or both. The performance of NDS with EDL DR can be significantly improved without placing significant demands on the NDS processor(s)/system(s).

In aspects, data in an EDL is governed by different data management protocols/rules (policies) (e.g., queries applied to raw data or based on regularly run generic schema applications applied at ingestion, Stored in two or more separate sections of the EDL, containing data with different identified characteristics (CT) applied at the time of collection, after the initial collection, or a combination thereof (based on the operation of an on-demand application such as an NDS analysis function, etc.) do. In aspects, one element of some, most, generally all or all of the EDL data governance area definitions is the presence of PHI. In aspects, one element of the data zone governance zone definition is whether the data is subject to curation, scoring, or a combination thereof. You can tag data with policies or apply policies to data that conforms to certain standards (for example, using if/then logic or related logical structures).

In aspects, EDL data relayed as output from the NDS (e.g., NDS-AD) may apply tags/identifiers to data records containing PHI (e.g., commercial/commercial user class associated device(s)/ It is stored in different governance areas according to different policies, including tags that work with other components to block access to or transmission of such data in unrecovered or unmodified form on the interface(s). In aspects, a portion of the EDL consists of or is associated with an element of an NDS-MEMU, such as a database or data warehouse, e.g., configured as a data mart component of the EDL, which provides a material amount, most, generally all or substantially all All structured data is NDS-AD or a subset thereof or data related thereto (e.g., in response to a query or otherwise to a schema application applied to unstructured/semi-structured data in other parts of the EDL or DR).

In aspects, NDS may include engine(s)/component(s)/system(s) for data grouping and separation functions. In aspects, an NDS may include a plurality of data sets or data that may be characterized as identifiable as belonging to a particular data subset. For example, in aspects, an NDS may include (a) data about MAs in a particular country, (b) country-specific data governance rules, and (c) system blueprint data shared with one or more other NDSs. . According to embodiments, NDS-MEMU may include (a) SMAD, cache data, or both; (b) selected data, scored data, or both; (c) system test data; and (d) include a separate governance area that governs the storage, use, and access of outgoing data. These function(s) may, for example, apply meta tag(s) to records/data, identify record(s)/data matching certain characteristics (e.g., analyze if/then structures, etc.), or It can be performed by a combination of.

In aspects, the EDL only allows data containing properties and value/function like relationships of a particular set type or stores only data containing properties and value/function like relationships of a particular set type in a particular data governance area. In aspects, the NDS monitors whether the NDS receives and stores data that has relationships such as certain attributes and characteristics to the EDL and notifies the administrator that such data is not received. In aspects, EDL allows only data that contains certain data structures (e.g., only semi-structured datasets, such as JSON data or other semi-structured data formats, discussed elsewhere) or allows such structures in certain areas. Store only the data you have. In aspects, the EDL allows for multiple data structure type(s) but separates the data in the EDL into multiple governance/content areas of the EDL based on data structure, for example.

In aspects, data structure requirements or transformation processes apply only to certain types of data streams, and other data streams/input(s) are handled in less regulated matters (similar or more similar to traditional DL). For example, in aspects, a structural requirement, transformation, or both are placed on one, some, most, generally all, or some, most, generally all, or all of the MA-D data/streams, but not others. The format's input is not subject to these structural requirements or transformations. For example, in aspects, the NDS may receive input via email, other messages, note applications, web page data, etc., or via an external data store/application (e.g., CMSS(s)), such as Data may include unstructured data or semi-structured/structured data whose structure is subject to change not under the current or former control of the NDS owner. Video data, image data, audio data, or a combination of these data may be received by the DL/EDL in native format, in a format requiring compliance with specific standards, or both.

Ingesting data into an EDL involves, for example, receiving data stream(s) (e.g., including bursty data streams) and transforming such incoming data prior to storage (during collection/pre-collection). applying (s) or imposing structural requirement(s), and typically adding structure/schema to the stored EDL Data prior to (post-collection) some, most, and generally all or all application/consumption of such Stored EDL Data; This may include imposing a . As discussed elsewhere, data transformation may include the application of a data improvement unit (DIU) for, for example, initial data harmonization, data cleaning, data validation, etc. Data transformation step(s)/function(s) may also include application of metadata; For example, curation of data into content/metatag-based governance zones; Or it may include CT. Data transformation may include applying encryption (e.g., applying SSL to data in motion or applying HSM-enabled keys to data “at rest” in an EDL).

Access to EDL data may require authentication (e.g., multi-factor authentication), and EDL management functions may include role-based access control (e.g., through POSIX-based access control). The EDL management function(s) may further include auditing access or configuration changes to EDL data (or to other aspects of the NDS or to the NDS generally).

Data containing personally identifiable information (PII), PHI, or both can be identified in the data collection process and DIU uses tokenization, for example, using format preserving encryption (FPE). You can encrypt this data or other confidential information. In aspects, some, most, generally all or all of the metadata that applies to the incoming data is automatically generated from data input to the EDL based on pre-programmed rules.

Like DL in general, EDL describes data through a schema, typically containing ~7, 10, 12, 15, or 20 or more related data elements for each record identified in the data. Can be subject to queries and schema applications (e.g., applied by analysis unit functions) that apply additional structure to the query-identified records, for example 100s; 1000 units; 10000 units; 100000 units; Or, for example, it could represent a number in the 1000000 range. EDL management functions may further include messaging functions, logging functions, reporting functions, export functions, crawler functions, machine learning modules, or any CT. In aspects, the EDL functionality includes one or more natural language query functions to also query features based on specific attribute/field relationships or other data entries/types. A data improvement unit (DIU) may apply processes to incoming or stored data that normalize, enrich, or tag data streams or stored data. In aspects, the DIU process applied to the incoming data/stream does not appreciably or significantly (“DoS”) affect latency.

In aspects, the NDS/MAC-DMS processing unit transforms the MA-D, imposes requirements on the MA-D, or both such that substantially all of the MA-D datasets stored in the enhanced data lake are medical device source identified. information, MA-D type information, and one or more physiological parameter datasets, each optionally represented in a preprogrammed MAC-DMS-recognizable standard format, the enhanced data lake as described above. It includes different data governance zones based on the source or content of the MA-D dataset stored internally, analysis data, or both.

2. NDS processor(s)

NDS is a processor unit(s)/system(s)/component(s) (also called NDS-PROCU or NDS processor), which is a device(s)/system(s) capable of executing (reading) NDS CEI stored in NDS memory. includes). Like NDS memory, NDS may include multiple processor units that may be physically or functionally separate from each other. These separate processing unit(s)/system(s) may form individual/interoperable processors, or the NDS may comprise multiple processing unit(s) operating separately from each other at least part, most or all of the time. You can. For example, in aspects, the NDS may include (1) a streaming data processor (SDP) unit/engine/system (a.k.a. SDP or SDE) that performs, for example, initial analysis tasks on incoming data and collects NDS DR data; and a first processor(s) associated with separate second (primary) NDS processor(s) for processing (e.g., performing NDS DR queries, generating NDS-AD and managing NDS output, etc.).

Although an SDP is often described as a “processor,” herein and in the art, an SDP may, in aspects, lack any separate physical processor device(s)/component(s) (e.g., an SDP may lack the main /may include engine(s) operating in conjunction with separate processor(s), such as an overall system processing unit). Accordingly, an SDP may alternatively be described as an engine (streaming data engine (“SDE”)) or a streaming data unit (“SDU”). In aspects, the SDP includes physical processor component(s) separate from other processing unit(s) of the NDS. Each of these different aspects is implicitly provided by any disclosure of the SDP.

The NDS processor may have any suitable feature/component(s) to perform the functionality of the NDS or applicable NDS component in accordance with the features/aspects described herein. Typically, we receive a large amount of data from multiple MAs in different MA groups (and for different types of MA, different patient types, different treatment protocols, etc.), analyze these data, and share these data with HCPs and Given NDS's role in providing services to other MA users and other system components, an NDS processor may (a) include significant physical processing capabilities that far exceed the typical processing capabilities of any single laptop/desktop general purpose computer; (b) may include engine(s)/unit(s)/component(s) using specialized data management methods to ensure immediate processing, analysis and relaying of data; Or (c) may include both (a) and (b).

In aspects, the NDS processor includes a workflow architecture that can be characterized as including massively parallel processes/very large workflows (e.g., such term may be used in connection with leading cloud-based systems such as Microsoft Azure systems). as understood in the art). For example, in aspects, the number of cores/processors of a multi-core MA can be -10 or more, e.g., -20 or more, -50 or more, -100 or more, -200 or more, -500 or more. or more than ~1,000 cores, such as ~2,000 cores, 5,000 cores, 10,000 cores, 12,500 cores, or ~15,000 cores (e.g., ~1,000-20,000 cores, 1,000-15,000 cores, 3,000-18,000 cores) , 2,000-16,000 cores or ~2,500-15,000 cores). In aspects the NDS processor is comprised primarily, generally only or entirely of cloud-based processor capabilities/functions. In aspects, the NDS processor operates based on a scalable, massively parallel and distributed processor architecture.

Massively parallel process (MPP) functions/methods can be achieved using massive system stage functions, such as Amazon Web Service (AWS) stage functions. Microsoft Azure services also include MPP functionality. In aspects, the NDS is configured such that some, most, generally all or substantially all analysis functions performed by the NDS processor(s) complete within ~30 seconds or less, ~10 seconds or less, or ~5 seconds or less. (at all times, on average, or at peak operating capacity) >100, >150, >200, >500, >1000, >2000, >5000, or >10,000 architectures that include processor/memory combination(s). The MPP architecture available on NDS processor(s) typically includes interconnected data paths. In aspects, the NDS processor has a grid computing MPP architecture, a computer cluster MPP architecture, or both.

In aspects, one, some, most or all NDS processor(s) may be “highly available” or characterized as including “highly available” workflow(s). In aspects, the NDS or a component of the NDS has availability (accessibility and standards) of at least 97%, at least 98%, at least 99% over a period of time (e.g., quarterly, annually, 3 years, 5 years, etc.). /optimal operation), and in a more specific embodiment, a high availability NDS represents availability of ˜99.8% or greater, ˜99.9% or greater, ˜99.95% or greater, or ˜99.999% or greater. High availability can be achieved by any suitable method(s), including general means, message queues, Lambda retry functions (e.g., in AWS), or CT. Common resources/architectures for high availability include applying component redundancy, component monitoring and management, failover (node/process replacement/routing), use of distributed replication volume(s), load balancing, or a combination of these.

In aspects, the NDS processor(s), such as an MPP NDS processor, exhibit a bandwidth of at least -100 GB/sec (e.g., at least -150 GB/sec, at least 200 GB/sec, or at least -250 GB/sec). In aspects, the NDS processor exhibits processing above -2 GHz, above 2.5 GHz, above 3 GHz, above 3.33 GHz, or above -3.5 GHz. In aspects, the NDS process may perform/process more than ˜50,000 transactions/events per second, more than 75,000 transactions/events per second, or more than ˜100,000 transactions/events per second. In aspects, the NDS processor is capable of operating at most times, generally all the time, substantially all the time, or on average (e.g., between about 0.5-12.5 petaFLOPS, e.g., 1-15 petaFLOPS, 1-20 petaFLOPS, 2-5 petaFLOPS). 50 petaFLOPS, 2-80 petaFLOPS, or between about 5-100 or 10-120 petaFLOPS, etc.) greater than ~0.5 petaFLOPS, greater than ~1 petaFLOPS, greater than ~2 petaFLOPS, greater than ~3 petaFLOPS, greater than ~5 petaFLOPS, greater than ~10 petaFLOPS Or operates at ~25 petaFLOPS or higher.

In aspects, the NDS processor may include a partitioning function, a processor power scaling function, a processor resource reservation function, a checkpointing function, a data queue-based processing function, an error recovery function (e.g., for a redundant processor error function), or Contains CTs that can detect or significantly improve the performance of the processor.

Methods, functions and data structures related to parallel processing systems (including MPP systems); and other related principles, many of which are adaptable to embodiments, in US5485627, US8799284, US8583896, US10802929, US5404562, US4727474, US5765181, US9239741, US10339235, US8903841, US5230079, US4380046, US7716336, US9569493, US10147103, US5799149, US6185693, US8903841, US5566321, No. US20030110230, No. US20080034157 , US20170270165, US20090031104, US20030195938, US10078565, US20170180272, US20130111188, US20200167362, US5881227, US5103 No. 393, US8799284, US20170270165, US20200364226, Nos. US20150120368, US10372696, US10565199, US6098178, US5103393, US5511221, US6957318, US5146608, US20100287557, US10303654, US9910821, US9697170, US5390298 No. US5008815, US5872987, US5253308, US8108718, US6185693, US9448966, EP0456201, EP0381671, CN103778212, CN103237045, KR1016 No. 32253, No. KR1020140063279, It is described in No. KR1020170056773, and No. KR101083052.

Parallel processing may include or perform architectures of distributed parallel processing, non-distributed parallel processing, or both. “Distributed processing” generally refers to processing performed on physically separate but networked machines. Non-distributed parallel processing can be performed on interconnected and co-located cores. Parallel processing systems may include systems that can be classified as clusters, grids, clouds, or combinations of these. In aspects, the NDS processor includes heterogeneous software, heterogeneous hardware, or both, or operates over a heterogeneous network (e.g., in terms of components, layers, communication protocols, and other aspects of topology). In aspects, the NDS processor, NDS memory, or both are dynamic systems (varying over time) in terms of software, hardware, or both.

The NDS, the network, or both may include or use routers, which may include networking/communications equipment configured to provide internal and external communications. The router includes network communication between NDS component(s) (server processing unit(s)/device(s)) and NDS memory (data storage) via local cluster networks, and NDS/NDS component(s) via communication links across the network. ) (e.g., a server cluster) and other devices, or both, may include packet-switching and/or routing device(s)/unit(s) (including switches and/or gateways) configured to provide network communications between You can. The router is designed to handle the network's data demands, data storage, latency, availability, and throughput of the NDS/network and other factors that may contribute to cost, speed, fault tolerance, resiliency, efficiency, and/or other design goals of the network/NDS architecture. It may be selected for functions that perform processing, composition, or both. The router(s) of the NDS/network may include security capabilities such as VPN, firewall, etc., and may also include multi-protocol label switching capabilities. Such routers are known and include, for example, the Cisco Catalyst 8000V router, Cisco Catalyst 9000 router, etc. In aspects, the router has scalability capabilities that can be modified in response to instructions from the NDS. In aspects, a router is coupled with a LAN switch with similar capabilities. In aspects, some, most, generally all, essentially all or all routing, switching and similar functions are performed by a software-defined wide area network component/unit (SD-WAN appliance), which may be a custom component.

In a distributed computing environment, such as may exist in a particular NDS, program modules or subroutines may be located in local or remote memory storage devices. Programs or program modules used in a distributed environment may be distributed electronically over the Internet or other networks (including wireless networks). In certain embodiments, the DR(s) are stored, in whole or in part, and the processor function(s) are utilized via a cloud platform such as Microsoft Azure or AWS. A distributed processor system(s)/component(s), which may comprise some, most, typically all or all parts of an NDS processor, may make use of distributed memory, whereby, for example, the processor is given chunks of memory space. Receive and communicate through message passing or similar methods. In this aspect, each processor can access local memory directly and indirectly access non-local or remote memory chunks.

In aspects, the NDS engine(s)/component(s)/unit(s)/system(s) may be used to largely, generally, essentially or entirely outsource computation, data storage, communication and service hosting operations. Based on cloud networks/remote server devices (e.g. integrated/connected server cluster(s)). Such server(s) may be virtualized (i.e., the server(s) may be or include a virtual machine). Examples of public cloud networks include Amazon Web Services (AWS) and Microsoft Azure services. NDS may include a network management platform and server cluster(s) that support public cloud networks providing load balancing, redundancy, high availability, scalability, etc.

In aspects, NDS may include a virtual machine/server (emulation including memory, processing, and communication resources) that may be implemented by computer device(s), server cluster(s), etc., which typically have an NDS controller. It is managed by centralized server devices, applications, etc., and can be selectively accessed by authorized NDS administrators. Virtual machine systems through Microsoft, VMWare, etc. are known in the art and can be applied to these applications.

In aspects, the hardware of the NDS processor may include specialized node(s) for optional analytics functions, which may include GPUs, specialized data search/mining units, etc., which in aspects includes non-cloud dedicated hardware units. It can, however, interface with cloud-based memory/processor components. In aspects, the processor functionality includes FPGA(s) where DoS lowers processing bottlenecks and DoS/DOS accelerates one or more functions (e.g., search operations). In aspects, some, most, or generally all processing components include multicore, multithreaded, or GPU processors. In aspects, the processor may have between about 2.5-25, 2.5-15, 2.5-12 or between about 2.5-10 (e.g., ~1-10, ~2-12, ~1-5, ~2-6 or ~2-10) Indicates the precision of teraFLOPS. In aspects, the NDS processor/system has a memory bandwidth of at least 100 GB/s, such as at least 125 GB/s, at least 150 GB/s, or at least 200 GB/s (e.g., a bandwidth between about 50-250 GB/s, For example, ~100Gb/s InfiniBand). In aspects, the NDS processor includes, primarily includes, or generally includes cores with at least 100, at least 200, at least 300, at least 350, at least 400, or at least about 500 GB of RAM. In aspects, the NDS processor has a base clock speed of at least 2 GHz, at least 2.5 GHz, at least 2.75 GHz, at least 3 GHz, at least 3.2 GHz, at least 3.4 GHz, at least 3.5 GHz, at least 3.6 GHz, at least 3.7 GHz, at least 3.8 GHz, or Contains, mainly contains, or usually contains cores greater than ~4 GHz. In aspects, the MPI latency of the NDS processor is, on average, most or generally less than -5 seconds, less than 2 seconds, less than 1 second, less than 0.25 seconds, less than 0.1 seconds, less than 0.01 seconds, or less than -0.005 seconds. In aspects, the node connection includes a gigabit switch, e.g., a switch supporting link speeds greater than -25, greater than 35, greater than 40, greater than -50 Gbps, greater than about 75, greater than about 85, or greater than about 100 Gbps.

In aspects, processor unit function(s)/engine(s) may include data scheduler(s) (e.g., Mesos, YARN, or Sparrow data scheduler). In aspects, the data scheduler of the NDS processor may be configured to be configured to be ~10 seconds or less, ~5 seconds or less, ~2 seconds or less, or ~1 second or less (e.g., ~0.5-7.5 seconds, ~0.25-5 seconds, or ~1-10 seconds). has a response time of seconds). In aspects, the DMS of the NDS processor includes a High-bandwidth Ultra-Low Latency (HULL) architecture. In aspects, the processor unit function(s)/unit(s)/engine(s)/system(s) includes a streaming data processor (also referred to as an SDP, SDE or stream processor), which in aspects is an NDS input unit. /Can also be classified as a component of the system. In aspects, a stream processor may perform stream processing functions such as maps, filters, joins, aggregation functions, and other data transformation functions (e.g., available in Kafka Streams). The SDP, the base processor, or both may include engine(s) for assembling time series and other suitable collection data, for example from the MA-D. In aspects, reassembly of the cache data and associated time series RT MA-D is performed largely or entirely external to the SDP (e.g., a primary processor or a special processor/engine) to reduce data processing burden on the SDP/SDE. Reassembly of the cache RT MA-D is discussed elsewhere.

Interconnection of components can be facilitated through Ethernet, fiber optic cables, Wi-Fi, or other suitable connections/topologies/methods. Processing functions include mapping functions for CEI and other data, scheduling functions to perform tasks (including, for example, data collection as discussed elsewhere), or both. Network interface(s) may also be over one or more non-Ethernet mediums, such as coaxial cable or power lines, or over a wide area medium such as Synchronous Optical networking (SONET) or digital subscriber line (DSL) technology. Can support communication. Processing functions may also include virtual machine monitor/control, APIs for user control of NDS memory systems/units, etc. Other functions that can be executed by the NDS processor are described separately herein (e.g., input functions, memory functions, analysis functions, and relay functions) (for process clarity, these functions are sometimes referred to herein as analysis units, input units, etc.). associated with the same specific unit/phase). Related processing functions that can be implemented by NDS processor(s) are discussed elsewhere (e.g., using NoSQL or Hadoop for data collection and management in NDS DR). In aspects, processing is managed through parallel processing in most, generally all, or substantially all cases. In aspects, batch processing is used by the NDS processor(s) for a particular process. These data processing methods are discussed further elsewhere. In aspects, NDS processing includes bulk synchronous parallel (BSP) processing component(s)/function(s)/engine(s). Other function(s)/component(s) of the NDS (and the network, if applicable) used to provide the architecture/functionality of the system/network described herein may also or alternatively include, for example, virtual switch(s) , virtual bridge(s) (e.g. to NIC), virtual adapter(s), NAT service component(s)/system(s)/engine(s), router(s)/router table(s), DNS /CSP system(s), subnet system(s), traffic monitor/manager, traffic filter(s)/firewall, etc.

3. NDS Security Engine(s)/Unit(s)

NDS includes security unit(s) (system(s)/component(s)/engine(s)) containing security component(s) which may be hardware components, software components/engines or a combination thereof (CT) can do. The NDS Security Unit (also referred to as NDS-SECURU or “NDS Security”) may be or include any combination of elements that provide one or more data security functions at the network level.

In aspects, NDS security includes firewall(s). In aspects, the NDS firewall functionality includes one or more packet filtering firewalls (eg, stateless packet filter firewalls). In aspects such a firewall includes a protocol for checking packet data against access control list(s), and a protocol for dropping/blocking unauthorized transit packets, forwarding authorized packets, or both. In aspects, the NDS firewall(s) utilize Stateful Packet Inspection (SPI) (aka, dynamic packet filtering). In aspects, the NDS firewall(s) include a proxy server firewall (aka application level gateway), ie, masking network IP addresses, restricting data traffic types, or both. In aspects, the NDS firewall(s) include circuit level gateway(s) (i.e., ensure a secure connection). In aspects, the NDS security unit includes a deep packet inspection firewall, which detects some, most, generally all, substantially all or all incoming packets, some, most, generally all, the TCP handshake, or both. Analyze substantially all or all payload content. In aspects, the NDS security firewall performs both surface and deep packet inspection in an ordered manner, based on packet analysis, or both. In aspects, the firewall function(s) also perform anti-virus scanning/protection functions, spam filtering functions, application control functions, or a combination thereof. In aspects, the NDS security unit may automatically and automatically respond to increased traffic load, generally independent of the scalability of other NDS elements, e.g., processing power or memory capacity, or other expansion(s) of NDS capabilities, e.g. Alternatively, use cloud firewall(s) (aka firewall-as-a-service (FWaaS) capabilities) that are scalable on-demand, for example, available through Microsoft Azure services. The NDS level firewall(s) may also or may otherwise be a web application firewall, which may be hardware or software based.

In other aspects, NDS security may include data encryption capabilities, anti-virus capabilities, authentication capabilities, data exclusion/redaction capabilities, or optional CT, aspects of which are described elsewhere herein (e.g., methods, (in relation to NDS memory or MA). .

4. NDS input engine(s)/component(s)/unit(s)

The NDS includes at least one NDS input unit (NDS-INPU or NDS input). The NDS input unit typically includes a combination of hardware component(s) and engine(s) that handle the reception of data from external sources and initial processing of this incoming data leading to memory component/system data storage (collection).

In aspects, an NDS input unit or component/alternative thereof (e.g., SDP/SDE) may process data received from some, most, generally all or all MA, other inputs (e.g., ONDI), or both. Evaluation(s)/analysis procedure(s) can be performed. In aspects, this “initial analysis” step is performed primarily and generally only in MA-D. This initial analysis process may be distinct from other NDS analysis processes, for example (e.g., performed by an analysis unit on DR data, or both). In one aspect, the NDS input unit may determine, upon initial analysis, whether the MA-D received from the MA(s) is NRT/RT-MAD, cache data, SUMAD, or both. These functions may be performed by known techniques such as data time synchronization and time series data matching/analysis, for example. In aspects, the initial analysis may include MA-D analysis of pre-programmed patterns, indicators, etc. that require immediate action based on incoming data, even before full data collection. In aspects, these pre-programmed patterns may be programmable, modified by a machine learning process, or both. In aspects, the NDS input unit may operate in conjunction with or include a controller system/engine/unit that sends control commands to the MA, ONDI, or both. In other aspects, the NDS generally analyzes data only during or after collection into NDS memory, with substantially no initial analysis performed. In some such aspects, the NDS may also include a stream processor that receives the SMAD.

The NDS input unit (NDS-INPU) may also include a buffer unit/function, which may store any data received via the incoming data source/stream until capacity is available for initial analysis, initial transformation and other aspects of collection. Maintain excess data. A scalable system to evaluate scaling or scaling resources to accommodate incoming data loads such that buffering at or above one or more thresholds does not significantly increase latency over a period of time (e.g., days, weeks, or months). Signal(s) can be provided to.

The NDS input unit may, most of the time, generally or substantially always, process multiple data streams simultaneously, e.g., a stream of TCP packets, using a plurality of processing system(s)/function(s), e.g., as discussed below and elsewhere. It can be received/processed through . Such NDS input units may be or include, for example, streaming data processors (SDP/SDE), as discussed further below and elsewhere.

The input received by the NDS input unit may be in any suitable format (e.g., text/alphanumeric data, tabular data, video data, audio data, image data, or any suitable combination thereof). In aspects, some input, typically less than half of the input, e.g., a significant, significant, or other amount (in terms of file number, data size, or both), may be unstructured data (e.g., emails, web pages, etc.). ) may be in the form or form of. In aspects, most, generally all or substantially all input received by the NDS has a semi-structured format (eg, CSV, JSON or Avro data format). In aspects, the input of most, generally all or substantially all data type(s) (e.g., MA-D) is in JSON format.

Input can be processed by batch processing, real-time/streaming processes, or both. Aspects of batch and real-time/streaming data are described elsewhere and below. The NDS input unit typically applies batch processing to both processes, e.g. cached data uploads, and real-time/to-D for MA-D most or usually when the MA is online (in substantially continuous communication with NDS). Applying stream (streaming) (RT/S) processing can be performed. Batch processing can also be applied to event/log data from network components, including MA, for example. In aspects, the NDS includes, at least in part, a unit specifically designed for cache data analysis (cache MA-D processing unit). The cache MA-D processing unit/engine may be part of a broader component of the MA, such as an MA processing unit. In aspects, the Cache MA-D engine/processor includes coded functions, routines, etc. that specifically analyze the Cache MA-D. In aspects, the cache data processor/engine/system is at least partially separate from other processor(s)/engine(s)/unit(s) of the NDS. In aspects, this cache processor/engine provides information regarding whether or not the processor/NDS has received, analyzed, or utilized cache information (e.g., provides status information, alarms, etc. from the MA that relayed cache data to the NDS). by relaying to network device(s).

In aspects, the NDS/MAC-DMS processing unit evaluates whether a received cache MA-D of a medical device is combinable with a received streaming MA-D of the same medical device, and the MAC-DMS processing unit determines whether the cache MA-D and if it is determined that the streaming MA-D is combinable, combine the streaming MA-D and the cache MA-D to form a mixed MA-D dataset, where the MA-D analyzed by the analysis unit is the mixed MA-D Contains data sets. Combining a cache MA-D with an associated streaming MA-D typically involves evaluating the temporal components of one, but typically two, streaming MA-D datasets and the endpoints of the cache MA-D dataset. This involves determining whether there is sufficient proximity to the timepoint/endpoint to combine. This evaluation may include generating a putative match, evaluating the quality/readability/analyzability of the putative match (combined cache/streaming MA-D). In this or other aspects, the NDS processor (or component thereof) evaluates the usefulness of the cache data for an analysis process, the suitability of storing the cache MA-D in NDS memory, or both.

Where appropriate, analysis and combination of cache data of a particular MA and data/records by an NDS such as RT-MA-D may be performed by any suitable data linking and assembly method. Many such methods are known and are therefore only briefly described here. In aspects, most, generally all or all MA-Ds (cache data and RT-MA-D) relayed from the MA will include temporal information and device identification information (which may be considered an entity identifier). . In aspects, processor(s) of the NDS, such as a cache data processor, include engine(s) that identifies common entity identifier information, time of capture/transfer information, and combines such information, such as cache data and MA-D. Use it as a criterion to decide whether to combine. In aspects, the MA-D may include two or more or three or more identifiers with which the NDS component(s)/system(s)/engine(s) are pre-programmed to identify, compare and analyze similarities/matches in such evaluation. Includes. In aspects where there is no time gap between the RT MA-D and the cache data, a join/merge process may be used to reassemble the data from the MA-D.

In aspects, the NDS may be used when data does not match based on data/record identifier(s), but the data is expected/known to be related/similar; If there are gaps in the time series of your data; or engine(s)/CEI to evaluate both. These methods may utilize/incorporate known record/data linking/matching methods/functions or tools available in the art.

In aspects, the engine(s) involved in data/record linking decisions may utilize a deterministic algorithm (e.g., reject a match unless 1, 2, 3 or more entity identifying data markers are present, match time series information, or both). ) is used. In aspects, such engine(s)/system(s) or other NDS component(s) may also or alternatively use a probabilistic data/record linking strategy (e.g., (1) the discriminatory ability of each identifier and (2) Evaluating the likelihood that two records are a true match based on whether they agree or disagree on various identifiers). The weight assigned to the agreement or disagreement for each identifier is the probability that a true match agrees with the identifier (e.g., the "m-probability") and the probability that a false match randomly agrees with the identifier (e.g., the "u-probability"). By comparing the “probabilities”), it can be evaluated as a likelihood ratio. For example, the EM algorithm is an iterative approach that estimates m- and u-probabilities. For example, Dusetzina SB et al., September 4, 2014, Overview of record linking methods. Source: ncbi.nlm.nih.gov/books/NBK253312/.

These function(s)/step(s) may include, for example, binary/pairwise supervised classification, clustering processes, probabilistic data linking processes, etc. These processes may include metastatic/non-metastatic screening functions/processes. In aspects, this process/engine(s)/function(s) includes a collection entity resolution technique.

In aspects, such function(s)/engine(s) include protocols/algorithms for protecting confidential information, e.g., PHI, in networks containing multiple patient, IE, or user classes (e.g., commercial class users). do. In these aspects, matching data may be relayed to some, most, or all client devices (e.g., MAs), but details of the underlying data are not relayed. Cryptographic methods such as Bloom filters or other cryptographic techniques described elsewhere may also or alternatively be used in these processes to protect confidential information.

In aspects, the engine(s)/component(s)/system(s) may include step(s)/engine(s) for evaluating data/records and parsing/blocking records that are more likely to contain similar sets of matches. s)/algorithm(s) involved, and therefore different approaches are used to measure similarity. In aspects, the smaller/parsed data set may be cleaned or removed in most, generally all or all cases prior to further potential linkage analysis. In general, identifying similar records in different sets can reveal links across datasets that facilitate cleansing, knowledge discovery, or reverse engineering that can contribute to master data aggregation. Thus, for example, the engine(s) involved in this process may, for example, consider the data type and use this information to base/compare/evaluate (e.g. a simple distance function for numeric data, "distance" Blocking, similarity scoring and coarse matching step(s)/function(s)/code can be applied as known in the art to determine the basis for (string comparison rules to identify, etc.).

In aspects, the engine(s)/component(s) involved in record matching in this context or another context (e.g., in a query process) may include an NLP engine(s)/algorithm(s) (e.g., Term Frequency, Inverse Document Frequency (or tf-idf)) is used. NLP methods are discussed elsewhere. TIF and similar algorithms split text into 'chunks' (or ngrams), count the occurrences of each chunk for a given sample, and then apply weights to them based on how rare the chunk is across all samples in the data set. . These algorithms are integrated into the ngram function of any programming language/platform available or adaptable to the system of the present invention. In aspects, a close match is also or alternatively found via a cosine similarity method.

In aspects, the NDS may utilize internal libraries or other information sources (e.g., third party databases, IE databases, or EMR/EHR information) to fill the gap. In aspects, the gap is filled from the MA, similar MA, or related MA-D of the MA IE owner.

In aspects, fuzzy matching methods known in the art are used for comparison/data linking. Such methods are known. For example, the Python Pandas package (Pandas) provides tools for evaluating and merging matching data (merge_asof). Pandas can also be used to work with time series data, typically for example a pandas.DataFrame object can contain multiple quantities, each of which can be extracted into individual pandas. The Python fuzzymatcher library provides an interface to concatenate two pandas DataFrames together using probabilistic record concatenation. The Python Record Linkage Toolkit provides a set of functions to automate record linkage and perform data deduplication (using data blocks, a number of algorithms for measuring string similarity, ranking matches using scoring algorithms, using supervised machine learning in the process, etc. )do. Similar tools/methods are known or applicable to the NDS process. In aspects, related functions such as data/record linking/evaluation and query functions also take into account schema matching of records/data sets.

Once it is determined that a match exists, the engine(s) uses merge, join or similar functions/actions/steps to combine the related data/records (e.g. matching cache data and RT-MA-D of MA). Bring together/reassemble. These features are well known in the art and are available in common programming languages and commercial systems. For example, Python Pandas includes high-performance in-memory join and merge operations, and merge and join statements/applications can be used in SQL (e.g. using the SAS DATA step). Systems such as Azure/Power BI can use SQL functions available through Google Cloud, as well as merge functions that form part of Google BigQuery and join operators in Amazon Redshift. The join may be, for example, an inner joint, right outer join, left outer join, full outer join, cross join, or any other suitable type of join depending on the data to be linked.

In aspects, an NDS or an NDS component, such as a cache processor/engine, performs a method, or starts: (1) if the MA goes offline, collect expected relevant cache data and RT-MA-D from the MA (e.g., within 60, 30, 20, 10, 5, 2, or 1 minute of time based on time series data); (2) compare RT-MA-D and cache data; (3) if the cache data is the same as or sufficiently similar to RT-MA-D in type and time series (based on comparison standard(s)); (a) join/merge cache/RT-MA-D; ELSE rejects merge/join; (4) optionally relaying results to MA/OND; and (5) terminating.

In aspects, most, generally all or substantially all of the NDS's input is processed under RT/S processing. In aspects, the batch job may be performed in the Hadoop/MapReduce framework or similar framework (which may perform map and reduce functions, such as split, map, partition, shuffle, sort, and reduce functions) or elsewhere. It is performed using a framework designed for both batch and RT/S processing as discussed. In either case, especially in routine processing, the NDS input unit takes attribute/value pairs (or key/value pairs) from the incoming data, partitions this data from any associated incoming file/chunk/stream data, or stores it. output a key-value pair or multiple key-value pairs (filtering or demultiplexing functions), optionally combining such output data through a combiner function, performing a partitioning function, performing a reducer function, or a shuffling function. It may include a mapper function that performs or a combination of these. In aspects, batch processing may also be used for analysis functions on stored data (e.g., performed by an analysis unit of an NDS processor). In aspects, some, most, generally all or all of the analysis functions performed on the stored data are performed via a batch processing method. In aspects, the RT/S data delivered to the NDS is specifically for processing streaming data, i.e., Apache Storm or a similar system (e.g., a system capable of processing more than ~1,000,000 records per second per node, Apache Kafka, etc.). In aspects, NDS-INPU includes two, three or more such systems working together in various aspects of the reception, analysis and collection of RT/S data (e.g., a combination of Kafka and Storm). Includes.

Definitions of “real-time processing” vary in the art. In aspects, real time (“RT”) processing generally includes, in all or substantially all cases, NDSs being collected/received and analyzing the streaming MA-D at least initially before/during collection, or using automated functions after collection. Processed only substantially or only in time to enable complete analysis, e.g., (1) most, usually all or all predetermined time threshold data is analyzed, and (2) (a) warning/alarm functions are delivered. or (b) MA device control commands are passed, (c) MA treatment commands are displayed on the applicable MA, or (d) a combination thereof occurs. In aspects, the system in operation is such that the number of output deliveries/applications that would be classified as delayed or output prior to any adverse treatment or diagnostic/monitoring effect is not significant in most, generally all, or substantially all cases. Provides treatment-related information regarding MA control or treatment.

RT/S data collection typically (mostly, usually, or only) involves collection before the next stream is collected to avoid significantly increasing the amount of buffer data for a significant period of time. In aspects, the timing of receipt of RT/S data in the NDS is not substantially or significantly different from the time the initial analysis was completed. In aspects, the timing of receiving RT/S data, completing initial analysis, collecting data, or all three processes is approximately the same.

In aspects, a “RT process” refers to within ~5 seconds or less, ~3 seconds or less, ~2 seconds or less, ~1 second or less, or ~0.5 seconds or less (e.g., ~0.25 seconds or less, ~0.2 seconds or less, or refers to a process that is performed for less than or equal to 0.1 seconds, such as between about 0.1-2.5 seconds, 0.01-2 seconds, 0.05-2 seconds, 0.05-1 seconds, 0.005-1.5, 0.001-1 seconds, or between about 0.0001-1 seconds. do. In aspects, some RT/S data is not stored by the NDS memory other than a buffer or temporary memory for initial RT analysis. In aspects, most, generally all or substantially all RT/S data is collected and stored in the NDS DR. A method of enabling stream processing includes using approximate methods for data aggregation/compression, using random read/write methods (with respect to NDS memory), and stream portions (e.g., a single file per process cycle, It may include a step of fine processing (a small number of records, etc.).

In aspects, NDS input may include email input(s). For example, the NDS may include email stream monitoring U/F(s) (method comprising email stream monitoring step(s)). The email input processing function(s) may include protocols for recognizing attachments, email text, or both. Email and related text messaging formats, web pages, etc. may be used to provide substantive subject data, system data, network data, network component data (e.g., MA-D) or requests for NDS or network components. In aspects, natural language processing (“NLP”) and other processing tools/methods may be used to infer email or other unstructured text message content or intent (eg, NDS service request). For example, the NDS input unit may use subject matter classification (SMC) algorithm(s) that can determine the context of unstructured input data. In aspects, ranking function(s), enrichment function(s), etc.) may be performed on the input to facilitate initial processing of the input (e.g., applying data queues, initial analysis, etc.). . In aspects, the initial input data transformation function is achieved through a larger system level function, such as an Amazon Web Services (AWS) level function or a corresponding function in Microsoft Azure.

In RT/S data processing, the NDS input unit(s) may feature a stream/streaming processing engine (“SPE”) or a stream processing unit (aka stream processor or SDP). May contain component(s)/function(s). SPE can identify cases and events in the MA-D stream, for example in critical care cases, such as surgical and intensive care unit (ICU) cases/settings, among others. In aspects, the SPE includes the type of MA, the specific MA, the medical procedure used, the timing of the medical data, the nature of the MA-D (data type), and the collection type of the MA-D (e.g., RT/S or cached MA). -CD), MA status data, MA sensor or MA-related sensor data (e.g., vital signs data), etc. (e.g., through data transformation or data entry requirements). For example, a time series of MA-Ds may represent status data representing the start of a procedure for a particular MA, the end of a procedure for a particular MA, or a change in patient condition that triggers one or more alarms/alerts based on NDS input unit screening of initially received data. It can be included. RT/S data originating from the same MA, same MA type, same patient, same HCP, same entity, same location or ACT may be tagged or identified as related by the NDS input unit. The NDS input unit applies tags to analyze related data streams simultaneously or to combine the analysis of related data streams to trigger prioritized actions by the NDS, for example in terms of warnings/alarms, MA control, MA protocol information display, etc. can be used to identify clinical cases that meet or exceed certain thresholds/criteria. For example, the MA status data stream, user input data stream, device settings data stream, and operation data stream can be used in aspects to identify when the device is used and how the device is used in the clinical case(s). . This information can be helpful in distinguishing between MAs in maintenance applications versus clinical use, clinical trial use, research use, or a combination of these. In networks that include multiple types of MAs, MAs serving multiple applications, or both, the input data can be used to identify MA-D streams as specific targets, specific HCPs or teams of HCPs, different classes of MA users, specific entities, or combinations of these. can be used to In aspects, RT/S MA-D or other MA-D input may be combined with information from other network/system components, such as MA owner system information, to infer other relationships that may be important in the initial analysis. For example, the MA owner system may include scheduling of procedures using the MA that may indicate how/when the MA is to be used by the entity, for example when associated with incoming MA data, and such information may include: It may be relayed to a research class of user, or back to a commercial class of user (providing modification/exclusion or other protections for PHI consistent with RR). However, these non-trivial analyzes are generally applied to stored data rather than input (data before collection).

In aspects, a stream processing unit, such as a streaming data processor (SDP), may use smallcoreboarding (dynamically scheduling a pipeline so that instructions can be executed out of order when there are no conflicts and processing resources are available), or another alternative. Use other types of message queuing or prioritization methods described elsewhere.

Aspects cause a streaming data processing unit to (a) receive a relayed streaming MA-D, (b) perform an initial analysis on the relayed streaming MA-D, and (c) perform an initial analysis on the relayed streaming MA-D. If D identifies one or more preprogrammed conditions, it may include causing one or more of a limited set of preprogrammed initial functions to be performed, wherein the initial functions include one or more medical devices, one or more other network devices, or both. Contains relay instructions to control the operation of. These functions also start (1) while the MA is operating; (a) Repeat until MA and NDS are not in a secure and stable communication state; (I) receive streaming MA-D from a streaming data processor; (II) perform initial analysis on streamed MA-D; (III) more than 1 condition at initial analysis (e.g., indication of patient risk, device failure, etc.); (A) perform initial analysis output function(s) (e.g., device relay control, such as alarm, @ MA(s), ONDI(s), or both); (B) storing streaming MA-D; (IV) Otherwise; (A) Store streaming MA-D; (2) During termination; It can be written/described as ending.

In aspects, other classes of confidential data, such as data RR, e.g., personally identifiable information/PHI protected under US HIPAA, EU GDPR, and California CCPA/CRPA RR, may be stored in the NDS and NDS output (e.g., data curation , optionally by relay/display, etc.) are individually identified and processed. In aspects, data in study class MA and other study classes OND may include data subject to other data rules, such as blinded/anonymized data rules, randomized data rules, etc.

As indicated, the NDS input unit may include or operate in conjunction with a controller that causes output(s) based on initial analysis performed on SMAD, cache data, or both. For example, streaming analytics function output may include alarm/warning algorithms, control algorithms, event detection algorithms, or prediction algorithms. These algorithms may be predefined or, in other embodiments, may be generated through automatic learning. Non-limiting examples of streaming analytics algorithms include early detection of deteriorating patient health status, detection of complications in the operating room (OR) or ICU, prediction of medical devices requiring maintenance, and prediction of when special care or scheduled delays may be needed in the future. Prediction of complications may be included. In aspects, a stream of MA-Ds may indicate how the MA(s) are being used and, upon initial analysis of data representing the operating state of the MAs, events such as intra-operative complications will be detected and appropriate actions/alarms will be triggered. You can. In embodiments, the streaming analytics U/F(s) predict changes in patient position that may be associated, for example, with gaps in RT/S data flow from the MA-D (and subsequent upload of the cached MA-CD). can be used to

In aspects, a DMS (e.g., a data processing engine) capable of effectively processing both RT/S and batch processing may be a component of or form a NDS input unit. A stream processing engine/SDP may generally "tap" an incoming data stream in a "non-intrusive" manner (without affecting the content of the data stream) and in some aspects without significantly affecting collection latency. . An example of such a system is Spring XD System (Apache). In aspects, the NDS input unit includes or accesses a unit/engine/function (U/F) that can perform several iterative data transformations or analyze steps prior to or concurrently with collection, such as Apache Spark.

In aspects, some, most or generally NDS input unit/engine functionality is performed on data maintained in one or more temporary memory unit(s). For example, in aspects, the method of the present invention includes collecting multiple components of a stream, multiple streams, or both into a temporary memory and storing such temporarily held data (e.g., immediate alert/alarm, performing one or more NDS input unit functions for analysis of data triggering changes in MA treatment operating parameters or both.

In aspects, the NDS input unit(s) or another component of NDS (e.g., NDS relay unit/NDS-RELAYU) is responsible for data serialization/deserialization (e.g., including data serialization libraries, schemas, etc.). Include/perform U/F for management. For example, these U/Fs can convert complex data structures into streams of bytes, typically for storage, transmission, and distribution on physical devices or for storage (e.g., in EDL). In aspects, the serialize/deserialize U/F may prefer data in a particular format or convert to another format where the system limits certain input data. For example, BSON, YAML, or MessagePack data can be converted to JSON data (and vice versa) by NDS' serialization/deserialization functions. Examples of known technologies/frameworks to facilitate serialization include Apache Thrift, Google Protocol Buffers, Apache Avro, and Apache Flume, for example.

In aspects, the NDS input unit immediately performs an in-process/in-memory data function on MA data or other inbound messages (telemetry). In aspects, the NDS input unit performs such data collection and analysis on a limited time repetitive cycle and/or over a limited period of time (e.g., every 5-30 seconds, such as about every 10 seconds or about 5-30 seconds). A second delay (e.g., about 10-20 seconds or about 10-25 seconds) delays action on this data. These features include immediate analysis of specific data leading to activation of device control functions, MA/ONDI alarms, etc.

In aspects, the NDS input unit outputs MA-D about every 1 second, about 2 seconds, about 3 seconds, about 4 seconds, about 5 seconds, about every 10 seconds, or, for example, about every 0.1 second or about every 0.5 seconds. 10 or more packets, for example, about 11 or more, about 12 or more, about 15 or more, about 20 or more, about 25 or more, about 50 or more, about 75 or more, or about 100 or more. , e.g., about 250 or more, about 500 or more, about 750 or more, about 1000 or more MA-D packets, including a data verification rule process based on an NDS input unit receiving packets from MA-D (system /Packet size depending on network properties, for example about 1-100kb, about 1.25-75kb or about 1.5-65kb). In aspects, if these data validation rules are violated, the CEI of the NDS input unit or another aspect of the NDS may trigger an action, such as a warning/alarm function discussed elsewhere.

5. Data handlers (event hub, IoT hub, etc.)

The NDS may include data handler(s) that form part of the input unit, are separate from the input unit, or both. A data handler is generally an engine/unit or method/function that performs data analysis functions, routing functions, event processing functions, or any combination thereof, and is at least partially distinct from the input units and relay units of the NDS. A data handler typically receives telemetry (data/messages) from multiple input sources (e.g. devices) (in the form of multiple input sources simultaneously in the case of thousands or millions of messages per second) and transmits these data to other unit(s). Or often two or more outputs are output simultaneously. Examples of data handlers include analysis engines and event handlers. Analysis engines such as streaming analysis engines, event handlers and similar systems/units are known. In aspects, the data handler(s) include cloud-based unit(s)/component(s).

In aspects, the NDS includes one or more event hub data handler units. An event hub is/contains units that process data at a large scale but low profile (e.g. no advanced sequencing features, delivery guarantees, etc.), typically operating with relatively low latency and high reliability. The input to the event hub can be called an event publisher. NDS's Event Hub and similar components can use various data relay protocols, such as the HTTP/AMQP protocol. In aspects, the event hub(s) includes partition(s) (e.g., 2-32 partitions) (an ordered sequence for maintaining events in the event hub). Partitions (segmented consumer model) allow multiple applications to process streams simultaneously, speeding up and controlling processing speed. In aspects, the event hub only processes data in a one-way manner (does not relay messages to the event publisher, but relays data from the event publisher to the event consumer (i.e., downstream unit)). Event hubs can act as the "front door" to an event pipeline; these event hubs are also called "event collectors."

In aspects, the data handler(s) of the NDS include an internet-of-things (“IoT”) hub(s). NDS's IoT hub is generally capable of performing two-way data communication, as well as functions related to device control, device authentication, device authorization, and protocol conversion and combination. In aspects, the IoT hub performs command and control functions via a connected device, such as a MA. For example, an IoT hub may include preprogrammed instructions for controlling via devices in response to specific conditions (e.g., specific physiological measures of the patient detected by the device(s)). In aspects, the IoT hub may handle device error reporting, e.g., verifying failed connection attempts per device, including disconnecting/disabling connected devices, or both.

In aspects, the data handler may be configured to perform repeating 1-minute, 2-minute, 3-minute, 5-minute, 6-minute or 10-minute data collection cycles/windows (e.g., 30-600 second data collection windows, e.g., 2-8 minute data collection windows). Performs one or more data functions on a time basis, such as the data collection window.

The Apache Kafka ecosystem includes known event hubs that can be used in NDS or as models for NDS event hubs. The Azure system includes both Azure Event Hub and IoT Hub. Azure's big data analytics services, including Databricks, Stream Analytics, ADLS, and HDInsight, can read and process data from the hub. Data handlers may also include event grids, which are units more focused on event processing. The NDS may include any suitable one or more of these types of hubs or equivalents in terms of the functions/capabilities performed.

In aspects, the data handler(s) of the NDS perform both data analysis and event processing functions. For example, analytics engines like Azure Stream Analytics serve as both real-time analytics and complex event processing engines that process streaming data from multiple sources simultaneously. In aspects, a data handler identifies data patterns, data relationships, or both from data from multiple input sources, including MA-D, NDS-AD, and other inputs. In aspects, the analysis function of this data handler may initiate an action, workflow (e.g., generate an alert), provide information to a reporting tool, and store or combine transformed data for later use. Analytics processors typically perform operations involving input, query, and output elements (for example, receiving data from an event hub or IoT hub, performing SQL query language-based queries, or user-defined functions (UDFs)) to filter streaming data. , Azure functions that sort, aggregate, and join data to other components/units, e.g., communicate or trigger custom workflows downstream or data from data stores (e.g., DL/EL, Azure Synapse Analytics, etc.) , relay to service bus topics or queues, or optionally train machine learning models based on historical data or perform batch analysis. You can use elements of SDP such as Kafka, Spark, Storm, and Apache tools such as Flink to perform these functions. Amazon tools such as Kinesis Streams, Kinesis, and Firehose can provide similar services.

6. Analysis engine(s)/unit(s)/function(s)

NDS typically includes component(s) that perform the analysis in MA-D, which is the NDS Analysis Unit(s)/Engine(s)/System(s) (sometimes called NDS-ANALU or similarly NDS Analysis/Analysis). (referred to as a unit) may be characterized. The NDS analysis unit typically consists of the unit(s)/engine(s) of the NDS and associated memory/processor resources that analyze data in the NDS memory, such as the NDS DR. The NDS may include any suitable number of analysis unit(s)/engine(s) of any suitable type(s). In aspects, the NDS includes at least one analysis unit that primarily, generally, or only analyzes (post-collection) DR data. In aspects, the NDS includes an analysis unit that analyzes data prior to collection (e.g., as part of an input unit such as the SDP discussed above and below). Data generated by NDS analysis are referred to as NDS-analysis data (“NDS-AD”). In aspects, the NDS-AD may be communicated to a network component, e.g. a MA or other network/NDS component, and may be the basis for additional analysis functions/methods, such as a higher level NDS-AD, a controller in the NDS. results in control operations (e.g., control of MA device functions) or both performed by the unit(s). NDS-AD may include organized or structured “raw” MA-D or other inputs from NDS DR, data generated by the application of analysis processes/algorithms to stored data, or both. In aspects, the analysis function applies schema(s) to data stored in NDS memory. For example, an NDS analysis unit may have ~2, 5, 10, 20, or 50 units that pass data to MA/ONDI, perform a function, or apply NDS-AD on CT. Commands for application of the above different schemas may be included. Most processes in the analysis unit are CPU/processor bound processes (rarely input/output processes), unlike the I/O bound processes used by, for example, the NDS input unit (NDS-INPU) or the NDS relay unit (NDS-RELAYU). (I/O) request/action creation). The NDS analysis unit engine(s)/function(s) will typically generate/result in one or more output formats that are delivered to the user of the network device/interface. Such output may include the format and delivery of data for display on a device or interface, machine control data for automatic operation of the device, alarm/warning instructions, or combinations thereof.

In aspects, the one or more NDS analysis unit/engine(s) is a fixed analysis unit that cannot be adjusted during operation. In aspects, one or more analysis units are adjustable during operation, or even automatically during operation. In aspects, machine learning is used to form a fixed function analysis unit. In aspects, machine learning is used to drive/shape the functionality of the analysis unit in operation (e.g., supervised or unsupervised machine learning is used to process the NDS analysis unit, such as predicting a subject's physiological state, best course of treatment, etc. may apply to or form part of the processing).

According to aspects, the code/CEI, which may be characterized as being part of an NDS analysis unit/engine, comprises one or more warning/alarm conditions associated with the sensor data and means for detecting the presence thereof, wherein the NDS analysis unit e.g. For MA-D, analysis determines whether one or more alarm conditions are triggered, and NDS allows alarms to register with the MA, based on sensor data and allowed user options, with the user associated with the MA/target or both. Ensure that it is delivered to the relevant device/interface.

In aspects, the MA-D includes information about the operating state of the MA-D, and the NDS analysis unit evaluates the operating state information of the MA-D when performing one or more analyses.

In aspects, the MA relays a packet that includes an identifier associated with temporal tagging, e.g., MA-D, indicating the time or sequence of a group of data. In aspects, the MA relays data packets containing such sequencing information, and the NDS analysis unit includes functionality to analyze temporal component(s)/attribute(s) of the cache data. In aspects, upon analyzing the temporal component of the cache data (MA-CD), NDS-ANALU may re-sequence the non-chronologically received MA-CD. In aspects, this resequencing sorts the MA-CD chronologically.

In aspects, the NDS analysis unit provides functions to identify historical MA-D, current/near current MA-D, and predicted MA-D (NDS-AD) (e.g., converts data with applicable timestamps/codes). tagging). In aspects, the NDS analysis unit performs one or more prediction functions based on the analysis and relays the results of the prediction functions to the MA, other network device/interface (ONDI), or both. For example, current data may be subject to initial analysis, while data stamped with a historical relevant window may be rejected or passed directly to DR collection. Data creation time, relay time, modification time or any CT may be considered when performing functions on DR data, as illustrated elsewhere.

In embodiments, the NDS analysis unit monitors whether an event occurs and re-performs the analysis when the event occurs, updates the analysis, and transmits the updated analysis to one or more MAs or one or more NDSs or network-related users, such as one or more other users. Includes CEI for reporting to network devices/interfaces (ONDI). In aspects, the NDS analysis unit includes a CEI for monitoring a data pattern that meets a preset alert condition, and when the data pattern meets the preset alert condition, the NDS analysis unit determines whether the MA(s), ONDI ( s) or CEI for signaling that notification of CT is required. For example, such warning conditions may be identified in MA-D patterns, NDS/network operation patterns, communication patterns, or any functional element within the system described herein for which data accessible by the NDS analysis unit is relevant. .

In certain embodiments, the NDS analysis unit performs one or more functions/engines regulated as software as a medical device (SAMD). In aspects, the NDS assay performs one or more SAMD functions and one or more non-SAMD function(s) (NSAMD function(s)). In aspects, the NDS passes the output of one or more SAMD functions (or more than SAMD and one or more NSAMD functions) to different MAs according to CEIs that reflect the corresponding regulatory status of the SAMD and NSAMD functions. In aspects, one or more SAMDs include providing diagnostic guidance or treatment guidance to a health care provider. According to some aspects, one or more SAMDs may change the operating conditions of the MA in response to one or more conditions. In aspects, the NSAMD function does not perform this task.

In some cases, the output application(s) are regulated as SaMD/software as a medical device (SAMD) by one or more regulatory agencies (e.g., U.S. FDA), and operation of the NDS or method may require that one or more SaMD applications -Includes one or more data transformations, data curation processes, data validation checks, or a combination of any or all of these, to ensure compliance with one or more regulatory requirements written in processor-readable instructions stored in the DMS memory unit. do. In aspects, the application of one or more outputs of such NDS is not regulated as SaMD and the operation of the NDS/method includes sorting the SaMD output(s) from non-SaMD output(s) to comply with the regulatory requirement(s). sort).

In many of the functions/methods performed by the NDS analysis unit, one or more data transformation(s) occurs, as described elsewhere. Structured data transformation can be performed in SQL, for example. Semi-unstructured data transformation may involve applying a schema to the data based on the execution of one or more queries.

At least one NDS analytics unit (e.g., the primary NDS analytics unit that performs most NDS analytics functions) performs query (search and matching) functions, for example, allowing users, processes, or both to perform queries on DR data. ) may include unit(s)/function(s). In aspects, the query unit may be configured to include a method for ranking matching records, as described elsewhere and for example in US10572221, US6651054, US5826260, US10229166, US10282472, US7970791. You can use alphanumeric data, metadata (tags, links, references, etc.), or both, in combination. Matching/ranking methods associated with query “hits” (results) may include user input, user preferences, or both (examples of such methods are described, for example, in US10387512 and US7996392) ). Ranking will typically include evaluation of several ranking factor(s), e.g. keyword meaning, context, etc., quality of matching recorded content, etc., which is often determined by the ranking/matching algorithm(s)/function(s). It is considered a weighting rule for analysis. The query process(es)/unit(s) may in some aspects/cases expand the query using a synonym generation method. Related principles and methods include, for example, US7636714, US8392413, US10546012, US20100082657, US20100313258, US20160253418, US9361362, US9489370, US8832092 and US20160253418. Described in US8812541 It is done. In aspects, a query includes search/query element(s) generated from a source or combination of terms from source(s) (term combination) according to frequent combination detection, system rules, or other suitable method(s). Examples of combined search term methods are described, for example, in US20100138411 and US20110184725. In aspects, a query is generated or records are matched through decomposing the data set into data set elements and comparing element by element (e.g., based on comparison of key/value and key/value combinations). Its components/related units, such as the NDS analysis unit or the NDS data improvement unit (DIU), or both, can be implemented at various levels (e.g., often for expected syntax, common expressions, semantics/NER or CT). In addition to testing (s) data at the single term/parcel character level, bigram level, trigram level, or higher N-gram level or CT) (e.g., at the individual token interpretation level) ignorable) and identifying "New York" as a specific stage/city through bigram tokenization compared to evaluating "York". The NLP process performed by the NLP U/F(s) may be performed to interpret or interpret heterogeneous input types, for example, unstructured input. The NLP process may be combined with the use of specialized SN(s), for example trained on relevant terms and meanings, synonyms, delimiters and other grammar/syntax or formatting rules, etc. There may be overlap of various query-related S(s)/F(s). For example, common NLP processes include tokenization in the form of word recognition, sentence segmentation, field segmentation (e.g., tabular data), or paragraph segmentation. NLP processes typically further include parts of speech recognition (and parts of speech tagging), tense recognition/tagging, etc. NLP processes also typically concatenate read terms from the input/DS(s) (e.g., dependency parsing (e.g., shallow parsing/"chunking"), syntax identification, word meaning disambiguation, natural language generation, and substitution It involves the application of a lemmatization process to find basic word forms, evaluating word relationships (by coreference resolution, sentiment classification, and Named Entity Recognition (NER)). The NER process for a specific term may need to include a specific corpus/corpus. NLP processes may include analysis based on sentence/phrase/expression morphology or syntax, while NER processes may utilize factors such as semantics or pragmatics. Exemplary NLP processes include, for example, NLTK, WordNet, BERT (sub-word token) models, and Python's spaCy library resources. Using subword token method(s) in NLP can help detectably reduce out-of-vocabulary (OOV) interpretation problem(s). NLP processes can also be used in input processes, such as receiving commands made by an NDS input unit, responding to questions, etc. Other NLP processes and processes related to data matching (e.g., in data linking) are provided elsewhere in this disclosure.

The query process may include stemming and related methods such as matching, synonym generation, or both. Stemming may involve suffix removal, prefix removal, or both. Porter Stemmer, Lovins Stemmer, Dawson Stemmer, Krovetz Stemmer, Xerox Stemmer, N-gram Stemmer ), Lancaster Stemmer, and Snowball Stemmer. Several well-known stemming algorithms are known and available. Lemmatization tools/resources and principles are known (e.g., the WordNetLemmatizer function in nltk.stem and the Lemmatizer class in Python's spaCy library provide NLP lemmatization for common English terms). The development of special thesauruses useful for query functions, matching functions or both is known (see, for example, US20100198821). String matching/stem extraction steps that may be used in the query/matching process include applying fuzzy (approximate) string matching methods, which use known and available tools/methods, for example the Levenshtein Distance method; This can be done, for example, using functions from the Python FuzzyWuzzy or fuzzymatcher packages/libraries (e.g., setting a minimum ratio of comparison strings). String stemming methods suitable for performing stemming step(s) integrated into the stemming function are also known. In aspects, the stemming step(s) includes the use of a pre-programmed lookup table. In aspects, the stemming step(s) includes application of a preprogrammed prefix removal rule, a suffix removal rule, a lemmatization algorithm, a stemming database matching algorithm, or a combination thereof (e.g., affix removal). In aspects, the stemming step(s) includes application of trained/trainable probabilistic estimation algorithm(s). In aspects, stemming, matching, or both used in the method/NDS may include rules trained to factor or include analysis/use of specific information, e.g., specific MA-D (e.g., vital signs data). /includes input. In aspects, the stemming step(s)/unit(s), matching step(s)/unit(s), or both may be implemented using an ML component/method (e.g., supervised learning or supervised and semi-supervised learning). It includes ML applied to an estimation algorithm trained by -supervised learning. In aspects, the matching or stemming function also applies to non-string input, such as images, values, etc. Any portion of this disclosure that is described in terms of string matching is understood to provide simultaneous support for the application of these other methods or broader classes of data matching/stemming that include two or more of these different types of data. It will be. Matching is often performed based on data points/data sets, for example from key/value pairs, field/record pairs, other schemas, or a combination of these. Examples of search/matching techniques and principles adaptable to the S(s)/F(s) of the method/NDS are described, for example, in US10572221, US10452764, US8145654, US6625615 and US20160306868. and the references cited herein are included. Search S(s)/F(s) may include metadata, such as search “tags” (e.g., exemplified by US20140039877, US7844587, US20080270451, US9305100, and US20200097595). It may include the use of . Examples of search/matching techniques and principles adaptable to the S(s)/F(s) of the method/NDS are described, for example, in US10572221, US10452764, US8145654, US6625615 and US20160306868. and the references cited herein are included. The search S(s)/F(s) of the method/NDS of the present invention may include metadata, e.g. search "tags" (e.g. US20140039877, US7844587, US20080270451, US9305100 and It may also include the use of (such as using the method described in US20200097595, etc.).

In aspects, the NDS analysis unit includes a task scheduling/process scheduling engine/function (task scheduler or process scheduler). Analysis units may use or mainly use long- or medium-term scheduling methods, while NDS input units or NDS relay units (NDS-RELAYU) often, mainly, usually or only work based on short-term (in-memory) scheduling processes. Only use scheduling unit(s)/function(s) (U(s)/F(s)). The task processor U/F may include a dispatcher component/function that provides control to the NDS processor/analysis unit for applicable processes when needed (e.g., in short-run processes). In aspects, the task processor includes a context switch/control, such as in response to a data event. The task processor can use FIFO, priority scheduling, shortest time remaining scheduling, capacity scheduling, round-robin scheduling, multilevel queue scheduling, fair scheduling, delayed scheduling, dynamic proportional scheduling, or resource-aware adaptive scheduling. Scheduling can be applied based on one or more methods, including adaptive scheduling (RAS). An example of this approach is described, for example, in Seethalakshmi et al., J Inform Tech Softw Eng 2018, 8:2, DOI: 10.4172/2175-7866.1000226. Task scheduling may use a threading model (eg, kernel level threading) in aspects.

The task scheduling process may be a component of another framework used for design structure matrix (DSM) task management, which may be used by unit(s)/function(s) of the NDS processor, e.g. , one example of which is MOMTH (Multi-Objective Scheduling Algorithm of Many Task in Hadoop). Hadoop, Spark, Storm, and Mesos are very well-known frameworks that contain several algorithms for scheduling short-run jobs, large-scale jobs, interactive jobs, large-scale/batch jobs, and guaranteed-capacity production jobs. See, for example, Mbarka Soualhia et al., Task Scheduling in Big Data Platforms: A Systematic Literature Review, Journal of Systems and Software, Volume 134, 2017, pages 170-189, doi.org/10.1016/j.jss.2017.09.001. do. Other related methods/principles can be found in Paul Krzyzanowski's "Process Scheduling: Who gets to run next?" at https://www.cs.rutgers.edu/~pxk/416/notes/07-scheduling.html (2014-02-19). and Tong Li; Dan Baumberger; Scott Hahn. "Efficient and Scalable Multiprocessor Fair Scheduling Using Distributed Weighted Round-Robin" is described at http://happyli.org/tongli/papers/dwrr.pdf.

7. Data Enhancement Engine(s)/Unit(s)

In aspects, the NDS features data enhancement unit(s) (DIU(s)) or includes a unit capable of performing the function(s). In aspects, the NDS includes a DIU that is a component of an NDS input unit (or such unit of the NDS includes a nested function). In aspects, the NDS includes a DIU that operates after initial collection of data. In aspects, data collection may be a step-by-step process. For example, in aspects, data input is subject to very limited transformation or structure requirements/screening, but after initial collection, such data is further subject to a DIU process resulting in a second level transformation of the data; The converted data is stored in NDS DR in a second collection process. In aspects, the data collected at the second level is subject to an NDS process, such as an NDS-ANALU process(s), and the resulting NDS analysis data (NDS-AD) typically contains schema(s) for such NDS-AD. When applied, it is stored in a more structured part of the DR. The NDS-DIU may perform function(s) to improve the quality or usability of input, such as heterogeneous data harmonization, input evaluation, and validation/rejection. These analysis processes may include processes performed automatically (e.g., a machine learning process applied to DR data) or on-demand (manually triggered) processes, such as performing data query(s) on DR data. You can.

In aspects, the NDS includes a DIU comprising or operating as a data harmonization unit (NDS-DHU), which evaluates characteristics of received data and identifies heterogeneous data, such as MA, SUMAD, and unstructured or structured MA. By applying a function to harmonize data from heterogeneous MAs in the network of -D, or a combination thereof, these data can be collectively joined/compared/analyzed. In aspects, the NDS may also or alternatively determine whether received data is suitable for use by an NDS analysis unit (e.g., approved for immediate use) or harmonize such data prior to use by applying one or more functions. Includes NDS-DHU to evaluate whether modifications are needed to achieve this. In aspects, the NDS-DHU may evaluate whether the MA-D of the NDS memory is approved for use by the NDS analysis unit. According to further embodiments, the NDS-DHU may determine how any such MA-D approved for use is used by the NDS analysis unit(s).

In aspects, the initially received MA-D is subject to data cleaning, data reconciliation/formatting (blending), or both in the NDS. This function may include, for example, assessing the effectiveness of initial MA-Ds received from each MA or most or substantially all MAs. Data validity assessment(s) may include, for example, measuring the extent to which detected CI data (e.g., values and attributes) conform to expected attributes/values based on established rules/constraints or prototypes. . In aspects, the NDS Analysis Unit or alternatively the NDS-DHU may rank data with a lower validity score in the analysis, exclude data determined to be invalid/irrelevant, or determine data that is not valid for the user. You can alert data, present valid data, or report both retained and excluded data, for example. In aspects, the DIU applies one or more tags or other form(s) of metadata to the data (e.g., one or more non-hierarchical data set(s) that can be used to process related data downstream in an NDS process. )/point(s) apply). NDS-DIU also provides data classification (e.g., data can be grouped into target-oriented datasets for easy processing at one or more data levels, e.g., all MA-Ds versus other inputs, all MA-Ds of each MA-D type). , grouped into all MA-Ds, etc.) associated with each type of patient/procedure employed by these MAs. DIU can also group data based on data categorization S(s)/F(s), for example data type or data type and data classification, which can be used for example for storage location or attribute, or as additional metadata. Can be used as a basis for data applications/tagging. In aspects, NDS-DIU uses a context-sensitive processing method when performing data analysis, transformation, or both, and in aspects NDS-DIU's application of metadata is context dependent. In aspects, application of context metadata DoS facilitates data processing applications, such as data mining. Context can be used, for example, to generate synonyms for a query, interpret records (e.g., interpret "ha" in an input related to cardiovascular MA as possibly meaning "heart attack", and in aspects related to dermatological devices, "ha"). It can be applied to “hyaluronic acid” (interpretation of “hyaluronic acid”). Examples of systems that can be used to perform DIU/data collection operations include Apache Nifi, Elastic Logstash, etc. When collecting data, NDS-DIU can apply queue processing, for example by categorizing the data, prioritizing the data, or both. In aspects, the NDS-DIU may include dynamic data record links (e.g., between semi-unstructured data and unstructured/structured data, e.g., between SUMAD associated with an MA and query response data associated with the MA). You can use metadata, semantic libraries, or master data as the basis for integrated links. In aspects, DIU uses NLP methods to translate input from multiple natural languages (e.g., English, Chinese, Japanese, German, French, Spanish, Arabic, Hindi, Korean, and CT). For example, in aspects at least about 2, at least 3, at least 5, at least 10, at least 15, or at least about 20 natural languages (NL), NL dialects (e.g., Chinese and Cantonese), Alternatively, the CT's input may be provided to the NDS, generated by the NDS, or both (for example, the NDS may relay output in Spanish and English, Japanese and English, or German and French).

In aspects, the NDS-DIU performs one or more data cleaning functions. A data cleaning unit/function/method may detect data problems (e.g., duplicate, incomplete, inappropriate, inaccurate, or irrelevant data) and remove or modify problematic data. Common errors that can be detected or corrected by data cleaning methods include spatial errors, duplication errors/duplications, mismatch errors, or formatting errors. In aspects, a Data Cleaning Function (DCF) detects or corrects classification or nomenclature errors. In aspects, the NDS uses a definition or set of rules to determine mismatch errors and other types of data corruption errors (e.g., in aspects the method includes developing, maintaining, and maintaining a dictionary, glossary, or authority file). (including the application of). In aspects, DCF includes using strict validation rule(s), fuzzy validation rule(s), or both. In aspects, DCF includes cross-checking one or more data set feature(s) (DSF(s)) or a verified record or a DSF(s) and a record with the DSF(s). In aspects, the DCF detects and resolves structural errors, such as incorrect attributes, incorrect labeling, etc. Various data cleaning methods/algorithms are known and can be applied or adapted to these steps/functions. Examples of known tools to perform this function include Duplicate Count Strategy++ (DCS++), Dedup, Progressive Sorted Neighborhood method (PSNM), and Innovative Window (InnWin) method. Known data cleaning tools that are applicable or contain applicable methods/approaches include IBM InfoSphere services/products, OpenRefine, Winpure, Trifacta Wrangler, Data Ladder's DataMatch component, Quadient Data Cleaner, and Salesforce's Cloudingo. In aspects, the method of the present invention includes using MLM in DCF(s). In aspects, the DCF(s) are trained or include/factorize rules or inputs for analysis/use of MA-D or other expected network device data (e.g., CMSS data).

In aspects, NDS-DIU supports various MA-D or EMR/EHR related messaging standards (e.g., Health Level 7 International (HL7 V2.x/v3), Clinical Document Architecture/Continuity Of Care Document (CDA/CCD) , American Society for Testing Materials (ASTM), Digital Imaging and Communications in Medicine (DICOM), etc.) and various standards or protocols (e.g., cross-enterprise document sharing (XDS.A/B)) cross-enterprise document media interchange (XDM) cross-enterprise document reliable interchange (XDR), patient identifier cross-referencing/patient demographics query ; PIX/PDQ) harmonize data from patient administration management (PAM), query for existing data (QED), national consultation for prescription drug programs (NCPDP), etc. This makes it possible to harmonize these heterogeneous inputs. For example, NDS-DIU can convert some, most, usually all, or all inputs into a consistent or compatible format for use within NDS (e.g., ISO/IEEE 11073-10101 nomenclature and its extensions). You can. In aspects, the DIU normalizes a stream of incoming time series data or other input, such as by converting the unit of measure of the data (time, volume, size, etc.). In aspects, non-uniform data may be harmonized (e.g., converting mole percentages to weight percentages, converting volumes to weights, converting inches to centimeters, converting volume or time units to alternative volume or time units, etc.). You can.

According to aspects, data, groups of data, or data sets, e.g., at least 2, at least 3, at least 5, at least 10, at least 25, at least 50, at least 100, MA-D fragments, groups or sets of ~500 or more, ~1000 or more, or even ~5000 or even ~10,000 or more may be used to determine, for example, the types of values present, the units of these values, etc. In NDS-DIU, uniformity evaluation, value type, value unit, etc. are subject to evaluation. In aspects, integrity may be used to describe the analysis of a combination of two or more of approved (e.g., immediately approved or harmonized) data, consistent data, accurate input, and complete input. In aspects, data cleaning follows integrity assessment.

According to aspects, the NDS DIU generally performs data audits to evaluate NDS input unit/incoming data anomalies, inconsistencies, other errors, etc. using rules, constraints, statistical analysis, or any combination thereof.

In aspects, the NDS DIU may apply one or more constraints to evaluate what data is acceptable and what is unacceptable, or what data is acceptable as received data and what data requires modification before acceptance and use. In aspects, the one or more constraints may include, but are not limited to, range constraints (e.g., expectations for the value of a particular attribute to fall within a numerical range or order of magnitude (e.g., volume or rate), or nominal values falling within a particular set (e.g., units consistent with expected physiological measurements)). Depending on the rules, constraints may also be applied to dates, times, and other values (typically maximum and minimum expected values). In aspects, the NDS input may be subject to mandatory constraints (e.g., required entries), unique constraints (particularly information identifying/associating a CI with one or more information items), or both. In aspects, regular expression pattern recognition is generally used for such input recognition. In aspects, a cross-field validation method may be used across, for example, data received as a set from an MA or MA type or MA that satisfies a particular set of conditions, with one field, such as two or more data fields, representing a percentage. Cross-reference data from one field to another. In aspects, some portion, such as more than 5%, more than 10%, more than 15%, more than 25%, or more than 33% of the input, is in an unstructured format, no constraints or content rules/requirements apply, or It's both.

According to embodiments, the NDS-DIU or other NDS component may perform completeness evaluation/assessment, especially when mandatory restriction rules for information are used. In aspects, the assessment threshold will determine whether and how information, such as MA-D or analysis, is utilized. In alternative aspects, the evaluation score will evaluate how such data is used or whether such data is transformed or excluded.

In aspects, an NDS-DIU, an NDS input unit, or another aspect of an NDS may be used to transfer data between input data of one or more data types/sources or within the source(s) of input over time (e.g., a single patient treatment or assessment period). (over the course of the process) will be assessed for consistency. Consistency measurements may be performed, for example, by matching against rules, between sources (e.g., between sources of similar MA-Ds), or both. In aspects, consistency analysis is performed using measurements (which may be reported to the user, used by an algorithm with a cutoff function, etc.). In aspects, the DIU determines consistency and acts (corrects data) based on an identified inconsistency or other detected data issue, for example by notifying the user of the problem or modifying the data according to established rules implemented through a CEI implementation. Decide to omit or modify. According to some embodiments, machine learning (ML) may be applied to the DIU process to make improved evaluation or consistency decisions, such as improved comparative or predictive evaluation. ML processes are generally described elsewhere and in the art.

In aspects, the NDS-DIU normalizes some, most, generally all or all inputs of one, some, most, generally all or all input types. Standardization requires internalized data to be in a form recognized or acceptable by the NDS (e.g., in a specific semi-unstructured data format or in a data format/record recognized as containing minimum data requirements) (e.g., in serialization and elsewhere herein). (through other standardization methods as described in). As an example of a standardization process, if NDS requires gender to be expressed as male, female, and other, but an external entity expresses gender as M, F, and O, the standardization process converts M, F, and O to male, female, and other. do.

The NDS-DIU can perform step(s)/function(s) on input/data to “master” the data. Data mastering refers to a variety of processes by which data belonging to a specific person, device, entity, etc. can be attributed to that person, device, entity, etc. As an example, data mastering may include recognizing that data attributed to Jonathan Jones and Jon Jones belong to the same person. The mastering function may include storing master data in a series of mastered IDs or maps. Master ID or map storage can be accessed during real-time or batch/analytical patient-specific data analysis to provide applicable algorithms along with synonyms for referenced people, devices, entities, etc.

Input data (input) and collected data can include both structured and unstructured data, and various consumption models include the data search consumption model, data analytics consumption model, scientific application consumption model, and data reporting consumption model. May be included. In some implementations, a transformer for one or more later stage purposes may be used in aspects such as data cleaning, data matching, Frame of Reference (FoR) transformation, model mapping, and data aggregation for data analysis. Additionally, in some implementations, such a converter may be configured to work with data in its original format within a data store, such as a data lake. In aspects, the transformer may be configured as a plug-in.

NDS-DIU typically includes redundancy detection and removal function(s) to minimize record size, improve efficiency, etc. However, these feature(s) are generally balanced against the standard(s) of pre-programmed redundancy as protection against component failures in the distributed system. These function(s) may be applied more than once in the method process, for example when data is linked to master data.

8. Data Monitor/Dashboard

A system/NDS may include one or more data monitor(s)/dashboard(s). The data monitor/dashboard created/embedded by NDS collects certain data from the NDS/network and displays it on network device(s) or other user accessible interface(s) (e.g. may include a combination of engine(s) that generate schema/representation(s) adapted/configured for display (on various web pages). The monitor/dashboard may provide the user with navigable access to actionable analytics, such as the current performance of the NDS/network or improvements in NDS/network behavior after modifications. In aspects, the system/NDS includes a dashboard/monitor that provides data visualization functionality based on data collected into the data store(s) of the NDS, such as one or more databases, a data lake, or both. In aspects, the dashboard/monitor provides data visualization functionality for analysis data (NDS-AD), query preparation data, etc. In aspects, the NDS includes at least two, at least three, at least four or more data monitor units/dashboards. Examples of data dashboards/monitors that can be applied to streaming data entering and flowing through the system are known in the art. For example, data monitors/dashboards based on Apache Kafka are known in the art. One such live monitoring dashboard is Redash (which integrates with other SQL dashboards such as Tableau, Grafana, and Apache Superset). Microsoft Power BI dashboards are another example of a type of data monitor known in the art. Power BI dashboards can be based on push datasets, streaming datasets, or PubSub streaming datasets. Dashboards, such as Power BI dashboards, can be the output of a stream analytics processor, streaming data processor, or event handler, or an ingestion upstream process into a data store, such as a database. In aspects, the NDS includes a dashboard that monitors an MA function, e.g., MA power state/function, on a repetitive basis (e.g., every 1-20 minutes, e.g., every 2-15 minutes). In aspects, the monitor is coordinated with functionality to provide analysis of data patterns over time, events, etc. For example, analytics functions may include monitoring events based on time/conditions, such as alarms, and providing feedback, reports, or functions based thereon. For example, for some parts of the network, alarm data can be collected over time to identify patterns based on events/conditions or patterns (e.g., more alarms occur during times of the week versus weekends). , the system can identify these patterns). In aspects, through data monitors and the like, the NDS may identify problems with a patient, device, or combination that cannot be readily determined through routine medical diagnosis, NDS analysis, or the like.

In some cases, the operation of an NDS may involve generating representation(s) regarding the quality of data stored in the RDB, inputting the RDB, or both, and rendering the representation(s) to the graphical user interface of one or more ONDs on the network (e.g., to one or more NDSs). to the OND associated with the administrator user). In aspects, an NDS may include two or more RDBs, and an NDS may include multiple units for generating such representations. For example, in aspects, the NDS includes a second RDB and the operation generates a representation regarding the quality of data that is stored in or entering a second relational database, or both, and converts this representation to a network Relays to the graphical user interface of one or more ONDs in the network (e.g., to one or more ONDs associated with one or more NDS Administrator users). In aspects, the operation of the NDS also provides for the MACMDS when the data quality represented by any such graphical representation of data quality (data monitor/dashboard, etc.) enters or is contained in the RDS, e.g., two or more RDBs. Results in applying one or more modifications to one or more instructions in a memory unit.

9. relational database

In aspects, the NDS/System may include one or more relational databases (“relational databases”) in addition to one or more other data stores, such as one or more data lake(s)/enhanced data lake(s) (DL(s)/EDL(s)). Contains one or more databases, such as "RDB"). Aspects related to the database/nature of this DR are described elsewhere. In aspects, the NDS includes at least two structured databases in addition to at least one DL/EDL. In one example, the NDS includes a database that stores NDS operational data including one or more elements of NDS performance (e.g., creation of NDS-AD, collection of data into a data store, reception of data from a network, etc.) . In one example, the NDS also includes a database containing NDS-AD, MA data, or both in a queryable format, in aspects where the data is mostly, substantially completely, essentially completely or completely in any of the NDS. (completely distinct from other relational DBs). In aspects, the NDS includes a unit/function to filter/remove unimportant data/messages before storing them in a relational database.

In aspects, the DR(s) of the NDS include a first relational database (in addition to the EDL), and the operations of the NDS include (1) generating first structured dataset data from analysis output data and (II) generating first structured data stores the set data in a first relational database, wherein (2) (a) the DR(s) include a second relational database and the operation is: (3) perform one or more analysis functions on data in the EDL to obtain analysis data; (II) generating second structured dataset data from such analysis data, optionally by combining it with data contained in the first relational database, and (III) storing the second structured dataset data in the second RDB. It includes doing.

By combining an initial analysis memory (e.g., system/network RAM), DL/EDL, and one or more RDBs, the NDS of the present invention provides a variety of data functions and potential life data in system/network RAM. Near real-time analysis of conservation/life-saving data; Fast data generation for near-state-of-the-art output applications such as prediction of physiological data from system/network RAM or through using data from EDL (e.g. DOS fast data generation); Fast querying of semi-structured data in EDL; and efficient (e.g., DOS is more efficient) higher-order analysis of data stored in RDB(s).

10. NDS relay engine(s)/component(s)/unit

An NDS typically includes some, most, typically all or all MAs in a network, and often other network devices/interfaces (ONDIs), e.g. research organization/class MAs and other devices, clinical support organizations/class devices. or may have the capability of relaying data to some, most, generally all or all network devices, including also commercial class devices/interfaces, etc., where network communications may be achieved through direct physical communication facilitated by any suitable means of communication, e.g. cables. It may be performed through communication, wireless communication (e.g., Bluetooth communication), or communication via, for example, the Internet or CT. In aspects, such communications are mostly, generally, or only conducted as secure communications, as discussed elsewhere or as known in the art. The physical component, engine(s) or both involved in transmitting data from NDS to another network device/interface may feature a relay unit (NDS-RELAYU or NDS RELAYU).

As with other "unit" configurations, the elements of the NDS Relay Unit are those described as forming/forming part of the Analysis Unit (NDS-ANALU), NDS Processor (NDS-PROCU), NDS Memory (NDS-MEMU), etc. Because they can be nested, "unit" constructs are sometimes masqueraded as a convenient framework for discussing the functionality of a step(s)/function(s) rather than always corresponding to an individual/unique set of components/features or engine(s). I understand. A similar approach to terminology is used in the art.

NDS Relay securely relays information over the Internet, for example, via encrypted data, by using a VPN, or through other data protection standards/methods. In aspects, the security information is communicated/transmitted to one or more MAs individually or in groups or groups (e.g., to a central server or node for the IE that relays data to the MAs in the IE's local network) over the Internet. do. In aspects, information transmitted by NDS-RELAYU is received by a MA input unit, including functionality to identify NDS relay communications and block other unauthorized inputs. In aspects, the NDS-RELAYU provides to each MA information that is specific to a MA, specific to a patient associated with that MA, or both, and is one or more specific types of information specifically identified and configured to be accepted into the MA security unit. Transmission, e.g. transmission/relay. The NDS relay may transmit/relay NDS-AD (e.g., predicted physiological data derived from application of MLM(s) to MA-D) to MAs, ONDIs, or both. Other data transmitted from NDS-RELAYU may include NDS availability information, software/OS update readiness information, or component or CT. In aspects, the data transmitted from the NDS relay to the MA-INPU mostly consists of or essentially consists of biometric prediction data, commands or control provisions of the MA, NDS status, MA software version status, or a combination thereof. In certain aspects, data permitted to be transmitted from the NDS-RELAYU/DDRU includes software version status information. In aspects, use of NDS allows updating of some, most or all MA software via the Internet. In aspects, NDS does not allow preventing updates of some, most or all MA software, for example via the Internet. The NDS relay unit will typically include a network interface controller, network adapter, such as a server level NIC adapter/controller/card known in the art. Given the capabilities of the NDS, these NIC components may include, for example, Gigabit Ethernet NIC component(s), "smart NICs" (e.g., those used in major cloud computing platforms such as AWS and Azure cloud services), and NIC services with processing capabilities, such as including a field programmable gate array (FPGA) that provides offload capacity to the server-level NIC independent of other processing functions. This architecture allows NDS to more efficiently perform functions such as load balancing, data encryption, or deep packet inspection, known in the art for key cloud processing/storage services. In aspects, an NDS NIC system includes multi-queue NIC(s) and utilizes NIC partitioning (NPAR, also known as port partitioning) (e.g., using known SR-IOV virtualization), TCP Offload Engine technology, or any of these. Use any or all combinations of. In alternative aspects, NDS also includes/only includes a virtual network interface, such as Google Virtual NIC (gVNIC) or Oracle Cloud Infrastructure.

In aspects, the NDS relay unit may include an NDS output processing system capable of filtering data, analyzing data, or both filtering and analyzing relevant data. In aspects, such functionality may be an automatically applied functionality, such as automatic data filtering, automatic data analysis, or both, and may be facilitated, for example, by appropriate programming. In certain embodiments, the NDS relay unit/processor automatically filters the MA-D, the analysis (e.g., the results of one or more analysis(s)), or both, for each MA and/or alternatively one or more other analysis(s). Delivered to network devices.

In aspects, the NDS data relay unit transmits information (output) including MA-D, analysis (e.g., results of analysis(s)), output application, or combinations thereof via the Internet (e.g., securely can be securely relayed to one or more other network devices/interfaces (ONDI) (via Internet communications). In aspects, the information relayed to ONDI includes information from a plurality of MAs (e.g., any number of MAs) associated with any number of IEs, or from two or more IEs, e.g., about three or more, about MA received from multiple MAs associated with 4 or more, or about 5, about 10, about 15, about 20, about 25, about 30, about 35, about 40, or about 50 IEs This is data derived from -D.

In aspects, NDS output includes an output application. The output application may include instructions to control aspect(s) of MA operation, ONDI operation, or both. In aspects, output includes relaying data into a schema or graphical representation. In aspects, the output includes all or part of a software application executing on a MA/OND client device/machine. These NDS support/implementation software applications include graphically displaying data on a client OND/MA graphical display unit, various data tailored to the user class associated with the associated client device (e.g., for commercial class users, MA without PHI) May include aggregates of status, utilization, etc.; patient/device-specific data for HCPs, including PHI; and study-related information for study group users. Output applications often access data (e.g., graphical representations and other data) from the NDS in combination with stored elements (e.g., part or all of the graphical representation of the application) stored/generated on the local device via MA/ONDI. It can be run in . In aspects, an application running on MA or ONDI (as known by dividing functionality into model, view, and controller functions, thereby decoupling the presentation of information from how the information is presented to the user, allowing for efficient code reuse and parallel development). It is a model-view-controller (MVC) application. In aspects, such applications are web-based and provide create, read, update, delete (CRUD) capabilities. In aspects, this capability allows new applications to be built on a common application infrastructure (e.g., for applications relayed to NDS Administrator class users). The output application may represent the OND/MA GUI in a variety of ways (e.g., create a GUI representation using a combination of HTML and JAVASCRIPT, including client device executable code, NDS executable code, or both). NDS allows the client device to store these representation(s) (in two, three, five, or more aspects depending on conditions such as patient state, device state, etc.) It can be transmitted or otherwise provided to the client device for display on the screen/GUI according to programmed NDS parameters or both. Alternatively, the representation of the GUI may take another form, such as an intermediate form (e.g., JAVA bytecode) that the client device can use to directly generate graphical output. User interaction with GUI elements such as buttons, menus, tabs, sliders, checkboxes, toggles, etc. may be referred to as “selecting,” “activating,” or “acting” them. These terms may be used regardless of whether GUI elements are interacted with through a keyboard, pointing device, touch screen, or other mechanism. In aspects, components of the NDS organize received data (including MA-D) into a web page or web application representation for display in ONDI. This representation may take the form of a markup language, such as hypertext markup language (HTML), extensible markup language (XML), etc. In aspects, the NDS component/unit executes various types of computer scripting languages, such as, for example, Perl, Python, PHP, Active Server Pages (ASP), JavaScript, etc., to interact with network client devices and such web pages/presentations. Facilitates delivery/display of web pages for MA/OND interaction. Languages such as Java can also facilitate the creation of web pages on network client devices, provide web application functionality, or both. In aspects, the NDS relay unit communicates output (display representation or other data, output application, or both) to one or more medical devices, one or more other network devices, or both via secure Internet communication. The outputs are (a) analysis data output; (b) (I) one or more medical device features on one or more of the medical devices in the data network, (II) one or more other network device features on one or more of the other network devices in the data network, or (III) (I) and (II) one or more output applications or other network devices on a data network that contain instructions that control the operation of other network device functions, or (III) that contain instructions that control the operation of both (I) and (II). One or more output applications that: or (c) a combination of (a) and (b).

The NDS relay unit may access the method/function(s) of the NDS, such as reporting by email or other communication method (e.g., SMS/text), reporting by HTML/XML file, or reporting by network device (e.g., Any suitable form that can be used for analysis/output reporting can be used, including reporting within a search/action application that displays results via a GUI on a smartphone) or web-accessible interface. When reporting results, S(s)/F(s) will typically use authentication/access level information (e.g., generated by AM) to protect PHI or other confidential information, for example, to protect PHI. Confidentiality rule(s) to ensure that data is not inappropriately released from the NDS's DR(s) to users who are not authorized to view such data based on data ownership, regulatory requirements (e.g. GDPR, HIPAA, etc.), or both. ), algorithm(s), etc.

In one aspect, the NDS relay unit conveys MA-D, NDS-AD, or both to a plurality of GUI schemas/interfaces based in part on user roles (classes). In aspects, these user classes include research team members/organizations (research class users/ONDI), commercial employees/agents (commercial class or business purpose users/ONDI), and administrator class users/organizations (administrator class ONDI). In aspects, some, most, generally all or all of Commercial/BP User/ONDI, Administrator ONDI, or both are associated with the entity(ies) that own or manage the NDS. Research class users/ONDIs may be associated with an NDS owner/operator, an independent entity (IE), or both. In aspects, some, most, generally all or all of the study class ONDI/User is associated with an IE (an entity independent of the NDS owner/manager entity(s)). Another possible class of user/ONDI is a clinical or medical support team (clinical support user/class/ONDI) associated with the NDS owner/administrator in aspects. Users and ONDI may be associated with an IE licensed to use the NDS (e.g., a customer of the NDS owner, e.g. if the NDS owner is a company that creates and sells (i.e. uses) MAs in the NDS) there is. ONDI and user classes are described in more detail elsewhere.

The network and NDS(s) may include any one or more wired or wireless medium/medium that conveys data between the point(s)/node(s)/component(s) of the network component, NDS component, or both. there is. In aspects, wired or wireless media may include, but are not limited to, metallic conductor links, radio frequency (RF) communication links, infrared (IR) communication links, optical communication links, etc. RF communication links may include, for example, Wi-Fi, WiMAX, IEEE 802.11, DECT, 3G, 4G or 5G cellular standards, Bluetooth, etc. Communication(s) links may include, for example, voice-over-Internet-Protocol (VoIP) lines, cellular network links, Internet Protocol links, etc. Internet protocols support the application layer (e.g. BGP, DHCP, DNS, FTP, HTTP, IMAP, LDAP, MGCP, NNTP, NTP, POP, ONC/RPC, RTP, RTSP, RIP, SIP, SMTP, SNMP, SSH, Telnet, TLS/SSL, ) and link layers (e.g., ARP, NDP, OSPF, tunnel (L2TP), PPP, MAC (Ethernet, DSL, ISDN, FDDI, etc.)).

NDS-RELAYU may include unit(s)/engine(s) included in the input unit, including for example data tagging/curating functions, serialization/deserialization functions and short-term (in-memory) analysis functions. The NDS relay unit will generally utilize multiple (e.g., massively) parallel processor architecture(s) and framework(s), such as those described elsewhere in connection with other U/F(s). The NDS relay unit, in aspects, may also use distributed processing and processing functions, such as queuing, task scheduling, etc., as well as data filtering and data structures/schema for data presentation (such functions may be can also be performed by the analysis unit in NDS-AD generation).

In aspects, the output application may be configured to (a) one or more therapeutic tasks performed by a particular medical device (e.g., the MA operates to treat a symptom(s) or cause(s) of a disorder, such as a physiological condition; (b) one or more preventive actions performed by a specific medical device (reducing the risk of onset, reducing severity at onset, delaying onset, (c) medical devices to control both one or more therapeutic tasks and one or more preventive tasks performed by a particular medical device; Contains device-specific instructions; (2) the particular medical device receives, interprets, and executes one or more output applications; (3) a particular medical device changes one or more conditions of patient care based on one or more output applications received (e.g., as described above).

In aspects, the creation of output application(s) includes (1) (I) recommended medical instructions, (II) analytical data related to a medical device, a patient, or both, for display in a graphical user interface of one or more medical devices, or (III) generating a first representation comprising both (I) and (II), (2) relaying the first representation to one or more medical devices for display on one or more graphical user interfaces, (3) ) generating a second representation comprising the analysis data without any patient protected health information, for display on a graphical user interface of one or more other network devices, and (4) for display on one or more graphical user interfaces. Relaying the second representation to one or more other network devices, wherein steps (1)-(4) are performed in 5 minutes, 2 minutes, 1 minute, 0.5 minutes, 0.25 minutes, less than 0.1 minute, less than 2 seconds, or 1 minute. It performs in less than a second.

C. Other network devices/interfaces and components

In addition to MAs and NDSs, the network may contain other devices (ONDs) and NDSs may pass data to other network device interfaces (ONDIs), in either case typically receiving data, transmitting data to or sending data to and from NDSs. You can do both. ONDI may be associated with other classes of users in addition to the MA's HCP Operator, MA Administrator or MA Local/IE Network Administrator, and NDS Administrator. ONDIs may be grouped according to user class, for example, RNDI (research ONDI), BPNDI (business purpose/commercial ONDI), and ANDI (administrative ONDI).

In aspects, ONDI includes NDS Owner/Operator (SO) Support System(s) (SOSS(s)), and NDS supports MA-D, NDS Analysis, or both NDS Owner/Operator Associated Network Access Devices (SOANAD). ) is delivered to. These support system(s) may include (a) the NDS Analyst/Administrator device/interface, (b) the Clinical Support Class of Device/Interface (CONDI/CSONDI), or both, which are often personnel associated with the NDS owner/administrator. It is operated by NDS analysts/administrators may be involved in NDS maintenance, NDS configuration, NDS management, NDS analysis, etc. and can access NDS through administrative ONDI (ANDI/AONDI). Additional classes of ONDI/Users include Commercial/Business Purpose (BP) Users/ONDIs, and Users and ONDIs may also be associated with NDS Owners/Administrators. Professionals operating BP-ONDI may include MA sales representatives and commercial management. Regulatory requirements (“RRs”) may not allow persons to access PHI, and therefore NDS rules for data transfer to BP-ONDIs restrict such ONDIs from receiving or accessing such data. In aspects, the ONDI is an actual hardware device (“OND”), such as a smartphone, tablet, personal computer, etc.

Another ONDI/User belongs to the Research class Person/Organization, and this user is associated with a Research ONDI (RONDI/RNDI). Some, most, generally all or all study class users may, in aspects, have a study MA that is part of the network. Research MAs may include MAs of an experimental nature (new MAs, proposed improved MAs, etc.), commercially available MAs in operation in clinical trials or other trials, or both, which may include other types of ONDIs of interest to researchers (e.g. The study class may exist alongside or as an alternative to the user's computer, mobile phone, etc.). The NDS may include special unit(s) to receive input from some, most, typically all or all ONDIs, relay NDS-AD and other data to these ONDI devices/interfaces, or both. In aspects, one or more ONDIs in the network may be one or more sub-collections of ONDIs, e.g., based on a subnetwork, user class, or both (e.g., a particular IE or researcher class associated with a study; a particular type of MA). classes of BP-ONDI associated with sales; etc.), and the associated data will include tags or other identifiers for these subclasses of these users/data sources.

In aspects, an NDS administrator/analyst, a study class user, or both may participate in machine learning management, such as a supervised machine learning method. Clinical support users typically, for example, observe MA-Ds, receive alerts/alarms based on these MA-Ds, and generally report any issues not identified or resolved according to standards, protocols, etc. It is the user who provides monitoring support for subjects treated by the MA by providing second level support to the user in notifying IE owners, relevant HCPs, etc. Other owner-related devices/interfaces may be associated with BP/commercial class users (eg, sales professionals, medical affairs professionals, etc.). Owner-related users, especially BP/commercial users, generally do not have access to PHI, so in these aspects NDS typically uses filters, curation methods, etc. to prevent these owner-related users from receiving PHI. Data tagging and matching methods may be used in these function(s)/engine(s).

In aspects, the network may include a commercial class device/interface network, e.g., one or more sales representatives, sales managers, or corporate level personnel who supervise sales, sales representatives, or sales training, typically associated with the NDS owner. Includes users (e.g., sales representatives of MA in the network). According to one aspect, the user includes a sales representative who sells or leases MA on behalf of an NDS owner/operator (SO). In aspects, communication over such a network may facilitate training, support beneficial communication between a sales representative and an independent entity housing one or more MAs, or to support training of a sales team, e.g. For example, data groups may be facilitated or supported to provide data on NDS features, NDS alerts, aggregated NDS data (e.g., related to NDS performance, functionality, etc.), or NDS utilization. In some embodiments, NDS or SOSS may combine MA-D, analytics (NDS-Ad), or both with data from a customer relationship management (CRM) system. Data from the CRM Support System (CRMSS) can be entered directly into the NDS and delivered to commercial class devices/interfaces in combination with NDS-AD, etc.

In aspects, ONDI is a research platform that delivers MA-D, analysis, or both to a network access device (NAD) associated with a scientific researcher (SR) associated network access device (SRANAD). Includes RP). In aspects, some, most, generally all or all SR users are not associated with the SO through employment or similar affiliation (e.g., by being employed by one or more IEs). In aspects, NAD is associated with one or more SRANAD and SR is associated with SO. In aspects, a study class of users includes both SO-related and non-SO/IE-related users, and the NDS provides data to link the study-user-related MA or other input or output (e.g., interface) with the study-user-related Includes tagging or other means of data identification. In aspects, communication with such a platform may facilitate NDS training, assist with further NDS development efforts, alert developers to NDS errors, provide developers with information related to NDS usage levels, demand and data flow patterns, etc. . Additionally or alternatively, in aspects, communications on these platforms promote SO-related, SO-sponsored or SO-independent medical research, support SO-related, SO-sponsored or SO-independent clinical research, or other such clinical data group related efforts. can support. In aspects, data shared with such ONDI may be subject to pre-established rules (e.g., rules established by the SO, by one or more individual SR(s) or a group of SR(s), rules established by the SO, patient consent). , established data controls (e.g., rules established by contracts, agreements, scientific protocols, etc., or by, for example, healthcare compliance rules) (e.g., governments have imposed privacy rules, such as HIPAA rules, GDPR rules, etc.) Controlled and/or managed by a mechanism. In aspects, the NDS includes a repository of such rules or access to such rules and a system for monitoring or regularly updating such applicable PII/PHI rules.

In aspects, one or more different user classes/groups may include a clinical support group associated with a clinical support device/interface, which may generally transmit or receive certain types of data to/from the NDS. In aspects, communication with these groups facilitates improved patient care, for example, clinical support staff may be involved in communication between the NDS and the primary care provider(s), such as the MA(s), MAG owner, etc. Allow participation. In aspects, communication with a clinical support group may allow such clinical support group to, for example, assist with data interpretation, interpret NDS indicator(s), e.g., alarm(s), etc.

In aspects, the NDS can read data directly from an electronic health/medical record (EHR/EMR), write MA-D, NDS analysis, or both directly to the electronic health record (EHR), or both. Includes functional modules/engines/units. In aspects, the NDS restricts access to EMR/EHR data to HCPs through encryption, data curation, governance area applications, etc. The terms EMR and EHR are used here as alternative aspects, providing implicit support for each other.

In example aspects, the network may include at least 3, at least 5, at least 10, at least 20, at least 30, at least 50, at least 100, at least 200, or at least 500 different network devices (ONDs). wherein each OND includes (I) a (A) processing unit, (B) a memory unit, and (C) a remotely controllable graphical user interface, and (II) a user assigned to at least one user class and Associated, user classes include (A) health care providers authorized to access patient protected health information and (B) commercial users who are restricted from receiving patient protected health information. NDS's CEI provides isolation, redaction, and encryption of PHI, preventing such data from being passed on to commercial class user-specific ONDI. In aspects, the NDS CEI includes guidance for using non-patient-specific aggregate data, etc., to provide commercial class users with information that is useful and relevant to the MA of interest to the commercial class user(s), such as aggregate usage data, performance data, etc. Information can be received.

According to aspects, the MA-D includes location information and the NDS Relay/DDRU simultaneously relays information to two or more ONDI classes based on facility, metropolitan area, state/region, country, or IE. In some embodiments, the MA input unit(s) indirectly receive input derived from one or more research teams and IEs using the MA in clinical research application(s).

In aspects, the NDS processor may automatically filter the MA-D, the analysis (e.g., one or more analysis results), or both. In aspects, the NDS processor may implement one or more established or predefined rules or sets of rules, e.g., rules or sets of rules relating to confidentiality (e.g., rules, agreements, or rules established by one or more individual facility(s)). filter data according to, for example, healthcare compliance rules (e.g., rules established by agreement, etc.) or by, for example, healthcare compliance rules (e.g., HIPAA rules, HI-TECH Act rules, privacy rules imposed by governments, such as GDPR, etc.); This filtering can be used to ensure that ONDI only receives data appropriate for its role. ONDI may include any suitable hardware device(s), software application(s), or both to receive output from the NDS. Each class of ONDI Users will generally receive data according to one or more schemas and rule sets tailored specifically to that class of ONDI Users in a manner that complies with regulatory requirements. In other aspects, such users may browse from any suitable device, multiple devices that support a web browser application (e.g., a mobile phone, tablet, or laptop computer) and comply with appropriate log-in/security processes. You can interact with NDS through a web-based interface that can be retrieved from many of these devices. Accordingly, the ONDI process may be implemented in hardware, firmware, software, or a combination thereof (CT). The hardware of an ONDI device may include, for example, one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), neural network processors (NNPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), and field programming. It may include a capable gate array (FPGA), processor, controller, microcontroller, microprocessor, electronics or any other electronic unit/circuit/component suitable to perform the relevant steps/functions. Firmware/software components may include, for example, microcode, procedures, functions, etc. that perform S(s)/F(s). For example, CEI, such as program code, may reside in any suitable PTRCRM, such as NTRCRM, executed by a processor. The computer(s), which may be ONDI devices (e.g., mobile phones, laptops, servers), networks, and accessible processor capabilities (e.g., in a distributed computing environment), may include processing function(s) and data memory. and can optionally supplement one or both with cloud-based resources or NDS resources. In aspects, an ONDI computer or computer system may include CPU, ROM, RAM, HD, and I/O device(s). I/O devices may include, for example, a keyboard, monitor, printer, electronic pointing device (e.g., mouse, trackball, stylus, touch pad, etc.), etc. ROM, RAM and HD are known NTCRM memories that store computer executable instructions executable by the CPU or can be compiled or interpreted to be executable by the CPU. PTRCRM or NTCRM includes volatile and non-volatile computer memory and storage devices, such as random access memory, read-only memory, hard drives, data cartridges, direct access storage arrays, magnetic tape, floppy diskettes, flash memory drives, and optical data storage. It may include devices, compact disk read-only memory, and other suitable computer memory and data storage devices. Examples of NTCRM include register memory, processor cache and power-independent memory media such as ROM, hard drive(s), and ACT. Any one of the CRM types may refer to, for example, a data cartridge, data backup magnetic tape, floppy diskette, flash memory drive, optical data storage drive, CD-ROM, ROM, RAM, HD, etc. ONDI devices may store, operate, or store and operate an operating system (OS) used to control the operation of the device(s). OSs are known in the art and include LINUX, WINDOWS, Apple iOS, Android, UNIX, SOLARIS and other suitable platforms.

D. How the system operates and related methods

The present invention provides a method for collecting information from a connected network of medical devices, namely, accessing a network of separately located medical devices (MAs) (typically in two or more MAGs owned by different IEs). and collecting data conveyed from the MA in a medical device network data management system (NDS) forming a network (e.g., SDWAN) with the MA, wherein such data is primarily, generally or substantially transferred to the SMAD. Although collected, the NDS also receives locally stored/cached MA-D collected and relayed by the MA under condition(s) (e.g., when communication fails because the MA and NDS are one or both offline) . In aspects, the MA-D received by the NDS is stored in the DL or EDL DR. In aspects, the network includes one or more other network device/interface (ONDI) classes associated with users of the relevant class, e.g., a research class, a clinical support class, a business purpose/commercial class, or a combination thereof. In aspects, the NDS transmits the NDS-AD to most, typically all or all of these other ONDIs simultaneously, either periodically or event-driven, but such ONDI displayed data is stored in a schema/curate format that limits and curates the data in such displays. They are distinguished from each other by rules (e.g., withholding PHI from commercial class users). The MA, NDS, and other network components/NDS components involved in these methods may have components, perform any invention, and exhibit any characteristics described elsewhere with respect to such elements. In general, any one of the NDS components described above may be associated with a method step. However, to further clarify aspects of the invention, the operational characteristics of certain aspects of the method steps or certain elements of the NDS/method are described in the following sections.

Also, as will become clear from the previous sections of this disclosure, there are several steps that can be involved in the operation of the NDS, both at the MA (Device) level, the NDS (System/MAC-DMS) level and the ONDI level. At the MA level, these steps include sensing and analyzing target data, transmitting this data to the NDS (directly or potentially indirectly from the MZMA), and receiving data/instructions from the NDS. At the NDS level, the steps are typically (a) data entry/inflow (e.g., by a SDP), (b) initial analysis decisions of the incoming data (e.g., by a component of the SDP), (c) initial perform initial actions based on the analysis, (d) collect data into NDS DR (e.g., EDL), (e) analyze DR data (automatically, on demand, or both), and (f) NDS of DR data. -Includes performing actions based on AD (e.g., changing ONDI display, changing MA display, changing MA control, or CT).

I. System input/inflow methods and characteristics

The method of the present invention may include receiving input from a MA, typically a number of MAs (e.g., ˜100 or more, 1000 or more, 5000 or more or ˜10000 or more MAs), which may include receiving input from several different MAs. IEs (e.g., 3 or more, 5 or more, 10 or more, 20 or more, 50 or more, or ~100 or more IEs), similar numbers of different positions (any +/- ~33 of these values) %), including different MA types (e.g., ECMO and cardiac pump devices), different patient types, or any CT. Input to NDS is typically processed by highly available parallel processing. In aspects, the input is processed by a distributed massively parallel processor, which in aspects includes a mostly scalable cloud-based processor, or is a generally or fully scalable cloud-based processor. In aspects, the method includes an initial analysis step performed at or immediately after influx, such as in the primary memory/processor of the NDS (e.g., in an SDP) and a separate memory/processor, optionally resulting in an immediate action ( s) or output occurs. In aspects, the input method includes applying a data queuing process, minimal transformation, or structural screening, or both, to most or generally all RT/S input data after NDS DR collection. In aspects, data is at least initially collected and largely, generally, or substantially maintained in a DR containing a DL or EDL structure. Other specific aspects of the method are discussed below, which may be applied to or combined with these and other aspects of the disclosure.

One. System data security

In aspects, the method includes a data transformation step to ensure confidentiality of confidential information of the DR(s), e.g., PHI, to protect data transmitted from the NDS, to protect the NDS from unauthorized/malicious access or CT. Includes application of. These steps may include applying one or more encryption, firewall protection (e.g., including web application firewall(s)), or both.

In aspects, the Secure Sockets Layer (SSL) protocol may be used to protect sensitive/confidential information (SI) that must be kept confidential based on contractual, proprietary, or regulatory reasons. In aspects, secure channel Java applet transport may also be used to protect SI. Data encryption algorithms that can also be applied to these data protection methods include, for example, RSA Data Security RC4, Data Encryption Standard (DES), and Triple DES (3DES). In aspects, S(s)/F(s) includes monitoring SI access, usage or transmission, such as using database activity monitoring (DAM) software/tools. Examples of other commercial data security tools that can be applied to NDS (or whose components can be integrated into NDS) include Sophos Intercept X for Server, IBM Security Guardium, and Oracle Audit Vault. Includes Oracle Audit Vault and Database Firewall, Imperva Data Security, Trend Micro ServerProtect, and SQL Secure. In aspects, the firewall function includes a list of authorized commands that may vary depending on user/entity authentication level, etc. Firewall and authentication features, such as IP address evaluation, may also be duplicated, reporting abnormal information, attacks against the NDS, etc. In aspects, the SI-containing engine(s), DR(s), or both are segmented from other DS(s)/unit(s) by data curation rules/methods. Typically, each type of DS is identified by one or more identifiers, including type identifier(s), which aids in segmentation and protection of SIs. Typically, the NDS will include a confidential information module (CIM) that may contain or configure a key management system to store access keys, policies, protocols, monitoring method(s) or CTs. Most or all NDS information may be stored encrypted. Regional storage tags/rules, etc. may also be applied to limit/control or verify information access. In aspects, some, most or all components of the NDS reside in a secure network with no or limited ability to receive Internet-based external (inbound) communication(s). NDS may include several isolated subsystems in some aspects, but may share, or sometimes share, a message queue in some aspects. In aspects, data is extracted from the NDS/method only by API call. Other examples of methods/techniques for protecting SI in networks/systems, e.g. encryption, firewalls, etc., applicable to NDS/methods include, for example, US10601593, WO2001037152, US8010791, WO2013064565. US6148342, US10581605, US20180300497, US9436841, US6148342, and references cited therein. Methods for protecting confidential information can be found elsewhere.

The firewall used by the method/NDS may provide security in aspects by selectively allowing or denying access to the private network. A firewall may be/include/implement NAT, proxy, other device(s)/function(s) or a combination of two or more of these or similar system(s)/component(s)/engine(s). These engine(s)/device(s) may block or limit unauthorized incoming data and unauthorized incoming requests from devices on the private network. A firewall can provide security against unwanted connections by isolating devices "behind" the firewall from the public network. A firewall can also restrict how internal computers access external public sites, such as sites on the Internet. One technique for setting up a firewall is to maintain a list of "authenticated" addresses. The address information contained in the remote device's data packet may be checked by an applicable security method/unit, for example to check whether the original source is listed. Only packets coming from approved addresses can pass through. NDS may also include cryptographic functions/engines, which may include arbitrary logic, business rules, functions or actions to handle the processing of any security-related protocols, such as SSL or TLS, or any functions related thereto. there is. The encryption unit may, for example, encrypt and decrypt network packets or any portion thereof communicated through the appliance, establish an SSL or TLS connection on behalf of the client, or both. In aspects, the cryptographic unit/function provides a VPN between the MA/ONDI and the network NDS using a tunneling protocol.

The application firewall, in aspects, may inspect or analyze any network communication according to rules or policies of NDS/CIM to identify any confidential information in any field of the network packet. In embodiments, an application firewall identifies PHI/confidential information in network communications and takes policy action on such network communications (e.g., rewriting, removing or masking confidential information, blocking messages, etc.).

In aspects, proxy server(s) are included in the NDS/network architecture (e.g., deployed behind NDS firewall(s)). In some cases, proxy server(s) may initiate a communication session with a network client device (MA, OND, etc.) "through" a firewall(s), as is known in the art. In these aspects, the firewall(s) do not need to be specially configured to support incoming/outgoing sessions/communications, thus DOS reduces the risk of communication loss for proxy server managed communication(s).

In aspects, the method also includes steps to ensure that the MA's data is safe from unauthorized physical tampering, malicious Internet tampering/access, or CT. These steps may include the application of tamper-evident software, firewall security, authentication, and other physical tamper-evident mechanisms, discussed elsewhere. In aspects, the method(s) may be implemented in one or more areas where one or more zones are relatively restricted, e.g., there is no direct Internet interaction (e.g., connectivity or communication), or permitted Internet data exchange is extremely restricted (e.g. For example, no more than 10, no more than 7, no more than 5, no more than 3 allowed transaction types, for example, controlling restricted area components, updating zone/MA operating systems (but generally requiring a pool of local users). may be limited to only) or both) and includes the use of MZMA.

2. Status and operating mode data

In aspects, the NDS may detect MA operating mode(s) or other MA-related status information (e.g., device malfunction). MA operation mode detection may be performed by receiving status data transmitted from the MA, contextual data analysis, or both. For example, in aspects, the NDS may detect MA in a non-clinical mode of operation and use this functionality for, for example, research and development or scalability testing. In aspects, maintenance of the network/NDS may include providing a non-operational status signal to the NDS and evaluating the ability of the NDS to operate with such a test MA/simulator or with such a test MA/simulator added to the current network data load. The test includes the performance of a competency test using the MA or MA simulator/simulation. The detected MA mode may also include the application status of the MA, e.g., MA participating in clinical research, basic/basic MA/network research, or both. The MA mode may also include the MA in local MA repair/maintenance mode in aspects.

3. Data transformation and data characteristics

The steps of the method of the present invention may include one or more data conversion processes, which may include device control, display of instructions on a device/interface display, or other data display or data control application (e.g., alarms/alerts or reports). may result in Data transformation includes a data collection layer, a data collector/ingestion layer (where data is moved from storage to a data pipeline for processing/analysis), (e.g., steps include data cleaning, data reconciliation/formatting, or CT). ), a data enhancement layer (e.g., NDS Analysis Unit (NDS-ANALU)), a data enhancement layer (e.g., NDS Analysis Unit (NDS-ANALU)), where query processes and other intensive analytics applications occur - e.g. applications, e.g. Apache It can be used at the data query layer (through the use of Hive), or at the data visualization/application layer.

The method of the present invention can also be used in a variety of ways, including both RT/S and cached data as mentioned, as well as data in different formats, such as unstructured data, semi-unstructured data, structured data, or combinations thereof. May include processing of data with different characteristics. The analysis step of the method can also generate and relay data in a variety of similar formats.

“Structured data” generally means organized data, e.g. data that is mapped to predefined fields in a structured array, e.g. data consisting of columns/rows or fields/records. Structured data typically contains about 5 or more, 6 or more, or about 7 or more data relationships, often ~2 levels or more, 3 levels or more, or ~4 levels or more of data or data types or data transformations or special data (e.g. For example, it will contain several columns (attributes), rows (values), and tabs; a table with records, fields, primary keys, and queries; etc.) Structured data generally includes relational data. Structured data is usually rigid/fixed in structure. Unstructured data generally refers to data that cannot be contained in a highly structured or structured format (e.g., a row-column database), has no associated data model, or both. Examples of unstructured data records include web pages, text messages, images, social media content, documents, and recordings. Semi-structured data is data that has a limited amount of definition or consistent characteristics/relationships, but does not contain complex structure or follow a strict structure as expected from structured data. Semi-structured data may be characterized by simplicity of relationships, heterogeneity of data content, or both. An example of a semi-structured data record is an email, which has a limited number of structured (value/attribute) elements (sender name, recipient name, sent date, and subject), but is typically largely unstructured (in the primary content of the message). There is. Other examples may include XML, EDI, CSV, ORC, Parquet, TSV, HTML and OEM documents/objects (however, some CSV/TSV delimited structures may be/can be classified as structured data). Unstructured data can be converted to semi-structured data by applying metadata (e.g., in the case of video or image data, which may include shooting date, shooting location, photographer, or CT, but is primarily unstructured data). Semi-structured data attributes are often not aligned consistently. In a step/method, the input includes, mainly includes, or generally consists of semi-unstructured data, for example SUMAD. In aspects, the step of the method is Receiving some, most or generally all input of at least some type, e.g. MA-D, in a particular semi-unstructured format, e.g. JSON format. In aspects, the serialization/deserialization step includes: Performs similar or specific other formats to provide more data in the target format (e.g., JSON or Avro). In aspects, the JSON formatted data input may include a separate list (e.g. (e.g., through inclusion of a backet delimiter). In aspects, most, generally all, or substantially all JSON data for each JSON or similar semi-unstructured input file is typically comprised of no or substantially no data repetition. In certain methods, the semi-unstructured data input of the method(s) is limited to a source set, expected data values, etc. In aspects, the NDS resource is Attempts to identify data. In aspects, the policy prevents adding other types of inputs without SO approval and NDS modification. This limitation is applicable to semi-unstructured data in NDS DR despite the semi-unstructured nature of the collected data. ensures that queries based on are effective, while the semi-unstructured nature of the input ensures that the input file size is small and simple, thereby reducing the DoS collection time in aspects. Methods may include applying MLM to SUMAD, for example, text analytics models such as key feature extraction, sentiment analysis, context analysis, etc. In aspects, methods include use of a system adapted to processing unstructured and semi-structured data, such as MongoDB or Aparavi. In aspects, methods include using a system capable of simultaneously processing unstructured, structured and semi-unstructured data, such as the Aster Centerprise System or the Microsoft Azure Data Management System.

The method may include applying metadata to data as part of a data transformation step. Metadata is generally "data about data" or data that provides information about a file, record, data set, chunk, stream, packet, or other data structure. Metadata may include source information (e.g., device identifier, device-entity association, device-location relationship, device type identifier, subject identifier, subject type, treatment method, associated HCP(s)/user or CT). . Metadata may also or otherwise include structural metadata (e.g., data types, data relationships, properties, hierarchies, expected scope/type/unit, level, etc.), administrative metadata (e.g., permissions, creation date, update, etc.) date, update instructions, administrator contact information, etc.) or reference metadata (e.g., how the data was acquired - e.g. RT/S MA-D, cached MA-CD, NDS-AD, or how the data was converted, e.g. For example, schema application, query results, application output, modifications to improve data (e.g., data cleansing, MLM results, or arbitrary CTs, etc.). Metadata can include, for example, access control descriptors, legal definition descriptors, and summarized and aggregated definitions, which can be used to control access to data in a data lake or other data store or to drive search heuristics. . Additionally, implementations may automatically recalibrate, enhance, modify, or recalculate data based on substantially continuous tracking of the object's lineage information, system origin, process transformation, or specific transformation version applied to the data.

In aspects, most, generally all or substantially all of the data of one or more types (or the entire data input) received as input by the NDS is streaming MA data (SMAD) or real-time data (RT/S data). “Streaming data” generally refers to data that is delivered as a data stream, which is typically a set of data that is unbound (of unknown or unlimited size) and is continuously updated (at least while the source is running and online). The method may include receiving, selectively analyzing, selectively acting on, and collecting stream data through the application of a streaming data processor (SDP) and related methods for processing the data stream, e.g., stream partitioning. . In aspects, a method includes generating a sequence of ordered, replayable, fault-tolerant, and immutable data records in a stream partition creation where the data records are defined by key-value pairs. Processor topology refers to the computational logic of the aspects of data processing. In a stream processing application, the topology may include, for example, a graph of stream processors (nodes or stream processors) connected by streams (edges). Typically, each node is used to transform or collect data. Standard operations such as maps or filters, joins, and aggregates are examples of functions performed by a stream processor as part of an input function/unit. The stream may be stateless, but the method may include partitioning the stream into stateful data records (allowing joins, aggregation and application of window functions and fault tolerance methods). Unit(s)/function(s) (timestamp extractor) can apply timestamps to all stream derived data records. Aggregation operations can take an input stream or table and combine multiple input records into a single output record to create a new data structure, for example a table. A join operation can merge two or more input streams or tables and create a new stream/table based on the keys of the data records. Stream processing methods typically include RT monitoring functions including status/threat reports/monitoring data/output, trend detection, event detection, etc. In aspects, the method includes applying a method to ensure that most all or generally all data is processed in order. In aspects, the method includes F(s)/S(s) to provide sufficient time for the incorrect partition to be re-associated with the correct partition. These methods provide for one or more data cycles in which a collection of data is generated from partitions prior to one or more levels of analysis (e.g., by engine(s)/component(s) that may be classified as data stream aggregators). This may include: For example, in one aspect, when partitioned data is collected, an initial data collection cycle of at least 5 seconds, at least 7 seconds, or at least 8 seconds is used before an initial analysis method is used on the first level of assembled data collection. and, in a further aspect, assembly of a larger second level data set comprising an initial dataset that is a collection of multiples of the first level prior to authorizing consumption of the data by one or more applications (e.g., an MLM application). Longer periods of time are used, for example, more than 1 minute, more than 2 minutes, more than 3 minutes, or more than 15 minutes. In aspects, the first level data set is continuously evaluated in the construction of the second level data set, and if an error is detected and cannot be corrected during the second data cycle, the data that would have been collected in the original second cycle window/period The second data cycle can be started again without losing some or all of . These methods also demonstrate the use of a combination of processes that can feature streaming/RT collection along with batch processing for the collected RT/S data. In aspects, a method includes aggregating first data collected over a first data cycle time and subject to a first analysis, and aggregating the first aggregated data collected over a second data cycle time and further subjecting the second analysis to a second analysis. Collecting streaming MA-D (“SMAD”) from a second aggregate that is the target of, wherein the data cycle time for collecting the second aggregate is at least 5 times the first data cycle time, and at least 10 times the time. time or 25 times more time; The first analysis and the second analysis are different; The second analysis is more data intensive, more processing intensive, or both than the first process; The method further comprises evaluating each first aggregation for suitability for inclusion in a second aggregation and resetting any second data cycle when the first aggregation is determined to be unsuitable prior to completion of the second aggregation. Includes. In aspects, this method is performed mostly, generally, or only on SMAD derived data after collection in the NDS DR.

Streaming queries performed as part of the initial analysis performed by the SDP may be processed, for example, using a micro-batch engine, which processes the data stream as a series of small batch operations to reduce end-to-end latency. Approximately 1-500, 1-250 or approximately 1-100 milliseconds, with exactly one fault tolerance guaranteed. Event Hub, IoT Hub, Azure Data Lake Storage Gen2, and Blob Storage are supported as data stream input sources. Kafka Streams and similar frameworks are designed to handle streaming data input and related processes. Event Hubs are used to collect event streams from multiple devices and services, such as networks. Blob storage can be used as an input source to collect bulk data into streams such as log files relayed from MA. Azure Stream Analytics, a cloud-based service for collecting high-speed data streaming from devices, sensors, applications, websites, and other data sources and analyzing that data in real time, uses some, most, or generally all streaming data inputs or It can be used to perform analysis processes. In aspects, such a platform or other method analyzes incoming data for anomalies or information of interest (e.g., streaming data indicating a change in a patient's condition, which could signal an emergency or the onset of a life-threatening condition). application changes are required to prevent this, which may trigger the NDS to send warnings/alarms or treatment component instructions or control data).

In aspects, the streaming analytics service/unit (SDP or component thereof) operates with a throughput of about 1 MB/sec to about 50 MB/sec. In aspects, streaming data flow(s) may also be received, initially processed (initially transformed, analyzed, curated, or CT), and stored as RT, as discussed elsewhere herein in aspects. Applies in one or more respects to the period being considered. In aspects, NDS capabilities and processes may enable data collection, transformation, application, or relaying processes, or combinations thereof, with low latency (e.g., between ~0.0001 - 100 seconds, between 0.0001-50 seconds, 0.0001-10 seconds, or between ~0.0001-10 seconds). 1 second, or other measurements provided herein) and is achieved and maintained on average over most, generally all, or substantially all operating periods, or both, which may also or alternatively characterize the process as RT. . In aspects, the streaming characterization is generally supported by a substantially continuous flow of data from most, generally all, or substantially all network devices. In aspects, the RT system may be a “soft” RT system with a latency, for example, of ˜0.5-10 seconds, or an average in the range of ˜0.001-0.1 sec or ˜0.001-0.1 sec, where some, most or all of the time may be used. /Can feature a “hard” RT system with the most latency.

The method of the present invention may include performing at least some data transformation, at least some data analysis, at least some data application or CT on RT/S data before such data is committed to NDS DR (collection). In addition to other methods described herein, stream processing methods combine multiple computational units, such as a floating point unit of a graphics processing unit or a field programmable gate array (FPGA), without explicitly managing allocation, synchronization, or communication between those units. You can use it. In aspects, a series of operations (kernel functions) are applied to each element of the stream. Kernel functions are typically pipelined, and optimal local on-chip memory reuse is attempted to minimize bandwidth loss associated with external memory interactions. Uniform streaming is common, where kernel functions are applied to all elements of the stream. Stream processing hardware can use scoreboarding, for example, to initiate direct memory access (DMA) once dependencies are known. Eliminating manual DMA management reduces software complexity, and eliminating involvement in hardware cache I/O reduces data area expansion associated with servicing by special computational units, such as arithmetic logic units. Stream processors are typically equipped with fast and efficient memory buses (e.g., crossbar switches or multiple buses, e.g., 128-bit or 256-bit crossbar switch matrices (4 or 2 segments)). Pipelining is a very widespread and widely used method in stream processors, and GPUs featuring pipelines exceeding 200 stages can be applied/used in the method. The "cost" of switching settings varies depending on the setting being modified. "To avoid costs/burden at various levels of the pipeline, the method can be applied to Many technologies can be deployed, such as "ber shaders" and "texture atlases". Stream processing data is called an event stream processor (ESP), which can collect data streams and process them with low response time and no data loss. Streaming event data may be generated by beacons, which may send MA location data to the NDS, for example.

Non-commercial examples of stream programming languages/frameworks/systems include Ateji PX Free Edition, the Stream-Based Supercomputing Laboratory at Washington University in St. Louis, which uses the MapReduce algorithm, actor models, and stream programming in JVM Auto-Pipe. It enables simple expressions, and the ACOTES programming model: the language of the Polytechnic Institute of Catalonia, the Brook language from Stanford, RaftLib - an open source C++ stream processing template library originally from the Stream Based Supercomputing Lab at Washington University in St. Louis, and StreamIt from MIT. and WaveScript are also functional stream processing from MIT. Commercial implementations include AccelerEyes' Jacket, a commercialization of the GPU engine for MATLAB, IBM Spade - Stream Processing Application Declarative Engine (SPAED: see System S Declarative Stream Processing Engine), RapidMind, a commercialization of Sh (acquired by Intel), and Nvidia's CUDA (Compute Unified Device Architecture), Apache Kafka, Apache Storm, Apache Apex, Apache Spark Streaming, Apache Flink, Apache Flume, Amazon Web Services - Kinesis, Kinesis Streams, and Amazon Firehose, Google Cloud - Dataflow, IBM Streams, and IBM Streaming Analytics, Oracle Stream Analytics, Oracle GoldenGate, Microsoft Azure - Includes Stream Analytics and its components/related applications (e.g. PowerBI, Trill Steam Processor, etc.).

In aspects, a method may include remotely managing one or more aspects of NDS operation. For example, methods may include scaling, data transformation, data collection rules, queries, or relaying data to remote maps, MLM maps, or other network devices in other applications. A cloud-based NDS or NDS component can be deployed across multiple virtual machines (vAppliances), including, but not limited to, multiple virtual local area networks (VLANs) and potentially compute node (C-N) nodes (also known as servers). Can include bridge routers (BR-RTR), routers, firewalls, and DHCP-DNS (DDNS) across the data center for combined expansion. A cloud system virtual network may include, for example, a software defined router, a Demilitarized Zone (DMZ) firewall, or both. The queue function/method of the RT/S data collection process may receive data packets/streams through a redundant system of messaging servers, the packets containing instructions/requests for information from the NDS, data for analysis, or both; The queue function is processed or a control processor (controller) that can determine, for example, the capacity to process a packet, keep the packet in a buffer until capacity becomes available, and forward the packet to the NDS/network component when it is ready for processing. ) can be relayed. Determining availability may include checking other components such as memory, processors, routers, firewalls, etc. for load/capacity. In aspects, a stream processor/message broker or other component of the NDS-INPU may generate a data stream comprised of data segments obtained from multiple separate sources (e.g., two or more MAs associated with a subject). In aspects, a similar process is performed at the analysis level, e.g., both upon reconstructing MA-D from cached MA-CD and before/after RT/S MA-D. Streaming analysis functions include selecting stream(s) corresponding to a parameter, parameters or profile indicative of a condition requiring immediate NDS action, for example, based on a comparison of in-memory stream data with such a model. , and relaying a warning/alarm or device control command based on such event detection decision(s). The streaming analytics process can also help you evaluate MA performance against similar parameters and determine whether the MA is behaving as it should, is working properly, or both, and take appropriate action. Such methods may include non-invasively extracting one or more data features from data stream(s). The collected data is stored in the NDS DR, which may include a DL (for example, a cloud-based scalable DL such as Amazon's D3 DL) or an EDL. In aspects, the stream/streaming processor initial recruitment process may be generally, substantially or fully automatic in generally, substantially or all instances of operation. In aspects, the initial query/analysis/function may operate substantially continuously in the stream processor framework. In aspects, methods include the use of a live data mart used to aggregate streaming data for queries or other applications in real time or near real time. In aspects, the streaming processor framework may include a connector for data conversion/translation. A stream processor cluster can store temporary data locally and transfer global data into and out of the stream register file. To enable multiple stream processors to be interconnected, the stream register file may also, in aspects, be connected to a network interface such that an entire data stream can be transferred from one processor's stream register file to another processor's stream via an input unit/NDS. It can be transmitted as a register file. Using software pipelines, each cluster can also process multiple stream elements simultaneously. The combination of data parallelism, instruction-level parallelism, and software pipelining can help stream processors leverage large numbers of arithmetic units for media processing applications. In aspects, the NDS includes a vector processor (and possibly additional vector memory/registers) in conjunction with or in place of the stream processor(s). In aspects, a near real time (NRT) process may follow current events with a sufficiently immediate degree of responsiveness to current events, or with a sufficiently short latency, or in a manner that is reasonably meaningful with respect to such events. In context, it can be understood as a slower ability than RT processing. Additional methods, frameworks, applications, principles and strategies/architectures applicable to RT/S data processing include, for example, US20150032879, US10672204, AU2015252037, US8880524, US9270937 and US6195701. , US7512829, US7627685, US7827299, US8271666, US8689313 and US9158775.

II. Analytical processing of MA-data and other data

Data processing by an NDS processor, such as MA-D, may be performed at various levels, each level following one or more processes that are different from any other one or more levels. For example, raw incoming MA-Ds may be subject to initial data enhancement/enrichment, tagging or curation as described elsewhere at a first level, and at a second level these initially converted MA-Ds may be subject to It may be subjected to one or more analysis processes by an analysis unit of the NDS processor unit (eg, MLM).

The NDS analysis unit/analysis service may extract the desired data from the NDS DR (e.g., NDS DL/EDL DR) and then implement an algorithm or algorithms determined to be suitable for performing on-demand real-time patient-specific data analysis requests. To provide the processing power and speed needed to efficiently perform many algorithms on large data sets, analytics services may leverage compute clusters that contain multiple servers that provide the processing power needed to run one or more algorithms. there is. A cluster can be defined as a type of parallel and distributed system consisting of a collection of interconnected standalone computers that work together as a single integrated computing resource. The computing platform of the NDS (analysis unit(s)) also includes data integration services to process, transform and validate data received from external entities such as MAs, HCPs, CMRSs, etc. prior to the initial or secondary collection of the NDS DR. Modules may be included. Parallel processing of data-intensive applications typically involves partitioning or subdividing data into multiple segments that can be processed independently using the same executable application program in parallel on a suitable computing platform, and then reassembling the results to produce a completed output. It involves creating a . Data parallelism allows computations to be applied independently to each data item in a data set, which allows the degree of parallelism to scale depending on data volume. In aspects, some components of NDS use a shared-nothing architecture that ensures that there is no single point of failure in at least part of the NDS environment (e.g., each node operates independently of the other nodes, so that no If a failure occurs, other machines will continue running). In aspects, a portion of the NDS memory operates as a massively parallel analytics DR, e.g., database using columnar architecture(s).

Parallel processing in NDS can operate mostly, generally, intrinsically or only on a Multiple Instruction Multiple Data (MIMD) basis. In aspects, a portion of the processor operates in Single Instruction Multiple Data (SIMD), such as in a vector processor. In aspects, the NDS/method generally represents/includes task parallelism, including a pipeline with many independent modules and independent branches executing in separate threads. In aspects, NDS/Network also exhibits pipeline parallelism (e.g., typically a pipeline is partitioned into subnetworks that operate on different tasks, e.g., streams). In aspects, NDS is also configured to exhibit or apply data parallelism, where data elements are decomposed and processed in parallel (and typically merged back into a result/dataset).

In aspects, the NDS can detect most, generally all, substantially all, or all MA-Ds received by the NDS within 1 second, e.g., ~0.75 seconds or less, ~0.5 seconds or less, ~0.25 seconds or less, ~ It can be collected and initially processed within time periods that are impossible for humans, for example, within 0.15 seconds or less, ~0.1 seconds or less, or even within, for example, hundredths of a second, milliseconds, or millionths of a second. . In aspects, MA-D is critical care medical data. In aspects, for example, at least the initial analysis of the SMAD for the presence of an alarm/warning condition is performed within ~2 minutes or less, within ~1 minute, within ~0.5 minutes, within ~0.25 minutes, or within ~5 seconds of receipt. do. In aspects, the initial analysis is performed prior to or concurrently with collecting the SMAD at the NDS DR.

One. machine learning

In aspects, NDS-ANALU includes implementing CEI(s) to perform one or more machine learning (ML) methods on data set(s), e.g., data related to a particular condition, physiological parameter, or CT. . In aspects, developing ML method(s) includes applying feature learning method(s), feature engineering method(s), or both to feature(s) to develop ML method(s); Applying supervised or semi-supervised learning/refinement of these ML method implementation features; Applying reinforcement learning or unsupervised learning to enhance these function(s); and ultimately allowing the function(s) or aspects of the function(s) to be managed by the trained model. In aspects, functionality implemented with machine learning may characterize, for example, a medical condition. In aspects, functionality implemented with machine learning may identify patterns or relationships, and, for example, unexpected data anomalies. In aspects, functions implemented with machine learning may also be used to predict matches, differences, events, etc.

In aspects, an NDS machine language module (NDS-MLM) analyzes MA-D from homogeneous or heterogeneous types of MA and optionally further performs or recommends performance of one or more functions of NDS based on such MA-D analysis. . According to aspects, machine learning (ML) may be applied to all data received or processed by one or more units of the NDS. In aspects, NDS builds a predictive function based on the learning increase achieved by NDS-MLM over time. In aspects, the NDS-MLM can analyze and compare MA-Ds received from peer MAs and what this data has been associated with in the past.

There are various known ML algorithms/models that can be used in these approaches, such as data classification methods, Naive Bayes classification (or Bayesian network methods), decision tree methods, decision rule methods, regression methods ( For example, logistic regression, lasso regression, SVM regression, ridge regression or linear regression), random forest methods are known and are often used in supervised ML methods. In aspects, the ML model often uses an unsupervised enhanced ML method, e.g., k-means (or a variant thereof, e.g., K-means++)/nearest neighbor analysis model, e.g., k-nearest neighbor analysis model. Close neighbor analysis; Other clustering methods (e.g., partitioned clustering, mean shift clustering, density-based clustering (e.g., DBSCAN method), or hierarchical clustering (e.g., agglomerative clustering)); and multidimensional mapping methods, such as self-organizing mapping methods; and method(s) used in affinity mapping (e.g., event detection or event prediction). In aspects, reinforcement learning methods, such as artificial neural network methods, are applied. In aspects, ML methods include ML methods for data decomposition, e.g., decomposition methods, e.g., single value decomposition methods, dimensionality reduction methods (e.g., principal component analysis (PCA), singular value decomposition (e.g., Singular value decomposition (SVD) or TSNE) or combinations thereof are included. In aspects, the ML method uses a model-free method in the context of reinforcement learning, for example a Q-learning method. In aspects, MLIF includes model-agnostic methods, such as Partial Dependence Plot (PDP) methods, ICE methods, ALE plot methods, LIME methods, etc. Other ML models that can be used include partial dependence plot methods, such as Generalized Linear Model (GLM), Generalized Additive Model (GAM), etc. ML implementation function(s) may include, for example, deep learning methods, shallow learning methods, or combinations thereof.

In aspects, the ML/AI application (AIA) applicable to the step(s)/function(s) (S(s)/F(s)) of the NDS/method may be characterized at the map level of the MLM/AI application. there is. In one aspect, the MLM(s) are supervised learning (SL) MLM(s). In aspects, the MLM(s) are semi-supervised learning MLM(s). In aspects, the MLM(s) are unsupervised learning MLM(s). In aspects, the MLM(s) are compensated by the MLM(s). In aspects, the NDS/method includes two, three or all four of these types of MLM. In aspects, any MLM(s) of a SMGA or method/NDS may vary from one form of MLM to one or more other forms of MLM (typically a less supervised form of MLM, e.g., SL MLM to SSL MLM or unsupervised MLM). It proceeds by proceeding with). In aspects, the MLM includes S(s)/F(s) performed by the method/NDS (e.g., data transformation, e.g., tokenization, phrase/sentence/field segmentation, data structure recognition, or CT); Data cleaning, query generation (e.g. synonym recognition/application, stemming/truncation, lemmatization, metadata factorization or CT), query match/hit determination, DS(s) enrichment determination and dataset(s)/ DS(s) reinforcement)) and key/feature recognition S(s)/F(s) based on the associated training dataset. Certain AIA/MLMs, such as Naive Bayes, nearest neighbor decision trees, and related methods, are described and known elsewhere. Conditional random field (CRF) methodology can also be used in the MLM feature engineering/identification step(s) of an MLM with reference to relevant data sets. The classification process may include the application of a Multinomial Naive Bayes (MNB) classification type algorithm. The MLM process may also include the use of other clustering algorithms, such as mean shift clustering, Gaussian mixture models, or DBSCAN. MLMs can be updated dynamically over time through the provision of updated training data, user feedback, administrator input/guidance, or ACT. Training is typically performed targeting/using extracted or pre-identified feature(s)/element(s). In aspects, PHI/PII or other confidential information is removed from the training information or replaced with altered data similar to/based on confidential/secret information (SI) data, modified data, or a combination thereof (CT).

The machine learning model may be a machine learning framework known in the art, such as the TensorFlow framework, Microsoft Cognitive Toolkit framework, Apache Singa framework, or Apache MXNet framework, or equivalent, or perform similar or enhanced ML functionality. It can be implemented and deployed using any machine learning framework.

In aspects, the MLM training data may include focused/specialized corpus data (e.g., one or more models of MA sensor data of one or more MA types, one or more patient types, or both) or often may be based on an MLM method/resource, e.g. , may interface or interact with other processes/resources, featuring semantic networks (SN(s)), natural language processors (NLP(s)), or both. Supervised learning (SL) and semi-supervised learning (SSL) MLMs can involve generating confidence scores and evaluating the confidence scores for the MLM versus a threshold (e.g., an auto-tuning threshold) and determining if the confidence score threshold is not met. If not, we will route the test to an administrator to review the ML output in real time. Tests/analyses, etc. performed or managed by subsequent administrators may be fed back to the appropriate units/functions to continue NDS processing and may also be fed back to the ML training set for inclusion or specific training/modification of the MLM. To facilitate ML/AI method(s)/function(s), NDS includes neural network processor(s) or distributed processor(s) that may consist of neural networks or run software to model or simulate neural networks. It can be used to implement/enhance machine learning.

MLM(s) may be trained by feature engineering (FE) and feature learning (FL) processes on training data, initial application data, or both. Some, most, GA or all MLM(s) of NDS/methods operate, at least initially, based on SL or SSL. In aspects, in the early stages of an MLM function, a higher level of human (administrator) involvement may be common to make the improvement of the MLM function comparable, detectable, or significantly (DoS) above average/all human performance. . In aspects, applying MLM(s) improves DoS of feature performance with increased feature usage; DoS-enhance human-only performance (if possible within relevant timescale/accuracy), human-programmed function-only performance, or both; Or improve the Dos of all or any one of these.

The MA-D collection can be used as training data in a closed-loop manner, where the engine is continuously or iteratively trained using machine learning techniques in a supervised or unsupervised manner. In aspects, if there is a discrepancy between the engine findings and an administrator (or study user/HCP user) or other relevant opinion (including a decision to adjust, confirm or deny), a message recording that event may be sent to the MLM, MLM, for example, can provide learning by ML medical data review system. This may, in aspects, occur in an unsupervised manner where an engine ultimately provides feedback to another engine to create a closed loop learning scenario. In such cases, the first, second, and even third results may come from a non-human engine (or an engine of engines, e.g., a master MLM applied to multiple MLMs or MLM(s) and other analysis processes). . In aspects, ML interpretation and corrected/validated findings may be captured into a combined data set/cohort. These data/training cohorts can be used to retroactively learn by the ML engine, and these data can be injected into the healthcare data review process by the healthcare data review system to further improve the performance of the HCP/device or other non-ML analysis processes. You can validate, further improve training data, and develop new ML engines/MLMs.

In aspects, the MLM may be configured to detect one or more detected signals during a relevant period of time (e.g., the next day, about 0.25 days, ~1 hour, ~0.5 hours, ~0.25 hours, ~0.1 hours, or ~0.05 hours (~3 minutes)). It is used to predict patient status under certain conditions. In aspects, the predictive MLM not only provides subject-specific sensor data relevant to the prediction, but also provides access to performance data in the NDS memory or network, which may include data obtained from the study class's behavior or the behavior of another MA under similar conditions. there is. Investigational class devices may include investigational class MAs, which may be considered ONDs because they are not MAs in routine clinical use (investigational MAs may participate in clinical trials for the development of new MAs, new indications, etc.). In aspects, the MLM is provided with access to EMR data. In aspects, the MLM prediction data is relayed by the NDS/relay unit and then back to the MA provided with the actual target data, the relevant HCP, etc. For example, in aspects the prediction may include one or more critically ill conditions, such as cardiovascular conditions, such as those described in Abiomed, Inc., cited herein. This is described in the patent references. In aspects, the MLM data is used for output applications, such as control of a MA cardiovascular therapy task, pulmonary therapy task, or both, in an associated MA. In aspects, MLM DoS enhances the functionality of one, some, most, generally all or all aspects of NDS or MA operation.

2. Data cycle and data processing timing

The method of the present invention collects data, e.g. most or all RT/S MA data, for initial analysis, post-inflow/subsequent application (e.g. by U/F(s) of the analysis unit), or both. /Can include counting. The data collection period used to form a collection/aggregation can be considered a collection/aggregation cycle, which is sometimes simply described as a data cycle. In aspects, performing a function (e.g., receiving data)/gathering data for an initial application may be used to form a larger data collection for an NDS analysis unit application. In aspects, the time (i.e., data cycle) it takes to form the subsequent/secondary data collection(s) is significantly longer than the data cycle required to form the initial data collection(s). For example, in aspects, the secondary data collection cycle may be at least 5 times, at least about 10 times, at least about 20 times, or at least -50 times, at least about -75 times, or at least about -100 times. there is. In aspects, the secondary data cycle is at least about 150 times, at least about 250 times, at least about 500 times, or even at least about 1,000 times. In aspects, the initial data cycle (e.g., the time to process the receipt of the data stream) is subjected to limited data analysis, such as by an NDS streaming processor application (e.g., by a streaming processor application), as described elsewhere herein. It can be performed at the input unit level. In aspects, the function performed on the initial data cycle data includes evaluating the usefulness of the initial cycle data as a component of secondary cycle data. In aspects, the method includes rejecting and optionally restarting a second cycle data collection where the initial cycle is rejected by the NDS based on pre-programmed criteria. For example, the NDS analysis unit can complete the MA-D analysis, e.g., apply the MLM(s) to the MA-D within ~10 minutes, within ~5 minutes, within ~2 minutes, or within ~1 minute. may be less than, and the secondary data cycle is timed accordingly. In one aspect, one or more functions of the NDS analysis unit are based on processing MA-D collection over a period of time (typically much longer than the period during which the NDS receives the MA-D (initial data cycle)). In aspects, this period is at least 30 seconds, at least 40 seconds, or at least 60 seconds of MA-D per MA-D collection repetition/cycle, e.g., at least about 1 minute, at least about 70 seconds of MA-D per MA-D collection repetition/cycle. , about 80 seconds or more, about 90 seconds or more, about 100 seconds or more, about 110 seconds or more, about 2 minutes or more, about 2.5 minutes or more, about 3 minutes or more, about 3.5 minutes or more, about 4 minutes or more, about 4.5 minutes or more , about 5 minutes or more. In aspects, the initial data cycle may be, for example, ~40 seconds (sec) or less, ~30 seconds or less, ~20 seconds or less, ~10 seconds or less, ~8 seconds or less, ~6 seconds or less, ~4 seconds or less, ~ 2 seconds or less or ~1 second or less (e.g., 0.5 seconds or less or 0.1 seconds or less), during which time the initial analysis process is completed by the streaming processor(s) or other engine(s)/component(s) . In aspects, the NDS includes a set of unit(s) or performs function(s) that can be similarly classified as a cache data processor, and processes the MA-CD as such data is relayed from the MA.

Cache data processing may, in aspects, be performed differently than RT-SMAD processing and initial analysis/collection, although one or more of these processes may alternatively be performed on cached MA data (“CMAD,” MA-CD, or “cache data”). Evaluating the immediate output application may include, for example, evaluating whether an alarm is triggered based on the initial analysis of the cache data. The functionality and associated resources for performing these processes may be characterized as cache data processors/units. Processing of cached data may, in aspects, be performed using a batch process. For example, such data may be delivered as data sets larger than typical stream chunks/partitions, or may be individual (start, end, and size), or both.

In aspects, an initial data cycle (e.g., time to process the receipt of a data stream) is subjected to limited data analysis, such as by an NDS streaming processor application (e.g., by a streaming processor application), as described elsewhere herein. It can be performed at the input unit level. The reader will note that although RT/S-MA-D is discussed extensively herein, such data may, in aspects, not be delivered in real time but still delivered in a streaming manner, such data may simply be delivered in a streaming MA-D or It will be appreciated that it may be classified as “SMAD”.

The CMAD/MA-CD relayed/delivered to the NDS may, in addition to the SMAD, be an NDS input unit or its component (e.g. a special unit for MA-CD analysis, which may feature a "cache processor"), an SDP/SDE or an SDP The NDS input unit may be received by the MA-D based on the characteristic(s) of this MA-D, including in aspects the relevant timestamp, relevance of the relevant data, tagging or CT applied at the MA level. -CD can be distinguished from RT/S-MA0D. In aspects, the method of the present invention includes assembling a collection of cache data, using MA-CD to Reconstructing missing data from the relevant SMAD for the receiving MA), or a combination thereof. The cache processor performing these steps/functions may be a component of an SDP processor, a primary NDS processor, or an SDP and With respect to the primary processor, it may be a functionally independent processor, a physically independent processor, or both. The same relationship may apply to any memory specifically associated with the operation of the cache processor (e.g., a cache processor may be a functionally/physically independent processor). (may include native memory or simply represent/operate on the memory of an SDP or NDS-MEMU). In aspects, cache data is delivered in batches upon events or passing regular intervals. In aspects, the cache processor It operates through batch processing.In aspects, the MA-CD, relayed by most, typically all or all MAs in the network, may contain sensor data, temporal data, device operating characteristics, patient information, offline status, etc. in addition to location data. data or a combination thereof.In aspects, the MA-CD may be periodically stored in the NDS as a backup to the RT/S-MA-D (e.g., to allow for RT/S-MA-D auditing). transmitted, permitted for event(s), or both. The MA may relay MA-CD simultaneously with RT/S-MA-D or in batches between RT/S-MA-D transmission periods. . NDS is programmed with settings to understand and adapt to the MA-CD/CMAD transfer mode from the MA.

In exemplary embodiments, the method of the present invention includes an NDS/MAC-DMS processing unit automatically (1) collecting MA-Ds during a data collection period to form a data collection, and (2) forming a data collection into one or more pre-programmed data collections. Evaluate whether the data collection is suitable for analysis according to established standards/rules, etc.; (3) if the data collection is suitable for analysis, add the data collection to the data aggregation; (4) At least 2, 4, 5, 6, 10, 12, 20, 25, 50, 80, or 100 instances of the data collection are added to the data aggregation to achieve a complete data aggregation. and repeating steps (1)-(3) until a complete data aggregate is formed, and (5) if any instance of the data collection is determined to be unsuitable before the complete data aggregate is formed, the method may include: discarding incomplete data aggregates and starting the method again; and (6) once the complete data aggregate is formed, the method further includes performing one or more analysis functions on the data comprising the complete data aggregate. do.

3. Scaling of system resources

In aspects, the function(s)/portion(s) of the NDS may include, for example, pre-programmed demand threshold(s), e.g., the number of MAs in the network; The amount of data transferred from the MA (e.g., average amount per day, week, month, quarter, or year); The amount of analysis performed by NDS, other operational features of NDS (e.g., security features); Amount of data relayed from NDS; Amount of data stored in NDS; It can automatically scale in response to the timing requirements of data uptake, data processing or data delivery, or any combination of these, in the network. For example, in aspects, an NDS may be implemented in most automatically scalable cloud-based computer systems that include one or more special purpose units (e.g., special memory, special processing capabilities, or both), as described herein. , only generally or completely "included" or otherwise included. Scalable resources typically include input resources (e.g., SDP resources), but may also include DR resources, processing resources, etc. Accordingly, in aspects, NDS includes extensible components that respond on demand or automatically.

In aspects, the NDS/method includes a scalability test function/step that anticipates scaling needs (e.g., one or more portions of the NDS meets or exceeds one or more indication values/measures or other indicators), Test the addition of these resources (optionally reserving these resources to meet expected demand) and automatically add these resources as needed, as determined by detecting that a second set of threshold metrics/values are met/exceeded. do. In aspects, the added resource is added when the added resource is added, after the added resource is added, or both, to ensure that the scaling of the NDS is effective (e.g., there is no detectable or significant decrease in NDS performance). Resources are added in a scaled/incremental manner through selective testing of added resources. In aspects, resources may be added as needed upon reaching a predetermined demand threshold, such as demand for a unit, a combination of units, or an entire NDS. In aspects, security or safety measures are present within the NDS/method to ensure that the NDS continues to operate, e.g., that the NDS rarely fails to function due to lack of resources to handle demand. In aspects, the NDS maintains operation at or above a level(s) where the NDS demand is at least 99.5% of the time, such as at least about 99.6%, at least about 99.7%, at least -99.8%, at least about 99.9% of the time. maintain sufficient resources or maintain access to sufficient resources to

In aspects, the method includes performing scalability testing, capability testing, or both types of NDS/network testing using a real MA or simulation model. In aspects, the actual scalability/ability test MA relays state/mode data with respect to such test to the NDS so that data from such test MA can be appropriately tagged and curated/separated from other MA-Ds. (i.e. not factored into MLM).

III. Regulatory status of NDS-Data applications

NDS applications may be subject to various types of regulations and related requirements (“RR”) depending on the nature of the application controlled by the NDS application. For example, an NDS application may, in aspects, be software as a medical device (SaMD/SAMD) (i.e., software intended to be used for medical purpose(s) that performs such purpose without being part of a hardware medical device). May include applications regulated by . In aspects, the NDS simultaneously performs two or more, three or more, or ~5 or more SaMD applications in one or more MA types/classifications (e.g., in two or more MA types/classifications in a network). In aspects, the NDS SaMD application is a diagnostic application, a therapeutic application (eg, an application considered a digital therapy), or both. Therapeutic applications include applications that treat an untreated condition or an initially treated condition, applications that are associated with the maintenance of a condition, or prevention of the development of a condition (e.g., preventing the development of a condition, reducing the likelihood of developing the condition, reducing the severity of the developing condition, or may refer to medical operations/applications related to delayed onset of symptoms, etc. In aspects, most, generally all or all SaMD applications comply with the IEC 62304 life cycle/design/development standard. In aspects, SaMD applications performed by NDS include a mix of IEC 62304 Class A, Class B, and Class C applications. In aspects, SaMD applications performed by the NDS include a mix of FDA minor concern, moderate concern, and major concern applications. Considering the various regulatory characteristics and applicable RRs associated with possible NDS applications, the NDS or NDS Relay Unit may implement tagging, compliance standards, other data curation/transformation methods (e.g., PHI removal or protection), or a combination thereof. can be used to ensure appropriate treatment of NDS applications matching the corresponding RR. As such, the method may include application/analysis of output and application of such data curation step(s). In aspects, most, generally all or all SaMD applications of the NDS are used only in clinical settings, subject to review and approval by regulatory authorities. In aspects, an NDS application includes two or more SaMD applications with various levels of SaMD approval/classification. For example, in aspects the SaMD application provides the HCP with information to make treatment decisions or apply treatment-related device controls/parameters for non-critical care or critical care diagnostic or treatment purposes. (And in the EU, for example, they are regulated as Class IIa devices or Class III/Class IIb devices respectively, the latter depending on the possible consequences of these decisions). In aspects, SaMD applications are directed towards monitoring of physiological processes (e.g. regulated as a Class IIa device in the EU or as a Class IIb device in the intensive care environment).

In other aspects, one, some, most, generally all, substantially all or all NDS data applications are non-SaMD regulated applications. In aspects, NDS applications include a mix of SaMD regulated applications and non-SaMD applications. In aspects, one, some, most, generally all, substantially all, or all NDS applications may be classified as a clinical support decision system (CDSS) that is generally not regulated as a medical device. A CDSS typically includes a knowledge base (here, MA-D from subject-related devices and similar device/patient combinations), an inference engine (e.g., analysis U/F(s)), and a means of communication (e.g., relaying the NDS-AD to the MA, other HCP devices/interfaces on the network, or both). The CDS knowledge base includes rules and associations in compiled data, most often in the form of IF-THEN rules. Warning/alarm functions are often considered CDSS. Recommended courses of action, provision of information, etc. may also be classified as CDSS applications. In aspects, NDS uses an expression language, such as GELLO or Clinical Quality Language (CQL), in the delivery of some or most CDSS applications. CDSS applications may also use MLM (if MLM-specific applications are used, these AI applications may feature knowledgeless CDSS). ML/non-knowledge based systems may include, for example, support vector machines, artificial neural networks, genetic algorithms (using random sets of possible solutions, such as mutations, iterations, etc.), or combinations thereof. The CDSS application, the SaMD application, or both may include actual and delivered analytics of predicted data, e.g., predicted A1c, predicted heart rate, predicted respiration/oxygen concentration, etc. Metadata tags applied by NDS/NDS relay units typically include regulatory status information. Delivery methods include screening of MA locations to ensure that only approved SaMDs are used in the relevant country/jurisdiction. CDSS functionality may include providing warnings/alarms as well as treatment/diagnostic recommendations and similar function(s).

In aspects, the methods of the present invention include applying the core components of the NDS outside of regulated SaMD applications to MAs, HCPs, and other classes of users in other countries. Such adaptations may include, for example, making components of the NDS available to users in other countries, but segregating SaMD applications only to users in countries where such SaMD applications have been approved by the appropriate regulatory authorities. In aspects, the steps/methods of making the core component(s) of the NDS (e.g., some, most, and generally all) separate from the unit(s) classified as a SaMD application regulated by a national or regional regulatory agency. or all component(s)/engine(s)) may involve sharing these core components between sub-NDSs or NDS parts/components focused on specific regulatory regimes. In aspects, the NDS, a portion of the NDS, or a feature of the NDS may be subject to application (e.g., in a particular country or other jurisdiction (e.g., an international jurisdiction (e.g., the EU) or a local jurisdiction (e.g., a state or administrative district))). s) are specifically limited to. In aspects, the NDS may include both (a) a MA, e.g., data for an MA in a particular country, (b) a plurality of rule sets, e.g., country-specific data governance rules, and (c) . In aspects, an NDS includes a core architecture that is copied or shared between two or more country/jurisdictional NDSs. For example, in aspects, an NDS blueprint data/core component can be transferred to one or more other NDSs, e.g., 3, 4, 5, 6, 7, 8, via copy or shared access via the Internet. , 9, 10, 15, 20, 25, 30, 35, 40, 45, or about 50 or more NDSs.

IV. NDS Process for MA OS(s)/Software Updates

The MA typically includes an operating system (OS) or special software that coordinates the MA's function(s)/engine(s) involved in data communication between the MA and the NDS. In aspects, an operating system (OS) of some, most, generally all or all MA(s) in the network; MA software (e.g., software related to the application of MA functions, such as MA:NDS communication, therapeutic/diagnostic functions); Or both may be subject to update(s) during the operational life of such device. With respect to MA, without contradiction, the terms software and OS provide implicit support for each other herein (e.g., an aspect describing a MA OS update also implicitly discloses a corresponding aspect of an MA software update) . In aspects, OS/software updates are triggered at the local/MA level, NDS/network level, or both. In aspects, some, most, generally all or all updates to a particular MA's OS/software, MA type, MA class (e.g., an MA associated with a particular entity), or a particular zone/processor of the MZMA may include local/ Participation (input, approval or other action) is required at both the MA level and the NDS/network level. In aspects, some MA system (OS/software) updates/modifications can only be performed at the local level (e.g., in aspects the highly limited therapeutic component of MZMA can only be updated at the local level). In aspects, the NDS informs the user of the availability of updates/fixes to the MA system, for example, via alerts/alarms or other messaging sent to the MA, other network interface/device, or both. In aspects, MA system updates are mostly, generally or entirely, relayed from the NDS via the Internet and downloaded to the MA. In aspects, the MA OS/software versioning is or should be included in some, most, generally all or all MA-D streams/data, thereby facilitating targeting of updates and update availability messages by the NDS. In aspects, NDS monitoring for the MA or zone software/OS may result in output to physically transmit updates to a local user (e.g., USB drive, external hard drive, disk or other memory device), Users, if authorized, can modify this OS/software locally. In aspects, a zone processor may operate independently, be updated independently, or both, from another zone processor (or another zone processor and any primary MA processor), which may occur according to the various methods/procedures described above. That's it. In aspects, processor(s) of the MZMA may be updated according to a method/process/procedure, while a second one or more processor(s) of the MZMA may be updated according to a different method/process procedure.

The invention also provides a method for controlling the operation of an MA to detect information about the operation of the MA in the network, for example, to determine the MA performance level, MA performance problems, identify opportunities to improve MA performance, etc. provides. In these aspects, the NDS/MAC-DMS processor/analysis engine evaluates the performance of the medical device in one or more aspects of the network, MAC-DMS, or both. These assessments can be performed automatically, on demand or conditionally automatically, continuously, repetitively/routinely/periodically or only on-demand. In exemplary embodiments, such methods may utilize previously collected MA-D analysis data, other/related standards (e.g., other measures of physiological state, such as subject heart rate, etc.), or the performance of other MAs of the same or different type. Involves assessing the MA-D of one, some, most, or all MAs. In aspects, the method includes changing at least one parameter of medical device operation, NDS/MAC-DMS operation, or both based on an evaluation of the medical device and NDS/MAC-DMS. MA-D analyzed in this way may include log data related to device performance. In aspects, this log data is data that is collected in a restricted area of the MZMA, transferred to a less restricted area, and relayed to the NDS for subsequent analysis (a data flow that is also applicable to other MZMA-related methods). In aspects, data in an MZMA restricted area is identified based on data tagging (applicable to these and other MZMA related aspects). In aspects, these methods are performed on aggregation/collection of data that may be collected over minutes, hours, days, weeks, months, or years. In aspects, this log data/MA-D also or alternatively includes subject-related sensor data. In aspects, this data is organized according to standards, etc. to identify unusual patterns, outliers, etc. that can be subject to NDS analysis and output. In aspects, this method DOS increases the likelihood of identifying MA operational problems compared to identifying such problems at a single MA or even single MAG level. For example, MA-D analysis with log data containing heat pump-related aortic pressure (AOP) or left ventricular pressure (LVP) measurements; unexpected sensor data may cause device behavior issues ( For example, heart pump motor operation issues such as motor current) can be determined.

In another aspect, the present invention includes causing each operating medical device (MA) in a MA:NDS data network to repeatedly, routinely/automatically or conditionally collect sensor data from an associated subject/patient, Provides a method of treating the medical condition(s) of a subject/patient in the population; The NDS Analysis Engine/Function is capable of converting MA-D from any, most, or each operating MA of the MA:NDS data network to (I) previously collected MA-D analysis data, (II) pre-programmed standards, or ( III) compare to both (I) and (II); The method further includes causing the NDS/MAC-DMS processor to relay one or more outputs via secure Internet communication to one or more MAs, one or more ONDs, or both, wherein one or more outputs are (a) (I) MA associated with the patient, (II) another network device associated with healthcare provided with respect to the patient, or (III) analytic data output associated with the patient's care relayed to both (I) and (II), (b) (I) one or more MA functions (e.g., treatment functions) on one or more of the medical devices in the data network, (II) one or more MA functions (e.g., treatment functions) on one or more of the other network devices in the data network that are associated with the healthcare provider associated with the patient; other network device functions (e.g., alert/alarm registration), or (III) one or more output applications containing instructions that control the operation of both (I) and (II), or (c) (a) and Includes combinations of (b).

In aspects, the method also or alternatively includes diagnosis of a disease state for treatment of the disease state of MA. In aspects, operation of the MA:NDS network can detect or significantly increase the probability of identifying the subject's condition type associated with the MA in the data network. For example, by applying MLM(s) to the MA-D collected by several/many MAs in the network, MLM in NDS can detect these problems faster than previously standard-of-care diagnostic devices. It can be trained to detect warning signs of DOS conditions faster than was possible with NDS, or faster than previously possible using NDS. This is one of the advantages of collecting large amounts of data through the NDS of the present invention and using this large data pool to generate NDS-AD such as MLM prediction(s).

Embodiments illustrated in the drawings

In this section, additional aspects of the invention are described with reference to flow diagrams/block diagrams of the methods. The reader will generally understand that each "block" of a flow diagram/block diagram, and combinations of blocks therein, may be implemented through CEI execution by the processor(s). The CEI units/functions reflected in such “blocks” are provided to the processor(s) of the applicable device(s)/system(s) to create a machine, system or both, where the CEI executed by the processor is the block(s). Implement the system/function specified in . These CEIs are stored in a CRM (e.g., NTCRM/PTRCRM) that can instruct the applicable computer(s) to function in a particular way according to the CEIs, thereby storing the DR(s) (including functional data) and the CEI(s). A CRM comprising a manufactured article that performs a useful practical operation.

Although the embodiments illustrated herein are described with reference to flowcharts/block diagrams, any portion or combination of each block, block, combination of functions, etc. may be combined or separated as may be appropriate within the context of the NDS or method of the present invention. It can be separated into operations or performed in a different order. References to “module,” “unit,” “step,” etc. in this disclosure are generally made for the convenience of the reader and are not intended to limit the implementation of any method or NDS. Any portion or combination of any block, module, etc. may include computer executable (program) instructions (e.g., software), hardware (e.g., combinational logic, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), etc. ), processor(s) or other hardware), firmware, or any combination thereof (CT). That is, the flowcharts, block diagrams, etc. reflected in the drawings illustrate the architecture, functions, and operations of possible implementations of the NDS/method. Each block in the flowchart/block diagram may represent a device, component, module, segment, CEI, or part of a CEI for implementing the specified step(s)/function(s). In aspects, the arrangement of the step(s) or function(s) of the method described with respect to this block may occur in an order other than that depicted in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order depending on the functionality involved. The reader is advised that each block in a block diagram or flowchart, and any combination of blocks in a block diagram/flowchart, may be implemented by a special-purpose hardware-based system that performs a designated function or action, or may perform a combination of special-purpose hardware and computer instructions. Be careful.

Different programming techniques may be used, for example procedural or object-oriented approaches of NDS(s)/method(s). Any particular routine may be executed on a suitable single processor, multiple processors, or even multiple devices. Data may be stored on a single storage medium or distributed across multiple storage media, and may reside in a single database or multiple databases (or other data storage technologies). Accordingly, although steps, operations or calculations may be presented in a particular order, this order may be varied in alternative aspects and any one of the specifically disclosed routines/workflows provided herein may be used to provide the indicated output. It may involve rearranging, repeating, skipping, combining, or any combination thereof (CT) of the above step(s)/function(s). In embodiments, to the extent that multiple steps are shown sequentially in the drawings, in alternative embodiments some combination of such steps may be performed simultaneously. Where appropriate, any sequence of operations described herein may be interrupted, halted, or otherwise controlled by another process, such as an operating system, kernel, etc. Routines can run in an operating system environment or as stand-alone routines. The functions, routines, methods, steps and operations described herein may be performed, for example, in hardware, software, firmware or any CT described herein.

For these and other reasons, the description of the aspects of the drawings and the description set forth herein in connection with the drawings are not intended to be within the scope of the invention as provided by other portions of the disclosure or within the scope of the disclosure taken as a whole in the light of ordinary skill in the art. should not be used to limit .

Displayed elements are generally identified with the "#" symbol in the following: When references to elements are repeated in the drawing description, additional element reference(s) may be omitted. Abbreviation "n.s." Refers to features/steps not shown in the drawing.

Figure 1

1 illustrates an example basic relationship (#100) between a medical device (“MA”) (#102) and a network data system (“NDS”) (#150). The arrows in this and similar figures provide a non-limiting illustration of the flow of data through a system, network, or network relationship (as represented in this figure). Lines around components in the figures (e.g., MA-MEMU (#112) and MA-DISPU (#120)) indicate that these components are part of another depicted component/system (here, MA or NDS, as applicable). It indicates that it is or is related to this.

MA(#102) is associated with (often at least partially inserted into), for example, a blood pump (e.g. a heart pump) or a human subject (HSUB(#104)) and is typically a support system ( For example, it may be a portable extracorporeal membrane oxygenation (ECMO) system and may include electronic/computational hardware for data collection, storage, processing, transmission and reception. MA (#102) includes sensor(s) (#106) that respectively detect physiological condition(s) of HSUB (#104), operational conditions of MA (#102), or both. Sensors may include, for example, flow sensors, pressure sensors, and other sensors associated with medical devices that collect this data and process it with stored instructions, perform data analysis, and other functions as described throughout this section. relay electronically to the MA processor(s) (MA-PROCU(#108)), which consists of computer processor(s) to perform (s). Sensor(s) typically measure physiological states (conditions) (e.g., blood pressure, heart rate, oxygen levels, respiratory rate, blood product levels, brain function, etc.) as well as other types of sensing data. The MA-PROCU (#108) is capable of transmitting MA-PROCU (#108) via electronic communication following the transmission of programmed instructions, e.g., status signal packets, typically in secure Internet communication via wireless communication (e.g., via Wi-Fi). Contains or is associated with a component(s) that operates as a MA-STATU (#110) that periodically sends status signal(s)/communication(s) (e.g. ping signals, etc.) from the NDS to the NDS. do. The MA-PROCU (#108) records sensor data in a local device memory unit (MA-MEMU) (#112), which may also contain stored instructions for functions/modules running on the MA-PROCU. The MA-PROCU (#108) also has a relay unit (MA-RELAYU) ( Contains or is associated with component(s) that can constitute #118). When online, information relayed by MA-RELAYU includes locally stored/cached data (R-LST-MA-D is also known as MA-CD or L-STR-MA-D (#120)) and streaming "real-time" data. " Contains MA data (RT-MA-D(#122)).

NDS (#150) includes an input unit (NDS-INPU (#160)) that receives and processes reception information relayed from MA (#102). The input unit may contain instructions (protocols) in a virtual server environment to receive and process MA data or separate physical processor(s), memory, or both (e.g., for SDP, as e.g. illustrated in Figure 23). /function) can be expressed. Received MA data is relayed to the NDS processing unit (NDS-PROCU(#162)), which typically operates on multiple massively parallel, highly available, virtual/cloud-based, scalable and distributed processors, typically in one or more hosting facilities; NDS-PROCU (#162) will typically include an NDS status unit (NDS-STATU ( #164)), determines the state of a networked MA (#102) (state machine(s)/component(s) may also or alternatively be included in the MA). NDS- PROCU is a locally stored data analysis unit, LS-D-ANALU (#166), which analyzes locally stored MA data (MA-D) (#120) (aka cache data, R-LST-MA-D, etc.) It may further include engines/modules/units/functions for analysis of received data, such as RT-D-ANALU (#168) for analyzing real-time/streaming MA-D (#122). These analysis units ("ANALU ") includes a memory component (e.g., special software instructions/engine(s)) in combination with the processor(s) when placed in an operational configuration and operating as a special device for processing this specific type of MA-D. NDS (#150) may also include, primarily include, or consist of one or more DR(s), such as a Data Lake (DL) or an Enhanced Data Lake (EDL). , Contains NDS-MEMU (#167), a generally configurable or essentially configurable NDS memory unit, for example, for received data, analyzed data and NDS-PROCU execution. Stores the command: NDS-PROCU (#162) is typically the NDS Security Unit (NDS-PROCU), which filters and restricts data relayed from NDS to ensure the protection of PHI in accordance with regulatory requirements (“RR”). After "passing" (analyzed/checked) SECURU (#180), NDS data responsible for data transfer to MA and other network devices/interfaces (ONDI (#182)) (e.g. system administrator) It further includes or is operably connected to a relay unit (NDS-RELAYU) (#170). In this aspect, the MA-D received by NDS (#150) may be analyzed by one or both of the reference analysis unit (ANALU) component(s) (#166 and #168) of NDS-PROCU (#162). The analysis output generated by this analysis (NDS-AD) is (1) often passed through a device/MA security unit, such as a device-level firewall or security system (#172), and then passed through the MA input unit (MA-INPU). )(#174) (which may include, for example, a NIC card or similar component/system and associated engine(s)) to the MA (#102) and (2) to another network device/interface (ONDI)(# 182). Real-time MA data (#120) can be analyzed mostly/usually/essentially in a streaming manner, except when the MA (#102) is offline, in which case the MA data stored during the period that the MA (#102) is offline -CD/cache data is relayed to NDS (#150) to process the function, reconstruction/harmonization of RT data received before and after offline events with these stored cache data.

Figure 2

2 shows a group (#200) of MAs (#202), each MA (#202) associated with a subject/HSUB (#204), real-time streaming MA data (RT-MA-D) (#220), and at least Provides an overview of a simplified representation of the network with each MA sometimes/intermittently transmitting locally stored/cache data (L-STR-MA-D/MA-CD) (#222) to the NDS (#250) do. The illustrated NDS ensures compliance with regulatory requirements (RR) when transmitting data derived from the MA to ONDI (#264), as well as the memory unit NDS-MEMU (#256) and the processor NDS-PROCU (#258). Includes a security unit/engine/system (NDS-SECURU) (#262) that In the example network illustrated, the MAs are grouped/sub-networked (sometimes referred to as networks), e.g., MA Network 1 (#270), where each network includes multiple MAs (e.g., excluding PHI); It consists of MA Network 2 (#280) and MA Network 3 (#290). The lines around MAs in the diagram help define MA groups/networks. Each of these MA networks (which may be referred to as a “subnetwork” to avoid confusion with the overall network, which includes multiple MA subnetworks/OND subnetworks and NDS) may be an owned/controlled entity, region or other characteristic, e.g. For example, it may be characterized/defined based on geographic area, device configuration, etc. Subnetworks/device groups in the overall NDS network may be organized at different levels (e.g., independent entity subnetworks may include regional subnetworks, hospital subnetworks, etc.). Subnetworks may include entry points/nodes (not shown) that include security systems (eg, firewalls), etc. MAs in a subnetwork may relay subnetwork-specific data (e.g., confidential information accessible to independent entities owning or operating MAs in the group/subnetwork). NDS-PROCU (#258) processes data from all associated groups/networks as well as data stored in NDS-MEMU (#256), and delivers analysis results obtained from the analysis of these data back to each group/network associated with the MA. However, it uses the combined overall network data to perform common analysis processes that can be used to pass data back to MA/MA users, ONDI, or both. This configuration of the system of the present invention allows the system to utilize information across various groups/sub-networks, improving the analysis of the overall system (e.g., in terms of machine learning applications) while ensuring that only a few independent entities have access to it. Ensures that confidential information can be accessed only by appropriate entities. This information may be relayed to other network devices/interfaces (ONDI) (#264), which may be associated with commercial class users, for example, the owner/operator of the NDS, and may have certain information such as PHI. After passing the NDS security process (NDS-SECURU) (#262) to prevent relaying to ONDI, support/service is provided to two or more IEs associated with different MA groups. In this respect, NDS (and also or alternatively other devices on the network) ensures proper identification of data on the network, screens information for such identification, to protect such information from unwanted/inappropriate access/placement; It is configured to maintain the confidentiality of confidential information in the network at at least two different operational levels by applying modifications, routing, corrections, etc.

Figure 3

3 shows one level of an MA network/group containing several MA subnetworks associated with different areas (metropolitan, state, county, country, hospital network, etc.), reflecting another aspect of system/network operation of the present invention. Here is another simplified diagram for: For example, area A (#302) has three MA groups/networks (as designated by the boxed areas in the figure): MA network/group A1 (#304), MA network A2 (#306), and MA network A3 (#304). 308)), each MA network is shown to include a plurality of medical devices (e.g., 5 or more, 10 or more, 20 or more, 30 or more, 40 or more, 50 or more, or 100 per network). These MA subnetworks/groups may be associated with different Independent Entity (IE) owners (from each other, from the NDS/System Owner/Operator, or from both). Separate area B (#310) includes MA group/network (MAG) B1 (#312) and MA network/group/subnetwork B2 (#314), while separate area C (#320) also contains MA group/network (MAG) B1 (#312) and MA network/group/subnetwork B2 (#314). Includes only network C1 (#322). In operation, NDS (#350) collects data from each MA group/network, including location information, affiliation information, or both, about the MAs in each area/network (e.g., state Receive (e.g. as a transport packet sent from such MA) which may be transmitted as a signal or other transmission to NDS(#350), allowing NDS(#350) to identify the data source, and enable NDS(#350) to identify the data source Not only can it return data specific to a particular patient at the MA or MA user level, but it can also perform MA network/group or area level analysis to other network components (e.g. ONDI(#364)), e.g. Serve as a scientific liaison, salesperson, researcher, NDS/systems analyst, or clinical support staff, and study or observe performance at the network/area level or conduct comparative studies between networks or areas. Identifying the appropriate areas of client devices on the network allows NDS to perform MA group level analysis, assists in relaying confidential information only to the appropriate receiving devices, or allows NDS to operate under the regulatory requirements of a particular group/area (or owns a group of MAs). /According to the requirements of the IE that runs it), ensure that only approved applications are relayed. In these aspects, the NDS and the network device are configured to provide data that can quickly identify MA-Ds as being associated with these different levels of sources (specific MAs/patients, groups, regions, etc.), so that the NDS performs analysis at these various levels or provides output to the user based on these levels simultaneously.

Figure 4

Figure 4 provides an overview of an example process that may be performed by the system (NDS) when dealing with a potential MA offline period issue. At the beginning (#402) of the illustrated exemplary process (#400), the MA(s) collects (#404) data from the subject(s), for example via MA sensor(s). The MA(s) in the network periodically attempt (#406) to transmit or receive status information from the NDS via status units (MA/NDS STATU(s) (e.g., when in one or more operating states/modes). (periodically transmits a status signal). If the MA is offline (#408), the MA transmits RT-MA-D (and possibly MA-CD) (#410). If the MA is not online, the MA It is adapted to automatically indicate (identify/record) the start of an offline state and the MA continues or starts (#414) the collection of MA-CD/cache data and stores this cache data in the MA memory. (or on a regular basis, always on), the MA continues to transmit/receive status signals to the NDS (#416). If the MA is not restored to the online state within a preprogrammed time (#418), the MA will One or more alarms can be sent (#419) to one or more user(s) via the controller (n.s.). When the MA resumes its online state (#418), the MA will -STR-MA-D) to NDS (#420) NDS-PROCU or its components are responsible for the use of cached L-STR-MA-D in continuous analysis processes related to MA-D, network, area, etc. Evaluate the sufficiency (#422) of the cached MA-CD against one or more sufficiency standards/rules or algorithms/protocols to make a sufficiency decision (#424). If there is insufficient data, the MA-D Transmission (#410) of RT-MA-D (in combination with L-STR-MA-D/MA-CD) can be restarted. Once the stored data is deemed sufficient, the NDS-PROCU can (aka C-MA-CD) (e.g. combining/blending (#426) this data with data stored on another network (N-STR-D)). This blended data is It can be further harmonized/blended (#428) with data from other MAs, and NDS-PROCU will use these data to perform one or more analytical processes, e.g. AI/ML processes (#430), resulting in is relayed (#432) back to the MA(s) and in each case displayed (#436) on the MA display, and data derived from this analysis may also or alternatively be transmitted (#434) to ONDI. Typically, these processes will restart in an iterative manner during MA operation.

Figure 5

Figure 5 illustrates a scenario (#500) further illustrating the collection and possible processing of cache data/MA-CD/L-STR-MA-D as in Figure 4, but here with example physical components and operations of the network portion. Refer to the location of the portable MA in use. A human subject/patient (HSUB) (#504) is diagnosed/treated with MA (#506) while being transported through Area 1 (#502). MA relays real-time streaming MA-D (RT-MA-D(#510)) to NDS processor (NDS-PROCU(#522)) via wireless network point (#508) at the first time (8:30) do. Then, at the second time (10 minutes later / 8:40), when the subject is in Area 2 (#516), which lacks wireless communication capability, the MA is tagged/marked L-STR-MA-D (aka MA- Starts collecting CD or cache data (#518) and stores it in device memory (MA-MEMU (#520)). Once the subject reaches the location identified as Zone 3 (#511) (at 8:50), which is again associated with the wireless relay (#508), the MA will receive a new RT-MA-D (# 512) and L-STR-MA-D (#518). If sufficiently determined/detected by the MA/NDS, additional data, such as known or expected causes of network communication errors, may also be relayed, sensed, or predicted. The ability of the NDA/MA network to effectively store, relay, and process real-time MA-D as well as these cache data, as temporary offline states are possible in these transmission settings or in the event of a network or device issue/outage, is critical to the application for MA data. significantly improves efficiency, providing better data, better NDS operation, and better patient care.

Figure 6

6 shows that at least a portion of the MA/NDS network (#600) includes an NDS including a MA network (#602) and an NDS processor (NDS-PROCU (#604) and NDS memory (NDS-MEMU (#636)). In addition to this, other network devices/interfaces (exemplified in the illustrated system (#600) as commercial networks/groups/components (#668), research groups/platforms (#644), and clinical support components/groups (#624) ONDI) is exemplified.

Each of these other network/NDS components, such as the MA Network (#602), may concurrently/simultaneously utilize MA-D, NDS-AD, or both, but each of these other network/NDS components is also typically regulated. Due to requirements, confidentiality concerns and different data needs/roles of users in these networks/NDS, different modalities of this data are received. Therefore, the NDS processor (NDS-PROCU (#604)) receives MA-D from the MA network (#602) and applies data enhancement functions to these data (e.g., cleaning, harmonization, etc. (#628)). and stores these data in memory (NDS-MEMU(#636)), as well as within limited time windows (e.g., less than 10 minutes, less than 5 minutes, less than 2 minutes, less than 1 minute, less than 30 seconds or 20 seconds from each other). to efficiently tag, sort, organize and analyze MA-Ds (in less than a second), generate NDS-ADs, and execute NDS-ADs and associated controls/commands (applications) to these various components in the network in an effective, secure and efficient manner. Simultaneously accesses the programmed instructions (engine(s)) in the NDS-MEMU (#636) PTRCRM through embedded processing components that use these instructions/code to distribute regulatory requirements (RR) and other rules. (e.g. NDS-PROCU (#604) ensures that only output of data destined for/directed to various network components/devices is properly forwarded to other authorized/appropriate network component(s) (may include output function(s)).

Commercial networks (#668) interface with or support commercial roles within the healthcare organization that manages/owns the network (#600), such as salespeople, medical liaisons, marketing specialists, business intelligence specialists, etc. A network of devices or interfaces (e.g. any Contains a number of web pages (accessible via the Internet from any suitable device). The company that owns/manages the system, network, or both is also typically the company that manufactures/distributes the MA(s), sells NDS operating services, or both. In aspects, some, most, generally all or all of the professionals accessing the devices/interfaces in these commercial networks act in a commercial sales and marketing role for the network administrator or organization that has access to the NDS/system. Regulatory requirements (RR) for these professionals may differ significantly from other users of these systems (e.g., HCPs who treat patients with MA), such as with respect to access to PHI. Accordingly, the NDS-PROCU (#604) component, e.g., the machine learning component (NDS-MLU (#608)), is in aspects more suitable for commercial networks (#668) than for example for MA (#602). It is adapted/configured to apply different rules to the output provided. Specifically, users in commercial networks/groups (#668) may receive structured user roles, capabilities, and applicable RRs/other requirements, which data will be provided to HCPs using and accessing the MA (#602). The content or form is significantly different from the display. For example, Rep 1 (#670) may support multiple hospitals in a hospital network, so each hospital typically has individual device data limited to high-level performance aspects (usage, errors, health, etc.) without disclosing PHI. You will receive a display of data about the MA performance. Rep 2 (#672) may receive similar information about unique, identical, or overlapping sites, entities, or networks. Devices on the commercial network can provide data directly to the NDS-PROCU (#604), but there are also independent data sources that can provide data to the commercial network user interface/device, such as a customer relationship management (CRM) database. (#664) (e.g., a Salesforce™ CRM database), and such data, in aspects, is blended by a local component of such interface/device, NDS, or both to bind to such user. Display of information (e.g., entity information and sales information of CRM combined with usage and clinical outcome information of NDS-AD) may be provided.

The HCP may receive data via software from one or more NDS-PROCU functions regulated by regulatory authorities, for example, as medical device regulations. For example, a first software, SAMD1 (#678), as a medical device application executed by the NDS processor/engine(s), may provide treatment instructions to the HCP, while a second application, SAMD2 (#686), may provide treatment instructions to the HCP. Allows direct control of one or more operating functions/parameters of the MA. Other NDS-PROCU features used at the MA level may include clinical decision support (CDS) systems (“CDSS”). For example, the first CDSS, CDS1 (#682), is received by NDS-PROCU as RT-MA-D, followed by RT-D process (#616) and machine learning unit(s) (NDS-MLU (#608 )) can provide possible treatment options based on the detected MA conditions analyzed by both, the latter with data from many MAs in the network (#602), historical MAs stored in NDS-MEMU (#636) Data is extracted from or both. The relationship of these components of NDS to the overall NDS processor (#604) (or primary NDS processor) is reinforced by the boxes surrounding these components. A second exemplary CDSS, CDS2 (#690), provides analysis support functions extracted from both MA- and other data stored in the patient EMR(s) (#696) (and optionally NDS sends output to the EMR(s)). Includes. Exemplary support functions include providing alerts when changes to MA settings appear to be inconsistent with treatment status based on CDSS, providing recommended MA settings or other courses of action, providing alarms based on the RT-D process (#616), etc. This may be included. The EMR data passes through the EMR Security Unit (#694) in a highly secure manner to the NDS-PROCU (#604), which performs packet scanning, for example, to identify data packets containing acceptable elements, while also It may contain one or more firewall(s)/filter(s) scanning for potential malware/viruses, encryption, and thus NDS-PROCU (#604) will typically recognize this EMR data and send it to an authorized HCP ( s) will include function(s) to route such EMR data to prevent access to users of the NDS other than those of the NDS. NDS-PROCU (#604) applies tagging of data routed to CDSS versus SAMD processes, for example, providing only those data required for individual CDSS/SAMD processes and taking into account the different regulatory authority status of these processes. can do. For example, the security or correctness of different SAMD functions (#678, #686) is generally at or above the level required (more intensively) for CDSS processes (#682, #690), and in particular for SAMD processes that directly control aspects of MA processing. will be demonstrated, verified, and maintained/audited at the local/limited), level (by NDS, users, or both). Additional security unit(s) (SECURU(s)) (#692) can be applied at the network level, MA level, or both, e.g. firewalls/filters, to ensure that only appropriately tagged MA data is stored in each MA and each MA function. It can be delivered to .

Likewise, a research platform/group/network (#664) typically includes multiple users, user organizations, or both. As illustrated herein, the research platform (#664) is comprised of a plurality of clinical research sites/devices (illustrated herein as Site 1 (#648), Site 2 (#652), and Site 3 (#656)). This typically includes networks of different independent entities (e.g. different clinical research organizations, university hospitals or other organizations involved in clinical research) or even different networks within an entity (e.g. Represents a device/system/group managed by a team or clinical study). Data accessible on research platforms (#664) may be subject to significantly different RR than on commercial networks (#668). Modifications to data forwarding, access, etc. to support compliance with RR and other requirements (e.g. contractual requirements) can be modified, for example, through permissions/settings and filters applied to the output of e.g. NDS-PROCU (#604). It can be managed by applying /firewall (or permissions/settings) (#660). Research platform users also have access to some, most, or generally all NDS-PROCU features, such as the Data Store Query Process (#620), which allows them to query data stored in NDS-MEMU (#636). and, for example, users on commercial networks (#668) cannot access it. The query process may include applying one or more schemas (#632) to data contained in portion(s) of NDS-MEMU (#636), stored NDS data, for example, as discussed/exampled elsewhere. As described, it may be semi-unstructured data stored in data lake (DL) format or EDL format, which generates query response data (Query-D (#640)) that is delivered to the research platform user(s). Additionally, in many aspects, unlike commercial network (#668) users, research platform users may provide data directly to NDS-PROCU, for example, clinical study data, modeling data, research analysis data, etc. Thus, for example, some NDS analysis processes may use data from the research platform, for example in developing machine learning models, and the research platform data is the source, primary or only source of information for those models. These models may be limited to specific applications, taking into account the research characteristics of the data on the research platform. For example, such data may be used in CDSS, but is not suitable for use in SAMD functions.

A clinical support network/group/component (#624) is a group of professionals involved in monitoring the condition of patients with MA in one or more care settings, usually in a specialty clinic (MA(#602)), a research platform setting (#644), or both. Includes other devices/interfaces (ONDI) that can be accessed by. With respect to users in the clinical support component/team (#624), access data in NDS-PROCU (#604) may be subject to different rules than other classes of users (e.g. commercial users), who may be subject to MA /A different display of NDS data (MA-D, NDS-AD, or both) is provided, and thus a different profile/tools/interface than users on commercial networks (#668) or research platforms (#644) are provided (output (but may overlap more with interfaces passed to HCPs accessing similar data from MA, ONDI, or both). Clinical support personnel can use RT-D processes (#616) based on MA status information (data analysis capabilities performed on streaming MA-Ds), processes performed on locally stored MA-Ds uploaded after an offline event (#616). 612), or both. In aspects, clinical support personnel are associated (employed or contracted) with the NDS owner/operator. NDS owner/operator employees and contractors may be subject to legal requirements ensuring confidentiality and compliance with applicable RRs.

Figure 7

7 illustrates a collection and data management process for data #700 associated with, primarily originating from/included in, or otherwise associated with at least a portion of an exemplary NDS/System Memory Unit (NMEMU (#702)). NMEMU captures both streaming real-time medical device data (RT-MA-D) (#704) and data stored locally in medical device memory (LSTR-M-AD (#706), also known as cache data/MA-CD). Receive. RT-MA-D is typically delivered in real-time (or near real-time), streaming format, or both. MA-CD is typically delivered via batch data delivery periodically upon an event (e.g., an offline event described above), or RT-MA when streaming becomes available (e.g., when the MA is brought back online). When combined with -D, it can be transmitted in a streaming manner. RT-MA-D is typically delivered as semi-unstructured data (SUMAD), unstructured data, or often a combination of these (e.g. state information (#730) that is stored as a collection of individual data and can be analyzed as such) , but attribute and value pairs (e.g. location: geolocation, device type: heart pump, etc.) are typically passed as SUMAD). MA-CD can also be delivered as SUMAD, orthotopic MA-D, or both. SUMAD typically has a relatively minimal number of features and limited data relationships (e.g., feature-attribute relationships at one level or less across a limited number of records), and allows relatively fast relay and data inflow/collection to NDS data. Facilitates processing of data from many input MAs to the processor(s) (n.s.).

To promote data integrity and usability, these methods include the following steps: cleaning incoming data (#708), applying (tagging) metadata (#710), and simultaneously or later sorting the data for further processing (#708). #720) may be further included. Data harmonization and other data enhancement processes from different sources (stored and RT/S data, different types of MA, etc.) are described in detail elsewhere herein. Systems/methods for performing these applications are provided elsewhere. These steps and specific data collections described below are included within the database diagram to reflect that most, typically all or all, are performed/contained in the NDS, most often the NDS memory unit (NMEMU (#702)).

NDS can transform, analyze, and sort MA-D and NDS-AD into various functional categories that affect data application, data access, and other characteristics. Timing is one of the characteristics that can be used for this characterization. For example, the NDS/method separates RT-MA-D (#722) which is considered "current" according to pre-programmed rules that sort RT/streaming data into blocks delivered within relevant short-term periods/"windows". Can be identified and applied. Short-term MA-D (#726) can represent different categories of MA-D associated with different time periods defining the group, which encompass RT-MA-D at this level/step of the NDS/method (process) It can overlap, overlap, or be differentiated from one another. Categorizing data from different time periods into collections allows the system to perform time-related analyzes on this data at two, three, or more time points. For example, NDS may perform analysis (e.g. automatically) on recently received/collected data and may be performed only over a limited period of time or over a longer period of time (hours, days, weeks, months, quarters or years). Separate analyzes can be performed on the stored data (for example, to establish a sufficient amount of data to meet minimum standards for performing a particular application).

The relatively raw MA data (e.g. RT-MA-D and MA-CD) received by the NDS can be subjected to further processing, such as sorting, by the NDS, which can then perform Analysis/AD can be created. Additionally, for example, MA-CD (cache data) (also sometimes shown in the figures as "L-STR-MA-D", meaning "locally stored MA-D") can be used to determine validation rules (e.g. After undergoing validation audit analysis (minimum data time, minimum data quality, etc.), it is characterized as a validated MA-CD (#724). A machine learning model/module (MLM) process may generate, for example, physiological parameters or other types of predictive data (#728).

NDS can also characterize/block data based on confidentiality rules. For example, PHI (#732) may be used by, for example, users/components (e.g., EMR, HCP users, etc.) that may receive or have access to PHI from users who may not be users of commercial network components. ) can be blocked/isolated/categorized/tagged separately from non-PHI (#734), facilitating efficient delivery of data to Other levels of confidentiality also generally apply to NDS data, such as data that can be accessed by specific user entities. This sorting may involve location/affiliation (entity) data, MA LOC/AFFIL.-D (#736), which may also facilitate analysis at the location, entity or group level. NDS-AD based on location/affiliation may also be presented in the form of summary information or non-PHI that can be accessed by users of commercial network components. In these and other aspects, the reader will recognize that these groups of data may overlap with other groups described above (e.g., RT-MA-D will typically include PHI).

Combinations of these properties can also be used to characterize/form other zones of network memory (#702), and these zones can be subject to rules/governance policies. For example, a SAMD access zone (#740) defines the collection of data accessible by SAMD(s) governed by a SAMD access policy (#742), and a CMD access zone (#744) likewise presets Defines a collection of data managed by NDS according to a programmed CMD access policy (#746). As mentioned elsewhere, the SAMD policy may be more stringent than the CMD policy, for example due to RR. In a similar manner, additional data areas include a research access area (#748) governed by the research access policy (#750) and a commercial access area (#752) governed by the commercial access (Acc.). A policy (#754) can be defined. The policies of these zones can reflect the different access levels and types of data that users associated with these "zones" can create and access under RR and other system rules. Another combination of data may include data derived from or directed to be delivered to the EMR(s), MA-DISPU(s), or both (#738), which may include various individual records containing PHI. there is.

Figure 8

Figure 8 is a schematic diagram illustrating the inclusion/application of different data zones for NDS data storage/memory unit (#800). The first data zone consists of inbound MA-D (#802), for example RT MA-D and MA log data (#804). Log data may include arbitrary data related to the occurrence of pre-programmed events (e.g., sending a MA-CD in the event of an offline event, registering a device alarm, etc.), as well as status information, service information by the application or the user, or both. It may also include actions taken, actions performed by the MA or MA User (HCP), decisions made by the application, actions timed by the application, runtime characteristics of the application, and any other types of log data. This region can be characterized as inbound external (MA) access only (#806), preserving the properties of the native MA-D in this region (e.g., being part of a memory unit, this region can be combined with any other aspect). can be considered a general aspect). The second zone, which supports network (NDS/Cloud Processor Unit) (internal) access, includes only, for example, curated data (#808) and scored data (#810), which are at least partially It can be derived from data stored in . Curated and scored data (#808 and #810) can be subject to governance policies (#812) that support, for example, cloud/NDS internal access and data separation. A third area, which acts as a sandbox (#814), can be accessed for individual user testing applications, proof-of-concept testing, etc. (#816). Area 4 includes outbound data (#818) and governance policies (#820) that support data export, e.g. restricting access to other data contained in the overall data unit, to the appropriate user(s). Appropriate data transfer, application(s) such as MA, etc. are applied. Data is sorted by section through meta tags, etc., and the engine(s) implementing such data sorting/curation, storage, and retrieval are provided elsewhere. The inclusion of these data governance zones, and the delivery of data to these zones after initial collection, for example as part of an enhanced data lake, can result in data collection and subsequent on-demand or conditional automated/automated applications performed on the data in the zone(s). The speed of can be detected or greatly increased.

Figure 9

9 is a representation illustrating various possible portions of an example network (#900), including a MA group and an NDS (#918), focusing on examples of the types of physical device components that can operate within such a network. .

The illustrated network representation includes multiple different MA groups containing different types of MAs that, at least in some cases, generate different types of MA sensor data (and thus the included NDS (#918) has access to receive and transmit data). Although only a few MA groups are illustrated to simplify the description, in many embodiments, more MA groups may be associated with an NDS (e.g., about 5 or more, 10 or more, 15 or more, 20). A group of 25 or more, 35 or more, 50 or more, or about 100 or more refers to a large number of devices, for example, about 10 or more, 15 or more, 25 or more, 50 or more, or 100 or more. , at least 150, at least 200, or at least about 250, each consisting of at least 3, at least 4, at least 5, at least 7, or at least about 10 types of MAs). As illustrated herein, the first MA network/group (#902) monitors and controls patient data related to the MA(s) of the first type of MA (N1 MA-1 (#904)), e.g., heart pumps. and one or more MAs of a second type of MA (N1 MA-2 (#906)), for example an extracorporeal membrane oxygenation (ECMO) system. The second MA group (Network 2 (#908)) is comprised of other unit(s)/group(s) of the first and second types of MA (N2 MA-1 (#910) and N2 MA-2 (#912)). ) includes. A third exemplary MA group includes another Type 1 device (N3 MA-1 (#929)). All three MA groups transmit data to NDS (#918). To illustrate aspects, N3 MA-1 (#929) includes displayable information displayed on MA DISPU (#933) where the data display conforms to the schema(s)/representation(s) generated by the NDS. Cleared via security unit (MA-SECURU(#928)), relaying information to telemetry function (#931), e.g. Wi-Fi transmitter or NDS (#918) and from NDS to NDS-AD, control It is shown as associated with another wireless protocol data transmitter that receives commands back.

NDS(#918) encompasses a cloud-based, scalable (demand-responsive, scalable) system architecture containing processor "units" (NDS-PROCU(#920)), which are typically massively parallel, distributed, e.g. , a high-availability, virtual processor, and a memory unit primarily comprised of a Data Lake (DL) (#926), which may include or be in the form of an Enhanced Data Lake (EDL) as described herein. NDS (#918) also provides analytics unit(s)/engines that perform the same functions as, for example, data lake applications (#924) (e.g., query engine, schema application engine, prediction engine(s), etc.) (s) and machine learning units/modules (MLU(#922)) that perform machine learning-based processes or processes including applications of machine learning. NDS (#918) also includes or is associated with a security unit (NSECURU (#950)) that includes, for example, firewall functionality, and collection and sorting of functional data suitable for use by various other NDS/network components. Associated with the feature filter (#954) that provides .

Other components of the network may include various network access/input devices (#958) including laptop computers, tablets, smartphones, etc. used by various users of the NDS/network. These users may include system administrators (#962), which includes users associated with the administrator/owner of the system who monitor and attend to system performance issues and perform other roles such as guidance of machine learning in the supervised machine learning module. Clinical Support (#966) is another miscellaneous network group/component that can monitor patient status as a backup function for the HCP. Users of the research component/program (#970) may also be provided with some, most or generally all N-AD, MA-D, or both via other network devices (#958). Similarly, users in commercial groups/components (#974) can receive optional N-AD (which typically does not contain PHI due to regulatory requirements) through network devices, while other external networks (#978) , for example, may receive data from a customer relationship management database/program, which may also or alternatively enable NDS to generate an NDS-AD from a combination of these other information sources together with the MA-D or other NDS-AD. Data can be relayed directly to NDS. From this example, it can be seen that the networks of the present invention can include levels of interoperability and complexity that far exceed anything previously described in the art, and that the systems of the present invention can provide data ingress and egress to and from the various constituent groups of such complex networks. It is found to be unique in that it is adapted/configured to process data output simultaneously, allowing better management of healthcare-related information at many levels of healthcare systems/operations.

Figure 10

Figure 10 focuses on data flow in these networks: MA (#1004), NDS (represented by NDS-PROCU (#1016)) and other network/NDS components (e.g., NDS-MEMU (#1052)) ) provides another example of a network component (#1000) formed between . In the illustrated example network, MA (#1004) is capable of transmitting, for example, video data (#1012) via a real-time/streaming process (and in at least some cases MA-CD) (e.g., MA or subject, and semi-structured MA-D, e.g. JSON formatted semi-structured data (#1008) as well as other status/log data to the NDS processing unit (NDS-PROCU #1016)), which may be, e.g., a web/cloud-based scalable, high-speed, highly available processor unit, e.g., any of the system(s) illustrated elsewhere herein. . NDS-PROCU (#1016) can receive additional input from devices associated with users assigned to OND, for example, research units/groups (#1020), HCPs (#1028), and commercial units/groups (#1040). there is. These ONDI users may provide semi-structured data entry, structured data entry, or both, for example, via email (#1024) or web interface (#1032) (e.g., mobile device app, web page, etc.) . External data repositories (DR(s))/services (#1036), e.g. CRM, may provide data to commercial unit users, or alternatively directly to NDS-PROCU (#1016) (e.g., in aspects such data is first processed by an NDS processor before being relayed to a system user, such as a commercial unit user, but in other aspects such data is also or alternatively combined at the user device/interface level, These devices receive data directly from an external database and typically blend it with NDS-AD according to, for example, NDS output parameters/controls. NDS-PROCU (#1016) supports various data integration processes (#1044) (e.g., data harmonization, validation, cleaning, etc.), data improvement/analysis processes (#1048), e.g., forecasting for healthcare management. As a tool, it can apply machine learning predictions of expected patient physiological data, leading to device displays, alerts or even MA controls, and then store these data in the system memory component (NDS-MEMU(#1052)); It may primarily comprise or consist essentially of a Data Lake (DL) or Enhanced Data Lake (EDL), and the NDS may also be accessed by network/system users or MA DISPU(s) (#1056). NDS-AD can be delivered through a web display/other Internet accessible interface. As can be seen from this example, the system(s) of the present invention are capable of receiving and processing a range of significantly different types of data and using this data to generate analytics leading to outputs that are transmitted back to the device or to other devices/interfaces on the network. Configured/adapted for use. NDS's ability to process these diverse inputs allows for more robust data collection, and NDS's ability to rapidly process these data inputs, for example by including DL(s), allows these system(s) to be used as previously described. Distinguish it from the existing system.

Figure 11

11 is a flow diagram illustrating the steps of an exemplary data processing method (#1100) usable with components of the system/network of the present invention. In this exemplary method, MA represents data, e.g., stream real-time data (RT-MA-D (#1102)), L-STR-MA-D/MA-CD (#1104), video data (#1106) ) (e.g., video on a MA display, as described in the Abiomed patent document cited herein), or optionally a combination of any/all of other types of data, operating in conjunction with or including a streaming data processor/engine. to a capable high-availability receiver (#1108), and then additionally captures these input characteristics (e.g., transmit/receive times, nature of the data, necessity of the data to perform NDS functions, and data size for the NDS process). It is sent to the message queue process (#116), which applies pre-programmed rules to prioritize the various data inputs for processing based on their impact.

The network demand assessment function/step (#1110) simultaneously evaluates the demand for NDS in terms of data flow, backlog of data to be processed, etc. If demand exceeds a preprogrammed threshold(s), the vertical/horizontal resource scaling feature (#1112) increases the number of available processors for parallel distributed processing that currently comprises NDS-PROCU (#1114), thereby: Increase NDS resources at either level.

After, before or during message queuing (#1116), the NDS-PROCU may apply other modifications to the incoming data, such as data tagging (#1118) and data cleaning and harmonization (#1122). NDS-PROCU also supports NDS, given the need for NDS to remain highly accessible and provide very fast (at least partially near real-time or real-time) responsiveness in healthcare environments, e.g., data needs, data timing, and MAY include asynchronous processing functions/protocols (#1120) to ensure prioritized data is reprocessed first, depending on factors including data impact on NDS functionality. The reader will understand that this prioritization of specific data types and the inclusion of asynchronous processing engine(s)/step(s) represent general aspects of the invention that can be combined with any other method/system aspects provided herein. will be. Prioritization may be applied based on rules (e.g., data such as device operability or patient health data are prioritized over other data), metatags or other data described herein or known in the art. It can be executed through application of an identifier. NDS-PROCU also uses machine learning module(s) (MLM(#1124)) to perform other analyzes such as predictive models for patient physiological parameter(s), outcomes, response(s) to treatment course(s), etc. can be applied. MA-D and NDS-AD can be stored in NDS memory units, which are generally efficient for receiving semi-structured MA-D, and include a data lake (#1130) which again supports feature speed, NDS availability, etc. do. NDS also provides on-demand functions, such as query functions and schema applications (#1132), where data from a data lake (#1130) or other data store (e.g., EDL or database) is retrieved and sorted into relational datasets, etc. ) may include. NDS-AD obtained through a query process, MLM, or other analytical process may be forwarded to ONDI or MA (#1126). This overview is intended to ensure that the system performs the various described functions of the system efficiently and effectively in a reliable manner and to distinguish the method/system of the present invention from other previously described methods/systems for processing medical device data. Some of the various steps are illustrated.

Figure 12

12 is a simplified illustration of the relationships between components of a special type of MA (multi-zone MA (MZMA) or combined MA (CMA)) that may be in a network with NDS (#1200), depending on the aspect. The boxes around the process/component represent elements included in the CMA or otherwise closely functionally related to it.

In the illustrated example, a patient (HSUB(#1202)) is referred to a MA that includes treatment component(s) (#1204) (e.g., blood pump, ECMO, etc.) that apply one or more medical treatments to the patient/HSUB. I am receiving treatment. Therapeutic application and other patient physiological information obtained from the sensor (#1206) or other information related to the operation of the therapeutic component/MA is typically transmitted via a direct data transmission line (#1208) or similar means of communication, e.g., a local wireless transmission channel; For example, it is relayed to the data system of the combined MA (CMA(#1214)) (aka MZMA) via a secure Bluetooth communication channel. The sensor (#1206) is placed on the patient, within the patient or both and, in addition to measuring the treatment components, is not directly connected to the control of the treatment modality of the MA, but also communicates with the CMA via a separate direct communication line (#1210). Physiological parameters of other communicating patients can also be measured. Combined MA (or MZMA) because CMA includes a combination of components primarily or exclusively dedicated to therapeutic component (Tx Comp) data management and functions, as well as other components dedicated to processing of non-Tx functions/data, e.g. is considered. These devices are also sometimes called multi-zone MA (MZMA), as described elsewhere, especially when different zones of the component are subject to different levels of network interaction, modifiability, regulation, etc.

Treatment component data will be relayed to the Treatment Component (TxComp) Processing/Control Unit (Tx COMP PROCU and Control (#1222)), which is part of the Treatment Component Data/Control Area/Component, which can be considered an “aspect” or part of the CMA. You can. Other components of the treatment component "zone" (part or "side") include (1) a memory unit (MA-MEMU1) (#1224) that stores the TxComp MA-D; (2) TxComp Control RELAYU (#1226), which relays information to the non-therapeutic component "side" or part of the CMA after being cleaned/screened/approved by (#1228)), and (2) NDS-PROCU (#1250) or CMA/ It may include a Tx component input unit/status unit (#1240) that receives non-therapeutic function (NTxF) "sides" of the MZMA and status information.

Non-therapeutic function (NTxF) components include, for example, a separate NTxF PROCU (#1230), a separate memory NTxF MEMU (#1232), a security unit NTxF SECURU (#1234) and a relay unit NTxF RELAYU (#1234). 1236), and an NTxF INPU (#1238), which is an input unit/receiver. In operation, the NTxF INPU (#1238) receives non-therapeutic control data via line (#1210) directly from the sensor (#1206) and passes this data to the NTxF PROCU (#1230). The NTxF PROCU (#1230) also receives TxComp data via Tx Comp SECURU (#1228) from the Tx Comp RELAYU (#1226), which limits the data that can be relayed from the Tx Comp side of the CMA. Unrestricted data flow through these steps/functions/components is illustrated by the arrow direction in the figure. The second security unit, TxF SECURU (#1234), can screen data transferred from NDS-PROCU (#1250) to NExT INPUT (#1238), for example, NTxF PROCU update/patch, etc. This direct connection between the NDS-PROCU and Tx Comp components may be limited to status data transfer only or similar NDS status signals (e.g., software update availability). By restricting data flow to Tx Comp components, the CMA/MZMA configuration prevents these components, which may participate in critical life support functions, from any type of interference relayed over the Internet, such as computer viruses, hacking, or other harmful/ Ensures protection/isolation from malicious code. Similarly, the NTxF RELAYU (#1236) is responsible for relaying both NTxF data as well as Tx Comp data to the NDS-PROCU (#1250), thereby controlling the Tx Comp component and NDS with respect to the MA to NDS outgoing data flow. Separate. CMA represents an independent aspect of the invention and an important aspect of the network of the invention. Devices adapted to include multiple components at different levels of network access, security, etc. help ensure that critical life support systems are protected from unauthorized access, tampering, etc., improving patient safety and trust in network/medical devices. .

Figure 13

Figure 13 provides an example of data (#1300) flow from NDS to and through a MA device/system similar to the MZMA/CMA device described in Figure 12. NDS (#1302) supports (1) status queries/requests (#1304), (2) machine learning module (MLM) treatment (TRx) control (C)-data (D) (MLM TRxC-D) (#1306) ; (3) diagnostic prediction (Diag. Predn.) data (#1308) generally derived from the application of NDS MLM(s); (4) System update (Sys. Upd.) data (#1310); and (5) invalid data (e.g., data corrupted during transmission/processing) (#1312). The CMA includes a first security unit (MA SECURU 1 (#1314)) that screens this data; The first MA operates in the non-therapeutic control mode of the CMA (MA PROCU-1 (NTxCC) (#1318), which blocks invalid data (#1312) from being relayed to the CMA component, but prevents the other four types of data from being relayed to the CMA component. Allows the MA PROCU-1 (#1318) to relay diagnostic predictive information to the display unit, alarm component, or both (not shown), but no longer transmits diagnostic predictive information (#1308). and limits the data flow to only three data collections, which are received by the second security unit/process, MA SECURU2 (#1322), and further blocks system update data (#1310), thereby preventing Internet relay messages. protects the MA PROCU-2 (which is part of the treatment control component - TxCC - of MZMA (#1326)) from modification through the MZMA (#1326), thus protecting the status information (#1304) and the operation of the treatment control component (#1306). Data specifically designed to be controlled is allowed to flow into MA-PROCU-2 (#1326), greatly improving the security of MA-PROCU-2 CMA/MZMA also detects physical access to components of the treatment control unit. Thus, it may further include a physical anti-tampering system (#1330) that can trigger an alarm, shutdown, or other steps/results. MA-PROCU-2 (#1326) may also include an NDS security unit, NDS SECURU (# It is possible to relay (#1334) specific data to the NDS (#1302) either directly (i.e., after screening) via (A) NTxCC (#1318), or (A) indirectly via NTxCC (#1318), the latter data flow path being You can add more security to TxCC operation by limiting direct outflow communication between your network and the Internet.

Figure 14

14 illustrates another example configuration (#1400) of components of a composite medical device (CMA/MZMA). The therapy (Tx) component (TXcomp(#1402)) may control the operation of a medical device, such as a heart pump, as described/illustrated elsewhere. TXcomp (#1402) is a connectivity module (#1408) that records and relays patient condition monitoring functions to the NDS via an Internet connection (#1448), for example, an Ethernet connection (#1422) or a Wi-Fi connection (#1424). ) communicate with. Boxes drawn around various elements indicate that these elements are typically included in, operate on, or are otherwise closely related to this non-Tx component (connection module). Specifically, data communication between the secure TXcomp component (#1402) and the connectivity module (#1408) may include, for example, (1) a video image associated with the MA, received by a field programmable gate array (FPGA (#1410)); (2) a video communication line that transmits data to the connection module (Video Graphics Array (VGA) relayed over USB (#1404)) and (2) other data is relayed over a two-way twisted-pair USB (#1406) and USB hub (#1414). ) can relay data through a second data communication line received by. FPGA (#1410) is a component of the processing function of the connection module and MA, and the FPGA (#1410) performs analysis functions on incoming data (e.g. tagging, sorting, validation, cleaning, local alarm monitoring, etc.) can do. In general, the FPGA (#1410) can be dynamically programmed/reprogrammed using data paths to match the specific workload of the combined device (CMA) function(s). Communication over both channels is usually substantially or entirely one-way, with data only flowing from Tx Comp (#1402) to the connection module (#1408), for example. The FGPA (#1410) also relays data to a USB hub (#1414), which is then sent to the System on Module (SOM) (#1418) for relay to the NDS (not shown in this figure). It is transmitted to other users who have direct access to the data of the relevant MA. Data can be retrieved locally from a USB hub (#1414) via a USB port (#1416). Video and other data are all relayed to the connectivity module memory (#1408), which can be retrieved via an application that relays the data to a USB hub (#1414) for local device access, or via the Internet (#1448) via NDS or It can be relayed to the System on Module (SOM(#1418)) for transmission to other users. SOM (#1418) can receive and transmit data to the Internet (#1448) and can be considered to form both an input/output unit for MZMA. However, microcontrollers and firewall components (#1412) generally screen incoming data and restrict data passing in both directions between the USB hub (#1414) and the SOM (#1418), but especially incoming messages (shown as dotted lines). ) (usually through screening for special packets that contain the information needed to pass through the firewall component). Inter-component communication (between parts/components of different zones/parts of the MZMA/CMA) is managed through the RS232 data processing component (#1420), which forms part of the SOM. Components of the system, as described elsewhere, connect locally to module memory for relaying information to local users (e.g., via a USB port (#1416)) or to the NDS via the Internet (#1448). (#1446) is accessible. The MA/system, including the coupling device system illustrated in this figure (#1400), provides coupling device characteristics/functions described elsewhere with respect to other aspects and maintains a high level of security for the therapeutic components, thereby protecting the patient. Ensures safety and compliance with applicable regulatory requirements.

Any of the various systems described herein can be modified by skilled artisans. For example, RS232 communication may be replaced by any other suitable inter-component communication standard/equipment; The FGPA may be replaced or enhanced/combined with other integrated/hardware circuits or processor components or may be combined with various application specific integrated circuits (ASICs) or processors (not shown); USB hubs and ports can be replaced with other local communication components, hubs and ports; Or it may be any combination thereof.

The illustrated example components of MZMA reflect how the various principles of the invention, particularly in relation to MZMA/CMA, can be implemented by a person of ordinary skill in the art using known/available components such as USB ports, FPGAs and microcontrollers. .

Figure 15

Figure 15 provides another illustration of how the mechanical and data system components of a combined device (MZMA/CMA) can work together in a real application. Specifically, the example network connection (#1500) shown includes a medical device (MA (#1502)) and an NDS (labeled NDS PROCU (#1510)). The combined device component (#1502) is a therapeutic component, MA Zone 1 (#1504), i.e. capable of controlling life support functions and containing/providing local display of data (now displayed), and diagnostics/patient status. MA Zone 2 (#1506), which includes other elements configured/adapted to receive information, perform analytical functions, and perform other functions, including relaying information to the Internet and receiving information from the Internet through wireless transmitter/receiver components. It consists of The MA Zone 1 Security Unit (SECURU(#1514)) exists and utilizes this to transfer data from MA Zone 2 (#1506) to MA Zone 1 (#1504) in certain restricted forms that meet format or content requirements. It can be limited to communication only. MA Zone 2 (#1506) blocks any transmitted data that does not meet pre-programmed data standards (e.g., using a firewall to indicate that the data originates from an NDS or other approved data relay device). ) may be associated with the MA Zone 2 Security Unit (SECURU(#1512)) which also screens data at a less restrictive level. Data uploaded from MA Zone 2 (#1506) may also be screened by the NDS Security Unit (NDS SECURU (#1508)) before reaching NDS, which may, for example, prevent incoming data from computer viruses, unauthorized data requests, etc. Alternatively, it may include a firewall component/system to prevent other malicious/unauthorized code from being included.

Figure 16

16 controls updates of software/operating system element(s) of non-therapeutic components (e.g., connectivity module components) of a combination device (CMA/MZMA), protects patient safety, supports compliance with regulatory requirements (RR), or both. Illustrates an example two-step security protocol (#1602) for:

MA Zone 2 (#1602) is responsible for functions other than the life-sustaining MA control functions handled by the relevant Tx Comp (n.s.) when in operation, such as patient physiological data collection, NDS data, as described elsewhere. It performs upload and download, local processing, and memory storage functions. Occasionally system updates to the operating system/software of MA Zone 2 (#1602) may be required/desired, but it may be important to keep the system in a secure state for patient safety and RR compliance, patient safety, confidentiality, etc. In this aspect, the NDS PROCU (#1610) may relay an update enable signal (#1613) to the MA when the NDS determines (#1612) that a software update is recommended/required. The update available signal (UAS) (#1613), like other incoming data/messages, is screened by the MA Zone 2 Security Unit (#1620) and then sent to the MA Zone 2 component after the message is determined to be authorized. Allowed to be received by (#1602). UAS (#1613) may include version information, description of changes, etc., as well as information about the nature of the update (importance, affected features, expected update time, and system impact, etc.).

Authorized users of the MA may decide (#1614) whether system (e.g., OS) updates are approved/required. For example, if a device is currently being used by a patient, if the device is part of an investigational program, if the local administrator/user(s) would like to evaluate an update first; Or you may not need an update for any other reason. If an update is approved/required (#1614), the user may have the MA relay the update request (#1618) to the NDS PROCU (#1610) via MA Zone 2 (#1602). In aspects, the NDS PROCU (#1610) attempts to transmit the software update (#1625) to MA Zone 2 only if such request is received or if a confirmation request is received in response to a system availability signal. System update data may be screened by MA Area 2 (SECURU (#1620)). If SECURU (#1620) determines (#1630) that the component(s) of the update data sufficiently match expected specifications according to pre-programmed standards, the update is permitted to update the MA Zone 2 software (#1634). If an update is not requested (#1614), MA Zone 2 or NDS may trigger one or more update alerts (#1616) (e.g., a special display, email, or text message to the user/administrator, etc.). Alarms may also or alternatively be registered with the device, other network devices, etc., if a device update is delayed beyond the period during which the update is available, particularly if the update is deemed critical to device security, device effectiveness, patient safety, etc.

Figure 17

17 is a network comprising several medical devices (MAs) illustrating MAs communicating with NDSs in various states of operation, to illustrate how the system of the present invention processes information from MAs in these different states of operation. 1700) shows an exemplary portion. Specifically, the first illustrated MA is in the first medical treatment (TRx1) state (#1702), the second MA is in the second medical treatment state (TRx2) (#1704), and relevant information about both states (e.g. For example, various patient physiological measurements or device performance measurements, various device controls, e.g., various SAMD/CDS protocols or combinations thereof (ACT)) are relayed to the NDS processor (NDS-PROCU(#1712)) and thereby It is received from The third MA is shown online (#1716). The 4th MA is simultaneously involved in system/network testing, such as scalability/scaling testing (#1706) and NDS-PROCU (#1712), as well as relaying and receiving information related to these tests. The 6th MA also participates in local device testing (#1718). The 5th MA is for clinical trials (#1708), e.g., testing new applications for MA types, patient types, disease types, or combinations thereof, and NDS-PROCU (#1712) specific to the performance of clinical trials. Participates in receiving information simultaneously. The 7th MA participates in the research program, or users of the research program can access data from a variety of other MAs through the research group/platform ONDI (#1710). For example, research platform users may participate in MA testing, testing NDS implementation functionality (e.g., new machine language modules) or any combination thereof, and relaying and receiving data related to NDS or ONDI. Research component(s) (#1710) may also participate in monitoring the performance of other aspects of the network, such as the performance of one or more of the other MAs described herein.

The NDS processing function (NDS-PROCU(#1712)) provides a component to simultaneously identify these different data inputs and outputs (e.g., to identify various MAs based on status information relayed from each MA and recognizable by the NDS-PROCU). processor to identify the state of the unit) and components to ensure that the NDS-AD is routed appropriately to these MAs simultaneously. In many aspects, the number of device states, device types, locations, and devices specifically identified and simultaneously communicated by the NDS-PROCU may be greater than or equal to 100, greater than 250, greater than 500, greater than 1,000, or greater. 2,500+, ~5,000+, ~10,000+, ~25,000+ or even more (e.g., ~100,000+ unique states). Accordingly, systems hosting these networks typically employ the use of functional data units that provide secure and reliable identification of specific devices, status, and other information (e.g., entity information, location information, device type, etc.). will include In aspects, some information may include streaming/real-time data transfers to the NDS, other data transfers to the NDS, and data transfers from the NDS to a large group of MAs, as well as other network/NDS components or other interfaces accessing the NDS, the MA, or both. To reduce the incoming data load associated with relaying data to and receiving data from them, they are relayed or revalidated only periodically, or are maintained in NDS memory or ACT. NDS-PROCU (#1712) also simultaneously performs other analysis and control functions, such as evaluating MA performance under one or more operating states, as discussed elsewhere, when one or more threshold indicator(s) are met or If triggered, more types of alerts or alarms (#1714), known user interfaces (e.g. mobile devices, email accounts, etc.), MA Manager, MA display/output (e.g. audio output) to one, two or more user groups/entities (e.g. clinical monitoring, research, administrators or HCPs). Data from devices participating in system/network testing, device testing, etc. are analyzed in relation to these network operational level activities, but such data is specifically separated from data related to human-facing applications to ensure the integrity of the targeted application data.

The ability of the NDS to simultaneously receive data from MAs in these states, while processing such data and relaying the NDS-AD to these users, allows the NDS to provide a substantial improvement over a variety of medical device management systems known or described in the art. functionality, such as the ability to receive treatment from all actual treatment, clinical trial, and research components simultaneously, and to use such data in the development, improvement, or operation of MLMs used in the SAMD protocol, the CDS protocol, or both. At the same time, it facilitates 24/7 operation of NDS by allowing NDS/network testing (e.g. scalability testing), device testing, etc. without affecting the stream.

Figure 18

Figure 18 provides a brief overview of the components of the network (#1800) of the invention comprising different user groups, each presented in a different special data display according to the representation/schema generated by the NDS. Receive data (NDS-AD). In the illustrated example, the NDS processor (NDS-PROCU (#1804)) receives real-time/streaming data and other data from MAs in the MA network(s) (#1802) and applies analysis processes to these incoming MA-Ds. thus developing NDS-AD. The filtering/directing unit/engine (FILTERU(#1806)) evaluates the NDS-AD, determines which recipients and recipient classes (user groups) will receive the NDS-AD, and special Sends data structured to populate displays used by different user groups of users according to their schema/representation. Specifically, the healthcare provider (HCP (#1814)) receives the HCP display from the HCP Interface/Device Display Unit (#1816), MA-specific/patient-specific data, e.g., treatment recommendations, relevant information for investigation. Can include short-term actual and predicted physiological parameters (e.g., short-term actual and predicted heart rate generated by MLM processed by NDS PROCU), along with other CDSS or SAMD application outputs/functions such as points, possible diagnoses, etc. there is. On the other hand, commercial group users (#1820) simultaneously receive NDS-AD in a commercial group display configuration (#1822), which typically includes NDS processing units and also external commercial database(s), e.g. CRM(s). (not shown) retrieves data from both (directly or indirectly; in the latter case, such data is first received and processed by the NDS before being relayed to the commercial group display/device). Commercial group data displayed on a commercial display unit (COM DISPU (#1822)) typically does not include PHI and typically includes aggregated device data rather than patient-specific/device-specific data. Alternatively, still the study group user (#1830) simultaneously receives different data displayed on the interface/device via the study group display unit(s) (study DISPU (#1832)), which can also be used for various conditions, e.g. It may include information about several different MAs operating under the control, patients diagnosed/treated for various conditions, data flows of devices, systems, or networks, or a combination thereof. The data presented in each of these groups, derived from simultaneously processed NDS-AD, delivered and displayed simultaneously, is therefore very different in content. For example, research users may receive data on unauthorized use of MA that would be withheld from HCP display due to RR. Similarly, the commercial user display will not receive sensitive patient or IE information that may be displayed on the HCP display. This concept can be applied to additional components, users, etc., reflecting the improved and broader capabilities of NDS to simultaneously process input and deliver output to various components. In aspects, there is some degree of data overlap that is analyzed by the NDS, coming from two or more such classes, being passed on to display(s) of two or more classes, or both. The flexibility/comprehensiveness of this system further distinguishes the system of the present invention from previously described medical device data management systems.

Figure 19

Figure 19 is a simple schematic diagram showing data grouping of one or more NDSs containing overlapping but different NDS/network components (#1900). The illustrated network includes a first country defined MA network/group (#1916) where the MA is located in one country (e.g., the United States), and an NDS or NDS component that includes a shared data core (#1902); , which covers at least some basic/fundamental functions of NDS, such as processes for handling real-time/streaming data (e.g., messaging queues, prioritization, and NDS scaling components), data cleansing processes, device identification, and data connectivity. Processes, analytical processes (e.g. MLM), etc. However, certain processes performed by the NDS, such as device control functions related to subject treatment, are subject to specific country-specific regulatory classifications/RRs, e.g., SAMD (#1910) and SAMD2 (#1914) and CDS/CDSS (#1912). is subject to. The second MA network (#1906) of the MA in country 2 (e.g., Germany) also includes or supports shared core functionality/components (#1902) that exist in and/or are utilized by the MA in country 1. Pass the data to a local NDS or an international NDS with access, but also apply a second country-specific SAMD (here SAMD3 (#1920)), for example a SAMD approved by the regulatory authority of the second country. Shaded boxes are included around elements of each MA network to clarify at least partial separation of some components of these networks. Finally, a third country (e.g., Japan) includes a third MA network (#1918), which also includes or has access to the data sharing core functionality (#1902) and country-specific functionality; For example, passing it to NDS or NDS components including SAMD4 (#1930) and CDS (#1932). The various SAMDs in Country 1 (SAMD 1 (#1910) and 2 (#1914)), SAMD3 (#1920) in Country 2, and SAMD4 (#1930) in Country 3 have different regulatory statuses and different regulatory requirements. The shared core (#1902) is a shared core (#1902) that covers many, most, generally all, or substantially all functional components of an NDS, although they may have different data functions and thus may have different data functions or apply these functions to different MA data. This means that it is shared or repeated between these different countries. The principles illustrated in this figure may be applied to more complex systems involving more countries, regions, regulatory requirements, devices, etc., as described in this disclosure. This example illustrates how the network of the present invention can be deployed effectively across boundaries to share certain functions while also respecting local RRs in providing output functions.

Figure 20

Figure 20 illustrates data flow over a network (#2000) and data processing over time according to time-dependent data processing rules, reflecting certain aspects of the present invention. The illustrated process begins (#2002) by collecting data from the MA network (#2004) over time. For example, at Time 1 (#2005), which is one minute and 1 second (1:01) after start, live/streaming data is sent (#2006) to NDS (#2012), for the remainder of the Time 1 cycle. Make sure it continues to be transmitted. At time 2 (#2007), here 8 seconds later, 1 minute and 9 seconds (1:09), a new data cycle begins with the transfer of new cycle data (#2008) to the NDS (#2012). More than 8 seconds later, at time 3 (#2009), the third exemplary data cycle begins (1:17) with the transfer (#2010) of another set/collection/unit of RT/streaming data to NDS (#2012). )do. Collecting data in a fixed data cycle during the operation of a MA:NDS network connection, sometimes, most of the time, generally all the time, or always, is an aspect of the invention applicable to any of the other aspects described herein. The use of acquisition cycles can be used in MA-D analysis, for example, in that certain types of data can be expected to be repeated (at least in format) in each cycle or number of cycles according to pre-programmed rules, for example. It's helpful. For example, the MA can be configured to deliver a set amount of physiological sensor data, device performance data, device health data, etc. within preprogrammed data cycles, which can then be used as an analysis tool when selecting data for analysis by the NDS. It is used. The systems/methods of the present invention may also include collection of large data sets from smaller cycles or other data collection over time, events, etc.

For example, such "cycle data" (data delivered in the transmission cycle expected for a series of streaming data), once received, can be used by various data processing step(s)/engine(s), e.g., data cleansing ( For example, it may be subject to a data cleansing unit/engine (CLEANU(#2014)). The collection of cycle data may be evaluated for data validity (#2016) according to data validation rules, e.g. , in terms of data content and integrity, if sufficient valid data exist, for example for the collection of large data cycles (e.g. data are considered sufficient (#2018)), then these data, or these data and other cycle data; The collection may be or be maintained in temporary storage for combining with other data collections to form large data collections. For example, temporarily stored cycle data can be stored to enable the operation of machine learning modules (MLM(#2022)). Risk may be assessed (#2020) for whether a minimal amount of data (e.g. measured by the minimum period of continuous data collection) is present. In the illustrated embodiment, cycle data collected over a period of approximately 5 minutes (e.g. For example, containing approximately 37-38 cycles worth of RT/streaming data) is collected and maintained in temporary storage/memory (#2020) until a minimum period of time has elapsed or until data is collected (as illustrated here: This occurs 6 minutes and 1 second (6:01) from the start of data collection (in #2019). This second large-scale data collection is processed, for example, through the application of a machine learning module (MLM (#2022)). An NDS-AD can be generated, which is relayed back to the devices in the MA network (#2004), however, if the data is invalid or insufficient to form a second collection/aggregation (#2016, #2018). , the collection of data that is added to the growing collection held in temporary storage may be stopped (#2030), and the collection process for large data in small collection/data cycles starts again from the beginning. Assessment of data validity, e.g. consistency/connection with other data, completeness of data (e.g. continuity across time series, expected schema, etc.), etc. (e.g. determined by regression analysis, probabilistic matching algorithms, etc.) It can be based on any number of factors including. Stopping data collection for a minimum collection time, rather than running the process over the entire period before making an assessment, will ultimately result in NDS time being insufficient to collect enough data to meet processing capability standards, e.g. MLM (#2022). Since it is not wasted, more evaluations can be made. As mentioned, the exact times herein are exemplary, and this process may be performed in more or less time, data units, etc., and may be performed at a higher level of data collection (e.g., forming a second, larger collection). 1 number of vowels and several second vowels forming a third vowel, etc.).

Figure 21

21 is another overview of a network component (#2100) that includes multiple user groups, NDS and MA, and highlights the ability of these NDS to provide various alerts/alarms to different users in different groups according to aspects. provides.

The illustrated first healthcare provider (HCP 1 (#2102)) associated with MA1 (#2114) may access the MA ( For example, in the case of the first alarm (#2120), setting control for the user sets alarm/warning settings (#2162), and these settings are relayed to NDS (#2144). NDS can also or alternatively apply processor level alarm(s)/warning(s) based on user group, for example to HCP1 (#2118), setting, alarm or both to MA (#2114) or other relayed to user device(s)/interface(s) or even to devices or interfaces associated with other network user(s). HCP1 responses to warning(s)/alarm(s) (#2112) can direct the behavior of device components, modify NDS behavior, or both; HCP response monitoring functions (#2130); It may also be monitored by various user groups, for example through a research unit (#2106), a clinical support group (#2108), an administrator (#2152), or a combination of some or all of these. Therefore, both local and network configured warnings/alarms can be applied to HCP1 and HCP1 responses can be monitored. Response monitoring may provide information regarding, for example, the validity of alarms/alerts relayed to HCP1, the performance of HCP1, or both. HCP2 (#2104) associated with MA2 (#2126) similarly sets alarm/alert settings (#2128), and NDS also sends HCP2-related alarms to MA2 (#2126) when certain thresholds are met or exceeded. (#2122) (e.g., physiological parameters detected by sensors associated with the MA (not shown), e.g., blood flow, heart rate, oxygen level, organ function, etc.). HCP2 responses (#2124) to alarms/alerts such as HCP1 can also be implemented by the HCP monitoring function (#2130) (e.g. as described for HCP1) to various user groups, e.g. clinical support, research teams. , this information relayed to the administrator or any combination thereof may be monitored. Readers may be aware that when operating a large network, there are 10 or more, 50 or more, 100 or more, 150 or more, 200 or more, 250 or more, 500 or more, or ~1000 or more HCPs and MAs, each using the system/MA of the present invention. You will find that you may be on a network that has some level of custom alarm settings that reflect the performance level of the network. The reader may also generally use the concepts/principles described and illustrated above to monitor responses to alarms, analyze these responses, and change one or more aspects of NDS operation, MA operation, or both based on these responses and analysis. It will be understood that (eg, changing alarm states/characteristics) is a general aspect of the invention that can be combined with any other aspect described herein.

Research team users (#2106) similarly provide local alarm/alert settings (#2138) to the MA (#2136), and the NDS also provides research team NDS level alarms/warnings that are displayed on the MA, other user devices/interfaces, or both. Set the settings (#2140). Research team alarms may differ significantly from HCP alarms. For example, HCP alarms may be limited to a specific set of alarm/alert settings that have proven effective in clinical practice, whereas research team users may be encouraged to research new alarm/alert settings for new devices, conditions, alarm/alert media, etc. You can participate. Research group test responses (#2132) can be monitored and analyzed in the process of developing enhanced alarm/alert settings, protocols, etc. that can later be deployed to HCP devices/HCPs.

Clinical Support Team/Group (#2108) may also set Clinical Support Alarms at the user level (#2134), while NDS may also or alternatively have Clinical Support Team/Group Alarms (#2142), but generally Clinical support receives output and sets alarms through the web interface (#2146) or other devices other than the MA level. NDS (#2144) relays MA-specific alarms/alerts to some user groups, but not to other user groups, such as clinical support.

Commercial group users/devices (#2110) may also receive alarms/alerts from time to time, but for reasons of regulatory requirements, these alarms/alerts typically do not contain PHI, nor are these users receiving information from subgroups of the MA. There may be, for example, clinical support team(s). Similar to clinical support, user group users can set up local alarm preferences (#2148) and set alarms at the NDS level (#2156). Additionally, as with clinical support, commercial group users do not typically access alarms/alerts at the MA level, but typically enter alarm settings via the web interface (#2150), and may enter alarm settings via a variety of user devices (e.g. mobile phones, etc.). ) to receive alarms/warnings.

Administrator group users (#2152), which may include experts who perform NDS functions, such as monitoring/maintaining the NDS or participating in supervised machine learning for example, can likewise typically be contacted individually via a web portal/interface (#2160). You can set alarms/warnings (#2154) and receive administrator class alarms/warnings set to NDS level (#2158).

The Processor Unit (PROCU) function (#2161) with NDS level alarms/alerts described above may also include NDS level alarm/alert settings (#2162), which may, for example, The type or content of, or displayed data (#2164); Set timing, trigger, or repetition (#2166) (e.g. with ~3, ~4, or ~5 or more repetitions); Communication channel settings (#2168) (e.g., whether alarms/alerts are relayed via e.g. email, text message, device notification, automatic or manual phone call, login notification, or combination(s) thereof); Target device/interface settings (#2170) (e.g. mobile phone, workstation, etc. where alarms will be displayed/registered); And alarm/alert recipient group settings (#2172) may be included to receive, recommend, or be notified of user or NDS level alarms for specific individuals, groups, devices, areas, or entities. The processor and NDS functionality includes various sub-networks, MA This includes the ability to manage multiple alarm/alert settings, users, and more across complex networks. The highly customized alarm system of the network of the present invention reflects another distinguishing feature of the sophisticated/complex system compared to previously described medical device data management systems.

Figure 22

22 provides a brief overview of a portion of a network #2200 including multiple machine learning modules (MLMs) according to another aspect of the present invention. Complex(s)/group(s) of the first type of MA (MA-1 complex (#2210)) provides real-time/streaming and other data, e.g. MA-CD, to NDS, and among these MA-Ds At least some of it is processed by MLM(s) trained to analyze MA1 MLM(s) (#2212), which is MA-1 type data. Similarly, a second type of MA complex(s) (MA-2 complex (#2218)) delivers real-time/streaming or other MA-D to the network, some of which data is MA-2 type data: MA2 MLM (#2220) It is operated by MLM(s) focused on To reconcile these data, especially when a patient involves both MA-1 and MA-2 type devices, the system/NDS includes one or more master machine learning module(s) (#2230), which Receives raw data from the star MLM(s) or both, and analyzes this data to arrive at a combined overview and analysis of the data. Master(MLM)(s) may include supervised learning component(s), or NDS Administrator(s) (#2260), Research Unit User(s) (#2270), or both proposed Master(MLM) output/model and MLM coordination; Through a supervised learning process (#2250), which can receive the base, etc. and, if necessary, provide feedback/corrections or other oversight to the Primary MLM(s), Master MLM(s), or other component(s) of the system/network. It can be trained. The master MLM(s) may override one or more MA-specific data streams, combine various MA data streams to present a different diagnosis than that obtained from the device-specific MLM(s), or use conclusions from one or more MA-specific data streams. You can check it. The MLM(s) may act or operate as a guidance component to various SAMD modules that control the MA, provide treatment direction to HCPs through the MA, provide treatment direction specific to MA operations, or a combination thereof. (For example, the first SAMD component, SAMD (#2240), may provide medical device device applications to the device(s) of the MA-1 complex (#2210), and the second SAMD component, SAMD 2 (#2246) ) may provide medical device applications to the device(s) of the MA-2 complex (#2218). These principles of using the Master Machine Learning module provide additional types of MA; MA operated under conditions of specific patient, entity or regulatory requirements; Or it can be extended to data generated from a combination of these (data that can optionally be first analyzed by a more specific/low level MLM as illustrated in this figure). The master MLM(s) may, in aspects, operate a conditional level, wherein such MLM(s) may determine, for example, one or more MA-specific MLM(s) or MA-D's data to reach a pre-programmed threshold. Triggered by meeting or exceeding triggering review/intervention of the master MLM(s). A master MLM can be created or improved through supervised learning methods, as described elsewhere. Including the Master MLM component in the NDS will provide DoS with better patient outcomes, especially when patients are treated with multiple MAs, as is the case for patients with serious health conditions (e.g., multiple system disorders or multiple system conditions). You can. The master MLM may be trained based on outcome data related to various MAs and other inputs provided to the NDS, for example, treatment applications, sensor data, etc. Machine learning methods and related applications/principles and methods for clinical diagnosis are known in the art (e.g. US20160012349, WO2021012225, US20210098130, WO2020047171, US20200357515, WO2021044431, US20200402663, US20200111570, WO2018220565, US20210202094, US10861606, US11037070, US20210065898, US20190371464, US2019034 No. 8178, US20210090738, WO2019246086 as well as other references cited herein. see literature). These methods/principles and systems/components may be combined or adapted from the aspects, principles and methods described in connection with this figure or provided in any other part of this disclosure. The system/network of the present invention provides a more robust data set for better training of medical diagnosis/therapy-related machine learning applications than was previously possible based on previously described medical data management systems, thereby enabling many ML systems/ The performance of the method can be improved.

Figure 23

FIG. 23 illustrates data flow into, within, and output from the Streaming Data Processor (SDP/SDE) component of an example System/NDS, and optional processing and analysis of streaming data prior to collection into NDS memory.

Data (MA-D) is transmitted by MA-1 (#2301) which transmits RT/S-MA-D (#2303) and RT/S-MA-D and L-STR-MA-D/MA-CD (# 2307) (e.g., after an offline event) from several MAs (#2302), including MA-2 (#2305), which transmits a data stream containing both. We focus here on a few MAs for simplicity and brevity, but in most cases there are at least 10, 50, 100, 200, 500, or 1000 different MAs of one or more types. Transmit data containing MA-D together with and simultaneously with input(s) such as OND.

Most, usually all or all MA-Ds transmitted from MA (#2302), including MA-1, MA-2 (#2303 and #2305) respectively, have a fixed/known counterpart to speed up processing and collection. May be in an unstructured format (e.g. most, generally all or all MA-Ds may be relayed/presented/embedded in JSON file formatting). The Streaming Data Processor (“SDP”) (#2320) includes a Streaming Data (“SD”) receiver module/component (#2321) that can be considered a type of input unit (or part of an input unit). Boxes around these and other components in the drawing indicate that these components/functions are either part of the SDP or are closely related to the SDP. SDP can simultaneously receive multiple data streams from numerous MAs networked with the NDS. SDP receiver (#2321) can have (e.g., 100+, 200+, 500+, 1000+, 2500+, 5000+, 10,000+, 25,000+, or 50,000+ receivers transmitting data simultaneously. You can effectively receive and register multiple streams at the same time (from more than one stream client). The SDP receiver may share resources with, or be considered an aspect of, other elements of the SDP memory, such as stream registry file(s). Communications to SDP may also include or utilize a variety of network interfaces known in the art.

Effective stream processing by SDP may be achieved by any suitable means, examples of which are described elsewhere. For example, an SDP can perform parallel reception on received data streams, typically performing a limited set of operations (e.g., kernel functions) on most, usually all, or all elements of the stream. . Most, generally all, substantially all or all of the processing performed in the SDP is performed in the SDP hardware and software, and is performed on the main NDS memory (e.g., data lake/EDL primary NDS-MEMU (#2360)). There is little to no referencing/interaction. In aspects, most, and generally all, all streaming processor functions are performed uniformly on elements of a stream, at least an RT/S-MA-D stream (i.e., such data stream undergoes uniform stream processing/uniform streaming). received). In aspects, a known compiler component may be used to automate and optimize in-memory/on-chip processing of stream data in an SDP unit (where the SDP memory is at least functionally separate from the primary memory of the NDS). At the hardware level, SDP (#2320) includes, for example, multiple memory bus systems (e.g., crossbar switches) (e.g., one or more crossbar switches of 512 MB or more) and multiple processor/cluster processing units, and physical or In terms of data rule separation, a memory that is distinct from the primary system memory (eg, EDL) may be installed. In addition to RT/S-MA-D and L-STR-MA-D/MA-CD, the SDP receiver (#2321) can also receive unstructured data (e.g. from email or text message input(n.s)). there is. In aspects, most, and generally all or all, data inputs from other systems (e.g., networked third-party CRMs) are processed separately from inputs to the SDP.

The component(s)/engine(s) (e.g. kernel(s)) may be a component of the SDP, such as for example identifying the MA-CD and transmitting it to the MA-CD immediate analyzer (which may also may be considered a "cache processor") and analyzes the characteristics of the incoming data stream, including determining whether conditions are necessary to trigger the action of an alarm(s) on the MA-CD and It can be characterized/configured with an SD Handler (#2322) that controls (at this point this component can also be considered an event processor). In aspects, the MA-CD immediate handler may process a limited amount of data for this component of the SDP to determine whether there is immediate data that requires immediate action in terms of alerts, MA control, etc. (i.e., initial analysis discussed elsewhere). MA-CD and RT-D-MA-D harmonization/reconstruction may or may not be performed. The SD handler can also direct streaming data to additional SDP memory, such as an SD buffer (e.g. #2323), or to a queue to be processed according to processing/prioritization rules based on component availability, stream load, etc. . In aspects, a known software system (e.g., Kafka, Apache Flink, etc.) for receiving and processing a suitable data stream may be considered a suitable component of the SDP receiver (#2321) and handler (#2322) elsewhere. discussed. The SDP buffer (#2323) may consist of a registry file/file system, for example, stream registry file(s) of the type known in the art, and additional local SDP memory.

SDP memory streaming data ready for analysis is stored on RT/S-MA-D (e.g. when providing treatment, controlling displays, e.g. performing CDSS functions, etc.) on network devices based on SDP processing/analysis. Alarm triggers under the control of the SDP controller (#2327), which includes the engine(s) for controlling the SDP analyzer unit/function ( #2325). The SDP analysis process is typically limited to only certain data elements (e.g. device data, critical sensor data, etc.) and excludes many other data elements stored in the primary NDS memory (#2360) (e.g. Data about users are not analyzed at this level of processing). RT/S-MA-D and MA-CD are then transmitted from SDP to other component(s) of NDS either later or by output (#2328). In this aspect, the SDP handler can be viewed as an agent that transforms streams coming into the SDP into outgoing streams/other outputs (e.g., local output registry files).

After output from the SDP, other components of the NDS memory unit perform data collection functions (#2330), typically after data cleansing, harmonization, or both, as described elsewhere herein, to a primary network, such as a data lake or EDL. Save data to NDS memory (#2360). This component of SDP may also be considered part of the NDS Input Unit (NDS-INPU). After DL/EDL collection, the primary NDS processor (n.s) performs automatic, on-demand, or conditionally automated NDS-MEMU analysis functions (#2340) (e.g., as described elsewhere herein) on data stored in the DL/EDL. machine learning functions) and on-demand functions such as data query processes (#2350). Collection functions (#2330) applied during collection may include, among others, application of metadata to unstructured data, and separation of incoming data of various formats and contents into EDL management areas. On-demand queries and automated query processes that include only EDL data received in an unstructured manner, or that include both unstructured and semi-structured data, may differ from those applied to semi-structured data (for example, the former may be based on keyword searches). and the latter focuses on attribute/value pairs). Both types of query functions can contain two types of queries for these different data groups, resulting in different NDS-ADs. The EDL data recognized/used by these query functions often includes data that has not been analyzed by the SDP, such as non-critical sensor data, non-critical device performance data, commercial user relevance, etc.

By separating resource-intensive analysis processes, such as the ML process and the query process, from the immediate processes performed in the SDP, the exemplary NDS of the present invention provides real-time or near-real-time performance despite the significant amount of incoming streaming data received and processed by the NDS. It can operate more frequently in this state. The use of efficient primary memory such as EDL further ensures that secondary processes such as the automatic NDS-MEMU analysis process can also be performed within minutes from NDS reception of streaming data.

Figure 24

Figure 24 shows another diagram of a portion of an exemplary system/NDS (#2400) of the present invention. A medical device (MA) (#2403), which may include one or more MZMAs (not shown), a single component MA, or both, relays data to and receives data from the NDS. For simplicity, only a few MAs are shown in this diagram, but a network may contain 50, 100, or 1000 MAs, all of which are operational and capable of simultaneously relaying data to or receiving data from the NDS. There are various types, statuses, locations, affiliations, etc. (not shown).

Data flow to and from one or more of the MAs (#2403) may be controlled by a device security system or firewall (#2405). One or more MAs may also be subject to other anti-tampering protections (not shown), as discussed elsewhere herein. In operation, each MA rapidly relays data (e.g., in streaming digital alphanumeric format, image format, or both) to the NDS (NDS/MAC-DMS) (e.g., ~5-15 per second (1)). (2) digital alphanumeric messages (e.g., ~7-12 messages per second, e.g., 8 messages per second) or (2) at a rate of 1 image every 10-30 seconds (e.g., every ~20 seconds). If the MA is operational and has a secure and reliable network connection with the NDS/MAC-DMS, these communications are at least substantially continuous. Most/all of these communications are typically relayed over secure Internet communications.

Incoming MA data is received by the Internet of Things (IoT) gateway component (#2406) of NDS (NDS/MAC-DMS), which may serve as or include a Streaming Data Processor (SDP), as described elsewhere herein. It may or may not be considered a component of an input unit as described. The gateway (#2406) can broadcast/relay the digital message as a data stream (#2409) to the inbound message event hub (#2410). Simultaneously or together, gateway #2406 may relay messages to subscribers (e.g., other engine(s), connected database(s)/system(s) or ONDI). For example, as shown, gateway #2406 also relays image data (#2407) to an OCR processing module (OCR PROC. (#2408)) that converts the OCR readable elements of the image data into alphanumeric data. do.

The Inbound Message Event Hub (#2410), which also represents elements/functions of SDP, can route and optionally relay data, including MA data, to subscribers, and can handle any or all aspects of collection into NDS (NDS) memory. there is. In the latter sense, an inbound message event hub (#2410) collects inbound message data, typically on a time or conditional relay basis, through one of several concurrent output streams (#2412), selectively processes it, and distributes it to the NDS data lake (#2412). DL)/Enhanced DL (EDL) (#2440). Datasets containing MA-D in these inbound output streams (#2412) typically consist generally, essentially, or entirely of MA-D (i.e., are not significantly modified and do not contain analysis data). The gateway (#2406) or message hub (#2410) can be used for 1-10 minutes, 2-8 minutes, 3-6 minutes, 3-7 minutes, 2-6 minutes, or 4-6 minutes (e.g., about 5 minutes). It is possible to collect data at intervals (minutes) and then repeatedly relay this collected data to the DL/EDL in continuous/repeated batches/collections/units. The Inbound Message and Event Hub (#2140) will also include the ability to compress data before ingestion, typically in DL/EDL (e.g., in AVRO format, known in the art). The inbound message and event hub (#2410) can also relay messages or pre-collected analytics data, commands, etc. to one or more other subscribers (#2411). For example, as illustrated, an inbound message event hub (#2410) simultaneously relays message data to applied research unit users/systems/devices (#2412) and various other MAs (#2413) on the network (e.g. For example, sending device command commands, device display commands, etc.). The inbound message event hub (#2410) also simultaneously relays SaMD-related data (#2414) to the SaMD processor (#2420) after analysis by the stream analysis engine (#2415). As illustrated in this way, message hub #2410 can selectively direct specific messages/data (or data types) to various functional units of the NDS. For example, the hub may relay HCP-related MA derived MA-Ds only to SaMD, and study user class MA-Ds may be routed to other functional units (not shown).

The stream analysis engine/unit (#2415) performs various data analysis on streaming data relayed to the SaMD/SAMD module (#2420), including for example data filtering, data cleaning, data validation, NDS manager alerting, etc. It can perform its function. The SaMD engine (#2420) generates analysis data (NDS-AD), i.e. scored message data, which is first relayed to the Scored Message Event Hub (#2430), which in turn produces the scored data (#2435). Relayed to the data lake/EDL (#2440), this scored message data is received and stored in different governance areas of the DL/EDL (not shown) from the inbound data stream (#2412). Scoring of data as part of a data conversion process can be generally applied to any aspect of the invention described herein, such scoring being achieved by, for example, one or more pre-programmed and programmable methods applied by the NDS component(s). Data classification or validity audit rules are applied by comparison of the data. Simultaneously/together, the scored message event hub (#2430) relays the prediction data to the prediction handler unit/engine (#2490), which in turn relays the analysis data (NDS-AD) (here, e.g. physiological parameter predictions). Web applications/interfaces (#2493) (e.g., by generating formatted output for display in a web application interface) and various network MAs and other network devices and interfaces (ONDIs) (a.k.a. OND) )(#2495). Relayed information may also include output functions, such as commands for triggering alerts, changing device behavior, etc.

The data in the DL/EDL (#2440) is compressed automatically, periodically or otherwise, by a data compression unit such as AVRO Explorer (#2450) or equivalent, and the compressed DL data is then stored in one database, such as the first database. relayed to one or more structured database data stores, including the Behavioral Reporting Store (#2460), which contains (1) data received directly from an analytics processor or other functional component of NDS, and (2) a second relational database (NDS- Stores NDS performance-related data, including data obtained or received from the RDB (# 2470), including structured data sets generated from output relayed to the network component of the NDS/MAC-DMS). The data in the behavioral reporting repository/primary database is also stored in a structured format suitable for inclusion in a relational database (e.g., containing multiple levels of data in various fields, records and tables in an ordered hierarchy), e.g. It can be used to perform queries, reports, etc. using more complex data structures than those stored in other parts of the NDS data store, such as an enhanced data lake, and provides another means of ensuring or improving NDS operability.

The Behavioral Data Health Dashboard (#2480) provides system/NDS analysts (#2485) with the ability to monitor data quality coming into or into the Behavioral Reporting Repository on a continuous, regularly recurring, conditionally occurring, or on-demand basis. It may be considered a functional module (FM) that includes or corresponds to engine(s)/unit(s)/system(s) that provides the functions provided. A dashboard may be a schema/representation passed to various device(s)/interface(s), or it may be a dedicated device/NDS component, in either case providing visual indicator(s) of various aspects of the state of the data (data gaps). , data inflow/processing delay, data consistency, amount of data modification, correlation between expected data parameter(s) and data, etc.). Using data visualization dashboards, such as this example dashboard (#2480), you can identify data quality issues either manually (e.g., through visual inspection) or automatically (by comparing data to predetermined standards, missing/corrupted records). /scanning of the dataset, etc., or a combination thereof). Once NDS analyst users become aware of these data problems, they can change aspect(s) of NDS operation to reduce the likelihood, severity, or frequency of these data errors occurring. Similar dashboard monitoring methods/systems can be applied to any other aspect as well.

As mentioned, system relay data may be relayed from here to a second relational database, NDS-RDB (#2470), which may serve as the basis for network-visible functions/output such as data queries (not shown). there is. Data entering the NDS-RDB (#2470) can be accessed by the NDS Memory Unit (NDS-MEMU) Data Status Dashboard (#2475), which allows data to be accessed by system analysts (#2476) and independent entity network analysts. Another user evaluates data entered or already contained in the second relational database.

This example demonstrates data processing via NDS, analysis of early events in the NDS analysis process, use of structured databases as a complement to DL/EDL DR, and use of monitoring dashboard(s) to ensure data quality/data health during system operation. Including, it shows various aspects of the invention, all of which reflect additional distinguishing aspects/features of the system/network of the invention.

Figures 25, 26, 27 and 28

25-28 can be relayed by MA to NDS and operated by NDS component(s) such as SDE, stored in DR such as EDL, and in turn output application (not shown in Figure 25-28). This is an exemplary semi-unstructured dataset of the type that can be used to generate NDS-AD, which is used to generate output.

Figure 25 specifically includes a semi-structured data structure (JSON record) (#2500) containing several predefined attribute entries (#2503) and corresponding value entries (#2507), allowing records/fields within the semi-structured data structure. forms. The datasets in Figures 26, 27, and 28 are also semi-unstructured JSON type datasets containing attribute/value pairs.

As shown in each of Figures 25-28, such datasets may include dataset identifying information, generally provided as a first portion of the dataset (as shown), which allows the NDS component(s) to access the data. A set can be associated with a specific MA and derive MA status, ownership, location, type, etc. In general, the method of the present invention may be configured to receive data from a MA comprising a plurality of data points contained in a plurality of different semi-unstructured collections comprising a plurality of types of attribute/value pairs, among which are At least some of them contain multiple values for two, three, four or more attributes, which attributes typically include sensor data, device performance data, or both, as illustrated in these figures and described in the following paragraphs. do.

In Figure 25, for example, data record (#2600) includes a first line containing #2503, "JSON", a value that reflects the type of data record, indicating that the data record is a JSON formatted record. indicates). The first line (#2510) of the data record (#2500) further includes a second value (#2507) identified as “Pump_data” that signals that the record belongs to pump MA performance/status information. In either case, note that no explicit attribute field is provided in the first line, which reflects that in some cases attributes may be determined based solely on the location of the data record.

A second record (#2520) associated with the "JUID" attribute contains one record identifier record/entry/value ("84000011") that can be used to distinguish this dataset from other datasets received by NDS. do. A third record (#2530) associated with the "MSG_NO" attribute provides here another identifier value ("804") associated with a particular dataset, allowing this dataset (messages) to be distributed to or from the same MA in the same period of time. Distinguish it from other transmitted datasets. The fourth record (#2540) provides a time index record for a zone in the relevant MZMA over which the MA/dataset is relayed. The fifth record (#2550) provides the second temporal indicator record for the second zone of the associated MZMA. The sixth record (#2560) associated with the "CASE_ID" attribute provides the third dataset/source identifier (here the "F8_0_1_0" value).

As can be seen in this example dataset, a SUMAD dataset generated by an MA can be used to determine a specific function (e.g., a specific function performed by the dataset (e.g., a specific time(s), a specific MA(s), or a specific MA(s), etc. It may contain a number of identifiers that can identify the s) associated with it, and may also include several time indicators (particularly in the case of MZMA(s)). These principles may be modified and applied to any other aspect of the invention. Including multiple identifiers in data records can help with data security, data analysis, or both.

The second part of the dataset (#2500) shown in Figure 25 provides several values associated with the “RPM” attribute (#2570). This illustrates how the MA can include one dataset or one portion of the dataset device performance data (here, pump revolutions per minute (RPM)).

Dataset (#2600) in Figure 26 contains similar attribute (#2603) and value (#2607) record layouts and illustrated datasets (e.g., PUMP_DATA values (#2610) and other identifiers (#2620, #2630, #2640, #2650, and #2660) and MA sensor data (specifically, the “LVP” attribute (#2670), which reflects left ventricular pressure (“LVP”), measured in patients associated with MZMA. Similar identifying information (sometimes referred to as a header) is included in the first part of the data set (containing data set). The data string (including a number of "0" entries) at the beginning of the value record is in an inactive state or discarded from data analysis. It may reflect other invalid data.

A similar semi-unstructured data set (#2700) shown in Figure 27 includes a collection of value/attribute pair records (#2705) containing various identifying information and device performance data. Specifically, the first record, "JSON", contains an "alarm" value (#2710), which identifies that the data set contains alarm data, e.g., MA-D will be received by NDS. Provides fast detection by SDE when Unique message number and case number records (#2730 and #2760) are once again provided, where device performance data is in the form of data identifying alarms registered to the MA (#2770).

The semi-unstructured dataset (#2800) shown in FIG. 28 includes a first dataset identifier/record (#2810) as well as various system/software state information. For example, various operating system, software, and hardware versions are provided in the records (#2815, #2820, #2825, #2830, #2835, #2840, #2845, #2850, and #2855), which are Illustrates how state information records of can be included in the SUMAD dataset. This information can be used by the NDS to determine, for example, whether the MA needs updates to understand its performance capabilities.

In aspects, some or all of the types of MA-Ds described above are combined into a single dataset that is relayed to the NDS (e.g., the dataset includes a number of points of MA/dataset identifier, along with device state information; may include any combination of device performance information; system, software or hardware version information; sensor data). The semi-unstructured nature and layout of these data provides for rapid and efficient analysis/processing and storage of data by NDS/methods, which is important in the context of providing medical treatment or diagnosis.

technical effect

Those skilled in the art will understand that the system and method of the present invention utilizes the various technical features of the present disclosure to provide heretofore unavailable tool(s) or to solve several problems that have not been solved in a similar or sufficient manner by hitherto known systems/methods. It will be recognized that it provides several technical effects to solve the problem. Various technical effects are described elsewhere in this disclosure, and some specific/exemplary technical effects are highlighted/reinforced herein.

One exemplary technical effect of the present invention is the ability to securely manage medical device data generated by a plurality of individually located medical devices (MAs) (e.g., MAs in a WAN) in a real-time or near-real-time manner. and a plurality of individually located MAs each have an interface with a network data management system (NDS), which cannot be actionable or managed in a timely manner by a human or group of humans, from which useful, time-sensitive data can be extracted, It may be compiled, processed, applied or otherwise operated, which cannot otherwise be feasibly performed by a human or human group addressed herein through the technical capabilities of MA and NDS.

In aspects, the technical effect of the present invention includes simultaneous control of the operation of a plurality of networked MAs in a network with NDS (DCDMS), such operation control of both stored SMAD and cache data during periods when the MA is offline. It is based on the analysis of and performs analysis and control functions based on the combination of these data. Such motion control may include delivering treatment instructions, delivering predictions, or controlling treatment components.

In these and other respects, the present invention improves the functionality of medical devices/devices in a network as well as the overall functionality of the system itself. The system provides enhanced management of multiple devices simultaneously based on sensor data, other data inputs, and historical collection of aggregated device data and individual device/patient data from device populations. Without the combination of elements of the inventive system described herein, such medical devices will not operate accurately or effectively, and other users of the system will be able to use the inventive system to obtain data from the system in as useful and compliant a manner as possible. You won't be able to access it.

In aspects, technical effects associated with the present invention may include providing a multi-component MA (Multi-Zone MA (MZMA)) comprising limited components/zones where Internet communications are significantly limited or where there is no direct Internet communications. This includes protecting sensitive MA components from unauthorized Internet communication intrusions, hacking, etc. In aspects, controlling these components requires local operations in addition to network level operations, such as local requests for software modifications/upgrades if such modifications/upgrades are possible.

In aspects, technical effects associated with the present invention include providing real-time or near-real-time analysis of such data through the use of MPP functionality, while operating in various states, as well as using improved data lake memory structures and collection processes, as well as the processor of the system. Includes the ability to process streaming data input from multiple MAs, various types of MAs associated with various subjects in various conditions, using data queuing and system scaling according to pre-programmed instructions executed by (s). In aspects, the systems and methods of the present invention perform a limited initial analysis of RT/S-MA-D and MA-CD upon inflow prior to or during NDS DR collection and, where appropriate, perform initial controls based on this initial analysis. or performing an output operation. One way to achieve this is through the use of multiple processing systems and memory components (e.g., an initial SDP that includes an SDP processor and memory and a primary processor unit and primary memory/DR (e.g., an enhanced data lake)). It is achieved through

In aspects, the technical effects associated with the present invention include jointly/simultaneously relaying analysis data generated from MA data analysis to various users of various user classes, including HCP and commercial/BP class users/devices (ONDI); , the data delivered is tailored to these different users, providing for example, redaction or exclusion of PHI from data delivered to commercial class users. In aspects, the technical effects also or alternatively include receiving input data from study class users, using such data in conjunction with clinical MA data in generating some system analysis data, and also in compliance with regulatory requirements and other clinical trials. /Separate these data and analytics data based on these data for business purposes.

The technological features/advantages of the system(s)/method(s) may lead to improved patient care delivery, including, for example, predictive capabilities or, alternatively, new learning(s) of potentially anticipated adverse medical events. It could lead to preventive or future medical improvements, healthcare operation(s), and technological effects that could prove invaluable to human life.

These exemplary technical features of the MA include device physical, transportable, and reproducible computer-readable media (MAPTRCRM), including processing functions for executing device computer-executable instructions (MACEI), and sensor information over time during operation. Device memory (DM) for recording information including; device display unit (MA-DISPU); Device relay unit (MA-RELAYU/DDRU) capable of transmitting real-time (RT-MA-D) or stored (MA-CD) structured, unstructured or semi-structured device information (MA-D), including sensor information, to the NDS; Device Data Input Unit (MA-INPU); and MA, which includes a device data security system (MA-SECURU) that includes microcontroller(s) providing data protection functions including restricting data based on established authorized data types.

The ingenious systems and methods presented herein are designed to improve the quality of data analysis and the system's ability to process rapidly incoming streams and data from numerous devices simultaneously, including multiple time-based data collection cycles within system memory, various time-out operations, and a variety of Includes the use of data governance areas.

Exemplary technical features of the NDS include a Retrievable Data Repository (DR) that receives and stores semi-unstructured MA-D (SUMAD) and NDS PTRCRM, which further includes NDS CEI (NCEI) encoding instructions for the functions performed by the NDS. NDS containing memory unit (NDS-MEMU); NDS processing function (NDS-PROCU), which runs NCEI; Automatically receives data from MAs communicating with the NDS and can distinguish the type(s) of MA-D (e.g., RT-MA-D, MA-CD, or both) received from each MA. NDS data input unit (NDS-INPU); an NDS Analysis Unit (NDS-ANALU), which analyzes real-time, stored, and semi-unstructured MA-Ds to generate analytics and further applies these analyzes to the performance of one or more NDS functions; the NDS Device Data Harmonization Unit (NDS-DHU), which evaluates whether MA-Ds are approved for use by NDS-ANALU and determines how these approved MA-Ds are used by NDS-ANALU; Automatically configures MA-D, analysis, or both for selective delivery to each MA or other network device/interface (ONDI) (e.g., to other clinical, non-clinical, or research components), based on confidentiality and healthcare compliance rules. NDS output processing system (NDS-PROCU), which can be filtered by; Securely relaying specific information over the Internet to specific target locations, e.g., MA-specific, patient-specific, or both, with each MA being specifically identified and configured to be adaptable by the MA-SECURU(s), one or more specific data types. In addition, relay information, including MA-D, analysis, or both, to one or more ONDIs, where the information relayed to ONDI may include information from multiple MAs associated with independent entities (IEs). data relay unit (NDS-RELAYU); and the NDS Stored Data Analysis function (NDS-ANALU), which generates stored data analysis (LS-D-ANALU) based on the application of one or more schemas to semi-unstructured M-AD.

The system(s) and method(s) of the present invention can centrally collect, centrally store, and centrally analyze MA-Ds derived from independently operating MAs of a plurality of IEs that together form a MA-network. MA-D may include various data originating from the MA and selectively communicate information based on the collection and analysis of such data to a plurality of entities, such as clinical entities, sales entities, and research entities, and such communications may include: Limited based on target recipient profile(s).

This process is similar to the process recognized by patent authorities as covering patentable subject matter. For example, this process compares, for example, to the collection and distribution of stock-related data (stock quotes) as described in Example 21 of the USPTO's Guidance on Subject Eligibility available through the United States Patent and Trademark Office (USPTO); , whereby the stock quote alert(s) are formatted into blocks of data according to established information formatting protocols, or preferences or rules, or the address/destination of the data, wherein the data is stored in a set specification before being distributed over a communications channel to its final destination. It is filtered or analyzed according to. Another aspect, as described herein, is that data may be cached in such a way that the data becomes available (e.g., transmitted, e.g., an exemplary stock alert is provided) when the system is online. In that respect, it is similar to Example 21, for example. Accordingly, the aspects described herein provide much more than simply organizing and comparing data. As illustrated in the USPTO example provided, the present invention is directed to the use of a memory for storing rules/settings/preferences and a transmission component (e.g., a microprocessor) with specific and limited functionality, in a first location over a data channel. transmitting data and associated alerts to at least a second location, receiving the data or alerts, even if such data/alerts are collected, where not all aspects of the system are necessarily online so that the collected data is transmitted once public communication is established; and providing mechanisms for interpretation and interpretation.

The combination of memory and processing capabilities combined with a data source that operates on data received from the source offers much more than the abstract idea of using data collection techniques to manage data, for example. Receive, transmit, manage, control and apply medical data from multiple units (comparable to multiple video cameras, for example) and integrate them within a single system to provide meaningfully different new data sets. The application of functional processors, analysis units, data modification units, memory units, relay units and other functional modules described here gives back much more than an abstract idea of data management.

The technical functionality of the system(s)/method(s) herein addresses the identification and analysis of anomalous patterns that can direct or inform further processing, thereby modifying what NDS users would face in the absence of such NDS or method(s). and; The systems and methods provided herein may also utilize corrective actions for anomalous data or patterns in the data, such as, for example, applying corrections or directing alerts and, among other things, directing activities based on the identification or correction of anomalous data or data patterns. (see, e.g., USPTO Guidance, Example 46).

Centralized collection, storage, and analysis of MA-Ds that may be generated by MAs associated with critical life support functions from independently operating MAs within or representing multiple IEs are an addition to those available locally to each MA. Provide clinical oversight, provide opportunities to support clinical research, product development and sales efforts, and further provide mechanisms for improved MA product performance by virtue of the at least semi-remote controllability of the systems and method aspects disclosed herein. to provide.

Accordingly, exemplary element(s) of the technical features include continuous data transmission to NDS by NDS-RELAYU(s)/DDRU(s) in data format(s) acceptable to MA-SECURU(s); An NDS function for identifying past, current and expected MA-D, wherein NDS-ANALU can perform prediction function(s) based on the analysis and relay the results of the prediction function to MA, ONDI, or both. NDS function; As an NDS-ANALU performing function(s) regulated by software as a medical device (SAMD) and a non-SAMD function (NSAMD), the system shall be eligible for SAMD and NSAMD on MA under a CEI that reflects the applicable regulatory status of the SAMD and NSAMD functions. the NDS-ANALU performing function(s), passing the output of the function; SAMD, which can change the operating conditions of the MA(s) in response to one or more conditions; NDS-RELAYU, which delivers MA-D, analysis, or both in multiple GUI formats based at least in part on user roles; As a CEI that contains one or more alarm conditions associated with sensor data, NDS-ANALU determines whether one or more alarm conditions are triggered by MA-D, analysis, or both, and NDS determines whether the alarm is triggered by sensor data and an authorized user. the CEI, optionally allowing registration with a MA, a User Associated Network Access Device (NAD), or both; MA-SECURU with anti-tampering detection; and storage, for example, for various types of data (e.g., RT-MA-D, MA-CD, or both, curated data, scored data, or both, system test data, and outbound data); Includes NDS-MEMU, which includes a separate governance area to manage usage and access. Physical components, such as processors and processing systems, are used in conjunction with communication channels and data recognition methods to integrate, manage, effectively and efficiently manage all the diverse data provided by multiple medical devices within complex, modern healthcare environments. Solve the challenge of providing proactive, comprehensive and effective medical device data management. The systems and methods provided herein solve the problem of safely managing vast, diverse, and complex medical data in a compliant and effective manner.

Technical effects may include combination(s) of the effects described above.

List of Exemplary Aspects

The following is a non-limiting list of illustrative embodiments of the invention to illustrate some embodiments of the invention presented in summary form. Similar to patent claims, aspects described in a paragraph of this section may be referenced to (depending on/from) one or more other paragraphs. The reader will understand that such references mean that the features/characteristics or steps of such referenced aspects are incorporated/combined into the referenced aspect. For example, if an aspect of a paragraph (e.g., paragraph 501/aspect 2) refers to a different aspect by paragraph or provided aspect number (e.g., paragraph 500/aspect 1), the elements of paragraph 501/aspect 2 , it will be understood that all elements, steps or features of paragraph 500/Aspect 1 are included, in addition to steps or features.

In another aspect, the present invention provides a system for (1) automatically and continuously receiving and processing relayed MA-D from a plurality of medical devices authorized to receive MA-D, and performing initial analysis on the received streaming MA-D; perform to determine whether one or more preprogrammed conditions exist in the streaming MA-D, and if one or more such conditions exist, perform one or more of a limited set of preprogrammed initial functions to determine whether the medical device, one or more other network devices, or Both operate as one or more controllers, the initial function of which includes relaying instructions to control the operation of one or more medical devices networked with the system, one or more other networked computer devices networked with the NDS, or both. a streaming data processing unit; (2) A system memory component that includes processor-executable instructions and one or more data data stores, wherein the one or more data stores automatically store at least a portion of the MA-D and have access conditions separate from the MA-D and different from the MA-D. further storing at least some of the analysis data under (a) governance rules for sorting and managing the stored data; (b) predetermined data formatting standards applicable to at least some of the stored data; or (c) (a) and (b) the system memory component, including both; (3) an analytics engine that performs one or more analytics functions based at least in part on analytics data stored in the enhanced data lake, either upon user request, upon the occurrence of preprogrammed conditions, or both; (4) a cache MA that analyzes the cache MA-D when received by the medical device and determines whether the cache MA-D should be stored in the MAC-DMS memory component, analyzed by the analysis engine, or both; -D processing engine; and (5) an analytical data controller that relays one or more outputs via secure Internet communication to one or more medical devices, one or more other networked computer devices, or both, wherein the one or more outputs are: (a) analytical data outputs; (b) (I) one or more medical device functions of one or more of the networked medical devices, (II) one or more other network device functions of one or more of the other networked devices networked with the System, or (III) (I) and (II) Provided is a system/NDS (e.g., MAC-DMS) comprising the analytics data controller, including one or more output applications containing instructions to control the operation of both (Aspect 1).

A system according to aspect 1 is further provided, wherein the system is capable of combining a MA-D of a medical device with a received streaming MA-D of the same medical device, and the system engine is capable of combining a cache MA-D and a streaming MA-D. and an engine for combining the streaming MA-D and the cache MA-D to form a mixed MA-D data set, wherein the MA-D analyzed by the analysis engine is mixed to generate analysis data or output. Utilizes the MA-D data set (Aspect 2).

A system according to aspect 1 or aspect 2 is also provided, wherein (1) one or more output applications comprise (a) one or more therapeutic operations performed by a particular medical device networked with the system, (b) to be performed by the particular device; contains medical device-specific instructions for controlling one or more preventive operations, or (c) both one or more remedial operations and one or more preventive operations to be performed by a particular medical device; (2) The system causes a particular medical device to receive, interpret, and execute the one or more output applications, thereby changing the condition of the patient based on the one or more output applications received (Aspect 3).

A system according to any one or more of aspects 1-3 is provided, including: (a) one or more recommended medical instructions, (b) for display on a graphical user interface of one or more networked medical devices; ) analytic data associated with a medical device, a patient, or both, wherein the analytic data includes patient protected health information, or (c) generates both (a) and (b); (2) relay the first representation to one or more networked medical devices for display in one or more graphical user interfaces (aspect 4).

A system according to aspect 4 is also provided, the system further comprising: (3) generating a second representation comprising analysis data completely free of any patient protected health information, for display in a graphical user interface of one or more other network devices; ; (4) relaying the second representation to one or more other network devices for display on one or more graphical user interfaces, the system being adapted to perform steps (1)-(4) in less than one minute (aspect 5).

A system according to any one or more of aspects 1-5 is also provided, wherein (1) the one or more data stores further include a first relational database, and (2) operation of the system includes (a) generating the first structured data from analysis output data; generate dataset data, (b) store the first structured dataset data in a first relational database; (3) the one or more data stores include a second relational database, and (4) the system is configured to (a) perform one or more analytics functions on data in the enhanced data lake to obtain analytics data, and (b) optionally, a second relational database. 1 Generate second structured dataset data from this analysis data by combining it with data contained in the relational database, and (c) store the second structured dataset data in the second relational database (Aspect 6).

A system according to aspect 6 is also provided, wherein the system automatically (1) (a) prepares or inputs into the first relational database a third representation regarding the quality of data stored in the first relational database, or both; (b) relaying the third representation to a graphical user interface of one or more other network devices in a data network associated with the one or more system administrator users, or (b) performing a fourth representation regarding the quality of data stored in the second relational database. prepare, input into a second relational database, or both, thereby relaying the fourth representation to a graphical user interface of one or more other network devices on the data network associated with one or more system administrator users, or (c ) (I) prepare a third representation regarding the quality of data stored in the first relational database, enter into the first relational database, or both, and (II) make the third representation associated with one or more system administrator users. relay to a graphical user interface of one or more other network devices in the data network, and (III) prepare a fourth representation regarding the quality of the data stored in the second relational database, input into the second relational database, or both. and (IV) relaying the fourth representation to a graphical user interface of one or more other network devices on a data network associated with one or more system administrator users, and (2) data represented by the third representation, the fourth representation, or both. Apply one or more modifications to one or more instructions in system memory if the quality indicates a lack of quality in the first relational database data, the second relational database data, or both (Aspect 7).

Additionally provided is a system according to any one or more of aspects 1-7, wherein in operation the system automatically (1) collects MA-D during a data collection period to form a data collection; (2) assess whether the data collection is suitable for analysis according to one or more preprogrammed standards; (3) If the data collection is suitable for analysis, add the data collection to the data aggregate, and repeat steps (1)-(3) until at least 10 data collection instances are added to the data aggregate to form a complete data aggregate. repeat; (4) If any data collection instance is determined to be inadequate before a complete data aggregate is formed, the system automatically discards the incomplete data aggregate and restarts data collection; (5) When a complete data aggregate is formed, the system causes one or more analysis functions to be performed on the data containing the complete data aggregate (Aspect 8).

Also provided is a system according to any one or more of aspects 1-8, wherein the system comprises: three or more independent entities, multiple other network devices based on their association with a class of commercial users, or both. Identifies data from networked medical devices and selectively communicates data to one or more different medical devices, one or more different networked devices, or both, resulting in inadvertent disclosure of confidential information, unauthorized disclosure of personal health information, or both. Adapted to prevent differences (Aspect 9).

Additionally provided is a system according to any one or more of aspects 1-9, wherein the system comprises at least two different medical devices (e.g., a first type of medical device that performs one or more pulmonary treatment tasks and one or more (aspect 10).

The invention also provides a system according to aspect 10, wherein the system automatically applies the MA-D received from both the first medical device type and the second medical device type to generate predictions associated with the treatment operation performed by the medical device. A machine learning module that generates predicted patient-specific physiological parameters and communicates these predicted patient-specific physiological parameters to a medical device, another network device, or a combination of one or both of two different medical device types. Includes (Aspect 11).

Additionally provided is a system according to any one or more of aspects 1-11, wherein the system identifies data from a medical device or other network device associated with a study class user, and retrieves the MA-D obtained from the medical device associated with the healthcare provider. Adapted to apply pre-programmed rules, conditions, or both, for coupling with devices relevant to the research user class and to perform one or more analysis engine functions based at least in part on the blended data set (aspect 12).

Also provided is a system according to any one or more of aspects 1-12, wherein the system automatically imposes a requirement for MAD, or both, to store substantially all MA-D datasets stored in the enhanced data lake. (2) to include medical device source identification information, MA-D type information, and one or more physiological parameter datasets, each of which is represented in a standard, preprogrammed, system-recognizable format; (2) the enhanced data lake contains Adapted to include different data governance zones based on the source or content of the stored MA-D dataset, analysis data, or both (Aspect 13).

Additionally, a system according to one or more of aspects 1-13 is provided, wherein the system comprises (1) providing one or more alarms registered with one or more medical devices, one or more other network devices, or a combination thereof; automatically generate and apply one or more output applications; (2) is adapted to provide user-adjustable triggering parameters, communication parameters, repetition parameters, or a combination of any or all of these for one or more alarms, wherein the system determines whether the parameters are (a) local medical device level, local other network (b) set at the device level or both; (b) set at the system level based on medical device type, patient type, user type, or any or all combinations thereof; or (c) both (a) and (b) It is adapted to be set according to (Aspect 14).

In one aspect, the present invention provides a computer-implemented method for controlling the operation of medical devices and other devices in a data network, comprising: (1) providing a data network, wherein the data networks include (a) at least five; 10, 20, 50 or 100 remotely controlled, selectively operable, Internet-connected medical devices, some, most or each of which (I) processes information regarding one or more physiological conditions; One or more sensors that detect one or more patient-related physiological conditions of any patient operably associated with a medical device, converting them into readable medical device data (MA-D), wherein the MA-D is a predefined semi-structured data format. one or more sensors, including a compliant MA-D; (II) an output engine to selectively relay data via secure Internet data communication; (III) to optionally store the MA-D, analyze the MA-D, and a medical device memory component comprising processor-executable instructions for relaying and evaluating a connection between the medical device and a network, and (IV) a medical device processor executing the instructions of the medical device memory component, (b) MAC-DMS, comprising (I) a MAC-DMS processor that reads computer readable instructions to analyze data and perform functions, (II) a streaming data processing engine, (III) a cache MA-D processing engine, ( IV) an analysis engine, and (V) a MAC-DMS memory component including processor executable instructions and one or more data stores, wherein the one or more data stores store at least a portion of the MA-D and at least a portion of the analysis data separately and from each other. the MAC-DMS, including the MAC-DMS memory component, including an enhanced data lake for storing under access conditions, and (c) at least three other network devices, each of the other network devices configured to: (I) (A) ) a processor, (B) a memory component, and (C) a remotely controllable graphical user interface, (II) associated with a user assigned to at least one user class, the user class being (A) a patient protected health information; (B) providing at least three other network devices, including (B) a healthcare provider authorized to access and (B) a commercial user restricted from receiving patient protected health information; (2) allowing each operating medical device to repeatedly collect sensor data from the patient; (3) Ensuring that each operating medical device automatically and repeatedly evaluates whether a secure network connection is available, which (a) provides practical access to MAC-DMS via secure Internet data communication, if a secure and reliable network connection is available; (b) if a secure and reliable network connection is not available, (I) automatically relay data containing the MA-D on an ongoing basis; (ii) storing the cache MA-D in the medical device memory component as a cache MA-D and (ii) relaying the cache MA-D to the MAC-DMS via secure Internet data communication when a secure and reliable network connection becomes available; (4) The MAC-DMS processor automatically uses the streaming data processing engine to (a) receive the relayed streaming MA-D, (b) perform initial analysis on the relayed streaming MA-D, and (c) If the initial analysis identifies one or more pre-programmed conditions in the streaming MA-D, causing it to perform one or more of a limited set of pre-programmed initial functions, which initial functions may include: one or more medical devices, one or more other network causing to be performed, including relaying instructions to control the operation of the device or both; (5) The MAC-DMS processor uses the Cache MA-D process to (a) receive the Initiating MA-D when the Cache MA-D is relayed from the medical device to the MAC-DMS, and (b) receive the Cache MA-D. causing D to determine whether it is suitable for analysis by an analysis engine, storage in at least one of the one or more data stores, or both; (6) causing the MAC-DMS processor to automatically store at least a portion of the MA-D in the enhanced data lake; (7) the MAC-DMS processor using the analysis engine to perform one or more analysis functions on the MA-D stored in the enhanced data lake upon user request, upon the occurrence of pre-programmed conditions, or both, and (8) causing the MAC-DMS processor to relay one or more outputs via secure Internet communication to one or more medical devices, one or more other network devices, or both, wherein the one or more outputs are (a) analysis data output, (b) ) (I) one or more medical device features on one or more of the medical devices in the data network, (II) one or more other network device features on one or more of the other network devices in the data network, or (III) both (I) and ( II) the one or more output applications, including instructions for controlling the operation of both, and (c) causing the relay to include a combination of (a) and (b) of step (8) ( Aspect 15).

Also provided is a computer-implemented method for controlling the operation of medical devices and other devices in a data network, comprising: (1) providing a data network, wherein the data network is (a) remotely controllable, selectively operable, and connected to the Internet; At least 10 medical devices connected, each of the at least 10 medical devices (I) detecting one or more patient-related physiological conditions and converting information regarding such one or more physiological conditions into processor-readable medical device data (MA-D); one or more sensors that convert, the MA-D comprising: an MA-D that conforms to a preset semi-structured data format; (II) an output engine that selectively relays data via secure Internet data communication; (III) a medical device memory component containing processor-executable instructions for selectively storing MA-D, analyzing and relaying MA-D, and evaluating the connection between the medical device and the network, and (IV) a medical device memory component. at least ten medical devices, including a medical device processor executing instructions, (b) a MAC-DMS, (I) a MAC-DMS that reads computer readable instructions to analyze data and perform functions; (II) a streaming data processing engine, (III) a cache MA-D processing engine, (IV) an analysis engine, and (V) a MAC-DMS memory component including processor executable instructions and one or more data stores. said providing step, comprising -DMS; and (2) causing each medical device in operation to automatically and repeatedly evaluate whether a secure network connection is available, where (a) a secure and reliable network connection is available, in a substantially continuous manner via secure Internet data communication; automatically relaying data containing the D to the MAC-DMS, or (b) if a secure and reliable network connection is not available, (I) transferring the MA-D to the medical device until a secure and reliable network connection is available; (II) storing the cache MA-D in the memory component as a cache MA-D and (II) relaying the cache MA-D to the MAC-DMS via secure Internet data communication when a secure and reliable network connection becomes available; (3) The MAC-DMS processor automatically uses the streaming data processing engine to (a) receive the relayed streaming MA-D, (b) perform initial analysis on the relayed streaming MA-D, and (c) If the initial analysis identifies one or more pre-programmed conditions in the relayed streaming MA-D, a step of causing it to perform one or more of a limited set of pre-programmed initial functions, wherein the initial functions are: one or more medical devices, one or more other network the steps comprising relaying instructions to control the operation of the device, or both; (4) the MAC-DMS processor uses the analysis engine to (a) identify a collection of MA-Ds representing periods of MAC-DMS operation, medical device operation, or both to form a first unit of MA-D; , (b) analyze the first unit of the MA-D to determine whether the first unit of the MA-D complies with the preprogrammed unit analysis conditions, and (c) determine whether the first unit of the MA-D complies with the preprogrammed first unit. (d) initiate the formation of a second unit of the MA-D by adding the first unit of the current MA-D if the unit analysis conditions are complied with; (d) (I) the first unit analysis conditions for which the current first unit is preprogrammed; or (II) repeating steps (a)-(c) until the second unit of MA-D is completed; (5) performing one or more analytical functions on a second unit of the MA-D; and (6) causing the MAC-DMS processor to relay one or more outputs based on the results of the one or more analysis functions to one or more medical devices via secure Internet communication, wherein the one or more outputs are (a) generated from the second unit. (b) one or more output applications containing instructions that control the operation of one or more medical device functions on one or more of the medical devices in the data network, or (c) a combination of (a) and (b). Comprising, comprising the step of relaying (embodiment 16).

The present invention also provides a computer-implemented method for controlling the operation of medical devices and other devices in a data network, comprising: (1) providing a data network, the data network comprising (a) a plurality (e.g., at least 10) remotely controllable, selectively operable, Internet-connected medical devices, each of which (I) detects one or more patient-related physiological states and reads information to a processor regarding one or more physiological states; (ii) one or more sensors that convert medical device data (MA-D) into capable medical device data (MA-D), wherein the MA-D conforms to a pre-established semi-structured data format, the one or more sensors, (ii) secure Internet data communication; an output engine for selectively relaying data through; (III) a medical device memory containing processor-executable instructions for selectively storing MA-Ds, analyzing and relaying MA-Ds, and evaluating the connectivity between the medical device and the network; Components, and (IV) a medical device processor that executes instructions of a medical device memory component, (b) (I) reading computer-readable instructions to analyze data and perform functions; A MAC-DMS processor, (II) a streaming data processing engine, (III) a cache MA-D processing engine, (IV) an analysis engine, and (V) a MAC-DMS memory component including processor executable instructions and one or more data stores. wherein the one or more data stores include an enhanced data lake for storing at least a portion of the MA-D and at least a portion of the analysis data individually under different access conditions, comprising the MAC-DMS memory component. a Device Controller and Data Management System (“MAC-DMS”), and (c) at least three other network devices, each of the other network devices being (I) (A) a processor, (B) a memory component, and (C) a remote and (II) associated with a user assigned to at least one user class, wherein the user class is: (A) a health care provider authorized to access patient protected health information and (B) a patient protected health information; The providing step, including the at least three different network devices, including commercial users restricted from receiving health information; (2) causing each medical device to perform one or more steps to assess whether a secure network connection is possible, (a) if a secure and reliable network connection is available, in a substantially continuous manner via secure Internet data communication; automatically relaying data containing D to the MAC-DMS, or (b) if a secure and reliable network connection is not available, (I) the medical device to the MA-D until a safe and reliable network connection is available; performing one or more steps to store the cache MA-D in a medical device memory component; and (II) when a secure and reliable network connection becomes available, the medical device stores the cache MA-D via secure Internet data communication. performing one or more steps for relaying to MAC-DMS; (3) the MAC-DMS processor automatically uses the streaming data processing engine to (a) perform one or more steps to receive the streaming MA-D, and (b) perform an initial analysis of the relayed streaming MA-D; and (c) one or more steps to initially analyze the MA-D for the presence of a limited set of indicators for one or more emergency conditions if the initial analysis identifies one or more preprogrammed conditions in the streaming relay MA-D. performing and, if such one or more emergency conditions exist in the MA-D, causing the streaming data processing engine to perform one or more steps to control the operation of one or more medical devices, one or more other network devices, or both; (4) the MAC-DMS processor uses the cache MA-D processor to: (a) perform one or more steps to receive the cache MA-D when the cache MA-D is relayed from the medical device to the MAC-DMS; b) causing one or more steps to be performed to determine whether the received cache MA-D is suitable for analysis by an analysis engine, storage in at least one of the one or more data stores, or both; (5) causing the MAC-DMS processor to perform one or more steps to automatically store at least some of the MA-Ds in the enhanced data lake; (6) cause the MAC-DMS processor to use the analysis engine to perform one or more steps to analyze the MA-D stored in the enhanced data lake upon request by the user, upon the occurrence of preprogrammed conditions, or both; steps; and (7) causing the MAC-DMS processor to perform one or more steps to relay one or more outputs via secure Internet communication to one or more medical devices, one or more other networked computer devices, or both, wherein one or more outputs are ( a) Analysis data output; (b) (I) one or more medical device features on one or more of the medical devices in the data network, (II) one or more other network device features on one or more of the other network devices in the data network, or (III) (I) and (II) one or more output applications comprising instructions that control the operation of both, or (c) a combination of (a) and (b) (aspect 17).

The present invention also provides a method of treating a medical condition of a patient in a patient population, the method comprising: (1) providing a data network, the data network being (a) a plurality of remotely controllable, selectively operable; , an Internet-connected medical device, each of which (I) is associated with a patient, and (II) detects one or more patient-related physiological states from (A) the associated patient and processes information regarding such one or more physiological states; (B) one or more sensors that convert readable medical device data (MA-D), the MA-D comprising the MA-D conforming to a pre-established semi-structured data format; (B) secure Internet data communication; an output engine for selectively relaying data through, (C) an output engine containing processor-executable instructions for selectively storing MA-Ds, analyzing and relaying MA-Ds, and evaluating the connectivity between the medical device and the network; a medical device, (b) a MAC-DMS, comprising a medical device memory component, and (D) a medical device processor that executes instructions of the medical device memory component to: (I) read computer-readable instructions to analyze data; a MAC-DMS processor, (II) a Streaming Data Processing Engine, (III) a Cache MA-D Processing Engine, (IV) an Analysis Engine, and (V) (A) processor executable instructions, and (B) one or (i) at least some of the MA-D, (ii) at least some of the Analysis Data, or (iii) in any event, at least some of such Data separately and under different access terms (i) ) and (ii) both, and (iv) an enhanced data lake that stores a collection of previously collected MA-D analysis data obtained from substantially similar medical devices associated with similar patients. a MAC-DMS, comprising a MAC-DMS memory component, and (c) at least three other network devices, each of the other network devices having (I) (A) a processor, (B) a memory component, and (C) (II) is associated with a user assigned to at least one user class, wherein the user class is (A) a health care provider authorized to access the patient protected health information and (B) a patient; the providing, comprising at least three different network devices, including commercial users who are restricted from receiving protected health information; (2) causing each operating medical device to repeatedly collect sensor data from the patient associated with it; (3) Automatically and repeatedly assessing whether each medical device is capable of a secure network connection, including (a) MA-D in a substantially continuous manner via secure Internet data communication, if a secure and reliable network connection is available; (b) automatically relay the data to the MAC-DMS, or (b) if a secure and reliable network connection is not available, (I) connect the MA-D to the medical device memory component until a secure and reliable network connection is available; (II) storing the cache MA-D to the MAC-DMS via secure Internet data communication when a secure and reliable network connection becomes available; (3) The MAC-DMS processor automatically uses the streaming data processing engine to (a) receive relayed streaming MA-D from medical devices, and (b) provide information about the relayed streaming MA-D received from each medical device. performing an initial analysis, and (c) if the initial analysis identifies one or more pre-programmed conditions in the streaming relay MA-D, causing it to perform one or more of a limited set of pre-programmed initial functions, wherein the initial functions are one or more the steps comprising relaying instructions to control the operation of a medical device, one or more other network devices, or both; (4) The MAC-DMS processor uses the Cache MA-D processor to (a) receive the Cache MA-D when the Cache MA-D is relayed from the medical device to the MAC-DMS, and (b) receive the Cache MA-D. determining whether D is suitable for analysis by an analysis engine, storage in at least one of the one or more data stores, or both; (5) causing the MAC-DMS processor to automatically store at least some of the MA-Ds in the enhanced data lake; (6) cause the MAC-DMS processor to use the analytics engine to perform one or more analyzes on at least a portion of the analytics data stored in the enhanced data lake upon request by a user, upon the occurrence of preprogrammed conditions, or both; As a step, the analysis engine (a) performs the analysis using the analysis data generated from the medical device by the MA-D when performing the analysis, and (b) analyzes the MA-D of each medical device using (I) the previously collected data. Comparing the MA-D analysis data, (II) to a preprogrammed standard, or (III) to both (I) and (II); (7) causing the MAC-DMS processor to relay one or more outputs via secure Internet communication to one or more medical devices, one or more other network devices, or both, wherein one or more outputs are (a) (I) medical related to the patient; device, (II) another network device closely associated with the provided healthcare related to the patient, or (III) output analytic data related to the patient's care relayed to both (I) and (II), (b) (I) (II) the functionality of one or more medical devices on one or more of the medical devices in the data network, (II) the functionality of one or more other network devices on one or more of the other network devices in the data network that are associated with a healthcare provider associated with the patient, or (III) (a) at least one output application comprising instructions to control the operation of both (I) and (II), or (c) a combination of (a) and (b). 18).

The invention also provides a computer-implemented method for controlling the operation of medical devices and other devices in a data network, comprising: (1) providing a data network, wherein the data network includes (a) a plurality of remotely controllable, selectively controlled devices; A medical device operable and connected to the Internet, each of at least 10 medical devices comprising: (I) one or more physical components that (A) when operated modifies one or more aspects of the physical condition of the relevant patient; (B) the relevant patient's physical condition; (C) one or more patient-interactive components that include both (A) and (B), or (II) one or more sensors that detect one or more physiological states, (II) storing such information as electronic medical device data (MA-D) A component for converting MA-D into data conforming to a preset semi-structured data format, (III) an output engine for selectively relaying the data over secure Internet data communication, (IV) MA -a medical device memory component containing processor-executable instructions for optionally storing D, analyzing and relaying MA-D, and evaluating the connection between the medical device and the network, and (V) executing the instructions of the medical device memory component. (b) a MAC-DMS, comprising: (I) a MAC-DMS processor that reads computer readable instructions to analyze data and perform functions; (II) streaming data; a processing engine, (III) a cache MA-D processing engine, (IV) an analysis engine, and (V) (A) processor executable instructions and (B) one or more data stores, wherein the one or more data stores are (i) MA- D, (ii) at least some of the Analysis Data, or (iii) in any event at least some of such data separately and under different access terms to both (i) and (ii), and (iv) substantially similar a MAC-DMS, comprising a MAC-DMS memory component including one or more data stores, including an enhanced data lake for storing a collection of previously collected MA-D analysis data obtained from a medical device, and (c ) at least three different network devices, each different network device comprising (I) (A) a processor, (B) a memory component, and (C) a remotely controllable graphical user interface, (II) at least one user class is associated with a user assigned to, wherein the user classes include at least three of the above, including (A) healthcare providers authorized to access patient protected health information and (B) commercial users restricted from receiving patient protected health information. The providing step, including another network device; (2) allowing each operating medical device to repeatedly collect sensor data and convert such data into MA-D; (3) causing each medical device in operation to automatically and repeatedly evaluate whether a secure network connection is available, which (a) if a secure and reliable network connection is available, MA-D in a substantially continuous manner via secure Internet data communication; (b) automatically relaying data containing data to the MAC-DMS, or (b) if a secure and reliable network connection is not available, (I) transferring the MA-D to the medical device memory until a secure and reliable network connection is available; (II) storing the cache MA-D in the component as a cache MA-D and (II) relaying the cache MA-D to the MAC-DMS via secure Internet data communication when a secure and stable network connection is available; (4) The MAC-DMS processor uses the Cache MA-D processor to (a) receive the Cache MA-D when the Cache MA-D is relayed from the medical device to the MAC-DMS, and (b) receive the Cache MA-D. determining whether D is suitable for analysis by an analysis engine, storage in at least one of the one or more data stores, or both; (5) causing the MAC-DMS processor to automatically store at least some of the MA-Ds in the enhanced data lake; (6) The MAC-DMS processor (a) evaluates the MA-D of each medical device against the MA-D of each medical device, or (b) generates and transfers analysis data from the MA-D of all medical devices. Evaluating the analysis data by comparing it to the MA-D analysis data collected in, or (c) performing both (a) and (b), thereby automatically evaluating the performance of the medical devices in the network using the analysis engine; and (7) based on the evaluation of the medical device and the NDS/MAC-DMS, changing at least one parameter of the medical device operation, the NDS/MAC-DMS operation, or both (Aspect 19).

Also provided is a method according to any one of aspects 15-19, wherein the method comprises evaluating whether a received cache MA-D of a medical device is combinable with a received streaming MA-D of the same medical device, and a MAC -If the DMS determines that the cache MA-D and the streaming MA-D can be combined, combining the streaming MA-D and the cache MA-D to form a mixed MA-D data set, by the analysis engine The analyzed MA-D includes a mixed MA-D data set (Aspect 20).

Also provided is a method of any one of aspects 15-2-, wherein (1) the one or more output applications comprise: (a) one or more therapeutic operations performed by a particular medical device; (b) one or more therapeutic operations performed by a particular medical device; preventive operations, or (c) medical device-specific instructions for controlling one or more therapeutic operations and one or more preventive operations performed by a particular medical device; (2) the particular medical device receives, interprets, and executes the one or more output applications, and (3) the particular medical device modifies one or more conditions of patient care based on the one or more output applications received (Aspect 21). .

Additionally provided is a method of any one or more of aspects 15-21, wherein the creation of one or more output applications comprises (1) for display in a graphical user interface of one or more medical devices: (a) one or more recommended medical instructions, (b) ) analytic data relating to a medical device, a patient, or both, where the analytic data includes patient protected health information, or (c) generating a first representation that includes both (a) and (b); (2) relaying the first representation to one or more medical devices for display on one or more graphical user interfaces, (3) for display on a graphical user interface of one or more other network devices, wherein any patient protected health information is generating a second representation comprising missing analysis data, and (4) relaying the second representation to one or more other network devices for display on one or more graphical user interfaces, wherein steps (1)— (4) is performed in less than 1 minute (Aspect 22).

Also provided is a method according to any one or more of aspects 15-22, wherein: (1) the one or more data stores further comprise a first relational database; (2) The method includes (a) generating first structured dataset data from analysis output data, (b) storing the first structured dataset data in a first relational database; (3) the one or more data stores include a second relational database, and (4) the method includes (a) performing one or more analytics functions on data in the enhanced data lake to obtain analytics data, (b) optionally generating second structured dataset data from such analysis data by combining it with data included in the first relational database; (c) storing the second structured dataset data in the second relational database (aspect 23).

Also provided is a method of aspect 23, comprising: (a) preparing a third representation regarding the quality of data stored in a first relational database, inputting it to the first relational database, or both, and generating the third representation: relaying to a graphical user interface of one or more other network devices in a data network associated with the one or more system administrator users, (b) preparing a fourth representation regarding the quality of the data stored in the second relational database, and entering into a database, or both, and relaying the fourth representation to a graphical user interface of one or more other network devices on the data network associated with the one or more system administrator users, or (c) (I) 1 prepare a third representation of the quality of data stored in a relational database, input it into the first relational database, or both; and (II) create a third representation on a data network associated with one or more system administrator users. relaying to a graphical user interface of one or more other network devices, (III) preparing a fourth expression regarding the quality of the data stored in the second relational database, inputting it to the second relational database, or both, ( IV) relaying the fourth representation to a graphical user interface of one or more other network devices in a data network associated with the one or more system administrator users; and (2) thereafter, if the quality of the data represented by the third representation, the fourth representation, or both indicates a lack of quality of the first relational database data, the second relational database data, or both, one or more of the MAC-DMS memory. and applying one or more modifications to the instruction (Aspect 24).

Additionally provided is a method of any one or more of aspects 15-24, wherein any one or more of the medical devices comprises one or more multi-zone medical devices (MZMAs), each MZMA comprising two or more separate zones; Each zone (1) includes a separate processor that processes at least some of the MA-Ds that have not been processed by the processors of at least one other component; (2) (a) receive information from different sensors, (b) perform different therapeutic or preventive medical operations, or (c) receive information from different sensors and perform different therapeutic or preventive medical operations, or , (d) perform any or all of or any combination of (a)-(c), wherein at least one zone of each MZMZ has different levels of interoperability with at least one other zone of the MZMA and one or more other parts of the data network. It receives action (Mode 25).

Also provided is the method of aspect 25, wherein at least one zone of at least one of the one or more MZMAs is associated with application of a therapeutic medical operation and is not in direct communication with a data network (aspect 26).

Also provided is the method of aspect 25 or aspect 26, wherein at least one zone of the at least one MZMA is (1) associated with the application of a therapeutic medical operation, a preventive operation, or both; (2) communicate with MAC-DMS; (3) Accept only a preset amount of input from the MAC-DMS, and any changes to the operating system, software, or approved forms of the MAC-DMS entered into the zones of at least one MZMA must be approved by at least one MZMA; Requires local approval from the authorized operator (Aspect 27).

Additionally provided is a method of any one or more of aspects 15-27, wherein the MAC-DMS automatically (1) collects the MA-D during a data collection period to form a data collection, and (2) the data collection Evaluate suitability for analysis according to one or more preprogrammed standards; (3) If the data collection is suitable for analysis, add the data collection to the data aggregate, and repeat steps (1)-(3) until at least 10 data collection instances are added to the data aggregate to form a complete data aggregate. and; (4) If an instance of any data collection is determined to be unsuitable before a complete data aggregation is formed, the method includes discarding the incomplete data aggregation and starting the method again; (5) When a complete data aggregate is formed, the method further includes performing one or more analysis functions on the data comprising the complete data aggregate (Aspect 28).

Also provided is a method of any one or more of aspects 15-28, wherein (1) the medical devices in the data network are owned by at least three different, independent entities; (2) at least one user of one or more other network devices is a commercial class user and is legally associated with the owner of the MAC-DMS; (3) analytic data output provided to one or more other network devices associated with one or more commercial class users (a) includes data generated from a collection of medical devices owned by multiple independent entities and (b) MAC-DMS; Exclude one or more classes of independent entity confidential information identified as (aspect 29).

Also provided is a method of any one or more of aspects 15-29, wherein (1) the medical device comprises at least two different medical device types, wherein the medical device type comprises a first medical device that performs one or more pulmonary treatment tasks; type and a second medical device type that performs one or more cardiovascular therapeutic tasks; (2) the method applies a machine learning module to the MA-D received from both the first medical device type and the second medical device type to generate predicted patient-specific physiological parameters related to the therapeutic tasks performed by the medical device; and communicating these predicted patient-specific physiological parameters to one or both medical devices of two different medical device types, another network device, or a combination thereof (aspect 30).

Also provided is a method of any one or more of aspects 15-30, wherein (1) the user class includes one or more study user classes; (2) one or more medical devices in the data network are associated with one or more users of the one or more study user classes; (3) A method wherein (a) the MAC-DMS receives input from at least some of the study user-related medical devices, and (b) the MAC-DMS receives MA-Ds from at least some of the study user-related medical devices to a health care provider. to form a blended data set, and (c) the MAC-DMS comprising performing one or more analysis engine functions based at least in part on the blended data set (aspect 31 ).

Also provided is a method of any one or more of aspects 15-30, wherein (1) the MAC-DMS transmits the MA-D, imposes requirements on the MA-D, or both to Ensure that every MA-D dataset includes medical device source identification information, MA-D type information, and one or more physiological parameter datasets, each of which is presented in a standard preprogrammed MAC-DMS-recognizable format, ( 2) The enhanced data lake includes different data governance zones based on the source or content of the MA-D dataset, analytics data, or both stored therein (Aspect 32).

Also provided is a method of any one or more of aspects 15-32, wherein (1) the one or more output applications include the provision of one or more alarms registered to one or more medical devices, one or more other network devices, or a combination thereof, and (2) ) Triggering parameters, communication parameters, repetition parameters, or a combination of any or all of these for one or more alarms may be set (a) at the local medical device level, at the local other network device level, or both, or (b) at the medical device type. , is set to the MAC-DMS level based on patient type, user type, or a combination of some or all of these, or (c) is set according to both (a) and (b) (aspect 33).

Also provided is a method of aspect 33, wherein (1) the output application(s) comprises (a) one or more output applications regulated as Software as Medical Devices (SaMD/SAMD) by one or more regulatory authorities, and (b) a SaMD. Contains one or more output applications that are not regulated; (2) the method comprises one or more data transformation, data curation processes, and data validation processes to ensure that the one or more SaMD applications comply with one or more regulatory requirements recorded in processor-readable instructions stored in the MAC-DMS memory. Applying test confirmation or a combination of any or all thereof (embodiment 34).

In one aspect, the present invention provides (1) a plurality of remotely controllable, selectively operable, Internet-connected medical devices, each medical device comprising: (a) detecting one or more patient-related physiological conditions; and Sensor(s) that convert information regarding a physiological state into processor-readable medical device data (MA-D), the MA-D comprising an MA-D that conforms to a preset semi-structured data format. s), (b) an output engine for selectively relaying data over secure Internet data communications, (c) a medical device that optionally stores MA-Ds and includes processor-executable instructions for one or more medical device computer-implemented data engines. a device memory component, (d) a medical device processor that executes instructions of the medical device memory component, and (e) (I) automatically and repeatedly checks for the availability of a secure and reliable Internet connection during operation, and (II) a secure and reliable Internet connection. (III) if an Internet connection exists, relay at least a portion of the MA-D to one or more intended recipient Internet-connected systems over such secure and reliable Internet connection; (III) if a secure and reliable Internet connection does not exist, causing at least some of the MA-Ds to be stored as cache MA-Ds in a medical device memory component until an Internet connection is established or reset, and then relaying at least some of the cache MA-Ds to one or more recipient Internet-connected devices or systems. the plurality of medical devices, including a network state engine; and (2) (a) a system processor that reads computer-readable instructions to analyze data and perform functions; (b) automatically and continuously receiving and processing MA-D relayed from the medical device and performing an initial analysis on the received streaming MA-D to determine whether one or more pre-programmed conditions are present in the streaming MA-D; , if one or more of these conditions are present, operates as a controller of the medical device, one or more other network devices, or both by performing one or more of a limited set of preprogrammed initial functions, the initial functions of the one or more medical devices a streaming data processing engine including relaying instructions to control operations; (c) a MAC-DMS comprising processor executable instructions and one or more data data stores, wherein the one or more data stores automatically store at least a portion of the MA-D and have access conditions separate from and different from the MA-D; the MAC-DMS, which additionally stores at least some of the analysis data; (d) an analytics engine that performs one or more analytics functions based at least in part on analytics data stored in the enhanced data lake, either upon user request, upon the occurrence of pre-programmed conditions, or both; (e) a cache MA that analyzes the cache MA-D when received by the medical device and determines whether the cache MA-D should be stored in the MAC-DMS memory component, analyzed by the analysis engine, or both; -D processing engine; and (7) a network device controller (analytical data controller) that relays one or more outputs via secure Internet communications to one or more medical devices, one or more other network computerized devices, or both, wherein the one or more outputs are (I) analytical data outputs; ; (II) (A) the functionality of one or more medical devices on one or more of the medical devices on the data network, (B) the functionality of one or more other network devices on one or more of the other network devices on the data network, or (C) (A) and (B) one or more output applications containing instructions for controlling the operation of both, or (III) a combination of (I) and (II), a machine controller and data, including the network device controller. An Internet-based data network including a management system (MAC-DMS) is provided (Aspect 35).

In a further aspect, the present invention provides (1) providing an Internet-based data network comprising multiple (e.g., ~10 or more) remotely controllable, selectively operable, Internet-connected medical devices, Each device comprises (a) one or more sensors that detect one or more patient-related physiological states and convert information regarding one or more physiological states into processor-readable medical device data (MA-D), wherein the MA-D is one or more sensors, including a MA-D that complies with an established semi-structured data format; (b) an output engine that selectively relays data via secure Internet data communication; (c) optionally stores the MA-D; and (d) a medical device memory component that contains processor-executable instructions for a medical device computer-implemented data engine, (d) a medical device processor that executes the instructions of the medical device memory component, (e) a secure and reliable Internet connection during (I) operation; (II) automatically and repeatedly check the availability of the III) If a secure and stable Internet connection does not exist, ensure that at least some of the MA-Ds are stored as cache MA-Ds in the medical device memory component until a secure and stable Internet connection is established or reset, and then cache MA-Ds. a network state engine that relays at least some of D to one or more recipient Internet-connected devices or systems; and (2) (a) a MAC-DMS processor that reads computer-readable instructions to analyze data and perform functions, (b) automatically and continuously receives and processes MA-D relayed from the medical device, and By performing an initial analysis of the Streaming MA-D to determine whether one or more pre-programmed conditions exist in the Streaming MA-D and, if one or more such conditions exist, by performing one or more of a limited set of pre-programmed initial functions. A streaming data processing engine that operates as a controller of one or more of a medical device, one or more other network devices, or both, and whose initial function includes relaying instructions for controlling the operation of one or more medical devices; (c) a MAC-DMS memory component including one or more MAC-DMS implementation engines and processor-executable instructions for one or more data stores, wherein one or more data lakes are configured such that (I) each data lake management zone manages a different data lake; an enhanced data lake comprising a plurality of data lake management zones associated with zone access rules; the MAC-DMS memory component including (II) a first relational database and (III) a second relational database; (d) one or more one or more MA-D memory acquisition engines that analyze the MA-D based on pre-programmed criteria and log the MA-D to one or more data lake management areas, (e) upon the occurrence of a pre-programmed condition, upon request by a user; , or both, as the case may be, an analytics engine that performs one or more analytics functions based at least in part on analytics data stored in the enhanced data lake; (f) analyzing analysis data based on one or more pre-programmed conditions and based on such pre-programmed conditions (I) analysis data generated directly from the MA-D of a first relational database, (II) a second relational database; analytic data generated from data contained in the enhanced data lake, and (III) an analytic data memory ingestion engine that records the analytic data in one or more data lake management areas of the enhanced data lake, (g) ingested into a first relational database. a data store inspection engine that collects information about the data being stored, the data being collected in a second relational database, or both, and relaying such information to one or more graphical user interfaces accessible by one or more system administrators; and (h) A network device controller that relays one or more outputs via secure Internet communications to one or more medical devices, one or more other networked computerized devices, or both, wherein one or more outputs include (I) analytical data outputs; (II) (A) the functionality of one or more medical devices on one or more of the medical devices on the data network, (B) the functionality of one or more other network devices on one or more of the other network devices on the data network, or (C) (A) and (B) one or more output applications containing instructions for controlling the operation of both, or (III) a combination of (I) and (II), a machine controller and data, including the network device controller. An Internet-based data network including a management system (MAC-DMS) is provided (Aspect 36).

In one aspect, the invention provides a network according to aspect 35 or aspect 36, wherein (1) the one or more data stores further comprise a first relational database, and (2) a method comprising: generating structured dataset data, and (b) storing the first structured dataset data in a first relational database; (3) the one or more data stores include a second relational database, and (4) the system is configured to (a) perform one or more analytics functions on data in the enhanced data lake to obtain analytics data, and (b) optionally Generate second structured dataset data from this analysis data by combining it with data contained in the first relational database, and (c) store the second structured dataset data in the second relational database (aspect 37).

In a further aspect, the invention provides a network according to any one or more of aspects 35-37, wherein any one or more of the medical devices comprises one or more multi-zone medical devices (MZMAs), each MZMA comprising two or more comprising separate zones, each zone (1) comprising a separate processor to process at least some of the MA-Ds that have not been processed by the processors of at least one other component; (2) (a) receive information from different sensors, (b) perform different therapeutic or preventive medical operations, or (c) receive information from different sensors and perform different therapeutic or preventive medical operations, or , (d) adapted to perform any or all of or a combination of (a)-(c), wherein at least one zone of each MZMA is different from at least one other zone of the MZMA and one or more other portions of the data network. Subject to level interaction (Aspect 38).

There is also provided a network according to aspect 38, wherein at least one zone of at least one of the one or more MZMAs is associated with the application of a therapeutic medical operation and is not in direct communication with the data network (aspect 39).

There is also provided a network according to aspect 38 or aspect 39, wherein at least one zone of the at least one MZMA is (1) associated with the application of a therapeutic medical operation, a preventive operation or both; (2) communicate with MAC-DMS; (3) only allow a preset amount of input from MAC-DMS; Changes to the operating system, software, or authorized form of the MAC-DMS entered into a zone of at least one of the at least one MZMA require local approval from an authorized operator of the at least one MZMA (aspect 40).

Also provided is a network according to any one or more of aspects 35-40, wherein the MAC-DMS automatically (1) collects MA-D during a data collection period to form a data collection, and (2) the data collection is one. Evaluate suitability for analysis according to the director's preprogrammed standards; (3) If the data collection is suitable for analysis, add the data collection to the data aggregate, and repeat steps (1)-(3) until at least 10 data collection instances are added to the data aggregate to form a complete data aggregate. and; (4) If an instance of any data collection is determined to be unsuitable before a complete data aggregate is formed, the method includes discarding the incomplete data aggregate and starting the method again; (5) When a complete data aggregate is formed, the method further includes performing one or more analysis functions on the data comprising the complete data aggregate (aspect 41).

Also provided is a network of any one or more of aspects 35-42, wherein: (1) the medical device comprises at least two different medical device types, wherein the medical device type is a first medical device that performs one or more pulmonary treatment tasks; type and a second medical device type that performs one or more cardiovascular therapeutic tasks; (2) the system applies a machine learning module to the MA-D received from both the first medical device type and the second medical device type to generate predicted patient-specific physiological parameters related to the therapeutic tasks performed by the medical device; and adapted to communicate these predicted patient-specific physiological parameters to one or both of two different medical device types, to another network device, or to a combination thereof (aspect 43).

There is also provided a network according to any one or more of aspects 35-43, wherein (1) (a) the other network device(s) or both are associated with one or more classes of research users; (b) one or more medical devices in the data network are associated with one or more users of one or more surveyed user classes; or (c) may relate to both (a) and (b); (2) the MAC-DMS (a) receives input from at least some of the study user-related medical devices, and (b) the MAC-DMS reports the MA-D from at least some of the study user-related medical devices to a health care provider. combined with the MA-D obtained from the medical device to form a blended data set, and (c) the MAC-DMS is adapted to perform one or more analysis engine functions based at least in part on the blended data set (aspect 44).

There is also provided a network according to any one or more of aspects 35-44, wherein (1) the system/MAC-DMS is configured to trigger action of one or more alarms registered to one or more medical devices, one or more other network devices, or a combination thereof; Adapted to generate one or more output applications, (2) the System/MAC-DMS is programmable with respect to alarm triggering parameters, communication parameters, repetition parameters, or a combination of any or all of these, such parameter(s) being ( a) set at the local medical device level, local other network device level, or both; (b) medical device type, patient type, user type, or a combination of any or all of these; or (c) (a) and (b) ) can be set according to both (aspect 45).

There is also provided a network according to any one or more of aspects 35-45, wherein (1) the one or more output applications are: (a) one or more output applications that are regulated as Software as Medical Devices (SaMD/SAMD) by one or more regulatory authorities; and (b) contains one or more output applications that are not regulated by SaMD; (2) The System/MAC-DMS performs one or more data transformation, data curation processes, and Adapted to apply validation checks or a combination of any or all of these (embodiment 46).

In another aspect, the present invention relates to (1) a high security zone comprising a collection of directly interoperable high security zone components, wherein the high security zone (a) operates to apply medical treatment to a patient and receive electronic control; (b) one or more therapeutic components controllable via instructions, (b) a high security zone memory component comprising a computer-readable medium containing instructions for a plurality of computer implemented instructions that control the operation of one or more high security zone components, (c) ) a high security zone computer processor component, (d) (I) ( A) receives electronic communications from at least one medium security zone component and (B) a local physical input, and (II) ensures that only communications that comply with one or more validation standards are permitted to control the operation of one or more high security zone components. (III) a high security zone communication component that relays electronic communications to (A) at least one medium security zone component and (B) a local medical device output, ( e) comprising a physical anti-tampering system that limits access to the high security area memory components to only authorized users; (f) the high security area has no direct Internet communication capability; and (2) a medium security zone comprising a second collection of interoperable components, wherein the medium security zone component is configured to: (a) (I) the performance of one or more treatment components in the high security zone, (II) one of the patients involved; one or more physiological conditions, or (III) one or more physical conditions of both (I) and (II), as medical device data (MA-D), and converting such measurements into electronically transmittable data; a sensor, (b) (I) a computer readable medium containing instructions for a plurality of computer implemented instructions to control the operation of one or more medium security area components, and (II) a medium security area component for storage of the MA-D. an intermediate security zone memory component, including (c) a network state engine that evaluates whether (I) a secure and reliable Internet gathering is possible; and (A) if such a connection is possible, (i) MA-D to one or more intended Internet recipients; (ii) receive relayed commands from one or more remote control devices via secure Internet communications, or (B) if such a connection is not possible, store the MA-D as cache data in the middle zone secure memory component; (II) a medium-secure zone computer processor component that executes computer-implemented instructions contained in a network state engine, and (II) a medium-secure zone memory component, including a device-to-device communication engine that receives data from the therapeutic component and sends electronic instructions to the therapeutic component. (Aspect 47).

There is also provided a medical device according to aspect 47, wherein the device is configured to: (aspect 48).

Also provided is a medical device according to aspect 48, wherein the operating system of the high security computer processor component is configured to be modified only by a user with physical access to the high security computer processor component (aspect 49).

In another aspect, the present invention relates to (1) a plurality of individually located and at least partially remotely controllable medical devices (MAs) in substantially continuous communication with a network data system (NDS), wherein the MAs are connected to a plurality of (e.g. (e.g., at least five) under the physical control of a separate, independent entity (IE), each MA in the system comprising: (a) at least one sensor that, when activated, detects the patient's condition; (b) device computer-executable instructions; (CEI) and device memory, including physical, transportable, and reproducible computer-readable media (PTRCRM) containing records containing sensor information collected over time; (c) a device computer processing component for reading the CEI from the device memory, (d) a device display unit, (e) a device information (MA-D) capable of including sensor information from the MA to the NDS via the Internet in operation. A device data relay unit that transmits, when in operation, the MA-D relayed by the MA relay unit can be used for real-time sensor data (RT-MA-D), stored sensor data (MA-CD), or RT-MA-D and MA- Containing both a CD, the MA-D includes a device data relay unit, (f) a device data input unit, containing both structured and unstructured data, and (g) optionally, when activated, one or more data protection functions (e.g. a device data security system optionally comprising at least one microcontroller that performs the following steps: (e.g., restricting data input to only data that is specifically identified data of an approved data type); (2) a network data system (NDS or system) and (2) at least one searchable data store that receives and stores (1) (A) semi-unstructured MA data (SUMAD) and (B) a function to be retrieved by the NDS; an NDS memory unit containing an NDS PTRCRM containing an NDS CEI (NCEI) encoding instructions for; (2) NDS processing function that executes NDS CEI, (3) automatically receives data from MAs communicating with NDS, and determines whether the MA-D received from each MA is RT-MA-D, MA-CD, or both. (4) an NDS data entry unit that determines diecognition, (4) an NDS analysis unit that analyzes RT-MA-D, MA-CD, and SUMAD to generate an analysis and applies that analysis to the performance of one or more NDS functions, ( 5) optionally an NDS Device Data Harmonization Unit, ( 6) NDS output processing system that automatically filters the MA-D, analysis, or both for delivery to each MA and other network device (OND) in the data network based on confidentiality rules, healthcare compliance rules, or both, (7) Via the Internet, (A) information about each MA specific to the MA, the patient involved, or both, and (B) information containing the MA-D, analysis, or both, to one or more other network devices/interfaces (OND or ONDI)I An NDS data relay unit relayed to an NDS, wherein the information relayed to ONDI includes information from a plurality of MAs associated with an IE or information derived from MA-Ds received from a plurality of MAs associated with two or more IEs. A data network is provided (aspect 50), including a data relay unit, and (8) an NDS analysis unit that generates analysis (analysis data) based on the application of one or more schemas to SUMAD.

One aspect is a network according to aspect 50, wherein the NDS has an engine/unit that detects the amount (demand) of incoming data and automatically increases NDS processor power when the amount of incoming data meets or exceeds a preprogrammed threshold. Includes (embodiment 51).

A further aspect is a network according to aspect 50 or aspect 51, wherein in operation the NDS relay unit continuously transmits NDS status information to the MA in the acceptable network to the MA security unit in the MA (aspect 52).

Another aspect is a network according to any one or more of aspects 50-52, wherein the MA CEI of the MA is such that the MA does not receive an indication that the NDS is operational until the MA receives an indication that the NDS is operational. Contains an instruction to save -D as MA-CD (Aspect 53).

A further aspect is a network according to any one or more of aspects 50-53, wherein the NDS includes functions for identifying past, current and expected MA-Ds, and the NDS analysis unit provides at least one prediction function based on the analysis. perform and propagate the results of the prediction function to the MA, OND, or both (embodiment 54).

One aspect is a network according to any one or more of aspects 50-54, wherein the NDS analysis unit has at least one function regulated as a software as a medical device (SAMD) and at least one other non-SAMD function (NSAMD). The system communicates the output of at least one SAMD and at least one NSAMD function to the MA according to a CEI that reflects the applicable regulatory status of the SAMD and NSAMD function (Embodiment 55).

A further aspect is a network according to aspect 55, wherein at least one SAMD comprises providing diagnostic guidance or treatment guidance to an HCP (aspect 56).

A further aspect is a network according to aspect 55 or aspect 56, wherein at least one SAMD is capable of changing the operating conditions of the MA in response to condition(s) (aspect 57).

A further aspect is a network according to any one or more of aspects 50-57, wherein the OND supports a system owner (SO) passing MA-D, analysis (NDS-AD), or both to a SO associated network access device (SOANAD). Includes SOSS (Aspect 58).

A further aspect is a network according to aspect 58, where SOSS combines MA-D, NDS-AD or both with data from a customer relationship management support system (CRMSS) (aspect 59).

A further aspect is the network according to aspect 59, wherein the ONDI/NDS users include sales representatives who sell/rent network MAs to SOs (aspect 60).

A further aspect is a network according to any one or more of aspects 50-60, wherein the network receives or delivers MA-D, analyzes or a combination thereof to an ONDI associated with a Scientific Researcher (SR) Associated Network Access Device (SRANAD). , one or more research platform(s) (RP(s)) that communicate to the MA or both (embodiment 61).

A further aspect is a network according to any one or more of aspects 50-61, wherein the MA-D includes information about the operational state of the MA-D, and the NDS analysis unit provides the operational state information of the MA-D in the analysis process. Evaluate (Aspect 62).

A further aspect is a network according to any one or more of aspects 50-62, wherein the MA comprises two or more heterogeneous types of MA, and the NDS determines the MA device type prior to relaying the NDS analysis or NDS output application. Aspect 63).

A further aspect is a network according to any one or more of aspects 50-63, wherein at least a majority of the MAs are related to supporting or treating important life support functions, such as the cardiovascular system, lungs, brain or kidneys (aspects 64).

A further aspect is a network according to any one or more of aspects 50-64, wherein the NDS analyzes MA-Ds from heterogeneous MAs and performs or functions one or more functions of the NDS based on the analysis of the heterogeneous MA MA-Ds. Includes a machine learning module (MLM) that recommends performance (Aspect 65).

A further aspect is a network according to any one or more of aspects 50-65, wherein the NDS has the ability to write MA-D, analysis (analysis data output based on the MA-D analysis), or both directly to the electronic health record. Contains a module (Aspect 66).

A further aspect is a network according to any one or more of aspects 50-66, wherein the data permitted to be transmitted from the NDS relay unit to the MA input unit/MA is essentially biometric predictive data, guidance provision or MA control, NDS status, It consists of a MA software version status or a combination thereof (CT) (mode 67).

A further aspect is a network according to aspect 67, wherein the data permitted to be transferred from the NDS to the MA includes MA software version status, but the MA, the System/NDS, or both prevent updating the MA software over the Internet, and optionally: Allow updates in response to a locally initiated pull command from the MA (Aspect 68).

One aspect is a network according to any one or more of aspects 50-68, wherein the MA-D includes location information and the NDS is connected to at least two classes of ONDI based on facility, metropolitan area, state/region, country, or IE. Information is relayed simultaneously (Aspect 69).

A further aspect is a network according to any one or more of aspects 50-69, wherein the MA receives input from one or more research teams, a plurality of IEs using the MA in clinical applications, or both (aspect 70).

A further aspect is a network according to any one or more of aspects 50-70, wherein the NDS is an independent research team member, a system owner device sales or rental promotional agent, an IE user or administrator, a system owner clinical or medical support team member, and The MA-D, analysis, or both are delivered in a plurality of graphical user interfaces (ONDI) based at least in part on user roles, including the system owner system analyst (aspect 71).

A further aspect is a network according to any one or more of aspects 50-71, wherein the NDS CEI includes one or more alarm conditions coupled to sensor data, and the NDS (e.g., NDS analysis unit) has one or more alarm conditions connected to the MA. -D, determines whether the alarm is triggered by MA-D analysis (analysis/NDS-AD) or both, and NDS allows alarms to be registered with MA, user-specific OND, or both based on sensor data and user options (Aspect 72).

A further aspect is a network according to any one or more of aspects 50-72, wherein the MA has an anti-tampering detection component that sends a signal to the NDS, OND, or both, for example, when a prohibited tampering event occurs. s)/function(s) (embodiment 73).

A further aspect is a network according to any one or more of aspects 50-73, wherein the MA-D includes image and non-image sensor data from the MA, the MA environment, or both (aspect 74).

A further aspect is a network according to any one or more of aspects 50-74, wherein the NDS memory is (a) RT-MA-D, MA-CD, or both; (b) curated data, scored data, or both; (c) system test data; (d) outgoing data; or (d) comprises two or more separate governance areas that manage the storage, use and access of any or all combinations thereof (Embodiment 75).

A further aspect is a network according to any one or more of aspects 50-75, wherein the NDS includes (a) data for MAs in a particular country, (b) country-specific data governance rules, and (c) other NDS(s). Contains shared system blueprint data (aspect 76).

A further aspect is a network according to any one or more of aspects 50-76, wherein the MA relay packet includes sequencing information, and the NDS analyzes the temporal component of the MA-CD and re-sequences the non-chronologically received MA-D. Includes a unit/function that does (Aspect 77).

A further aspect is a network according to any one or more of aspects 50-77, wherein one or more functions/units of the NDS comprise at least about 20, 30, or 60 seconds of MA-D per repetition (e.g., 20-200 Every second, every 30-180 seconds or every 45-90 seconds) based on MA-D processing, NDS at least every 2, 3, 5 seconds (e.g. every 2-10 seconds, 2-6 data validation rule process based on NDS receiving at least 5, 8, or at least 10 packets from MA to MA-D (every second, every 3-9 seconds, every 4-8 seconds, or every 3-8 seconds) and the NDS restarts the iteration if any validation rule violation occurs (Aspect 78).

A further aspect is a network according to any one or more of aspects 50-78, wherein each cycle of MA-D collected by the NDS for each MA when forming a data collection for analysis is a network of data packets from the MA to the NDS. At least about 100 times, at least about 250 times, at least about 500 times, or at least about 1,000 times longer than each cycle of transmission (Aspect 79).

A further aspect is a network according to any one or more of aspects 50-79, wherein the NDS can detect MAs that are in a non-clinical mode of operation and use this capability for enhanced scalability testing (aspect 80).

In one aspect, the invention provides a network as described in any one or more of aspects 50-80, wherein at least some of the MAs in the network at least some of the time when operating are compliant with a wireless communication protocol (e.g., Wi- It is a mobile MA that transmits the RT-MA-D to the NDS via and the ability to collect and relay stored cached data when the communication channel is again available (aspect 81).

A further aspect is a network according to any one or more of aspects 50-81, wherein at least some, but not all, of the MAs in the network provide treatment to one or more critical life support systems (e.g., respiratory, cardiovascular, or neurological). A MA that provides (Embodiment 82).

In one aspect, the invention provides a network as described in any one or more of aspects 50-82, wherein at least some MAs of the network include at least two separate components to which separate security zones/rules apply. (Aspect 83).

In one aspect, the invention provides a network as described in aspect 83, wherein at least some of the multi-zone MAs (MZMAs) include very limited therapeutic application components that provide critical life support system treatment functions, and wherein It includes anti-purring protection and includes a MA CEI that is only locally modifiable (aspect 84).

In one aspect, the invention provides a network as described in aspect 83 or aspect 84, wherein at least some of the MAs in the network include a patient monitoring component that includes a processing unit capable of receiving system update availability, but the NDS Also includes the MA CEI, which can only be modified through a pull request for (Aspect 85).

In one aspect, the invention provides a system according to any one or more of aspects 50-85, wherein the system is configured to: a streaming data processor that performs limited initial analysis (e.g., limited by analysis on a set number of rules/data points) via controller(s)/alarms, etc. (aspect 86).

Also provided is a method for managing a plurality of medical devices in real-time on a device data network, (1) in substantially continuous communication with a network data system (NDS), optionally with at least five separate independent entities (IEs); Accessing a plurality of separately located and at least partially remotely controllable medical devices (“MAs”) under physical control, wherein each MA of the system includes (a) at least one sensor that, when activated, detects the condition of the patient; (b) a device memory including PTRCRM containing device computer executable instructions and a device memory (DM) that records information including time-dependent sensor information during operation; (c) a device processor that reads/executes the MA CEI, (d) a device display unit, (e) that in operation transmits device information (MA-D), which may include sensor information, from the MA to the NDS via the Internet. As a device data relay unit, most of the MA-Ds relayed by the MA in operation are real-time sensor data (RT-MA-D), stored/cache sensor data (MA-CD), or RT-MA-D and MA-D. a device data relay unit, (f) a device data input unit (MA-INPU), and (g) a data input, including both CD data (MA-CD), where MA-D includes both structured and unstructured data. Comprising an optional device data security system, optionally including at least one component (e.g., a microcontroller) that performs one or more data protection functions including restricting data to only specifically identified data of approved data types. , the accessing step; and (2) a medical device network data management system comprising (I) an NDS input unit/engine that automatically receives system acceptance data relayed to the NDS, and (II) storing the received data in an NDS memory that includes a PTRCRM. (3) (III) stored instructions/CEI contained in the NDS memory (e.g., based on analysis of the received MA-D); and (IV) an NDS relay unit/engine that communicates new data, output functions (e.g., MA control instructions), or both to a network device (e.g., MA). NDS memory includes one or more queryable/searchable data stores (e.g. a data lake or enhanced data lake), in both cases at least partially compliant with pre-established standards. The MA-D processing speed is increased by receiving and storing semi-unstructured MA data (SUMAD) in a format (Aspect 87).

Another aspect is the method of aspect 87, wherein the NDS automatically performs an initial analysis on the received MA-D and an analysis unit for analyzing the data stored in the NDS after the analysis of the MA-D and stored (collected) therein. It includes an engine/unit that performs one or more functions based on instructions for controlling the operation of , less than 3 minutes, less than 2 minutes, less than 1 minute, or less than 0.5 minutes), and any or all combinations thereof (Embodiment 88).

One aspect is the method of aspect 87 or aspect 88, wherein the NDS evaluates whether the RT-MA-D of the MA-D is in an acceptable format for analysis by the NDS analysis unit prior to analyzing the data, and if so prior to analysis, determines whether the RT-MA-D is in an acceptable format for analysis by the NDS analysis unit. A device data reconciliation unit/engine that selectively modifies data (aspect 89).

One aspect is a method according to any one or more of aspects 87-89, wherein the NDS is pre-programmed and based on programmable confidentiality or healthcare compliance rules to convey MA-D, analysis data to the MA(s) or ONDI. , an output filtering/routing engine/unit that automatically tags/filters output applications or a combination thereof, and the NDS provides information to different MAs, ONDI, or both based on the most recently received MA-D. It relays at the same time, but does not transmit the same information to either the MA or ONDI connected through the network (Mode 90).

One aspect is a method according to aspect 90, wherein the NDS is adapted to recognize an MA-D and an associated entity identifying each authorized MA and an ONDI delivering data to or receiving data from the NDS, thereby allowing the entity to Confidential information belonging to may be protected from being disclosed to MA/ONDI relative to other independent entities accessing the network (aspect 91).

One aspect is a method according to any one or more of aspects 87-91, wherein the NDS includes an engine/unit that identifies MA-CDs (cache data) relayed from the MA, and stores such MA-CDs in the NDS memory. used by an analysis unit, combined with RT-MA-D, or a combination of any or all thereof (embodiment 92).

One aspect is a method according to any one or more of aspects 87-92, wherein the NDS comprises a unit that automatically screens the MA-D or causes the MA-D to comply with one or more schemas during data analysis, data storage, or both. /Includes engine (Aspect 93).

One aspect is a method according to any one or more of aspects 87-93, wherein most, generally all or all MAs are units/that assess the existence of a secure/stable communication channel for relaying the MA-D to the NDS. These MAs collect MA-Ds into cache MA-Ds (MA-CDs) and then relay these cache MA-Ds to the NDS, if such a channel does not exist, until this connection is re-established. Do it (Yangtae 94).

A further aspect is a method according to aspect 94, wherein the NDS includes a unit/engine automatically and periodically/continuously transmitting NDS status information to a MA in the network, wherein the MA collects the MA-D when no signal is received. and a CEI that relays this collected cache MA-D whenever a signal is next received (aspect 95).

Another aspect is a method according to any one or more of aspects 87-95, wherein the NDS includes an engine/unit that identifies past, current and expected MA-D, and wherein the NDS analysis unit determines at least based on the MA-D analysis. Performs a prediction function and propagates the results of the prediction function to MA, OND, or both (mode 96).

A further aspect is a method according to any one or more of aspects 87-96, wherein the NDS performs at least one function regulated as a software as a medical device (SAMD) and at least one other non-SAMD function (NSAMD). , the NDS/System communicates the output of at least one SAMD and at least one NSAMD function to the MA according to a CEI that reflects the applicable regulatory status of the SAMD and NSAMD functions (aspect 97).

In another aspect, the invention provides a method as described in aspect 97, wherein at least one SAMD includes providing diagnostic instructions or treatment instructions to a HCP (aspect 98).

In another aspect, a method as described in aspect 97 or aspect 98 of the present invention is provided, wherein the at least one SAMD modifies the operating conditions of the MA in response to the condition(s) reflected in the MA-D or analysis ( aspect 99).

A further aspect is a method according to any one or more of aspects 89-99, wherein ONDI includes a System Owner (SO) Support System (SOSS) that forwards MA-D, analysis, or both to SOANAD (aspect 100). .

In one aspect, the invention provides a method as described in aspect 100, wherein SOSS combines MA-D, analysis, or both with data from CRMS (aspect 101).

In a further aspect, the invention provides a method as described in aspect 101, wherein the user includes a sales representative who sells or leases the device on behalf of the system owner (aspect 102).

In another aspect, the invention provides a method as described in any one or more of aspects 87-102, wherein the network comprises a research platform comprising a MA or OND associated scientific researcher (SR) associated network access device (SRANAD). (RP), SR is not associated with SO and data received from SRANAD is used for at least some analysis functions (aspect 103).

In another aspect, the invention provides a method as described in any one or more of aspects 87-103, wherein the MA-D includes information about the operational state of the MA-D, and the NDS performs analysis and delivers output. or both, evaluate MA operational status information (aspect 104).

In another aspect, the invention provides a method as described in any one or more of aspects 87-104, wherein the MA comprises two or more heterogeneous types of MA, and the NDS performs analysis, relays output, or both. Determine the device type of each MA before proceeding (Aspect 105).

A further aspect is a method according to any one or more of aspects 87-105, wherein at least a majority of the MAs in the network are associated with important life-sustaining functions, such as the cardiovascular system, lungs, brain or kidneys (aspect 106).

In one aspect, the invention provides a method as described in any one of aspects 87-106, wherein the NDS analyzes MA-D from a heterogeneous type of MA and determines the NDS based on the analysis of the heterogeneous MA MA-D. A machine learning module (MLM) that performs or recommends performing one or more functions (aspect 107).

A further aspect is a method according to any one or more of aspects 87-106, wherein the NDS includes a functional module capable of writing MA-D, analysis, or both directly to the EHR/EMR (aspect 108).

A further aspect is a method according to any one or more of aspects 87-108, wherein the DM is adapted to receive input only from the MA (aspect 109).

In another aspect, the invention provides a method as described in any one or more of aspects 87-109, wherein the data permitted to be transmitted from the NDS to at least some of the MA is essentially biometric predictive data, guidance provision, or MA. Consists of control, NDS status, MA software version status, or a combination thereof (aspect 110).

In one aspect, the invention provides a method as described in aspect 110, wherein the data permitted to be transmitted from the NDS includes MD software version status, but where the system/NDS, MA, or both are connected to the MA software over the Internet. Prevent updates (e.g., information that results in an alarm or indicator that a manual/local update of the MA software is needed, a pull signal for a software update being invoked, etc.) (aspect 111).

A further aspect is a method according to any one or more of aspects 87-111, wherein MA-D comprises location information and NDS comprises at least two classes of entities based on facility, metropolitan area, state/region, country, or independent entity association. Information is simultaneously relayed to ONDI (Mode 112).

A further aspect is a method according to any one or more of aspects 87-112, wherein the NDS receives input from one or more research teams, a plurality of IEs using the MA in clinical application, or both, and separately identifies/identifies such data. Tag and use such data in at least some analysis operations (aspect 113).

A further aspect is a system according to any one or more of aspects 87-113, wherein the NDS includes MA-D to a plurality of GUIs of MA/OND including a plurality of GUI schemes/display types based at least in part on user role Delivers analysis or both; these user roles include independent research team members, System Owner device sales or rental promotional agents, IE users or administrators, System Owner clinical or medical support team personnel, and System Owner system analysts (aspects 114).

In another aspect, the invention provides a method as described in any one or more of aspects 87-114, wherein the NDS CEI is based on the presence of one or more alarm triggering conditions in the MA-D, the assay, or both. and instructions to cause one or more alarms to be registered at the MA, OND, or both, such conditions being programmable at the NDS level, the MA/OND level, or both (aspect 115).

In one aspect, a method as described in any one or more of aspects 87-115 is provided, wherein some, most or all MAs are configured to prevent tampering by signaling the NDS when prohibited tampering occurs in the MA. Includes detection function.

In one aspect, the present invention provides a method as described in any one or more of aspects 87-116, wherein the MA-D is a MA (MA component/screen, etc.), an MA environment, or both image and non-image Includes sensor data (aspect 117).

In another aspect, the invention provides a method as described in any one or more of aspects 87-117, wherein NDS memory or a component thereof (e.g., data lake/enhanced data lake) comprises, for example (a) ) MA-D or both; (b) curated data, scored data, or both; (c) system test data; (d) outgoing data/output; or (e) a separate governance area that governs the storage, use, and access of any or all combinations of (a)-(d) (Embodiment 118).

In one aspect, a method as described in any one or more of aspects 87-118 is provided, wherein the NDS includes (a) data for a country's MD, (b) country-specific data governance rules, and (c) optional and system operations/blueprint instructions/engine(s) that are shared with one or more other NDSs, such as sharing resources (Aspect 119).

In another aspect, the invention provides a method as described in any one or more of aspects 87-119, wherein the MA relay packet includes sequencing information, and the NDS analyzes the temporal component of the MA-CD and provides a non-chronological sequence. and an engine/unit (performing the function) for re-sequencing the received MA-CD (aspect 120).

In another aspect, the invention provides a method as described in any one or more of aspects 87-120, wherein one or more NDS functions are performed at least 20 seconds, 30 seconds, 40 seconds, 60 seconds, 90 seconds, per repetition. A collection of MA-Ds for 120 or 180 seconds of MA-D (e.g., 30-300 seconds of data, 40-120 seconds of data, or 25-100 seconds of data) and whether they are suitable for use in analyzes such as MLM analysis. It is based on the analysis of these vowel(s) to determine (Mode 121).

In another aspect, the invention provides a method according to any one or more of aspects 87-121, wherein the NDS is maintained for a set period of time (e.g., every 1-10 seconds, every 2-12 seconds, 2-8 seconds). expected amount of data packets received (e.g., 2-100, 5-100, 5-75, 5-80, 5-50, every 3-6 seconds or ~5 seconds) Data collection process/engine based on collection of 5-25 or 5-80 MA-D packets), NDS optionally collects before collection is complete to comply with data fulfillment requirements/content rules , and the NDS restarts data collection if any validation rule violations occur (Mode 122).

In another aspect, the invention provides a method as described in aspect 121 or aspect 122, wherein the MA-D acquisition cycle for MA-D acquisition analysis is such that the NDS relays the output to the MA, ONDI, or both, or is at least about 100 times, at least about 250 times, at least about 500 times, or at least about 1,000 times longer than at least one period of time for relaying the MA-D to the NDS (Embodiment 123).

A further aspect is a method according to any one or more of aspects 87-123, wherein the NDS is capable of detecting MA in a non-clinical mode of operation (aspect 124).

A further aspect is a method according to aspect 124, wherein the method includes performing a network scalability test for a non-clinical mode of operation MA prior to integrating such MA into a network (aspect 125).

In one aspect, the invention provides a method as described in any one or more of aspects 87-125, wherein at least some of the MAs, at least some of the time during operation, connect the RT-MA-D to the NDS by a wireless communication protocol. It is a mobile MA that transmits to (Mode 126).

In another aspect, the invention provides a method as described in any one or more of aspects 87-126, wherein at least some of the MAs include two or more components to which separate security zones apply (aspect 127). .

In another aspect, the invention provides a method as described in aspect 127, wherein at least some of the MA includes very limited therapeutic application components that provide critical life support system treatment functions, and includes physical anti-tampering protection. and includes a locally modifiable MA CEI (embodiment 128).

In one aspect, the invention provides a method as described in any one or more of aspects 87-128, wherein at least some of the MAs include a patient monitoring component including a processing unit capable of receiving system update availability. However, it also includes a MA CEI that can only be modified through a pull request sent to NDS (Aspect 129).

Another aspect is a method of performing a method according to any one or more of aspects 87-129, wherein the method performs an initial analysis on incoming data received by an engine/unit of the NDS (e.g., streaming data processor). and causing the control component/unit to communicate one or more actions to the MA, ONDI, or both based on the initial analysis, wherein the initial analysis is such that the MA-D is fully integrated into the NDS memory data store, such as an enhanced data lake. Occurs before collection (Mode 130).

A further aspect of the present invention is a medical device and control system comprising: (1) access to a plurality (e.g., 25 or more, 50 or ~100 or more) of remotely controllable, Internet-connectable medical devices (MAs); wherein the MA(s) include (I) subject sensor means for detecting subject data and sensor data conversion means for converting the sensor data into Internet transmittable data (MA-D) and optionally performing therapeutic operations; , said access; (II) a means for streaming semi-unstructured MA-D in a substantially continuous manner via secure Internet data communications when in operation or online; (III) means for collecting cached MA-D and storing electronic data; means for storing such MA-D in a means (MA memory), (IV) means for detecting the state of communication between the MA and the network; and (V) means for relaying the cached MA-D upon the occurrence of preprogrammed condition(s) or event(s); (2) (I) a means for storing data and applying EDL-compatible data input collection processes, including an enhanced data lake (EDL) architecture, (II) processing streaming and cached MA data, and storing MAC-DMS data; means for massively parallel processing to perform automated and on-demand secondary analyzes on data stored in the means, (III) means for MAC-DMS data storage to generate analysis data, instructions for output applications performed on the MA, or both; an NDS (e.g., MAC-DMS) comprising analytical processing means for analyzing the data, and (IV) means for relaying the analytical data, output applications, or both; and (3) multiple (e.g., at least 10, at least 20, or at least 100) ONDs/ONDIs, each including processor means and display means, each and such user classes having (I) MA and Includes (II) HCPs who are authorized to interact and access PHI and (II) commercial users who do not interact directly with the MA and are subject to restrictions on receiving PHI; The output application controls the operation of one or more functions of the MA and simultaneously and separately relays analysis data output based on the analysis of the MA-D to at least some of the ONDs associated with commercial class users (aspect 131).

Additional aspects including means or steps for performing a function

Some aspects of the invention are described in relation to (1) a function and (2) “means” of a system/device(s) or “steps” of a method for performing the function, including any means or steps depicted therein. It is explained to the effect that equivalents in the art are included. To assist the reader, illustrative descriptions or reference(s) are provided herein to support selected means/steps for performing the functions, but additional assistance for various means/steps for performing the functions is provided elsewhere herein. It will be recognized that it will happen.

For example, means for detecting the physiological state of a subject (steps for collecting sensor data) are provided, for example, in paragraphs [0139] - [0144]. Means for assessing whether an appropriate/appropriate data connection is available are described, for example, in paragraph [0160]. Data input means/input means/input stage (means for receiving data) can be, for example, paragraphs [0254] - [0286] (focusing on NDS input units/methods) and paragraph [0169] (MA input units ( It is explained in (with emphasis on). Steps/means for relaying/transmitting data are for example paragraphs [0158] - [0168] (focusing on MA relay units/methods) and paragraphs [0326] - [0337] (focusing on NDS relay units/methods) is provided). means of improving data; Means/steps for improving the data are provided for example in paragraphs [0320] [0307] - [0328].

Means/steps for reading/interpreting the CEI/code and data can be found, for example, in paragraphs [0153] - [0157] (focusing on MA processors) and paragraphs [0234] - [0250] (focusing on NDS processors). ) is provided. Means/steps for analyzing system data (e.g., MA-D) are provided, for example, in paragraphs [0293] - [0306] and paragraphs [0369] - [0389]. Means/steps for analyzing cache data and combining it with RT-MAD are provided, for example, in paragraphs [0260] - [0271], etc.

memory means; Means/steps for storing data are provided, for example, in paragraph [0152] (focusing on MA memory) and paragraphs [0199] - [0233] (focusing on NDS memory). EDL and DL can be considered means/steps for storing unstructured or semi-unstructured data. A means for recording SUMAD, such as a JSON file format, is provided, for example, in paragraph [0234] or paragraph [0259] or paragraph [0361]. Means for processing the data stream (steps for processing streaming data) are provided, for example, in paragraphs [0278] - [0280], paragraph [0292] or paragraph [0364] or paragraph [0367].

Means/steps for protecting the confidentiality of information (e.g., using the encryption methods disclosed herein and equivalent methods), means for restricting incoming data (e.g., using firewalls described herein and equivalents), and Descriptions/support for means/steps of other functions such as the same are also provided herein.

Claims (16)

A computer-implemented method for controlling the operation of medical devices and other devices in a data network, comprising:
(1) Providing a data network, wherein the data network includes:
(a) at least ten remote-controllable, selectively operable, Internet-connected medical devices, each of the at least ten medical devices comprising: (I) processor-readable medical device information regarding one or more physiological states; One or more sensors for detecting one or more patient-related physiological states of any patient operably associated with the medical device, converting data (MA-D) to data (MA-D) that conforms to a preset semi-structured data format. said one or more sensors, including a MA-D; (II) an output engine for selectively relaying data via secure Internet data communication; (III) selectively storing the MA-D and analyzing and relaying the MA-D; , a medical device memory component comprising processor-executable instructions for evaluating the connection between the medical device and the network, and (IV) a medical device processor executing the instructions of the medical device memory component. Device,
(b) a medical device controller and data management system (“MAC-DMS”), comprising (I) a MAC-DMS processor that reads computer-readable instructions to analyze data and perform one or more functions, and (II) processing streaming data; A MAC-DMS memory component including an engine, (III) a cache MA-D processing engine, (IV) an analysis engine, and (V) processor executable instructions and one or more data stores, wherein the one or more data stores are accessed differently from each other. the MAC-DMS, comprising the MAC-DMS memory component, comprising an enhanced data lake for storing at least a portion of the MA-D and at least a portion of the analysis data, respectively, under conditions; and
(c) at least three different network devices, each different network device comprising (I) (A) a processor, (B) a memory component, and (C) a remotely controllable graphical user interface, and (II) at least one associated with a user assigned to a user class, wherein the user class includes (A) a healthcare provider authorized to access patient protected health information and (B) a commercial user restricted from receiving patient protected health information; The providing step, comprising three different network devices;
(2) causing each medical device in operation to repeatedly collect sensor data from the patient associated with the medical device;
(3) allowing each operating medical device to automatically and repeatedly evaluate whether a secure network connection is possible, and
(a) automatically relaying data containing MA-D to said MAC-DMS in a substantially continuous manner via secure Internet data communications, if a secure and reliable network connection is available; or
(b) if a secure and reliable network connection is not available, (I) store the MA-D as a cache MA-D in said medical device memory component until a secure and reliable network connection is available; and (II) relaying the cache MA-D to the MAC-DMS through secure Internet data communication when a stable network connection is available;
(4) causing the MAC-DMS processor to automatically use the streaming data processing engine,
(a) receiving the relayed streaming MA-D,
(b) perform an initial analysis on the relayed streaming MA-D,
(c) if said initial analysis identifies one or more pre-programmed conditions in said streaming relay MA-D, perform one or more of a limited set of pre-programmed initial functions, wherein said initial functions include: comprising relaying instructions to control the operation of a network device, or both;
(5) The MAC-DMS processor uses the cache MA-D processor,
(a) receive cache MA-D when it is relayed from a medical device to the MAC-DMS,
(b) determining whether the received cache MA-D is suitable for analysis by the analysis engine, storage in at least one of the one or more data stores, or both;
(6) causing the MAC-DMS processor to automatically store at least a portion of the MA-D in the enhanced data lake;
(7) the MAC-DMS processor uses the analysis engine to perform one or more analysis functions on MA-D stored in the enhanced data lake upon user request, upon occurrence of pre-programmed conditions, or both; steps to be performed;
(8) causing the MAC-DMS processor to relay one or more outputs via secure Internet communication to one or more medical devices, one or more other network devices, or both, wherein the one or more outputs are:
(a) Analysis data output,
(b) (I) one or more medical device functions in one or more of said medical devices in said data network, (II) one or more other network device functions in one or more of said other network devices in said data network, or ( III) one or more output applications containing instructions that control the operation of both (I) and (II), or
(c) A method comprising the step of relaying, comprising a combination of (a) and (b). 2. The method of claim 1, wherein the method comprises evaluating whether a received cache MA-D of a medical device is combinable with a received streaming MA-D of the same medical device, and wherein the MAC-DMS determines whether the cache MA-D When determining that D and streaming MA-D are combinable, combining the streaming MA-D and the cache MA-D to form a mixed MA-D data set, wherein the MA analyzed by the analysis engine -D contains the mixed MA-D data set, method. According to paragraph 1,
(1) The one or more output applications include:
(a) one or more therapeutic operations performed by a particular medical device,
(b) one or more preventive actions performed by a particular medical device, or
(c) medical device-specific instructions for controlling both one or more therapeutic operations and one or more preventive operations performed by said particular medical device;
(2) the particular medical device receives, interprets, and executes the one or more output applications;
(3) The method wherein the particular medical device changes one or more conditions of patient care based on the one or more output applications received. The method of claim 1, wherein creating the one or more output applications comprises:
(1) for display on a graphical user interface of one or more medical devices,
(a) one or more recommended medical instructions;
(b) analytics data associated with a medical device, a patient, or both, wherein the analytics data includes protected patient health information, or
(c) generating a first representation comprising both (a) and (b);
(2) relaying the first representation to the one or more medical devices for display in one or more graphical user interfaces;
(3) generating a second representation comprising the analysis data completely free of any patient protected health information for display in a graphical user interface of one or more other network devices; and
(4) relaying the second representation to one or more other network devices for display on one or more graphical user interfaces, wherein steps (1)-(4) are performed in less than one minute. According to paragraph 4,
(1) the one or more data stores further include a first relational database,
(2) the method includes (a) generating first structured dataset data from analysis output data, and (b) storing the first structured dataset data in the first relational database;
(3) the one or more data stores include a second relational database,
(4) the method includes (a) performing one or more analysis functions on data in the enhanced data lake to obtain analysis data, (b) optionally combining such analysis with data contained in the first relational database; A method comprising generating second structured dataset data from data, and (c) storing the second structured dataset data in the second relational database. The method of claim 5, wherein
(1) First,
(a) preparing a third representation regarding the quality of data stored in the first relational database, inputting it into the first relational database, or both, and rendering the third representation to one or more system administrator users. relaying to the graphical user interface of one or more other network devices in the data network;
(b) prepare a fourth representation regarding the quality of data stored in the second relational database, input it into the second relational database, or both, and convert the fourth representation to the one or more system administrator users associated with the fourth representation. relaying to the graphical user interface of one or more other network devices in the data network, or
(c) (I) prepare a third representation regarding the quality of data stored in the first relational database, input it into the first relational database, or both, and (II) prepare the third representation in one or more ways. relaying to the graphical user interface of one or more other network devices in the data network associated with a system administrator user, (III) preparing a fourth representation regarding the quality of data stored in the second relational database, and inputting into a relational database, or both, and (IV) relaying the fourth representation to the graphical user interface of one or more other network devices on the data network associated with one or more system administrator users; and
(2) thereafter, of the MAC-DMS memory if the data quality represented by the third representation, the fourth representation, or both indicates a lack of quality of the first relational database data, the second relational database data, or both. A method comprising applying one or more modifications to one or more instructions. 2. The method of claim 1, wherein any one or more of the medical devices comprises one or more multi-zone medical devices (MZMA), each MZMA comprising two or more separate zones,
(1) Each zone includes a separate processor that processes at least some MA-Ds that have not been processed by said processors in at least one other zone;
(2) Each zone is:
(a) receive information from different sensors,
(b) perform different therapeutic or preventive medical operations;
(c) receive information from different sensors and perform different therapeutic or preventive medical tasks;
(d) perform any or all or any combination of (a)-(c);
wherein at least one zone is configured to receive different levels of interaction with at least one other zone of the MZMA and one or more other portions of the data network. 8. The method of claim 7, wherein at least one zone of at least one of the one or more MZMAs is associated with the application of a therapeutic medical operation and is configured not to communicate directly with the data network. 9. The method of claim 8, wherein at least one zone of the one or more MZMAs is:
(1) Associated with the application of curative medical operations, preventive operations, or both;
(2) communicate with the MAC-DMS;
(3) allows only preset types of input from the MAC-DMS;
and wherein changes to the operating system, software or authorized form of the MAC-DMS entered into the zone of the at least one of the at least one MZMA require local approval from an authorized operator. The method of claim 1, wherein the MAC-DMS automatically,
(1) Collect MA-D during the data collection period to form a data collection;
(2) assessing whether the data collection is suitable for analysis according to Director Hana's preprogrammed standards;
(3) if the data collection is suitable for analysis, adding the data collection to the data aggregate;
(4) repeat steps (1)-(3) so that instances of at least 10 data collections are added to the data aggregation to form a complete data aggregation;
(5) If an instance of any data collection is determined to be unsuitable before the complete data aggregate is formed, the method includes discarding the incomplete data aggregate and starting the method again;
(6) When a complete data aggregate is formed, the method further comprises performing one or more analysis functions on data comprising the complete data aggregate. According to paragraph 1,
(1) The medical devices in the data network are owned by at least three different independent entities;
(2) at least one user of one or more other network devices is a commercial class user and is legally associated with the owner of the MAC-DMS;
(3) output of the analytics data provided to one or more other network devices associated with the one or more commercial class users,
(a) includes data generated from a collection of medical devices owned by multiple independent entities,
(b) A method for excluding one or more classes of MAC-DMS-identified independent entity confidential information. According to paragraph 1,
(1) The medical device includes at least two different medical device types, wherein the medical device type includes a first medical device type that performs one or more pulmonary treatment operations and a second medical device type that performs one or more cardiovascular treatment operations. Contains types;
(2) the method applies a machine learning module to the MA-D received from both the first medical device type and the second medical device type to provide predicted patient-specific information associated with the therapeutic operation performed by the medical device; Generating physiological parameters, and communicating these predicted patient-specific physiological parameters to a medical device of one or both of the two different medical device types, another network device, or a combination thereof. , method. According to paragraph 1,
(1) A user class contains one or more research user classes;
(2) one or more medical devices in the data network are associated with one or more users of the one or more study user classes;
(3) The above method is:
(a) the MAC-DMS receives input from at least some of the study user-related medical devices, and
(b) the MAC-DMS combines MA-Ds from at least some of the study user-related medical devices with MA-Ds obtained from medical devices associated with health care providers to form a blended data set;
(c) the MAC-DMS performing one or more analysis engine functions based at least in part on the mixed data set. According to paragraph 1,
(1) The MAC-DMS may: (a) impose data content requirements; (b) impose data format requirements; (c) transmit MA-Ds in accordance with one or more preprogrammed requirements, or (d) perform a combination of any or all of (a)-(d), thereby removing substantially all of the MA-Ds stored in said enhanced data lake. The -D dataset includes medical device source identification information, MA-D type information, and one or more sensor-derived physiological parameter datasets, each of which is provided in a standard preprogrammed MAC-DMS-recognizable format;
(2) The enhanced data lake includes different data governance zones based on the source or content of the MA-D dataset, analytics data, or both stored therein. According to paragraph 1,
(1) the one or more output applications include the provision of one or more alarms registered to one or more medical devices, one or more other network devices, or a combination thereof;
(2) Triggering parameters, communication parameters, repetition parameters, or a combination of any or all of these for the one or more alarms,
(a) set at the local medical device level, local other network device level, or both;
(b) set by medical device type, patient type, user type, or a combination of any or all of these;
(c) A method established according to both (a) and (b). According to clause 11,
(1) The one or more output applications include:
(a) one or more output applications that are regulated as software as a medical device (SaMD) by one or more regulatory authorities, and
(b) contains one or more output applications that are not regulated by SaMD;
(2) the method comprises one or more data transformations, data curation processes, and data validation to ensure that the one or more SaMD applications comply with one or more regulatory requirements recorded in processor-readable instructions stored in the MAC-DMS memory. A method comprising test confirmation or a combination of any or all thereof.

Images