DISTRIBUTED MEDICAL INTERVENTION TESTING ON A DIGITALLY SIMULATED PATIENT

Apparatus and methods for simulating a trial of a medical intervention on a patient. The medical intervention may include implantation or application of a medical device. The apparatus may include a digital trial platform. The platform may a provide a 3D (three-dimensional) model with a connection to a simulated patient. The 3D model may solve flow equations in three spatial dimensions and a temporal dimension in a digital simulation of the medical device. The platform may provide to a user of the 3D model commands and data formats that the user may use to cause the 3D model to exchange, across a network, 3D model simulation information with the simulated patient.

BACKGROUND

Typical medical intervention testing involves animal and human trials. Computational fluid dynamics software has provided device developers with numerical methods to evaluate devices in different flow regimes.

It would therefore be desirable to provide a system that device developers may use to apply physiologically-based boundary conditions to numerical models of devices.

DETAILED DESCRIPTION

Apparatus and methods for simulating a trial of a medical intervention on a patient are provided.

The medical intervention may include implantation or application of a medical device.

The medical intervention may include a drug administration.

The apparatus may include a digital trial platform. The platform may a provide a 3D (three-dimensional) model with a connection to a simulated patient. The 3D model may solve flow equations in three spatial dimensions and a temporal dimension in a digital simulation of the medical device.

“Solver” will be understood to include a computer program that numerically solves mathematical equations.

Table 1 lists illustrative medical devices that may be simulated.

The platform may provide to a user of the 3D model coupling software, such as an Application Program Interface (“API”). The API may provide the user with commands and data formats that the user may use to cause the 3D model to exchange 3D model simulation information with the simulated patient. The 3D model simulation information may include configuration information. The 3D model simulation information may include calculation information.

TABLE 3Illustrative 3D model API commands (for fluid including blood).CommandMessage structureExplanation, illustrative scenariosFor transmission by 3D model to simulated patientREQUEST{When the request contains the entry″BoundaryExchangeList″: {“BoundaryExchangeList”,″BoundaryConditions″: [boundary conditions information{are exchanged.″Inlet″: {A 3D model of the ascending aorta″ID″: 1,is requesting pressure, flow and a″Name″: ″3D-Aorta″list of substance concentrations at},the outlet interface connected to a″Outlet″: {1D (one-dimensional) transport″ID″: 2,model aortic arch blood vessel.″Name″: ″Aortic arch″,A “Requested” entry may be″Pressure″: {inserted for each quantity of interest″Type″: ″Requested″for which a value is be calculated.},A file (e.g., a JSON file) may″Flow″: {include a march command along″Type″: ″Requested″with the total duration of the 3D},time step.″Substance″: [The MARCH command may{instruct a solver to perform″Name″: ″O2″,calculations, evolve, or advance″Concentration″: {over a time period or one or more″Type″: ″Requested″time steps of a model.}},{″Name″: ″CO2″,″Concentration″: {″Type″: ″Requested″}}]}}]}}MARCH{“March”:{″Durations″:0.001} }CommandMessage structureExplanationFor receipt by 3D model from simulated patientPROVIDE{When providing responsive″BoundaryExchangeList″: {information to the 3D model, the″BoundaryConditions″: [same JSON structure may be{maintained as in the request″Inlet″: {method. The entry″ID″: 1,“BoundaryExchangeList” may be″Name″: ″3D-Aorta″maintained, and may contain the},requested information.″Outlet″: {The “Requested” entry may be″ID″: 2,removed from the file structure, and″Name″: ″Aortic arch″,the quantity of interest may be″Pressure″: {directly provided by adding a value″mmHg″: 10field with the unit name.},Here, for example, the aortic arch is″Flow″: {providing 10 mmHg, 20 mL/s, 0.3″mL_per_s″: 20mg/mL of oxygen and 0.7 mg/mL},of carbon dioxide.″Substance″: [When the 3D model wants to stop{the simulation, it may send a Stop″Name″: ″O2″,entry in the file structure.″Concentration″: {Log information may be inserted″mg_per_mL″: 0.3through info messages, warning}messages, error messages, fatal},error messages and any other{suitable messages.″Name″: ″CO2″,Log messages may contain″Concentration″: {additional information.″mg_per_mL″: 0.7Warnings may contain messages}related to possible mathematical}problems.]Error messages may contain issues}related to the file structure.}Fatal errors may include problems]that may prevent a simulation from}working properly, and may indicate}stopping the software.STOP{″Stop″:{ }}A 3D model of the ascending aortaLOG″Log″: {is requesting pressure, flow and aMESSAGES″Info″: [list of substance concentrations at″This is an information text″the 1D transport model aortic arch],blood vessel.″Warning″: [″This is a warning message″],″Error″: [″This is an error message″],″Fatal″: [″This is a fatal message″]}Other suitablecommands

The APIs may route commands between models using directives such as CLOUDSEND and LOCALSEND. CLOUDSEND may route a command between client and server across a network. LOCALSEND may route a command from one model instance to another without traversing a client/server link.

The configuration information may define simulated interfaces between the device and the simulated anatomy of the simulated patient. The configuration information may define 3D model information, such as a simulated duration of a time step in the model. The configuration information may include a duration of simulated time that it takes for the 3D model to advance through a time step. The configuration information may include any other suitable information.

The calculation information may include boundary conditions that are produced in the 3D simulation or in the simulated patient. The calculation information may include identifiers that associate the boundary conditions with a physiological parameter. The calculation information may include identifiers that associate the boundary conditions with simulated anatomy. The calculation information may include any other suitable information.

The simulated patient may include a 1D transport model. The simulated patient may include an 0D physiological model.

The 1D transport model may include simulated flow patterns that correspond to anatomical flow patterns. The patterns may include simulated flow channels that correspond to anatomical flow channels. The 1D transport model may interact with the 3D model. The 1D transport model may interact with a 0D physiological model. In this way, the 3D model may simulate behavior of the simulated 3D device based on boundary conditions that reflect behavior of flow channels and physiology.

The flow channels may include one or more networks of flow channels. For example, the flow channels may simulate a circulation system in the patient. Table 4 lists illustrative circulation systems and corresponding fluids.

TABLE 4Illustrative circulation systems and corresponding fluids.Illustrative circulation systemsSystemFluidPulmonary systemAirVenous systemBloodArterial systemBloodMicrocirculation systemBloodUrinary systemUrineOther suitable circulation systemsOther suitable fluidsCombination of any of the aboveCombination of any of the above

The patient may correspond to a human. The patient may correspond to an animal.

The flow channels may be defined in a database. The 1D transport model may be used to solve equations of motion and conservation on the channels. The simulated flow in a particular channel may be contemplated to vary along only one spatial dimension and time.

The 1D transport model may include representations of flow channel, computational elements defined in the representations of the flow channels, and junctions between the flow channels. The 1D transport model may include a 1D transport solver. The 1D transport solver may be configured to solve equations of motion, conservation and other suitable equations, upon the computational elements. The 1D transport model may include hardware and software configured for I/O. The 1D transport model may include any other suitable features, whether numerical, computational, or otherwise.

The 0D physiological model may include a 0D physiological solver. The 0D physiological solver may solve equations in which time is an independent variable. The 0D physiological solver may solve equations for which solutions do not depend on a spatial variable.

The 0D physiological model may provide physiological outputs to the 1D transport model based on 1D transport inputs to the 0D physiological model. The 1D transport model may provide 1D transport output to the 0D physiological model. Table 6 lists illustrative 0D physiological model inputs and outputs.

TABLE 6Illustrative OD physiological model inputs and outputs.Illustrative OD physiological model inputs and outputsInputsOutputsMass flow rateMass flow rateFluid flow rateFluid flow ratePressurePressureSubstance concentrationSubstance concentrationTemperatureTemperatureOther suitable inputsOther suitable outputs

The 0D physiological model may include one or more components that simulate different physiological systems. A component may simulate physiological responses to inputs based on one or more electrical circuit analogies, artificial intelligence, correlations, logic trees and other suitable functions, relationships or analogies. Table 8 lists illustrative components.

TABLE 9Illustrative physiological models.Illustrative physiological modelsSolver available under the trademark PULSEPHYSIOLOGY ENGINE from Kitware ®, Inc.Clifton Park, New YorkOther suitable models

The 1D transport model may interact with 3D model to provide to the 3D model simulated physiological conditions that correspond to real conditions to which the corresponding real medical device may be subjected in the corresponding real patient.

The apparatus and methods may provide for interaction of the 3D model with one or more other models aside from the simulated patient. The interaction may be via the simulated patient. The interaction may be in a master/slave configuration. The 3D model may be the master. The one or more other models may be slaves. A slave model may simulate a medical intervention. The slave model may simulate a medical intervention that is in part or whole different from a medical intervention simulated by the master model. Different slave models may simulate different medical interventions. A slave model may include one or more features that are present also in the master model.

The 1D transport solver may be instantiated on a first machine. The 3D solver may be instantiated on a second machine. The 0D physiological solver may be instantiated on a third machine. Different components may be instantiated on different third machines. One or more slave models may be instantiated on one or more corresponding fourth machines.

