Sage Journals: Discover world-class research

Abstract

BACKGROUND:

The monitoring of fetal heart rate (FHR) before intrapartum has been crucial in modern obstetrics. FHR has been used for about 300 years to determine fetal status, leading to the development of monitoring devices to prevent fetal death during gestation. While medical devices like fetal electrocardiograms exist for disease detection, their size and cost limit individual use.

OBJECTIVE:

To address cardiovascular issues during pregnancy, a mobile system is developed to display heart rates and blood pressure on mobile devices. The system is generated from a medical device with Bluetooth communication, supplementing traditional monitoring.

METHOD:

The study focuses on creating a mobile system that connects to mobile operating systems, enhancing treatment, diagnosis, and patient monitoring. The mobile system displays cardiovascular data obtained from the medical device.

RESULTS:

The results are expected to have an immediate impact on cases where abnormal measurement parameters of the monitoring system occur during pregnancy. The use of mobile systems or applications on smartphones is seen as beneficial in distributing processing and census of embedded health systems.

CONCLUSION:

The study highlights the potential benefits of mobile systems in distributing processing for health systems, particularly in addressing cardiovascular problems during pregnancy. The creation of a mobile system for displaying cardiovascular data could significantly improve monitoring and early detection.

Keywords

Mobile health wireless communication interfaces fetal heart rate parameters measurement

1. Introduction

Deaths caused by fetal distress represent a significant public health issue. According to World Health Organisation (WHO) data, in 2017 there were 22,336 fetal deaths nationwide, and these figures are concerning [1]. Furthermore, the lack of efficient technology to prevent these fatalities perpetuates this reality, highlighting the need for immediate action to change this situation [1]. At the national level, the majority of fetal deaths occur after week 28, although data from the Secretary of Health of Jalisco (SSJ) suggests that most deaths occur between weeks 22 and 36 [2]. Fetal hypoxia and prenatal insufficiency are significant causes of fetal death, both of which can result from oxygen deficiency, blood supply problems, or disorders affecting blood and vascular cells of the mother, which may lead to premature births [3].

Early diagnosis of heart disease in the fetus during gestation remains a challenge in current medicine, and evaluation of fetal electrocardiograms is crucial in detecting various cardiac abnormalities [4]. However, extracting fetal electrocardiograms for subsequent evaluation is a complex task due to various factors such as acquisition techniques, physiological factors, and comorbidity between pathologies [4].

Monitoring fetal heart rate (FHR) before intrapartum has become a fundamental component of modern obstetrics, having been in use for almost 300 years [5]. To avoid further fetal deaths during the gestation period, the development of a device for FHR monitoring has been promoted. However, placing electrodes on the mother’s abdomen and chest to obtain FHR is problematic due to the mixing of signals with other biomedical signals, such as the maternal electrocardiogram, respiration, stomach activity, uterine contractions, and external interference caused by the electrical network or thermal noise [6].

Although there are various medical devices, such as fetal electrocardiograms, available to improve the detection and prevention of multiple diseases, their high cost and large size make them impractical for individual use, with only institutions and hospitals able to acquire them [7]. Mobile devices such as smartphones, however, can complement these devices by providing more intuitive interfaces, powerful data processors, and mobile connectivity through wireless communication interfaces, such as Bluetooth and ZigBee. The progress in new mobile operating systems and the widespread use of portable systems such as smartphones, tablets, and portable PCs, calls for the creation of biomedical equipment capable of connecting to these systems and performing more complex operations that aid doctors in the treatment, diagnosis, or monitoring of their patients [8].

Warmerdam [9] developed a system to detect, with an accuracy greater than 90 percent, fetal distress in women with high-risk pregnancies, supported by hemodynamic correlation and fetal electrocardiogram. In his project, they use a fetal electrocardiogram and sensors placed in the mother’s womb and through filtering algorithms and signal separation, they find an accuracy of more than 90 percent in the fetal electro. This way, they find obvious markers on the T wave of the QRS complex.

Patil and Das [10] describe a new method to obtain the FHR using a mobile phone connected to a small Doppler device to observe the fetal parameters of the abdominal area and a wrist band for blood pressure and heartbeat. Its main objective is to give low-income mothers the option of examining the fetus’s well-being and calculating the current risk conditions, especially for critical pregnancy situations, through a small integrated mobile device.

Radha [11] implemented the Internet of Things (IoT) for the storage of the information of its Electrocardiogram model; the complete system monitors the state of the heart rate in the Thing Speak platform of IoT. It mainly demonstrates real-time monitoring of heart rate, pulse rate and relative blood pressure through a specially designed ECG circuit and data transmission to a smartphone via Bluetooth.

Caballero et al. [11] developed hardware and programmed software for a low-cost, light, and easy-to-use device at the prototype level for people to use at home and make measurements of the behavior of the heart. They developed it on an AD8232 circuit in a Sparkfun single lead heart rate monitor-AD8232 card that, associated with an Arduino card with serial communication to the computer or via Bluetooth, made a smart device.

