Core and modules to be able to advertise capabilities that can be configured and manipulated
This thread is to call upon everyone to share their thoughts, needs and suggestions over the next 2 weeks, to help drive the prioritization and planning.
Thanks @ssmusoke for setting us up for the discussion.
I feel it would be good to consider releasing Platform 2.2.0 before RA 2.7.0 and basing RA 2.7.0 on a newer version of Platform with faster patient search and improved caching. Setting up a few automated performance tests would be part of the work.
We are also targeting to start using Open Concept Lab for managing concepts in RA 2.7.0, giving implementations an easy way to upgrade to the full CIEL and use custom concepts.
Iāll be working on further improvements to writing custom widgets for patient dashboards.
It would be good to move RA configuration from different modules to one place following the config files pattern introduced in Bahmni to simplify customizing RA.
Lastly prebuilt reports for the Reference Application will be done as part of GSoC 2017.
Here are features weāre planning to deliver by the end of September:
Planned for OpenMRS Community
Updated Patient Flags module that exposes flags in the clinician facing dashboard
Production quality integration with OpenEMPI using HL7 v3 PIX/PDQ messaging standards
Haiti Specific
(Iām not sure if this could be done in the community) Fingerprint integration with the local M2Sys platform that allows patients to search by fingerprint, register new fingerprints in the registration app and click a button in the clinician facing dashboard to collect fingerprints.
Weāre in the design phase of building a local queue that integrates with OpenHIM for a number of OpenHIE patient registration workflows. Iām not sure how specific this will be to Haiti, but expect that we will be working on the events module and add HL7 templates at a minimum.
+1. One thing Iād like us to at least look at is the initializer module that @mksrom and @mksd have highlighted a few times recently. I havenāt looked closely, but it would be interesting to see if this could be pulled into the referenceapplication to meet some of these needs.
This is something that we need to do also for our implementation in Haiti, and hope to collaboration with @craigappl and team on this.
A few other things to mention:
Hopefully we can release the new cohort builder OWA and remove the reportingcompatibility omod from the refapp
The PIH team (@mogoodrich and @ddesimone can comment more) are currently building more comprehensive program support in (program dashboards, program enrollment and display widgets, etc)
The PIH team (@cioan and @ddesimone can comment more) have been working on adding more comprehensive relationship support and more tools around provider management (eg. apps for managing and viewing a CHW workforce)
Hi @ssmusoke, thanks for leading this effort and pinging us about this thread.
Thanks @mseaton for promoting the Initializer module.
Yes to the question āwhat would you have loved to have as an implementorā I would definitely say: the Initializer module.
However so far we have been going solo on it so, should there be a community desire to get it into the Ref App, well people should look at it as soon as possible because right now its initial design can still be easily influenced. We are right in the middle of developing it and would like to release 1.0 somewhere in early July.
My former number one would be: Visit Documents UI.
I have updated wiki page of release dates as it was bit outdated. Reference Application 2.7.0 dates arenāt confirmed yet. Once they are finalized, please update the dates there.
In two weeks, we are scheduled to be ready to integrate the following features that could be added to RA 2.7:
Registration Core
Real-time PIX/PDQ integration with an MPI during registration process using HL7 v2 messages. (We are still working on the process to update patient information in the MPI when demographic information is saved.)
M2Sys fingerprint reader integration
Registration App
Realtime PIX/PDQ integration with an MPI, exposing these in the registration screen
M2Sys fingerprint reader integration as a fragment in the registration page, registration summary and patient search.
Patient Flags - Updated module
Patient Flags UI - New module that exposes the flags as a fragment on the clinician facing dashboard.
What is the process for reviewing these features and ensuring they would be appropriate to add to this release? Also, does anyone recommend a timeline for this to happen?
@ssmusoke, a long while ago we developed an extended patient header that allowed to edit all of the registration data. Not just the patient name and address but also everything else that was provided through the registration app either as person attributes or obs.
It seems that this feature is still not part of the latest versions of Core Apps, am I correct?
Would you be interested for us to finally merge this in, or it was intentionally kept that way?
And if it was intentionally kept that way, what is the recommended way to edit those custom fields that are part of the registration form?
But so just to know, if custom person attributes are captured during registration, how are those meant to be edited in the current form of the Ref App?
What I mean is that if a user saves a custom registration app configuration that adds custom sections, say via the UI, then the links are nowhere to be found within the app to those āedit sectionā fragments.
What we did back then is ensure that the app config is scanned and that all possible edit sections are made available through the patient header. I hope you know what I mean here?
@mksd I am thinking, if the edit extensions are not defined in the app, can the fragment use the default replacing the app name? It can be documented behavior
There is another issue, what about addresses that follow a custom address template (and possibly leverage the Address Hierarchy module)?
What Iām trying to say here is that we had solved all this with a patient header that would make sure that you can obtain all edit sections dynamically following the registration app config. What sort of shocked us at first with the Ref App is that the user would feel locked out. There would be no simple way to edit things that where just provided.
Looking back at my code it is possible that most of the changes should in fact go to the Registration App module, but that doesnāt change the initial question: is there an interest for this?
Ah! I found a screenshot that I had showed up back then, here.
