TRUNK-6462: (feat) Align FulfillerStatus enum with FHIR Task Status codes on platform 3.x

[its-kios09]

Description of what I changed

Adding FHIR-aligned statuses to FulfillerStatus enum to better support task/order lifecycle management.

Reference: https://hl7.org/fhir/codesystem-task-status.html

New statuses being added:

• DRAFT
• REQUESTED
• ACCEPTED
• REJECTED
• READY
• CANCELLED
• FAILED
• ENTERED_IN_ERROR

This will allow OpenMRS to better represent the complete lifecycle of orders/tasks in FHIR-compliant ways.
DEMO Video

Issue I worked on

see https://openmrs.atlassian.net/browse/TRUNK-6462

Checklist: I completed these to help reviewers :)

• My IDE is configured to follow the code style of this project.

  No? Unsure? -> configure your IDE, format the code and add the changes with git add . && git commit --amend

• I have added tests to cover my changes. (If you refactored
  existing code that was well tested you do not have to add tests)

  No? -> write tests and add them to this commit git add . && git commit --amend

• I ran mvn clean package right before creating this pull request and
  added all formatting changes to my commit.

  No? -> execute above command

• All new and existing tests passed.

  No? -> figure out why and add the fix to your commit. It is your responsibility to make sure your code works.

• My pull request is based on the latest changes of the master branch.

  No? Unsure? -> execute command git pull --rebase upstream master

[its-kios09]

@chibongho ping

[chibongho]

Looks good, but deferring to others with more experience with core.

Context: openmrs/openmrs-esm-laboratory-app#445 (comment)
This change aligns with FHIR's medicationrequest-status

[mseaton]

Is this valid? I don't think DRAFT is a FulfillerStatus. If it is, then we need to add update the javadoc to reflect the version of OpenMRS where this is since.

[wikumChamith]

@its-kios09 did you get a chance to look at the this: https://openmrs.atlassian.net/wiki/spaces/docs/pages/25477199/Pull+Request+Tips?

[its-kios09]

@wikumChamith You can confirm from this reference https://openmrs.atlassian.net/browse/TRUNK-6462

[its-kios09]

@mseaton Yes, DRAFT is a valid FulfillerStatus that I'm adding in this PR. You're correct that the JavaDoc needs to be updated.

[mseaton]

A few things.

• I still don't see the @since Javadoc updated. That would need to be done.
• Assuming https://hl7.org/fhir/codesystem-task-status.html represents the list of valid fulfiller statuses from FHIR, it seems fine to me to add this, but why wouldn't we add the rest while we are at it?
• I don't actually think that using DRAFT fulfiller status is the right interpretation of how it is intended to be used, for the use case that you present. i.e. my read of that FHIR link is that this status is meant to mean "Do not yet perform this test", not "Test is performed but results are not ready to be shared / need to be verified".

I would like @ibacher to weigh in as more of a FHIR expert with this thoughts

[ibacher]

I agree with @mseaton's points. DRAFT is not a reasonable "fulfiller status". I'm also uncertain about using Task Status here. Orders are not FHIR tasks, though I suppose they might result in one. We've historically been using something similar to this valueset as a model: https://www.hl7.org/fhir/valueset-diagnostic-report-status.html, which is more directly a valueset of "statuses of results", which is really what an order should expect.

If we want to be able to track tasks resulting from orders, we should just build a data model that supports tracking tasks, not try to bolt it onto the order, especially via this already overloaded FulfillerStatus enum.

We've had some discussion of supporting draft elements, but that would be a matter of marking the order itself as a draft (for example). FHIR and OpenMRS have somewhat different workflows and just adopting a FHIR valueset with different semantics here leads to a field with a very unclear meaning.