Urinary flow rate detector

Abstract

This application relates to methods and systems for the capture of an audio recording of urination and the analysis of said audio recording to predict one or more uroflowmetry parameters. The analysis comprises a pre-processing step with a dereverberation subsystem and / or microphone correction subsystem and a processing step using a machine learning subsystem. Further downstream processing may be performed on the uroflowmetry parameters to provide a patient-specific assessment. The recording may be made in a private setting and the analysis performed remotely, such that a uroflowmetry analysis may be performed for a patient without the patient having to visit a clinic.

Description

[0001] Urinary Flow Rate Detector

[0002] Field

[0003] The present disclosure relates to systems and methods for analysing sound recordings of urine flow and predicted uroflowmetry parameters such as flow rates.

[0004] Background

[0005] Lower urinary tract symptoms (LUTS) are hugely prevalent in men. The most common cause is benign prostatic hyperplasia (BPH). Prevalence of LUTS in the UK is 13% for men aged 40-49 years, and rises to 43% of those aged 60-69, i.e around 3 million men. Across Europe, 30% of men over 50 years (i.e. around 26 million men) experience bothersome LUTS. The estimated global prevalence rose from 51 .1 million men in 2000 to 94 million in 2019.

[0006] Access to urological care is limited by low capacity in health services and a high demand for treatment. Typically, the patient assessment pathway is protracted and congested. In the UK, men face a lengthy wait for a general practitioner (GP) consultation. They may require multiple GP reviews whilst lifestyle and medical managements are trialled. If specialist review is required, patients face further delays due to hospital pressures. Upon access to a urology clinic, men may be tested using uroflowmetry. Uroflowmetry is a non- invasive diagnostic test which measures the rate of urination. A uroflowmeter calculates a flow rate over time and uses this to calculate other uroflowmetry parameters such as maximum flow rate, average flow rate, time to maximum flow, total voiding time, and flow rate as a function of time. The uroflowmetry parameters can be used to identify urinary problems.

[0007] There are challenges with the generation and interpretation of uroflowmetry data. When a patient has an appointment, they first need to fill their bladder before an assessment, which can be difficult to organize when the urology appointment time is predetermined. This means that appointments may run late. Furthermore, a patient may not urinate naturally in a clinical setting due to embarrassment or anxiety. In addition, uroflowmetry tests are typically taken at a single time point, which may not be adequate to characterise

[0008] 38186463-1 the urine flow of a patient. Without accurate and representative test results, patients may not receive appropriate care.

[0009] Sonouroflowmetry is anapproach to uroflowmetry whereby of the sound of the urine flow is analysed to estimate uroflowmetry parameters. Krhut J, Gartner M, Sykora R, Hurtfk P, Burda M, Lunacek L, et al. Comparison between uroflowmetry and sonouroflowmetry in recording of urinary flow in healthy men. Int J Urol. 2015 Aug;22(8):761-5. demonstrates the feasibility of sonouroflowmetry but notes that further development of the technology is required.

[0010] Summary

[0011] The present application provides an improved method and system for determining uroflowmetry parameters by sonouroflowmetry using a machine learning approach. The approach described herein pre-processes a version of audio data of urination with a dereverberation subsystem and / or a microphone correction subsystem to improve the quality of the data such that uroflowmetry parameters may be more accurately predicted.

[0012] According to first aspect, a computer-implemented method for analysing audio data of urination is provided. The method comprises receiving audio data of urination; preprocessing a version of the audio data with a dereverberation subsystem and / or a microphone correction subsystem to obtain pre-processed audio data; and processing the pre-processed audio data with a machine learning subsystem to predict one or more uroflowmetry parameters.

[0013] The one or more uroflowmetry parameters may comprise one or more flow rates. Each of the one or more flow rates may correspond to a respective time steps in the audio data.

[0014] The version of the audio data may be the audio data or a version of the audio data that has already undergone pre-processing to correct for a distortion with one of the microphone correction subsystem or the dereverberated subsystem. In further detail, the version of the audio data may be one of: the audio data, a microphone corrected version of the audio data, or a dereverberated version of the audio data. Optionally, the

[0015] 38186463-1 version of the audio data may be in segments that are predicted as corresponding to the sound urination.

[0016] Optionally, the pre-processing requires pre-processing the version of the audio data with the dereverberation subsystem, wherein pre-processing the version of the audio data with the dereverberation subsystem comprises: processing the version of the audio data using the dereverberation subsystem to obtain a dereverberated version of the audio data.

[0017] The dereverberation subsystem removes reverberation, or echo, from the version of the audio data that it processes.

[0018] Optionally, the dereverberation subsystem comprises a U-net, wherein pre-processing the version of the audio data with the dereverberation subsystem comprises: processing a representation of the version of the audio data as a spectrogram using the U-net to obtain the pre-processed audio data for processing with the machine learning subsystem.

[0019] Optionally, the method further comprises: receiving second audio data, wherein the second audio data comprises a spectrogram based upon one or more recordings of impulsive sounds, and wherein processing the representation of the version of the audio data as the spectrogram using the U-net comprises processing a combination of the spectrogram and the second audio data represented as a second spectrogram using the U-net to generate the pre-processed audio data, wherein the pre-processed audio data comprises a spectrogram.

[0020] Optionally, the pre-processing requires pre-processing with the microphone correction subsystem, and wherein pre-processing with the microphone correction subsystem comprises: processing the version of the audio data using the microphone correction subsystem to correct the version of the audio data for the microphone used to capture the audio data.

[0021] 38186463-1 The microphone correction subsystem is trained to compensate for variations between the characteristics of multiple different types of microphone associated with multiple different types of device used to capture the audio data.

[0022] Optionally, processing the version of the audio data with the microphone correction subsystem does not require the type of microphone or device to be known; and compensates for variations between the different types of microphone.

[0023] Optionally, the microphone correction subsystem comprises a second U-net, wherein pre-processing the version of the audio data with the microphone correction subsystem comprises: pre-processing a representation of the version of the audio data as a spectrogram using the second U-net to generate pre-processed audio data, wherein the pre- processed audio data comprises a spectrogram.

[0024] Optionally, obtaining the pre-processed audio data comprises either: i) processing the audio data using the dereverberation subsystem to remove reverberation from the audio data to generate a dereverberated version of the audio data, and then processing the dereverberated version of the audio data using the microphone correction subsystem to correct the dereverberated version of the audio data for the microphone used to capture the audio data to obtain the pre-processed audio data for processing with the machine learning subsystem; or ii) processing the audio data using the microphone correction subsystem to correct the audio data for the microphone used to capture the audio data to generate a corrected version of the audio data, and then processing the corrected version of the audio data using the dereverberation subsystem to remove reverberation from the audio data to obtain the pre-processed audio data for processing with the machine learning subsystem.

[0025] The input and output of the dereverberation subsystem and the microphone correction subsystem may each comprise a respective spectrogram.

[0026] Optionally, the method further comprises: receiving an audio recording of urination;

[0027] 38186463-1 converting the audio recording to audio data, wherein the audio data comprises a spectrogram representation of the audio recording.

[0028] Optionally, the method further comprises: processing the version of audio data, or the pre-processed audio data, with a flow detection subsystem to identify time windows in the version of the audio data or the pre- processed audio data that are predicted as corresponding to urination; wherein processing the pre-processed audio data with a machine learning subsystem comprises: processing respective segments of pre-processed audio data with the machine learning algorithm corresponding to the time windows predicted as corresponding to urination with the machine learning subsystem to predict one or more uroflowmetry parameters.

[0029] The flow detection subsystem can be applied at any point of the pre-processing before processing with the machine learning subsystem. The flow detection subsystem may therefore identify time windows that predicted as corresponding to urination in the audio data, a microphone corrected version of the audio data, a dereverberated version of the audio data, or a microphone corrected and dereverberated version of the audio data, and segment the data from which the time windows were identified accordingly. Only the respective segments that are predicted as corresponding to urination are processed by the downstream subsystems. Therefore, dependent on at what point the flow detection subsystem is applied, the dereverberation subsystem and / or microphone correction subsystem may process either a single spectrogram or respective spectrogram segments that are predicted as corresponding to urination. At whichever point the flow detection subsystem is applied, the machine learning subsystem processes respective segments of pre-processed audio data.

