Versions Compared

Version Old Version 1 New Version Current
Changes made by

John V Stoecker (Unlicensed)

John V Stoecker (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

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

Gliffy
nameDecision Support Back End

...

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

...

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:

...

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.