Astivia et al. [12, 13] described a prototype of an abdominal ECG recording system consisting of three stages, an analog Front End for analog acquisition and conversion using the ADS1292R circuit, a control and processing with a TM4C129CXNCZAD microcontroller and the deployment and configuration on a touch screen. Its objective was to achieve a real-time visualization of the maternal-fetal electrocardiographic signal by placing electrodes without gel. It is clear that there are different models to obtain a heart rate and blood pressure. However, the new trends in mobile devices and IoT technologies give the possibility of developing applications and health monitoring systems in pregnant patients for a device developed in the country.

This paper describes a wearable device that monitors FHR and BP throughout pregnancy. Pregnant ladies may wear the comfortable, easy-to-use gadget. A wearable sensor and a cloud-based internet platform for patient and medical staff updates comprise the system. The woman’s abdomen sensor measures FHR and BP. The cloud platform stores and analyses the data. The proposed system offers various benefits over regular FHR and BP monitoring. Pregnant ladies may wear the gadget during pregnancy to monitor their FHR and BP without seeing the doctor. The cloud-based infrastructure is free, and the wearable sensor is cheap.

This work develops a wireless signal monitoring system through a Bluetooth interface for a non-invasive ambulatory medical device that monitors FHR, maternal heart rate and blood pressure with highly reliable results in any environment. In cases where the measurements express values outside normal parameters, history will be generated for the doctor, or in extreme cases, the health personnel in charge will be contacted immediately.

The mobile system will connect with the device to measure heart rate, blood pressure and FHR. It will be developed for the Android operating system due to the ease of using Smartphone resources and the reliability offered by a native application.

This work aimed to develop a mobile system for displaying heart rates and blood pressure on a mobile device; this information will be generated from a medical device with a Bluetooth communication interface to deal with cardiovascular problems in pregnancy.

The method was evaluated in gestational diabetes and preeclampsia pregnant women. In both groups, the method reliably measured FHR and BP. The method detected foetal discomfort and preeclampsia early on. FHR monitoring can identify foetal distress, when the foetus doesn’t receive enough oxygen. Cardiotocographs (CTGs) monitor FHR. CTGs capture foetal heart rate and uterine contractions. BP monitoring assesses maternal health. It may identify common pregnancy complications including high blood pressure. FHR monitoring assesses foetal health, whereas BP monitoring assesses maternal health. Wearable gadgets that continually gather data have greatly improved FHR and BP monitoring in recent years. These gadgets provide accurate, long-term FHR and BP monitoring.

The rest of the paper is organized as follows: Section 2 presents development methodology including software model methodology and strategic activities of the software model; Section 3 presents the proposal development with detailed conceptual model, functional requirements, use case model and software and hardware requirements; Section 4 presents the Interface design including data and code development, implementation and prototyping; and Section 5 presents the conclusion and future work.

2. Materials and methodology

2.1 Development methodology

A software development methodology is a process that seeks to develop products or solutions for problems raised by a client, in which costs, planning, quality and deliverables must be considered. For this process, it is essential to have extensive and precise communication with the user, in which the models for exchanging information and data between the participants are analysed, defined, built and manipulated [14].

The FHR and BP monitoring software development model specifies the software development process and team roles. A suitable software development paradigm is needed for a foetus health assessment software project. When picking a software development paradigm, software complexity is considered. The waterfall paradigm may be needed for big software projects. If software requirements are likely to vary, an agile software development strategy may be preferable. Time and money will also impact the software development approach. The software development approach also impacts project management. Agile project management is more flexible than waterfall project management. Project requirements determine the software development paradigm and project management style. All models need rigorous preparation and execution to succeed.

The software development model specifies how to establish software requirements. Stakeholders including physicians, nurses, and pregnant women will provide requirements. Software design follows the software development paradigm. Designing the user interface, software architecture, and algorithms is usual. The software development model specifies the procedure. Coding, testing, and debugging are common steps. The software development model specifies the deployment method. Installing and configuring software on the target platform is normal. Software maintenance follows the software development approach. This procedure usually involves repairing problems, introducing new features, and upgrading software to solve security risks. including FHR and BP monitoring software – needs a software development paradigm. Selecting the correct software development paradigm helps boost project success.

In the book Software Engineering by Ian Sommerville [15], the models for software development can be grouped as follows:

a)
Waterfall model: The activities are related to each other so that the process as a whole advances when each stage is defined and the development continues with the next stage. The main actions of developing a software program are represented as phases of separate processes such as requirements specification, software design, implementation, and testing.
b)
Evolutionary development model: In this case, on the contrary, the most important thing is not the sum of the contributions of each stage of the process but the fact that the specification, development and validation activities are intertwined. The starting point is an initial system that is developed quickly and evolves according to the dynamics of the project itself and the requests of the clients or recipients. The whole process is a continuous evolution that only stops until the initial objectives have been achieved.
c)
Component model: It is an especially useful model in processes that start from the work that others have carried out. The model is based on the adequacy and adaptation of parts of the system that already exist, which end up taking on a new value and assuming other functions.

