PILLAR 01Implemented in Prototype
Daily Report Architecture
Create one structured record for the complete delivery day.
- Report date
- Driver identity
- Assigned vehicle
- Start odometer
- End odometer
- Total mileage
- Daily completion state
FEATURED CASE STUDY • FUNCTIONAL PROTOTYPE
Turning frontline medical-delivery experience into a practical accountability system.
Daily medical-delivery operations generate critical information across vehicles, mileage, packages, stops, delivery zones, returns, transfers, STAT requests, and unexpected route conditions. When that information is fragmented across memory, messages, paper notes, or disconnected reports, operational visibility becomes difficult for both drivers and administrators.
Med-DayLivery translates firsthand operational insight into a structured low-code prototype designed to make daily reporting clearer, more consistent, and more accountable.
Independently conceived and developed by Dulain F. Charles. The prototype was not commissioned, funded, sponsored, owned, or formally adopted by an employer or healthcare institution.
- Category
- Healthcare Logistics & Digital Product Design
- Maturity
- Functional Prototype
- Period
- 2026–Present
Abstract representation of the Med-DayLivery operational reporting system. Illustrative only.
Project Snapshot
Project snapshot
- Project
- Med-DayLivery
- Category
- Healthcare Logistics & Digital Product Design
- Maturity
- Functional Prototype
- Period
- 2026–Present
- Operational context
- Time-sensitive medical-delivery reporting and accountability.
- Development model
- Independently developed low-code prototype.
Primary users
- Medical-delivery drivers
- Operational administrators
Product purpose
Create one structured workflow for recording daily vehicle use, mileage, packages, stops, delivery zones, returns, transfers, STAT deliveries, exceptions, and administrative review.
Dulain’s contribution
- Operational observation
- Product concept
- Requirements definition
- Workflow architecture
- Interface direction
- Low-code development
- Functional testing
- Product refinement
The Operational Context
A delivery day produces more operational information than a final mileage total.
A driver may begin the day with one vehicle, a defined package count, multiple delivery zones, time-sensitive stops, and a planned route.
During the day, conditions may change. A vehicle may become unavailable. A replacement vehicle may be used. Packages may be delivered, returned, or transferred. A STAT request may be added. Mileage may need to be connected to more than one vehicle. The operational record must explain not only how the day ended, but how the work was completed.
01
Multiple accountability points
Mileage, packages, stops, zones, vehicles, and exceptions must reconcile within one daily record.
02
Time-sensitive operations
STAT requests and scheduled deliveries require clear status and execution tracking.
03
Changing field conditions
Vehicle problems, route changes, borrowed vehicles, package transfers, and partial continuation can alter the original plan.
04
Driver usability
The reporting workflow must remain practical for a driver completing the report after an operationally demanding day.
05
Administrative review
Administrators need consistent data that can be reviewed, compared, exported, and used for operational decisions.
The Challenge
How do you capture the complete delivery day without making reporting harder than the work itself?
A reporting system can fail in two opposite ways. It may collect too little information, leaving mileage, packages, vehicles, and exceptions difficult to reconcile. Or it may ask for so much information that drivers avoid, delay, or inconsistently complete the report.
The product challenge was to create a structured but practical balance between operational detail and real-world usability.
DIMENSION 01
Data completeness
Capture the operational information required to understand the day without creating unnecessary reporting burden.
DIMENSION 02
Reconciliation
Connect packages received, delivered, returned, transferred, and remaining outcomes within one accountable record.
DIMENSION 03
Vehicle and mileage accuracy
Associate mileage with the vehicle or vehicles actually used during the delivery day.
DIMENSION 04
Exception visibility
Document what changed, why it changed, and how the delivery work continued.
DIMENSION 05
Driver and administrator alignment
Create one reporting structure that is usable by the driver and meaningful to the administrator reviewing it.
The Product Response
One operational system connecting the driver’s day to administrative visibility.
Med-DayLivery was structured around the complete daily reporting lifecycle rather than one isolated function. The prototype connects day setup, vehicle information, mileage, package reconciliation, stops, zones, STAT activity, exceptions, submission, review, and export.
PILLAR 02Implemented in Prototype
Package Accountability
Track how packages move from receipt through delivery, return, or transfer.
- Boxes received
- Boxes delivered
- Boxes returned
- Boxes transferred
- Transfer notes
- Daily reconciliation
PILLAR 03Implemented in Prototype
Stops, Zones & Route Context
Record the operational structure of the route beyond mileage alone.
- Total stops
- Delivery zones
- Route context
- Operational notes
- Stop-level accountability logic
The verified prototype currently reconciles total stops with boxes received according to the existing reporting logic.
PILLAR 04Implemented in Prototype
STAT Delivery Workflow
Capture time-sensitive delivery requests and their completion status within the daily report.
- STAT address or destination context
- STAT status
- Completion tracking
- Administrative aggregation
- Export visibility
PILLAR 05Implemented in Prototype
Vehicle & Mileage Logic
Connect mileage to the vehicle used and support more accurate review of operational movement.
- Vehicle selection
- Start and end odometer
- Calculated mileage
- Vehicle records
- Mileage-based reporting
- Administrative review
A same-day multi-vehicle workflow is under Active Refinement to support drivers who begin the day with one vehicle and continue with a borrowed or replacement vehicle — with per-vehicle odometer ranges, per-vehicle mileage, a combined daily total, and documented reason for change.
PILLAR 06Implemented in Prototype
Administrative Visibility
Provide administrators with structured records, vehicle and driver management, reporting controls, and exportable operational information.
- Driver management
- Vehicle management
- Report review
- Weekly statistics
- Mileage and stop rates
- Export functions
- Aggregated STAT information
Driver Workflow
From vehicle assignment to a complete daily operational record.
The workflow represents the current prototype structure. It does not imply integration with a pharmacy, hospital, dispatch platform, or healthcare database.
- STAGE 01
Start the report
The driver opens or creates the report for the delivery date.
- STAGE 02
Confirm driver and vehicle
The report connects the delivery day to the responsible driver and assigned vehicle.
- STAGE 03
Record starting mileage
The starting odometer establishes the day’s mileage baseline.
- STAGE 04
Record packages received
The initial package count creates the reconciliation foundation.
- STAGE 05
Complete deliveries and route activity
The driver completes scheduled stops, delivery zones, and any added STAT activity.
- STAGE 06
Record returns, transfers, and exceptions
Undelivered packages, transferred boxes, vehicle problems, and operational changes are documented.
- STAGE 07
Record ending mileage and totals
The ending odometer and operational totals complete the daily record.
- STAGE 08
Submit for administrative review
The report becomes available for review, statistics, rates, and export.
Exception Design
A real operational system must explain what happened when the original plan changed.
The most valuable product requirements often emerge from unexpected field situations. Med-DayLivery treats exceptions as operational data rather than informal explanations added after the fact.
EXCEPTION 01
Active RefinementVehicle breakdown
Record that the assigned vehicle became unavailable during the route and document the operational consequence.
Product need
- Time or stage of interruption
- Vehicle involved
- Operational note
- Mileage completed before interruption
- Continuation status
EXCEPTION 02
Active RefinementBorrowed or replacement vehicle
Support the same driver continuing the delivery day with another vehicle.
Product need
- Second vehicle identification
- New start odometer
- New end odometer
- Per-vehicle mileage
- Combined daily mileage
- Reason for vehicle change
EXCEPTION 03
Implemented in PrototypePackage transfer
Document packages transferred to another driver or operational resource when the original route cannot continue as planned.
Product need
- Number of boxes transferred
- Transfer note
- Responsibility continuity
- Reconciliation with delivered and returned totals
EXCEPTION 04
Implemented in PrototypePartial route completion
Explain how much of the route was completed, what remained unresolved, and how the packages were ultimately handled.
Product need
- Completed stops
- Remaining work
- Returns or transfers
- Operational explanation
- Administrative review
Dulain’s Contribution
Frontline observation translated into product logic.
The product did not begin with a generic software template. It began with recurring operational questions observed during daily medical-delivery work. The contribution connected firsthand field experience with structured product development.
- 01
Operational Observation
Identified recurring reporting needs, accountability gaps, exception cases, and workflow conditions through direct delivery experience.
- 02
Problem Definition
Translated operational friction into clear product problems involving mileage, packages, stops, vehicles, STAT activity, and reporting consistency.
- 03
Requirements Architecture
Defined fields, rules, relationships, statuses, administrative needs, and exception scenarios.
- 04
Workflow & Interface Design
Structured the reporting sequence around the driver’s actual day and the administrator’s review needs.
- 05
Low-Code Development
Used low-code tools and database configuration to move the product from concept to functional prototype.
- 06
Testing & Refinement
Used real operational scenarios to identify limitations, test reporting logic, and guide continued product improvement.
Two Operational Perspectives
The driver records the day. The administrator needs to understand it.
Driver perspective
- A clear reporting sequence
- Practical field labels
- Minimal duplication
- Reliable calculations
- Exception notes
- Mobile usability
- Confidence that the report reflects the actual day
Administrator perspective
- Complete reports
- Consistent fields
- Driver and vehicle records
- Package reconciliation
- Mileage and stop visibility
- STAT aggregation
- Weekly statistics
- Exportable data
- Clear exception explanations
The product becomes useful when driver usability and administrative accountability reinforce each other.
Administrative System
Structured daily data supports review, comparison, and operational decision-making.
- Driver creation and management
- Vehicle creation and management
- Daily-report review
- Mileage-based rate configuration
- Stop-based rate configuration
- Weekly reporting statistics
- Report export
- STAT-delivery aggregation
- Vehicle and driver context
Administrative capabilities describe verified prototype functions. No fabricated analytics, weekly totals, driver records, or vehicle identifiers are shown.
Reporting Logic
Accountability depends on relationships between the fields — not simply collecting more data.
RULE 01
Mileage must connect to a vehicle
Distance without vehicle context creates incomplete operational information.
RULE 02
Packages must reconcile
Received, delivered, returned, and transferred boxes must form a coherent daily record.
RULE 03
Stops require operational context
Stops, zones, packages, and STAT activity should be understandable together.
RULE 04
Exceptions must remain visible
Vehicle changes, transfers, breakdowns, and partial completion should not disappear inside a general note.
RULE 05
Administrative data must remain reviewable
Reports should support comparison, rates, weekly review, and export without rewriting the driver’s information manually.
Reporting logic is operational, not legal, regulatory, medical, or billing-compliance in nature.
Privacy-Aware Design
Operational accountability does not require exposing sensitive healthcare information.
PRINCIPLE 01
Minimum necessary operational data
Collect only the information required for delivery reporting and accountability.
PRINCIPLE 02
No patient storytelling
The portfolio case study must not expose patient names, medical conditions, prescription details, or personal stories.
PRINCIPLE 03
Address protection
Real delivery addresses must not appear in public screenshots or evidence.
PRINCIPLE 04
Role-based operational access
Driver and administrator functions should remain separated according to operational responsibility.
PRINCIPLE 05
Evidence anonymization
Future screenshots must use redaction, anonymization, or approved demonstration data.
PRINCIPLE 06
Human review
Operational decisions and exception interpretation remain human responsibilities.
HIPAA compliance is not claimed. No HIPAA badge is displayed. Any regulatory conformance would require independent legal and technical assessment.
From Field Insight to Functional Prototype
The product developed through observation, translation, testing, and refinement.
- STAGE 01
Observe the operation
Identify recurring tasks, reporting friction, and accountability needs.
- STAGE 02
Define the product problem
Separate operational symptoms from the underlying workflow issue.
- STAGE 03
Structure the requirements
Define fields, users, relationships, rules, statuses, and exceptions.
- STAGE 04
Design the workflow
Organize the sequence around how drivers and administrators actually work.
- STAGE 05
Build the prototype
Translate the workflow into a functioning low-code product.
- STAGE 06
Test with operational scenarios
Use realistic reporting conditions and exception cases to identify weaknesses.
- STAGE 07
Refine continuously
Adjust logic, fields, interface behavior, and product architecture as new operational needs emerge.
Selected technologies
- Lovable
- Supabase
- Low-code product development
- Structured database logic
Presented as supporting tools. No endorsement or partnership with technology companies is implied.
Method in Practice
The product illustrates how frontline listening can become a structured digital response.
Med-DayLivery illustrates several dimensions of The Dulain Method™.
LISTEN
Observe the driver’s daily experience, reporting burden, exceptions, and accountability needs.
UNDERSTAND
Clarify how drivers, vehicles, packages, stops, mileage, STAT activity, and administrators connect.
ANALYZE
Identify workflow gaps, data relationships, exception scenarios, and administrative requirements.
ALIGN
Connect driver usability with administrative visibility and operational accountability.
DESIGN
Structure fields, rules, user roles, reporting sequence, and exception logic.
IMPLEMENT
Develop the low-code prototype and database-supported workflow.
STRENGTHEN
Refine reporting structures, admin tools, exports, and reusable product logic.
SUSTAIN
Create a foundation for continued product testing, workflow improvement, and future responsible deployment.
Current State
A functional prototype with implemented workflows and active refinement areas.
Implemented in prototype
- Driver daily reports
- Start and end odometer
- Mileage calculation
- Boxes received
- Boxes delivered
- Boxes returned
- Boxes transferred
- Transfer notes
- Total stops
- Delivery zones
- STAT delivery information and status
- Driver management
- Vehicle management
- Report review
- Weekly statistics
- Mileage and stop rates
- Report export
- STAT aggregation
Active refinement
- Multi-vehicle reporting within one delivery day
- Per-vehicle mileage segments
- Borrowed or replacement vehicle continuity
- Stronger exception architecture
- Continued responsive and usability refinement
- Product testing across additional operational scenarios
Med-DayLivery remains a Functional Prototype. It is not commercially launched, institutionally deployed, used by an employer, pharmacy, or hospital, connected to patient data, or certified for regulatory compliance.
Product Evidence
Connected prototype evidence, published without operational or healthcare data.
These interface views document the prototype’s reporting, accountability, and administrative architecture. All visible values are test data.
Prototype interface shown with test data.
digitalInterface evidence
Operational Analytics Dashboard
Administrative analytics dashboard designed to consolidate mileage, stops, box movements, returns, urgent deliveries, financial amounts, and operational trends.
Prototype interface shown with test data.
digitalInterface evidence
Driver Daily Reporting Workflow
Structured daily reporting workflow for capturing work date, vehicle use, zones, mileage, boxes, stops, transfers, tolls, operational notes, and final submission.
Prototype interface shown with test data.
digitalInterface evidence
Urgent / Special Delivery Workflow
Structured special-delivery workflow for capturing date, vehicle state, box and stop counts, mileage, pickup and delivery information, completion status, notes, and tolls.
Prototype interface shown with test data.
digitalInterface evidence
Daily Reports & Submission Accountability
Administrative report view supporting status tracking, mileage and stop accountability, delivered and returned box totals, toll review, export, locking, and controlled report reopening.
Prototype interface shown with test data.
digitalInterface evidence
Reporting & Export Architecture
Reporting and export layer supporting accounting, daily operations, payments, toll details, special deliveries, and operational reporting in PDF and spreadsheet formats.
Prototype interface shown with test data.
digitalInterface evidence
Driver Report History & Edit/Lock Logic
Driver-side report history showing draft versus locked states, report values, tolls, notes, and controlled editing behavior.
Prototype interface shown with test data.
Additional verified evidence may be connected after validation and publication approval.
Professional Value
Operational experience becomes product value when it is translated into structured systems.
Operational Analysis
Translating firsthand delivery observations into structured product requirements and reporting logic.
Digital Product Design
Designing a reporting workflow that serves both driver usability and administrative accountability.
Workflow Architecture
Sequencing daily reporting from vehicle assignment through submission for review.
Requirements Definition
Defining fields, relationships, statuses, exceptions, and administrative needs from operational reality.
Low-Code Development
Moving from concept to functional prototype using low-code tooling and structured database logic.
Systems Thinking
Connecting mileage, vehicles, packages, stops, STAT activity, and exceptions inside one coherent record.
Lessons
The strongest workflow requirements often appear when the normal process stops being normal.
LESSON 01
Frontline experience reveals hidden requirements
Daily operational work exposes reporting needs and exception scenarios that may not appear in a generic software specification.
LESSON 02
An exception is part of the workflow
Vehicle breakdowns, replacement vehicles, package transfers, and partial routes should be designed into the reporting system rather than treated as rare notes.
LESSON 03
Driver usability and admin visibility are connected
A report must be practical to complete and structured enough to support meaningful review.
LESSON 04
Data relationships matter more than field quantity
Mileage, vehicles, packages, stops, and exceptions become useful when their relationships are clearly defined.
LESSON 05
A functional prototype is a learning system
The value of the prototype includes its ability to reveal new requirements and guide increasingly accurate product decisions.
Related Pathways
Related professional pathways
Expertise
Explore the product, workflow, and systems capabilities behind the project.
Method
Understand the methodology connecting observation, analysis, design, implementation, and refinement.
Contact
Discuss an operational workflow or digital-product challenge.
From operational friction to product logic
Does an important workflow still depend on fragmented reports, memory, or workarounds?
Let’s examine the users, steps, data, exceptions, accountability needs, and implementation conditions — and translate them into a practical digital system.