Patent Publication Number: US-2023162854-A1

Title: Automated triggers for electrophysiology case support

Description:
CROSS REFERENCE TO RELATED APPLICATION 
     This application claims the benefit of U.S. Provisional Patent Application No. 63/281,310, filed 19 Nov. 2021, which is incorporated herein by reference in its entirety. 
    
    
     FIELD 
     The present technology is generally related to automated triggers for case support that can occur during electrophysiology procedures. 
     BACKGROUND 
     Electrophysiology procedures are used to analyze, diagnose and/or treat cardiac electrical activities. Electrophysiology procedures usually take place in an electrophysiology (EP) lab or a catheterization (Cath) lab at a hospital or other medical facility. For example, an EP mapping procedure can be performed in an invasive procedure in which one or more electrode catheters are placed in or on the heart to measure electrophysiology signals. In an additional or alternative example, the EP mapping procedure may be performed using a non-invasive arrangement of electrodes distributed across an outer surface of the patient&#39;s body (e.g., on the thorax). In some cases, a clinical specialist may be present to provide guidance and technical support before, during, and/or after the EP procedure. The use of clinical specialists at the site of an EP procedure can result in significant expense due to salaries and travel and often is an inefficient use of the mapping specialist&#39;s time, especially in simple cases or when a case is canceled. 
     SUMMARY 
     The techniques of this disclosure generally relate to systems and methods for implementing automated triggers for case support during electrophysiology procedures. 
     In one aspect, the present disclosure provides one or more non-transitory machine-readable media to store data and instructions executable by one or more processors. The instructions are programmed to analyze workflow data for a given phase of a plurality of phases of an ongoing electrophysiology (EP) workflow implemented using a first computing apparatus. The instructions can also determine at least one support event based on the analysis of the workflow data and send a request to at least one remote support specialist responsive to determining the at least one support event. The instructions further can establish a communication link between the first computing apparatus and a second computing apparatus, which is associated with a respective remote support specialist, and enable user interaction with and control of the machine-readable EP workflow instructions on the first computing apparatus responsive to a user input by the respective remote support specialist at the second computing apparatus. 
     The details of one or more aspects of the disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the techniques described in this disclosure will be apparent from the description and drawings, and from the claims. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         FIG.  1    is a flow diagram that illustrates a method for triggering remote support for an electrophysiology encounter. 
         FIG.  2    is a block diagram that illustrates a system configured to implement automated triggers for electrophysiology case support. 
         FIG.  3    is a block diagram that illustrates software code programmed to implement automated triggers for electrophysiology case support. 
         FIG.  4    is a block diagram that illustrates further software functions programmed to implement the event detector of  FIG.  3   . 
         FIG.  5    is a block diagram that illustrates an example system architecture to implement automated triggers for electrophysiology case support. 
         FIG.  6    is a block diagram that illustrates another example system architecture with multiple remote specialists to implement electrophysiology case support. 
     
    
    
     DETAILED DESCRIPTION 
     This disclosure relates to systems and methods to automate triggers that can occur during electrophysiology (EP) procedures to implement case support by a remote specialist. As an example, a computing apparatus (e.g., and EP computer workstation) can store workflow data pertaining to an ongoing electrophysiology (EP) workflow session. The EP workflow session can have a plurality of phases, such as a pre-procedure phase and an intraprocedure (e.g., mapping and analysis) phase. The pre-procedure phase can involve electrodes being applied to the patient for measuring EP signals and geometry data being generated (e.g., from imaging or other geometry generating mechanism) to enable reconstruction of EP signals on a surface of interest. The intraprocedure phase can involve acquiring and processing of measured EP signals, selecting signals of interest and generating one or more EP maps on the surface of interest. 
     Systems and methods disclosed herein can be configured to implement automated triggers for support by a remote support specialist. For example, one or more support events can be determined based on an analysis of the workflow data for a given phase of the plurality of phases. The workflow data can relate to a user condition (e.g., stress level, body temperature or the like), user actions (e.g., user performing illogical steps, physiological changes in the patient (e.g., unexpected rhythm change or a change to a rhythm type related to a condition in which the user is not an expert. 
     The determination of a given support event can be used as a trigger for issuing a request for a remote support specialist. In response to determining such a support event, a request (e.g., a notification or message) can be sent to one or more remote support specialists responsive to detecting the support event. The request can be sent to one or more remote support specialists in response to the support event depending on the workflow data and the phase of the EP workflow. The support event may be detected based on determining an exception, complexity or ambiguity from the workflow data. 
     In response to a respective remote support specialist responding to the request (e.g., accepting the request from a second computing apparatus), a communication link can be established between the first computing apparatus and the second computing apparatus. After the link has been established, the first computing apparatus can be configured to enable remote user interaction with and control of the machine-readable EP workflow instructions on the first computing apparatus responsive to user inputs by the respective remote support specialist at the second computing apparatus. For example, the control of the EP workflow instructions can be transferred from the local operator to the remote support specialist. The remote support specialist can remotely control EP workflow instructions on the first computing apparatus in response to user input data provided at the second computing apparatus, such as to execute an upcoming event in the EP workflow and/or for revise (or regenerate) previously generated workflow data. The types of controls that may be implemented can vary depending on the phase of the EP workflow as well as can be implemented at the discretion of the remote support specialist. After the remote specialist has implemented the controls deemed necessary, control can be returned to the local operator (e.g., in response to control transfer user input instruction). 
     A bidirectional video and/or audio connection can also be used (e.g., over the same or another communications link) to enable real-time verbal communication between the remote support specialist and the local operator. The bidirectional video and/or audio connection can be implemented independently from the remote control function, which is activated responsive to determining a support event. Alternatively, the bidirectional video and/or audio connection can be provided each time a support event is detected. 
     The systems and methods disclosed herein thus can reduce costs in the overall EP workflow session because a reduced number of mapping specialists may be used to service a greater number of EP workflow sessions without requiring travel. For example, a given remote specialist further can implement remote control from the second computing apparatus for multiple instances of EP workflow sessions running on respective computing apparatuses (e.g., for different patients), which remote control functions can be implemented concurrently or sequentially. Additionally, the approach described herein can enable worldwide assistance by connecting specific specialists having particular expertise relating to a situation or problem encountered. 
       FIG.  1    is a flow diagram that illustrates an example method  100  for implementing automated triggers for case support by a remote support specialist. While for purposes of simplicity of explanation, the example method of  FIG.  1    is shown and described as executing serially, the example method  100  is not limited by the illustrated order, as some actions could in other examples occur in different orders, multiple times and/or concurrently from that shown and described herein. In an example, the method  100  is implemented as machine-readable instructions executed by a processor, such as by a computing apparatus (e.g., a local computer, a cloud-based computer or a computing apparatus that include hardware and/or software distributed between a local premise and a cloud computing architecture). As an example, the method  100  can be implemented by instructions being executed by one or more processors of a cardiac mapping system, such as the CardioInsight® mapping products (e.g., mapping vest and workstation) available from Medtronic of Minneapolis, Minn. USA. Further examples of cardiac mapping systems, which can implement the method  100  are disclosed in U.S. Pat. Nos. 8,478,393, 9,078,573, and 9,427,166, each of which is incorporated herein by reference. In other examples, other cardiac mapping systems can be programmed to implement the method  100  (e.g., the EnSite cardiac mapping system from Abbott or the CARTO system from Biosense Webster). That is, the systems and methods disclosed herein are applicable to nearly any form or configuration of EP mapping, recording or stimulation system. 
     At  102 , the method  100  includes analyzing workflow data during an EP workflow session, such as workflow data for a given phase of the plurality of phases of the EP workflow session. As used herein, the workflow data can include any data relating to a given electrophysiology (EP) workflow session that is being implemented for a respective patient using a first computing apparatus (e.g., a local computer or workstation). For example, workflow data can include patient data (e.g., patient demographic information, health history information and the like), image data (e.g., 3D anatomical image of the patient, such as including an arrangement of sensors on the patient&#39;s thorax), geometry data (e.g., describing spatial relationship between a patient&#39;s body surface and a surface of interest) and electrophysiological data (e.g., EP signal measurements) for a patient. The workflow data can also relate to the user, such a user condition and/or user actions (or omissions). The workflow data can be obtained during the EP workflow session or prior to the workflow session, depending on the type of data and how it is acquired. For example, workflow data describing a user condition can be based on determining a level of user stress (e.g., above a stress threshold). Workflow data describing user actions the user performing illogical steps within the software (e.g., indicating confusion or lack of knowledge on how to operate the system). Additionally, the system can track and store information, as part of the workflow data, representative of an experience and/or expertise of users and specialists. Thus, the system can determine a support event based on workflow data indicate a user (or local specialist) is not an expert or otherwise lacks experience related a patient condition (e.g., unexpected rhythm change or a change to a rhythm type). 
     At  104 , a support event is determined based on the analysis of the workflow data. The support event can represent any condition or part of the EP workflow session in response to which assistance from a remote specialist is to be requested. In an example, a given EP workflow session can include predetermined portions of the workflow session, each of which are represented by workflow status data indicating when such portion of the workflow is active or is expected to be active (e.g., it will be implemented next in the workflow). Certain portions of the workflow thus can be designated as requiring review and/or approval by a mapping specialist before proceeding to a next portion of the session, and a request (e.g., a notification) can be sent to obtain such approval from a remote specialist in response to detecting (based on the workflow status data specifying) when such portion of the workflow session is approaching or imminent. Another example of a portion of the workflow that can determine a support event is a final check of one or more maps or other generated EP data that is expected to be used to drive an intervention (e.g., treatment or therapy or implant). In addition, the system may allow the user to define which step or combination of steps will automatically generate a request for support based upon the expertise of the local team and/or user. 
     Support events further can also be determined from analysis of workflow data that includes EP information that is generated or derived during a respective phase in overall EP workflow session. As an example, in the pre-procedure phase, support events can include determining a need for assistance in anatomic segmentation of pre-procedure images in support of a given patient&#39;s case based on detecting an atypical anatomy for the patient (e.g., from image analysis or patient condition data). Additionally or alternatively, a confidence (e.g., a statistical value) can be computed with respect to the segmented image data, and a confidence value that is below a threshold value can specify a support event. In yet another example, a support event regarding image segmentation can be determined based on the image segmentation process taking an amount of time that exceeds a normal time period (e.g., which may be a statistical value or be an operator specific value). The pre-procedure phase can also determine support events associated with the improper placement and/or contact of sensors placed on the patient&#39;s body surface such as based on a determination of low channel integrity. 
     During the intra-procedure phase, support events can also be determined at  104  based on which one or more mapping functions the operator has invoked in response to a user input. For example, the operator data can specify a qualification (or experience) level with respect to each of the available mapping and analysis functions implemented by the computing apparatus. A support event thus can be determined at  104  in response to determining that the operator has selected a mapping or analysis function for which the operator has no experience or has an experience level that is below a threshold value. 
     As another example during the intra-procedure phase, a support event can be determined at  104  in response to determining that an electroanatomic map may be ambiguous (e.g., in which the map is determined to have a low confidence and/or incoherent portions). During the intra-procedure phase, for example, the method  100  can access stored electrophysiological data that is provided based on electrophysiological signals measured from a plurality of sensors positioned on an outer surface of the patient&#39;s body. Electrophysiological signals can be reconstructed on a surface of interest within the patient&#39;s body (e.g., by solving the inverse problem) based on the electrophysiological data and geometry data. Examples of inverse algorithms that can be utilized to reconstruct the EP signals on a surface of interest are disclosed in U.S. Pat. Nos. 7,983,743 and 6,772,004, which are incorporated herein by reference. 
     An indication of noise for the reconstructed electrophysiological signals on the surface of interest further can be computed and, if the indication of noise for the reconstructed electrophysiological signals exceeds a noise threshold, the method can determine a support event. Additionally, one or more graphical maps can be generated based on the reconstructed EP signals on the surface of interest, and a physiological coherence can be calculated from the graphical map. If the physiological coherence (e.g., noise) computed for the graphical map describes a coherence value that is below a respective threshold, the method can determine the support event 
     At  106 , the method includes sending a request to one or more remote support specialists responsive to determining at least one support event (at  104 ). The request can be sent from the computing apparatus (e.g., which is executing instructions to perform the method  100 ) directly to one or more remote support specialists, or the request can be sent to a server (or other messaging platform) to manage sending the request to one or more remote support specialists. One or more remote support specialists can receive the request at respective computing apparatuses, which can vary depending on the protocol used to send the request to the remote support specialists. As an example, the request can be sent as an email (e.g., using Simple Mail Transfer Protocol (SMTP), Internet Message Access Protocol (IMAP), or other email protocol), text message (e.g., using short message service (SMS) protocol) or other messaging formats. The second computing apparatus, which is used by the remote support specialist, can be a smart phone or device, a desktop computer, a laptop computer, a tablet computer or a workstation. Thus, the computing apparatus includes a user input device (e.g., touchscreen, keyboard, mouse and/or other) to enable the remote support specialist to accept the request in response to a user input through the user input device. 
     At  108 , the method  100  includes establishing a communication link between the first computing apparatus and the second computing apparatus, which is associated with a respective remote support specialist. The second computing apparatus can be the same computing apparatus at which the specialist received the request that was sent at  106 . Alternatively, the second computing apparatus can be different from the computing apparatus at which the specialist received the request that was sent at  106 . The communications link can provide a communications path through one or more networks, which can include local area networks, wide area networks or a combination of networks. The communications path can further include one or more of wireless data communications (e.g., Bluetooth, WiFi, cellular data) and/or communications over physical paths (e.g., electrically conductive wires or traces and/or optical fibers). The communications path can include one or more secure channels, such as using a secure shell (SSH) protocol, transport layer security and/or secure socket layer (SSL), to provide for bi-directional communications between the respect computing apparatuses. 
     In an example, the first computing device includes remote desktop software (e.g., machine readable instructions) programmed to implement remote desktop protocol (RDP) or other application sharing protocol (commercially available or proprietary) that is tunneled over SSH. The second computing apparatus thus connects to the first computing apparatus through the communications link. In an example where the connection is encrypted through a secure tunnel (e.g., SSH tunneling), an unencrypted protocol can be used to transmit information between the first and second computing apparatuses. Because the request includes data describing the support event, the remote support specialist can know the type of support that is needed at the current stage of the EP workflow session in advance. In some examples, a bidirectional video and/or audio connection is established, through which respective users can discuss current circumstances or other issues relating to the EP workflow session, including while rendering the remote support. 
     At  110 , the method includes enabling user interaction with and control of the machine-readable EP workflow instructions running on the first computing apparatus responsive to user input by the respective remote support specialist at the second computing apparatus. For example, the first computing apparatus implements the application sharing code to provide the second computing apparatus (e.g., the remote support specialist) a graphical user interface through which the remote support specialist can access and utilize the EP workflow software system running on the first computing apparatus. In some examples, control is transferred to the remote support specialist in response to a user input by the operator at the first computing apparatus. Alternatively, in other examples, control is transferred to the remote support specialist automatically responsive to the remote specialist invoking activation instructions provided with the request. 
     After control has been transferred, the first computing apparatus can receive instructions in response to user input instructions provided at the second computing apparatus to control execution the EP workflow instructions and/or workflow data at the first computing for an upcoming event or, if some instructions or functions need to be re-executed, to redo some or all of a past event. Additionally, in some examples, after the control is transferred, some level of controls can remain active at each of the first and second computing apparatuses (e.g., some or all control remains with the local operator), which further can enable collaboration in response to user inputs provided at each of the computing apparatuses. The graphics and control afforded the remote support specialist at the second (remote) computing apparatus can be the same or comparable to that which are rendered locally on the first computing apparatus (e.g., as if the specialist were co-located with the operator). After the remote support specialist has rendered assistance, full control may be returned to the local operator at the first computing apparatus. Alternatively, when the control is transferred, controls can remain active at second computing apparatus until the communication link has been terminated (e.g., in response to a user input by either user). 
       FIG.  2    illustrates an example computing system  200  that can implement the method  100 . Thus, the description of  FIG.  2    also refers to the method of  FIG.  1   . Additionally, further examples of support events that can be determined as well as further examples of workflow instructions that can be controlled by the support specialist through the communications link, which can be included in the method  100 , may be better appreciated with reference to the following description of  FIGS.  2 - 8   . 
     The computing system  200  of  FIG.  2    includes an EP system  202 . The EP system  202  can be implemented as any system configured to perform stimulation, perform ablation, measure EP signals, and/or perform mapping based on signal measurements, such as can be used in an EP laboratory. Examples of some types of EP system  202  are disclosed in U.S. Pat. Nos. 9,078,573, 9,427,166 and 10,076,260, each of which is incorporated herein by reference. In the example of  FIG.  2   , the system includes a sensor array  204  that includes one or more sensors configured measure EP signals from patient&#39;s body. For example, the sensor array  204  includes an arrangement of body surface sensors to measure EP signals non-invasively from an external body surface. One example of an arrangement of body surface sensors that can be used to implement the sensor array  204  is disclosed in U.S. Pat. No. 9,655,561, which is incorporated herein by reference. Other arrangements of body surface sensors can be used in other examples. In an alternative or additional example, the sensor array  204  can measure EP signals from within the patient&#39;s body, such as from a cardiac surface (e.g., by contact or non-contact sensors). 
     For example, the sensor array  204  includes a plurality input channels configured to receive electrical signals from respective electrical sensors (e.g., electrodes). In some examples, the input channels provide electrical signals representing EP signal measurements according to the location where the sensors are placed (e.g., non-invasively on the body surface and/or invasively within the patient&#39;s body). Each of the electrical sensors in the array  204  is coupled to an amplifier/interface  206  such through one or more connectors. The amplifier/interface  206  thus can receive signal measurements from any sensors in the array. The amplifier/interface  206  can be configured to amplify the signals from each of the sensors and provide a set of amplified electrical signals via an output to a computing apparatus  208 . The amplifier/interface  206  can include signal processing circuitry, such as for filtering signals to remove noise, and/or circuitry configured to convert the measured EP signals to corresponding digital signals. 
     In the example of  FIG.  2   , the computing apparatus  208  includes one or more processors  210 , memory  212  and a communications interface  214 . The memory  212  can include one or more forms of memory (e.g., one or more non-transitory computer readable media) configured to store data and machine readable instructions that can be accessed by the processor  210  through a bus structure. The processor thus can access data and execute respective instructions, including EP measurement and analysis software instructions, to perform functions and methods disclosed herein (see, e.g.,  FIGS.  1 ,  3  and  4   ). 
     A display  216  can be coupled with the computing apparatus  208 . The display can be coupled to a video interface (e.g., hardware and software) of the computing apparatus  208  through a cable. In some examples, the display can be integral with the computing apparatus  208 . The hardware and software implemented by the computing apparatus  208  are configured to control output data (e.g., information and graphics) that is provided to the display  216  for visualization. For example, the display  216  can include one or more of a monitor, projector, virtual reality headset or other type of display device. 
     The system  202  can also include one or more input devices  218 , such as a pointing device (e.g., a mouse or touch screen) and/or other input device (e.g., a keyboard or gesture control). A user thus can use the input devices  218  to interact with and control the computing apparatus  208  and instructions (e.g., GUI or other functions and methods) executed by the processor  210 . For example, instructions in the memory  212  include a user interface (e.g., a graphical user interface) that can enable a user to control the data acquisition process, analysis and generation of EP maps and other outputs. The display  216  may present the GUI and other visualization, and the user can enter commands and information into the computing apparatus through the input device  218  to enable interaction with the GUI and other functions and methods. 
     In some examples, the EP system  202  can also include a camera. The camera can include a microphone and be configured to capture real-time video and audio according to the field of view. For example, the video and audio can include a local operator at the site of the system  202 , such as for use during a video session with one or more remote support specialists (at another computing apparatus  222 ). The audio and/or video can be compressed to facilitate streaming thereof over a communications link. 
     The communications interface  214  is configured to connect the computing apparatus to a network  224  through a physical or wireless link, shown as  226 . The network  224  can include one or more local area network (LAN), a wide area network (WAN), such as the Internet, and/or any other type of or combination of computer networks. The computing apparatus  208  can include more than one communications interface  214  to enable connections to the network  224  through one or more respective communication links according to the physical and data link layer (e.g., Ethernet, WiFi, cellular data) being implemented by the respective interface(s). As described herein, in response to the computing apparatus determining a support event based on workflow data (e.g., stored in memory  212 ), a request is sent to one or more remote support specialists through the link (or through multiple links)  226 . 
     For example, one or more remote support specialists can each have access to one or more remote computing apparatus  222 . Similar to the computing apparatus  208 , the remote computing apparatus  222  can include a processor  228 , memory  230  and a communications interface  232 . The computing apparatus  222  can be coupled to the network  224  through a respective communications link, shown as  233 . In an example, a secure tunneling (e.g., using SSH) can be implemented in the connection  226 ,  224  and  233  between the computing apparatuses  208  and  222 . 
     The computing apparatus  222  can have the same or different configuration or form factor from the computing apparatus  208 . Additionally, the computing apparatus  222  can include or be coupled to a display  234  as well as one or more user input devices  236 . In some examples, the computing apparatus  222  can include or be coupled to a camera  238 , such as to provide for bi-directional communications with the computing apparatus  208  during an EP workflow session. The memory  230  can include instructions and data (e.g., a remote desktop client) configured to view and control the EP system  202  from the remote computing apparatus  222  (e.g., through a secure connection) in response to user inputs entered through the user input device  236 . 
     By way of further example,  FIG.  3    is a block diagram of the memory  212  that illustrates an example of data and instructions that can be stored in the memory. The data includes workflow data  302 . As described herein, the workflow data  302  can include any information associated with and/or describing electrical signal measurements, the sensing function or location of electrical sensors, one or more patient conditions, operator characteristics as well as other information that is input into the computing apparatus or derived from such information for the given EP workflow session. In the example of  FIG.  3   , the workflow data includes patient data  304 , image data  306 , geometry data  308  and EP data  310 . 
     Patient data  304  can include patient demographics, such as can be retrieved from an electronic health record or entered by the operator or assistant. For example, the patient data  304  can describe a known physiological condition or disease, and can include electrical and/or anatomical features. As a further example, the patient data can specify special circumstances indicative of a likely increased complex EP study due to complicating patient conditions. For example, the patient condition can describe an abnormal heart condition (e.g., Brugada syndrome). In another example, the patient condition data can specify a structural complicating issue, such as a congenital or other deformity, scar tissue from previous procedure or injury or an implanted medical device (e.g., pacemaker and/or defibrillator). As described herein, the existence of these and other complicating factors in the patient data  304  can be used to trigger a support event. 
     The image data  306  can include two-dimensional or three-dimensional image data acquired for the patient using a medical imaging modality. Examples of imaging modalities include ultrasound, computed tomography (CT), 3D Rotational angiography (3DRA), magnetic resonance imaging (MRI), x-ray, positron emission tomography (PET), fluoroscopy, and the like. In an example, the image data  306  is acquired using an imaging modality while a sensor array  204  is placed on the patient&#39;s body. In this way, the resulting image(s) in imaging data include both the patient&#39;s anatomy and the sensors in the array  204 . 
     The geometry data  308  is derived from the image data  306  to describe the spatial relationship for portions of the patient anatomy and the sensors in the array  204 . By way of further example, the geometry data  308  can include a representation of one or more geometrical surfaces, such as including a portion of an outer surface of the patient&#39;s body and a surface of interest within the patient&#39;s body. The geometry data  308  can describe 3D spatial coordinates for each of the sensors (e.g., centroids of respective sensors) as well as describe a surface of interest within the patient&#39;s body in a common coordinate system. As disclosed herein, the sensors can include body surface sensors in the sensor array  204  as well one or more invasive sensors positioned within the patient&#39;s body (e.g., affixed to a catheter or other probe). The surface of interest can correspond to a three-dimensional surface geometry corresponding to a surface of the patient&#39;s heart, which surface can be epicardial and/or endocardial. Alternatively or additionally, the surface of interest can correspond to a geometric surface that resides between the epicardial surface of a patient&#39;s heart and the surface of the patient&#39;s body where a sensor array has been positioned. Additionally, the geometry data  308  can correspond to actual patient anatomical geometry, a preprogrammed generic model, or a combination thereof (e.g., a model that is modified based on patient anatomy). 
     As an example, the geometry data  308  may be in the form of a graphical representation of the patient&#39;s torso. For example, a geometry manager  312  can be configured to manage and generate the geometry data  308 . The geometry manager  312  includes or otherwise is configured to use a segmentation control programmed to extract and segment anatomical features, including one or more organs and other structures, from a digital image set corresponding to the image data  306 . For example, the segmentation control  314  can perform thresholding or other operations to identify respective surfaces and surface boundaries in the image data  306 , including for the surface interest and the outer surface where the sensors are positioned. For example, the segmentation control  314  can be programmed to extract and segment each of the sensors in the sensor array  204 , such as an automatic segmentation method and/or in response to a user input, and store respective sensor locations in the geometry data  308 . Other non-imaging based techniques can also be utilized to obtain the position of the sensors in the sensor array, such as a digitizer or manual measurements, and the sensor locations can be registered in the spatial coordinate system with the surface of interest. Similarly, the geometry manager  314  can be programmed to identify locations on the surface of interest from the image data  306 , such as in response to a user input or through automated extraction and segmentation methods. Resulting spatial coordinates for the sensor locations and surface(s) of interest can be stored as the geometry data  308 . 
     In some examples, the geometry manager  312  can provide the geometry data  308  as a mathematical model (e.g., a mesh having respective vertices connected by line segments to define each surface), such as can be a generic model or a model that has been constructed based on the image data  306  for the patient. Appropriate anatomical or other landmarks, including locations for the sensors in the sensor array, can be identified and stored in the geometry data  308 . The identification of such landmarks can be done manually (e.g., in response to a user input) or automatically (e.g., via image processing techniques) and, in some examples, can be implemented by segmentation control  314  or other functions in the geometry manager  312 . 
     The EP data  310  includes electrophysiological signals measured by the sensors of the array  204 . In some examples, the EP data  310  can also include electrophysiological signals measured by one or more sensors within the patient&#39;s body. In some examples, the electrophysiological signals are acquired in real-time, such as during a procedure or study. For example, the EP data  310  can correspond to a real time data flow that can be acquired by non-invasive (e.g., body surface) sensors during a procedure such as during an electrophysiological study as well as during a treatment procedure that can include cardiac ablation. In other examples, the EP data  310  includes electrophysiological measurements acquired over an extended period of time prior to a procedure, such as by a Holter monitoring system or the like. As described herein, a signal processing function  316  can be applied to the EP data  310 . 
     The EP data can be raw EP signals or can have had pre-processing applied. For example, such pre-processing can include line-filtering, offset correction, analog-to-digital conversion and the like to remove selected noise components from the respective input channels such that the EP data  310  includes digital representations of the pre-processed signals for each input channel. The signal processing function  316  can be configured to perform additional filtering and signal analysis methods, such as can be configured in response to a user input (e.g., though user input device  218 ). The filtering can include notch, bandpass, high-pass and/or low-pass filtering. Signal analysis can include fast Fourier transform, and frequency domain analysis. Other signal processing functions can be implemented in other examples. 
     In addition to EP signals sensed from the patient&#39;s body surface, other sensors can be used to sense other patient conditions (e.g., heart rate, pulse rate, blood pressure, respiration rate, pulse oxygen level, etc.), which can also be stored as part of the workflow data  302 . The workflow data  302  can also include operator data for one or more operators utilizing the EP system  202 . For example, a user-operator can use the user input device  218  to login to the computing apparatus  208  and to an EP application, which can retrieve operator characteristics from memory (local or remote). Alternatively, the operator can manually enter relevant characteristics through the user input device  218 . Operator characteristics can include a qualification (or training) level of the operator with respect to each phase of the EP workflow session or conditions of the operator that can be sensed during the session. For example, when the operator logs into the computing apparatus, an operator profile can be retrieved based on the operator login information, which includes respective qualification levels. During the workflow session, cameras (e.g., infrared and/or visible light cameras)  220  can be used to monitor operator gestures and/or facial expressions (e.g., change in skin hue, temperature changes, heart rate changes) that are indicative of stress and/or anxiety. 
     The instructions also include a map generator  318  configured to generate a graphical map representing reconstructed electrophysiological signals on the surface of interest for one or more intervals. Thus, the map generator  318  can include a reconstruction engine  320  configured to reconstruct the electrophysiological signals on a surface of interest based on the geometry data  308  and the EP data  310 . 
     For example, the reconstruction engine  320  can be configured to compute an inverse solution to reconstruct electrophysiological signals on the surface of interest within the body of the patient based on the electrophysiological data  310  and the geometry data  308 . Examples of solutions to the inverse problem, which the reconstruction engine  320  can use, include a boundary element method (BEM) or a method of fundamental solution (MFS). In some examples, the inverse calculation can employ a transformation matrix, which is derived from the geometry data  308 , to reconstruct electrical activity sensed on the patient&#39;s body onto the surface of interest. Examples of inverse algorithms that can be utilized by the reconstruction engine  320  to implement the inverse solution include those disclosed in U.S. Pat. Nos. 7,983,743 and 6,772,004, each of which is incorporated herein by reference. The reconstruction engine  320  thus can reconstruct a body surface electrical activity measured via the sensors (e.g., the sensor array) on a body of the patient onto a multitude of locations (e.g., nodes distributed across on the surface of interest (e.g., an epicardial and/or endocardial surface). 
     The map generator  318  further may compute or derive one or more graphical maps from the reconstructed electrophysiological signals to provide an output on the display  216  and visualize features of the reconstructed signals across the surface of interest for one or more respective time intervals. For example, the map can include a potential map, a butterfly map, a phase map, a propagation map, and/or an activation map or other map, which type of map can be selected in response to a user input (e.g., though input device  218 ). The EP system  202  can be configured to provide the map (or maps) and can modify feature of such maps, such as in response to a user input selecting the type of map, one or more output parameters or signal intervals for processing and inclusion in the selected map. The map generator  318  can generate the map from real-time EP signals that are being acquired, or the map can be generated for a prior time interval, such as can be selected in response to a user input (e.g., using input device  218 ). 
     The instructions also include an event detector  322  programmed to detect a support event associated with the EP workflow based on the workflow data  302 . The event detector  322  can be programmed to detect support events based on the workflow data  302  for one or more phases of the EP workflow process, such as including patient/sensor setup, segmentation of imaging data, generating geometry data, EP data acquisition and mapping phases. Thus, the event detector  322  can generate support event data to describe the detected event. The support event data can be stored in the memory  212 , such as part of log for the EP workflow. The support event data can include an event name, supporting workflow data (or the results of analyzing the workflow data) to specify the cause (or causes) that triggered the event. Additional workflow data  302  can be store in memory  212  for the event part of the support event data, including logistic information (e.g., time, date, etc.), patient information (e.g., patient ID, condition, health information etc.), operator information (e.g., operator name/ID, affiliation, etc.) and the like. Additionally, the event detector can provide an indication of the detected support event can be provided to the operator, such as by providing a text, graphical and/or audio message on the display or other output of the system  202 . For example, a graphical element can be provided on a GUI of the display  216  to notify the operator of the detected support event. The graphical element can be a button or other GUI element that the operator can activate in response to a user input (e.g., using user input device  218 ), such as to decline the request, accept the request and/or acknowledge the support event. 
     A support request engine  324  can be programmed to generate and send one or more requests in response to the event detector detecting a support event. In an example, the request can include data specifying the support event that the event detector  322  has determined, such as based on the event support data. For example, the request data (and/or event support data) can be used to identify one or more support specialists who are qualified to render remote support for the detected support event. The request can also include a resource locator (e.g., a uniform resource identifier, such as a URL or other link) that can be used (in response to a user input) by a respective remote support specialist, who receives the request, to accept and initiate providing remote support. A support session can be established in response to (or when) the request is generated, in response to detecting the support event or in response to a remote specialist activating the session in response to a user input (e.g., through user input device  236  of a remote computing apparatus  222 ). In addition to describing the determined support event and enabling the recipient to access and connect to the local EP workflow session, the request can also specify operator information (e.g., operator identity, experience level etc.) as well as data describing the patient&#39;s condition. However, the request engine  324  can be configured to remove any personal and health-related information of the patient necessary to maintain HIPPA compliance and/or institutional security. 
     In some examples, the event detector  322  can be programmed to (as a default condition) designate one or more portions of the workflow as requiring review and/or approval by a mapping specialist before proceeding to a next portion of the session. Thus, in response to reaching such designated portion, the event detector  322  can trigger a support event, in response to which the support request engine  324  sends a request (e.g., a notification) to obtain approval from a remote specialist. Because, such pre-designated portions of the workflow are known in advance, the event detector can trigger the support event before reaching the designated event (e.g., generate the support event when the event is approaching or imminent). Another example of a portion of the workflow that can determine a support event is a final check of one or more maps or other generated EP data that is expected to be used to drive an intervention (e.g., treatment or therapy or implant). 
     In some examples, the support request engine  324  is resident on the local computing apparatus  208 . In other examples, the support request engine  324  resides on a remote computer, such as a server or cloud. In either configuration, the support request engine  324  can be configured to determine to which support specialists each request is sent. Alternatively, such as in the example where support request engine  324  resides locally on computing apparatus  208 , the support request engine  324  can send the request to a message service to control distribution of the request to one or more support specialist. The message service can be fully automated or it can be semi-automated such as using a person to select and control where each request is sent. The request can be sent based on availability, work schedules and other human resource parameters. In one example, the support request engine  324  is configured send the request to the respective remote support specialist based on the remote support specialist being a subject matter expert with respect to a condition of the patient, such as a particular abnormal heart condition. 
     The instructions can also include a user interface control  326 . The user interface control  326  is configured to establish a communication link between the first computing apparatus and a second computing apparatus, which used by a respective remote support specialist. For example, the remote specialist can activate a link (e.g., URL or other resource identifier), which is provided in the request received by the remote support specialist, to accept and activate the request. As mentioned, the request can be sent using a messaging protocol to send the request (e.g., an email, text, SMS or the like) to one or more remote support specialists. In response to activating the link at the specialists computing apparatus, the communication link can be established to remotely connect the specialist&#39;s computing apparatus to the EP system  202 , such as described herein. 
     The user interface control  326  can also be configured to enable user interaction with and control of the machine-readable EP workflow instructions (in memory  212 ) executing on the computing apparatus  208  responsive to a user input (through user input device  236 ) by the respective remote support specialist at the second computing apparatus  222 . For example, the computing apparatus  208  of the EP system  202  executes the user interface control  326  to implement an application sharing protocol (e.g., RDP) that is tunneled over SSH through a network architecture. As a result, the remote support specialist can control the functions of the EP system  202  running on the local computing apparatus  208 . 
     As shown in  FIG.  4   , the event detector  322  further can include analysis functions configured to determine the occurrence of one or more support events based on workflow data  302  during respective phases in EP workflow session. For example, the event detector  322  includes a segmentation quality calculator  402 . The segmentation quality calculator  402  is programmed to compute a quality score based on a segmentation performed (e.g., by segmentation control  314 ) on the image data  306 , which was acquired pre-procedure. For example, the segmentation quality calculator  402  is configured to evaluate the segmentation quality based on one or more of following characteristics of the segmented structure or structures: unknown structure and/or shapes (e.g., valves, LADs, CS); smoothness of cardiac surfaces; a relative alignment with CT volume; an alignment with one or more templates; the time period to complete the segmentation, etc. The scoring methods can be updated as more templates and/or more segmented geometries are scored. 
     The segmentation quality calculator  402  can compare the quality score relative to a segmentation quality threshold and determine the occurrence of a segmentation support event responsive to the comparison. For example, consistency of the segmentation can be compared to a particular gray scale threshold on the medical imaging modality used. Alternately or additionally, the rendered anatomy can be compared to a database to seek deviations beyond a particular threshold for surface area, volume, or similar parameters. After the remote specialist has connected to the EP workstation during the current workflow, the instructions in memory  212  can enable the respective remote specialist to implement the segmentation control  314  to perform another image segmentation on the image data  306  through the communication link responsive to a user input at the remote computing apparatus  222 . As a result, the image data can be segmented remotely to provide segmented image data that is stored in memory  212  of the first computing apparatus  208 . During the process, the remote support specialist can describe the process and educate the operator to reduce the likelihood of the same support event being triggered again. 
     The event detector  322  can also include a channel integrity function  404 . The channel integrity function  404  is programmed to determine one or more indications of channel integrity for each of the input signal channels providing EP signals for respective sensors of array  204 . For example, the channel integrity function  404  uses the signal processing function  316  to analyze the EP data  310  to ascertain the integrity of respective sensors positioned on an outer surface of a patient&#39;s body. The signal processing function thus can perform signal processing on the EP data  310  to extract one or more components from the measured electrophysiological signals. The event detector  322  thus can trigger the support event to cause the request to be sent to the respective remote support specialist based on the extracted one or more components. 
     In another example, the channel integrity function  404  can be configured to determine a value representing the acceptability and/or integrity of some or each of the respective channels that provide the EP data  310 . As an example, the channel integrity function  404  can be programmed to determine channel integrity for some or all EP sensors in the array  204  that have been placed on the patient&#39;s body, such as according to any of the approaches described in U.S. Pat. Nos. 9,977,060 and/or 10,874,318, each of which is incorporated herein by reference. Thus, the event detector  322  can trigger the support event to cause the request to be sent to the respective remote support specialist based on the determined channel integrity. 
     The event detector  322  can also include a channel noise calculator  406 . For example, the signal processing function  316  can be programmed to compute an indication of signal to noise (SNR) for respective signal channels (a selected set or all of the channels). The channel noise calculator  406  can evaluate the computed SNR values relative to a threshold to determine if channel noise exceeds a noise threshold. If the noise exceeds the noise threshold, the event detector  322  thus can trigger the support event to cause the request to be sent to the respective remote support specialist based on the noise level. 
     In another example, the channel noise calculator  406  can be programmed (e.g., include a sensor confidence map generator) to generate a confidence map of the respective sensors positioned on the outer surface of the patient&#39;s body based on the computed SNR or other indication of channel noise. The event detector can determine a support event based on the confidence map indicating a low confidence level across the body surface (as compared to a confidence threshold). The confidence threshold can vary depending on the type of mapping functions being implemented and/or the region of interest within the patient&#39;s body. For example, a low confidence in one region of the body surface may adversely affect a map of a first region of the heart (e.g., noisy section of the output map) but have little or no impact on the map within a second (different) region of the heart. 
     As a further example, the channel noise calculator  406  can invoke the signal processing function  316  to perform signal processing extract P-waves from the electrophysiological signals based on amplitude and frequency thereof. The signal processing function  316  can also perform FFT on the extracted P-waves and analyze spectral features in the extracted P-waves. The channel noise calculator  406  can be programmed to identify baseline noise in the electrophysiological signals (e.g., by averaging noise across the body surface or a portion thereof) and compare the amplitude of the P-waves to with respect to the baseline noise. A support event can be determined if the P-wave amplitudes are too small (e.g., below a threshold). For example, the P-wave threshold can be applied locally or regionally in neighborhoods, such as to account for far-field interference or other localized noise features. 
     The event detector  322  can also include a map evaluator function  410  programmed to determine the occurrence (or non-occurrence) of a support event based on an evaluation of one or more maps generated by the map generator  318 . As described herein, the electrophysiological data  310  is provided based on electrophysiological signals measured from sensors of the array  204  positioned on an outer surface of a patient&#39;s body. The map generator  318  employs reconstruction engine  320  to reconstruct electrophysiological signals on a surface of interest within the patient&#39;s body based on the EP data  310  and geometry data  308 . One or more maps can be generated with or derived from the reconstructed EP signals. The map evaluator function  410  can evaluate such maps or derivations thereof to determine whether to trigger a support event. 
     For example, the map evaluator function  410  can include a map noise calculator  412  programmed to compute an indication of noise for the reconstructed electrophysiological signals on the surface of interest. The noise can be a global indication of noise across the surface of interest or it can be computed regionally for respective regions of interest distributed across the surface of interest. The event detector  322  thus can determine a support event to trigger sending a request to respective remote support specialist(s) based on the indication of noise computed for the reconstructed electrophysiological signals. 
     In another example, the map noise calculator  412  can be programmed to compute a physiological coherence across a graphical EP map according to arrangement and distribution of pixel values (e.g., set according to a color scale). The event detector  322  thus can determine a support event to trigger sending a to the respective remote support specialist based on the physiological coherence of the graphical map. 
     The map evaluator function  410  can also include a signal-to-map correlation function  414  programmed to compute a correlation between the EP data  310  and a map generated from the EP data for a common time interval (or intervals). The correlation function  414  For example, EP signals for a subset of sensors distributed across the body surface can be correlated with respect to signals for a subset of nodes across the surface of interest. The numbers of signals can be the same or different, and may include less than all or up to all the respective measured and reconstructed signals. In one example, the correlation function  414  can invoke the map generator to generate a phase map for the set of reconstructed electrophysiological signals on the surface of interest. The correlation function can compute a correlation between the phase map and the measured EP signals. If the correlation indicates that the phase map is not aligned with the phase of the measured EP signals (e.g., a phase shift exceeds a threshold), the event detector  322  can determine a support event to trigger the request engine to send a request to one or more support specialists based on the correlation between the phase map and the measured electrophysiological signals. 
     In another example, the support request engine  324  can be programmed to route the request to a respective remote support specialist based on a type of map that the operator has selected from a plurality of available map types (e.g., in response to a user input instruction to the map generator  318 ). For example, the request can include data specifying a type of the map, such that support specialists having a higher level of experience with certain types of maps can be matched with requests specifying those types of maps. 
     In another example, the map generator  318  includes GUI elements to enable an operator of the first computing apparatus  208  to retain or discard each map that is generated in response to a user review input instruction (e.g., using input device  218 ). The EP application further can include instructions to determine a number of maps retained by the operator relative to a number of maps that the operator has discarded or tagged as being undecided in response to user review input instructions. The event detector  322  further can be programmed to determine a support event and trigger the request engine to send a request to one or more support specialists based on the number or ratio of maps being retained and discarded or tagged as undecided. 
       FIGS.  5  and  6    are block diagrams showing respective system architectures for different scenarios. In  FIG.  5    a given remote specialist is shown to provide remote support from a respective computing apparatus with respect to multiple EP systems being implemented concurrently at different locations. In  FIG.  6   , multiple (P) remote support specialists are shown for providing remote support from respective computing apparatuses with respect to multiple (M) EP systems being implemented concurrently at different locations, where M and be can be the same or different. 
     It should be understood that various aspects disclosed herein may be combined in different combinations than the combinations specifically presented in the description and accompanying drawings. It should also be understood that, depending on the example, certain acts or events of any of the processes or methods described herein may be performed in a different sequence, may be added, merged, or left out altogether (e.g., all described acts or events may not be necessary to carry out the techniques). In addition, while certain aspects of this disclosure are described as being performed by a single module or unit for purposes of clarity, it should be understood that the techniques of this disclosure may be performed by a combination of units or modules associated with, for example, a medical device. 
     In one or more examples, the described techniques may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include non-transitory computer-readable media, which corresponds to a tangible medium such as data storage media (e.g., RAM, ROM, EEPROM, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer). 
     Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the term “processor” as used herein may refer to any of the foregoing structure or any other physical structure suitable for implementation of the described techniques. Also, the techniques could be fully implemented in one or more circuits or logic elements.