[0030] As a result, each of the following pre-processing sequences are possible to obtain pre- processed audio data for processing with the machine learning subsystem: i) The audio data is processed by the flow detection subsystem to result in segments of audio data predicted as corresponding to urination. Segments of a version of the audio data predicted as corresponding to urination are pre-processed by the microphone correction and / or dereverberation subsystem to result in segments of a dereverberated

[0031] 38186463-1 and / or microphone corrected version of the audio data for processing with the machine learning subsystem. ii) The microphone corrected version of the audio data is processed by the flow detection subsystem to result in segments of microphone corrected audio data predicted as corresponding as urination. If processing with the dereverberation subsystem is not subsequently performed, the segments of microphone corrected audio data are the segments of pre-processed audio for processing with the machine learning subsystem. If processing with the dereverberation subsystem is subsequently performed, the dereverberation subsystem processes respective segments of microphone corrected audio data predicted as corresponding as urination to obtain respective segments of dereverberated and microphone corrected audio data for processing with the machine learning subsystem. iii) The dereverberated version of the audio data is processed by the flow detection subsystem to result in segments of dereverberated audio data predicted as corresponding as urination. If processing with the microphone subsystem is not subsequently performed, the segments of dereverberated audio data are the segments of pre-processed audio data for processing with the machine learning subsystem. If processing with the microphone correction subsystem is subsequently performed, the microphone correction subsystem processes respective segments of dereverberated audio data predicted as corresponding as urination to obtain respective segments of dereverberated and microphone corrected audio data for processing with the machine learning subsystem. iv) The dereverberated and microphone corrected audio data is processed by the flow detection subsystem to result in segments of dereverberated and microphone corrected audio data for processing with the machine learning subsystem

[0032] Optionally, the flow detection subsystem comprises a second convolutional neural network, wherein processing the version of the audio data, or the pre-processed audio data, with the flow detection subsystem comprises: processing the version of the audio data, or the pre-processed audio data, with the second convolutional neural network to generate a sequence of probabilities, each of the probabilities indicating if the audio data, or pre-processed audio data, at respective time chunks corresponds to the sound of urination, and determining the time windows based upon the time chunks.

[0033] 38186463-1 Optionally, the time windows that are identified as corresponding to urination are selected such that they have time duration above a predetermined threshold.

[0034] Optionally, the method further comprises: detecting the presence of background noise in data associated with the audio data at one or more timesteps; updating the uroflowmetry parameters corresponding to the one or more timesteps.

[0035] The data associated with the audio data is obtained by generating overlapping frames of the audio recording and converting each of the overlapping frames to a spectrogram representation.

[0036] Optionally, updating the uroflowmetry parameters at the detected one or more timesteps comprises: interpolating from uroflowmetry parameters at timesteps in which the corresponding audio data are not detected as comprising background noise.

[0037] Optionally, the presence of background noise is detected using a third convolutional neural network, and wherein detecting the presence of background noise in the audio data comprises: processing the data associated with the audio data with the third convolutional neural network to output a probability that data associated with the audio data at respective timesteps comprises background noise.

[0038] Optionally, the method further comprises: analysing the one or more uroflowmetry parameters with patient specific data to provide a urological assessment.

[0039] Optionally, the audio data corresponds to a recording made at one time point for a patient, the method further comprising: comparing the one or more uroflowmetry parameters with one or more other uroflowmetery parameters obtained for the patient for one or more previous recordings to provide a longitudinal patient assessment.

[0040] 38186463-1 According to a second aspect there is provided a system comprising at least one processor; and a non-transitory computer readable medium comprising instructions that, when executed by the at least one processor, cause the system to perform a method.

[0041] According to a third aspect there is provided a non-transitory computer-readable medium storing instructions that, when executed by at least one processor, cause a computing device to perform a method.

[0042] Brief Description of Figures

[0043] Arrangements of the present disclosure will be understood and appreciated more fully from the following detailed description, made by way of example only and taken in conjunction with drawings in which:

[0044] Figure 1 illustrates a computer network comprising a plurality of audio devices suitable for the recording of audio data. Each of the audio devices are connected to one or more servers suitable for the processing of audio data;

[0045] Figure 2 illustrates a computing device suitable for use as any of the one or more servers or plurality of audio devices of Figure 1 ;

[0046] Figure 3 illustrates the server connected to an audio device in further detail;

[0047] Figure 4 is a method to predict uroflowmetry parameters based upon an audio recording of urination;

[0048] Figure 5 is a method to pre-process an audio recording of urination by removing portions of the audio recording that do not correspond to urine flow;

[0049] Figure 6 shows schematically a block diagram showing, on the left side, the preprocessing of an audio recording and the prediction of uroflowmetry parameters, and on the right side, the detection of background noise in the audio recording and the updating of the uroflowmetry parameters based upon the detected background noise.

[0050] Description

[0051] The present application provides an improved system and method for the prediction of uroflowmetry parameters from an audio recording of urination. The systems and methods disclosed herein allow for a patient to record audio data of urination in a private setting, and therefore the recorded urine flow may be more typical or natural for the patient. The

[0052] 38186463-1 audio recording is analysed remotely to predict uroflowmetry parameters. This offers convenience for the patient, since they can have uroflowmetry parameters recorded without having to visit a urologist in a clinical setting. This may encourage the patient to record their urination more frequently, which facilitates the monitoring and assessment of the patient.

[0053] There are challenges to the interpretation of an audio recording of urination. When analysing audio recordings taken by different patients, there will be inherent differences in the recording due to the room in which the recording took place, which will have its own acoustic characteristics. There will also be characteristics in the audio recording which arise due to the type of microphone used for the recording, and these characteristics will vary dependent between different types of microphone. Furthermore, a recording may not comprise a continuous signal corresponding to urination from start to finish of the recording. These characteristics in the audio data may make lead to inaccurate predictions of uroflowmetry parameters. .

[0054] The embodiments described herein overcome these challenges by pre-processing the audio data by one or more algorithms to compensate for dereverberation and / or to correct for the type of microphone used. A machine learning subsystem processes the pre-processed audio data to predict uroflowmetry parameters. Optionally, a flow detection subsystem may identify time windows in a version of the audio data, or pre- processed audio data, that corresponds to urination, such that only segments of the pre- processed audio data that are predicted as corresponding to urination are processed by the machine learning subsystem. A background noise correction subsystem may correct the uroflowmetry parameters for background noise. Further uroflowmetry parameters can then be predicted. The embodiments described herein further provide for a personalised patient assessment based on the predicted uroflowmetry parameters and other medical information. These algorithms allow patients to undergo a clinic-standard uroflowmetry assessment from the convenience of their homes.

[0055] Figure 1 illustrates a network environment 100 for producing an audio recording of urination and remote analysis of the audio recording to predict uroflowmetry parameters. The network environment comprises a plurality of audio devices 1 10a-1 10n each connected to a server 130 via a network 140. The server 130 may be one server or a plurality of servers. The network 140 is any type of wired or wireless network suitable for

[0056] 38186463-1 allowing communication between each of the plurality of audio devices 110a-110n and the server 130. In one embodiment, the network environment 100 is a cloud computing environment and the server 130 is connected to the one or more audio devices 110a- 1 1 On via a cloud network 140. The one or more servers 130 can each be situated geographically remotely to each of the one or more devices 1 10a-110n.

[0057] Each of the audio devices 110a-110n is a device suitable for the recording of audio such as voice recorder, computer device, or smart phone. Each of the plurality of audio devices 110a-1 10n comprises, or is connected to, a microphone, and comprises a memory for storing audio recordings. The audio devices 1 10a-110n send audio recordings to the one or more servers 130. The one or more servers 130 comprise algorithms for the processing and analysing of audio recordings to determine analysis results including uroflowmetry parameters. The one or more servers 130 may send analysis results to a corresponding one of the audio devices 1 10a-110n that sent the recording.

[0058] The one or more servers 130 comprise a storage for storing audio recordings and data derived from the audio recordings. The storage may also store training data for the subsystems.

