/
Sticky Note in O3

Sticky Note in O3

4 Must-Do’s

1. Problem Description: Have you clearly defined the user problem(s) you intend to solve, and what value this creates? Write down a story, user insight, or quote about this problem (this is important because (1) this will motivate your team, and (2) without this your problem might not actually be a big problem for the users themselves).
2. User Stories: Have you clearly written at least 3 user stories and use cases? 
3. Market Analysis: Have you surveyed what the market is doing here (e.g. comparison to other EMRs, or paper approaches; and don’t forget about learning from historic/existing OMRS instances)? Have you written down any possible gaps in your understanding of your users or their workflows? Have you reviewed the topic in FHIR to see what requirements or fields the global community references? (Eg if working on insurance, should look here)
4. Technical Considerations & Dependencies: Have you outlined what you need from cross-functional areas for success of the feature? E.g. do you need the platform to support a new API call? Have you explained how you’ve addressed dev concerns, such as designs that may not be feasible, or will be extra time-intensive to implement? 

Optional/Encouraged

Sketches: Have you added a drawing or description of how the feature could work to solve the problem at hand? (Pictures of sketches are ok!) 
Project Management: Have you created the Epic and JIRA tasks so you can share work clearly? Roll-out plan: Do you have an idea whether this will be an experiment, gradual roll out, and when? Have you added this to the timeline view? Have you planned how you will promote and/or work with communications folks in order to help this feature reach the widest audience and have the biggest impact it can?

Later but should do

QA Plan: Have you mentioned the plan for QA, such as how you will discover and address edge cases? Does your team/squad have a plan for automated tests to be added to new components (unit tests) or workflows (e2e tests)?
Safety & Tech Risks: Is there any reason you could regret rolling out this feature? (e.g. possible patient harm, heavy tech debt like introducing an unsupported library) Have you thought through the risks for this particular solution? And, how to reduce/address those? 

This checklist was inspired by this article. Additional Business Analyst Resources here.

Status: In Progress

Technical Complexity: Easy

Summary:

  • The “Sticky Note” was a popular feature in O2. We need this feature built in O3!

  • There are professional designs ready to use in order to build this feature.

image-20250913-013730.png
The sticky note designs for O3

1. Problem + User Stories

The “Sticky Note” was a popular feature in O2. We need this feature built in O3! The Sticky Note is heavily used for practical team communication by teams that use O2. It is very simple and not based on any rules or automation.

  • For Healthcare Workers:

    • Helps communicate with different types of staff, especially if they sit in a different office than you (e.g. Doctor vs Social Worker).

    • This is also a truly MVP way to get started on “care plans”. Literally minimum viable - because instead of having to build complex task-management, the simple Sticky Note gives different types of healthcare staff an easy way to tell each other what to remember about a patient.

image-20250913-015451.png
Images showing the Sticky Note feature and it’s workflow in O2.

  • 3 Examples of how Sticky Notes help Staff:

    • MSF Staff at a large surgical hospital are interested in a simple patient-attached to-do, for example to facilitate staff rotations in Inpatient Care (e.g. “Due for dressing change”; “family ready for discharge”, etc).

    • UgandaEMR sites on O2 use the sticky note a lot to share miscellaneous notes that are important to other team members: “I was amazed during in person visits by how helpful it was for intra-discipline communication, e.g. doctor to social worker etc; or for ensuring better follow up at the next visit, e.g. “ensure ask about food need next visit”, or “Note to the next Clinical Officer to see this patient” and more.” - Grace Potma, reflecting on site visits in Uganda).

    • Even if a Clinician sees the same patient at a later date, the clinician may have seen hundreds of other people since the last consultation. Notes can help the same clinician write notes to their future self! (e.g. “Remember to ask about any reactions to new drug”, or “due for tetanus shot soon” etc)

  • For Admins:

    • Admins need some way they could audit the history of these notes if needed. This is because these notes can contain very important info, so should be saved somewhere for future reference. Why: There are unfortunately cases where staff try to edit medical records with poor intent, e.g. in order to absolve them from responsibility when something goes wrong. In the event a staff member were to try to delete someone’s note in order to say “I was never told to do such-and-such”, this would be traceable by an admin.

2. Designs

Designs were created by professional designers and are available in Zeplin:

One issue you may notice is that the designs assume that there is a slot / space in the UI for flags and other types of warnings, as shown in the image below:

image-20250913-024716.png

For the purpose of getting this feature done promptly, please consider simply consider adding the Sticky note feature below “Actions”, as shown below. It can always be moved later once there is a slot/space established in the O3 UI for flags.

image-20250913-024847.png

3. Technical Considerations

  • Ensure there is a complete saved history like in O2: In O2, the data is stored in the obs table, even though past notes/edits are not shown in the UI. This is satisfactory because the complete saved history available in the obs table means the content is at least audit-able.

  • As a start, you can follow how Patient Notes (Sticky Note) were implemented in O2.

    • Could be implemented on top of an obs, basically just like the 2.x version. However: @Ian Bacher is less keen on a frontend-only task list backed by obs, because while it’s technically feasible, since the backend treats obs as immutable, that design would pretty quickly pollute the obs table. (Though for example METS suggested that “We can decide to clear them after a certain period if needed.”) (See the Talk thread here.)

    • There are other options, like storing things in a PersonAttribute or something that are less horrendous, but kind of limit what the task list can do (i.e., the tasks would be patient-centric and it would be hard to build a cross-patient task list). Talk to @Ian Bacher about how to store the data.

  • Icon Behavior. Grace worries that the O3 design is a bit too hidden, compared to how in-your-face the O2 UI is (if there’s an existing note). See the comparison images below, where you can see in O2 the note is blindingly obvious as soon as you open the patient chart (like a real sticky note on papers!); whereas in the O3 design a note with info in it just has an icon suggesting it be opened. One way to address this is to make sure that the red icon should stick around even if the user has opened it, so that providers sharing accounts can’t miss that there is a sticky note (sharing accounts is of course discouraged, but happens in the real world).