...
Secondarily, to provide other interfaces (other tabs/panels, for example) which provide additional insights, controls, and diagnostic information to the system administrator. For example, diagnostic information about missing backend modules.
Driving User Story: Developers and project leaders for OpenMRS EMRs want their remote sites to be empowered to make the changes they need to make, and depend much less on core developer resources, (and so that devs are not doing a bunch of custom UI hacks with expensive dev time). Central dev support teams often get requests like "We would like the registration page to lead directly to the patient's chart, instead of the registration summary". These Implementer Tools should make changes like that easier.
User Goals
All user stories below are for non-developer admins of OpenMRS. These folks range in skills from being new to using MS Office or GSuite tools, to being fluent in JSON.
| Priority | Need | Reason | Notes |
|---|---|---|---|
| Highest | CONFIG: Configure existing widgets | I need it to be easy to find and change the config for each widget, so I can quickly made the changes needed for my particular organization or site, so that our custom Concept Codes can be applied to the widgets. | Each widget is designed to work with default settings, but users may have to change certain things.
|
| Higher | ADD WIDGETS: Add ready-made widgets to my existing pages or my custom pages | I need to easily find alternative/additional widgets that are already available, so that I can quickly add content of interest throughout my EMR, without having to ask developers to build new custom things for us. | |
| High | PAGES: Create my own custom pages for the patient chart | I need to build a page specific to a particular program or site, so that patient chart information that only that program area is interested in is easy to find. e.g. Imagine new pages dedicated to program/topics like:
| Workflow:
|
| High | WIDGET TEMPLATES: Customize my own widget from a widget template | I need to be able to adapt a "templated"/"vanilla" version to suit my needs, so that when there's no pre-existing widget like what I want, I have the ability to unblock myself without needing developers to build an entirely new widget for me. | aka Configure your own "vanilla" widget: E.g. Table Example: I want a Table widget showing a few key peices of information that matter to our pre-surgical clinic - e.g. BMI, Blood Sugar, and Blood Clotting tests results at each of their most recent pre-surgical Visits. I imagine something like this: (Visit Date) | (BMI) | (Blood Sugar) mmol/L | (Blood Clotting test result) 1) Search for existing widget that meets that description, and don't find one (side note: many users might not even want to bother with searching and might want to jump right in to creating their own thing; but probably a good idea to enforce a search workflow first to reduce duplication of widgets & work) 2) Identify "I want to build my own widget" 3) Select "Table" type (which then provides me with a blank vanilla Table widget to start from) 4) I can then identify the concept(s) I want to track in each column (e.g. Visit Date, BMI, etc). E.g. Chart Example: I want a Chart showing Pregnancy-related Weight Gain over time. Possible workflow: 1) Search for existing widget that meets that description, and don't find one 2) Identify "I want to build my own widget" 3) Select "Chart" type (which then provides me with a blank vanilla Chart widget to start from) 4) I can then identify the concept(s) I want to track (e.g. "Pregnancy Weight"), and further configure things like the color and style of the line. Reorder arrays (like custom pages in patient chart) Brandon calls this a "list of multiple complex things (aka array of objects)" where the user has the ability to further define what sits inside the table/list/widget. His early example design is here:
|
Starting Point
We have an application, the Implementer Tools, which provides a janky interface for managing configuration.
...
All of the above, despite its ugliness, should be reviewed to understand the types of functionality that have been envisaged so far.
Functional Specification
User Story: I need a way to publish my changes, so that...
(this is a JSON file I download, and upload somewhere; or they get saved to the server directly)
User Story: IUntil I publish my changes, I need my changes to only be applied to my browser, so that the changes aren't happening on the fly in production and impacting users live at my clinic.
There are essentially the following main parts: microfrontend configuration, extension configuration, and the UI editor.
...
wherein one object has an element that is not part of the member object spec.
Editing
- Editing basic config values. These are booleans, numbers, or strings.
- Editing arrays. Should be able to add, remove, and reorder elements. For arrays of objects, adding an element to the array should add an object with the correct shape.
- Editing freeform objects? Literal JSON editing might be the best we can do, here, since values can be of any type.
...