Stream: who-smart-guidelines
Topic: community-process
Fred Hersch (Jan 21 2022 at 08:25):
@Carl Leitner @Christopher Haskew Sharing some thoughts on process
Following up from the last call .. Should we try and set up specific topics or threads for each of the priority areas we need to work on for emCare? Ideally each one has an owner and an associated doc where we can delve into requirements and try and discuss asynchronously. Then we can use the Tuesday calls to surface issues or identify the need for deeper dives. Some of the "big" topics that I think are relevant are:
Specific to emCare priorities shared on Tuesday:
Data sync and conflict handling
- IG Deployment and design for the SDK (filtering based on role?)
- Client DB duplicates management
- FHIR Analytics (lower priority)
- General priority areas for the SDK
Workflow/Task Management
- CQL Evaluation
- Auth needs (for implementing more granular access controls)
- Sync patterns
- Security (as raised by Carl)
cc: @Matt Berg @Kunjan Patel
Carl Leitner (Jan 21 2022 at 13:26):
yes. and I think that this document is not specific to emCare but for any "SMART Guidelines" app. I have been trying to draft out some architectural assumptions on this here:
https://docs.google.com/presentation/d/1tklkYEJAeSqvpOx8txEgEmeWRbiBm5QaQYh_qMtE7tQ/edit#slide=id.g10aa2e78e3f_0_97
but it is still a work in progress.
Matt Berg (Jan 25 2022 at 02:57):
@Carl Leitner thanks for sharing this. Could we setup a time to go through this when you have some time. I think @Fred Hersch and others would be interested too
Matt Berg (Jan 26 2022 at 20:09):
Hi @Fred Hersch sorry I missed your message as part of this thread earlier. Those all sound good. I think in general what would be really helpful is a more detailed overview of the requirements for emCare. We can also work to better share the different requirements we are working towards. The document shared so far relating to this is this which is similar to the list of items you've shared. https://worldhealthorg-my.sharepoint.com/:x:/g/personal/haskewc_who_int/EfD5cfUdJmdNlk-nXw8tRCwBvAsXlXD3Qck3YPF-cPtqAA?e=DYXygF
Matt Berg (Jan 26 2022 at 20:11):
I think these high level things are good. There are a lot of other functionality though that I think would probably need to be in a system (ones we are thinking about). It would be great to know if there is overlap and if so is there a way to potentially we can as a community divide up some of the work.
Matt Berg (Jan 26 2022 at 20:11):
Some of the questions include:
Matt Berg (Jan 26 2022 at 20:11):
- Need for P2P
Matt Berg (Jan 26 2022 at 20:13):
- Web interface for viewing and managing patient data
- web interface for data entry via questionnaires and web based data extraction
- Scheduling
Matt Berg (Jan 26 2022 at 20:14):
Those are a few examples. Others are more on the implementation side like authentication strategies, strategies for sync, etc. I think this is what we're trying to discuss more.
Matt Berg (Jan 26 2022 at 20:16):
Third are just a lot of the pragmatic issues. Things we are encountering like:
- data extraction performance
- data validation performance in SDC
- $evaluate and $apply early implementation issues that need to be tested and worked on
Matt Berg (Jan 26 2022 at 20:29):
It's this last item in particular that I'd love to eventually see getting more people in the community testing, providing feedback and helping to improve. We're starting to see that with SDC on the SDK which is exciting. So that's something that will come I'm sure with broader adoption.
Matt Berg (Jan 26 2022 at 20:30):
It would be great if we can start to use this channel more active discussion on specific items on the above.
Matt Berg (Jan 26 2022 at 20:41):
The better we have understanding of people's needed timelines too it would really help. In an ideal world, I'd love to be able to see different groups being able to pick up different functionalities they can then contribute back.
Matt Berg (Feb 14 2022 at 15:19):
hi @Carl Leitner @Christopher Haskew wanted to bring up an issue that we discussed on our call with Google today. There are some general risks around the SDK in terms of performance that I think we should be looking at as a community. Namely CQL evaluations can be quite slow (especially on lower end devices). Similarly things like data extraction can be very slow. This relates to optimizations that are needed in the HAPI library. @Jing Tang can provide more details. We'll try and provide more details but generally we see data extractions taking several seconds on a modern device. However, on an older 1G 1.3GHZ android device it was taking over 10 minutes. So there may be some memory based limitations with our current SDK architecture. I'm flagging this because I think these are issues that may need to take time to resolve and it may take coordination involvement outside of what Google alone can do. Since we've been trying to build out a lot of app functionality on top of the SDK we might be hitting these issues earlier than others. This would be a great topic to discuss when / if we get a governance call setup. Basically - I think we'll need to ensure CQL library performance for Android is prioritized in addition to HAPI optimizations (both libraries were written for servers so this is not to knock them).
Matt Berg (Feb 14 2022 at 15:20):
I think require a bigger effort so don't want people to be surprised later
Matt Berg (Feb 14 2022 at 15:21):
even on faster devices the experience isn't optimal
Matt Berg (Feb 14 2022 at 15:38):
Let me know thoughts on best way to discuss. It would be great if we can collaborate and coordinate to figure out best way to first better understand this issue and then tackle it
Matt Berg (Feb 14 2022 at 16:36):
Speaking to Vitor some of these issues may also be related to needing to preloading libraries so will try and provide more clarity if there is guidance when implementing we can provide. I think regardless I think there will need to be some continued investment in some of the libraries the SDK is dependent on.
Christopher Haskew (Apr 12 2022 at 14:18):
Matt Berg said:
hi Carl Leitner Christopher Haskew wanted to bring up an issue that we discussed on our call with Google today. There are some general risks around the SDK in terms of performance that I think we should be looking at as a community. Namely CQL evaluations can be quite slow (especially on lower end devices). Similarly things like data extraction can be very slow. This relates to optimizations that are needed in the HAPI library. Jing Tang can provide more details. We'll try and provide more details but generally we see data extractions taking several seconds on a modern device. However, on an older 1G 1.3GHZ android device it was taking over 10 minutes. So there may be some memory based limitations with our current SDK architecture. I'm flagging this because I think these are issues that may need to take time to resolve and it may take coordination involvement outside of what Google alone can do. Since we've been trying to build out a lot of app functionality on top of the SDK we might be hitting these issues earlier than others. This would be a great topic to discuss when / if we get a governance call setup. Basically - I think we'll need to ensure CQL library performance for Android is prioritized in addition to HAPI optimizations (both libraries were written for servers so this is not to knock them).
Hi @Matt Berg sorry for the late reply... @Carl Leitner and I chatted to Vitor about the CQL work last night. From what I understand - yes we're aware that the compiled CQL files are +++ in size and we need to find ways to optimise sync to mobile. Vitor is continuing to work on that.
Once on the device, Im not aware of issues re: time to evaluate the compiled CQL though. @Vitor Pamplona have you tested this yet? Are both issues linked?
Christopher Haskew (Apr 12 2022 at 14:19):
Tagging also @Kunjan Patel and @Patrick Delcroix
Last updated: Apr 12 2022 at 19:14 UTC
