Uploaded image for project: 'FHIR Module v2'
  1. FHIR Module v2
  2. FM2-480

Support expansion of Medication Request statuses

    XMLWordPrintable

Details

    • New Feature
    • Status: Ready for Work
    • TBD
    • Resolution: Unresolved
    • None
    • None
    • None
    • None

    Description

      Currently, the only statuses supported on MedicationRequest are "ACTIVE" and "CANCELLED", with "UNKNOWN" used for anything that doesn't fall into those buckets. However, FHIR supports a broader range of statuses and we need to add support for these for using in Dispensing work. For example, see O3-1213

      The statuses supported by FHIR (See https://hapifhir.io/hapi-fhir/apidocs/hapi-fhir-structures-r4/org/hl7/fhir/r4/model/MedicationRequest.MedicationRequestStatus.html) are:

      ACTIVE,
      ONHOLD,
      CANCELLED,
      COMPLETED,
      ENTEREDINERROR,
      STOPPED,
      DRAFT,
      UNKNOWN,
      NULL;

      We should update the MedicationRequestStatusTranslatorImpl to handle additional statuses beyond ACTIVE, CANCELLED, UNKNOWN, likely be utilizing the "fulfillerStatus" property that was added to the Order class in 2.2, which refers to an enum with possible values of "RECEIVED", "IN_PROGRESS", "EXCEPTION", "COMPLETED".

      NOTE: This may require (or benefit from) updates to OpenMRS core, by adding service methods to determine an Order status based on factors including whether the order is active, has been discontinued or expired, and comparing the quantity requested along with the number of allowed refills with data from the associated medication dispenses. That logic can be added to FHIR2 in the short term, but likely is something we'll want to move to core once it is established.

      ibacher and burke thoughts appreciated.

      Work-in-progress table:

       

      FHIR Status Description Current Implementation Potential Implementatton Notes
      ACTIVE The prescription is 'actionable', but not all actions that are implied by it have occurred yet. Order is Active (based on Order API logic: not a Discontinue order, date activated prior to current date, and auto expire date and date stopped null or after current date) Same as before  
      CANCELLED The prescription has been withdrawn before any administrations have occurred Order is Discontinued (base on Order API logic: Discontinue date before current date) Not used (see STOPPED)  
      COMPLETED All actions that are implied by the prescription have occurred.   Fulfiller Status = COMPLETED We may or may not want this? What does "completed" mean in terms of refills?  How/where is completd set?
      DRAFT The prescription is not yet 'actionable', e.g.   Not used (until we introduce draft orders in OpenMRS)  
      NULL added to help the parsers with the generic types   Not used  
      ONHOLD Actions implied by the prescription are to be temporarily halted, but are expected to continue later.   Not used? Potentially used by the "return to prescriber" use case
      STOPPED Actions implied by the prescription are to be permanently halted, before all of the administrations occurred.   Order is Discontinued or Expired (based on Order API logic) (Note previous CANCELLED was based only on discontinued) and FULFILLER STATUS != COMPLETED I move this logic from Cancelled because by description cancelled implies knowledge of downstream action, which OpenMRS may or may not have.
       
      Would we want to implement this as logic ("isStopped()?") in Core
      ENTEREDINERROR Some of the actions that are implied by the medication request may have occurred.   Not used? We could try to implement some logic based around this if we have MedicationRequest logic, but we may be getting too complicated, ie: "Order is Discontinued based on Order AP land there is or more associated Medication Request event linked to this Drug Order prior to discontinued date"... probabyl getting too complicated?
      UNKNOWN The authoring/source system does not know which of the status values currently applies for this observation. If not ACTIVE or CANCELLED based on above logic If not any of the above statuses based on above logic.  

       

      Note to self:

      • different states of downstream systems-- none, some but offline,  some but realtime
      • Note that some of this logic is currently derived at the API level, which will potentially/likely made "speedy" querying difficult, do we need to build some of this into the API?

      Gliffy Diagrams

        Attachments

          Issue Links

            Activity

              People

                Unassigned Unassigned
                mseaton Mike Seaton
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                  Created:
                  Updated: