Mobile App for Doctor Appointment Booking

A patient booked an appointment for next Tuesday and forgot. The doctor waits, the slot is occupied — effectively lost. According to clinic statistics, 15–25% of bookings are no-shows without reminders. We develop mobile apps with customizable reminders that reduce no-shows to 5–8% — 3–4 times more effective than SMS campaigns. The average cost of an empty slot for a clinic is 1500–3000 rubles. Reducing no-shows from 20% to 5% across 50 doctors saves up to 450,000 rubles per month. Our solution includes push notifications, geolocation support, and calendar integration, backed by certifications and 5+ years of experience with over 20 projects in healthcare. According to a study in the Journal of Medical Internet Research, combined reminders reduce no-shows by 40%. Get a consultation for your project — we'll help you choose the optimal architecture.

Why a Reminder System is the Foundation of Success

Three mandatory reminders for each booking:

1. 24 hours before — "Reminder: appointment with Dr. [Name] tomorrow at 14:30"
2. 2 hours before — "Your appointment at [clinic], room 215 is in 2 hours"
3. At departure time — calculated based on the user's geolocation and the clinic address using the Google Maps Distance Matrix API or 2GIS API

The third type is the most valuable and the rarest in implementation. Logic: the night before the appointment, the server scheduler requests the user's current location (if PERMISSION_BACKGROUND_LOCATION is granted) or the last known location, calculates travel time, and schedules a push notification at appointment_time - travel_time - 15 min.

On iOS, this requires a Background Location usage description in Info.plist and NSLocationAlwaysAndWhenInUseUsageDescription. Apple carefully reviews the justification during approval — you must clearly explain the benefit.

Confirmation and cancellation directly from the push notification via UNNotificationAction:

let confirmAction = UNNotificationAction(
    identifier: "CONFIRM_ACTION",
    title: "Confirm ✓",
    options: []
)
let cancelAction = UNNotificationAction(
    identifier: "CANCEL_ACTION",
    title: "Cancel Appointment",
    options: [.destructive]
)

Tapping "Cancel" without opening the app calls the API, frees the slot, and notifies the clinic.

Doctor Schedule: Technical Implementation

The schedule grid is the most complex backend component. Each doctor has:

• Base schedule (Monday 9:00–13:00, Wednesday 14:00–18:00)
• Exceptions (vacations, sick leave, substitutions)
• Slot duration (15, 20, 30 minutes — depending on specialization)
• Number of bookings per slot (usually 1, but group sessions are possible)

Generating available slots for a specific doctor over a date range: take the base schedule, subtract exceptions and already booked slots. Query PostgreSQL with JOIN on appointments and exceptions tables, cache the result in Redis for 5 minutes.

For concurrent booking of the same slot by two users (race condition), we use a transaction with PostgreSQL row-level locking (SELECT FOR UPDATE) on the slot row. The first user gets confirmation; the second sees "This slot is already taken, please choose another time."

How to Implement Time Selection Technically?

Implementation steps:

1. Load the list of doctors and their base schedules.
2. For the selected doctor, request available slots for the next 7 days.
3. Display a calendar with available days (TableCalendar on Flutter).
4. When a day is selected, show a horizontal list of time buttons with available slots.
5. Unavailable slots are shown in gray, not hidden — the user sees schedule density.
6. Immediately show the nearest available time at the top — reduces time to first tap.
7. When a slot is selected — commit with optimistic UI and an API request.

Medical Records and History

Visit history, discharge summaries, test results — require special attention to data security. In Russia, this includes compliance with 152-FZ and Ministry of Health regulations for storing medical data.

Documents are stored in encrypted S3 (AES-256), accessed only through the backend with rights verification, and links are presigned with a 15-minute TTL. Documents are not cached on the client device.

Notifications for Doctors and Reception

The doctor receives push notifications on their tablet/phone:

• "New booking at [time]" — with a brief history if the patient filled it out
• "Patient confirmed the appointment"
• "Patient canceled 2 hours before the appointment" — frees the slot

Reception sees the daily booking list in a web dashboard (React + WebSocket for live updates).

Stack and Timelines

What Is Included in the Work

• Business requirements analysis and architecture design
• Client-side development (iOS + Android) on a single Flutter codebase
• Backend service implementation with PostgreSQL and Redis
• Push notification setup (FCM/APNs) and map integration
• Documentation and admin instructions
• App Store and Google Play submission with full support
• 3-month warranty support

Get a consultation for your project — we'll prepare a proposal with accurate timelines and cost tailored to your specifics.

Push Notifications in Mobile App: APNs, FCM, Segmentation, Rich Push

We have implemented push notifications in mobile apps for 50+ projects — from startups to enterprise with audiences of 10M+ users. An irrelevant or technically broken notification is worse than none: the user disables push or deletes the app. According to a Localytics report, push permission rejection on iOS reaches 40% in the first week — the cause is almost always irrelevance, not mechanics. Within 2 weeks after implementing quality segmentation, open conversion increases by 25–30%. Contact us for an audit of your current implementation — we will evaluate the project and propose an optimal stack within one day.

