Reference Application 2.7 Planning, Ideas, Features and Road Map

[ssmusoke (Stephen Senkomago Musoke)]

Continuing the discussion from Reference Application 2.6.0 Is Released.:

Now that Ref App 2.6 is out, it is time to shift gears to 2.7 which will be released in October 2017.

1. As an implementor what do you want to see in this release - what are your top 5 asks?

2. As a developer who is customizing and extending Ref App - what advances do you want to see?

3. As a user, hospital, health facility, doctor - what do you want to see in the next release?

The approach for 2.7 will follow similar methodology as 2.6 to help focus the value proposition [Discussion] Reference Application 2.6 Roadmap for April 28, 2017 Release :

1. 2.7 will have 4 big features and 5 small features

2. Due to the available time until October 2017, there can be 2 cycles of development each delivering parts of the target features for 2.7

3. Carry over features from 2.6 can be found here https://wiki.openmrs.org/display/docs/Technical+Road+Map

   • Prebuilt reports for the Reference Application
   • Sticky Note on the Patient dashboard
   • Ability to edit implementation forms
   • Responsiveness to the clinician facing dashboard
   • 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.

[raff (Rafal Korytkowski)]

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.

[burke (Burke Mamlin)]

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.

+1

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.

+1. This would be a good target for 2.7

Regarding getting more input from implementers…

Have you directly pinged people from Partners in Health, iTech Haiti, Uganda, Mekom Solutions, and Banda Health for their input on this?

[craigappl]

Hi Everyone,

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.
• iSanté indicator interface integration in the clinic
• HealthQual Report

Other

• 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.

[mseaton (Mike Seaton)]

To add my +1 to a few thoughts expressed above:

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.

+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.

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.

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)

Mike

[mksd (Dimitri R)]

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.

My take on Ref App 2.7:

• Initializer
• VDUI

[judeniroshan]

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.

https://wiki.openmrs.org/display/docs/Release+Process+Timeline

[craigappl]

Hi Everyone,

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?

Thanks, Craig

[mseaton (Mike Seaton)]

Hi @craigappl,

Great to hear of this progress! At minimum, I think we need -

• Tickets raised in each of the respective modules to describe the new feature that is planned
• Pull requests issued, and status updates made within the ticket

This will then initiate those who are interested and/or responsible for reviewing these features to start that process.

@ssmusoke - any comments on your end?

Looking forward to seeing these improvements, Mike

[ssmusoke (Stephen Senkomago Musoke)]

@mseaton @craigappl I do not have any objections - opening up to anyone else who sees and can advise differently …

[dkayiwa (Daniel Kayiwa)]

@mseaton’s proposal looks like the perfect way forward!

[mksd (Dimitri R)]

@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?

[ssmusoke (Stephen Senkomago Musoke)]

@mksd I would suggest starting a new thread, showing how it works and putting a PR in there for review

[mksd (Dimitri R)]

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?

[ssmusoke (Stephen Senkomago Musoke)]

@mksd I have personally been using the editSection fragment to do so

[mksd (Dimitri R)]

Yes sure but there is not link to it anywhere is it? I’m talking from the perspective of the end user here.

[mksd (Dimitri R)]

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?

[ssmusoke (Stephen Senkomago Musoke)]

@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

[mksd (Dimitri R)]

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.