Network · Secure Messaging
Encryption is the easy part. Knowing who is covered is not.
Encrypting a message is the part everyone gets right. Knowing whether the person receiving it is covered by an agreement, and refusing to send when they are not, is a different job — and it is the one this channel does.
HIPAA mapping
Where this fits in the HIPAA rules.
4 provisions this capability contributes to, each with the specific Secure Messaging behavior behind it. The obligation stays with your practice — the mapping shows which part of the work the platform carries.
§164.312(e)Transmission security
Implements technical security measures to guard against unauthorized access to ePHI being transmitted over an electronic network. The platform encrypts messages in transit and at rest, which addresses this directly.
§164.312(e)(2)(ii)Encryption
Implements a mechanism to encrypt ePHI whenever deemed appropriate. Always-on encryption removes the “deemed appropriate” judgment.
§164.502(e)Disclosures to business associates
Permits disclosure to a BA only when satisfactory assurances are in place (the BAA). The gate enforces this — no BAA, no ePHI through messaging.
§164.504(e)Business associate contracts
Specifies required BAA contents. The platform's BAA workflow aligns with §164.504(e) requirements.
What it does
Encryption is solved. Governance is the actual problem.
The HIPAA messaging problem isn't encryption. Encryption is solved. The problem is governance — knowing whether the recipient is covered by a BAA, knowing whether the BAA is current, knowing whether the content type is appropriate for the recipient. Most “HIPAA-compliant messaging” tools encrypt the messages and leave the governance to the practice.
Patient Protect's messaging gates itself. The platform reads BAA state from the Workforce module continuously. Messages to vendors with Active BAAs flow normally. Messages to vendors without Active BAAs are gated — content masked, attachments blocked, ePHI exchange prevented at the architecture layer. The governance is in the platform, not the practice's memory.
The gate is symmetric. The vendor's side of the conversation is also gated when the BAA isn't Active. Both parties are prevented from sending ePHI when the contract isn't in force.
How it works
6 mechanisms keep Secure Messaging working.
The gate is on the send, not on your memory.
Messaging to a vendor reads that vendor's BAA state. Where no agreement is in force the exchange does not happen — the block is the mechanism, not a warning banner someone can dismiss at 4:50pm on a Friday. This is the whole argument for putting the agreement and the channel in one system: a register of BAAs sitting beside an unrelated inbox has never stopped anything.
One BAA state, read by both.
The gate reads the same six states Vendor & BAA Governance holds — none, staging, pending, active, expired, revoked. There is no second copy of the agreement's status maintained for messaging, which matters because a second copy is how a revoked agreement stays green somewhere for a month.
Encrypted in transit and at rest, without a setting.
There is no unencrypted mode to leave switched off. That is a low bar and worth stating plainly rather than dressing up: what does the work here is not the cryptography. It is that the channel reads the agreement state before the exchange and stops it when there is none.
Patients are participants, not a separate product.
A practice can invite a patient into the channel and exchange messages and files with them there, on Basic, without buying a patient module. What the practice sends and to whom is a clinical and privacy judgement the practice makes; the channel's job is that the exchange is governed and recorded rather than sitting in somebody's personal email.
Files travel the same path as the words.
An attachment is subject to the same gate as the message carrying it. A vendor without an agreement in force does not receive the message and does not receive the file, which is the case that actually matters — the ePHI that leaks is far more often a document than a sentence.
Recorded, and readable afterwards.
Exchanges are logged with sender, recipient and time, so the question that follows an incident — did we ever send anything to that vendor — has an answer that does not depend on whose mailbox it was in. The record lives in the same audit the rest of the platform writes to.
Who this is for
Built for the practices that need it most.
Practices that exchange ePHI with vendors regularly.
Billing services, transcription, lab interfaces, IT vendors — vendors that handle ePHI as part of their normal function. The gate is most valuable for these high-frequency relationships where the cost of a missed BAA is highest.
Practices recovering from a BAA-related incident.
If your office has had a finding involving ePHI sent to a vendor without an active BAA, the architectural gate is the remediation. The platform makes the failure mode impossible forward.
Practices replacing email-with-encryption.
Practices that have been using “secure email” or third-party encryption tools for vendor communication often hit governance gaps. The platform's integrated gate is the replacement — messaging plus governance plus audit in one workflow.
Practices that exchange ePHI with patients.
Patient messaging is the operational alternative to phone tag and to portal logins. Encrypted, BAA-acknowledgment-gated, audit-logged.
What you get
6 outcomes you’ll feel in week one.
The channel checks the agreement.
No agreement in force, no exchange with that vendor here.
Always-on encryption.
Encrypted in transit and at rest. No opt-in, no opt-out.
Six-state lifecycle.
None / Staging / Pending / Active / Expired / Revoked — explicit at every moment.
One source for the state.
The gate reads the BAA record itself, not a copy of it.
Patients in the same channel.
Invite a patient and exchange messages and files with them, on Basic.
Sender, recipient, time.
The question after an incident has an answer that is not a mailbox.
What happens to past messages when a BAA expires?
Can we message patients here, on Basic?
What if a vendor refuses to use Patient Protect?
Can a workforce member delete a message?
Who can read a thread?
What about file sizes?
What it does not do.
- Inviting a patient into a conversation is Secure Messaging, not Patient Management
- No end-to-end encryption claim — it has never been established
Continue exploring
Related features in the platform.
Defense
Vendor & BAA Governance
A BAA is either in force or it is not, and most practices cannot say which. Six states, one list, and ePHI blocked where no agreement covers it.
Learn moreNetwork
Smart Referrals
Referral records leave most practices by fax or by somebody's email, because the alternative has always required the other end to adopt your software. This does not.
Learn moreNetwork
Patient Management
Your EHR holds the clinical story. The administrative one — who this patient is to your office, what has passed between you, what is still outstanding — usually holds together only in somebody's head.
Learn moreEncrypted messaging that gates itself. The gate is the architecture.
Most practices replace email-with-encryption inside the first month. The governance gap closes architecturally.