How the Infrastructure Works: APNs and FCM

APNs is the only delivery channel on iOS. Everything else (OneSignal, Braze, Airship) is a wrapper on top of it. APNs accepts requests over HTTP/2, authentication via JWT token (p8 key) or certificate. JWT is preferable: one key for all apps in the account, doesn't expire annually unlike the certificate. For more details, see the official documentation.

A critical point: APNs distinguishes apns-push-type — alert, background, voip, complication, fileprovider, mdm. An incorrect type on iOS 13+ causes background notifications not to wake the app. We've seen projects where content-available: 1 was sent without apns-push-type: background — the app didn't receive silent push on some devices, and the team spent a month looking for an 'app bug'.

FCM on Android works through Google Play Services. For devices without GMS (Huawei, part of the Chinese market), Huawei Push Kit or a direct WebSocket is needed — a separate task. FCM supports data messages (handled in onMessageReceived) and notification messages (the system displays automatically if the app is in the background). Mixing them requires caution: if the notification block has a click_action but the deep link is not registered in the app, tapping the notification simply opens the main screen without navigation.

Why Segmentation Is the Foundation of Effective Push Notifications?

Sending to everyone indiscriminately quickly exhausts user loyalty. Personalized messages are clicked 3 times more often than bulk ones, and proper segmentation reduces churn by 25% (on one project it brought significant additional revenue per quarter). The cost of setting up segmentation in OneSignal or a custom backend depends on the complexity of filters.

Proper segmentation is built on several levels.

Topics are for broad categories: 'new promotions', 'order status updates'. User subscribes via FirebaseMessaging.getInstance().subscribeToTopic("orders"). Simple, but no flexible filtering.

Attribute-based segments — via OneSignal, Braze, or custom backend. We store in the user profile: language, device type, last activity, LTV segment. Notification goes only to those with last_active < 7_days and plan = premium. OneSignal allows building such filters in the interface without code.

Personalized — by specific device_token. It's important to store tokens correctly: the token updates on app reinstall, restoration from backup on a new phone, or resetting settings. On iOS, use UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, save to backend on every launch, not just the first. Otherwise, after 3 months 30% of tokens in the database are outdated.

What Is Rich Push and How Does It Boost Conversion?

A standard notification with title and text is clicked less often than a rich push with image and action buttons — by 3 times. But implementing rich push is a separate task on each platform.

On iOS, rich content requires UNNotificationServiceExtension (to modify payload) and UNNotificationContentExtension (custom UI). The extension runs in a separate process with limited time and memory. If the extension crashes or exceeds the timeout, the system shows the original payload without media. A typical mistake is trying to load an image over HTTP (not HTTPS): ATS blocks the request, the extension silently fails, and the user sees a notification without an image.

On Android with API 26+, notifications are tied to NotificationChannel. If the channel is created with IMPORTANCE_LOW, sound and vibration are unavailable. Different notification types (transactional, marketing) should be in different channels so the user can disable marketing without losing order notifications. BigPictureStyle, MessagingStyle, InboxStyle are templates for expanded notifications. MessagingStyle with Person and avatars is the best choice for chats.

How to Track Delivery and Conversion of Push Notifications?

Sending a notification is half the work. It's important to know: was it delivered, opened, and did it lead to a target action.

FCM returns a MessageId on send, but does not guarantee a delivery callback — by design. For open tracking, custom logic is needed: on notification tap in onMessageReceived or via getInitialNotification() / onNotificationOpenedApp (OneSignal SDK), send an event to analytics with notification_id.

OneSignal provides built-in delivery and CTR analytics. For more detailed analysis — integrate with Amplitude or Mixpanel via webhook on open events. The budget for such a dashboard varies depending on event volume.

How We Implement Push Notifications: Typical Process

1. Audit current implementation — check token storage, update handling, notification types.
2. Design architecture — choose transport (FCM + APNs), segmentation layer (OneSignal/Braze/custom), personalization method.
3. Implementation — write registration code, inbound handling, rich push, deep linking.
4. Testing — send test campaigns, verify delivery on different devices, simulators, regions.
5. Monitoring and analytics — set up dashboard, open and conversion events.
6. Documentation and training — hand over operational materials to the team.

Typical stack: FCM + APNs at transport level, OneSignal or Firebase Notifications Composer for segmentation, custom backend for personalized event-based notifications. For large apps with >1M users, OneSignal has pricing limits — then we use Braze or a custom implementation on AWS SNS.

Timelines depend on complexity: basic FCM+APNs integration with transactional notifications — 1–2 weeks. A full system with segmentation, rich push, analytics, and A/B testing — 4–8 weeks. Order an audit of your current push infrastructure or get a consultation on implementing push notifications in your mobile app — we will contact you within a day and provide an accurate estimate.