§What HIPAA Security Rule requires
Source: 45 CFR Part 164 Subparts A and C — Security Standards for the Protection of Electronic Protected Health Information — accessed 2026-05-11.
Jurisdiction. Applies to U.S. Covered Entities (health plans, healthcare clearinghouses, and most healthcare providers) and their Business Associates with respect to electronic Protected Health Information (ePHI). Compliance date for most covered entities: 21 April 2005.
Personal data definition. The Security Rule governs electronic Protected Health Information (ePHI) — the subset of PHI created, received, maintained, or transmitted in electronic form. The Privacy Rule defines what counts as PHI; the Security Rule defines how ePHI must be protected.
Key requirements relevant to mobile analytics. 45 CFR §164.306(a) sets four general requirements: ensure the confidentiality, integrity, and availability of all ePHI; protect against reasonably anticipated threats; protect against reasonably anticipated impermissible uses or disclosures; and ensure workforce compliance. §164.312 sets the Technical Safeguards — Access Control (unique user identification, emergency access procedure, automatic logoff, encryption/decryption), Audit Controls, Integrity (mechanism to authenticate ePHI), Person or Entity Authentication, and Transmission Security (integrity controls and encryption during transmission).
⚑Where mobile analytics typically creates exposure for telehealth apps
If ePHI flows into an analytics SDK, the entire analytics pipeline becomes part of the ePHI environment and inherits the Security Rule's technical-safeguard obligations: unique user identification, audit trails, encryption in transit, integrity controls. Most analytics SDKs are not engineered for this — they treat events as commodity telemetry, not as ePHI.
Telehealth apps routinely process appointment metadata, symptom descriptions, diagnosis codes, medication names, vitals (heart rate, blood pressure, glucose), and prescription details. Each of these is individually identifying when combined with a user identifier in an analytics event.
Health-related data is treated as a special category under most privacy regimes — GDPR Art. 9, CPRA sensitive personal information, and PHI under HIPAA. A single event like appointment_booked with parameters { specialty: 'oncology', user_id: '...' } is structurally health data tied to an identifier.
▸What Respectlytics's design does (technical facts)
Respectlytics's API stores exactly five fields per event: event_name, session_id (rotates every two hours, RAM-only), timestamp, platform, and country. Health-category fields are rejected at the API with a 400. A telehealth app can use Respectlytics to track product signals (appointment_booked_paid, prescription_renewal_attempted) at the session level — the actual clinical content stays in the EHR or telehealth platform where it belongs.
Reduces the surface. Removing the surface where the categories covered by HIPAA Security Rule could be collected in the first place narrows what a HIPAA Security Rule review needs to scope. Whether the resulting posture meets the regulation's requirements for your specific app is something to discuss with your legal team.
❓Frequently asked questions
What is the difference between the HIPAA Privacy Rule and the HIPAA Security Rule?
The Privacy Rule (45 CFR Part 164 Subpart E) governs how PHI may be used and disclosed — including in non-electronic forms. The Security Rule (Subparts A and C) governs how electronic PHI must be protected with administrative, physical, and technical safeguards. Both apply to the same covered entities; the Security Rule narrows the focus to ePHI.
Are encryption and audit logging required by the Security Rule?
§164.312 lists encryption (at rest and in transit) and audit controls. Some specifications are designated Required (e.g., audit controls, unique user identification); others are Addressable, which means the covered entity must either implement the spec or document why it is not reasonable and implement an equivalent alternative.
Does using Respectlytics by itself resolve HIPAA Security Rule obligations for our telehealth apps app?
No — and no analytics SDK can credibly answer that question. Whether your product meets HIPAA Security Rule's requirements is a property of your whole product, contracts, and operational practice, evaluated by your legal team. Respectlytics's contribution is a smaller data surface: identifying fields and the regulation's special categories are rejected at the API. Whether that posture, combined with your other controls, satisfies HIPAA Security Rule for your specific app is a conversation for your counsel.
What if we already use a different analytics SDK today?
The starting point is an inventory of what your current SDK actually collects and where it sends it. Our privacy self-assessment worksheet walks through that in seven sections — it outputs an educational summary you can bring to your legal team.