I was actually asking about the time the mentors might need to review the draft proposal and in this org are we allowed to submit a draft for evaluation? @r0bby
Alright, thank you. i will consider that
I believe so. The webapp is new so I can’t say for certain but I suspect it is possible. As far as the time, we review them as they come in.
Work on your starter tasks.
@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