Some ideas from this doc,
Dynamic EHR: Custom Home screen (and other screens) based on User roles, locations and other values
By @ibacher
We would like to show UI elements on the O3 home page and other pages that are most relevant to the user. Currently, there is ability to do so based on User privilege. However, this is limiting and not general enough. We would like to define what to show based on other values, such as Location, currenting displayed Visit / Encounter, etc…
More generally, this can be solved by having a way to write custom logic (in the form of a reduced set of JavaScript expressions) to define whether an Extension should be shown. There is actually something (what?) similar in O2 already. We should be able to inject dynamic variable values into the expression.
Some other Idas from the same doc:
-
Extension useEffect hook
-
Better typings for passing data into extensions and simpler extension configs
-
Better way to receive feedback from clinicians / users
-
Start having reference implementations of component in ZeroHeight
-
Deduplicate requests from useCurrentPatient & useSession hook. Ticket
- It should be possible to leverage SWR’s caching and deduplicating features in the useCurrentPatient hook. Presently, multiple requests get fired each time we load up a Patient Chart, and unnecessarily so.
-
Stricter Typescript configuration for strong typing
- Dovetails with Chi Bong’s work on extractwhaing a types library from our Swagger backend docs.
There are also some ideas proposed in 2024 that didn’t move forward:
https://openmrs.atlassian.net/wiki/spaces/RES/pages/26279023/Summer+of+Code+2024#Pending-project-ideas%3A
OpenMRS Standalone:
Replace the Standalone with something else. Very old, can’t even build in our latest releases - we disable it as the technology no longer works and is no longer supported. We now just ship the .war file and README. Suggestion to leverage Docker - something that works by double clicking and then just runs.
We never intended to use the OpenMRS Standalone version in production. But it turned out to be used in a number of places because they found it easier to use for sites that did not have support staff with advanced IT skills. We are also seeing an increasing number of people in our community who do not have lots of computer skills and just want something to download, click and run for their hospitals.
User-defined extension show / hide rules:
The idea here is to implement something like O2’s checkRequireExpression() via the configuration schema’s “Display conditions”, allowing implementations to right JS rules to determine whether a specific extension should be visible or not.
Revamping OpenMRS 3.0 FHIR Module for Enhanced Offline Data Synchronization and Interoperability
This proposal aims to overhaul the FHIR module in OpenMRS 3.0, focusing on enabling its interoperability with applications like Google’s Open Health Stack for efficient offline data collection. The project will involve a comprehensive review of the current module, identification of limitations, and subsequent enhancements to support adding, editing, and deleting patient data, visits, encounters, and observations. The goal is to facilitate robust two-way data synchronization, crucial for healthcare settings in LMICs with intermittent internet connectivity.
Next Generation Implementer Tools for OpenMRS 3
Non-tech users can set up a 3.x EMR in a friendly, no-code UI, similar to designing a website. Empowers local team members to set up and config their EMR themselves. More detailed user stories and requirements documented here. Project plan documented here.
Scope: technical work on the redesigned config tools for O3.
*Design is done because Ampath/@jdick graciously contributed designs and user testing, sample designs, and @bistenes gave a lot of architectural and technical input but then had to set the project aside.
O3: Search Patient Chart feature
E.g. search all of a particular patient chart for an item of interest, e.g. “IUD” or “COVID”, to find if that term/situation has ever come up for this patient. We can likely leverage this past work: GitHub - openmrs/openmrs-module-chartsearch: liquibase.xml Will need an API.
