HIPAA & Compliance
HIPAA, in plain language—and where we stand
If your department runs EMS, the records you keep in Command Established can include protected health information. This page breaks down what HIPAA actually requires, how it applies to a platform like ours, and—requirement by requirement—how Command Established measures up. We're candid about what's in place, what's still in progress, and where responsibilities are shared.
Last updated June 2026 · Informational only—not legal advice
HIPAA in plain terms
HIPAA—the Health Insurance Portability and Accountability Act—sets federal rules for protecting health information. For software like ours, three of its rules matter most:
Privacy Rule
Governs who may use or disclose protected health information, and limits it to the "minimum necessary" for the task at hand.
Security Rule
Requires administrative, physical, and technical safeguards for health information kept in electronic form (ePHI). This is where software does most of its work.
Breach Notification Rule
Requires that affected individuals—and, for breaches of 500 or more, regulators and the media—be notified, generally within 60 days, when unsecured (unencrypted) health information is exposed. Properly encrypted data falls under a safe harbor.
A few terms worth knowing
- PHI / ePHI
- Protected Health Information—identifiable information about a person's health, care, or payment for care, when it's held by a covered entity or its business associates. "ePHI" is PHI in electronic form. A patient's name alongside their vitals, medications, or transport on an EMS run is ePHI.
- Covered entity
- A health plan, clearinghouse, or health care provider that transmits health information electronically in connection with certain standard transactions—most commonly electronic billing. Delivering care isn't enough on its own: a fire or EMS department is a covered entity when it bills electronically for that care. The HIPAA obligations ultimately rest with the covered entity.
- Business associate
- A vendor that creates, receives, maintains, or transmits PHI on a covered entity's behalf—the role a HIPAA-compliant software vendor would play. Simply storing PHI makes a cloud vendor a business associate, even if it can't read the encrypted data.
- BAA
- Business Associate Agreement—the written contract a covered entity must have in place before it can lawfully share PHI with a vendor acting as its business associate. Command Established is finalizing its own customer-facing BAA; our subprocessors (AWS, Google Cloud, and TurboPuffer) are already under BAAs with us.
- Required vs. addressable
- Some Security Rule specifications are mandatory ("required"); others are "addressable"—which does not mean optional. You must implement an addressable spec where reasonable, or document why not and adopt an equivalent. Encryption, for example, is currently addressable but widely treated as expected—and a proposed 2025 update would make it required (see below).
Does HIPAA apply to your department?
It depends on what you do and what you store. A useful rule of thumb:
- Fire-only departments that record incidents without identifiable patient-care information generally hold little or no PHI in the platform.
- Departments running EMS—documenting patients, vitals, medications, treatments, transport, or refusals of care—are very likely handling patient health information. HIPAA's Privacy and Security Rules attach once your department is a "covered entity," which for a provider generally means billing electronically for that care; most EMS agencies that bill cross this line.
- Even outside HIPAA, EMS records are sensitive under state law. We treat them with heightened care regardless of whether HIPAA technically applies to your operation.
What PHI can live in Command Established
When you use EMS features, the platform can store patient records, vital signs, administered medications, treatments and procedures, refusal-of-care (AMA/RMA) e-signatures, and the EMS detail modules used for NERIS reporting. All of this is encrypted in transit and at rest and is isolated to your department's tenant—see the architecture overview for exactly where it lives. We also deliberately keep this data within the subprocessors we hold BAAs with (AWS, Google Cloud, and our search provider TurboPuffer); our other subprocessors—analytics, error monitoring, payments, and mapping—are not sent patient health information.
The Security Rule, mapped to our platform
The Security Rule is organized into three families of safeguards. Below we map the rule's key standards to an honest status and a note on how Command Established does—or doesn't—address each. It's a plain-language summary, not the full regulatory text.
Technical safeguards — §164.312
| Requirement | Status | How we handle it |
|---|---|---|
| Access control & unique user identity | In place | Every user has a unique account. Role-based permissions are checked on every request that touches department data, and each department's data is isolated from every other tenant. |
| Automatic logoff | In place | Sessions are time-limited and expire, requiring re-authentication. Session cookies are secure and HTTP-only. |
| Encryption & decryption | In place | AES-256 at rest across every data store; the most sensitive secrets use a customer-managed KMS key. See the encryption details on our architecture page. |
| Audit controls | In place | An append-only audit log records every create and update—who, when, and what changed. We also log views of sensitive records such as incidents and patients, so access to PHI is traceable, not just edits. |
| Integrity | In place | All inputs are schema-validated, writes are soft-deletes (no destructive hard deletes), and the append-only audit trail plus point-in-time backups let you reconstruct prior state. |
| Authentication | In place | Password authentication with hashed credentials, plus multi-factor authentication. A department admin can now require MFA department-wide: once enabled, every member who signs in with a password must enroll a verified second factor before they can access the department. (Members who use Google sign-in only are exempt—Google enforces its own MFA.) |
| Transmission security | In place | TLS 1.2+ on every external connection, with HSTS enforced. Internal traffic to AWS data services is encrypted over private network paths. |
Administrative safeguards — §164.308
| Requirement | Status | How we handle it |
|---|---|---|
| Information access management | In place | Role-based access in the app; least-privilege IAM for the infrastructure. Our staff's access to your data is restricted to what's necessary to operate and support the service. |
| Assigned security responsibility | In place | We have designated a named Security Official who is accountable for our security program, with written responsibilities and supporting procedures. |
| Contingency plan (backups & recovery) | In place | Point-in-time recovery on the primary database, versioned object storage, daily cache snapshots, and redundant compute across multiple availability zones. |
| Security incident procedures & monitoring | In place | Centralized logging, metrics, and error monitoring with automated alerts, plus account-level audit logging and alerting on root, console, and IAM-credential use. A written incident-response and breach-notification procedure is documented and in effect. |
| Risk analysis & periodic evaluation | In place | We maintain a formal, documented risk analysis and risk register covering where ePHI lives and the risks to it, reviewed at least annually and when the system changes materially. |
| Workforce security training | In place | Every workforce member with access to ePHI completes security-awareness training at onboarding and at least annually, against a written curriculum and signed attestation. |
| Business associate contracts with subprocessors | In place | We hold signed BAAs with the subprocessors that store or process data on our behalf—Amazon Web Services, Google Cloud (for the Vertex AI / Gemini features we use), and TurboPuffer (which powers full-text search)—so PHI handling flows down under contract, as §164.308(b) requires. |
| Customer-facing BAA (with your department) | Partial | We're finalizing a customer-facing BAA. If your department needs one in place before sharing PHI, contact us and we'll work through it with you. Our own subprocessors are already under BAAs with us. |
Physical safeguards — §164.310
| Requirement | Status | How we handle it |
|---|---|---|
| Facility & data-center access controls | In place | All systems run in AWS data centers in the United States, which maintain physical security and their own independent compliance certifications. We operate no on-premises servers holding your data. |
| Device & media controls | In place | Storage is managed, encrypted cloud storage—decommissioning and media disposal are handled by AWS, never by physical drives we move or discard. |
| Workstation use & security | Shared | The devices your members use to access the platform—station computers, tablets, phones—are governed by your department's own policies. We provide secure sessions and MFA; you control the endpoints. |
Where the rules are heading
In January 2025, HHS proposed the most significant update to the Security Rule in two decades. If finalized, it would remove the "addressable" category—making specifications like encryption and multi-factor authentication mandatory (MFA we already support enforcing department-wide)—and add new requirements such as written asset inventories and network maps, annual compliance audits, regular vulnerability scanning and penetration testing, and restoration of critical systems within 72 hours of a loss. As of mid-2026 it remains a proposal, not law, and a final rule could differ. We're tracking it and building toward the stricter bar regardless.
A shared-responsibility model
Even with a HIPAA-compliant vendor, the covered entity always keeps responsibilities of its own. Here's a clear split of who does what.
What Command Established provides
- ✓Encryption in transit (TLS 1.2+) and at rest (AES-256)
- ✓Unique accounts, role-based permissions, and tenant isolation
- ✓Append-only change auditing and view/access logging for sensitive records
- ✓Multi-factor authentication—optional per member, or required department-wide by an admin—and secure, expiring sessions
- ✓Backups, point-in-time recovery, and multi-AZ redundancy
- ✓Least-privilege infrastructure and restricted staff access to your data
- ✓Signed BAAs with our infrastructure subprocessors (AWS, Google Cloud, and TurboPuffer)
- ✓PHI confined to those BAA-covered subprocessors—analytics, error monitoring, payments, and mapping vendors aren't sent patient data
- ✓A documented HIPAA program—risk analysis and register, a workforce security-training program, and a written incident-response & breach-notification procedure
What your department owns
- △Deciding whether HIPAA applies to your operation and entering PHI accordingly
- △Managing your users—who has accounts, what role each holds, and timely off-boarding
- △Deciding whether to require MFA department-wide, and enforcing strong-password and device policies for your members
- △Securing the workstations, tablets, and phones used to access the platform
- △Applying "minimum necessary" practices and training your own workforce
- △Maintaining your own HIPAA documentation, risk analysis, and policies
Customer-facing BAAs
If your department is a covered entity, you'll generally need a Business Associate Agreement in place with us before PHI goes into the platform. We're finalizing our own customer-facing BAA—if your department needs one, contact us and we'll work through it with you. Our own subprocessors are already under BAAs with us.
However you're using EMS records, that's exactly the conversation we want to have—tell us what you need, and we'll be straight with you about timelines and fit. You can also review our Privacy Policy, Terms of Use, and Subprocessors for the full picture.
This page is provided for information only and is not legal advice. HIPAA obligations depend on your specific circumstances; consult your own counsel or compliance officer.
Questions about HIPAA and your data?
We're glad to walk your compliance officer or IT team through any part of this, answer a security questionnaire, or talk about what a BAA would take. No spin—just a clear conversation.