A HIPAA compliant messaging app is a chat app that can prove who read what.
Clinicians already have a messaging app. It is the one on their own phone, and it is why this question keeps coming up. A HIPAA compliant messaging app is not a chat app with a padlock drawn on it. It is a chat app that knows who each person is, records that a message was opened, locks itself when the phone is put down, and can be answered for a year later. The wider ground under all of that is covered in HIPAA compliant app development.
This page covers what the Security Rule actually asks of a message, why the lock screen is where most of the exposure sits, what end to end encryption would and would not buy a practice, and what a clinical thread has to carry beyond the text itself.
See what the lock screen gives awayThe short version
The rule cares less about the padlock and more about the record.
Search for a HIPAA compliant texting app and you get a page of padlocks. Encryption is where everyone starts, and in the technical safeguards it is marked addressable rather than required. The two specifications marked required under access control are duller and much harder to bolt on later: every person gets a unique identifier, and there is a procedure for reaching the information in an emergency. Audit controls and person or entity authentication are standards in their own right.
For a messaging app that comes down to four things. Named sign in, with no shared station login. A line written every time a message is opened. A screen that locks itself. And a deliberate decision about what a push notification may say on a locked phone, because that is the part that gets read by people who were never in the thread.
What the Security Rule asks of a message
The technical safeguards are short, and they read more like a product backlog than a legal text. Access control requires a unique name or number for identifying and tracking each user, and an emergency access procedure for obtaining electronic protected health information during an emergency. Both are marked Required. Automatic logoff after a predetermined period of inactivity, and a mechanism to encrypt and decrypt, are marked Addressable.
Addressable does not mean optional. It means you assess whether the measure is reasonable and appropriate where you are, implement it where it is, and where it is not, document why and put an equivalent measure in place. For messages that cross mobile networks and sit on handsets that get left in cars, that assessment has a predictable ending.
The rest of the list is where a messaging app usually falls down. Audit controls: mechanisms that record and examine activity in systems holding protected health information. Integrity: electronic mechanisms to corroborate that information has not been altered or destroyed in an unauthorised manner. Person or entity authentication. Transmission security, covering integrity controls and encryption in flight. A group chat where anyone can edit a message and nobody knows who read it misses three of those at once.
None of this is specific to chat. Every hipaa compliant phone app has to answer the same list. Messaging just makes each answer visible to more people at the same time.
Most of the exposure is on the lock screen
A clinical messaging app sends push notifications, because a message nobody sees is not a message. That single feature moves patient information onto a locked screen, into a notification list, onto a paired watch, and through two or three companies that were never in the conversation.
The path is worth knowing before you design the payload. With Expo's push service, your server posts the notification to Expo, which queues it and hands it to Firebase Cloud Messaging on Android or the Apple Push Notification service on iOS, and one of those delivers it to the handset. Whatever sits in the title and body travels that whole way. The documented limit on the payload is 4096 bytes.
The fix is not a setting, it is a decision made at build time: put no clinical content in the payload at all. Send a neutral title, a message identifier in the data object, and let the app fetch the text after the person has unlocked and authenticated. iOS also lets a notification category carry placeholder text to show when the system hides previews, so the alert can still say something arrived without saying what it was.
The same restraint applies to the watch, the tablet on the desk and the car display. A notification is a copy of the message sent somewhere you do not control, and the only reliable way to keep it safe is to make sure it never contained anything.
Expo, sending push notifications
Try it
What the lock screen gives away
On a locked phone
Margaret Hale, bed 12: potassium 6.1, please review now
A named patient and a result, readable by anyone holding the phone.
That text also passes through the push service, then through Apple or Google, on its way to the handset.
End to end encryption pulls against the audit trail
Encrypted clinical messaging covers two arrangements that are not the same thing. End to end encryption means a message is encrypted on the sender's device with a key the server never holds, and decrypted only on the recipient's device. Encryption in transit means something different: the message is protected on the wire, then decrypted and stored by the service carrying it. Most clinical messaging products do the second and call it secure, which is fair, and is not the same claim.
There is a real tension here, and it explains why the second option is so common. If only the two handsets can read a thread, the practice cannot. It cannot produce the thread for a records request, it cannot review it after a complaint, and it cannot reach it when a clinician leaves and the phone goes with them. The required emergency access procedure and the audit controls standard both assume the organisation can get at the information. Encryption that shuts the organisation out is a design decision with consequences, not a free upgrade.
It is worth answering the build question plainly, because the assumption usually runs the other way. Newly is an AI app builder, and the backend a generated project comes with gives you sign in, an API service, a Postgres database and file storage. Nothing in that sets up a key pair on each device or a key exchange between two of them, and the product documentation does not describe end to end encryption anywhere. So the honest answer is no: a build does not give you end to end encryption between two users out of the box. Messages are protected the ordinary way, encrypted in transit and fenced by access control in the database. Anything stronger is something you design and add yourself.
What most teams actually need first is the layer underneath, done properly: encryption in transit and at rest, a locked local store on the handset, and key material kept in the operating system keychain rather than in your own code. That is a separate piece of work, and it is worth reading up on before you choose where the messages will live.
What a clinical thread has to carry
A consumer chat app models a conversation between people. A secure messaging app for healthcare models a conversation about a patient, and that changes the data. A thread needs a subject, usually a patient identifier rather than a name in the title. It needs a reason for existing. And it has to survive the people in it changing, because the doctor on call at nine is not the one on call at three.
Routing is the feature people underestimate. Most clinical messages are not addressed to a person, they are addressed to a role: the physician on call, the duty pharmacist, whoever is covering the third floor tonight. An app that only knows individuals makes every sender check the schedule first, and that is exactly the friction that sends a team back to the group chat they already have.
Urgency belongs in the message rather than in the wording. A sender marking something as needing an answer within the hour, and an escalation when nobody opens it, is most of what separates a clinical tool from a chat app. So is a read state that is honest about what it means: delivered to a device, opened by a named person, at a time, and kept whether or not the message is later deleted.
Then there is what happens to all of it afterwards. A message becomes a clinical record the moment it carries clinical detail, which is the same problem a therapy notes app solves with a structured note. If the thread is where the detail lives, the thread is the record, and it needs the retention rule and the access log that a record gets.
What each way of messaging gives a practice
| Option | Content encrypted in transit | Named sign in per person | Record of who read it | You set the retention rule |
|---|---|---|---|---|
| Standard SMS | No | No | No | No |
| Consumer chat app | Yes | one login per phone | No | No |
| Work email | depends on both servers | Yes | server logs only | the mail admin does |
| Clinical messaging product | Yes | Yes | Yes | within its settings |
| A messaging app you build | Yes | Yes | Yes | Yes |
Building one around how your team actually works
Clinical messaging products exist and they are good at the general case: named accounts, audit logs, message recall, a staff directory. They are priced per user per month and shaped around a hospital org chart. A six person practice, a home health team or a single clinic usually needs a fraction of that, plus one or two things the product will not do. Routing to your call schedule. A thread tied to the identifier your practice management system already uses. An escalation rule that matches how your after hours cover really works.
Newly is an AI app builder. You describe the app in plain English, it writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and uploads iOS builds to TestFlight through your own Apple Developer account. The Deploy tab has an Android section too: one press builds, signs and uploads to Google Play internal testing, and it also produces a standalone release APK you can download and install on a phone directly. It costs $25 a month and there is no free plan. The documentation does not mention HIPAA or a business associate agreement, so settle who holds the data, and under what agreement, before any patient information goes near it.
Whatever you build, start from the four things that are painful to retrofit: named sign in, an access log, a session timeout, and a push payload that says nothing. Features are easy to add to an app that has those. They are miserable to add to one that does not.
Questions people ask about HIPAA compliant messaging apps
Strictly, an app is not compliant by itself. Compliance belongs to the organisation using it. What an app can do is support the technical safeguards: a unique identifier for each user, an emergency access procedure, a record of activity in the system, verification that a user is who they claim to be, and protection of information in transit. Unique user identification and emergency access are Required. Automatic logoff and encryption are Addressable, meaning you implement them or document why not and put an equivalent measure in place.
Describe the messages your team actually sends
Write down who needs to reach whom, what a locked phone is allowed to show, and what has to be answerable a year from now. Build the app around those three answers.
Start building