A digital trial platform may be instantiated on a fifth machine. One or more of the machines may be a virtual machine. One or more of the machines may be the same machine as one or more of the other machines. Two or more of the machines may be configured as separate nodes of an electronic communication network. The electronic communication network may include wired, wireless or optical communication links. Table 10 lists illustrative networks.

Table 11 lists illustrative communication protocols for communication between the machines over the networks.

The digital trial platform may configure a hierarchy of simulations. The platform may configure a master 3D model as a driver of the 1D transport model. The platform may configure the 1D transport model as a driver of the 0D physiological model. The platform may configure the 1D transport model as the driver of the slave 3D model.

Thus, the digital trial platform may orchestrate temporally coordinated digital test on the simulated patient of one or more simulated interventions running on different machines. The machines may be geographically distributed.

The 1D transport solver may numerically solve a system of equations, including transport and mass conservation equations. The equations may be defined in the 1D transport model. Boundary conditions at the interfaces of the 1D transport model and the 0D physiological model may constrain the system of equations.

Equation 1 is an illustrative governing equation for the 0D physiological model:

where G represents interconnection between passive elements, B and C are represent connections between potential sources, v and j represent potentials and fluxes, respectively, i represents a sum of fluxes through passive elements, and e represents independent potential sources.

System of Equations 2 includes illustrative governing equations for the 1D transport model for a single flow channel with transport of various substance concentrations:

where x is an axial coordinate along the longitudinal axis of the channel, t is time, ρ is fluid density, ƒ is friction force per unit length, A(x,t) is cross-sectional area of the vessel, u(x,t) is fluid flow (a velocity), p(x,t) is average internal pressure over a channel cross-section, q(x,t)=A(x,t)u(x,t) is volumetric fluid flow rate, and Cl(x,t), . . . , Ck(x,t) are concentrations of k solutes or substances.

Another equation may be included to form a closed system of equations. One such equation may provide a constraint that relates cross-sectional area to transmural pressure for a viscous material wall.

Equation 3 is an illustrative constraint based on a compliant tube law:

where K is a parameter that defines mechanical properties of the channel, Aois vessel cross-sectional area at equilibrium, m and n are real numbers, and ϕ(A) defines the viscoelasticity of the channel wall.

By using the first partial differential equation in system of Equations 2, the temporal derivative of the cross-sectional area in Equation 3 is replaced with the spatial derivative of fluid flow as follows:

When introducing Equation 4 in the system of Equations 2, the resulting system of partial differential equations may be parabolic. To hyperbolize the system of Equations 2, auxiliary variable θ and relaxation parameter ϵ, in Equation 5, which may be an evolution equation, may be introduced.

By integrating Equation 5 in Equation 4, a compliant tube may be obtained as:

By integrating Equation 5 and Equation 6 into the system of differential Equations 2, Equation 7, below, may be obtained:

in which:

in which Q is the vector of conserved quantities, A(Q) is the Jacobian matrix, S(Q) is the source term, and c is the wave speed.

Values of illustrative parameters ρ, ƒ, K, Ao, m, n, and ϕ may be derived or selected based on empirical or theoretical data. Values of illustrative parameters ρ, ƒ, K, Ao, m, n, and ϕ may be imported into one or more of the models.

The total flow of fluid out of the 0D physiological model (into the 1D transport model) may be constrained by the total simulated flow of fluid into the 0D physiological model (out of the 1D transport model).

The methods may include receiving at a first machine, from a 3D model instantiated on a second machine, a 3D-inflow file. The methods may include receiving at a first machine, from a 3D model instantiated on a second machine, a 3D-outflow file. The methods may include providing from the first machine, via the network, to the 3D model a 1D-outflow file. The methods may include providing from the first machine, via the network, to the 3D model a 1D-inflow file. The methods may include receiving from the second machine, via the network, an instruction to advance a 1D transport model instantiated on the first machine.

Table 12 lists illustrative types of files.

TABLE 12Illustrative types of files.Illustrative types of filesJSONXMLOther suitable types of files

The methods may include requesting from the second machine the 3D-inflow file before receiving the 3D-outflow file at the first machine.

The methods may include receiving over the network a configuration file. The configuration file may define an upstream interface between the simulated medical device and anatomy of the digitally simulated patient. The configuration file may define a downstream interface between the simulated medical device and the anatomy.

The 3D-outflow file may include a boundary condition record. The 3D-inflow file may include a boundary condition record. The 1D-outflow file may include a boundary condition record. The 1D-inflow file may include a boundary condition record. A boundary condition record may include a flow interface identifier referring to either of the upstream interface and the downstream interface. A boundary condition record may include a numerical boundary condition. A numerical boundary condition may be included in a boundary condition vector. The vector may include one or more calculated quantities. Table 13 lists illustrative quantities.

TABLE 13Illustrative quantities.Illustrative types of quantitiesFluid pressureFluid flow rateFluid constituent concentrationSolute flow rateAny of the 0D physiological model inputs and outputsOther suitable quantitiesAny combination of two or more of the above quantities

The methods may include, in response to the instruction, advancing the 1D transport model through a series of 1D transport model time steps.

The advancing may include obtaining from a 0D physiological model a first 1D transport model input. The advancing may include providing to the 0D physiological model a first 1D transport model output. The advancing may include providing to the 0D physiological model a second 1D transport model output.

The 0D physiological model may be instantiated on a third machine.

The first machine and the third machines may be distinct from each other. The first machine and the third machine may be machines that are not distinct from each other. The first machine, the second machine and the third machine all may be distinct from each other. The first machine, the second machine and the third machine all may be indistinct from each other.

The first 1D transport model input may include a boundary condition record. The first 1D transport model output may include a boundary condition record. The second 1D transport model output may include a boundary condition record. The boundary condition record may include a 0D physiological model component identifier.

The boundary condition record may include a 1D transport model component code. The boundary condition record may include an inlet/outlet indicator. The boundary condition record may include a 0D/1D boundary condition vector.

The providing to the 0D physiological model a first 1D transport model output may include distributing to each 0D physiological model time step in a 0D simulation a fraction of a value of the first 1D transport model output that is defined by:

The methods may include to the 0D physiological model a 1D transport model time step. The methods may include to the 0D physiological model and an instruction to return a second 1D transport model input. The methods may include to the 0D physiological model and an instruction to return a second 1D transport model input after the 0D physiological model advances through a series of 0D physiological model time steps

The second 1D transport model input may include a boundary condition record. The boundary condition record may include a 0D physiological model component identifier. The boundary condition record may include a 1D transport model component code. The boundary condition record may include an inlet/outlet indicator. The boundary condition record may include a 0D/1D boundary condition vector.

The second 1D transport model input may include a sum derived from values calculated in each 0D physiological model time step.

A value of the 1D-outflow file may be based on a value of the second 1D transport model input.

The 1D-outflow file may be based on the first 1D transport model input and the second 1D transport model input. The 1D-inflow file may be based on the first 1D transport model input and the second 1D transport model input.

The 1D-outflow file may be determined by the first 1D transport model input and the second 1D transport model input. The 1D-inflow file may be determined by the first 1D transport model input and the second 1D transport model input.

The methods may include evolving a 1D simulation in the 1D transport model for each of the time steps. The evolving may include using a solver to solve the equations using boundary conditions associated with a time step of the model.

The methods may include distributing to each 1D transport model time step in a 1D simulation a fraction of a value of the 3D-inflow file that is defined by:

The 1D-outflow file may include sum derived from values calculated in each during time steps of a 1D simulation in the 1D transport model.

The 3D model may be a master 3D model. The methods may include, when the 3D model is a master 3D model, receiving at the first machine from a slave 3D model a 3D-inflow slave file.

A master 3D model may be a 3D model that instructs a 1D transport model to advance. A slave 3D model may be a 3D model that is instructed to advance by a 1D transport model. The trial platform may provide users of the 3D models to register a 3D model as a master 3D model. The trial platform may provide users of the 3D models to register a 3D model as a slave 3D model. The trial platform may order simulation steps in accordance with the registrations.

The methods may include, when the 3D model is a master 3D model, receiving at the first machine from a slave 3D model a 3D-outflow slave file. The methods may include, when the 3D model is a master 3D model, providing from the first machine to the 3D model a 1D-outflow slave file. The methods may include, when the 3D model is a master 3D model, providing from the first machine to the 3D model a 1D-inflow slave file. The methods may include, when the 3D model is a master 3D model, providing from the first machine to the 3D model an instruction to advance a slave 3D simulation on the slave 3D model.

The instruction may include an instruction to advance the slave 3D simulation through slave 3D model time steps corresponding, in sum, to a 1D transport model time step of the 1D transport model.

The slave 3D model may be of a plurality of slave 3D models in communication with the first machine.

The receiving of the 3D-inflow slave file may include a receiving via an electronic communication network. The receiving of the 3D-outflow slave file may include a receiving via an electronic communication network.

The providing of the 1D-outflow slave file may include a providing via the network. The providing of the 1D-inflow slave file may include a providing via the network. The providing of the instruction to advance a slave 3D simulation on the slave 3D model may include a providing via the network.

