A dental practice app is mostly a decision about what reaches the phone.

Treatment notes and x rays are PHI, and the handset is where that bites

A practice that sends claims electronically is a covered entity under 45 CFR 160.103, and what it creates about a named patient's care is protected health information. That includes the parts nobody thinks of as records: the bitewing series, the intraoral photo, the probing depths, the note saying a patient is anxious about needles. There is no dental exception and no x ray exception.

The rule that decides how a phone gets treated is the one about securing the data. HHS guidance names two methods that render PHI unusable, unreadable or indecipherable: encryption and destruction. For data at rest, a valid encryption process is one consistent with NIST Special Publication 800-111. If a device holding PHI goes missing and the data was not secured that way, the practice is not handling an IT ticket. It is handling unsecured PHI and the breach notification process that follows.

So here is the plain version: unencrypted PHI must not sit in device storage. In practice that rules out habits that feel harmless. Do not write radiographs or clinical photos to the shared camera roll, where other apps and photo backup can reach them. Do not cache chart text, claim data or note bodies in plain files, unprotected local databases or debug logs. Do not leave a long lived token that unlocks the whole chart on a handset with no passcode and no automatic logoff. The Security Rule lists automatic logoff at 45 CFR 164.312(a)(2)(iii) and encryption and decryption at 164.312(a)(2)(iv), both as addressable specifications, which means you decide and you write down why.

Encryption on the device is one control out of a long list, and this page stops at the storage question on purpose. Before fixing an architecture, read what HIPAA actually requires, and have the design reviewed by whoever is accountable for compliance at the practice. Shipping an app does not discharge that duty for anyone.

HHS, guidance to render unsecured protected health information unusable, unreadable or indecipherable

What your practice management system will let an app read

A dental patient app that cannot see the schedule is a brochure with a logo on it. Whether it can see the schedule depends entirely on the practice management system, and the honest range runs from a documented REST API to nothing at all. Ask that question before anyone draws a screen, because the answer decides the shape and the cost of the whole project.

Open Dental is the clearest published example. Its REST API exposes resources that line up closely with the database tables: Appointments, Patients, Recalls, Documents, ProcNotes, PerioExams, Claims. Appointments can be pulled for a single day or a date range and filtered by status values such as Scheduled, Complete, Broken or ASAP, and there are calls to confirm one or break one. Two keys travel in the request header, a developer key and a customer key, and the office enables that key inside its own copy of Open Dental. Remote access also needs the office to be running the eConnector. Developer portal access is requested from the vendor with a list of the resources and permissions you need and a description of the app, and the documentation says to expect one to three business days.

Two things follow. The integration is per practice, not per app: every office has to switch you on, and can switch you off. And other systems are nothing like this. Some publish no API, some sell access, some move data only through a partner programme, some will hand you a nightly export and nothing more. An optometry practice app hits the same wall with a different vendor list. Get the terms in writing before promising a feature that depends on them.

One more line in that documentation is worth reading twice: it tells developers to have a business associate agreement in place with their clients. If the app or the service behind it touches PHI on behalf of the practice, that paperwork is part of the build, not an afterthought.

Open Dental, API specification

Reminders and recall are where a dental office app pays for itself

The expensive problem in a dental office is not charting, it is an empty chair at two o'clock. Recall is the engine underneath that: a hygiene patient due every six months, a list of who is overdue, and a record of how many reminders have gone out and when. Open Dental's recall data carries a due date and an interval written in a form like 6m1d, and its recall list adds the number of reminders sent since the last recall appointment and the date of the most recent one. Whatever system you integrate with has its own version of those fields, and they are what any reminder feature actually runs on.

The version that earns money closes the loop. A patient confirms and the status changes in the practice software, not in a spreadsheet somebody retypes on Monday. A nine o'clock cancellation pushes the gap to the people who said they would take short notice. Underneath it is the same machinery as any appointment reminder app, with a recall interval bolted on and a chart behind it.

Keep the message itself boring. The minimum necessary standard at 45 CFR 164.502(b) does not apply to a disclosure made to the patient themselves, so the rule is not what constrains you here. The lock screen is. A notification is readable by whoever happens to be holding the phone, and in a family that is often not the patient. Time, place and a way to confirm is enough. The procedure name, the tooth number and the balance can wait until someone has signed in.

Where a custom app fits next to what the practice already pays for

Most practices already run three things that overlap with the app they are imagining: a patient portal from the software vendor, a messaging service that sends reminders, and a website. Before building anything, write down what those three do not do. The list is usually short and very specific. The lab case that has not come back. The hygienist checking tomorrow's medical alerts from home. The associate who covers two sites and wants one schedule. The new patient forms that still get retyped at the desk.

That list is the app. It is staff facing more often than patient facing, which surprises people, and it is the part no vendor sells, because it is shaped like your practice and nobody else's. The patient facing half is mostly solved already by the portal you own and the reminders you send.

A useful test is whether a feature needs live chart data at all. A medical history form the patient fills in the night before is worth building even if it never touches the practice database, because it removes a retype and the answers get reviewed and entered once. A feature that does need live clinical data inherits everything in the integration question above, and its real cost is that integration, not the screens.