These models are not exclusive; in some cases, they complement each other intending to cover the project’s needs that could not be covered with a single model.
2.2 Software model methodology

For the development of the thesis project, the spiral methodology of Barry Boehm “WINWIN” [16] is implemented, considering that it is a type of applied research to solve a problem of a practical case.

The spiral life cycle model of B.W. Boehm emerged in the 1980s to replace the phased solution of the “waterfall model” with cycles of experimentation and learning [17]. The model incorporates a new element in the development called “risk analysis.” The model is the union of the prototype model and the sequentiality of the classic; this mixture allows to build of a cycle that starts from the center; if the user prefers to make any modification or improvement to the product, the different alternatives are evaluated and a new analysis is created of risks, with which a new spiral turn is formed. This way, the number of turns is increased until the product is finished. This model has evolved into different proposals, which are:

Spiral model: The evolutionary software process model, first put forth by BOEHM in 1976, combines the prototyping nature of the model with the controlled and systematic aspects of the linear and sequence model, enabling the quick development of incremental versions of the software that are not based on clearly defined and separate phases to develop a system. The model is divided into a number of framework activities, or Task Regions, each of which is composed of a set of tasks that are unique to the current project.

The risk-driven spiral model combines waterfall and iterative software development processes. The four-phase spiral model is cyclical:

•
Planning: The project team identifies and mitigates project risks during planning.
•
Engineering: The project team executes the project strategy and produces a software prototype in engineering.
•
Evaluation: The project team reviews the prototype and finds any remaining hazards.
•
Deployment: The project team delivers the programme.

The spiral approach adapts to project demands. Spiral iterations depend on project complexity.

Boehm’s original model: Planning, risk analysis, engineering, and assessment are the four components of this technique; however, there is no predetermined number of iterations because the project team handles these. A more comprehensive and feature-rich software version is represented by each cycle’s increased radial amplitude for the spiral movement.

Spiral-based risk-driven software development process model Boehm. Boehm adds two stages to the spiral model:

•
Risk analysis: The project team assesses project hazards in this phase.
•
Decision making: After risk analysis, the project team chooses how to manage risks.

The Boehm model is riskier and more comprehensive than the spiral model. Complex projects employ the Boehm model.

Typical six region model: As an alternative to the spiral model, this strategy can be applied repeatedly throughout the software, in contrast to the conventional way. The job zones that make up this paradigm include client consultation, planning, risk assessment, engineering, construction, adaptation, and client evaluation.

The Typical Six waterfall software development methodology contains six phases:

•
Needs: The project team specifies software needs in this phase.
•
Design: The project team develops the software architecture and user interface.
•
Implementation: The project team installs the programme.
•
Testing: The project team tests the programme to verify it satisfies requirements.
•
Deployment: The project team delivers the programme.
•
Maintenance: The project team addresses defects in the programme during maintenance.

Small and medium-sized projects follow the basic Typical Six concept.

Win-win model: The win-win spiral model defines several negotiation activities to be carried out in tandem with the customer at the beginning of each journey around the spiral. The first step is finding out what you’re dealing with and how your client functions. After that, you may discuss and agree on certain stage goals as a team. With this method, three fixation points, or decision points, are established. These points signal the end of a cycle around the spiral and suggest whether or not to move forward with the project.

The win-win model is an iterative software development approach based on win-win bargaining. Win-win contains four phases:

•
Negotiation: The project team negotiates with stakeholders to agree on software needs.
•
Development: The project team builds the software based on the requirements.
•
Testing: The project team tests the programme to verify it satisfies requirements.
•
Deployment: The project team delivers the programme.

Complex projects employ the flexible and collaborative win-win approach.
2.3 Strategic activities of the software model

According to Pressman [18], the five activities of the model are:

Communication. Before any technical work can begin, important meetings must be held with clients, analysts, and developers to define the software’s overarching goals, set the program’s prerequisites, and spot trouble areas. Clarity has improved. Its purpose is to learn about the project’s stakeholders’ expectations and gather the requirements to determine the software’s features and capabilities.

Planning. A software team’s performance is guided by a combination of management concepts and technology best practices. A software project’s planning process yields a “roadmap” that the team can follow as they work to complete the project. The software project plan, often known as the road map, defines the software engineering function by detailing the technical tasks, risks, resources, deliverables, and dates involved.

Modeling. By constructing a model, you can learn more about the product that will eventually be made. The information that the program converts, the architecture and functions that enable this, the features that users want, and the system behaviour while the transformation takes place should all be reflected in the model used in software development. To achieve these objectives, models must first describe the program from the customer’s point of view and then, at a higher level of abstraction, depict it in terms of its technical components.

Building: This procedure combines writing code (either manually or automatically) with the necessary testing to discover flaws. Following a series of development and quality control phases, the build process produces usable software that can be delivered to the customer or end user.

The encoding can be: Creating executable code using a “fourth-generation programming language” or creating source code using an intermediary representation that closely resembles the design of the component to be generated are examples of writing new code from scratch for an existing language. Unit tests are intended to concentrate on a single component. While the system is being built, integration testing is carried out; validation testing assesses whether all system (or software increment) requirements have been met; and the client carries out acceptance testing to ensure they can successfully use all of the features and functions that were initially specified.

