Reference Application 2.7 Planning, Ideas, Features and Road Map

Software Reference App
21

@mksd How about adding a global property that turns on the new functionality that way the app works the same way for existing users and new ones can turn it on

22

I’m trying to get a sense as to what was the original design idea. Was it to prevent users to edit the registration data (except name and address, and yet to certain extent)?

In Bahmni for example, you have registration form that you can go back to should you want to edit items. Why is the Ref App taking the current counter-intuitive stance? I would say that if there is no good reason, then there should be a simple way for users to go back to the registration form and edit its data. And that shouldn’t be optional through a GP, IMHO.

@darius, @mogoodrich, @dkayiwa, opinions?

23

@mksd To expend the idea further I think it should be possible to edit a patient profile with all metadata - names, identifiers, and attributes - I think this is what the patient management OWA is meant to be doing


24

@ssmusoke and @mksd - not sure I understand, but it was never our intention to prevent editing of registration data once it was saved, so let’s clear that up :slight_smile: I’m having a bit of a hard time visualizing how you would support editing everything from the patient header. This is the intention behind the registration summary page that is provided as a part of the registrationapp module at openmrs/registrationapp/registrationSummary.page - to summarize all data captured during registration and provide means for editing and otherwise managing that data as appropriate.

@mogoodrich can clarify further as to what one needs to configure in their app config in order to configure this registration summary to contain all of the corresponding sections from the registration process. I would certainly advocate for the default to be for this to include everything configured to be captured during registration, which could be overridden by specific configuration, if this is not already in place. In our PIH setups, we have a “General Action” that allows navigating into the registration summary.

Is this what you are looking for? Mike

25

Thanks @mseaton, yes I just gave it a quick try on qa-refapp (as the demo seems to be down?) and yes that is what I was looking for. I would wish for no specific configuration though. This registration summary page should just be able to recall all registration sections. In the same way as the registration form is able to display itself based on the registration app config. In other words: both the registration form and the registration summary page should be driven by the registration config.

In short I would wish for the default behaviour to be:

  1. There should be a link to that page that is obvious to find.
  • That page should display all configured sections by default.
26

Mike and I were just talking about this, and +1 to what @mksd is saying above: the registration app config should be able to drive both a “enter” and “edit” flow, instead of having to separately configure a edit flow.

I think this should happen from within the registration summary flow, with having it able to happen within the patient header is a nice-to-have
 though maybe it rises higher up the priority list since it’s already been built.

(That been said, we already have a fairly complex edit configuration, so, just in case the first pass of a new edit flow driving by the registration app config doesn’t handle all of our use cases, we should make sure that turning on this new functionality is optional
 :slight_smile: )

Take care, Mark

27

Actually, to clarify turning on the new functionality should be optional, but the default for out-of-the-box should be “on”. :slight_smile:

28

Thanks Mark.

I just looked quickly in the following modules: Reference Application, Registration App and Core Apps and I didn’t find any edit configuration JSON for the Ref App distro. What is driving the current behaviour that can be observed on qa-refapp when typing in the URL that Mike indicated above?

Also could you point me to a working config from one of your distros?

29

I’m not sure where the edit configuration for the Reference App is set up
 maybe @ssmusoke knows?

For our PIH EMR distro configuration, most of it can be found here:

and our registration app config can be found here:

Note that we programmatically set up our Apps and Extensions, which has been convenient for us, but a downside in cases like this it’s hard to point others to clear example of our configuration–you kind of have to dig into our utilities methods to understand exactly what is going on. The particular part that sets up patient registration and the summary questions can be found here:

Take a look, and let me know what questions you have. One interesting thing we did–though I don’t know if I’d call it innovative or hacky :slight_smile: – is that for the observations we collect as part of the registration process (which are quite a few), we render them on the registration summary section using various instances of the coreapps “mostRecentEncounter” widget, and edit them using custom HFE forms
 this is how we worked around the fact that the registration app did not provide edit functionality.

Take care, Mark

30

@mksd I am following up on this thread - the editing of the complete registration is not available without specifying the section. I do not know where to edit the registration information in a single page

31

So clearly the Ref App should offer a link to that page out of the box. I will have to work on that for one of our distros, so hopefully I’ll be able to cover that case for the Ref App. I’ll create an RA issue for that.

But how do you do in UgandaEMR to edit registration information then?

32

@mksd Most of our information is in the ContactInfo section so editing that section does it for us.

33

@craigappl Following up on the status of work on the patient flags (still has some issues) and the MPI enhancements to Registration App and Registration Core

@mksd Can you share the JIRA ticket for the editing of registration information so that I can rally support to get it worked on ASAP

34

@ssmusoke, here:
RA-1425 - ‘Registration summary page to loop on all defined registration sections and display their summary section widgets’.

Cc @mogoodrich

35

@mksd My understanding was that the issue is that there is no link to enable the editing of all the registration information in one place as it can only be edited one section at a time.

I think the display outside the sections is tricky since if all sections are shown then there is a need to have the ability to hide selected sections

36

Can you elaborate? I didn’t understand what you meant here:

37

@mksd What I meant is that when you display all the sections in the Registration Summary you also need to provide a means of hiding some of the sections like ContactInfo - which is in the header, and any which the use case may not need to be always shown.

38

I don’t think so. When we did this exact exercise with the widget that summarises the registration info in the patient header, we just ensured that all sections, minus ‘contact info’ and ‘demographics’, were dynamically added. I basically wish for the exact same thing here.

All in all, this registration summary page should just keep displaying as it always did when no other sections have been defined in the registration app’s JSON config.

All the above implies (as it is hardcoded in various GSP files) that both the ‘contact info’ and ‘demographics’ sections are in fact mandatory (they can’t be stripped out).

39

@mksd I am thinking ahead for other implementations which may collect some data for either patient triage or another reason, and once collected is not needed going forward. So there needs to be the ability to eliminate some sections when displaying on the Summary page.

Which is why I am confused on the ticket, which does not talk about editing all the registration information in a single place instead of section by section, which is what I thought was the issue, not displaying the registration data.

40

So you seem to suggest that the fact that there isn’t an edit version of the registration form is in fact wanted by design? To ensure that some information won’t be edited afterwards?

That feels a bit weird to me. Should the registration form not be used to collect patient attributes. Such as: names, addresses, next of kin, (person) attributes, identifiers, contact info
 etc.

I remember our surprise at first that there was no obvious way to edit those pieces of information (except for the two default sections).

But anyway to cover the cases of concern that you describe, the section data model could be extended - say with a type or a flag - that would direct the registration summary page in knowing whether the section summary widget should be displayed or not.

I quote what was said above by Mark:

This is what RA-1425 says: follow the registration app’s config and give access to an “edit” flow too for sections for which an “enter” flow is defined (except for the two default sections that are already hardcoded).