Notes from a brief whiteboard design session on domain modeling, starting with Orders. The 2.0 ERD was taken as inspiration. This is meant to capture basic ideas and relationships - we expect attribute lists to be fleshed out, names normalized, etc. Business requirement input is also needed.
requisitionCode | Code back to originating Requisition (Optional) |
createdDate | When order was created |
createdBy |
|
program |
|
requestingFacility | Facility requesting the order |
receivingFacility | Facility to receive the Shipment. Could be requestingFacility or one that holds it on behalf |
supplyingFacility | Facility fulfilling the order. Handles local fill or ERP |
orderCode | Order number - user defined and configurable |
status | ORDERED, IN_TRANSIT, PICKING, PICKED, SHIPPED, etc. |
id |
|
quotedCost |
|
Likely need more audit columns, e.g. addl time stamps, assignments, etc. Approvals? Notes?
orderId | Foreign key to Order |
Id |
|
product | Foreign key to Product*. Or <Requestable>? |
orderedQuantity |
|
fulfillmentStatus | Has this been fulfilled by a shipment? Needed if orders are broken up into several Shipments |
*Current OpenLMIS: Requisition specifies exact Product, including pack size, etc. Do we refactor this to request doses or impact, e.g. "Give me 1,000 pills of aspirin" vs. "10 bottles of 100 count aspirin"? Esp. when considering vaccines and doses. This is a required ToDo. Also consider quotedCost here.
If Rationing is done at the order level, need additional column for rationedQuantity.
Must support substitutions and quantity adjustments
Id |
|
Lot |
|
QuantityToPick |
|
product |
|
pickListId |
|
id |
|
orderId | If originated from an Order |
originFacility | Facility sending shipment |
destinationFacility | Deliver to address |
program |
|
shipmentCode |
|
status |
|
Need various date and audit fields. Tracking id.
Id |
|
shipmentId |
|
lot |
|
product |
|
quantity |
|
status |
|
Likely have a ReceivedQuantity column - a specialized ReceivedLineItem object required only if detailed accounting of receipt is required.
id | |
facility | |
program | |
processingPeriod | |
status | |
supervisoryNode | Not sure why this here; drop it? |
emergency | boolean. Specifies whether this is an emergency requisition. Perhaps emergency requisitions should simply be thought of as (ad-hoc) Orders? |
allocatedBudget | |
fullSupplySubmittedCost | |
nonFullSupplySubmittedCost | |
clientSubmittedTime | For mobile client, subject to revision |
clientSubmittedNotes | For mobile client, subject to revision |
(Standard audit info columns) | |
patientQuantification | Foreign key related to requisitions, but should go wherever the report/program data goes |
requisitionSignatures | Foreign key; used by the mobile client and subject to revision |
requisitionStatusChanges | Foreign key; used by the mobile client and subject to revision |
TODO: Determine whether current approval-model is sufficient. Perhaps we need something more sophisticated?
TODO: Consider pulling out authorization into its own domain object to be informed by desired REST endpoint for requisition authorization (e.g. in the REST API, a requisition might have a link with rel=requisition/approve to some URI, and we might want a Requisition Approval to back this, rather than just capturing this in requisition.status, requisition.lineItems.quantityApproved, and requisition.statusChanges)
Requisition_line_item
id | |
requisition | |
product | code, or fk to product table |
productDisplayOrder | sort order of the products (within each category) |
productCategory | |
productCategoryDisplayOrder | sort order of the product categories |
quantityRequested | |
quantityApproved | |
skip | Is this really needed? If the uses checks "skip" in the UI, can we just decline to add a cooresponding row? |
packsToShip | (may not be at top level) |
reason | reason for requested quantity |
remarks | Used as part of approval process (should rename to approvalRemarks) |
(part of reporting, but not necessarily in top-level requisition domain) | |
quantityRecieved | |
beginingBalance | |
quantityRecieved | |
quantityDispensed | Used for reporting: tells you what was dispensed over the last period |
stockInHand | |
calculatedOrderQuantity | calculated by the system |
totalLossesAndAdjustments | |
newPatientCount | |
stockoutDays | Used for reporting |
normalizedConsumption | |
previousNormalizedConsumption | |
periodNormalizedConsumption | |
AMC | |
price | |
expirationDate | |
previousStockInHand | |
(copied reference data) | if underlying data is mutable, take snapshot of values of these fields in this table |
dispensingUnit | |
maxMonthsOfStock | |
maxStockQuantity | |
dosesPerDispensingUnit | |
dosesPerMonth | |
packSize | |
roundToZero | |
packRoundingThreshold | |
fullSupply | |
reportingDays |
RequisitionAdviceStrategy(Facility, Program, ProcessingPeriod, RequisitionTemplate) → Requisition
Will want to take some fields in these tables and put it into extensions, either through a JSON extradata field or attribute type and attribute tables, or something similar.
id | |
code | |
name | |
description | |
active | |
processes | NEW, workflows in a particular program, ex: vaccine program might use requisition process at higher level, but allocation process at lower level |
createdby | |
createddate | |
modifiedby | |
modifieddate | |
implementations should handle these via attributes or json extradata field | |
enableivdform | |
isequipmentconfigured |
push? | column to determine if requisition, allocation, etc. is turned on |
budgetingapplies | |
usepriceschedule | |
sendfeed | |
hideskippedproducts | |
shownonfullsupplytab | |
enableskipperiod |
id | |
code | |
name | |
description | |
geographiczoneid | |
typeid | |
catchmentpopulation | possibly might want to move this out to an extension |
operatedbyid | |
active | |
golivedate | |
godowndate | |
comment | |
enabled | |
location | has location related attributes (mainphone, fax, address, lat, long, altitude, etc.) |
createdby | |
createddate | |
modifiedby | |
modifieddate | |
implementations should handle these via attributes or json extradata field | |
gln | |
coldstoragegrosscapacity | |
coldstoragenetcapacity | |
online | |
satellite | |
pricescheduleid | |
haselectricity | |
haselectronicdar | |
suppliesothers | |
sdp | |
haselectronicscc | this one should probably move into inventory management context |
facility ftp details |
facility_demographic_estimates; demography as another domain?
facility_mappings; support mapping to DHIS2 facility code somehow (ELMIS)
mos_adjustment_facilities, order_quantity_adjustment_products; ???
id | |
code | |
name | |
description | |
displayorder | |
active | |
createddate | |
createdby | |
modifiedby | |
modifieddate | |
implementations should handle these via attributes or json extradata field | |
nominalmaxmonth | |
nominaleop |
Note: consider an alternate model of facility capabilities, instead or in addition to facility type
id | |
code | |
name | |
description | |
displayorder | |
createddate | |
createdby | |
modifiedby | |
modifieddate |
id | |
facility | |
program | |
startdate | |
active | |
standard audit fields |
id | |
code | |
name | |
description | |
standard audit fields |
id | |
processingSchedule | |
name | |
description | |
startdate | |
enddate | |
numberofmonths | is this needed? |
standard audit fields |
TODO: Get rid of period short name and include as a field in Processing Period?
Is this a sub-resource of Processing Schedule?
TODO: consider along with other things that deal with hierarchy and supervision
Requisition Groups and Members
Supply Lines
Geographic Zones and Levels
id | |
username | |
password | |
firstname | |
lastname | |
restrictlogin | does this duplicate active? |
primarynotificationmethod | consider pulling all notification into its own domain |
officephone | consider pulling all notification into its own domain |
cellphone | consider pulling all notification into its own domain |
consider pulling all notification into its own domain | |
supervisorid | |
facilityid | |
verified | |
active | |
preferences | user-specific preference settings |
roleAssignments | consider pulling some of this functionality out into a supervisions domain |
implementations should handle these via attributes or json extradata field | |
employeeid | |
jobtitle | |
ismobileuser |
user_password_reset_tokens
Not all of these may be domain models
Its own context or under Fulfillment context? Currently mentioned under fulfillment
Can we merge fulfillment_role_assignments into role_assignments?