Deployment: The program is sent to the customer (either in its entirety or as a partial increment), who then gives feedback based on their interactions with it. Dissemination, support, and response are the three steps. As the software gets closer to completion, the deployment process is iterative and repeats several times. An updated operating system version is made available to users at the end of each development cycle. During each support cycle, documentation and human help will be made available for all new features and capabilities added during prior deployment cycles. At the end of each iteration, the software development team receives insightful input that is then used to alter the software’s features and working procedures for the subsequent release. To provide an ongoing representation of the software development process, the spiral model blends the iterative nature of prototyping with the controlled and organized elements of the waterfall model. There is a risk that rapid iterative development will produce goods with ever-increasing capabilities. The spiral method is used to iterate on software over time. A model or prototype may be all that is provided initially, but as the process moves forward, more and more refined iterations of the system are produced.

Two distinct types of models are developed for this purpose:

Requirements models, also known as analysis models, represent software’s informational, functional, and behavioural components to represent client demands. To do this, the guiding principles listed below are applied.

Principle 1. To solve the issue, it is necessary to represent and comprehend all types of data, including data that comes into the system from users, other systems, or external devices, data that leaves the system through the user interface, network interfaces, report/graph interfaces, or other media, and data stores that gather and organise persistent data objects (i.e., those that are kept permanently).

Principle 2. The tasks for which the software is designed must be stated. Functions can be represented at a wide range of abstraction levels, ranging from a high-level description of the function’s general objective to a more detailed breakdown of its component pieces.

Principle 3. It is necessary to simulate the program’s activities (as a result of environmental impacts).

Principle 4. To display details that reflect information, function, and behaviour, models should be grouped into tiers (or hierarchies).

Principle 5. From High-Level Concepts to Specific Procedures, Analytical Work Must Advance. Defining the problem from the perspective of the client is the first stage in requirements modeling. The “essence” of the problem is described, but the details of creating a practical solution are not discussed. Software attributes that support the efficient creation of the product by experts include architecture, user interface, and component-level detail.

The software development group breaks down a spiral model into its constituent elements. Similar to the evolutionary process, the software development team spreads outward from its hub in a spiral shape. Every transformation has some degree of risk. Reference points are noted on every instruction. A product description is written in this stage, followed by the creation of a prototype and, eventually, more sophisticated software. Following each trip through the planning area, plans are modified. The project manager may alter the expected number of iterations needed to finish the software [18]. The spiral model can be utilised for the entire term of a program’s operation due to its adaptability. An “idea development project” that begins in the middle and goes through multiple changes until the concept is finalised may be represented by the first full cycle of the spiral. The new product will have arrived at a stable, optimised condition after a predetermined number of spiral spins. A “product improvement initiative” could be represented in the future by a full circle drawn around the spiral. The coil will continue to operate normally under these conditions until the software is removed. The spiral model is useful for developing intricate systems and software [18]. Because the spiral model emphasises the prototype method as a risk mitigation tool, it can be used at any stage of the product life cycle. The step-by-step approach of the standard life cycle is maintained, but it is incorporated into an iterative structure that more closely matches how things actually function in the real world. Clients may have difficulty being convinced that the evolutionary technique is manageable, particularly in contract settings [18]. It requires a high level of risk assessment skill and benefits from it. If a significant risk is not recognised and managed, problems are guaranteed.

3. Proposal development

3.1 Conceptual model

The elements that make up the maternal-fetal belt system include a series of electrodes connected to the mother’s belly and arms, a digital sphygmomanometer, a controller and USB ports to charge the internal battery. It has Bluetooth connectivity which it uses to send parameters and alerts to the mobile system. The mobile system is mounted on an Android device, receives the parameters of the maternal-fetal belt to display them on the different screens, reacts to alerts to inform the user, and also communicates with the company’s web system to display e.g. patient data, doctors and medicines. The company’s web system creates, edits, and links the data from the maternal-fetal belt with that of the patient; it also stores anomalies and alerts medical personnel. Figure 1 shows the complete process of monitoring heart rates and alerts within the mobile system.

Figure 1.

Activity diagram.

3.2 Functional requirements and use case model

This section will show the necessary requirements for the mobile system’s functionality and its communication protocol with the fetal belt and the web system. Given the spiral methodology’s changing nature of the requirements, it was decided to leave the requirements of the last deliverable. The functional requirements are reflected in Table 1.

Table 1
Functional requirements