The 1D-outflow file may be based on the 3D-inflow slave file. The 1D-outflow file may be based on the 3D-outflow slave file. The 1D-inflow file may be based on the 3D-inflow slave. The 1D-inflow file may be based on the 3D-outflow slave file.

The 1D-outflow file may be based on both the 3D-inflow slave file and the 3D-outflow slave file. The 1D-inflow file may be based on both the 3D-inflow slave file and the 3D-outflow slave file.

The 1D-outflow file may be determined by the 3D-inflow slave file. The 1D-outflow file may be determined by the 3D-outflow slave file. The 1D-inflow file may be determined by the 3D-inflow slave. The 1D-inflow file may be determined by the 3D-outflow slave file.

The 1D-outflow file may be determined by both the 3D-inflow slave file and the 3D-outflow slave file. The 1D-inflow file may be determined by both the 3D-inflow slave file and the 3D-outflow slave file.

The methods may include receiving over the network at a digital trial platform a slave configuration file. The slave configuration file may define a simulated upstream interface between a slave simulated device and anatomy of the digitally simulated patient. The slave configuration file may define a simulated downstream interface between the slave simulated device and the anatomy.

The simulated upstream interface may be of a plurality of simulated upstream interfaces between the slave simulated device and the anatomy.

The simulated upstream interface may be of a plurality of simulated downstream interfaces between the slave simulated device and the anatomy.

The 3D-inflow slave file may include a boundary condition record. The 3D-outflow slave file may include a boundary condition record. The 1D-outflow slave file may include a boundary condition record.

Apparatus and methods for simulating a trial of a medical device on a patient are provided. The apparatus may support practice of the methods. The methods may include advancing on a first machine a 1D transport model through a series of 1D transport model time steps. The advancing may include obtaining from a 0D physiological model a first 1D transport model input. The advancing may include providing to the 0D physiological model a first 1D transport model output. The advancing may include providing to the 0D physiological model a second 1D transport model output.

The first 1D transport model input may include a boundary condition record. The first 1D transport model output may include a boundary condition record. The second 1D transport model output may include a boundary condition record. The boundary condition record may include a 0D physiological model component identifier. The boundary condition record may include a 1D transport model component code. The boundary condition record may include an inlet/outlet indicator. The boundary condition record may include a 0D/1D boundary condition vector.

The providing to the 0D physiological model the first 1D transport model output includes distributing to each 0D physiological model time step in a 0D simulation a fraction of a value of the first 1D transport model output that is defined by:

The methods may include communicating to the 0D physiological model a 1D transport model time step. The methods may include communicating to the 0D physiological model an instruction to return a second 1D transport model input after the 0D physiological model advances through a series of 0D physiological model time steps.

The second 1D transport model input includes a boundary condition record. The boundary condition record may include a 0D physiological model component identifier. The boundary condition record may include a 1D transport model component code. The boundary condition record may include an inlet/outlet indicator. The boundary condition record may include a 0D/1D boundary condition vector.

The second 1D transport model input may include a sum derived from values calculated in each 0D physiological model time step in a sequence of 0D physiological model time steps.

The methods may include evolving a 1D simulation corresponding to a 1D transport solver time step. The evolving may include using a solver to solve the equations using boundary conditions associated with a time step of the model.

Illustrative embodiments of apparatus and methods in accordance with the principles of the invention will now be described with reference to the accompanying drawings, which forma part hereof. It is to be understood that other embodiments may be utilized and that structural, functional and procedural modifications or omissions may be made without departing from the scope and spirit of the present invention.

FIG.1is a block diagram that illustrates a computing server101(alternatively referred to herein as a “server or computer”) that may be used in accordance with the principles of the invention. The server101may have a processor103for controlling overall operation of the server and its associated components, including RAM105, ROM107, input/output (“I/O”) module109, and memory115.

I/O module109may include a microphone, keypad, touchscreen and/or stylus through which a user of server101may provide input, and may also include one or more of a speaker for providing audio output and a video display device for providing textual, audiovisual and/or graphical output. Software may be stored within memory115and/or other storage (not shown) to provide instructions to processor103for enabling server101to perform various functions. For example, memory115may store software used by server101, such as an operating system117, application programs119, and an associated database111. Alternatively, some or all of computer executable instructions of server101may be embodied in hardware or firmware (not shown).

Server101may operate in a networked environment supporting connections to one or more remote computers, such as terminals141and151. Terminals141and151may be personal computers or servers that include many or all of the elements described above relative to server101. The network connections depicted inFIG.1include a local area network (LAN)125and a wide area network (WAN)129, but may also include other networks.

When used in a LAN networking environment, server101is connected to LAN125through a network interface or adapter113.

When used in a WAN networking environment, server101may include a modem127or other means for establishing communications over WAN129, such as Internet131.

Additionally, application program119, which may be used by server101, may include computer executable instructions for invoking user functionality related to communication, such as email, short message service (SMS), and voice input and speech recognition applications.

Computing server101and/or terminals141or151may also be mobile terminals including various other components, such as a battery, speaker, and antennas (not shown). Terminal151and/or terminal141may be portable devices such as a laptop, tablet, smartphone or any other suitable device for receiving, storing, transmitting and/or displaying relevant information.

Any information described above in connection with database111, and any other suitable information, may be stored in memory115. One or more of applications119may include one or more algorithms that may be used to perform the functions of one or more of a digital trial platform, the models, a computing platform and perform any other suitable tasks.

FIG.2shows illustrative apparatus200that may be configured in accordance with the principles of the invention.

Apparatus200may be a computing machine. Apparatus200may include one or more features of the apparatus that is shown inFIG.1.

Apparatus200may include chip module202, which may include one or more integrated circuits, and which may include logic configured to perform any other suitable logical operations.

Apparatus200may include one or more of the following components: I/O circuitry204, which may include a transmitter device and a receiver device and may interface with fiber optic cable, coaxial cable, telephone lines, wireless devices, PHY layer hardware, a keypad/display control device or any other suitable encoded media or devices; peripheral devices206, which may include counter timers, real-time timers, power-on reset generators or any other suitable peripheral devices; logical processing device208, which may solve equations and perform other methods described herein; and machine-readable memory210.

Machine-readable memory210may be configured to store in machine-readable data structures associated with a digital trial platform, the models, a computing platform and any other suitable information or data structures.

The chip may be silicon-based.

FIG.3shows schematically illustrative medical device model M. Model M may be a numerical 3D model for which a trial in the simulated patient is desired. Model M may include simulated structure S. Model M may include simulated fluid F. Structure S may include one or more simulated inlets I. Structure S may include one or more simulated outlets O. Flow F may have a 3D flow pattern P. Model M may include a solver and computational elements upon which the solver may solve equations of motion, conservation and other suitable equations. Model M may include hardware and software configured for I/O. The computational elements may include inflow boundary interfaces E corresponding to inlets I. The computational elements may include outflow boundary interfaces Eocorresponding to outlets O. The simulated patient may provide boundary condition values to boundary interfaces Eiand Eo.

FIG.4shows schematically illustrative physiological functionalities400of the simulated patent. Functionalities400may include interaction with the ambient environment. Functionality400may include interactions between simulated interventions, such as drugs402, anesthesia machine404and inhaler406, with simulated physiology functions, such as respiratory408, gastrointestinal410, nervous412, cardiovascular414, fluid chemistry416, tissue418, endocrine420, renal422and energy424. The interactions may be categorized by type, such as advection426, diffusion428and property modifier430. Illustrative connections are shown.

FIG.5shows illustrative arrangement500for a distributed medical intervention testing. Arrangement500may include illustrative digitally simulated patient502, illustrative digital trial platform504, illustrative electronic communication network N, illustrative model M, illustrative slave model Ms1and illustrative slave model Ms2. Digital trial platform504may coordinate communication between one or more of models M, Ms1and Ms2and simulated patient502.

Simulated patient502may include 0D physiological model506. Simulated patient502may include 1D transport model508. In arrangement500, model M may be connected with simulated patient502via electronic communication network N.

Model M may include a master 3D solver. Slave model Ms1may include a first slave 3D solver. Slave model Ms2may include a second slave 3D solver. One or more of the slave solvers may have one or more features in common with the master 3D solver. Arrangement500may include further slave models and solvers.

A slave 3D model may include simulated structure. The slave 3D model may include simulated fluid. The structure may include one or more simulated inlets. The structure may include one or more simulated outlets. The flow may have a 3D flow pattern. The slave 3D model may include a slave 3D solver and computational elements upon which the solver may solve equations of motion, conservation and other suitable equations. The slave 3D model may include hardware and software configured for I/O. The computational elements may include inflow boundary interfaces corresponding to the inlets. The computational elements may include outflow boundary interfaces corresponding to the outlets. The simulated patient may provide boundary condition values to the boundary interfaces.

0D physiological model506may implement one or more of functionalities400(shown inFIG.4). 0D physiological model506may include one or more components510. A component510may correspond to one or more of functionalities400.

1D transport model508may solve one or more governing equations, such as Equations 2, on simulated flow channels512. Channels512may include branches such as branches513and515. Simulated flow channels512may have inflow interfaces such as inflow interfaces514,516,518,520and522. Simulated flow channels512may have outflow interfaces such as outflow interfaces524,526,528,530and532.

