Design of Alert, dividing logic between front/back end

[John Stoecker]

Hi all! I'm designing a data model for an alert to show up for various providers. 

Alerts will show up in most modules, such as if pharmacy stock is low, or emergency patient is assigned to a doctor, or pharmacist needs a doctor to approve a prescription, etc.

The alert will have various data such as:

-patient

-sender (provider)

-recipient (provider)

-time

-type of alert (lab/screener/etc)

-concept

-obs

-encounter

-default task to appear (approve prescription, allow access to patient file, etc)

------

However, I am debating on how to divide logic between front and back end.

1. I could have new models for AlertType and AlertTask (more work in back end)

OR

2. I could have these fields as simple strings, and in the front end do logic such as (IF AlertTask==="approvePrescription") THEN do something

My inclination is to do more logical work in the front end, and just using OpenMRS back end as a conduit for the messages.

What do you think?

Any input on this is appreciated,

thanks,

-john

[Joy M.]

Maybe doing most of the logic in the frontend will allow it to be more flexible over different modules (ie, CHW)

Does OpenMRS allow for sending of SMS in case of no internet connectivity?

2012/7/4 John Stoecker <johnst...@gmail.com>

[r.fri...@mindspring.com]

It seems like you are using "alert" in two different senses.  One sense is the detection of a notifiable condition; this is clearly not a problem in the case where one person is "alerting" another to something.  The other sense is the notification that the condition has occurred; this can be within modules that display the patient record, or by transmission of an electronic message (SMS, e-mail, REST POST to an external system, etc.).

With respect to the first part, OpenMRS does not have an event bus, the underlying raw events need to be caught by AOP around the save methods.  You could take a look at the new Event Module that Ben Wolfe made, that does incorporate a standard event management component.  You could also take a look at the Patient Flags module.  It seems that some (e.g. Pharmacy) could be done as scheduled runs of a report (drugs below reorder point or approaching expiration) whose output would be stored in a known location.

With respect to the second part, take a look at the messaging module.

Saludos, Roger