So far in our gap analyses with Palladium/KenyaEMR, PIH/CompanerosEMR, and Ampath/AMRS-POC, there are 2 common needs everyone has for the Registration page:
Configurable: Need for the Registration Forms to be configurable (even per site or per department, not just per organization) - 1 size does not fit all. (The same is true for Vital Signs/Triage)
I think essential forms like these should be built using the same Form Builder tech that’s used to build Clinical Forms.
Should we try to build-in an address hierarchy “widget” or feature into our 3.x Form Engine?
Strategic Rationale
Based on >70 user/org interviews and market research, I believe EASE OF CONFIGURABILITY needs to be one of the major differentiators of OpenMRS 3.x going forward. I.e. Our system should be easy enough for non-technical BAs/PMs to configure essential forms. This helps address speed of implementation, ability for implementers to scale their business/impact, and reduce the menial task burden on development (my impression is devs would like more meaningful work than basic config changes here and there).
“But Grace, you really only need to configure the Registration form once and then you’re fine.” Is this really others’ experience? My response is:
Scenario A: Scale. Implementers often have many, many sites to set up, with varying requirements (so maybe you only configure the registration form 1-2x per department; but if you have hundreds of go-lives over a few years, that really adds up!!)
Scenario B: Evolving Requirements. Clinicians and Managers and Funders often adjust their requirements. In my pre-OMRS form implementation days, we though Registration forms would be standard, but we found that over and over again sites wanted or needed tweaks to context-specific registration forms, which created painful forking complexity even for a single site. Eventually we had to make Reg forms easily configurable by folks like me.
(Note on priority: Medium. Right now clinical testing at Ampath (and I expect at future pilot sites) is focused on the clinician workflow, and the registration is still happening with the site’s legacy frontend. However since @vasharma05 has been working on the registration epic quite a lot lately, I’d like to figure out a pathway forwards.)
Thanks @grace. Our experience is that the core registration is often a regional specification, in fact a national specification.
From the top of my head the core registration is the way to record the names, the address(es) and the official identifiers. There are even perhaps a couple of attributes that can be part of the core registration, actually phone numbers are such attributes.
I agree that beyond that core process that is valid, presumably, in a certain country, then other things may become specific to a workflow existing somewhere, and I guess that’s what you refer to as those aspects of the registration that are specific to a department? Those could be done with a second form that is hooked to or that completes the core registration and that is to be submitted just after it (maybe as an extra registration encounter?)
If the non-core part of the registration was just a form, then there is nothing to do so to say, end users would just use the form builder to put it together.
Anyway, when doing the BA work here, it is important to identify what exactly is universal for a certain country/region, because this is what would be part of the country package for that geographic zone as part of the core registration for that geographical zone. We at @Mekom would like to start putting together country packages that exist precisely for that kind of reason.
Thanks @grace - I totally agree with this notion that registration needs to be fully customizable, and should be done consistently with our form engine approach, not with some other mechanism that tries to replicate a form engine. We ran into a bit of this problem with the 2.x registration, where capabilities in registration configurability and widgets is independent of capabilities in htmlformentry (and other form engines). It would be best to avoid this if we can. Certainly addresshierarchy is a key requirement.
One consideration however is that registration can have quite a few requirements that don’t fit neatly into most a lot of the standard Q and A form entry widgets. I’m thinking of things built into a registration app like:
auto-generation or manual entry of identifiers
printing of id cards, wristbands, and labels
similar patient matching, including integrating with an MPI
fingerprinting
We’ll need to consider how we can support registration built on configurable forms, largely maintained by BAs/PMs while also allowing for this type of functionality to be embedded within them by developers seamlessly.