Do we have any way of supporting free-text notes or other pieces of information (such as a to-do list) that is attached to the patient rather than any particular encounter?
I guess if I were to start implementing something like that from scratch, I would create a frontend widget that stores its state in a free-text obs. It would always display the value of the most recent obs. Editing the note would create a new encounter and a new obs, not necessarily attached to any visit. This seems like a reasonable approach to me, and has the benefit of keeping a history record of who has made what edits.
Are you at any one time, interested in looking at the history of this? Or is it like a patient phone contact where you only care about its current value? And i guess you now see that iam tempted to suggest using person attributes.
We basically had exactly what you propose in O2, except without the overhead of an encounter. Obs don’t technically need to be attached to an encounter.
Yes! We’d really love to get the Sticky-Note implemented in O3! :
It’s heavily used for practical team communication by teams that use O2 (e.g. UgandaEMR sites on O2 use the sticky note a lot to share miscellaneous notes that are important to the rest of the team; I was amazed during in person visits by how helpful it was for intra-discipline comms, e.g. doc to social worker etc; or for ensuring better follow up at the next visit, e.g. “ensure ask about food need next visit” etc).
This is also a truly MVP way to get started on a care plan. Literally minimum viable but way better than nothing.
Designs
So we do have designs for it, we just haven’t had anyone with bandwidth/interest to implement it. I’d love to see this in the product!!
There are just 2 weaknesses in my mind, though I’m not sure they should stop us:
In O2, no saved history: When you edit the note in O2, the previous words are forever erased - but the fact that it was not logged nor had any saved history of edits didn’t seem to be a problem.
@slubwama@mmwanje is that a fair assessment, or did your users wish that the notes added to the sticky note could be saved somewhere?
@ddesimone@ball did you find your O2 system users wished the history was saved? I see in your Hum-demo environment the sticky note is not available; was there a concern about it?
I worry 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.
Technically, there is a complete saved history, it just isn’t surfaced in the UI in any meaningful way. The data itself is right there in the obs table.
The context of this is the MSF team interested in a simple patient-attached to-do, for example to facilitate staff rotations in IPD. So quite practical and not based on any rules or automations - like the CDS work that @samuel34 is working on would bring later.
@Grace Potma These notes are very important and should be saved somewhere for future reference. We can decide to clear them after a certain period if needed.
I am getting the feeling that these are actually two very different features:
Patient Notes is very simple and should be implemented on top of an obs, basically just like the 2.x version. If we want to add history-related features we can always do that.
Task List is a whole project, involving PlanDefinitions or ActivityDefinitions, maybe CarePlans, maybe Tasks also? Lots of backend work would be required. But it would advance the CDS project (if I’m not mistaken).
There is an option where we develop a Task List implementation that actually just stores JSON objects in text obs—a patient notes app with a fancy front-end and SerDe. But this would be a hack, not sure if it would be worthwhile.
Yeah, they’re two different features. I don’t really see why we wouldn’t (long-term) want both.
I’m a little less keen on a frontend-only task list backed by obs. While it’s technically feasible, since the backend treats obs as immutable, I think that design would pretty quickly pollute the obs table. 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).
Yes, I completely agree: Simple notes is different than full Task Lists. But we want both, and, simple notes get you a surprisingly long way towards the underlying basic goals behind tasks (true MVP; “bicycle instead of a full car” kind of thing). So I see simple notes as both a separate feature and a step in the right direction.
