CoVital Platform: Thoughts on Phase 2

[haggy]

I wanted to start a discussion around what phase 2 for the backend might look like. It's always preferable for the backend to be slightly ahead of the curve if possible. I think now is the perfect time since the data team is wrapping up testing on the initial data collection app.

At a high level, these are the items I could foresee us needing relatively soon:

• API Authentication (@imonthercks looking into this using Auth0)
  • This is going to be especially prevalent when the user/patient facing app is released
• Service metrics and monitoring
  • Right now we have very little metrics and no monitoring
  • Doctors will be entering data around the clock so we need monitoring to ensure services remain available and to let us know when they are not
• Structured data access outside of S3/ML jobs
  • Being able to search and aggregate structured data directly in something like Postgres or MySQL
  • This will be important for things like "Business" Intelligence and general data analysis & discovery
  • Athena is an option but it can get expensive quickly so we need to keep that in mind
• Notification pipeline
  • This is primarily for user facing apps. There will most likely be times where we want to analyze data on the backend and "alert" the user to things as we discover them
• Unified Logging
  • We have no unified logging as of now. I put this last as I think it's something we can go without until more critical things such as monitoring and auth are implemented.

Would love to hear other people's thoughts on what we might need in the coming months!

[palfaiate]

This is one of the first Relational Schema proposed...

[haggy]

@palfaiate thanks for throwing that together. Based off what we currently know that looks like it could work but we'll have to wait for real data to start flowing in before we make any decisions. I have a feeling that once data starts flowing in there will be multiple revisions to what metadata we are collecting (which would affect the DB schema).

[cmontemuino]

@palfaiate I have a couple of comments on the proposed schema.

• Gender: I would consider something wider than binary (but I'm not sure how many options)
• latitude/longitude: have you considered using Double instead? For example, " Scaled Degrees north" / "Scaled Degrees west", or not scaled at all (i.e., [-90..90]/[-180..180]). My rationale is to make it easy the compute later (e.g., find nearest)

[haggy]

@cmontemuino Yea those are good thoughts and the primary reason why I think we'll have more luck tackling a schema after we have a decent starting dataset. We might see that gender has many options or we might see that 2 + "Other" is fine. I would also want the data team to weigh in on your question about scaling values vs. raw but in my experience we would definitely want to keep the raw values around somewhere so that we could recompute them on the fly.

[palfaiate]

Gender (enum think it would be enough)(Male, Female, Other) Weight on the readings table is useful BPM on the readings table is useful Any other value that should be included in readings is useful as well Height on user's table is useful SkinColor on user's is useful