The documentation says that if the units are unstructured, you can put them
in the inside '{ }' e.g '{my units}', so i plan to do both for units and
frequencies
Wyclif
On Wed, Aug 17, 2011 at 7:56 PM, Darius Jazayeri <[email protected]>wrote:
> Wyclif, does SMART allow unstructured frequencies?
>
> -Darius
>
>
> On Wed, Aug 17, 2011 at 4:42 PM, Burke Mamlin <[email protected]>wrote:
>
>> Wyclif,
>>
>> We should discuss dosing frequencies. Common frequencies would be:
>> daily, twice daily, three times daily, four times daily, every 4 hours,
>> every 6 hours, every 8 hours, every 12 hours – and perhaps for TB regimens –
>> once weekly, once monthly. There are many more possible.
>>
>> I wouldn't try to convert prior prescriptions into codified frequencies;
>> rather, use unstructured dosing for those (i.e., a single text field instead
>> of codified values for dose & frequency).
>>
>> -Burke
>>
>>
>> On Wed, Aug 17, 2011 at 5:29 PM, Wyclif Luyima <[email protected]>wrote:
>>
>>> Hi,
>>>
>>> Currently, in the API, we didn't enforce the format for values for the
>>> drugoOrder.frequency property, therefore there is a high chance to encounter
>>> values with invalid formats when creating a SmartMedication from a
>>> DrugOrder, if the existing value was entered in contrast to the OpenMRS
>>> suggested format which is to take one of the following 3 forms; 1/daily,
>>> 1/weekly and 1/monthly, then we need to take steps when converting it. Below
>>> is the proposed way to parse the existing values when converting from
>>> DrugOrder to SmartMedication;
>>>
>>> Create 3 constants to match weekly, daily and monthly and then parse the
>>> value of the frequency property to check if it ends with any of these and
>>> set the smartMedication.frequency property accordingly to match the Smart
>>> spec formats, if not we throw an exception telling the user that an invalid
>>> frequency was found and that the admin should fix it first.
>>>
>>> I will also go ahead to create a ticket for adding this enforcement into
>>> the orders API, we also need to have this added to the new order entry API.
>>>
>>> Wyclif
>>>
>>>
>>> ------------------------------
>>> Click here to
>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
>>> OpenMRS Developers' mailing list
>>
>>
>> ------------------------------
>> Click here to
>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
>> OpenMRS Developers' mailing list
>>
>
> ------------------------------
> Click here to
> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
> OpenMRS Developers' mailing list
>
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[email protected] with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
