Infrastructural Aspects of Software Component top
Each component will be the basis upon which other components can be built. This circulative data flow in the architecture diagram will eventually contribute to the development of other components synergistically. In other words, when considering the final overall goal of this software project as facilitating the data flow according to the software architecture, one part of the development will benefit the other part of the research.
The hemodynamic workbench software will be implemented to provide the following infrastructural functionalities: (1) To receive signals from the hemodynamic instrument; (2) To extract necessary information by wavelet analyses; (3) To understand the data according to the hemodynamic model and simulation; (4) To provide medical statistics; (5) To perform an action by reinforcement of the learning process.
(1) Device Interface top
Device driver interface component will enable the software to access raw data directly from a device. Biomedical companies seem to welcome the idea of enabling third parties to write software for their devices, which is exemplified by 3M providing an SDK (Software Development Kit) to allow people to write software for its Bluetooth stethoscope. However, my ultimate goal will be to make one step further by implementing the kernel-level device driver that would connect devices more fundamentally (as compared to existing SDK) and, therefore, to establish an integrative and flexible hemodynamic workbench.     Some EKG classification articles (Lee, 2013) (Lihuang, 2010) relied exclusively on the MIT-BIH arrhythmia database or the standard test material to evaluate their arrhythmia detection algorithms. However, to the best of our knowledge, the difficulty of acquiring additional new raw EKG dataset due to the absence of open-source device interface for EKG instrument may be at least partially attributed to those researchers's having to work exclusively on MIT-BIH arrhythmia database. Therefore, if this software can receive the EKG raw stream over a WiFi or USB connection from instruments, future engineers can acquire additional test materials by collecting further raw EKG data alongside with corresponding EKG diagnoses, directly.     Nonetheless, companies would be cautious about opening their device protocols for my implementing the kernel-level device interface, since doing so might change the company's marketing strategies and policies. Therefore, continuous improvement of Project nGene.org® in the long-term to gain agreement concerning its clinical pragmatism and to embrace clinicians' needs by providing an easy-to-write environment for their own scripts will have to be prioritized over this kernel component.
(2) Waveform Analyses top
"(2) Waveform Analyses" component pre-processes the raw wavelet data directly from the devices via the "(1) Device interface" component. In order to handle the raw wavelet dataset, such as EKG, lung and heart sounds, etc., two core algorithms have been chosen to be common denominating features: Independent Component Analysis (ICA) separates the mixed wavelets, whereas Support Vector Machine (SVM) classifies things after being trained.     Its benefit can be illustrated by how this feature may change the existing flow. These machine-learning components can be used tentatively, until a more precise implementation of the classification for wavelets is implemented later in the point of time. For example, machine-learning algorithms for classifying EKG would be no match for a manually-written conditional statements implemented according to the Sokolow-Lyon Criteria for left ventricular hypertrophy (LVH) (Sokolow, 1949), as it would be nonsensical for training SVM to distinguish whether the summation of the S wave in V1 and the R wave in V5 or V6 is greater than, specifically, 35mm or not for LVH. However, until the manually-implemented code is developed according to certain criteria, it may be better to employ machine-learning features to accommodate wavelets in order to accelerate research and development in the meanwhile.     For an example of embedding this software into the educational CPR kit mentioned above, the AED (Automated External Defibrillation) algorithm requires distinguishing normal EKG from various arrhythmia cases. However, since the MIT-BIH "arrhythmia" database does not have normal EKG dataset, the "(1) Device Interface" component can be used to collect a normal EKG raw dataset. Once normal EKG data with diagnoses are accumulated, then the SVM algorithm can be trained to classify whether it should be defibrillated, synchronized cardioversion, non-shockable, and normal, until the development of a more accurate manually-programmed classifying algorithm.
(3) Hemodynamics top
Project nGene.org® intends to facilitate research on the hemodynamic model, not only to better understand the physiology, and but also to gain further insights into improving the model. There are numerous equations published already and in the future and it may be too late if we just wait for the echocardiography manufacturing engineer to implement the module for the equation we need. Unless it is open-sourced, it cannot possibly follow the speed of insights during research. Yale Neuron is open-sourced with GUI for simulating neuron network; however, in my opinion, no matter how flexibly a software architect may implement its GUI, it cannot be on a par with the flexibility and creativity of new equations and insights of clinicians in the future.     Therefore, Project nGene.org® tries to circumvent this problem by integrating R script so that clinicians can add their equations to test those features during echocardiographic measurements on the flies. At the same time, I believe that the success of earning popularity depends on how easy and generic it is for clinicians to add and modify the source code. Since clinicians do not have time to spend on learning, it is very important to make it very intuitive to make them willing to invest their time. I think that clinicians will invest their time only if they can get it intuitively.
(4) Medical Statistics & (5) Machine Learning top
"(4) Medical Statistics" is something that I do, not as a destination, but as a necessary step. To put it straightforwardly, the ultimate goal is "(5) Machine Learning". "(5) Machine Learning" component is pushed back on the priority list in the Masterplan Chart, because the software is designed to provide the following different types of dataset for the machine-learning algorithms: (i) Directly from hardware via the kernel program part, "(1) Device Interface"; (ii) Indirectly processing the wavelets raw data from instruments, "(2) Waveform Analyses"; (iii) Parsing and processing articles, especially meta-analysis and survival curve data, "(4) Medical Statistics", via a semantic web.     The semantic web is a very suitable piece for medicine due to several reasons: (1) It is very flexible to integrate other semantic webs together, such that it can be used as a knowledge database with numerical information. (2) This numerical information with a network form can be fed into Bayesian-based machine learning. (3) Meta-Analysis is one of the forms of very specialized information that are available in the domain of medicine, and getting the hazard ratio from the survival curve for meta-analysis was, in my opinion, the most difficult methodology and the most challenging technical barrier when building a semantic web database.top