[0059] The server 130 stores, or has access to, machine learning subsystems for processing the audio recordings. A machine learning subsystem is an subsystem, algorithm or model which utilises one or more learning techniques to make a prediction, or some other output, based on an input. Learning techniques include supervised learning techniques, where the training data is labelled, unsupervised learning techniques, where the training data is unlabelled, and semi-supervised, where small amounts of labelled training data and large amounts of unlabelled training data are used. The architecture of a machine learning subsystem may be based upon on neural networks (for example feedforward neural networks, convolutional neural networks, recurrent neural networks, encoderdecoder and transformers), support vector machines, decision tress or clustering algorithms.

[0060] Each of the audio devices 1 10a-110n and one or more servers 130 may be implemented as any suitable type of computing system suitable for communicating over network environment 100 and performing the embodiments described herein. Figure 2 illustrates

[0061] 38186463-1 an example computing system 200 comprising a processor 210 coupled to a mass storage unit 220 and accessing a working memory 230. Usual procedures for the loading of software into memory and the storage of data in the mass storage unit 220 apply. The processor 210 also accesses, via bus 240, a communications interface 250 that is configured to receive data from and output data to an external system (e.g. an external network or a user input device or output device, such as a keyboard, mouse, display screen and / or touch-interface). The communications interface 250 may be a single component or may be divided into a separate input interface and a separate output interface.

[0062] The processor is configured to implement the methodology described herein based on executable software stored within the mass storage unit 220. The software can be embedded in original equipment, or can be provided, as a whole or in part, after manufacture. For instance, the software can be introduced, as a whole, as a computer program product, which may be in the form of a download, or to be introduced via a computer program storage medium, such as an optical disk or connectable memory drive (such as a Universal Serial Bus flash drive). Alternatively, modifications to an existing controller can be made by an update, or plug-in, to provide features of the above described embodiment. The software installed on the audio devices may be a stand alone application or it may be an application that interfaces with one or more other healthcare applications through an API installed on the audio devices.

[0063] The functionality of the server 130 and audio devices 110 will now be described in further detail with reference to Figure 3, which depicts a sonouroflowmetry system comprising a server 330 connected to an audio device 310 over a network 342. It will be understood that server 300, audio device 310 and network 342 are equivalent to the previously described server 130, audio device 1 10, and network 140.

[0064] The audio device 310 is configured to generate an audio recording 331 of urination. The audio recording is a recording of the sound of urine impacting a urine collection receptacle. The urine may impact water in the urine collection receptacle and / or the surface of the urine collection receptacle. The audio device 310 is further configured to transmit the recording over the network 342 to the server 330. The server 330 is

[0065] 38186463-1 configured to store the audio recording 331 in a storage 320. The server 330 is further configured to pre-process the audio recording to obtain pre-processed audio data 334, which is also stored in storage 320. The pre-processing is performed by an echo and microphone correction module 352 and optionally aflow detection module 350. The server is further configured to process the pre-processed audio data with the uroflowmetry module 354 to predict one or more uroflowmetry parameters 336 that are associated with the recorded urination. Optionally, the audio recording is processed by a background noise correction module 356, the output of which may be used to modify the uroflowmetry parameters output by the flow parameter prediction module 354.

[0066] Optionally, the server 330 comprises a personalised urology module 358 which is configured to provide a personalised medical assessment of a patient based on their uroflowmetry parameters and personalised medical data 340. The results of this analysis, as well as the uroflowmetry parameters 336, may be transmitted back to a smart phone of a patient where it is displayed on a patient dashboard 326.

[0067] The server 330 may store training data 338 for training of the subsystems accessed by each of modules 350-358. Alternatively, the training data may be stored on a separate server. Each of the subsystems utilised by modules 350-358 may be stored in the storage of the server or they may be accessed from another server over the cloud.

[0068] Prediction of uroflowmetry parameters from audio data

[0069] With reference to Figure 4, a method to process an audio recording 331 to predict uroflowmetry parameters 336 will now be described.

[0070] At 410, the server 330 receives an audio recording 331 of urination of a patient. The audio recording was recorded by one of the audio devices 31 On and transmitted to the server 330 over the network 342.

[0071] At 420, the audio recording 331 is converted to audio data 332, which comprises an alternative representation of the audio recording. The alternative representation may be a spectrogram.

[0072] 38186463-1 At 430, the the audio data is pre-processed to obtain pre-processed audio data 334. The pre-processing is performed by the echo and microphone correction module 352.

[0073] Optionally, at 440, further pre-processing is performed by the flow detection module 350. The flow detection module 350 processes a version of the audio data, or pre-processed audio data, to determine time windows in the version of the audio data or pre-processed audio that are predicted as corresponding to urination and segments the audio data or pre-processed audio data accordingly. This step may be performed before, or after, step 430, or may be performed part way through step 430 (i.e. after one of the dereverberation or microphone is applied and before the other of dereverberation and microphone correction is applied.).

[0074] At 450, the pre-processed audio data is processed by the uroflowmetry module 352 to predict one or more uroflowmetry parameters 336. If step 440 has been performed, the uroflowmetry module 352 only processes segments of pre-processed audio data corresponding to the time windows that are predicted as corresponding to urination.

[0075] Optionally, at 460, the audio data is processed by the background noise correction module 356 to detect portions of the audio data that comprise background noise. The one or more uroflowmetry parameters 336 are updated based upon the detected background noise.

[0076] Optionally, at 470, the uroflowmetry parameters 336 are processed by the personalised urology module 358 and integrated with patient-specific data 340 to generate a personalised urinary health assessment. The uroflowmetry parameters 336 may also be assessed in combination with uroflowmetry parameters obtained based upon previous recordings to provide a longitudinal assessment of the patient’s urinary health.

[0077] Conversion of audio recording to audio data

[0078] The audio recording 331 is first converted to audio data 332, which is an alternative representation of the audio recording.

[0079] The audio recording may be in digital format such as WAV, AIFF, MP3. If the recording is made using a smartphone, the smartphone’s audio processing software may be

[0080] 38186463-1 switched on or off. The audio data may comprise a time-frequency spectrogram, constant-Q transform, wavelet transform, multi-resolution representation, or other suitable representation which captures features of the audio recording. For example, the alternative representation may be a representation which captures one or more of spectral features, zero cross rate, root mean square, and other features of the audio recording.

[0081] In some embodiments, the audio data comprises a spectrogram, which is a representation of the time-varying frequency content of the audio recording. A spectrogram comprises a time axis, a frequency axis, and intensity points which correspond to the amplitude of the signal at a particular time and frequency. The spectrogram may be a mel-spectrogram.

[0082] Pre-processing of audio data with echo and microphone correction module

[0083] The echo and microphone correction module 352 processes the audio data 332 to remove reverberation from the audio data and / or correct for distortions in the audio data due to the type of microphone used to make the recording of urination.

[0084] The echo and microphone correction module may apply only one of the dereverberation subsystem and microphone correction subsystem to the audio data to obtain pre- processed audio data, i.e. the pre-processed audio data may be a dereverberated version of the audio data or microphone corrected version of the audio data. Alternatively, both the dereverberation subsystem and microphone correction subsystem may be applied to obtain pre-processed audio data which is a dereverberated and microphone corrected version of the audio data, and they may be applied in any order. For example, the audio data may first be processed with the dereverberation subsystem to obtain a dereverberated audio data version of the audio data, and the dereverberated version of the audio data is then processed with the microphone correction subsystem to obtain pre-processed audio data. Alternatively, the audio data may first be processed with the microphone correction subsystem to obtain a microphone corrected version of the audio data and the microphone corrected version of the audio data is then processed with the dereverberation subsystem to obtain pre-processed audio data.

[0085] 38186463-1 As a further option, a flow detection subsystem may be applied prior to processing with the echo and microphone correction module to segment the audio data into segments that are predicted as corresponding to the sound of urination, in which case, the echo and microphone correction module processes respective segments of audio data. As a further alternative, the flow detection subsystem may be applied after processing with one of the dereverberation subsystem or microphone correction subsystem to obtain either segments of a dereverberated version of the audio data or segments of a microphone corrected version of the audio data. Those segments may then be processed with the other of the dereverberation subsystem or microphone correction subsystem to obtain segments of pre-processed audio data. Alternatively, the flow detection module may be applied after processing with the echo and microphone correction module.

