Thanks @r0bby. Will work on this.
@sunbiz There are no official starter tasks for this project. I had asked this on the chat in the past but would just like to confirm as not doing starter task implies sureshot elimination. I had received a reply that non-trivial contributions to the existing apps in flutter can be attached as starter tasks.
Work on issues that are substantive on our flutter-based projects. They need to be more than just changing strings.
1 Like
Hi i am looking into the project under GSOC and i wanted to contribute to the project as i have experience in Flutter development. Can you please guide me on how to proceed 
thanks
Is this necessary to complete to be able to take part in the NeoRoo project under gsoc ?
No. Can you not read the post by me above yours?
I will say one thing: If you can’t seem to read other posts in this topic, I don’t see you being successful.
i am sorry but when i joined the chat it was mentioned that these tasks were neccessary so i got a little confused.
Yes, but I answered the question both on our chat and here. I couldn’t have been clearer.
Happy to review any drafts that you can share, here or through the GSoC system (which as @r0bby mentioned might not be robust yet)
1 Like
on the chat, we are having a parallel discussion that I’d like to bring to everyone’s notice and might help in the design of this project.
The tracker program in DHIS2 is used for tracking registered entities. So if high frequency data is used it can lead to thousands of stages each day right?
These will not be stages, but rather in one stage - i.e., a NeoWarm/KMC stage for a preterm delivery (program) - there will be a data element for each sensor/vital measurement with daily frequency. In another data element, there will be continuous measurement for that day, likely as CSV, which will then be averaged stored to the daily frequency data element.
Alerts are important can be given realtime but for retrospective analysis data after every 10 seconds becomes almost irrelevant as such data does not change so frequently over time. So, alerts when a vital crosses the safety limit that event can be reported instantly to all users. But when readings are within normal range an average value over 15 minutes also can be reported.
agreed, and thus the daily frequency data element can be used for posthoc analysis or charting, but more regular-interval data will be used for alerting. This is commonly the process used in ICU for capturing different vitals, where you have the granular data, but also aggregated data or interpreted information.
2 Likes
You can submit as many versions as you like up until 2022-04-19T18:00:00Z. The new app leaves a bit to be desired but it is what it is. Just clarifying. We’re learning this new web app along side all of you.
1 Like
@sunbiz Oh… so one element for each field. Please correct me if I am not wrong. There will be a new stage for each day or daily averages will also be stored in comma separated values for each data element?
Also @sunbiz it was mentioned in the chat that the KMC device is the single source of truth. It was mentioned in the messages in the top that the mobile device uploads the data to sync it. Now, if multiple phones are syncing the data the CSV might get conflicting values if one mobile device disconnects from bluetooth for a moment then missing values can occur if that device uploads? Or if my mobile is syncing the data and my colleague too syncs the data then duplicate values can occur?
Also the wards of the baby can only view data right? And message the doctors via the communication channel. I have seen hospitals being reluctant to give access to anyone other than doctor’s and nurses to their information system.
1 Like
There is just one stage… with 4 data elements for each sensor (heart rate, temp, skin-to-skin time, and spO2), which will have comma-separated values from the sensor. There are 4 aggregate elements in the stage that capture the mean for that day.
The sync doesn’t override, it just syncs. There wont be any missing values or changes, only synced values. Because there is no manual edits possible for the values, there is likely no chance of data loss or update. We will have keys (per app and device-id) and hashes to ensure this.
This is what we’d like to do… this will likely be configurable and the apps and individuals will need to provide device-id to connect to and sync with the device. I envision this is similar to fitbit, Apple Watch or other wearables.
2 Likes
@sunbiz So while capturing data for the second day, the mean for the first day is removed? If its to be stored in a single stage with one data value per aggergate then that aggregate can also possibly be a CSV if we need it for retrospective analysis.
Oh so when a phone connects to the KMC device it receives all messages and sync remains consistent right?
No, its a daily frequency element. So the same data element will have daily values. No overriding. Please read the documentation here for clarity:
yes
2 Likes
@sunbiz I have been through some other apps like the ECEB as well. In this app will doctors have to manually add the baby like in ECEB? Or the baby’s preliminary data will be entered by the clerical staff? In many hospitals, the patient entity is being created at the time of registration. The doctor’s and nurses simply monitor and update vitals.
The doctor or parent can click on the registered child and add the KMC device with proper authentication like the Fitbit watch. It shows a pass code on its screen and it is to be entered in the mobile device.
We are currently searching ways by means of iot and other tech to compensate for the lack of manpower and so are obtaining information about such projects.
1 Like
Hi everyone! This project seems really interesting and meaningful to me, and I also have experience in HTML, Javascript, and Flutter, so I am applying. Thank you to all in the steering committee who are patiently replying to all the questions, I have read them all and found them to be really helpful - learned about new technologies such as BLE and rsync as well!
I read the application guidelines that were mentioned in another thread and I had a few questions. If any of you guys could kindly answer them, it would be great, thank you!
-
For the starter tasks, we create an issue of something we would like to substantially change/add and then create a public fork that we later share a link of in our proposal right?
-
I read that we are required to show wireframes of all user interfaces, but I was thinking of using the screens that are already in the ECEB codebase and further adding on to by adding screens with my proposed features. Hence, would it be alright if I showed wireframes for the screens that have the product features that I am proposing?
-
For now, do the sensors in the device only measure heart rate, temp, skin-to-skin time, and spO2?
-
I know this has been explained quite a bit, and I apologize for asking again but I am slightly confused about the storing of data. Please correct me if I am wrong - the device uses its sensors to sense vitals and sends it over to the mobile app used by the parents using BLE. The data in the app used by the parents will be sent over to the health care workers’ app using a DHIS2 instance. And since all the data will be updated on the same dhis2 instance from all apps, all the apps will be updated. I understand till here, but I am slightly confused on the syncing/ CSV part. How does the data syncing work? I know my question’s a bit vague but if someone could provide some additional explanation about how the the data transfer works from the parents app to the health care workers’ app, it would be great!
Thank you so so much for taking the time to read this!
Ideally, this will be an MR for an already created issue. If not, then create an issue that requires substantive codebase changes and submit the MR for that. Participate in the updates from the MR review and iterate through it. We want you to be a FOSS participant.
Sure, I think that’s a great idea. Using the same design language as ECEB would help it be part of the suite. However, if you have better ideas, feel free to add it to your mockups/wireframes.
That is enough for now…
No, any user who has a phone device nearby - parents or providers will get the data and sync it with the DHIS2 instance. It doesn’t have to be parents or health workers. The data sync works because that infrastructure is already available in the DHIS2 SDK or you can rewrite that in flutter. But it is quite straightforward. The DHIS2 data element value (comma-separated list of high-frequency values - say 10 seconds for heart rate sensor) will be received from the NeoWarm device and sent over to DHIS2. All mobile apps connected to this baby will get the updated value from DHIS2.