Building A Secure Online Prescription & Patient Management A

A UK-based healthcare startup wanted a prescription management app that could run on tablets in clinics and also integrate with a physical medication dispensing unit. Think of it as an Office Vending machine for prescription drugs, but with proper security and compliance.

The app side was React Native (cross-platform, fast iteration). The hardware side? That's where we brought in our raspberry pi developers to build the dispensing controller.

## The Problem

Clinics were drowning in paper prescriptions. Patients lost them. Pharmacists misread handwriting. And the physical dispensing of medications in hospital wards was manual, error-prone, and slow. The client wanted:

- A secure patient portal for prescription requests

- A clinician dashboard for approvals

- A physical dispensing unit controlled by Raspberry Pi

- End-to-end encryption for patient data

- Offline capability (clinics lose internet sometimes)

We said yes, but only if we could do it properly.

## How It All Connects

The React Native app talks to a cloud backend (Node.js + PostgreSQL) for user management and prescription records. When a clinician approves a prescription, it gets pushed to the specific clinic's Raspberry Pi via MQTT over TLS.

The Pi stores the prescription locally in SQLite. When a patient arrives, they tap their NFC card on the reader. The Pi checks the local database, verifies the prescription is valid (time window, dosage, patient ID), then activates the correct stepper motor to release the medication packet.

If the internet is down? No problem. The Pi keeps working from the local database. When connectivity returns, it syncs dispensing logs back to the cloud.

## Security Decisions That Mattered

We didn't cut corners on security. Here's what we actually did:

**No cloud dependency for dispensing.** The Pi holds encrypted prescription data locally. Even if AWS goes down, patients get their meds.

**TLS 1.3 for all MQTT traffic.** Mosquitto configured with mutual TLS authentication. The app and the Pi both present certificates.

**AES-256-GCM for local storage.** SQLite database is encrypted at rest using SQLCipher. The encryption key is derived from the Pi's hardware serial number combined with a clinic-specific seed.

**NFC cards use ISO 14443-4 with encrypted sector keys.** We're not storing patient names on the card—just a random UUID that maps to the prescription database.

**Physical tamper detection.** A microswitch on the enclosure door triggers an alert if opened without authorization. The Pi logs the event and sends a push notification to the clinic admin.

## The Office Vending Machine Comparison

People ask why we used a Raspberry Pi instead of an industrial PLC. Two reasons:

1. **Cost.** A Raspberry Pi 4 costs $35. A comparable industrial controller is $300+. For a clinic network of 50 units, that's real money.

2. **Flexibility.** We needed WiFi, Bluetooth (for patient phone pairing), HDMI output, and GPIO for motors. The Pi gives us all of that on one board. No external modules needed.

The trade-off is reliability. Industrial PLCs are rated for 10+ years of continuous operation. The Pi isn't. But for a clinic environment with moderate usage (maybe 50-100 dispensing cycles per day), it's fine. We added the PiJuice UPS to handle power loss gracefully.

## Development Challenges We Actually Hit

**Stepper motor resonance.** The 28BYJ-48 motors are cheap and noisy. At certain speeds, they vibrate badly. We fixed this by using pigpio's hardware PWM instead of software PWM. Smoother movement, less noise.

**SQLite concurrency.** Multiple MQTT messages arriving at the same time caused database locking. We switched to WAL mode and used a simple queue system in Node.js. Each database write goes through a single-threaded queue.

**React Native BLE.** The original plan was to let patients authenticate via their phone over BLE. We built it, but it was too slow for real clinic flow. NFC was faster and more reliable. The BLE feature is still there as a backup.

**Touchscreen calibration.** The Waveshare screen needed manual calibration on first boot. We automated this in the setup script using xinput_calibrator and stored the calibration matrix in a config file.

## What We'd Do Differently

If we built this again, we'd use the Raspberry Pi 5 instead of Pi 4. The PCIe lane on Pi 5 would let us connect an NVMe SSD directly, giving us faster local database access and more reliable storage than microSD.

We'd also switch from MQTT to gRPC for the app-to-Pi communication. MQTT is great for IoT sensors, but for transactional operations like "dispense medication", the request-response pattern of gRPC fits better. We had to implement our own acknowledgment system on top of MQTT, which was messy.

## Final Thoughts

This project worked because we kept the hardware simple and the software secure. The Raspberry Pi handles the real-time motor control and sensor reading. React Native handles the user interface. MQTT bridges them together. No over-engineering, no unnecessary complexity.

The Office Vending machine analogy holds up. It's a box that dispenses things when the right credentials are presented. The difference is that this box has to be HIPAA-compliant, work offline, and never make a mistake with medication.

We shipped the first 10 prototypes in 8 weeks. The client is now rolling them out across 30 clinics in the UK. If you're thinking about building something similar—a secure dispensing system, a clinic management app, or anything that mixes React Native with embedded hardware—our raspberry pi developers have been through the trenches. We know where the sharp edges are.

**Got a project that needs both a mobile app and a physical device?** We build the firmware, the PCB, the enclosure, and the app. All in-house. We'll ship you a working prototype, not a PowerPoint.