How does OpenMRS support/model "Case Paradigms"? Eg 1 patient with multiple distinct episodes of the same condition? (eg pregnancy, TB...)

Hoping to hear from @burke & @dkayiwa & others on this.

Pregnancy ID Scenario:

  • You have a patient, Agnes. She has her own UUID (eg 12345ABC).
  • Agnes is currently pregnant. That pregnancy is given an ID (eg PID (pregnancy ID): PID1).
  • Agnes delivers that pregnancy successfully - that pregnancy is still called PID1, and there are post-delivery care actions/follow-up that needs to happen for PID1.
  • But soon afterwards, Agnes becomes pregnant again. That pregnancy needs an independent id (eg PID2), so that the care coordination of PID1 and PID2 do not get confused, especially since they have overlapping care timelines (eg Agnes may still be receiving post-partum care for PID1 while she is also receiving pre-natal care for PID2).

Same patient, different pregnancy case. (This is a real-world need for a country implementation of ANC that @UCSF is working with, where they do indeed have PIDs.)

Infection ID Scenario:

  • Patient: Bob.
  • Bob gets tuberculosis. He goes through routine treatment, and this is successful.
  • Bob lives TB-free for a while.
  • Eventually, Bob gets tuberculosis again. This time it DR-TB (drug resistant) and needs a special regimen to treat.

Same patient, different infection case. The program wants a way to differentiate these separate episodes, for the same patient - eg TBID1, TBID2…etc.

Reporting Implications These “Case IDs” become especially important in reporting, where it needs to be clear that “the outcome for Case1 was X, but the outcome for Case2 was Y”. Eg perhaps for Bob: The outcome of TB1 was routine treatment & recovery, but the outcome of TB2 became MDR-TB/further drug resistance and prolonged treatment.

Q: How do we model this / handle this “case identification paradigm” in OpenMRS?

CC @wamz @eudson @ibacher @mayanja

1 Like

While there’s some superficial similarity here, we’re closer to being able to support the second case rather than the first. For the second case, this is exactly what the Condition domain allows you to track, i.e., different instances of one or more problems with start and end dates. All that would be need would be to tie the condition, e.g. TB, to a specific program registration (perhaps via an attribute) and then the visits and encounters that are part of that program can be traced to the specific condition occurrence.

However, it’s probably not a good idea to use the Condition domain to track pregnancies, partially because there’s more information that should be tracked as part of the pregnancy, and partially because it’s a bit different. That said, a similar domain could be added via, say, a perinatal care module and tracked similarly.

1 Like

Agree with @ibacher .

We would like to use condition list, but it continues to be buggy. It’s modeled for chronic conditions (HIV, hypertension, etc)

I don’t think we would use this for TB, but program enrollment is a good match for this case. The patient starts/ends the program for each TB infections/treatment.

Pregnancy is different but our users want to keep history of each pregnancy which is challenging with the current tools. Challenges include a single pregnancy with multiple babies/outcomes AND the difficult situation when a pregnancy isn’t full-term.

1 Like

That should be fixed in 2.6 when it’s released. Unfortunately, the PR didn’t make it into 2.5. But it’s not just for chronic conditions… it’s for anything that might need follow-up over multiple visits, which I think matches TB.

1 Like

Problem lists (Condition) could be useful for case finding, but I wouldn’t want to depend on condition to define episodes of care. There can be multiple conditions (diagnoses codes) for a single “condition” – e.g., pregnancy. Also, Condition lists should be in the purview of providers to track clinically relevant conditions and we should be careful about creating workflows that require something to be added or removed from the condition list – using Condition is fine, but I wouldn’t depend on conditions in a patient’s Condition list (problem list) to drive workflow.

For lack of having formal support for episodes of care, OpenMRS’ Program would be the closest fit for pregnancies or TB treatment episodes.

1 Like

For pregnancy, we currently use Program (Maternal Child Health), Workflow (Type of treatment), State (Prenatal group) to indicate when a woman is pregnant. It is set on an htmlform (or program dashboard widget) and needs to transition/stop using the dashboard widget.


I have seen some implementations that use Programs enrolment/Exit to track cases, the issues has always been that with a new case old data gets overwritten.

@wamz The program data isn’t overwritten. For a test patient, they have been enrolled and exited MCH many times. The enrollment dates for a program cannot overlap.


1 Like

@ball can you have overlap in enrollments? Eg. if a woman gets pregnant again with child #2 shortly after birthing her last baby, while she is still in the post-natal/mch care program for child #1?

The woman would remain enrolled in MCH.

This is an interesting question… I don’t know how the episodes would get reported out if the second pregnancy took place within the first pregnancy’s MCH episode… I would like to understand how this is handled as it is one of the main differentiators of OpenMRS from DHIS2 tracker or Commcare which is based on episodes.