[0086] Dereverberation subsystem

[0087] The dereverberation subsystem is configured to receive a version of the audio data (i.e. the audio data or a microphone corrected version of the audio data) as input and output the version of the audio data with reduced reverberation.

[0088] The dereverberation subsystem may be a based upon neural networks and comprise one or more of an encoder-decoder, convolutional neural network (CNN), recurrent neural network (RNN), temporal convolutional neural network (TCN), fully connected network (FCN), auto encoder, graph neural network (GNN), and transformer.

[0089] In one embodiment, the dereverberation subsystem comprises an encoder-decoder. An encoder takes an input and processes it through a series of neural network layers to compress the input into a lower-dimensional representation, or latent space representation. A decoder takes the latent space representation and processes it through a series of neural network layers to reconstruct the latent space representation. In the context of a dereverberation encoder-decoder, the output of the decoder is a dereverberated version of the audio data input to the encoder.

[0090] The dereverberation subsystem may comprise a multi-input encoder which accepts a plurality of inputs. In one embodiment, the dereverberation subsystem accepts two inputs. The first input is an audio spectrogram and the second input is based on one or

[0091] 38186463-1 more room impulse response (RIR) spectrograms, preferably 2, 3 or 4, RIR spectrograms. A RIR spectrogram is generated by recording one, or a series, of claps or other impulsive sounds in the room in which the recording of urination took place and then converting the recording to a spectrogram. For example, a RIR spectrogram may be based on a recording of 1 , 2, 3, 4 or 5 successive claps. The RIR spectrograms are created using the same parameters used to create the spectrogram for the corresponding audio spectrogram. When there is more than one RIR spectrogram, the plurality of RIR spectrograms are arranged as a stack along the channel dimension such that the second input is a multi-channel input. The temporal resolution of the stack may be reduced to 1 by applying asymmetrical pooling operations along the time-axis of the stack.

[0092] In some embodiments, the dereverberation subsystem comprises a U-net, which is described in Ronneberger, Olaf, Philipp Fischer, and Thomas Brox. "U-net: Convolutional networks for biomedical image segmentation." Medical Image Computing and Computer-Assisted Intervention-MICCAI 2015: 18th International Conference, Munich, Germany, October 5-9, 2015, Proceedings, Part III 18. Springer International Publishing, 2015. A U-net architecture comprises a contracting path comprising encoder convolutional layers and an expansive path comprising decoder convolutional layers. The output from respective convolutional layers is termed a feature map. The U-net architecture further comprises skip connections which concatenate feature maps output from convolutional layers in the contracting path to corresponding convolutional layers in the expansive path. The U-net may be a multi-input U-net which accepts a first input of an an audio spectrogram and a second spectrogram based on one or more room impulse responses (RIR).

[0093] In one embodiment, the U-net comprises a contracting path with four convolutional layers, each with respectively increasing filter sizes. They may be 4, 5, or more convolutional layers. The convolutional layers scan across an input with a stride > 1 in order to downsample the input. The expansive path is symmetric to the contracting path. Channel-wise attention mechanisms may be introduced to the skip connections to adaptively weigh importance from the feature maps from the contracting path. The RIR spectrogram, or the stack of RIR spectrograms are concatenated to the audio spectrogram, or the feature maps, at multiple scales. The stack of RIR spectrograms are concatenated by first resizing the stack to match the audio spectrogram or feature map

[0094] 38186463-1 and then concatenating the stack to the audio spectrogram or feature map along the channel dimension.

[0095] The microphone correction subsystem corrects for distortion in the audio data which arises from the type of microphone used for the recording. The microphone correction subsystem is configured to accept a version of the audio data (i.e the audio data or a dereverberated version of the audio data) as input and outputs the version of the audio data, with variances in characteristics of the version of the audio data due to the type of microphone used removed or minimised.

[0096] The microphone correction subsystem may be a based upon neural networks and comprise one or more of an encoder-decoder, convolutional neural network (CNN), recurrent neural network (RNN), temporal convolutional neural network (TCN), fully connected network (FCN), auto encoder, graph neural network (GNN), and transformer.

[0097] In one embodiment, the microphone correction subsystem comprises an encoderdecoder. The microphone correction subsystem comprises a U-net. In one embodiment, the U-net comprises a contracting path with four convolutional layers, each with respectively increasing filter sizes. They may be 4, 5, or more convolutional layers. The convolutional layers scan across an input with a stride > 1. The expansive path is symmetric to the contracting path. Channel-wise attention mechanisms may be introduced to the skip connections to adaptively weigh importance from the feature maps from the contracting path.

[0098] Processino with flow detection module

[0099] The audio recording 331 and audio data derived from the recording may not comprise a continuous signal of urination from start to finish of the recording. For instance, there may be delay in the sound recording before a signal corresponding to urination is present, and a signal corresponding to urination may end before the recording finishes. In addition, the signal may be intermittent due to pauses in urination or due urine hitting the bowl rather than the water. Pauses in the urination recording can lead to inaccuracies in the prediction of uroflowmetry parameters. The flow detection module 350 identifies

[0100] 38186463-1 time windows in a version of the audio data, or pre-processed audio data, that are predicted as corresponding to urination, or voiding events and uses these time windows to segment the version of the audio data or pre-processed audio data.

[0101] With reference to Figure 5, a method 500 comprising the pre-processing of a version of the audio data (i.e. the audio data, dereverberated version of the audio data, or microphone corrected version of the audio data) or pre-processed audio data by the flow detection module 350 will now be described.

[0102] At 510, the flow detection module 350 accesses a flow detection subsystem. The flow detection subsystem receives the version of the audio data or pre-processed audio data as input and outputs a plurality of probabilities each indicating the probability that portions of the version of the audio data or pre-processed audio data at respective time chunks comprises the sound of urination. The time chunks may be between 1 to 50 ms, preferably between 5 to 20ms, for example, 5 or 10 ms.

[0103] The flow detection subsystem may comprise one or more of a convolutional neural network (CNN), recurrent neural network (RNN), temporal convolutional neural network (TCN), fully connected network (FCN), auto encoder, graph neural network (GNN), and transformer.

[0104] In some embodiments, the flow detection subsystem comprises a CNN. The CNN architecture may comprise an input layer, a plurality of convolutional layers, a plurality of max pooling layers, a global average pooling layer, and an output layer. The convolutional layers may have respective increasing filter sizes. Each of the convolutional layers may be succeeded by a max pooling layer to reduce dimensionality. A batch normalization followed by a ReLU activation function may be applied between each of the convolutional layers and max pooling layers. The global average pooling layer produces a fixed size vector. The output layer is a dense layer comprising a function, such as a sigmoid function, which outputs for each time step a probability that the audio recording 331 at that the timestep comprises the sound of urination.

[0105] In one embodiment, the input layer accepts a spectrogram, such as a mel-spectrogram representation of the audio recording. There are four convolutional layers having respective filter sizes of 32, 64, 128, 256. Each of the convolution layers is followed by

[0106] 38186463-1 batch normalization, a ReLU activation, and a max pooling layer. The final layers are a global average pooling layer followed by an output layer comprising a sigmoid function.

[0107] At 520, the flow detection subsystem determines time windows of the version of the audio data or pre-processed audio data that are predicted as corresponding to the sound of urination based on the probabilities. The flow detection subsystem may first convert each of the probabilities output by the flow prediction subsystem to a binary value, to represent the presence or absence of at the corresponding time chunk. The conversion may be performed based on a threshold. For example, probabilities less than a threshold value are set to 0 and probabilities equal to or greater than the threshold value are set to 1 .