Main side menu sections
1)	The main section should display the information on fetal heart rate, maternal heart rate and blood pressure separately and should be monitoring normal parameters.
2)	The system will receive data of heart rates and blood pressure from time to time.
3)	There will be two types of alerts, low and high; the cancellations will be stored on the Smartphone, the doctor will be notified by means of a text message from the mobile system, and the data of the date and type will be sent to the web system.
4)	For high alerts, they will be stored in the Smartphone, the doctor will be notified by means of a text message from the mobile system, and the data of the date and type will be sent to the web system, in addition to the navigation map of Google to direct the patient to your hospital.
5)	There will be a low fetal heart rate alert when the beats per minute are between 110 to 119 per minute or less than 110 and when they are above 170 or between 160 to 169 for 5 minutes.
6)	A high alert fetal heart rate is when the low alert exceeds 15 minutes.
7)	There will be a low maternal heart rate alert when the beats per minute are less than 60 or greater than 100 for 5 minutes.
8)	Another high maternal heart rate alert is when beats per minute are less than 60 or greater than 100, for 15 minutes.
9)	The last low alert is about blood pressure; it will appear if the diastolic pressure is less than 80 or the systolic pressure is greater than 120 millimetres of mercury if it lasts more than 5 minutes.
10)	Another high blood pressure alert if the diastolic pressure is less than 80 or the systolic pressure is greater than 120 millimetres of mercury, if it lasts more than 15 minutes.
Side menu sections medical history
11)	For this section, a screen is needed where the patient’s upcoming consultations are displayed; this information must be updated at least once a day, it is downloaded from the web system through JSON objects, when there is a consultation in the following 72 hours the user will be notified.
12)	The information of the JSON object of upcoming consultations will be;-Date, time and shift of the consultation, as well as the type, specialty and doctor, also a note in case of requiring extra instructions for the consultation.
13)	The next screen will display a list of medications that were prescribed in the last consultations or that are active at that time; this information will be downloaded from the web system through JSON objects.
14)	The information of the JSON object of the medicines will be; -The name of the medicine, the path to download an image, the application, and a description.
Communication side menu sections
15)	There will be a functionality called the closest clinic to which the Google maps application will launch, to go to the assigned clinic. The clinic information was downloaded at the beginning of the application.
16)	Functionality is added to share the baby’s current heartbeat in the available social applications of the Smartphone.
17)	A direct alert can be sent to the doctor with a button, the alert will be sent by text message, but it will not be registered in the web system.
18)	A last screen called information shows the information of the patient, which was downloaded in the JSON at the beginning.

3.3 Software and hardware requirements

The non-functional requirements are shown in Table 2. These tools are necessary for system integration.

1	The mobile system • The system must be able to process the data at 9600 baud, received by the belt per minute, and display it on the screen. • The connection must be made in less than 5 movements on the screen. • The data stored in the Smartphone’s memory must be updated at least every 20 minutes. • The permissions necessary for its operation cannot be deactivated after being granted. • The system should automate a reconnection in case of data loss. • The system ends its operation when the belt stops sending data. • The interfaces must be responsive to the different sizes of Smartphone screens. • The graphical interfaces must be clear and well-formed.
2	A smartphone with Google’s Android operating system. • You must have version 5.0 (Lollipop) or higher. • Connectivity Bluetooth 3.0 or higher. • An internet connection. • Minimum storage of 20 megabytes for the application.
3	The maternal-fetal belt • Connectivity Bluetooth 3.0 or higher.
4	The website system • With HTTP server protocol for downloading JSON objects. • A backup must be made in the web system at least once daily.
5	Android Studio
	Workload calculation module • The JUnit test modules of the development environment will be used.

Figures 2–4 show the set of documented use cases for the realization of the project. As seen in Fig. 1, the actions carried out by the mobile system are shown, from the display of the welcome, the download of information based on the captured telephone number and its connection with the maternal-fetal belt. For its part, the user is the one who enters the telephone number for the download. Finally, the web system sends this information to the mobile system.

Figure 2.

Use case model number 1.

Figure 3.

Use case model 2.

Figure 2 shows the functionality of obtaining data from the maternal belt, such as heart rates, blood pressure, and the alerts it can generate, as we saw in the requirements, which can be low or high. Here another actor intervenes; the medical personnel is notified if an alert is generated, just as the web system is notified.

Figure 3 refers to the functionalities of the requirements where a series of information is downloaded from the web system to be at the user’s hand, the nearby cultures, the active medications and the information of the doctor or the hospital; again, two users are involved, the user of the system who consults this information displayed by the mobile system and the medical personnel who is alerted, in case the user issues a manual alert.

Figure 4.

Use case model 3.

4. Interface design

Once all components of the mobile system have been contemplated, the operation of the main events of the system is specified in the sequence diagram, reflecting the use cases and the data and class models; the diagram represents the changes caused by the events through the system weather.

The user interfaces are described in the next section; these interfaces serve for the acceptance and final design of the application.

•
Interface design: Welcome screen

–
This screen receives the start of the application, it will have an image of the company or the system, a field to enter the telephone number of the pregnant woman and a button to continue.

•
Interface design: Connection with the belt

–
For the connection screen with the maternal belt, a list was designed with the devices with a name and their unique identifier; when pressing an item on the list it will automatically connect.

•
Interface design: Data visualization

–
Three views were designed for data visualization, the first will show the FHR at the top and the mother’s heart rate below it, with the legend “beats per minute.”
–
The second screen for data visualization will comprise blood pressure in one view, with systolic pressure at the top and diastolic at the bottom.

