GSOC 2023: Question about Validating and re-working (updating) the OpenMRS PatientFlags module

Community GSoC
1

Hello I am Sung Yoon Kim from South Korea.

I am interested in the following items. GSOC 2023: Validating and re-working (updating) the OpenMRS PatientFlags module

It was suggested that there are some loopholes in the idea description.

  1. To find out what kind of loopholes there are, I looked at the OpenMRS community and Git
  2. I saw a post saying that the speed is very slow when creating and importing some flags

this is the post → Scaling Patient Flags 2.x module GSoC 2023 project: Moving forward with patient Flags in RefApp 3.x - Development - OpenMRS Talk(Scaling Patient Flags 2.x module GSoC 2023 project: Moving forward with patient Flags in RefApp 3.x)

  1. When I look at the code, it seems that there are some logics that increasing time complexity, resulting in a request that takes a long time.

  2. I think it would be nice to solve this problem by refactoring these logics that have high time complexity.

Is this a good approach to the project?

And also could this be a major loopholes problem? Are there any other problems?

Thanks for reading my question.

@ibacher @dkayiwa

3 Likes
2

Hey @sienna1022, thanks for sharing your thoughts on the OpenMRS PatientFlags module project for GSOC 2023. Your observations about the potential loopholes in the project description and the issues with time complexity in the codebase are spot on.

To make sure we are on the same page about the project requirements, let’s set up a design call with @ibacher and @dkayiwa. This will be a great opportunity to discuss the project goals, clarify any ambiguities, and answer any questions you may have. We want to make sure that all interested students have a clear understanding of what is expected in this project and how they can contribute to it.

@ibacher and @dkayiwa, would it be possible to organize a design call to discuss the OpenMRS PatientFlags module project with interested students like @sienna1022? Please let me know your availability, and we can schedule a call accordingly. Thank you!

cc: @jnsereko

3

@jayasanka do we have mentors for it?

4

The starting point of this project is taking a look at the OpenMRS FHIR2 module and specifically how to add a new Resource to the FHIR tooling. (you need to add it to all the layers of the tooling ie ResourceProvider , Service , Translator , Dao )

HL7 FHIR has a better implementation of flagging, ie support for warnings / notifications with the Flag Resource. This resource supports creating references as subjects which can be mapped to the patient using his/her OpenMRS ID and/or UUID.

For now i might not be so sure if we are going to fade away with the whole earlier OpenMRS flags module, but i am pretty sure that the first step to solving this is Pushing a commit to openMRS FHIR for supporting a Flags Resource.

As this is the core requirement, it is a medium issue and i wouldn’t expect it to be so hard or too complex to implement. FYI, this is the reason why @ibacher tagged this project as might be done early.

In the long run, we need to think about how we shall implement earlier logic in the form of tags, priorities, and displaypoints

I think its @ibacher assisted by @jayasanka

cc @suubi7

5

PS I think we are simply going to define the Flag table in the Patient Flags module, and just simply translate to or from it in the FHIR module

6

Ian seems to already have more projects than our recommended number: GSoC - Guidelines for Mentors - Resources - OpenMRS Wiki

7

I would wish to mentor this project but i am applying as a GSOC student this year. Regardless, i will support as much as i can.

Would it be ok @dkayiwa if you become the main mentor for this?

8

Have you read the two wiki links in my previous post?