[0108] In further embodiments, additional rules may be implemented to determine whether a probability should be set to 0 or 1 . For example, a sequence of immediately successive time chunks that are each predicted as being associated with urination will only be set to correspond to urination if the total time duration of the sequence of time chunks is greater than a minimum time duration. The minimum time duration may have a value between 50 and 150ms, preferably 100ms. This acts to filter out brief noises. Furthermore, hysteresis behaviour may be implemented to prevent rapid on / off switching for probabilities that are close to the threshold. For example, time chunks with probabilities below the threshold, which would otherwise be indicated as not corresponding to urination, may be labelled as corresponding to urination if one or more immediately preceding and / or succeeding time chunks are labelled as corresponding to urination. Probabilities above the threshold, which would otherwise be indicated as corresponding to urination, may be labelled as not corresponding to urination if one or more immediately preceding and / or succeeding time chunks are not labelled as corresponding to urination

[0109] The binary output may be used as a mask or guide comprising time windows for the segmentation of the version of the audio data or the pre-processed audio data.

[0110] At 530, the flow detection subsystem segments the version of the audio data or the pre- processed audio data based on the time windows. A spectrogram of the version of the audio data or the pre-processed audio data may be segmented.

[0111] At 540, the segmented pre-proceed audio data is output for processing with the uroflowmetry module.

[0112] 38186463-1 Only the segments that are predicted as corresponding to urination are used for downstream processing. As a result, only the relevant segments derived are processed by the machine learning subsystem. This ensures that uroflowmetry parameters are predicted based on the relevant parts of the pre-processed data. It has been found by the inventors that predicting the flow rate parameters based upon the relevant portions results in an improvement in the accuracy and reliability of the analysis.

[0113] Parameter prediction with the uroflowmetry module

[0114] The uroflowmetry module 352 receives the pre-processed audio data 334 and processes the pre-processed audio data 334, or respective segments of the pre-processed audio data 334, with a machine learning subsystem to predict one or more uroflowmetry parameters. The one or more uroflowmetry parameters may comprise one or more flow rates (ml / sec), each flow rate corresponding to a respective time step of the pre- processed audio data.

[0115] Machine learning subsystem

[0116] The machine learning subsystem may be based on neural networks and comprises one or more of a CNN, RNN, a temporal convolutional neural network or transformers. The input layer of the machine learning subsystem receives the pre-processed audio data 334, or respective segments of the pre-processed audio data, and the output later outputs one or more uroflowmetry parameters. In one embodiment, the output of the machine learning subsystem comprises a plurality of flow rates.

[0117] In some embodiments, the machine learning subsystem is a CNN comprising an input layer, a plurality of convolutional layers, and an output layer. The plurality of convolutional layers may be stacked, i.e. they are placed one after the other in the neural network. The plurality of convolution layers comprise convolutional layers which are causal and / or dilated. A convolutional layer is causal if the kernel is applied to current and past time steps. A convolutional layer is dilated if the kernel skips input values based on a dilation factor, which effectively expands the receptive field of the network. Exponentially increasing dilation rates (e.g., 1 , 2, 4, 8, 16) may be used for respective convolutional layers, which expands the receptive field of the network exponentially. By combining

[0118] 38186463-1 dilation with causality, long-term dependencies in the input data may be captured whilst preserving temporal order.

[0119] Padding may be applied to the inputs of the convolutional layers to ensure that the length of the sequence output by a convolutional layer matches the length of the input sequence. Batch normalization may be applied between convolutional layers. Asymmetrical pooling operations, in which the pooling window has a differing width and height, may be applied between layers to compress the frequency dimension of the input data to a value of 1 . The asymmetrical pooling operations may be applied along the frequency axis only such that the temporal resolution of the input is preserved. Batch normalization may be applied between layers.

[0120] In other embodiments, the machine learning subsystem comprises a TCN and accepts an input comprising time series data, which may be a 1 D sequence of values over time. The time series may be obtained by converting the spectrogram of the pre-processed audio data to a time series format. The TCN comprises a plurality of convolutional layers, some of which may be causal and / or dilated. The one or more uroflowmetry parameters output of the machine learning subsystem may be displayed on a patient dashboard 326 of the audio device 310 which sent the recording. In addition, output may be sent to a computer device of a health provider or clinician.

[0121] Background noise subsystem

[0122] To ensure accurate analysis of the recording of urination, it is helpful to identify and correct for background noises that occur during the flow recording. The background noise correction module 356 is configured to process the audio recording 331 to identify non-flow sounds during urination, flag recordings with poor audio quality, and update the uroflowmetry parameters 336 output by the machine learning subsystem that are identified as comprising background noise.

[0123] T urning to Figure 6, a block diagram 600 illustrates schematically the interaction between the flow detection module 350, the echo and microphone correction modules 352, the uroflowmetry module 354 and the background noise correction module 356.

[0124] Audio recording 632 corresponds to audio recording 331 . Starting from the left side of the block diagram, pre-processing operation 640 comprises the conversion of the audio

[0125] 38186463-1 recording to audio data, the pre-processing of the audio data with the echo and microphone correction module 354 and optionally the flow detection module 350 to result in pre-processed audio data 642, which corresponds to pre-processed audio data 334. At operation 644, the pre-processed audio data is processed by the uroflowmetry module 354 to predict one or more uroflowmetry parameters 646, which correspond to uroflowmetry parameters 336.

[0126] Starting from the right side of the block diagram, operation 650 comprises processing of the audio recording by the background noise correction module 356 to segment the audio recording 632 into short, overlapping frames. In one example, respective frames may have a 20ms duration and overlap each other by 10ms. Each of the frames are then converted to an audio spectrogram representation, such as a mel-spectrogram. Each of the spectrograms are normalised to have values in the same range, for example between 0 and 1 . The audio spectrogram frames are termed segmented frames 652.

[0127] At operation 654, the background noise correction module 356 processes the segmented frames 652 with a background noise detection subsystem.

[0128] The background noise detection subsystem comprises a neural network based algorithm configured to predict if an input frame comprises background noise. In one embodiment, the background noise detection subsystem comprises a CNN and comprises an input later, a plurality of convolutional layers, a plurality of pooling layers, a dense layer, and an output layer. The input layer accepts the one or more frames 652. There may be 3, 4, 5 or more convolutional layers. Each of the convolutional layers may have increasing respective filter sizes (e.g. 32, 64, 128...) and may be followed by a batch normalization and ReLU activation. Each of the convolutional layers may be followed by a max pooling layer. A global average pooling layer may be provided after the convolutional and max pooling layers. The final layers are the dense layer and an output layer. The output layer may be a dense layer with a sigmoid function which outputs probabilities that respective frames 652 comprise background noise.

[0129] The probabilities may be converted to a binary classification indicating whether a frame is predicted to contain background noise or not based on a threshold. For example, probabilities less than a threshold may be labelled as “0” may indicate a clean urine flow sound and probabilities greater than or equal to a threshold may be labelled as “1 ” to indicate that non-flow noise is present.

[0130] 38186463-1 A sliding window, i.e. a moving average, may be applied to the sequence of binary classifications to smooth predictions over the frames.

[0131] At operation 660, the background noise correction module 356 evaluates the sequence of binary classifications to: i) determine the quality of the audio recording 632 and flag poor quality recordings, and ii) update uroflowmetry parameters 646.

[0132] The quality of the audio recording 632 may be determined based upon the percentage of frames 652 that are determined as comprising non-flow noise. If the percentage of frames is greater than a pre-determined threshold, the audio recording 632 may be flagged as poor quality. Flagged recordings may be excluded from downstream analysis. If a recording is flagged, an alert may be sent to the audio device 310 which sent the original recording inviting the patient to make another recording.

[0133] For recordings that are not flagged as poor quality, a quality score may be evaluated based upon the percentage of frames 652 determined not to comprise non-flow noise.

[0134] The quality score may be passed to the personalised medicine module 358 so that it can weight any assessments based upon the uroflowmetry parameters obtained from a respective recording based upon the associated quality score.

[0135] A further quality control for a recording may be performed based upon the quality score and an assessment of the uroflowmetry parameters calculated based upon that recording. If the uroflowmetry parameters calculated based on a given recording are not congruent with uroflowmetry parameters calculated based upon previous recording (i.e. the uroflowmetry parameters are outliers), and the quality score for the recording is relatively low, the recording may be flagged as poor quality.

