Some will be automatically collected, via the sensorized KMC device. For example, the 4 vital signs related to breathing, heart rate, body temperature, and oxygen saturation.
There will be data automatically captured regarding how many hours the baby spends in skin-to-skin/KMC care, versus non-skin to skin/KMC (we call this the “stand alone mode”).
Data will be automatically captured regarding the functioning of the device itself. For example, if a sensor stops working, that information will be transmitted to the app, and should send an alert.
Some information that has been discussed previously in this thread, such as data about the baby’s feeding, urine output, or family’s attendance at educational sessions, would have to be entered manually, at this time.
Hi @shbucher I understand each and every point that you explained but I have one question related to transmitting data from parents’ devices to health workers as KMC devices we will be nearer to parents so are we using any NoSQL database for storing baby’s vital signs or we will be creating our own server for establishing communication between parents and health workers?
@shbucher for example till now we did not know about the standalone mode of the device. I believe there are still many things we dont know. Can you please explain the entire cycle of use of the KMC device. Like an exhaustive set of features. It will be very useful in writing the proposal.
Also is there some authentication @shbucher while connecting via bluetooth or any form of encryption? I mean if there are two doctors in a hospital both have some patients. So one doctor must not be able to simply connect to KMC device of patients of another doctor. Am I right? So is there some cipher?
I have built a small prototype using some stuff I was allowed to bring home.
I don’t have the PCB yet else I could have made the device more compact and wearable. Also, the UI of the receiving app is not made properly as I just wanted to create something working and see how things go!
PFA the link of the video:
https://drive.google.com/file/d/1pygLu4AodSviNQNZdAfZwFWkzv_-b45T/view?usp=drivesdk
Google drive does play some mischief with the video resolution. By setting resolution to max possible value, the video looks clear. I will still try to upload a clearer video.
In response to your query about authentication, @Hrishikesh-Bhagwat : Yes, there will need to be the ability to differentiate among the NeoWarm devices, within the NeoRoo app(s). And, privacy protection is a paramount concern, in the healthcare setting.
Parents who are using NeoWarm (the biomedical device) + NeoRoo (the app) should ONLY be able to see the information related to their particular baby (or babies, in the event of twins/triplets) – they should never, ever, be able to see, or to access, information related to the health status or history of other infants (patients).
Healthcare providers are a bit trickier – but not an insurmountable challenge. It might be necessary for multiple health providers on a shift to see information about each of the babies wearing the NeoWarm device, connected to the NeoRoo app. For example, there may be an attending physician, nurse-in-charge, and several neonatal nurses. For purposes of supervision, it might be necessary for the attending physician and nurse-in-charge to be able to track all of the babies, via the app. However, for each neonatal nurse, it might be necessary for him/her to only track the babies under his/her direct charge. This number, of neonatal patients under an individual nurse’s care, might vary widely.
We have successfully addressed issues like this (that is, users of the app who have varying levels of “permission” can/cannot access different types of information), in the past, in various ways. Those prior solutions might prove beneficial to this use case. Check out the GitHub/GitLab repositories for mobile Helping Babies Survive powered by DHIS2 (mHBS/DHIS@) Tracker and Trainer, and for the ECEB app.
@sunbiz might be able to offer more detailed and specific technical advice.
It should be configurable, or whenever there is a stable connection available. Please look at the dhis2 android SDK for how its done in the mHBS tracker - even if its an Android Java app.
The problem with these approaches (MQTT or websockets) is that you require a constant internet connection from the device. In most settings, where we want this to make an impact, we will likely have intermittent internet connectivity and that too from the mobile phone only. Thus, the app will get updates only when it’s in range and not continuously from any distance because of power constraints.
As I said, assume that there won’t be continuous power available.
Since, all the data will be updated on the same dhis2 instance from all apps, all the apps will be updated. Think of how rsync works across all the mobile apps. So, irrespective of which user (parent/caregiver) extracted the data from the device, it will be updated on all the apps.
Please review the materials that were provided and doing a Google search with “NeoWarm biomedical device” will explain the KMC and stand-alone modes.
Please look at the ECEB app for how it’s done there.
This is something you should propose. Most wearables use some sort of device ID and a pairing process to share keys. BLE 4.x uses TK and STK. AES-CCM is the most common approach. These are fairly common and widely deployed approaches that you should read-up on…
Hey @sunbiz , I would love to work on this project. I have experience in HTML and Javascript. I can learn Flutter within few days. I have experience in Android.
Thanks, @sunbiz@shbucher for your valuable time in answering all of our questions we are almost closer to understanding and designing the workflow of the project but unfortunately I won’t be participating this year because of some work-related issues but would love to contribute to the project .
It was nice interacting with you @Hrishikesh-Bhagwat and All the best to everyone who will be participating this summer for the project hope you all can stand out what mentors are accepting from you.
I have done a few work related to this project hope this can help
@adarsh-technocrat Thank you for the good discussions. Sorry to hear that you won’t participate in GSoC, but we are an open-source project, and you can contribute later when you will have more time at hand.
.