Model M may include inlet I1, outlet O1and outlet O2. Model Ms1may include inlet Is1,1outlet Os1,1and outlet Os1,2. Model Ms2may include inlet Is2,1outlet Os2,1and outlet Os2,2. A user may register, in digital trial platform504, simulated connections of inlets I1, Is1, and Is2to outflow interfaces524,526,528,530and532, and of outlets O1, O2. Os1,1Os1,2. Os2,1and Os2,2to inflow interfaces514,516,518,520and522, to simulate positions of the models in the simulated patient.

The user may select a channel512and, using a tool of the digital trial platform, bisect the channel to create a new inlet and a new outlet for connection with a model.

FIG.6shows illustrative channels branch513of channels512(both shown inFIG.5). Branch513may include individual segments such as650,652,654,656,658,660and662. The segments may join at simulated channel junctions such as664,666and668. The segments may have unique identifiers, such as “a,” “b,” “c,” “d,” “e,” “f,” and “g.” Each of the segments may have a defined spatial dimension, such as xa, xb, xc, xd, xe, xfand xg. Each of the segments may have computational elements such as600that represent an interval in the xi direction. Each element may have an inflow border and an outflow border, such as601and603. Each segment may have a terminal border, such as604,605,606,607,608,609,610,611612,613,614,616and624. Illustrative inflow terminal borders include602(corresponding to inflow interface514),604,606,608,610,612and614. Illustrative outflow terminal borders include616,618,620(corresponding to outflow interface524),626(corresponding to outflow interface526),624,626(corresponding to outflow interface528) and628(corresponding to outflow interface530).

FIG.9shows illustrative architecture900for implementation of an arrangement such as500(shown inFIG.5). Model M may include a 3D solver. Simulated patient502may include computation platform902. One or both of platforms504and902may include one or more infrastructural features such as those shown inFIGS.1and2. Platform504may provide configuration files from 3D model M to 1D transport model508. The configuration file may include 3D model user selections of physiological parameters for communication to the 0D physiological model for configuration of the 0D physiological model. Platform504may provide API904for the exchange of boundary condition records between the 3D solver and the 1D transport solver. Platform504may provide API906for exchange of boundary condition records between the 1D transport solver and the 0D physiological solver. Platform504may configure simulated patient502to include 0D physiological functionalities in accordance with the user's selection of physiological parameters. API904may provide a route for exchange of boundary condition records between the 3D solver and the 1D transport solver. The route may be a route that does not include intervening routing through digital trial platform504. Such a route may have a latency that is less than that associated with a route that does include such intervening routing. Such a route may be referred to as a “direct route.”

The API may be based on socket.io protocol communication to allow for a realtime, bi-directional communication between the parties. The exchange of information may be based on short messages, such as short JSON file messages. The API may be implemented using any suitable protocol.

FIG.10shows illustrative “cloud computing” architecture1000for implementing the digital trial. In architecture1000, 0D physiological model506and 1D transport model508(both shown inFIG.5) may be implemented on cloud computing services platform1002. A socket server may support communication pathways with socket clients over communication network N. The communication pathways may be persistent. The communication pathways may be bi-directional. The socket server may be implemented as a socket.io server, a web socket server, or any other suitable server. Digital trial platform504may be implemented as a client of the socket server.

Digital trial platform504(shown inFIG.5) may provide to client1004API1006. Digital trial platform504may provide to client1008API1010. Digital trial platform504may provide to client1012API1014.

API1006may provide 3D model M with 3D solver API commands. API1006may provide 3D model M with telecommunication protocols suitable for communication with 1D transport model508via socket client1016, persistent bi-directional communication pathway1018, socket server1020and API1022.

Prior to advancement of a model, whether master, slave, 1D or 0D, the model may exchange boundary condition records with another model in communication with the system. A boundary condition may be transmitted in a data structure that may be referred to as a “file,” an “input,” an “output,” or by any other suitable term. The data structure may include a file. The data structure may include a message.

Boundary conditions provided by 1 1D model or a 3D model to another model may include quantities (see, e.g., Table 13) produced from a computational element or part thereof a logically abutting the model to which the boundary condition is being provided.

Boundary conditions provided by the 0D physiological model may include spatially-independent quantities (see, e.g., Table 13) corresponding to logically abutting 1D transport model interfaces.

FIG.11shows illustrative schema1100for testing the medical device. Schema1100may include illustrative facet1102. Schema1100may include illustrative facet1104. Schema1100may include illustrative facet1106. Coordinates1103and1105show how time t and space (e.g., x) may be interpreted in facets1102and1104, respectively.

Facet1102shows the 3D model instantiated on the second machine. The 1D transport model may be instantiated on the first machine. The 3D model may be logically juxtaposed between inflow interfaces (such as514-522, shown inFIG.5) of the 1D model and outflow interfaces (such as524-532, shown inFIG.5) of the 1D model. The 3D model may advance through step F, which has a simulated duration of dt3D, to advance simulation of the simulated medical device by one time step. When the 3D model advances by dt3D, it will be understood that the 3D model advances from a “current” time to a “future” time.

Advancement of step F may involve the advancement of the 1D transport model by a number of steps, such as A and B (which are representative of a plurality of steps).

Facet1104shows the 1D transport model logically juxtaposed between inflow interfaces of the 0D physiological model (corresponding to 1D model outflow interfaces such as524-532, shown inFIG.5) and outflow interfaces of the 0D physiological model (corresponding to 1D model inflow interfaces such as514-522, shown inFIG.5). The 1D transport model may advance through step E, which has a simulated duration of dt1D, to advance the 1D simulation for each step A, B, . . . , etc. When the 1D transport model advances by dt1D, it will be understood that the 1D transport model advances from a “current” time to a “future” time.

Advancement of step E may involve the advancement of the 0D physiological model by a number of steps, such as C and D (which are representative of one or more steps).

Facet1106shows illustrative nesting and iteration of the simulation steps of the different models. tF1is a duration of a first advancement through step F. tF1may include tA, tB, . . . , etc., for the advancement through steps A, B, . . . , etc. Each of tA, tB, . . . , etc., may include tC, tD, . . . , etc., for the advancement through steps C, D, . . . , etc. After tF1, the 3D model may advance to tF2, which may include a further nestings and iterations corresponding to those shown for tF1.

FIG.12shows facets1102and1104at a file exchange stage at the beginning of tF1. In facet1102, the 3D model may transmit a 3D-inflow file to the 1D transport model for application at the 1D model outflow interfaces. In facet1102, the 3D model may transmit a 3D-outflow file to the 1D transport model for application at the 1D model inflow interfaces.

FIG.13shows facets1102and1104at a simulation advancement stage. In facet1104, the 3D model has transmitted to the 1D transport model an instruction to advance. The 1D model may begin to advance by exchanging information with the 0D physiological model.

FIG.14shows facets1102and1104at a file exchange stage. In facet1104, the 1D transport model may request from the 0D physiological model a first 1D transport model input. The 0D physiological model may provide to the 1D transport model the first 1D transport model input. The 1D transport model may apply the first 1D transport model input at the 1D transport model outflow interfaces. The 1D model may derive (see arrow RI) from the first 1D transport model input a first 1D transport model output. The first 1D transport model output may be based on applying an approximation derived from the first 1D transport model input. The first 1D transport model output may include a Riemann Invariant based on the first 1D transport model input. The 1D transport model may provide to the 0D physiological model the first 1D transport model output. The 1D transport model may provide to the 0D physiological model the second 1D transport model output.

FIG.15shows facets1102and1104in the same stage as that shown inFIG.14.FIG.15shows that the first 1D transport model output may include a value that is distributed among time step C and time step D in the 0D physiological model. The value may be a fluid flow rate. The distribution may be performed to obey mass conservation laws in the communication between models having time steps of different simulated durations. The 1D model may provide to the 0D physiological model a sum (not shown), over all of the 1D model outflow interfaces, of the simulated fluid flow rates. The 0D model may use the sum to constrain, based on conservation of mass, a fluid flow rate value that the 0D physiological model later may provide to the 1D model inflow interfaces.

FIG.16shows facets1102and1104at a simulation advancement stage. In facet1104, the 1D transport model has transmitted to the 0D physiological model an instruction to advance. The 0D physiological model may begin to advance by performing calculations based on information exchanged with the 1D transport model. The 0D physiological model may advance through time steps C, D, . . . , etc.

FIG.17shows facets1102and1104at a file exchange stage. In facet1104, the 1D transport model may request from the 0D physiological model a second 1D transport model input. The 0D physiological model may provide to the 1D transport model the second 1D transport model input. The 1D transport model may apply the second 1D transport model input at the 1D transport model inflow interfaces.

FIG.18shows facets1102and1104in the same stage as that shown inFIG.19.FIG.20shows that the second 1D transport model input may include a sum of values drawn from time step C and time step D in the 0D physiological model. The value may be a fluid flow rate. The sum may be performed to obey mass conservation laws in the communication between models having time steps of different simulated durations. The 1D model may apply the sum to the 1D model inflow interfaces.