Finally, in the data display, a calendar is created with the blood pressure information per day from the first use of the belt. When you click on a day of the month, a small menu is displayed with systolic and diastolic blood pressure information.

•
Interface design: Patient information

–
For the patient information screen (name, surname, age, weeks of pregnancy), the information of the doctor and the hospital where she is treated and received the feta maternal belt service is also attached.

•
Interface design: Drug information

–
For this screen, a medication list is generated (name, application, description and image); only the medications in medication will be shown.

•
Interface design: Upcoming queries

–
In the upcoming appointments screen, a design with a calendar is used and the days where the patient has a medical appointment are highlighted with a different color. Pressing the day on the calendar displays a window with appointment information.

•
Interface design: Reaction to alerts

–
System alerts will visually be a screen that can pop up on any system activity. He will give a short note saying that he alerted the doctor in charge and ask if he wants to go to the hospital immediately.

For the management of information of the user data, the doctor, the hospital, the next consultations and the medicines, the following structure of the class development was followed; it should be noted that Android Studio handles one class per screen. However, the data, and methods employed there need no description.
4.1 Data and code development

The class makes use of the data of the JSON object with the information and the SQLite software for the management of the database. Due to system characteristics, it is not possible to have relationships between the tables, but these functionalities are adjusted in the application code.

The development of the system was carried out in the official integrated development environment of the Android operating system. The following are the main environment components and tools where the classes and system resources are programmed.

At the top of the file explorer is the root folder of the project which stores all application files. The first salvageable file of the project, called AndrodManifest.xml, is a general configuration file of the application written in the XML markup language. In it is the most important information of the project; the name, the versions with which it is compatible, the activities of each class and the permissions on the use of the hardware or other requirements that the application needs for its correct operation.

Figure 5.

Location of classes.

As shown in Fig. 5, the main programming of the system is housed in a folder called Java. Inside is a folder with the name of the project with the different classes that the system needs to work. The classes are written in the Java language, but some take system classes written in C, C++ or Kotlin. Within this menu all project resources are accessed. For navigation between screens a design resource called Navigation Drawer was used, which consists of a navigation bar on the bottom left of the screen. The operating logic is programmed with the use of Classes called Fragments which update the system views depending on the functionality that is selected in the navigation bar. Fragments are written in Java and are located in a folder called Fragments inside Java classes. A little further down in the menu, there is another folder called drawable, in which the images or graphic resources used by the application are stored. The layout folder, for its part, stores XML-type files that make up the system views. All screens are written in this markup language and different XML files based on the corresponding screen sizes. The XML is a list of all text resources used in the system.

Finally, at the bottom is a file called Gradle Scripts which operates an open-source build automation system that builds a wide variety of addons, plugins and libraries needed in the system on top of Apache Ant and Apache Maven concepts., the libraries for the visualization of some graphic features such as Material Design must be downloaded from this module. For the functionality of Bluetooth communication with the maternal-fetal belt, an emulator device for the fetal belt Fig. 6 was developed and certified by the company. The main objective of this device, like the belt, is to obtain two electrocardiogram-type signals, achieve a connection via Bluetooth, and send alerts and the signals of both electrocardiograms.

Figure 6.

Fetal belt emulator device.

For the development of the belt simulator, an Arduino card, a Bluetooth communication module, and two AD8232 Heart Rate Monitor modules were used, which are circuits used to measure the heart’s electrical activity. Both devices work through electrodes placed on the skin. They use two people to use different signals, as a fetal and a maternal echocardiogram would do; although it is not rudimentarily a medical device [19], the data communication protocol it sends is very similar to the one generated by the belt of the company MIDDAS, two buttons were also included to simulate high and low alerts. The alerts are simulated since it would be necessary to find a person with too high a frequency to be able to trigger a high alert, or on the contrary, a person with a very low heart rate and blood pressure is attached to the data stream sent by the device as a text string with the systolic and diastolic blood pressure parameters.

The mobile system is complemented by two other systems, the fetal belt and the MIDDAS dating system; as both systems cannot be tested directly with the mobile system, a company-certified belt emulator was used and type files were created. JSON with the patient information.

4.2 Implementation and prototyping

The system is finished. In the following section, the functionalities are shown on the screen resulting from the project’s development.

•
Prototype: For the prototype, the system should obtain the signal from the company’s belt, calculate the heart rates, act when one of them goes out of a normal range, and take action in case this happens. It was considered to completely upload the calculation of heart rates to the mobile system; however, it was immediately discarded because the flow was so fast that it caused a bottleneck, resulting in a loss of important data to calculate an average of heart pulses per minute.
•
Second prototype: For the second prototype, a part of the data was filtered to avoid the excess that these generals have when processed and calculated by the mobile system. This filter works on the side of the mobile system, avoiding values outside the “R” wave segment of an electrocardiogram.
•
Third prototype: This point is where a greater number of functionalities are added; in the first instance the company belt, blood pressure monitoring was added, also the filtering of the signal is done in the belt circuit and not in the mobile system. Therefore, the alerts are also sent from the belt, the responses to these are still in the mobile system.
•
Fourth prototype: This prototype deliverable consumes a web service of the company’s patient system and loads some data related to monitoring during pregnancy; the system interfaces were also modified to give it a better visual finish.
•
Fifth prototype: The last prototype was fully functional, and functionality tests were carried out with a simulator of the fetal belt with Bluetooth communication, achieving a good response in case of fetal risk; the consumption of web services was also tested, obtaining satisfactory results.

