Uploaded image for project: 'OpenMRS Core'
  1. OpenMRS Core
  2. TRUNK-5228

PatientProgram: If a program is completed, voidPatientState should set end date of previous state to date completed of program



    • Bug
    • Status: Closed
    • TBD
    • Resolution: Fixed
    • None
    • Platform 2.2.0, Core 2.2.0
    • None
    • None


      In core, the PatientState domain object has a "voidLastState(ProgramWorkflow)" utility method that voided the last (most recent) patient state for that patient within the specified workflow. This is what the REST module delegates to when deleting a state RESTfully.

      There's some business logic built int the method, namely that it sets the end date of the "next-to-last" patient state to null, which is generally the "right" behavior. That is if you have:

      Pre-ART: Oct 1, 2017 to Oct 5, 2017
      On ART: Oct 5 to Present

      And delete, "On ART", you end up with:

      Pre-ART: Oct 1, 2017 to Present

      The case when this doesn't seem right is when a program is completed... for instance, say you have:

      Program Completion Date: Oct 20, 2017
      Pre-ART: Oct 1, 2017 to Oct 5, 2017
      On ART: Oct 5 to Octo 20, 2017

      If you delete the "On ART" in this case, you end up with:

      Program Completion Date: Oct 20, 2017
      Pre-ART: Oct 1, 2017 to Present

      The correct logic is to set the end date of the next-to-last state to "null" if the program has not been completed, but, if not, set it to the completion date of the program.

      This functionality has been implemented in the following feature branch:


      ... but should not be added until TRUNK-5230 is completed for consistency.

      There was talk of backporting these, features, but I think it's fine to just apply them to the latest master at this point... but note that this feature branch was made off of 1.10.x, so you may want/need to cherry pick this commit into the master branch.


      Gliffy Diagrams


          Issue Links



                mogoodrich Mark Goodrich
                mogoodrich Mark Goodrich
                0 Vote for this issue
                1 Start watching this issue