We’re looking to you, the community, to help us decide on the next major focus for the OHS project which spans FHIR SDK, FHIR Info Gateway and FHIR Analytics.
What features, improvements, or new directions would you like to see us prioritise? Whether it’s a feature you think is missing, an improvement you’d love to see, or an entirely new area you’d like us to explore — your feedback is invaluable.
To contribute you can reply to this topic thread with your ideas, no matter how big or small. Your feedback is crucial in making sure our project evolves in a way that truly serves the community.
Feel free to be as detailed as you’d like. The more information you provide, the better we can understand your needs. You can include links, examples, or any context that would help us understand your suggestion.
If you think of something that others have mentioned already, feel free to give it a like or comment on it — we’re all about collaboration here!
We’re excited to hear your thoughts and get your insights on how we can continue improving this project for everyone.
My belief is that performance should be the highest priority as will be the most important driver for OHS adoption especially as some of the OHS projects get further scale.
I think two really key areas of initial focus should be reducing query loads and also improving memory performance.
For query loads, right now things like register views may trigger thousands of subqueries to return the data needed for a live view. This is something Graeme from FHIR has recently flagged in a discussion I had with him.
My proposal would be to prioritize exploring the use of view definitions in OHS. Not only would this be helpful for analytics but we could potentially use this to help improve aspects of the apps where flattened views would be very helpful. To do this I would look at the needs of say a register view and see if the view defintions would work for this. One thing I am wondering if is we need to lookup several task status or observations if this would work or if we would need a new approach. So I think prioritizing looking into this would be great.
If we can figure out view definitions, I think we can also use these to help with the issue of data pruning. It would be great, for example, if we could create a view definition for a prior pregancy and then just use that in the UI to view that. We could then get rid of the associated 100’s of resources linked to prior pregnancy we keep around to allow us to view that data. Once the data becomes readonly I think we should consider syncing it to the server and pruning it and just storing what is needed in view definitions.
The second critical issue is just overall app / memory performance. Forms in some apps can take 10’s of seconds to load and process. We really need to understand what the bottle necks are here. My hope is the new kotlin libraries can help with that.