FIG.19shows facets1102and1104at a simulation advancement stage. In facet1104, the 1D transport model has received from the 0D physiological model the second 1D transport model input. The 1D transport model may begin to advance by performing calculations based on information exchanged with the 0D physiological model and the 3D model. The 1D transport model may advance through a time step E that corresponds to time step A (tAinFIG.11).

The 1D transport model may advance to time step B (tBinFIG.11), based on further iteration through time steps C, D, . . . , etc.

FIG.20shows facets1102and1104at the file exchange stage illustrated inFIG.14, but with file exchanges at the 1D transport model inflow interfaces that are different from the those shown inFIG.14.

In facet1104, the 1D transport model may request from the 0D physiological model a first 1D transport model input. The 0D physiological model may provide to the 1D transport model the first 1D transport model input. The 1D transport model may apply the first 1D transport model input at the 1D transport model outflow interfaces. The 1D model may derive (see arrow RI) from the first 1D transport model input a first 1D transport model output. The first 1D transport model output may be based on applying an approximation derived from the first 1D transport model input. The first 1D transport model output may include a Riemann Invariant based on the first 1D transport model input. The 1D transport model may provide to the 0D physiological model the first 1D transport model output. The 1D transport model may provide to the 0D physiological model the third 1D transport model output.

In facet1104, the 1D transport model may request from the 0D physiological model a third 1D transport model input. The 0D physiological model may provide to the 1D transport model the third 1D transport model input. The 1D transport model may apply the third 1D transport model input at the 1D transport model inflow interfaces. The 1D model may derive (see arrow RI) from the third 1D transport model input a third 1D transport model output. The third 1D transport model output may be based on applying an approximation derived from the third 1D transport model input. The third 1D transport model output may include a Riemann Invariant based on the third 1D transport model input. The 1D transport model may provide to the 0D physiological model the third 1D transport model output.

FIG.21shows facets1102and1104in the same stage as that shown inFIG.20, but with different file exchanges at the 1D transport model inflow interfaces. The first 1D transport model output may include a value that is distributed among time step C and time step D in the 0D physiological model. The value may be a fluid flow rate. The distribution may be performed to obey mass conservation laws in the communication between models having time steps of different simulated durations. The 1D model may provide to the 0D physiological model a sum not shown), over all of the 1D model outflow interfaces, of the simulated fluid flow rates. The 0D model may use the sum to constrain, based on conservation of mass, a fluid flow rate value that the 0D physiological model later may provide to the 1D model inflow interfaces.

FIG.21shows that the third 1D transport model output may include a value that is distributed among time step C and time step D in the 0D physiological model. The value may be a fluid flow rate. The distribution may be performed to obey mass conservation laws in the communication between models having time steps of different simulated durations. The 1D model may provide to the 0D physiological model a sum, over all of the 1D model outflow interfaces, of the simulated fluid flow rates. The 0D model may use the sum to constrain, based on conservation of mass, a fluid flow rate value that the 0D physiological model later may provide to the 1D model inflow interfaces.

FIG.22shows facets1102and1104at a simulation advancement stage. In facet1104, the 1D transport model has transmitted to the 0D physiological model an instruction to advance. The 0D physiological model may begin to advance by performing calculations based on information exchanged with the 1D transport model. The 0D physiological model may advance through time steps C, D, . . . , etc.

FIG.23shows facets1102and1104at a file exchange stage. In facet1104, the 1D transport model may request from the 0D physiological model a fourth 1D transport model input. The 0D physiological model may provide to the 1D transport model the fourth 1D transport model input. The 1D transport model may apply the fourth 1D transport model input at the 1D transport model inflow interfaces.

FIG.24shows facets1102and1104in the same stage as that shown inFIG.23.FIG.24shows that the fourth 1D transport model input may include a sum of values drawn from time step C and time step D in the 0D physiological model. The value may be a fluid flow rate. The sum may be performed to obey mass conservation laws in the communication between models having time steps of different simulated durations. The 1D model may apply the sum to the 1D model inflow interfaces.

FIG.25shows facets1102and1104at a simulation advancement stage. In facet1104, the 1D transport model has received from the 0D physiological model the third 1D transport model input. The 1D transport model may begin to advance by performing calculations based on information exchanged with the 0D physiological model and the 3D model. The 1D transport model may advance through a time step E that corresponds to time step A (tAinFIG.11).

The 1D transport model may advance to time step B (tBinFIG.11), based on further iteration through time steps C, D, . . . , etc.

FIG.26shows facets1102and1104at a file exchange stage after the 1D transport model advances through time steps A, B, . . . , etc., and corresponding subordinate sub steps C, D, . . . , etc. At this stage, the 1D transport model may provide to the 3D model a 1D-outflow file and a 1D-inflow file. The 3D model may apply the 1D-outflow file at the 3D model inflow interfaces. The 3D model may apply the 1D-inflow file at the 3D model outflow interfaces.

FIG.27shows facets1102and1104in the same stage as that shown inFIG.26.FIG.27shows that the 1D-outflow file may include a sum of values drawn from time step A and time step B in the 1D transport model. The value may be a fluid flow rate. The sum may be performed to obey mass conservation laws in the communication between models having time steps of different simulated durations. The 3D model may apply the sum to the 3D model inflow interfaces.

The 1D-inflow file may include a sum of values drawn from time step A and time step B in the 1D transport model. The value may be a fluid flow rate. The sum may be performed to obey mass conservation laws in the communication between models having time steps of different simulated durations. The 3D model may apply the sum to the 3D model outflow interfaces.

FIG.28shows facets1102and1104at a simulation advancement stage. In facet1102, the 3D model has received from the 1D transport model the 1D-outflow file and the 1D-inflow file. The 3D model may begin to advance by performing calculations based on information exchanged with the 1D transport model. The 3D model may advance through time step F.

FIG.29shows facets1102and1104at a file exchange stage at the beginning of tF2(seeFIG.11). In facet1102, the 3D model may transmit a 3D-inflow file to the 1D transport model for application at the 1D model outflow interfaces. In facet1102, the 3D model may transmit a 3D-outflow file to the 1D transport model for application at the 1D model inflow interfaces.

The simulation may continue for successive iterations of tFηuntil a simulation convergence criterion is satisfied.

FIG.30shows illustrative schema3000for testing a first simulated medical device in concert with a second simulated medical device. The first medical device may be simulated by the master 3D model. The second simulated medical device may be simulated by a slave 3D model. Illustrative schema3000shows interaction between the 1D transport model and the slave 3D model.

Schema3000may include illustrative facet3002and illustrative facet3006. Coordinates3003show how time t and space (e.g., x) may be interpreted in facets3002and1104, respectively.

Facet3002shows the slave 3D model corresponding to a slave 3D model instantiated on a fourth machine. The slave 3D model may be logically juxtaposed between inflow interfaces (such as514-522, shown inFIG.5) of the 1D model and outflow interfaces (such as524-532, shown inFIG.5) of the 1D model. The slave 3D model may advance through step F, which has a simulated duration of dt3D, to advance simulation of the simulated medical device by one time step.

After tF1, the 3D model may advance to tF2, which may include further nestings and iterations corresponding to those shown for tF1in facet3006.

FIG.31shows facet3002at a file exchange stage. In facet3002, the 1D transport model may request from the slave 3D model a 3D-outflow slave file and a 3D-inflow slave file. The 3D slave model may provide to the 1D transport model the 3D-outflow slave file and a 3D-inflow slave file. The 1D transport model may provide to the slave 3D model a 1D-inflow slave file and a 1D-outflow slave file. The 1D transport model may apply the 3D-outflow slave file at the 1D model inflow interfaces. The 1D transport model may apply the 3D-inflow slave file at the 1D model outflow interfaces.

The 1D model may derive (see arrow RI) from the 3D-outflow slave file the 1D-inflow slave file. The 1D model may derive (see arrow RI) from the 3D-inflow slave file the 1D-outflow slave file. The 1D-inflow slave file may be based on an approximation derived from the 3D-outflow slave file. The 1D-outflow slave file may be based on an approximation derived from the 3D-outflow slave file. One or both of the approximations may include a Riemann Invariant.

The slave 3D model may apply the 1D-inflow slave file at the slave 3D model outflow interfaces. The slave 3D model may apply the 1D-outflow slave file at the slave 3D model inflow interfaces.

FIG.32shows facet3002in the same stage as that shown inFIG.31.FIG.32shows that the 1D-inflow slave file may include a value that is distributed among step G and step H in the slave 3D model. The value may be a fluid flow rate. The distribution may be performed to obey mass conservation laws in the communication between models having time steps of different simulated durations. The 1D-outflow slave file may include a value that is distributed among step G and step H in the slave 3D model. The value may be a fluid flow rate. The distribution may be performed to obey mass conservation laws in the communication between models having time steps of different simulated durations.

FIG.33shows facet3002at a simulation advancement stage. In facet3002, the 1D transport model has transmitted to the slave 3D model an instruction to advance. The slave 3D model may begin to advance by performing calculations based on information exchanged with the 1D transport model. The slave 3D model may advance through steps G, H, . . . , etc.

