Medicinia
Medicinia is a startup that develops health technology solutions focused on human, safe, and structured communication between healthcare teams and professionals and their patients.
Special Patient Monitorings
The Special Patient Monitoring team (MOPE) is a nursing team dedicated to remotely monitoring the health of São Cristóvão Saúde patients.
The Special Patient Monitoring team needs to increase the number of patients monitored using a digital solution as a way to expand and enhance its reach, capacity and quality of care.
Enable the monitoring team to monitor the health of patients who have little or no time available for a traditional monitoring approach.
The MVP would be restricted to very high-risk hypertensive patients.
The MVP would involve patients who already use smartphones on a daily basis.
To define which indicators and frequency of measurements necessary for monitoring, the Hypertension Protocol of the Brazilian Society of Cardiology.
To begin the research process and understanding the problem,
Thus, the main points explored during the exploratory conversations were:
Talking to the monitoring team was extremely important for a greater understanding and deepening of the problem
During the research process, an analysis of the hypertension protocol used as a reference was carried out to better define the events and health indicators that would be monitored.
The result of this analysis can be summarized as:
Considering the type of information, the relevance and especially the frequency of the indicators to be monitored,
Chat
Alerts
Tasks
Information
Phone calls
In this way, it was possible to guarantee that the patient would receive or send their health information always using the most appropriate channel so that the nurse and the system could then react/act on the data sent.
Examples of Channels x Health Indicators
Evolving in the solution proposal, several subflows were defined to monitor each indicator to be observed. The union of all these subflows makes up the main organizational structure and functioning of the system.
Patient Tracking - Overview
Example of subflow for query using different channels
The number of indicators requested and information/explanations for patients were extremely relevant to ensure adherence to monitoring. In this way, it was decided to
Example of how patient-related events were distributed throughout the onboarding period
With this approach it was possible to achieve some benefits:
For the MVP to be successful, it was essential that the monitoring team had
Thus, some information and "triggers" were created to give the nurse, throughout the monitoring period, a vision
Example sequence of events for a critical Blood Pressure alert for a nurse
Taking advantage of the existing chat between the monitoring team (nurse) and patients, it was decided to bring together communication and the most recent patient data in the same interface, thus facilitating the
Simplification of the chat developed for nurses to maintain contact with the patient in the application
Once the structuring of data, information flow, channels and points of communication between the monitoring team and patients were defined and planned, we moved on to the phase of translating these decisions into mocks, flows and screens.
Below you can see some low-fidelity examples that were produced in the initial phases of designing the solution.
Some wireframes below of the screens to be developed for patients
One of the most important points for all monitoring was how the task structure (blood pressure, medications, weight, appointments, etc.) would fit into the standard and pre-existing structure of the app.
A part of this framework can be seen in the flow below:
Simplifying one of the patient app navigation flows
Briefly, we can divide the developed solution into two parts:
1. Tools available to the monitoring team
(such as chat, alerts for high or low blood pressure levels, weight, etc.).
2. App for patients
(also with chat, tasks, alerts, reminders and educational information).
The different subflows for the different situations and monitored indicators are executed with events and data entry between patients and nurses.
The storage of this data and its use, whether by the system after receiving a critical value or by the nurse acting with a qualitative analysis of what they receive, end up constituting a macro flow that is largely responsible for monitoring and monitoring the health of patients.
Summary of the solution developed for the MVP
After starting the MVP with 10 previously selected patients, the tests would continue by analyzing the use of available tools (chat, alerts, tasks, forms, etc.) to verify in loco and with direct feedbackfrom patients and professionals - through interviews and analysis of usage sessions - on the effectiveness of each flow and subflow designed and the effectiveness of each channel and its routines.
My participation in the project ended before the start of this new cycle...
A very important decision to facilitate the project's feedback loops was the option to develop the patient screens in the app in a web view and not directly in the application.
This way, the team could be faster and more assertive to respond to any identified improvements, avoiding the need for a new deployment in the stores.
I participated in the design of the backend structure/modeling to be developed for the project, highlighting the importance (and managing to collaborate for this) of the structure being generic enough to respond quickly to future changes and adjustments.
The first internal tests with the monitoring team acting as test patients had a strong manual component in their execution. Thus, alerts and tasks were sent without any automation (code development) to these users.
This solution development strategy proved to be essential for a better understanding and refinement of the product (both backend and front-end and UX/design ) to be built.