@eudson, I’m sorry I didn’t know about the meeting yesterday. Thanks for the example. I would suggest some tweaks…
I would suggest we use URIs or URLs for order_template_type so we can include versioning and don’t have to manage a single namespace for all types. For example:
order_template_type: "org.openmrs.ordertemplatetype.drug/v1"
Dose and dose units should be separated. Ideally, we would evolve to use FHIR-compatible dosing (i.e., at least an approach that we can translate to/from FHIR). Until we’re ready to handle dose ranges, infusions, etc. and assuming we can infer dose unit terminology, I think this just means separating dose value and units. For example:
{ dose: "250", doseUnits: "mg" }
Where there are choices for an field, a template should be able to optionally specify which is default:
dose: [
{ dose: "250", doseUnits: "mg" },
{ dose: "500", doseUnits: "mg", default: true }
]
numberOfPills is not needed and doesn’t apply in many cases. When needed, “number of pills” can be calculated. For example, a dose of 250 mg for a drug that has a strength of 500 mg is dose/strength → 250/500 → 0.5 pills. Number of pills also unnecessary or doesn’t make sense if the dose is “1 tablet” or the drug order is for eye drops. Also, I don’t believe it translates to FHIR’s dose syntax.
Templates should include all the information to complete the order form, where order form schema varies by order type and (in the future) could be orderable-specific. For drug order forms, this would mean including dosage instruction type (simple dosing, free text, taper, etc.), which would determine the values for dosing instruction. Simple dosing would provide dose, route, frequency, prn+condition, additional instructions, while free text would just include instructions.
Simple Dosing example
{
concept_uuid:"aaaa",
order_template_type: "org.openmrs.ordertemplatetype.drug/v1",
order_template: {
drug_uuid: "bbb",
dosingInstructionsType: "org.openmrs.SimpleDosingInstructions",
dosingInstructions: {
dose: [
{ dose: "500", doseUnits: "mg" default: true },
{ dose: "250", doseUnits: "mg" }
],
route: "Oral",
frequency: "Once Daily",
additionalInstructions: "Take with full cup of water.",
asNeeded: true,
asNeededCondition: "pain"
}
}
}
Free text dosing example
{
concept_uuid:"aaaa",
order_template_type: "org.openmrs.ordertemplatetype.drug/v1",
order_template: {
drug_uuid: "bbb",
dosingInstructionsType: "org.openmrs.FreeTextDosingInstructions",
dosingInstructions: {
instructions: [
{ text: "Take 2 tablets by mouth once daily on odd numbered days", default: true },
{ text: "Take 2 tablets by mouth once daily on even numbered days" }
]
]
}
}
In these examples, we’re presuming that all of the literal (and human-friendly) strings for codified elements (route, frequency, units) are unambiguous exact matches to names of corresponding concepts. It feels hacky to leave the application to infer whether a string is a UUID or a name (e.g., “Tablet” vs. “1765BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB”), especially since many of CIEL’s UUIDs don’t adhere to the UUID specification. We don’t want “1765BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB” to show up as a dose unit option because the application because someone accidentally left off a “B”. 
Perhaps a simple string could be assumed to be a name lookup and UUID require an object. For example, the following three references would be equivalent (assuming there’s only dose unit with the exact name “Tablet”):
doseUnits: "Tablet"
doseUnits: { uuid: "1765BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB" }
doseUnits: {
name: "Tablet",
uuid: "1765BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"
}
Note, I’m also assuming we can easily discriminate between array & object when parsing JSON, so we can use the same property for both single & multiple choices:
dose: { dose: "500", doseUnits: "mg" }
dose: [
{ dose: "500", doseUnits: "mg" },
{ dose: "250", doseUnits: "mg" }
]
BTW, linking a template to a specific drug formulation (i.e., drug_uuid) could be optional. A template linked to a concept without naming a specific drug formulation would apply to any formulation(s) of that drug for which there aren’t any templates (effectively, a way of defining a default template for a drug by concept without having to assign it to each formulation).
, we used paracetamol as an example:
