Defining UX differences between the Xforms and Registration App Modules for patient registration

Development
1

Hi Everyone,

I have a spike to define the differences between registering patients using the xforms module and the registration app. We’re trying to identify the best path forward for the implementation of iSantePlus in Haiti. Can you confirm that these statements are correct?

End User Functionality: There are core differences between the end user functionality of each module.

Registering Patients

  • The Xforms module redirects to the Xform when you click the button to register a patient, then redirects to the clinician facing dashboard once the form has been submitted. The xform page is a standard UI page.
  • The Registration app module redirects to a Simple UI form that’s displayed one field at a time. Once the form is complete, it redirects to the clinician facing dashboard. It’s also possible to build off the work of PIH and redirect to a registration summary dashboard.
  • Both modules allow you to store registration information as encounters and observations as well as person attributes. Additionally, they allow you to collect multiple identifiers
  • The Registration App performs a live search for duplicate patients when you type in the patient name. I don’t think this feature is available in the xforms module (@dkayiwa, please correct me if this isn’t true). Subsequently, it appears that there has been a spike to integrate this list with a Master Patient Index, allowing users to search both the local database and the Master Patient Index for duplicates during the registration process.
  • The Xforms module searches for duplicates after the form is submitted and presents an error if the registered patient appears to be a duplicate.

Editing Patients

  • Both modules allow you to edit patient registration information by clicking an area in the Patient Header of the Clinician Facing Dashboard
  • The Xforms module redirects to the full xform, populating the information that has already been entered.
  • The Registration App redirects you to the SimpleUI for a specific section. So, if you click the “Edit” hyperlink next to the patient’s name, you will be redirected to the demographics section of the registration form. Right now, there isn’t a clear way to edit all patient demographic information on a single screen with the registration app. If you have additional sections to add during the registration process, you need to create a link to edit those sections somewhere on the clinician facing dashboard (this is also a good reason to follow the PIH registration summary dashboard).

Configuration: Xforms: You have to create the xform in the form designer and Set the global property “xforms.usePatientXform” = true causing a redirect during patient registration and edit.

Registration App: Create an app.json to configure the registration app and make sure the redirectURLs point to the right place. You also have to override the edit button in the clinicianfacing dashboard to the sections point to the appropriate section in your registration app.

Craig

FYI @dkayiwa, @ball, @mogoodrich, @jamesfeshner, @arbaughj, @ssmusoke, @jmaxy

2

Going forwards, the recommended path is to use the Registration App!

3

Don’t forget about the Address Hierarchy capabilities in the Ref App Registration Module.

You should consider the user base of each registration method. I don’t know of any implementations in Haiti (or the world for that matter) that are using xForms currently.

I think your research is good.

4

@craigappl, thanks for this discussion. As far as iSantePlus, it would be awesome if we could end up in a place where it was aligned with the registration functionality that is in place already at PIH-supported facilities in Haiti. There is a lot of overlap here, as my guess is that much of the necessary demographic information is driven from ministry surveillance and reporting requirements that any Haiti distribution will want to meet (i.e. if iSante needs to change something, chances are that the PIH distribution will want to change it to). Harmonizing on not only the code, but also the data model (what is stored as attributes, what is stored as obs, etc) will make any future integration and collaboration far easier. Additionally, we can focus our energies towards integrating with an MPI and with a Fingerprinting solution in the same code base, rather than duplicate this effort.

At PIH, we would certainly be willing to move to a different registration approach if we could achieve the same functional requirements and a comparable or better user experience. That being said, my sense is that the easiest path forward, and the one that will allow us the best opportunities for collaboration, will be to work within the existing registration app, and to adapt it so that it meets both the iSante and PIH use cases. For example, I think many implementations would be interested in an alternative to the one-question-per-screen approach, where a single-page registration form was able to be used for creating/editing registration information. We would certainly be open to this.

Would be great to discuss further and to understand better how we can move forward together.

Best, Mike

5

Thanks Mike,

This kicked off a discussion about modeling our registration process after the PIH approach, while trying to retain a similar look and feel to the legacy iSanté. Here’s a screenshot of the registration form:

I’ll write back with an update soon.

Craig

6

Hi Again,

We have agreed to move forward with the registration app, including modeling the data after the PIH Haiti implementation. As I said earlier, this is a push to keep a similar look and field to the data entry screens in iSante as we transition to OpenMRS. The team is concerned about shifting user behaviors on data entry screens and has asked that we try to display the “edit demographic” information in a single form view instead of using the registration summary technique.

We would like to see what steps it would take to have a form-like user interface for the registration process. I dug around the module on Friday and it looks like there are two problems to solve:

  1. Register Patients: Add a StandardFormUI to the register patients process.
  • Is it as easy as modifying some CSS? Theoretically, we could switch the navigation bar on the left to section headers and questions. Is this a good idea for long term sustainability?
  • HTMLFormEntryUI does this with two pages (EnterFormwithStandardUI and EnterFormWithSimpleUI) Should we follow this model?
  1. Edit Patients: Add a page that displays all fields in a single form that can be edited.
  • Right now, the SimpleFormUI focuses on editing one section at a time. We could add a page that displays all sections in a single screen (similar to the registration screen). It would have to default to get the latest encounter of encounterType for all sections that utilize encounters.
  • On another thought, could we use an HTMLForm to view and edit patient demographics?

Thanks, Craig

7

Craig–

It would be valuable to have a “standard” view of the register patient and edit patients views. For the “register” case, It’s not quite as simple as modifying some CSS, but it shouldn’t be too difficult. Ideally, we’d have a single page that could render in either view depending on a passed in configuration. But if doing so would make that single page too complex and full of branching logic, two separate pages, as we did in htmlformentryui, would be preferred. I don’t remember exactly why we took the approach we did in htmlformnentryui, but it may have just been for expediency.

I did a little testing, and to switch the “registerPatient” into a standard UI (albeit with horrible formatting) you really need to only do two things:

If you do these two things, you’ll get a working single-screen app, but with layout that leaves more than a little to be desired. It’s possible you could clean this up simply by defining a new “standard-form-ui” style that lays out the elements properly in a single-screen layout. This could be defined in a style sheet modeled after the one for the simple-form-ui:

Changing the Edit Controller is trickier for the reasons you mentioned. It should be straight-forward to change the “Demographics” and “Contact Info” sections to display on a single screen, using a simple pattern as described about, and to display the other sections (which are all backed by the same encounter/html form) on a single screen, but, to merge the two you’d either need to modify the EditSectionPageController to handle editing registration encounter obs, or expand Html Form Entry to handle editing Person Names, Person Addresses, and Person Attributes. My gut would be to go for the latter approach (expand HFE). There is an existing “Person” tag within Html Form Entry, but, honestly, it’s not wildly used, so it wouldn’t surprise me if it doesn’t work out of the box with OpenMRS 2.x, or if it doesn’t provide all the functionality we need (looks like it supports name and address, but I don’t think is says anything about person attributes).

It’s somewhat clunky that we rely on two totally different means for editing different parts of a form (and beyond that, different means for entering vs editing a form). This is something that it would be nice to clean up at some point, but, also, it does work as-is, so it would be worth giving some thought if you could live with 2 pages for editing patient information (still an improvement over 5).

Hope this helps, let me know your thoughts and we can continue to explore further!

Take care, Mark

1 Like