From a 90-Day Prescription to the Vitalis Drug Planner
The Vitalis Drug Planner began with an ordinary experience: receiving medication intended to last 90 days.
A prescription may state the medicine, quantity and directions, but a person still has to translate that information into daily life. How many doses are expected? When should the supply finish? What happens if a dose is recorded late? Which information came from the prescription, and which information was calculated by the planner?
That experience led to a product question:
Can a medication plan be made easier to understand without turning a planning tool into a prescriber?
The problem is not only remembering
Medication planning is often described as a reminder problem. Reminders can help, but they do not solve every source of confusion.
A useful plan may need to explain:
- The medication name exactly as entered
- The prescribed directions exactly as provided
- The planned start date
- The number of planned doses per day
- The expected number of days supplied
- The estimated finish date
- The remaining planned quantity
- Which doses were recorded as taken, skipped or unresolved
- Whether a value came from the user, prescription label or calculation
The distinction between source information and calculated information matters. A planning tool should not quietly rewrite clinical instructions.
What the Vitalis Drug Planner is intended to do
The Vitalis Drug Planner is being designed as a medication organization and explanation tool.
Its planned role is to help a person or authorized caregiver:
- Record medication-plan information
- Display the schedule in understandable language
- Calculate expected planning dates from entered information
- Track the plan's remaining quantity
- Record whether a planned action was completed
- Produce a clear history for review
- Identify missing or internally inconsistent plan information
Every calculated value should identify the inputs used to produce it.
What the planner must not do
The planner is not intended to independently decide what medicine a person should take.
It must not:
- Prescribe medication
- Change a prescribed dose
- Recommend starting or stopping treatment
- Replace a pharmacist or prescriber
- Determine that a missed dose should be taken
- Diagnose a medical condition
- Provide emergency instructions
- Present calculated dates as clinical authorization
When a plan is unclear or inconsistent, the safer response is to identify the uncertainty and direct the person to an appropriate pharmacist or licensed healthcare professional.
A transparent planning calculation
Consider a simple planning example:
- Quantity supplied: 180 tablets
- Entered plan: 2 tablets per day
- Start date: September 1
The planner can calculate an expected 90-day supply because:
180 tablets ÷ 2 tablets per day = 90 planned days
That calculation does not confirm that the entered instructions are medically correct. It only explains the arithmetic based on the information provided.
The interface should keep those two ideas separate:
- Source instruction: what the authorized medication information says
- Planning result: what the software calculated from entered values
Designing for understandable records
Medication histories can become difficult to interpret when they record only a check mark or notification dismissal.
The planner should instead preserve understandable events, such as:
- Planned dose created
- Reminder displayed
- Dose recorded as taken
- Dose recorded as skipped
- Entry corrected by an authorized user
- Plan paused pending clarification
- Medication plan completed or archived
Corrections should not silently erase previous records. An audit history can show what changed, when it changed and which authorized user made the change.
Privacy and offline operation
Medication information is sensitive. The early prototype should therefore minimize collection and operate with simulated information during development.
The planned architecture emphasizes:
- Local-first operation
- Encryption at rest
- Clear access roles
- Minimal data collection
- Explicit export and deletion controls
- Backup and recovery
- No advertising profiles
- No sale of medication information
Any future sharing feature must be deliberate, limited and visible to the person using the planner.
Prototype before clinical claims
The first prototype is intended to test planning logic and clarity, not clinical effectiveness.
Prototype questions include:
- Can a user enter a medication plan without confusion?
- Are calculated dates and quantities explained clearly?
- Can the system distinguish entered instructions from calculated results?
- Can a user correct an entry without losing the history?
- Does the interface identify uncertainty instead of inventing an answer?
- Can the plan be backed up and restored reliably?
The prototype will use representative, non-patient information until the required privacy, safety, legal and research controls are established.
Turning lived experience into a testable system
The 90-day prescription did not automatically define a product. It revealed a workflow that could be examined carefully.
The Vitalis Drug Planner is Mahlis's attempt to turn that workflow into a transparent planning system—one that helps people understand the information in front of them while respecting the boundary between software organization and professional healthcare judgment.
Explore the Vitalis Drug Planner or view its development path in the Mahlis roadmap.