[0136] The uroflowmetry parameters 646 are updated by identifying frames that are classified as comprising non-flow noise and updating the corresponding uroflowmetry parameters by interpolating the uroflowmetry parameters at surrounding timesteps that are determined as not comprising non-flow noise. In one embodiment, the uroflowmetry parameters comprise flow rates. The background noise correction module 356 identifies contiguous sequences of frames that are predicted as comprising non-flow to be

[0137] 38186463-1 updated. The corresponding flow rates are updated based upon the flow rates at one or more timesteps immediately preceding and succeeding the timesteps corresponding to the contiguous sequence of frames. For contiguous frames corresponding to short gaps, such as less than 0.5 seconds, linear interpolation may be used. For contiguous frames corresponding to larger gaps, cubic spline interpolation may be used to create a smooth transition.

[0138] The updated uroflowmetry parameters 670 may be supplied back to the to the machine learning subsystem. Metadata may be added to the updated uroflowmetry parameters 670 which indicates the start and end timepoints of the interpolated sections and the type of interpolation method used, which adds transparency about how the uroflowmetry parameters 670 are determined.

[0139] This specialised background noise detection and removal subsystem enhances the reliability of the overall system by ensuring that only high-quality, clean urine flow data is used for accurate flow rate prediction. It helps filter out and compensate for sections contaminated by coughs, speech, or other non-flow sounds that could interfere with accurate analysis, thereby improving the overall accuracy and trustworthiness of the urinary flow assessment.

[0140] Training

[0141] Training of the subsystems utilised by modules 350 to 356 is based on curated datasets comprising audio recordings that are used to teach the subsystem accessed by the respect module to achieve the relevant objective for that model. The audio recordings are first converted to alternative representations, such as a spectrogram representations before they are used for training. Each of the spectrograms may be normalised to a common scale, e.g. 0 to 1 to facilitate training.

[0142] Training of the subsystems is achieved by processing the training data for a respective subsystem (the forward pass), calculating a loss function, which is calculated based on a difference between the predictions of the subsystem and a ground truth, and then updating the parameters of the subsystem based upon the loss function ( backpropagation). For subsystems based upon neural networks, the weights of the neural network layers are updated during back propagation. This is repeated for many iterations and epochs until the parameters of the model converge.

[0143] 38186463-1 Dereverberation

[0144] The dereverberation subsystem is trained based upon dataset comprising the recordings of a plurality of sounds which are respectively recorded in a low reverberation setting and a moderate and / or high reverberation setting. The recordings in the low reverberation setting is used as the ground truth. The recording in settings with moderate and / or high reverberation simulates different acoustic environments. Each of the respective sounds may be one of a plurality of preset audio files comprising a wide variety of clips such as speech, music and environmental sounds.

[0145] In embodiments where the dereverberation model is a multi-input model, a series of room impulse responses (RIRs) are recorded in each of the settings in which the sound recordings are made. The RIRs are hand claps or other impulsive sounds. For each training iteration, a spectrogram of a sound recording from a respective setting and a stack of spectrograms each corresponding to a plurality of RIRs for that setting are used as inputs to the dereverberation subsystem. The stack of spectrograms of RIRs for a given setting may be a subset from a larger pool of RIR spectrograms for a setting. For example, in one training iteration, a spectrogram of recording of an audio file in a low reverberation setting is the first input to the dereverberation subsystem and a stack of spectrograms corresponding to the recording of a plurality of RIRs in the low reverberation second is the second input. The inclusion of RIRs to the subsystem helps the subsystem to learn the mapping between high and low reverberation audio.

[0146] The microphone correction subsystem is trained based upon a dataset comprising the recordings of a plurality of respective sounds which are recorded using multiple smartphones and / or microphones with varying microphone qualities and specifications. Each of the respective sounds may be one of a plurality of preset audio files, the preset audio files comprising a wide variety of clips such as speech, music and environmental sounds. The recordings made using one of the smartphones or microphones, which has a high quality, are designated as the ground truth recordings. A range of microphone specifications are used which correspond to different price points to represent real-world variations in audio quality.

[0147] 38186463-1 Flow detection subsystem

[0148] The flow detection subsystem is trained based upon a dataset comprising audio recordings and ground truth labels indicating the start and end times of urine flow time in each of the audio recordings. The ground truth annotations may be performed by humans. In addition, or alternatively, ground truth annotations may be obtained by applying audio segmentation techniques to the audio recording to identify the start and end points of each voiding event in the recording.

[0149] The audio recordings may be modified using data augmentation techniques such as time stretching, pitch shifting, and by adding background noise. The augmentation is performed in order to improve the robustness of the subsystem so that it can make accurate predictions based upon distorted and / or noisy recordings.

[0150] The loss function may be a binary cross-entropy loss function. An Adam optimizer may be used during back propagation.

[0151] Machine learning subsystem

[0152] The machine learning subsystem is trained based upon a dataset comprising a plurality of audio recordings of urination, and / or simulated urination, and corresponding ground truth data for each of the respective audio recordings obtained using a uroflowmeter device to measure uroflowmetry parameters such as flow rates for the urination and / or simulated urination which is being recorded. The urination events which are recorded are configured to represent various types of voiding, and thus the training data covers a wide range of uroflowmetry parameters. The recordings may be made using respective smartphones with different microphones to account for device variability.

[0153] During training, a mean squared error loss function may be used to measure the difference between the predicted and ground truth uroflowmetry parameters. Backpropagation may be performed using an Adam optimizer.

[0154] 38186463-1 Background noise detection subsystem

[0155] The background noise detection subsystem is trained based upon a dataset of audio recordings and corresponding sequences of classifications for timeframes of the audio recordings corresponding to background noise or no background noise. The classifications may be obtained by human annotation of the recordings. Some recordings contain clean urine flow sounds only, in which case the corresponding sequence of classifications will indicate no background noise. Other recordings contain urine flow sounds with various non-flow noises added, such as coughing, talking, and object dropping, in which case the corresponding sequence of classifications indicate background noise at the appropriate time frames. Non-flow noises may be added at varying intensities to respective recordings using data augmentation techniques.

[0156] A binary cross-entropy loss function may be used. Backpropagation may be performed using an Adam optimizer.

[0157] Personalised flow analysis

[0158] In further embodiments, the personalised medicine module 358 analyses the uroflowmetry parameters 336 which are output by the machine learning subsystem and optionally updated by the background noise correction module 356, to provide a comprehensive urinary health assessment for the patient. The assessment is designed to assist the responsible healthcare professional in the diagnosis and management of their patient. Further, by providing a comprehensive view of the individual's urinary health trends and patterns, a patient and clinician may have valuable insights into the patient's condition, treatment efficacy, and overall urological health trajectory. This information will help both the patient and clinician make informed treatment decisions.

[0159] In one embodiment, the uroflowmetry parameters comprise a plurality of flow rates. The flow rates are analysed by the personalised medicine module 358 to predict further uroflowmetry parameters 336 such as:

[0160] Maximum flow rate (Qmax): Highest flow rate achieved during voiding

[0161] - Average flow rate (Qave): Mean flow rate over the entire void

[0162] Time to maximum flow (TQmax): Time from flow start to reaching Qmax

[0163] Voided volume: Total volume of urine voided

[0164] 38186463-1 - Void time: Total duration of the void

[0165] Flow time: Duration of actual urine flow (excluding interruptions)

[0166] - Time to start: Delay between attempt to void and actual flow start

[0167] - Acceleration: Rate of increase in flow rate at the start of voiding Deceleration: Rate of decrease in flow rate at the end of voiding

[0168] - A flow curve (flow rate against time)

[0169] Flow curve shape: Classification of the overall flow pattern (e.g., bell-shaped, plateau, intermittent).

[0170] Integration of uroflowmetry measures with patient specific data

[0171] The personalised medicine module 358 may receive personalised patient data 340, which can be used to adjust the uroflowmetry parameters 336 and make further assessments. These personalised patient data 340 may include:

[0172] Demographic data: Age, sex, height, weight, BMI

[0173] - Medical history: Presence of lower urinary tract symptoms (LUTS), previous urological procedures, medications