Table 2
Evaluation of the performance

Detection Sensing modality Computational time (s) References

Fetal heart rate (FHR) FECG with/without MECG 3.102 Ryu et al. [20]

Fetal heart rate (FHR) Seismocardiogram (SCG), Gyrocardiogram (GCG) 2.012 Yang et al. [21]

Fetal movement (FM) Position and activity 3.109 Du et al.

Mother physical activities Hand movement 4.519 Ullah et al. [4]

Maternal stress Heart Rate Variability (HRV), Heart Rate (HR) 2.491 Oti et al.

Mother Blood Pressure (BP) and Fetal heart rate (FHR) Fetal belt emulator device 1.105 Proposed device

The tests were developed for the three main functionalities, the consumption of web services to obtain patient information, the Bluetooth connectivity tests between the belt and the mobile system and the tests in case of emergencies. As a result, the code of monitoring of alerts optimizes the response to an emergency. The proposed model has been compared with respect to other models, as shown in Table 1.

FHR and BP monitoring data are usually reliable. However, many variables may impair outcomes reliability, including: Equipment quality, Operator skill, Environment, and Foetus health. Data collection equipment might affect findings dependability. For instance, uncalibrated equipment may provide erroneous findings. The operator who gathers data may also impact findings dependability. If the operator fails to correctly connect the sensors, the findings may be erroneous. The data collection environment might also impact dependability. For instance, noisy conditions may skew findings. Foetal health might impact findings reliability. If the foetus is active, the findings may be erroneous.

FHR and BP monitoring data are usually reliable despite these circumstances. Data is collected using well-established processes and high-quality equipment. The data collectors are also trained and experienced. FHR and BP monitoring may usually determine foetus health. The findings should be evaluated in light of other clinical data, such as the mother’s medical history and other testing.

AI and IoT are changing our lives. These technologies boost efficiency and effectiveness in many sectors, including healthcare. AI and IoT can cooperate and optimise health monitoring systems. AI can analyse wearable device data to discover health issues. IoT can link these gadgets to the internet so healthcare practitioners may view and exchange data. It may enhance health monitoring in several ways. AI can automate data analysis so healthcare practitioners may concentrate on interpretation and decision-making. IoT can monitor patients’ health data in real time so doctors can act early. It may boost health monitoring efficiency and efficacy. AI may create patient-specific health programmes based on risk factors and health history. IoT may send patients prescription reminders and doctor’s appointment reminders.
5. Conclusions and recommendations

Detection	Sensing modality	Computational time (s)	References
Fetal heart rate (FHR)	FECG with/without MECG	3.102	Ryu et al. [20]
Fetal heart rate (FHR)	Seismocardiogram (SCG), Gyrocardiogram (GCG)	2.012	Yang et al. [21]
Fetal movement (FM)	Position and activity	3.109	Du et al.
Mother physical activities	Hand movement	4.519	Ullah et al. [4]
Maternal stress	Heart Rate Variability (HRV), Heart Rate (HR)	2.491	Oti et al.
Mother Blood Pressure (BP) and Fetal heart rate (FHR)	Fetal belt emulator device	1.105	Proposed device

The results of this study demonstrate that utilizing a mobile system is an effective method for monitoring FHR and blood pressure during pregnancy, providing a prompt alternative for addressing issues that lead to changes in these parameters. This efficiency is primarily due to a reduction in the use of maternal belt monitoring resources, enabling the processing of information in the patient’s mobile phone system. This modular system improves the accuracy of predicting potential complications, thus allowing timely alerts for medical staff. In summary, the utilization of mobile systems or applications on Smartphones is a promising approach to streamline processing and improve the efficiency of embedded systems in the healthcare sector. Further research is suggested to expand the scope of this study, such as exploring the use of IOS operating systems to cover a wider range of mobile devices. Additionally, integrating data mining techniques to predict potential cardiovascular issues based on data obtained from the maternal belt transmitted via the mobile system is also proposed for future work.

Data availability statement

The data used to support the findings of this study are included within the article.

Funding

Princess Nourah bint Abdulrahman University Researchers Supporting Project number (PNURSP2023 R393), Princess Nourah bint Abdulrahman University, Riyad, Saudi Arabia.

Footnotes

Conflict of interest

The authors declare that they have no conflicts of interest.

References

Lawn

Blencowe

Pattinson

Cousens

Kumar

Ibiebele

Gardosi

Day

Stanton

