Role Based Messaging
Customer Request: Send messages to a role rather than an individual.
Customer Name(s):
Lead Hospitalist at Oklahoma University Medical Center
Ryan Endress of Vocera when speaking with potential customers
Tufts physicians
Northwestern
University of Maryland
Rationale:
Stated as common functionality within medical systems
Continuity of patient care during provider changes
Nurses who have multiple roles within the system i.e. ICU nurse who is on the rapid response team
Initial Problem Hypothesis:
Clear and complete transfer of information between providers whenever a transfer of patient care responsibilities is required, commonly known as a hand-off.
Further Work:
-
Validate problem hypothesis
connect to customers who have requested this
ask questions to further understand the unmet need
-
Mock-up possible solutions (assuming current problem hypothesis is correct) including:
Role based communications
Hand-off or sign-out reports
Explore potential connections with existing Clinical Documentation initiative
-
Mark Lichman
- Mar 17 2019
Related ideas
Please note that the idea as stated potentially raises some serious security concerns. Regardless of the write-up, this may raise the same concerns stated by Cathey Kilner below.
Commenting on behalf Cathey Kilner from a separate email thread on this topic:
"The way these stories read to me I have privacy concerns. There is an expectation as a user that a conversation I send is private between myself and the recipient(s). If I am a specialist contacting another specialist and I link a patient so that other party has the context, I would not want any random person on the care team to be able to access that conversation just because it was linked to a patient. I would not feel comfortable using the solution. An event history of alarms related to the patient has value as it allows me to better understand what has transpired before my shift. The actual role based conversation request where the message is addressed to the role and the role is what is maintained as the recipient, versus the resolved user name(s), is a lot easier to understand as a user as to why individuals are joining and leaving the conversation and why it is visible to others who are now fulfilling the role."
This customer request is stated in the form of a solution, sending messages to a role rather than an individual. Further work should be conducted to understand the problems addressed by this solution. Based on the rationale summarized above a hypothesis can be formed on the problems this proposed solution is addressing and has been included within the idea write-up as the Initial Problem hypothesis.