One app for the patient side of the practice

A patient who wants to see a lab result, ask their doctor a question, request an appointment and pay a bill should not need four tools to do it. For RXNT, a US healthcare software company, Toobler engineered the mobile app that brings those together for patients: health records, appointments, billing and secure messaging with providers, in one Flutter codebase, developed and maintained over three years.

Customer and context

RXNT builds software for medical practices. The patient app is the practice’s front door on a patient’s phone: the place a patient signs in to see their records, manage appointments, settle bills and message the people treating them.

Toobler was the engineering team on the app from late 2020 to late 2023, building it module by module and then keeping it current: new features, platform updates, accessibility work and testing as the product matured.

The challenge

A patient app looks like a set of screens. Most of the difficulty sits underneath them.

• The domain is record-heavy. Documents, lab results, health history, allergies, medications and the continuity-of-care record are different kinds of data, each with its own structure, and patients expect to find and use all of them in one place.
• Health records have to leave the app on the patient’s terms. A patient needs to send their care record to another provider or keep their own copy, not just read it on screen.
• Booking care is a request, not a calendar entry. The right appointment depends on the location, the provider and the visit type, and the request has to carry enough for the practice to act on.
• Messaging a clinician has to be dependable. A message that silently fails to send, or an inbox that shows a stale state, erodes trust in the whole product.
• A healthcare app is never finished. Mobile platforms change, sign-in expectations change, accessibility matters, and every release has to keep working for patients who rely on it.

The solution

One codebase across the patient journey. The app is built in Flutter, covering onboarding and sign-in, health records, appointments, billing and messaging. Patients register, recover a forgotten username or password, manage their profile, and from 2021 sign in with their fingerprint.

Records patients can use, not just view. Documents and lab results are searchable. Patients complete consent and intake forms in the app, maintain their past, family and social history, and see allergies, medications and devices. The continuity-of-care document can be emailed, sent by direct email or downloaded, so the record travels with the patient. Medication lists can be downloaded too.

Appointment requests modeled as a real workflow. A patient chooses a location, a provider and an appointment type, proposes time slots (adding, editing and removing them), gives a reason, or asks for the first available slot, then sends the request. The app also handles confirming appointments, and patients can check in for an appointment from the app.

Secure messaging, engineered with care. Messaging with providers is the most fully engineered part of the app. It has inbox and sent views, compose with a searchable choice of doctor, sorting and filtering by message type, multi-select, marking messages complete or read, delete and reply, and an unread badge. Every operation — loading, sending, fetching doctors, marking read, deleting — has its own error handling, built on a clear separation of events, state and data access using the BLoC pattern. Every messaging screen also has a dedicated tablet layout.

Billing in the same place. Patients see statements, make payments, pay a bill, and add or manage payment methods without leaving the app.

Keeping a healthcare app current

The second half of the engagement was the work that keeps a patient app trustworthy over time:

• an accessibility pass across the Flutter app;
• integration tests alongside unit tests, and cloud device testing on BrowserStack to check behavior across real devices;
• feature flags with LaunchDarkly, so features could be enabled deliberately rather than shipped all at once;
• push notifications with patient preferences, an activity log, and linked people on an account;
• platform and dependency upgrades, a move to a newer sign-in API, and a migration of the appointments module’s state management to Provider, with its unit tests updated to match.

A key workflow: requesting an appointment

1. The patient opens appointments and starts a request.
2. They choose a location; the app loads the providers and appointment types available there.
3. They pick a provider and a visit type, then add one or more preferred time slots, adjusting or removing them as needed, or ask for the first available.
4. They add a reason for the visit and send the request.
5. Once the appointment is confirmed, the patient can check in for it from the app.

Each step is its own state in the app, so a failure to load locations or send the request is reported clearly to the patient instead of leaving the screen in an unknown state.

Results

RXNT’s patients have a single mobile app for the patient side of their care: records they can search and share, appointment requests that reflect how practices actually schedule, bills they can pay, and secure messaging with their providers.

For Toobler, the engagement shows sustained product engineering in a regulated, record-heavy domain: three years of building and then maintaining a patient-facing app, with accessibility, testing and platform upkeep treated as part of the work rather than an afterthought. Toobler’s relationship with RXNT continues; the team also builds automated regression testing for RXNT’s practice-management applications.