Decision Support Module Goals

1. Create clinical decision support system with Arden rules in back end OpenMRS

2. Expose rules as REST calls (can create and get Arden rules)

3. Verify that Arden rules are run whenever data is modified

4. Send alert messages back the user based on Arden result. Use existing RaxaAlert service.

5. Create front end GUI to REST (GET and POST) in ExtJS

6. Create responses to Arden-generated alerts in the front end in Outpatient module.

Nice-to-haves:

7. Repository of rules

8. Arden in the front end (offline case)

9. Privacy constraints on rules ("Rules of rules")

10. Machine learning rules

Decision Support OpenMRS Module Architecture

Decision support should capture all REST calls and determine whether the input is valid. This can be done either:

At the REST layer, scraping calls for all resources (Preferred)
At the service layer, hooking into other service calls
At the database layer as SQL constraints

Determine where the existing Logic Module and org.openmrs.arden syntax does its validation currently in OpenMRS. Use existing Clinical Decision Support System progress as a starting point:

https://modules.openmrs.org/modules/view.jsp?module=dss (works with OpenMRS 1.7.x as per http://listarchives.openmrs.org/Clinical-decision-support-td7356724.html)

https://wiki.openmrs.org/display/docs/Clinical+Decision+Support

Where Does the Arden Rule Run? – triggered by any user call.

Responses to an Arden Rule Invalidation

The alerts should be as in-obtrusive as possible and not interrupt patient flow (unless Arden finds the rule breaking to be very severe/life threatening). In general, the alerts should show up in a small corner in the Outpatient module rather than a popup that requires the provider to click 'OK'.

Types of alerts:

--Informative: most rule invalidations should send this alert back. Appears as a small text field

--Overrideable: a more serious rule break incurs overrideable. Requires click from doctor (should avoid this as much as possible)

--Stop: does not allow data to be saved in the database. Only for life threatening rule breaks (should avoid this nearly always)

Note that this can be implemented by alertType member in the RaxaAlert data model.

Example Cases that Require Decision Support

The system should deal correctly with the following cases:

Example 1:

Patient X comes in diagnosed with congestive heart failure (linked to concept "Congestive Heart Failure"). Doctor D completes the Outpatient Encounter without creating a drug order containing a beta blocker (some set of drugs that are beta blockers, or also a drug_group called beta_blockers). Send a message back that says "X has congestive heart failure. Recommend beta blocker."

Example 2:

Patient X comes in, is prescribed with a NSAID drug such as ibuprofen. Patient has already been prescribed ACE inhibitor captopril. Send a message back that says "Drug <ibuprofen> interacts poorly with drug <captopril>. Recommend <different painkiller>."

Example 3:

Patient X comes in, is prescribed drug penicillin. Searching through the patient's obs is concept "ALLERGY" and the value is penicillin, or 'penicillin' is in any concept the has "ALLERGY" or "ALLERGIC" in the name. Send a message back that says "Patient is allergic to <penicillin>. Recommend <different antibiotic>."

Proposed Timeline

September 3: DSS module working in OpenMRS 1.7.x

September 10: have a working description of the work already done for Arden syntax and a plan for modifying existing code to our purposes

October 8: Arden is hooked into system at some level (database, service, or REST layer)

October 29: Can POST and GET Arden rules

November 12: Messages are sent back for the 3 example cases above

November 26: User is able to POST/GET Arden rules using front end ExtJS.

December 10: Responses to the 3 example cases above are implemented in Outpatient module. If Doctor clicks 'yes' to the suggestions, fields are automatically updated to new settings.

Browser not supported