[0174] - Validated Questionnaire Scores eg. International Prostate Symptom Score, International Consultation on Incontinence Questionnaire: Male Lower Urinary Tract Symptoms, International Consultation on Incontinence Questionnaire: Female Lower Urinary Tract Symptoms

[0175] Physiological data: Blood pressure, heart rate, prostate size (if available) Lifestyle factors: Fluid intake, caffeine consumption, physical activity level.

[0176] The uroflowmetry parameters 336 may be adjusted based upon the age of the patient. For example, specific adjustments may be required for paediatric populations and geriatric populations.

[0177] The personalised medicine module 358 may correlate the uroflowmetry parameters with patient-reported quality of life scores from the patient specific data 340. The correlation may be used to track improvement or deterioration of urinary symptoms over time

[0178] Statistical analysis may be performed to compare the uroflowmetry parameters of the patient against population norms. A percentile ranking for key metrics, such as the Qmax

[0179] 38186463-1 percentile for age group, may be calculated. A trend analysis may be performed based upon uroflowmetry parameters calculated for recordings taken at different time points.

[0180] The uroflowmetry parameters and patient data 340 may also be used to predict probabilities that the patient suffers from one or more urological diseases. This may be achieved using a machine learning model which is configured to receive uroflowmetry parameters relating to a single time point or time series, and the patient data 340, and output probability scores for various urological conditions.

[0181] A risk score for respective urological issues may be calculated for the patient. This allows for patients to be categorized into low, medium, and high-risk groups for various conditions, which can aid the management of patients.

[0182] The personalised medicine module 358 may also provide predictive analytics. The personalised medicine module 358 may monitor the progression of uroflowmetry parameter over multiple time points, as well as patient specific data 340, and estimate a progression of disease and / or a likelihood that the patient may require surgical intervention.

[0183] Patient monitoring may be provided which is specific to the age of the patient. For instance, urinary development patterns may be tracked in paediatric patients, and a risk of urinary retention or incontinence may be assessed in elderly patients. Patient specific data 340 such as fraility index and comorbidities may be also be considered for elderly patients.

[0184] The personalised medicine module 358 may integrate with clinical decision support systems and provide treatment suggestions based upon the uroflowmetry parameters and patient specific data. Recommendations for diagnostic tests or referrals may be provided. Personalised treatment plans may be suggested.

[0185] Results of the above described analyses may be summarised in a report to be sent to a health care provider or clinician, including key metrics and their interpretations. A visual representation of the urine flow for one or more respective recordings may be presented as a graph. The report may suggest potential areas of concerns or suggest areas of further investigation.

[0186] 38186463-1 The personalised medicine module 358 may perform a population health analysis by aggregating uroflowmetry parameters and patient specific data from multiple patients to identify trends in urological health. Trends may be determined across respective demographics. This can support epidemiological studies and public health initiatives. The uroflowmetry parameters and patient specific data may first be anonymized prior to this analysis.

[0187] This comprehensive flow analysis provides a holistic view of a patient's urinary health, integrating various data points to deliver personalised, actionable insights. By combining traditional uroflowmetry parameters with advanced analytics and patient-specific data, it offers a powerful tool for urological assessment and management in both clinical and research settings.

[0188] Aggregation of flow parameters with flow parameters from previous recordings

[0189] The uroflowmetry parameters 336 determined from a single recording may be compared against the uroflowmetry parameters 336 determined from previous recordings for the same patient. The changes in flow patterns over time may be analysed. Abnormal uroflowmetry parameters from any of the recordings for a patient may be detected based on predefined thresholds and machine learning subsystems.

[0190] The personalised medicine module 358 may compile all flow recordings from a patient, along with timestamps for the recording and associated meta data. Data formats and units may be standardised across different recording sessions. Quality checks may be implemented to identify and handle outliers or potentially erroneous recordings. Flow parameters associated with the current and previous recordings may compiled and a time series of key flow parameters (e.g., Qmax, voided volume, flow time) generated. Plots of the time series may be generated. Moving averages may be calculated from the time series data to smooth out short-term fluctuations and highlight longer-term trends. Any periodic patterns or cycles in a patient’s urinary function may be identified.

[0191] The personalised medicine module 358 may perform statistical analysis by calculating summary statistics for various uroflowmetry measures across all recordings (e.g. mean, median, standard deviation, range). A trend analysis may be performed to detect significant improvements or deteriorations in urinary function. Change point detection

[0192] 38186463-1 may be performed on the time series data to identify when any significant shifts in urinary patterns occurred.

[0193] When recordings are generated on a day-to-day, or almost day-to-day basis, a variability assessment may be performed to analyse the day-to-day variability in flow metrics. Coefficients of variation may be calculated for one or more uroflowmetry parameters to quantify consistency in urinary function. Time series uroflowmetry parameters may be correlated with contextual factors, such as (e.g., time of day, fluid intake, medication timing) to identify potential triggers or factors influencing urinary function. The personalised medicine module 358 may also implement pattern recognition techniques to identify distinct types of voiding events for the patient. Clustering algorithms may be used to detect any recurring abnormal flow patterns. Unusual voiding events that deviate significantly from the patient's typical patterns may be detected. Any potential issues or acute changes in condition may be flagged to a clinician.

[0194] The personalised medicine module 358 may evaluate the response of a patient to treatment. The personalised medicine module 358 may receive information on medications or that a patient is taking or other medical interventions. A comparison of uroflowmetry parameters before and after the initiation of a treatment or intervention may be performed. A magnitude and consistency of treatment effects over time may be assessed. The personalised medicine module 358 may also analyse relationships between flow metrics and patient-reported symptoms over time. Changes in quality of life measures reported by the patient may be correlated in relation to urinary function. Any changes in uroflowmetry metrics subsequent to the intervention may be tracked and evaluated to see if uroflowmetry parameters return to normal levels. This allows for a quantitative assessment of treatment efficacy.

[0195] The personalised medicine module 358 may utilise a model to predict the trajectory of the patient's urinary health based on time series uroflowmetry parameters. The likelihood of symptom progression or improvement based on observed trends may be estimated.

[0196] The personalised medicine module 358 may examine the relationship between voiding volume and flow rate by analysing how the patient's flow rates change with different voided volumes This enables any consistent patterns or anomalies in this relationship to be detected.

[0197] 38186463-1 The personalised medicine module 358 may optimize a treatment plan based upon the time series data. Effective interventions may be identified based upon patient's unique response patterns. The personalised medicine module 358 may, based on the timestamps associated with the audio recordings, examine how a patient's flow metrics vary throughout the day. Optimal times for medication administration or fluid intake management may be identified based on this analysis.

[0198] The personalised medicine module 358 may track the frequency of audio recordings in order to determine the adherence of the patient to recommended voiding schedules. Behavioural interventions may be suggested if adherence is not as recommended. The compliance of the patient may be assessed in combination with urinary health outcomes.

[0199] The personalised medicine module 358 may provide warnings to a clinician based upon the detection of deviations from established baseline patterns for the patient. The deviations may be detected based upon personalised thresholds for the patient which are calculated based upon uroflowmetry parameters that are representative of a baseline for the patient.

[0200] The results of the analysis may be presented as an interactive dashboard 326 which shows patient's urinary health trends over time to be presented to the patient and clinician. The dashboard may provide visual comparisons of flow curves from different time periods.

[0201] This comprehensive aggregate flow analysis system for individual patients provides a detailed, longitudinal view of urinary health. By analysing multiple flow recordings over time, it offers personalised insights into treatment efficacy, disease progression, and overall urological well-being. This approach enables more informed clinical decisionmaking, personalised treatment plans, and improved patient engagement in managing their urinary health.

[0202] Implementations of the subject matter and the operations described in this specification can be realized in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Implementations of the subject matter described in this specification can be realized using one or more computer

[0203] 38186463-1 programs, i.e., one or more modules of computer program instructions, encoded on computer storage medium for execution by, or to control the operation of, data processing apparatus. Alternatively or in addition, the program instructions can be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. A computer storage medium can be, or be included in, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, while a computer storage medium is not a propagated signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium can also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

