PREGNABITPregnabit — Real-Time Fetal Health Monitoring with Machine Learning Signal Analysis
Pregnabit is a professional telemedical CTG monitoring system that enables pregnant women to record cardiotocography traces at home. Our team built the real-time signal analysis layer using R and machine learning, processing diagnostic data from Pregnabit hardware to support clinical decision-making in prenatal care.
Scope of work
Data Analysis
R
Python
AWS Cloud
Genesis of the Project
Nestmedic is the manufacturer of the innovative telemedicine solution Pregnabit for remote monitoring of fetal well-being, through cardiotocography (KTG). At present, Nestmedic is conducting research and development, taking into account both new devices related to fetal well-being and the improvement of Pregnabit Pro. Soon, the Company plans to expand the device, with the function of a glucometer, or blood pressure testing, and introduce wireless probes equipped with light and vibration signaling, which will replace the wired ones and increase the comfort of the examination.
Challenge
The main challenge of this project was medical data and concepts understanding as healthcare sector data may be hard to understand at first. Also, there were challenges with algorithms adjustment and communication with the client.
Expertises
Healthcare & Lifestyle
Location
Poland
Main goals
The main goals of this project were to make algorithms more accurate and advanced as algorithms are extremely important when solving any type of computer science problem. Secondly, we were measuring the following: bradycardia and tachycardia, accelerations/decelerations, and TOCO.
All of these functionalities are an important part of the benefits of this application as Pregnabit sends data collected by the device by wireless data transmission to the Description Centre operated by qualified medical staff.
Solutions
The solution was to develop algorithms in R language and host them on the AWS cloud. We’ve chosen this solution because R is one of the most popular languages for statistical modeling and analysis, but not just because of that as R language also is an open-source programming language. This means that anyone can work with R without any need for a license or a fee.
Furthermore, even after the project, our clients can contribute to the development of R by customizing its packages, developing new ones, and resolving issues, so the application stays on time and can be updated with the latest trends and needs.
Summary
In this project, our client was Nestmedic company from the healthcare sector. They needed our expert help for their application called Pregnabit, which lets its users get CTG monitoring during the whole pregnancy. This system also records CTG traces in any place and at any time in a home environment.
Our experts had to improve and develop the algorithms that detected the fetus defects based on the data from a hardware device, so users could get a better experience with the Pregnabit app.
As a solution, we’ve chosen to develop algorithms in R language as R is one of the most popular languages for statistical modeling and analysis and because it is an open-source programming language that will let our clients update the application on time even after we cooperated with them. Also as a solution, we’ve hosted the algorithms on the AWS cloud, which will let app users get the best possible experience with the product.
Start your AI agent project today
Request a call today and get free consultation about your custom software solution with our specialists. First working demo just in 7 days from the project kick‑off.
Matt Sadowski
CEO of Mobile Reality
Case studies
Explore our past successes and see our expertise in action with our data science and healthcare case studies. Discover how we've helped healthcare industry drive growth and success from mobile apps to data analysis.
Frequently Asked Questions
Cardiotocography (CTG / KTG) measures fetal heart rate and uterine contractions. Traditionally it's done in clinic on a bedside machine. Remote CTG devices let pregnant patients run sessions at home, transmit the recording to a clinical platform, and have a clinician review it within hours instead of requiring a hospital visit. The platform's job is signal handling, automated screening, and a clinician review workflow that scales without compromising clinical accuracy.
ML models pre-process recordings to: (1) detect signal-quality issues (electrode loss, maternal heartbeat contamination); (2) classify trace patterns (baseline FHR, variability, accelerations, decelerations) per FIGO or NICE guidelines; (3) flag high-risk recordings for priority clinician review. ML is decision-support, not autonomous diagnosis — final calls remain with the obstetrician. Regulatory framing (FDA SaMD, EU MDR) treats clinical-decision-support ML as Class IIa or higher, requiring CE mark / FDA clearance.
The platform sits in regulated medical software territory: EU MDR (or FDA SaMD framework in the US) for clinical-grade software, ISO 13485 quality management, IEC 62304 for software lifecycle, and HIPAA / GDPR for patient data. PHI must be encrypted at rest and in transit; access logs are mandatory; data retention follows local healthcare retention rules (often 20+ years for obstetric records). Penetration testing and secure SDLC are baseline expectations from healthcare buyers.
Recordings land in a triage queue ordered by ML-assigned risk score and time-since-recording SLA. A clinician dashboard shows the top of the queue; opening a recording surfaces the trace, ML annotations, patient history, and a structured assessment form. Reviewed records get categorized (normal / repeat in 24h / urgent contact); the platform routes follow-up actions (SMS to patient, escalation to OB on call). The point is to keep the clinician's time on actual interpretation, not navigation.
Common toolchain: Python (NumPy, SciPy, scikit-learn, PyTorch / TensorFlow) for model development; R for statistical validation expected by clinical reviewers; MLflow or similar for experiment tracking and model registry; AWS for training (SageMaker or EKS-on-GPU) and inference (containerized API behind an internal load balancer). Models are versioned with their training data fingerprint, since regulatory submissions require reproducibility years later.