GSOC 24' : Validating and updating the OpenMRS patient flags module - Requirement gathering

Community GSoC
,
1

Hi,

I am interested in contributing to patient-flag module project in GSOC 2024 and I use this thread to discuss further about project and requirement gathering purposes. This project mainly focus on overhaul the performance issue in patient-flag module.

As a start I have gone through the module to find out potential performance issues. I’ve observed that the current module compute the flags for a patient (or a group of patients) when in form submission. Or do this as AOP for data submitted outside of forms.

Issue in current module

current patient flag module evaluate the flags sequentially, which can cause performance issues when a patient or group of patients has multiple flags.

Solution 1

We can improve performance by enabling asynchronous processing in patient-flag module. So This involves adding an asynchronous function to the flag service class, which will handle the flag evaluation for individual patients or groups of patients using the evaluation logic.Then we can call that async function to where the flag evaluation need. This approach allows multiple flag evaluations to be performed concurrently, potentially improving performance compared to sequential evaluation.

Solution 2

Instead of evaluating all patient flags each time the form submission. we can do incremental updates. Only patient related flags that have changed since the last evaluation or those that are relevant to the current context. This can reduce the amount of computation needed during evaluation process. But This will be complex to implement.

Furthermore, other objectives of this project are to add support for Java 17 and introduce a new functionality to facilitate the translation of patient flags between the Flag - FHIR v5.0.0 Resource and the OMRS Flag model.

When we mapping OMRS flag model between FHIR resource, we have to add the all layers of the tooling FlagResourceProvider , FhirFlagService , FlagTranslator , FhirFlagDao. I still thinking about the implementing evaluation logic, tags, proprieties and display-points.

I warmly welcome any ideas, suggestions, pointers, or guidance on this.

CC: @wikumc @dkayiwa @ibacher

2 Likes
2

Great investigation @manojll. I think your proposed solution 01 is the way to go. Solution 02 appears overly complex and could introduce complications if implemented.

1 Like
3

To include the flag-tag and evaluation logic in the FHIR Flag resource, I am to use the extension mechanism provided by FHIR. This extension allows us to add custom or non-standard elements to FHIR resources while maintaining interoperability with the standard. below is example how we can map the OMRS flag model with FHIR flag resource.

{
  "resourceType": "Flag",
  "id": "flag id",
  "name": "flag name",
  "criteria": "flag criteria",
  "subject": {
    "reference": "Patient/1"
  },
  "status": "active",
  "code": {
    "text": "message"
  },
  "priority": {
    "coding": [
      {
        "system": "URL",
        "code": "p1",
        "display": "red"
      }
    ],
    "rank": 2
  },
  "note": "additional note"
  "enabled": true,
  "extension": [
    {
      "url": "URL logic ",
      "valueString": "Groovy script"
    },
    {
      "url": "URL tag",
      "valueString": "Tag details"
    }
  ]
}

CC : @wikumc @ibacher @mherman22 @jnsereko @dkayiwa

1 Like
4

This refers to a large number of fields that are not part of the FHIR Flag resource (criteria, priority, note, enabled, etc.). I think more thought could be put into how these fields relate to the flag (and note that a Flag, in FHIR terminology, is an actual alert, not the logic to detect the alert (in OpenMRS terms, it is data and not metadata).

1 Like