Apparatus may omit features shown and/or described in connection with illustrative apparatus. Embodiments may include features that are neither shown nor described in connection with the illustrative apparatus. Features of illustrative apparatus may be combined. For example, an illustrative embodiment may include features shown in connection with another illustrative embodiment.

For the sake of illustration, the steps of the illustrated processes will be described as being performed by a “system.” A “system” may include one or more of the features of the apparatus and schema that are shown inFIG.1-FIG.33and/or any other suitable device or approach. The “system” may include one or more means for performing one or more of the steps described herein.

The steps of methods may be performed in an order other than the order shown and/or described herein. Embodiments may omit steps shown and/or described in connection with illustrative methods. Embodiments may include steps that are neither shown nor described in connection with illustrative methods.

Illustrative method steps may be combined. For example, an illustrative process may include steps shown in connection with another illustrative process.

FIG.34shows illustrative process3400for simulating a trial of a medical device on a patient. Process3400may begin at step3402. At step3402, the system may receive 3D model boundary conditions and apply them to 1D model channel inlets and outlets. At step3404, the system may cause the 1D model to propagate information coming from the 3D model to the 0D physiological model. At step3406, the system may cause the 0D physiological model to respond to the information provided by the 3D model and reflects a simulated physiological response to the information to the 1D model. At step3408, the system may cause the 1D model to provide to the 3D model boundary conditions that embody the physiological response.

FIG.35shows illustrative process3500for simulating the trial. Process3500may begin at step3502. At step3502, the system may receive a request from the 3D model to start the simulation. The request may include a transmission of a boundary condition file. At step3504, the system may determine whether a cumulative time of time steps performed by the 3D solver has reached Toutput, which may be a preset length simulation time for which the 3D model is to run. If at step3504, the outcome is “YES,” process3500may continue at step3506. At step3506, the 3D model may send a “STOP” file to the system. The file may be a “CLOUDSEND” message. The message may be transmitted to the system via network N. At step3508, the system may stop simulation activities. For example, the system may discontinue iteration of the 1D transport model solver. The system may discontinue iteration of the 0D physiological model solver.

If at step3504, the outcome is “NO,” process3500may continue at step3510. At step3510, the system may determine whether a sum of the cumulative time of time steps performed by the 3D model solver and dt3D, the length of a single simulated time step in the 3D solver, has exceeded Toutput. If the outcome of step3510is “YES,” process3500may continue at step3514. At step3514, the system may reset the length of dt3Dto the length of time by which Toutputexceeds the cumulative time.

If at step3510, the outcome is “NO,” process3500may continue at step3512. At step3512, the system may cause the 3D model and the 1D transport model to exchange boundary condition records. At step3516, the system may wait for the 3D model solver to evolve a solution based on boundary condition records received from the 1D transport model.

FIG.36shows illustrative process3600for conducting the digital trial. One or more steps of process3600may be performed in connection with step3512(shown inFIG.35). Process3600may begin at step3602. At step3602, the system may receive from the 3D model a boundary condition record for each 3D model outflow interface. The boundary condition record may include a 3D model simulated pressure. The boundary condition record may include a 3D model simulated substance concentration. The boundary condition record may correspond to current time. At step3604, the system may receive from the 3D model a boundary condition record for each 3D model inflow interface. The boundary condition record may include a 3D model simulated pressure. The boundary condition record may include a 3D model simulated substance concentration. The boundary condition record may correspond to current time.

At step3606, the system may cause the 1D transport model solver and the 0D physiological model solver to advance a time step dt3D.

At step3608, the system may receive from the 3D model a request for a boundary condition record for each 3D model inflow interface. The boundary condition record may include a 1D transport model simulated fluid flow rate. The boundary condition record may include a 1D transport model simulated substance concentration. (The substance concentration may be a substance concentration that the 1D transport model received from the 0D physiological model.) The boundary condition record may include a valued summed over 1D time steps corresponding in aggregate to dt3D.

At step3610, the system may receive from the 3D model a request for a boundary condition record for each 3D model outflow interface. The boundary condition record may include a 1D transport model simulated fluid flow rate. The boundary condition record may include a 1D transport model simulated substance concentration. (The substance concentration may be a substance concentration that the 1D transport model received from the 0D physiological model.) The boundary condition record may include a valued summed over 1D time steps corresponding in aggregate to dt3D.

At step3612, the system may resume process3500at step3516(shown inFIG.35).

FIG.37shows illustrative process3700for conducting the digital trial. One or more steps of process3700may be performed in connection with step3606(shown inFIG.36). Process3700may begin at step3702. At step3702, the system may set, for the 1D transport model, Toutput, which may be a preset length simulation time for which the 1D transport model solver is to run, to dt3D. The 1D transport model solver may thus be set to advance for a simulation time that is equivalent to one time step of the 3D solver. The system may set Time, which may be a counter to keep track of cumulative simulation time advanced by the 1D transport solver, to 0. At step3704, the system may assign to time step dt1Da magnitude that, based on a stability condition, such as a Courant-Friedrichs-Lewy (“CFL”) stability condition, may provide computational stability of mathematical operations performed by the 1D solver.

At step3706, the system may determine whether Time in the 1D transport model has become equal to Toutputof the 1D transport model. If at step3706, the outcome is “YES,” process3700may continue at step3708. At step3708, the system may resume process3600.

If at step3706, the outcome is “NO,” process3700continue at step3710. At step3710, the system may determine whether a sum of Time in the 1D transport model and dt1D, the length of a single simulated time step in the 1D transport model, has exceeded Toutputfor the 1D transport model. If the outcome of step3710is “YES,” process3700may continue at step3712. At step3712, the system may reset the length of dt1Dto the length of time by which Toutputof the 1D transport model exceeds Time in the 1D transport model.

If at step3710, the outcome is “NO,” process3700may continue at step3714. At step3714, the system may cause the 1D transport model and the 0D physiological model to exchange boundary condition records.

At step3716, the system may determine whether the simulation is to include a slave model. The slave model may include a slave 3D model. The determination may involve determining whether a slave model is registered in memory of a digital trial platform (such as504, shown inFIG.5). If at step3716, the outcome is “YES,” process3700may continue at step3718. At step3718, the system may perform steps3720and3722for each slave 3D model.

At step3720, the system may cause the 1D transport model and the slave 3D model to exchange boundary condition records. At step3722, the system may instruct the slave 3D model to advance for a duration of dt1D.

If at step3716, the outcome is “NO,” process3700may continue at step3724. At step3724, the system may apply boundary conditions records from the 0D physiological model to the inlets and outlets of the 1D transport model. At step3726, the system may cause the 1D transport model to advance for a time step dt1D. At step3728, the system may increment Time in the 1D transport model by dt1D.

FIG.38shows illustrative process3800for conducting the digital trial. One or more steps of process3800may be performed in connection with step3714(shown inFIG.37). Process3800may involve use of Riemann invariants at the 1D transport model outflow interfaces. Process3800may begin at step3802. At step3802, the system may request, of each component of the 0D physiological model that is logically connected to outlets (see512) of the 1D transport model, a boundary condition record. The boundary condition record may include a 0D physiological model solver simulated fluid pressure. The boundary condition record may include a 0D physiological model solver simulated substance concentration.

At step3804, the system may impose the 0D physiological model solver simulated fluid pressure at the 1D transport model outflow interfaces that are logically connected to the 0D physiological model inflow interfaces. At step3806, the system may calculate fluid flow at the 1D transport model outflow interfaces at a future time step dt1D. The system may calculate the fluid flow using a linear estimation. The system may calculate the fluid flow using an approximation.

At step3808, the system may provide to each 0D physiological model component, for all 1D transport model interfaces connected to the component, a sum of all 1D transport model fluid flows to the component, and, for each substance, a sum of mass flows to the component. The system may provide to the 0D physiological model, for all 1D transport model interfaces connected to the 0D physiological model, a sum of all 1D transport model fluid flows to the 0D physiological model, and, for each substance, a sum of mass flows to the 0D physiological model.

At step3810, the system may provide, to each component of the 0D physiological model that is logically connected to inlets (see512) of the 1D transport model, a boundary condition record. The boundary condition record may include a 1D transport model solver simulated fluid pressure. The boundary condition record may include a 1D transport model solver simulated substance concentration.

At step3812, the system may cause the 0D physiological model solver to advance one time step dt1D.

At step3814, the system may request, of each component of the 0D physiological model that is logically connected to an inlet (see512) of the 1D transport model, a boundary condition record. The boundary condition record may include a 0D physiological model solute flow rate. The boundary condition record may include a 0D physiological model simulated substance concentration.

At step3816, the system may resume process3700(shown inFIG.37).

FIG.39shows illustrative process3900for conducting the digital trial. One or more steps of process3900may be performed in connection with step3714(shown inFIG.37). Process3900may involve use of Riemann invariants at one or both of the 1D transport model outflow interfaces and inflow interfaces. Process3900may begin at step3902. At step3902, the system may request, of each component of the 0D physiological model that is logically connected to outlets (see512, shown inFIG.5) of the 1D transport model, a boundary condition record. The boundary condition record may include a 0D physiological model solver simulated fluid pressure. The boundary condition record may include a 0D physiological model solver simulated substance concentration.

