O3 Referrals - UOM Project

O3 Referrals – Weekly Progress Updates & Questions

Hi OpenMRS Community!

We are a student team working on the O3 Referrals project. We created this discussion to share our weekly progress, discuss questions that come up during our work, and get feedback and guidance from the OpenMRS community.

What we are working on

Our project focuses on improving the referral workflow in O3 by providing a structured and trackable referral process.

We will use this topic to share our progress each week.

While reviewing the existing OpenMRS pages and repository, we may come across questions related to the project. We will post those questions here to get feedback and guidance from the community.

We look forward to learning from the OpenMRS community and contributing to the project!

Week of September 1 – O3 Referrals

Done: Reviewed the relevant OpenMRS Wiki pages, forked and reviewed the repository, and created the initial Use Case Diagram and ER Diagram.

Next: Continue reviewing the existing referral workflow and refine our diagrams.

Blocked on: Nothing currently.

Decisions made: Agreed to further understand the existing implementation before starting development.

Decisions needed: Clarification on a few questions that came up while reviewing the repository and planning our implementation.

Diagrams:

Use Case Diagram

ER Diagram

1 Like

Great use case design @PalladiumKenya we have completed some work around this with use cases covering Community, Health Facility and Ambulance POC referrals

1 Like

Sorry if this comes across harshly, but this needs to be made in a way that can be added to the OpenMRS ecosystem.

Both the backend and frontend modules are meant to be built within the existing OpenMRS ecosystem as separate modules on their own yes, but you don’t have to recreate an entire system. Which I’m noting out based on the diagrams (and if these are mainly to cater for your university submissions, that is fine). A couple of points -

  • View notifications and alerts - We currently don’t have a mechanism for sending out notifications (or the system receiving it). A couple of things here -
    • There is an effort to build a notification system, which you can track in this thread here.
    • If the referrals app is planned to be made as an app inside patient management, the fact that we don’t have a notification/alert system already would likely be an issue. If it is a separate app of its own (like the form-builder) then I guess it is less likely of an issue?
  • Administrator - There is a general admin UI that allows users to mess around with users and permissions, and manage system configurations, so there is nothing new to make there in terms of those two specific use cases. If there are special UI screens required to configure parts of the referral app itself, for example configuring what the referral document template should like, then yes, those scenarios would justify its own admin screens.
  • View Reporting & Analytics - This is a bit vague. You’re probably going to have to be a bit more specific about reports and analytics you want to support.
  • User, Clinician & Administrator - This, sort of highlights my point about the fact that you are building a module (plugin, if you will) within an existing system that is made to support modules. You would not need to create separate entities for user roles like clinician, user and administrator and for keeping track of things like user, password, role, department, etc.

I suggest you also play around with our test instances so that you get a good understanding of how modules and packages are made, and how they fit in with the rest of the system. This is so that you not only understand what you need to make, but also what you don’t need to.

1 Like

An important consideration, too, is that there are multiple referral workflows. Sometimes, a referral may be electronically sendable and information may be able to pass back and forth, but referrals also may need to be printed out and done basically via paper with potentially no update or an update only at the next appointment that will need to be manually entered.

Thank you! That would be really helpful for our work. Could you please share the use cases or any related documentation? We’d be happy to review them and see how they can support our O3 Referrals work.

Thank you, that’s a good point. We’ll make sure to consider both electronic and offline referral workflows, including manual updates when needed.

Thank you for the detailed feedback. This is really helpful. We’ll review the existing OpenMRS modules and test instances to better understand how our referrals module should fit into the existing ecosystem.

Regarding “View Reports & Analytics,” we mean providing administrators with an overview of referral-related data, such as the total number of referrals, pending/completed/overdue referrals, referrals by department or service. This would allow administrators to monitor and analyze the overall referral workflow.

Week of September 15 – O3 Referrals

Done: Listed and organized the requirements related to the Internal Referral System based on the relevant OpenMRS requirements and discussions.

Next: Review and refine the identified internal referral requirements and continue analyzing the existing referral workflow.

Blocked on: Nothing currently.

Decisions made: Agreed to first understand and document the internal referral requirements before proceeding with implementation.

Decisions needed: Confirm the finalized internal referral requirements and workflow.

Links: Internal Referral Requirements document link– Internal Functional Requirements Specification - Google Docs