Meds and Orders Implementation Notes

Summary

This document contains some notes to help with implementation of "Meds & Orders" in the Buendia client, a set of flows within the app for tracking and order patient meds. For the latest mocks and more details on what the feature is and what the motivations are behind it, see https://docs.google.com/document/d/1_dILLB0xwaiJl7ttm4ZFy_5kfMISXmDvUnuh3-MKg9Q/edit#. These mocks will likely require further iteration but provide a starting point.

The OpenMRS Orders API

As of OpenMRS 1.10, OpenMRS contains an API specifically handling the entry and retrieval of orders. Ideally, any meds & orders implementation should integrate with this API for consistency with the OpenMRS data model. An "OrderResource" could easily be added to the Buendia server module that exposes a REST interface for placing and retrieving orders, making use of the OpenMRS OrderService.

Note: OpenMRS orders are immutable, which is at odds with the latest mocks.

Orders Data Architecture

If using the OpenMRS Orders API, ideally there should be a dedicated Order datatype on the client to cache orders locally and keep them in sync with the server. For more information on how the client database and client data architecture are structured, see Client Database Model and Client Data Architecture.

Alternatively, orders could be stored as observations, like all of the other data gathered during an encounter. This has the advantage that most of the data architecture and syncing would already be in place, but creates some confusion by using observations for something other than the intended purpose.

Adding Orders to a Form

Meds and orders will likely be embedded in a form defined on the OpenMRS server, whether part of the existing Encounter form as part of a new form. For more information on adding or editing forms, see Managing Forms and Form Fields.

The new form or form fields may require new OpenMRS concepts. For more information, see Managing Forms and Form Fields#Modifying-a-Concept or Managing Forms and Form Fields#Adding-a-Concept.

Prepopulating Form Fields

It may prove useful (as shown in some of the mocks) to prepopulate meds/orders with previous orders to provide some context.

Fields that can be prepopulated are defined in org/odk/collect/android/model/PrepopulatableFields.java. PatientChartController sets available fields when a form is opened, and the fields are then passed to the FormEntryActivity within the ODK module. From there, prepopulated fields are processed in several places with varying results, but org/odk/collect/android/widgets2/group/BinarySelectOneTableWidgetGroupBuilder.java is responsible for prepopulating the IV access and pregnancy fields, which are the closest analogues to the latest meds/orders mocks.

Creating the Orders Tab

The patient chart is managed by PatientChartActivity and PatientChartController. Currently, PatientChartController fetches all observations for the current patient and the chart UI displays a subset of these observations based on the concepts defined in the Chart Display Order form in OpenMRS.

If meds/order are stored as their own datatype, they will need to be fetched separately from the observations, but this data could embed all of the data necessary for display.

If meds/orders are stored as observations, then you can re-use the same idea:

1. Define a new chart on the server (e.g. Meds and Orders Concepts) that lists the relevant concepts and drugs

2. Hardcode the new chart id on the client

3. Use the fields in the chart to determine what observations to display and how to display them, which may require hardcoding concept ids on the client or changes to the server module