The plan is to have these some of these ideas released by October 2018, any which are not ready could be worked on in the hackathon
@ssmusoke okie then thanks
@dkayiwa The condition list tickets have been added here and are ready for work:
Thank you all for the input and feedback, in summary this is the list from the feedback:
- Big Features:
- Login, landing page, patient dashboard and visit pages refactored into react UI with a REST backend
- Condition List
- OWA standards: declaration of dependencies, UI foundation, basic widgets and development guide
- Review of module implementation - speed startup, do we need all modules (consolidation of modules), deprecation of others
- Integration of OCL into OpenMRS
- Order Entry UI
- Small features:
- Change Reference Application documentation to focus on patient flows rather than list of features which has been copied over from previous versions
- Additional patient dashboard widgets and custom REST end-points to speed them up
- REST API to HTML Form Entry
- Completion of OWAs: Cohort Builder, Obs Data etc
Please do add onto this list to help nail down the requirements for the next release
@ddesimone that is awesome!
It would be great to get one or more react gurus to help build this using best practices!
There is a course here that is $9.99 for the next 2 days - https://www.udemy.com/react-redux/?siteID=EXclnL5BfX4-_FzFoYS_wM36q0b6iqj_ug&LSNPUBID=EXclnL5BfX4
I am signing up - so would be great if we can have a group course unit
A whole new forms technology now counts as a “small feature”?
I know that you’ve been looking at the AMPATH forms, and whether that can be incorporated into the refapp. That may turn out to be totally viable, but I do think you should also consider Bahmni’s Forms 2.0 technology. In particular it was specifically designed and built as a standalone react library that could be incorporated in multiple UIs. In fact Bahmni itself includes this into its Angular 1.x UI. And PIH has experimented with it as well, showing a successful proof of concept.
(Based on my very limited knowledge I assume that the AMPATH forms supports a lot more widgets due to having much longer-term usage in a rich clinical environment, but that it’s more tied into AMPATH’s POC app, and not necessarily as straightforward to integrate elsewhere.)
There was a GSOC project to add REST backend to HTML Form Entry, was actually thinking of getting this integrated and see what opportunities it unlocks.
Oh yes we are looking at AMPATH forms for UgandaEMR, but my other hat (Ref App Lead) hopes to find an opportunity to test run Bahmni forms for RefApp - the only way to know what works is to actually use both and see where we end up
To add to that, I know this isn’t going to be popular, but we are actually moving forward with building a simple form entry technology in openmrs-contrib-reactcomponents right now, but if AMPATH forms or Bahmni Forms 2.0 becomes the default Ref App form technology we’d definitely consider using that. As @darius said, we did a proof of concept with using Bahmni forms and it was generally successful. Our main concern with it at this point was our ability to modify it and move forward with it quickly.
Take care, Mark
@mogoodrich so the openmrs-react-components extend react-boostrap components? Do they use the basic REST interface (Visit, Encounter, Obs) or the HTML Form Entry REST backend?
Yes, they use bootstrap form components/widgets behind the scenes, though if we needed a widget that bootstrap didn’t provide we would certainly consider incorporating other widgets. It also used redux, redux-form, and redux-saga.
It uses the standard REST interface and is not related to the HTML Form Entry REST backend.
Thinking about it, maybe me calling it a “form entry technology” was too heavyweight… right now the general vision is to create something generally lightweight that provides React Components that make it easier to create forms for OpenMRS using Redux Form. The significance here is that it doesn’t provide a way to extract out a schema, etc.
You can see an example usage here):
Right now all it can do is create widgets to enter data for numeric and coded obs… though we will be needing to add edit functionality in the near future.
Take care, Mark
Oh I see. I would probably call this “REST API to HTML Form Entry” (because HFE doesn’t inherently have any stronger Point of Care support than the core REST API does).
In the big picture, the release is intended to happen in October, so this basically means 1 month of dev time for all this (and 1 month of release process), so…let’s get to it!
And while I’m at it “Order Entry UI” is a small feature too? I think we have different definitions of small!
Exactly - any chance u have some devs who may be on the beach somewhere
Re-aligned our understanding of small - moved to large features
We just completed the improvements of Built-In reports module and released the version 1.0.0 of the module.
So I would like to include the Built-In reports module to the Reference Application 2.9 release as it reached the version 1.0.0 release now. During the RefApp 2.7 and 2.8 releases, there was an empty built-In reports icon in the homepage dashboard, but it failed to load the Built-In reports since it was not released along with the Ref App distributions yet. So I would like to include the Built-In reports OWA into the Ref App 2.9 release and link this OWA with the Built-In report Icon in the Home Page dashboard.
Thanks for the info. I’ll make sure it gets added to the release
Oh yes indeed excellent - we had hoped for this to happen for Ref App 2.7 so now is the time, thanks for following up
@ssmusoke, thanks for pinging us by email. We are very busy and underinvested in the Ref App right now, so we can’t contribute that much, but here are two ideas:
- Make Attachments 2.x be part of the Ref App.
Just wondering, is it only about making Attachments 2.1.0-SNAPSHOT being part of Ref App distro 2.9.0-SNAPSHOT?
- Enforce Ref App ⇔ Bahmni integrations.
Yes, let’s try to have Bahmni Forms 2.0 work in both distros!