[0204] While certain arrangements have been described, the arrangements have been presented by way of example only, and are not intended to limit the scope of protection. The inventive concepts described herein may be implemented in a variety of other forms. In addition, various omissions, substitutions and changes to the specific implementations described herein may be made without departing from the scope of protection defined in the following claims.

[0205] Each of the one or more servers 130 host cloud services including applications and / or databases that can be accessed by the one or more clients 1 10a-110n. Cloud services may be deployed privately, publicly, or a combination of the two (hybrid). Software and database services may be distributed as a Software as a Service (SaaS) model.

[0206] References

[0207] Garraway WM, Collins GN, Lee RJ. High prevalence of benign prostatic hypertrophy in the community. Lancet. 1991 Aug 24;338(8765):469-71 .

[0208] Awedew AF, Han H, Abbasi B, Abbasi-Kangevari M, Ahmed MB, Almidani O, et al. The global, regional, and national burden of benign prostatic hyperplasia in 204 countries and

[0209] 38186463-1 territories from 2000 to 2019: a systematic analysis for the Global Burden of Disease Study 2019. The Lancet Healthy Longevity. 2022 Nov 1 ;3(11 ):e754-76.

[0210] Krhut J, Gartner M, Sykora R, Hurtlk P, Burda M, Lunacek L, et al. Comparison between uroflowmetry and sonouroflowmetry in recording of urinary flow in healthy men. Int J Urol. 2015 Aug;22(8):761-5.

[0211] Franco JVA, Jung JH, Imamura M, Borofsky M, Omar Ml, Escobar Liquitay CM, et al. Minimally invasive treatments for benign prostatic hyperplasia: a Cochrane network meta-analysis. BJU Int. 2022 Aug; 130(2): 142-56.

[0212] El Helou E, Naba J, Youssef K, Mjaess G, Sleilaty G, Helou S. Mobile sonouroflowmetry using voiding sound and volume. Sci Rep. 2021 May 27;11 (1 ):11250.

[0213] Jin J, Chung Y, Kim W, Heo Y, Jeon J, Hoh J, et al. Classification of bladder emptying patterns by Istm neural network trained using acoustic signatures. Sensors. 2021 Jan;21 (16):5328.

[0214] Lee DG, Gerber J, Bhatia V, Janzen N, Austin PF, Koh CJ, et al. A Prospective Comparative Study of Mobile Acoustic Uroflowmetry and Conventional Uroflowmetry. Int Neurourol J. 2021 Dec;25(4):355-63.

[0215] Lee HJ, Aslim EJ, Balamurali BT, Ng LYS, Kuo TLC, Lin CMY, et al. Development and Validation of a Deep Learning System for Sound-based Prediction of Urinary Flow. European Urology Focus. 2023 Jan 1 ;9(1 ):209— 15.

[0216] 38186463-1

Claims

CLAIMS:

1. A computer-implemented method for analysing audio data of urination, the method comprising: receiving audio data of urination; pre-processing a version of the audio data with a dereverberation subsystem and / or a microphone correction subsystem to obtain pre-processed audio data; and processing the pre-processed audio data with a machine learning subsystem to predict one or more uroflowmetry parameters.

2. The method according to claim 1 , wherein the pre-processing requires preprocessing the version of the audio data with the dereverberation subsystem, and wherein pre-processing the version of the audio data with the dereverberation subsystem comprises: processing the version of the audio data using the dereverberation subsystem to remove reverberation from the version of the audio data.

3. The method according to any preceding claim, wherein the dereverberation subsystem comprises a U-net and wherein pre-processing the version of the audio data with the dereverberation subsystem comprises: processing a representation of the version of the audio data as a spectrogram using the U-net to obtain the pre-processed audio data for processing with the machine learning subsystem, wherein the pre-processed audio data comprises a spectrogram.

4. The method according to claim 3, further comprising: receiving second audio data, wherein the second audio data comprises a spectrogram based upon one or more recordings of impulsive sounds, and wherein processing the representation of the version of the audio data as the spectrogram using the U-net comprises processing a combination of the spectrogram and the second audio data represented as a second spectrogram using the U-net to generate the pre-processed audio data, wherein the pre-processed audio data comprises a spectrogram.38186463-15. The method according to any preceding claim, wherein the pre-processing requires pre-processing with the microphone correction subsystem, and wherein preprocessing with the microphone correction subsystem comprises: processing the version of the audio data using the microphone correction subsystem to correct the version of the audio data for distortions in the version of the audio data due to the microphone used to capture the audio data.

6. The method according to claim 5, wherein processing the version of the audio data with the microphone correction subsystem does not require the type of microphone or device to be known, and compensates for variations between the different types of microphone.

7. The method according to any preceding claim, wherein the microphone correction subsystem comprises a second U-net, and wherein pre-processing the version of the audio data with the microphone correction subsystem comprises: pre-processing a representation of the version of the audio data as a spectrogram using the second U-net to generate pre-processed audio data for processing with the machine learning subsystem, wherein the pre-processed audio data comprises a spectrogram.

8. The method according to any preceding claim, wherein obtaining the pre- processed audio data comprises either: i) processing the audio data using the dereverberation subsystem to remove reverberation from the audio data to generate a dereverberated version of the audio data, and then processing the dereverberated version of the audio data using the microphone correction subsystem to correct the dereverberated version of the audio data for the microphone used to capture the audio data to obtain the pre-processed audio data for processing with the machine learning subsystem; or ii) processing the audio data using the microphone correction subsystem to correct the audio data for the microphone used to capture the audio data to generate a corrected version of the audio data, and then processing the corrected version of the audio data using the dereverberation subsystem to remove reverberation from the audio data to obtain the pre-processed audio data for processing with the machine learning subsystem.38186463-19. The method according to any preceding claim, the method further comprising: receiving an audio recording of urination; converting the audio recording to audio data, wherein the audio data comprises a spectrogram representation of the audio recording.

10. The method according to any preceding claim, the method further comprising: processing the version of audio data or the pre-processed audio data with a flow detection subsystem to identify time windows in the version of the audio data or the pre- processed audio data that are predicted as corresponding to urination; and wherein processing the pre-processed audio data with a machine learning subsystem comprises: processing segments of the pre-processed audio data predicted as corresponding to urination with the machine learning subsystem to predict one or more uroflowmetry parameters.1 1. The method according to claim 10, wherein the flow detection subsystem comprises a second convolutional neural network, wherein processing the version of the audio data or the pre-processed audio data with the flow detection subsystem comprises: processing the version of the audio data or the pre-processed audio data with the second convolutional neural network to generate a sequence of probabilities, each of the probabilities indicating if the audio data at respective time chunks corresponds to the sound of urination, and determining the time windows based upon the time chunks.

12. The method according to claim 10 or 11 , wherein the time windows that are identified as corresponding to urination are selected such that they have time duration above a predetermined threshold.

13. The method according to any preceding claim, further comprising: detecting the presence of background noise in data associated with the audio data at one or more timesteps; updating the corresponding uroflowmetry parameters for the detected one or more timesteps.38186463-114. The method according to claim 13, wherein updating the uroflowmetry parameters at the detected one or more timesteps comprises: interpolating from uroflowmetry parameters at timesteps in which the corresponding audio data are not detected as comprising background noise.

15. The method according to claim 13 or 14, wherein the presence of background noise is detected using a third convolutional neural network, and wherein detecting the presence of background noise in the audio data comprises: processing the data associated with the audio data with the third convolutional neural network to output a probability that the data associated with the audio data at respective timesteps comprises background noise.

16. The method according to any preceding claim, further comprising: analysing the one or more uroflowmetry parameters with patient specific data to provide a urological assessment.

17. The method according to any preceding claim, wherein the audio data corresponds to a recording made at one time point for a patient, the method further comprising: comparing the one or more uroflowmetry parameters with one or more other uroflowmetery parameters obtained for the patient for one or more previous recordings to provide a longitudinal patient assessment.

18. A system comprising: at least one processor; and a non-transitory computer readable medium comprising instructions that, when executed by the at least one processor, cause the system to perform the method of any one of claims 1 to 17.

19. A non-transitory computer-readable medium storing instructions that, when executed by at least one processor, cause a computing device to perform the method of any one of claims 1 to 17.38186463-1

Images