Referrals in OpenMRS

Community
49

Fair point, @mseaton. Order types need to be discriminated for a variety of reasons:

  • Order selection – filtering search results to specific type(s)
  • Model – drug orders have different properties from test orders
  • Behavior – APIs can differ between order types
  • Order form – which details apply to the order, which are required vs. optional, etc.
  • Order routing – drug orders to pharmacy, blood tests to lab, others may get printed, etc.

We want to discriminate between order types as needed for the reasons above, but do we discriminate with separate Java classes or with a few Java classes with properties to discriminate? Let’s consider the possible order types:

Order Type Examples
Drugs Medications, IV fluids, etc.
Tests Lab tests (chemistries, microbiology, toxicology, etc.)
Procedures (radiology, cardiology, pathology, gastroenterology, etc.)
Referrals Specialists, community services, etc.
Medical equipment Braces, walking aids, bedside commode, etc.
Nursing Hang blood products, frequency of vitals checks, etc.
Patient education/counseling Materials or guidance to give patient
Diet Limits on calories, protein, etc.
Activities Bed rest, up in chair, up as needed, etc.
Precautions Seizures, withdrawal, fall risk, etc.
Call orders Criteria for notifying provider
Code status / Advanced directives Honoring patient’s preferences on end of life care

It appears FHIR’s approach is to lump these into:

FHIR Resource Order Type(s)
MedicationRequest Drugs
DeviceRequest Medical equipment
NutritionOrder Diet
ServiceRequest Everything else (tests referrals, nursing, education/counseling, activities, precautions, call orders, code status) [ref]

So, what you’re suggesting is we can align with FHIR, but – as you suggest – create subclasses under ServiceRequest for order types that fall within FHIR service requests, starting with TestOrder and ReferralOrder:

  • TestOrder
  • ReferralOrder
  • NursingOrder
  • ActivityOrder
  • PrecautionOrder
  • CallOrder

So, we:

  1. Copy TestOrder to ServiceOrder. Should this be an abstract class?
  2. Make TestOrder extend ServiceOrder and gut it (inheriting all of its functionality from ServiceOrder).
  3. Add ReferralOrder as another extension of ServiceOrder.
  4. Add other classes for subclasses of service order as needed.
  5. When we need order for medical equipment or diet orders, we create separate classes (siblings of DrugOrder and ServiceOrder) to align with FHIR.

Did I get it right, @mseaton?

3 Likes