At step3904, the system may impose the 0D physiological model solver simulated fluid pressure at the 1D model outflow interfaces that are logically connected to the 0D physiological model inflow interfaces. At step3906, the system may calculate fluid flow at the 1D transport model outflow interfaces at a future time step dt1D. The system may calculate the fluid flow using a linear estimation. The system may calculate the fluid flow using an approximation.

At step3908, the system may provide to each 0D physiological model component, for all 1D transport model interfaces connected to the component, a sum of all 1D transport model fluid flows to the component, and, for each substance, a sum of fluid flows to the component. The system may provide to the 0D physiological model, for all 1D interfaces connected to the 0D physiological model, a sum of all 1D transport model fluid flows to the 0D physiological model, and, for each substance, a sum of mass flows to the 0D physiological model.

At step3910, the system may request, of each component of the 0D physiological model that is logically connected to inlets (see512, shown inFIG.5) of the 1D transport model, a boundary condition record. The boundary condition record may include a 0D physiological model solver simulated fluid pressure. The boundary condition record may include a 0D physiological model solver simulated substance concentration.

At step3912, the system may impose the 0D physiological model solver simulated fluid pressure at the 1D transport model inflow interfaces that are logically connected to the 0D physiological model outflow interfaces. At step3914, the system may calculate flow at the 1D transport model inflow interfaces at a future time step dt1D. The system may calculate the flow using a linear estimation. The system may calculate the flow using an approximation.

At step3916, the system may provide to each 0D physiological model component, for all 1D transport model interfaces connected to the component, a sum of all 1D transport model fluid flows to the component, and, for each substance, a sum of fluid flows to the component. The system may provide to the 0D physiological model, for all 1D transport model interfaces connected to the 0D physiological model, a sum of all 1D transport model fluid flows to the 0D physiological model, and, for each substance, a sum of fluid flows to the 0D physiological model.

At step3918, the system may cause the 0D physiological solver to advance one time step dt1D.

At step3920, the system may resume process3700(shown inFIG.37).

FIG.40shows illustrative process4000for conducting the digital trial. One or more steps of process4000may be performed in connection with step3720(shown inFIG.37). Process4000may begin at step4002. At step4002, the system may request, of each slave 3D model that is logically connected to outlets (see512) of the 1D transport model, a boundary condition record. The boundary condition record may include a slave 3D model solver simulated fluid pressure. The boundary condition record may include a slave 3D model solver simulated substance concentration.

At step4004, the system may impose the slave 3D model solver simulated fluid pressure at the 1D transport model outflow interfaces that are logically connected to the slave 3D model inflow interfaces. At step4006, the system may calculate fluid flow at a future time step dt1Dfor the 1D transport model outflow interfaces logically connected with the slave 3D model. The system may calculate the fluid flow using a linear estimation. The system may calculate the fluid flow using an approximation.

At step4008, the system may provide, to each slave 3D model that is logically connected to outlets (see512) of the 1D transport model, a boundary condition record. The boundary condition record may include a 1D transport solver simulated fluid flow rate. The boundary condition record may include a 1D transport solver simulated substance concentration.

At step4010, the system may request, of each slave 3D model that is logically connected to inlets (see512) of the 1D transport model, a boundary condition record. The boundary condition record may include a slave 3D model solver simulated fluid pressure. The boundary condition record may include a slave 3D model solver simulated substance concentration.

At step4012, the system may impose the slave 3D model solver simulated fluid pressure at the 1D transport model inflow interfaces that are logically connected to the slave 3D model outflow interfaces. At step4014, the system may calculate fluid flow at a future time step dt1Dfor the 1D transport model inflow interfaces logically connected with the slave 3D model. The system may calculate the fluid flow using a linear estimation. The system may calculate the fluid flow using an approximation.

The approximations may include applying Riemann invariants, linear approximations from characteristic variable analysis, or any other suitable approximation.

At step4016, the system may provide, to each slave 3D model that is logically connected to inlets (see512) of the 1D transport model, a boundary condition record. The boundary condition record may include a 1D transport model solver simulated fluid flow rate. The boundary condition record may include a 1D transport model solver simulated substance concentration.

At step4018, the system may cause the slave 3D solver to advance for a duration of dt1D.

At step4020, the system may resume process3700(shown inFIG.37).

FIG.41shows illustrative process4100for conducting the digital trial. One or more steps of process4100may be performed in connection with step3726(shown inFIG.37). At step4102, the system may, for each border (seeFIG.6) of the control volumes in the 1D transport model, evaluate the Roe Matrix A. The control volumes may include computational elements, such as600(shown inFIG.6). The system may then solve the Classical Riemann Problem based on left and right states QLand QR. The system may then calculate the Godunov State Q*.

At step4104, the system may, for each terminal border (seeFIG.6), replace Q* with the quantities (see, e.g., Table 13) included in boundary condition records received from the 3D model, slave 3D models and 0D physiological models.

At step4106, the system may, for each interface of the control volumes, evaluate the Roe Matrix A in the left state QLand in the Godunov state Q*. The system may then define a left fluctuation as DLi=A*(Q*−QL).

At step4108, the system may, for each interface of the control volumes, evaluate the Roe Matrix A in the right state QRand in the Godunov state Q*. The system may then define the right fluctuation as DRi=A*(QR−Q*).