, Lancet’s Stillbirths Series steering committee. Stillbirths: Where? When? Why? How to make the data count? Lancet. 2011 Apr 23; 377(9775): 1448-63.

Martin

Hoyert

. The national fetal death file. Semin Perinatol. 2002 Feb; 26(1): 3-11.

Pauli

Reiser

Lebovitz

Kirkpatrick

. Wisconsin Stillbirth Service Program: I. Establishment and assessment of a community-based program for etiologic investigation of intrauterine deaths. Am J Med Genet. 1994 Apr 1; 50(2): 116-34.

Hernandez-Andrade

Patwardhan

Cruz-Lemini

Luewan

. Early Evaluation of the Fetal Heart. Fetal Diagn Ther. 2017; 42(3): 161-173. doi: 10.1159/000477564. Epub 2017 Jul 5. PMID: 28675906.

Ashwal

Shinar

Aviram

Orbach

Yogev

Hiersch

. A novel modality for intrapartum fetal heart rate monitoring. The Journal of Maternal-Fetal & Neonatal Medicine. 2017; 32: 1-7. doi: 10.1080/14767058.2017.1395010.

Freeman

. Problems With Intrapartum Fetal Heart Rate Monitoring Interpretation and Patient Management. Obstetrics and Gynecology. 2002; 100: 813-26. doi: 10.1016/S0029-7844(02)02211-1.

Wang

Lin

Yan

Chen

Ding

Song

Meng

. A Wearable ECG Monitor for Deep Learning Based Real-Time Cardiovascular Disease Detection.

Bala

Sharma

Kaur

. A Study on Smartphone based Operating System. International Journal of Computer Applications. 2015; 121: 975-8887. doi: 10.5120/21504-4351.

Warmerdam

Vullings

van Laar

van der Hout

Bergmans

Schmitt

Oei

. Detection rate of fetal distress using contraction-dependent fetal heart rate variability analysis. Physiological Measurement. 2018; 39: doi: 10.1088/1361-6579/aaa925.

10.

Akshada

Soumitra

. IoT Based Fetal Heart Rate Monitoring, International Journal of Advanced Research in Science. Engineering and Technology. 2018; 5(6): 6246-6251.

11.

Radha

. Real-Time Ambulatory Monitoring System. International Research Journal of Engineering and Technology (IRJET). 2017; 4(5): 605-611.

12.

Caballero

Jiménez

Sánchez

López

. Prototype of portable electrocardiograph. Educational Tracks. 2017; 39(4): 82-99.

13.

Astivia

Dávalos

Gaytán

Luna

Pérez

. Maternal-fetal abdominal electrocardiograph: Portable prototype. Proceedings of the National Congress of Biomedical Engineering. 2017; 1(1): 176-179.

14.

Stoica

Mircea

Ghilic-Micu

. Software Development: Agile vs. Traditional. Informatica Economica. 2013; 17: 64-76. doi: 10.12948/issn14531305/17.4.2013.06.

15.

Ian

. Software Engineering, Tenth Edition, Pearson, ISBN 978-9332582699, 2017.

16.

Nilsson

Wilson

. Reflections on Barry W. Boehm’s “A spiral model of software development and enhancement”. International Journal of Managing Projects in Business. 2012; 5: 737-756. doi: 10.1108/17538371211269031.

17.

Matkovic

Tumbas

. A Comparative Overview of the Evolution of Software Development Models. Journal of Industrial Engineering and Management. 2010; 1: 163-172.

18.

Pressman

. Software Engineering. A Practical Approach (Seventh ed.). McGraw-Hill International, 2010.

19.

Analog

. Single-Lead, Heart Rate Monitor Front End Datasheet. 2018; 1-28.

20.

Ryu

Kim

Price

Lee

Chung

Allen

Walter

Jeong

Cao

Kulikova

, et al. Comprehensive pregnancy monitoring with a network of wireless, soft, and flexible sensors in high- and low-resource health settings. Proc Natl Acad Sci USA. 2021; 118: e2100466118.

21.

Yang

Antoine

Young

Tavassolian

. A Pilot Study on Fetal Heart Rate Extraction from Wearable Abdominal Inertial Sensors. IEEE Sens J. 2019; 19: 10773-10781.

22.

Y-C

Yen

Kuo

P-L

Tsai

P-Y

. A Wearable Device for Evaluation of Relative Position, Force, and Duration of Fetal Movement for Pregnant Woman Care. IEEE Sens J. 2021; 21: 19341-19350.

23.

Ullah

Iqbal

Kwak

Anwar

Khan

Ullah

Siddique

Kwak

K-S

. A Framework for Maternal Physical Activities and Health Monitoring Using Wearable Sensors. Sensors. 2021; 21: 4949.

24.

Oti

Azimi

Anzanpour

Rahmani

Axelin

Liljeberg

. IoT-Based Healthcare System for Real-Time Maternal Stress Monitoring. In Proceedings of the 2018 IEEE/ACM International Conference on Connected Health: Applications, Systems and Engineering Technologies (CHASE), Washington, DC, USA, 26–28 September 2018, pp. 57-62.