I promised @moshon that I would share this with the wider community here. On last week’s TAC call, Ken shared this work that @Intellisoft has started with their customers for BotswanaEMR: a Discussion Board Feature.
Purpose and expected functionalities of the feature
Provided capabilities for nurses/medical practitioner to consult on cases they need assistance on.
Expected features:
Ability to search and add doctors associated with the facility to a case.
Ability to see if the associated doctors are online of offline.
Ability to send notification to invited doctors and for the doctor to respond on the notification.
Ability to stop adding doctors to a case.
Ability to add a file to the discussion(audio, video and image).
Current achievement/state
Ability for two medical practitioners to converse on a case as long as they are logged on and viewing the same patient file.
Technical Challenges Encountered
Implemented a web socket based on the Spring WebSocket API and the STOMP messaging protocol. However, while the code compiles correctly, it fails at runtime.
It appears that the module classloader loads an additional copy of the Jackson library, besides the one loaded by the container’s (Tomcat) classloader.
These features have been pre-defined by the client, who have their own designs around how the UI will look. But Ken’s and Burke’s point to the TAC was that if the backend is modelled properly, should be able to use for generic messaging as well (non-patient-specific, eg. “Hey are you working in X clinic today?”).
Thanks @grace for stepping in on behalf of the devs here.
It sounds interesting to me, at least as the core of such a provider-provider feature, for the EMR to
notify the user that “other practitioners have had encounters with this patient”
offer the user to browse those other practitioners
let the user IM with those practitioners
I really wonder if that resonates with the clinicians out there,. Has this been seen in other EMR systems (I’m sure yes), and deemed useful? Attn: @akanter, @burke, @jdick, @jteich
I don’t know that I’d want to bake in the whole panel case management feature by default, but some of its core elements definitely sounds like a good idea.
@jdick frequently mentions this messaging feature as being one of the single most valuable features of the EMR system he uses in his own practice as an Internist.
@akhilmalhotra have you also experienced provider-provider messaging within an EMR context? Curious to hear your thoughts too.
Back when I was working in patient care, messaging about patients was extremely taboo - our region just wasn’t fully in the digital age yet and shockingly pagers, phonecalls & faxes was the recommended comm’s method. But in practice most physicians just used iMessage. I’ve seen similar practices in shadowing where many providers & support staff in clinics are using WhatsApp or Email to rapidly communicate & collaborate on patient care plans, share attachments, etc.
I’ve come across the exact same use case actually with one of our projects where WhatsApp was used by default. This is problematic for data protection reasons and because those provider-provider exchanges end up outside the medical records.
And this is where doing this right becomes hard. In Ozone such a feature would fall into the wider telehealth topic and the approach would be to integrate a suitable open-source instant messenger solution (à la Rocket.Chat), by potentially embedding some of its UI within the O3 UX, or not. We would definitely refrain to go anywhere near to developing elements of an IM ourselves, it’s all about not building it.
Our hospital replaced pagers with the EMR messaging system. The messaging is commonly used to notify inpatient teams (e.g., helping keep all team members aware & simplifying communication when someone has the day off), reach providers for urgent issues (paging), and in clinic to reach a provider while she is with a patient. It’s also used commonly for personal communications (e.g., join us for pizza in team room) because everyone is already using it for clinical communication and you don’t need to know everyone’s phone number.
While people can choose to use WhatsApp, SMS, etc., it’s preferable to keep patient information secure and, if there’s a mobile friendly app or web app where you don’t have to separately maintain contact lists and can seamlessly connect to patient charts, people will begin to favor its usage.
As far as design goes, if we build a messaging system with the ability to optionally attach a patient or a topic/case, it will be far more useful than a messaging system that assumes it’s only used for case discussion.