At step4110, the system may, for each control volume, calculate numerical source terms Si(set forth in Eq'n. 10).

At step4112, the system may apply a path conservative finite volume method for each control volume, in which Qin+1=Qin−dt1D/dx(Di−1R+DiL)+dt1DSi, wherein n corresponds to a time increment of dt1D.

At step4114, the system may return to process3700(shown inFIG.37).

FIG.42shows schematically illustrative simulated topology4200. Topology4200may include simulated junction4202. Junction4202may correspond to a junction such as664,666or668(shown inFIG.6). Junction4202may join channels such as channels4204,4206,4208and4210. Arrows shown alongside channels4204,4206,4208and4210indicate “branching direction.” “Branching direction” may provide a framework in which interconnections between channels and junctions may be topologically defined.

In 1D transport model508(shown inFIG.5), junction4202may be indexed as the v th of N simulated junctions in the simulated patient. Index i=1, 2, 3, . . . , m may index the channels, such as channels4204,4206,4208and4210, that are connected to junction v. In topology4202, illustrative i-values are shown as 1, 2, 3 and 4, with m=4. Branching direction β may be an indicator of branching direction: “1” for branching into junction v, “−1” for branching out of junction v. β may be based on a signum function.

FIG.43shows illustrative process4300for performing step4102(shown inFIG.41). Process4300may begin at step4302. At step4302, the system may identify control volumes that abut channel junctions v. At step4304, the system may associate each control volume abutting junction v with variables Ai, ui, θi, Ci,1, . . . , Ci,k. At step4306, the system may set a counter for index i to zero. At step4308, the system may determine whether the counter is greater than m. If the counter is not greater than m, process4300may proceed at step4310. At step4310, the system may determine if the channel branches into junction v. If at step4310, the system determines that the channel does not branch into junction v, process4300may continue at step4312. At step4312, the system may set βito −1. Process4300may continue at step4316.

If at step4310the system determines that the channel branches into junction v, the system may continue at step4314. At step4314, the system may set βito 1. Process4300may continue at step4316.

At step4316, the system may increment the counter to the next value of i. Process4300may continue at step4308.

If at step4308the counter for i is greater than m, process4300may continue at step4318.

At step4318, the system may define illustrative function F over the m control volumes that abut junction v. Terms included in F are described above. At step4320, the system may find the roots of F and values of the arguments of F identified in connection with step4318. The system may use Newton's Method to find the roots.

At step4322, the system may set values for θ*i.

At step4324, the system may set a counter for i to 0.

At step4326, the system may determine whether the counter is greater than m. If the counter is not greater than m, process4300may proceed at step4328. Fluid flow in a channel may have a direction that is coincident with the branching direction of the channel. Fluid flow in a channel may have a direction that is not coincident with the branching direction. At step4328, the system may determine if channel i has fluid flowing into junction v. If at step4328, the system determines that the fluid is not flowing into junction v, process4300may continue at step4330. At step4330, the system may set flow direction γito −1. γ may be an indicator of flow direction: “−1” for flow into junction v, “1” for flow out of junction v. γ may be based on a signum function.

If at step4328the system determines that the channel is flowing into junction v, the system may continue at step4334. At step4334, the system may set γito 1. Process4300may continue at step4332.

At step4332, the system may increment the counter to the next value of i. Process4300may continue at step4326.

If at step4326the counter for i is greater than m, process4300may continue at step4336. At step4336, the system may perform, for each channel i: step4338, either step4340or step4344, and step4342.

At step4338, the system may determine if γi=1. If at step4338γiis not equal to 1, process4300may continue at step4340. At step4340, the system may calculate illustrative values C* for each channel i, for each substance k. C* may include a weighted-average substance concentration based on substance mass inflow into junction v and fluid outflow from junction v. At step4342, the system may define the conserved values Q*iat the abutting interface as set forth in connection with step4342.

FIG.44shows illustrative process4400for conducting the digital trial. Process4400may include client process4402. Process4400may include cloud-computing process4452. Client process4402may be performed on by a client such as client1004(shown inFIG.10). Cloud-computing process4452may be performed by a platform such as cloud-computing services platform1002.

In process4402, at step4404, the master client may be connected to a 1D transport model via a graphical user interface. At step4406, the master client may launch the 1D transport model using launch files provided by a website such as platform504(shown inFIG.5). The files may include configuration files.

In process4452, at step4454, the system may receive the launch files. The system may respond to receipt of the launch files by creating an instance of one or both of the 1D transport model and the 0D physiological model. At step4456, the 1D model may link to the 0D physiological model. At step4458, the 1D model may send a “LOCALSEND” message to the 0D physiological model. The LOCALSEND message may be a include a “BOUNDARYCONDITION EXCHANGE” instruction. The BOUNDARYCONDITION EXCHANGE instruction may request a boundary condition record from the 0D physiological model. The LOCALSEND message may be a include a “MARCH” instruction. The MARCH instruction may instruct the 0D physiological model to advance through one or more 0D physiological model time steps.

At step4460, communication of boundary condition records between the 1D transport model and the 0D physiological model begins.

In process4402, at step4408, the master client may start 3D model software. At step4410, the 3D model software and the 1D model software may exchange configuration files. A counterpart step (not shown) in process4452may be performed. At step4412, communication between the 3D model and the 1D transport model may start through an API and a socket arrangement. A counterpart step (not shown) in process4452may be performed. At step4414, the 3D model software may initiate a simulation.

At step4416, the 3D model software may start the simulation and exchange information with the 1D transport model software.

In process4452, at step4462, the system may, via the 1D model, receive a request for information from the 3D model software. The 1D transport model may provide to the 3D model software the requested information. During the simulation, communication between the client and the cloud computing platform may be performed via “CLOUDSEND” messages. CLOUDSEND messages may include BOUNDARYCONDITIONEXCHANGE, for requesting or providing boundary condition records. CLOUDSEND messages may include MARCH, for instructing a solver to advance.

In process4402, at step4418, the 3D model software may conclude the simulation. The 3D model software may stop the 1D transport model software. The 3D model software may send to the 1D transport model software a CLOUDSEND STOP instruction.

In process4452, at step4464, the system may receive the STOP instruction. In response to the STOP instruction, the system may provide to the user computational results of the 1D transport model software. In response to the STOP instruction, the system may provide to the user computational results of the 0D physiological model software.

The results may be selected by the user. The results may include values of one or more variables, quantities, parameters or characteristics associated with the 1D transport model or the 0D physiological model. The results may be provided for one or more selected segments of the 1D transport model. The results may be reported for one or more selected computational elements of the 1D transport model. The results may be reported for one or more selected components of the 0D physiological model. The results may be reported for one or more selected time steps or ranges of time steps of the 1D transport model or the 0D physiological model.

At step4466, the system may turn off the server instances of one or both of the 1D transport model and the 0D physiological model.

FIG.45shows illustrative application-level architecture4500for conducting the digital trial. Architecture4500may have one or more features in common with architecture1000(shown inFIG.10). The digital trial may involve one or more of the steps set forth in connection with architecture4500. The steps may be performed in a manner that is consistent with a socket server protocol. The socket server protocol may include socket.io protocols. Architecture4500may include cloud computing platform4502. Architecture4500may include client side4503. Client side4503may include process interconnection program4504. Process interconnection program4504may include an API (such as API1006,1010or1014, shown inFIG.10). The API may be encoded in the JAVA programming language. Client side4503may include 3D model software4506.

A message transferred in architecture4500may include one or more of a configuration file, input to be transferred between the 1D transport model and the 0D physiological model, output to be transferred between the 1D transport model and the 0D physiological model, a file to be transferred between the 1D transport model and the 3D master model, a file to be transferred between the 1D transport model and the 3D master model, and any other suitable information.

Cloud computing platform4502may include calculation manager4508. Calculation manager4508may support a user interface with a digital trial platform (such as504, shown inFIG.5). Cloud computing platform4502may include computing engine4510.

Computing engine4510may support the 1D transport model and 0D physiological model on 1D transport model (such as model508, shown inFIG.5) and 0D physiological model (such as model506, shown inFIG.5) partition4511. Computing engine4510may include socket client digital trial platform partition4513. Socket client digital trial platform partition4513support the digital trial platform (such as digital trial platform504, shown inFIG.5). Computing engine4510may support the socket server (such as1020, shown inFIG.10) on socket server partition4515.

Calculation manager4508may be implemented as a calculation manager service, under the trade name EC2, that is available from Amazon Web Services, Seattle, Wash. Computing engine4510may be implemented as a computing instance service, under the tradename EC2, that is available from Amazon Web Services.

At step4514, the system may define a communication room for boundary condition file exchange. At step4516, the system may receive from the user an instruction to run the digital trial. At step4518, the system may display to a user of the 3D model an IP address corresponding to an instance initiated at step4520in computing engine4510. At step4522, the system may start the simulation. Step4522may be triggered by performance of step4516. At step4518, the system may cause calculation manager4508to provide the IP address to process interconnection program4504.

When step4520is triggered, the system may route an IP address for the instance to calculation manager4508. At step4524, the system may start a socket server, which may be a socket.io server. At step4526, the system may start a socket client. The client may be a socket.io client. At step4528, the system may begin to run one or both of the 1D transport model and the 0D physiological models.

At step4530, the system may determine that one or both of the 1D transport model and the 0D physiological model has a message to send. At step4532, the system may send the message through named pipes to the digital trial platform socket client. At step4534, the system may receive a message for the 1D transport model or the 0D physiological model.

At step4536, the system may cause the digital trial platform to connect the 1D transport model and the socket client through named pipes.

At step4538, the system may cause the digital trial platform partition to connect to the communication room instantiated by calculation manager4508. Instantiation of the room may be at the request of a user of the 3D model software.

At step4540, the system may cause the digital trial platform to read a message through a named pipe. The message may be from the 1D transport model or the 0D physiological model.

At step4542, the system may cause the digital trial platform to emit the message in a communication room. The system may define different rooms. The rooms may be defined at step4514using calculation manager4508. A “MASTER ROOM” may be defined for a master 3D model such as model M1(shown inFIG.10). A “SLAVE-1 ROOM” may be defined for a slave 3D model such as model MS1(shown inFIG.10). A “SLAVE-2 ROOM” may be defined for a slave 3D model such as model MS2(shown inFIG.10).

The user may identify in a file including a boundary condition record the room “from which” the user is to communicate with the 1D transport model or the 0D physiological model. One or both of the 1D transport model or the 0D physiological model may be coded in a high-level language, such as FORTRAN. The code may be configured to obtain the message from the room. The code may be configured to identify the source of the message based on the name of the room.

At step4544, the system may cause the digital trial platform to receive a message and forward it through named pipes. The system may cause the digital trial platform to receive the message from socket server partition4515. The system may cause the digital trial platform to forward the message to one or both of the 1D transport model and the 0D physiological model in partition4511.

At step4546, the system may cause the socket server to receive a message from the digital trial platform. The system may cause the socket server to emit the message to the 3D model software.

At step4548, the system may cause the socket server to receive a message from process interconnection program4504. The system may cause the socket server to emit the message to the digital trial platform.

At step4550, the user may start the API.

At step4552, the API may connect through named pipes to 3D model software4506.

At step4554, the user may insert the IP address of the generated instance into memory. The IP address may thus be saved for message routing.

At step4556, the user may insert into memory a name of the communication room to be used for exchange of boundary condition records.

At step4558, the API may connect to the socket server using the IP address.

At step4560, the API may connect to the communication room.

At step4562, the socket client may receive a message from the socket server. The client may forward the message through named pipes to the 3D model software.

At step4564, the API may receive a message from the 3D model software. The API may emit the message in the communication room.

At step4566, the user may start the 3D model software.

At step4568, the user may run a simulation.

At step4570, the 3D model software may connect through a named pipe to the API.

At step4572, the 3D model software may receive a message from the API.

At step4574, the 3D model software may have a message to send.

If at step4574the 3D model software has a message to send, the 3D model software may at step4576send the message through a named pipe to the API.

FIG.46shows illustrative view4600of illustrative user interface4600. A user of the 3D software may use user interface4600to provide, to digital trial platform504(shown inFIG.5), in field4602, an IP address. The IP address may be an address for the 3D software. Digital trial platform504may establish APIs904and906(shown inFIG.9) based on the IP address. The user may use control4604to connect to digital trial platform504. The user may use control4606to connect to computation platform902(shown inFIG.5).

FIG.47shows view4700in a state in which the 3D software has been connected to both digital trial platform504and computation platform902.

As will be appreciated by one of skill in the art, the invention described herein may be embodied in whole or in part as a method, a data processing system, or a computer program product. Accordingly, the invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software, hardware and any other suitable approach or apparatus.

Thus, methods and apparatus for simulating a trial of a medical device on a patient have been provided. Persons skilled in the art will appreciate that the present invention may be practiced by other than the described embodiments, which are presented for purposes of illustration rather than of limitation.