Page Comparison

implemented ability to change a range depending on a given variable (eg age, sex) in flexible way; can be done with bare minimum change of data model. Also implemented in our data model FHIR’s obs reference ranges which enables OpenMRS to receive reference ranges from an LIS system (instead of disregarding this). Obs Interpretation: Based on those ref ranges, can apply whether this is Normal, Low, Critically High, etc. This is now part of the data stored in the DB. Overall this means that Pediatric and Elderly lab/vitals range differences now supported, warning flags now supported better.

Wiki Docs

Talk post | Epic | Tech framework done

• Test Automation coverage requirements tool in progress to make it easier to write tests for our code. Should make it easier to write unit tests. Slow grind being done by Ian.

• . Slow grind being done by Ian.

Use MPI integration to find and record patients, and exchange health records through central DB(s). May involve tracking patient consent for data-sharing.

A combination of Bed Management (ward app) + unique forms + ADT (admit body, discharge to family, transfer for investigations)

Fix issues with API performance, found via Automatic Load & Performance Testing. (Speed of loading: Locations, and Visits view)

Currently, there are no clear guidelines for Implementer BAs/PMs on how to wisely create, manage, and edit concepts / terminology.

Contact Person: Veronica Muthee

Problem: Users have too many choices to pick from (e.g. drug orders, labs, diagnosis options, etc). User-based favorites can improve the UX and speed.

Contact: Grace Potma

Wiki: ___ Epic: ___

Often clerks need to print an ID card after registering a new patient.

Interested: PIH, Madiro

Interested: PIH

Order Template Modelling E.g. Common Rx's 

GitHub Example

Interested: UCSF, PIH, Mekom

Support for Sets of anything that's order-able (e.g. COVID assessment set can contain Meds, Labs, Referrals...)

Interested: PIH, Mekom, Sonder, OpenMRS Inc, FAIMER

Clinical Views

Ability to add specialized program- or condition-specific views. Ideally, able to update config easily to add more - e.g. represent clinical view w/ JSON structure. 

Generic Encounter Widget 

Reuseable version of a common widget, powered by config that's easily editable (e.g. if you want to change columns & data shown in a table)

Orgs:

IPD Requirements Gathering

Collecting further requirements for inpatient care, e.g. Bed Mgmt, MAR.

Offline EMR Use (No Internet/Power Loss)

OpenMRS Reporting UI

Create a UI that would be able to run an existing report with parameters (if applicable), select the output format and download it

GSOC project?

Backend Dev work complete; UI work next.

Currently the DD Module causes slow startup times because of how patients are being created & data loaded. Idea: Generate the data once in it's own docker container instead of generating every time we start an instance. Largely coming from appointments module. The real fix is content packages, so we can remove the Demo Data from the base distro so everyone doesn't have to run the Demo Data when they start up the application. (Only 50 pts, but slows down startup by ~10 minutes; additional errors coming from Bahmni Telecom module)

Remove because this feature is significantly underused and slow (it's faster to stop, add an OMOD, and re-start your instance than it is to upload an OMOD on-the-fly at run time), and because the OMOD upload fx has security implications. The hope years ago was that Spring support would make this a more stable, performant feature, but this didn't happen, and it is very underused.

In order for the EMR-distro vs HIS-distro vision to work, the way data is served-up to the frontend needs to work smoothly & function the same way - otherwise neither application will be sustainable (especially with HIS-Lite fx being added to the EMR-distro like Billing, Inventory, Labs, and Data Viz). Plan is for a FHIR-based approach.

Bulk Retrospective Data Entry is regressed and unuseable in the O3 EMR distro. Very helpful for RDE so should be resurrected.

Interested: ICRC

• Dealing with concept overlaps, i.e. the same concept being a bit different in 2 different packages

Show & recommend specific forms based on information about Patient or Program Enrollment (eg show ANC forms for ANC visits); likely specified via Form Schema & executed via Form Engine. Very challenging engineering - would need context, workflow engine. In meantime the Tabbed Table Component from OHRI helps meet this user need to some degree. Future ideal is "If patient is [obs] = X and [visit type] = Y, then show these foms".

"Prevent Pt Duplicates" flow in Registration Page. Possibly should include merging pts. Should leverage pt-duplicate-detector in core.

e.g. Notifications between team members (within UX of System wide / Global notifications; for 1 user but not about 1 patient)

Patient Lists: Automated (Cohort Builder)

(1) Query for patients who meet a certain criteria, and (2) automated adding/removing of patients from this list (so it's automatically maintained). 

E.g. "show me all Patients who missed med pick up..."

E.g. "show me all Patients who missed their appointment..." 

+ Actions on that list (e.g. change patient status)

Interested: _______

Palladium recommends this OMOD be reviewed as it becomes key in CDS / patient flag calcs and reporting.

Currently not obvious in UI and underutilized.

OCL OpenMRS Import feature

An answer (and clear documentation) to "How do I get my legacy metadata into OCL?"

"Here's what will change" UX/UI when subscribing. (Possible GSOC Project)

Map OpenMRS Order statuses to FHIR

Send a case report from OMRS system to a central repo. 

Using 3.x RefApp, UW DIGI checked for areas where REST API is being used where FHIR either could be used or needs support (Doc Here)

Goal: Demo a form that’s defined and rendered through mappings (not UUIDs). Eg if a country maps to OHRI concepts → Need ability to map

Interested: PIH

A sample integration, both flow and tech, that implementers can easily re-use. Working ad-hoc with CHT Lead Architect on this. 

Goal: To expose OMRS Concept Dictionary through the FHIR API. Currently dependent on REST API for all things concept or terminology related. E.g. Needed for 3.x dynamic patient list queries to be entirely FHIR based; to convert all calls into individual concepts.

Event bus so that when things happen, they trigger a new process(es) to start. (e.g. patient finishes visit, needs to be moved from one Service Delivery Queue to another) - see OHRI example outlined here re Patient State vs Workflow State 

Roadmap here