Differences

This shows you the differences between two versions of the page.

--- en:dev:modules:notifications [2021/04/01 16:18] – [Links] remove draft nerdoc
+++ en:dev:modules:notifications [2021/04/01 16:21] (current) – add draft again nerdoc
@@ Line 4: / Line 4: @@
 ==== Description ====
-The module should provide a central API for alerts. Alerts should be placed at always the same positions in the visible area, to ease the recognition.
+See [[en:dev:module:notifications:draft|Draft]]
-What should be on top of all considerations and implementation is **Usability**. Don't bug the user. Stay out of his way as far as possible, but block him when critical problems occur (possible data loss, fatal medical decisions, etc.)
-//"Unless we improve medication alerts so they contain information that users need to make decisions, the problem of alert fatigue will grow as (electronic medical record) systems expand beyond single hospitals and share more data."//
-[[http://www.medpagetoday.com/PracticeManagement/InformationTechnology/32006| MedPage Today: Alissa Russ]]
-There should be different alert modes:
-  * //blocking// alerts
-  * //non-blocking// alerts
-The urgency of alerts should be three levels IMHO. More than three levels seem to confuse the user. We are used to 3 levels in many systems and can easily and automatically cope with that (e.g. traffic light)
-  * Error
-  * Warning
-  * Information
-==== Blocking alerts ====
-should "stop" the user in his workflow and urge him to take an action. This action can depend on the urgency or type of the alert.
-Examples are:
-  * Choose between options ('Really delete this? Can't be undone! ''Yes''/''No'')
-  * Postpone the alert (stays in the visual field, but work can continue, //remind me later//)
-  * Override the alert ("I know this is wrong, but I //want// it that way. I know what I'm doing.")
-  * Click on ''Ok'' (Use //very// sparsely! This is the typical usability pitfall)
-==== Non-blocking alerts ====
-These alerts must NOT interfere with the continuiation of the user's workflow. No Popups, no message- or confirmation boxes. They are just unobtrusive ways to inform the user that something **should** attract his attention. Examples are:
-  * A new update is available
-  * You can do this task more easily than you are doing it now.
-  * The backup process has ended **successfully**
-  * The backup process has ended **unsuccessfully** (user blocking is //not// indicated here)
-==== Considerations ====
-According to [[http://www.sciencedirect.com/science/article/pii/S1386505614000598|The effectiveness of computerized drug-lab alerts: A systematic review and meta-analysis]], there is very few good data about effectiveness of e.g. drug-drug-interaction alerts. Here are the highlights:
-  * There is no evidence that computerized drug lab alerts improve clinically important outcomes.
-  * Process outcomes are improved but without evidence of clinical benefit.
-  * No studies examined the cost effectiveness.
-  * Stronger evidence is needed prior to widespread implementation in electronic medical records.
-==== User stories ====
-* A patient arrives, and at the opening of his file, the assistent gets a "information" notice that a new doctor's letter had arrived from the Gynaecologist he was sent to. So the assistent can invite the patient to stay and discuss the findings with the doctor.
-* After having started a therapy with a certain drug where the liver enzymes have to be monitored on a regular basis, the doctor prescribes monthly control samples of blood: ALAT, ASAT, etc.
-The notice is shown after a month at file opening, and there is a generated "todo" list where the issue "control blood sample" is added starting with "today in 1 month".
 ==== Links ====
+  * [[en:dev:module:notifications:draft|Draft]]
   * [[en:dev:modules:notifications:spec|Specification]]
   * [[please-include-here-the-link-to-the-API|API]]
 {{tag>module stub}}