Product analytics and session replay for healthcare apps

Track the step, not the answer. Record that a user reached the date picker, the provider selection step and the confirmation screen, with a step ID, a timestamp and a coarse, non-identifying context such as platform and app version. Do not attach the reason for visit, the provider's specialty when it reveals a condition, the chosen clinic location if it is sensitive, or any text the patient typed. A simple rule for the team: event properties may hold step names, counts, durations and enumerated values from a fixed list you control, never free text or values copied from a form. Have your privacy officer and clinical governance owner confirm each funnel event and its properties before release, and record that approval in your data inventory. Note that the set of steps a patient reaches can still imply a visit type, so review combinations, not only single fields.

Measure drop-off by verification step ID and outcome category, not by the data entered. For example, record that a user started step 3 of identity verification, then left, or that a failure occurred in a category such as document upload timeout versus rejected format. Avoid recording document types that reveal insurance or clinical status, date of birth, member IDs, or the result of any check that references health records. Be cautious with error messages from identity providers, which can echo submitted values. Your team should map each step ID to a written description, and the privacy and security owners should confirm that the category list cannot be used to infer identity or health status. Ask your identity vendor which fields its SDK sends to its own servers, because those transfers sit outside your analytics configuration.

Error and performance telemetry is usually the most useful and the lowest risk category. Track JavaScript error types, HTTP status codes, API endpoint names without query strings or path parameters, page load timings, and the frequency of failed requests by app version and device class. The rule is to strip identifiers from URLs and never log request or response bodies. Patient record IDs, encounter numbers and medication names often appear in paths or query strings, so normalize routes to templates such as /appointments/:id before they leave the browser. Ask your engineering team to confirm that error reporting does not capture stack traces that include rendered values, and to test this after each front-end release.

Use role categories from a fixed list, such as patient, caregiver, clinician or administrator, and count feature use within those categories. Do not record the clinician's name, specialty, department, or any attribute that identifies a small group of people, since a rare role combined with a feature can single out an individual. Set a minimum group size before a report is shared, and suppress small cells. Keep the role field as a coded value assigned by the access control system rather than a free profile attribute. Confirm with your privacy owner whether role-level analytics count as personal data in your jurisdiction, and document the aggregation threshold in your records of processing.

Yes, for timing and task completion, but not for the content being read. Useful measures include time to complete a form step, the number of retries on a control, use of keyboard navigation versus pointer input, and whether a screen reader user hits repeated focus loops. These measures tell you where the interface slows people down without capturing the text they enter. Replays of assistive technology sessions need extra care, because the replay may show masked fields but still reveal the page structure a patient is viewing. Set masking to default-on for all text in these flows, and confirm with your accessibility lead and clinical governance owner which timing events are collected and why.

The safest pattern is an allowlist. Define every event name and property key in a versioned tracking plan, and reject any property not on the list in code review and in the analytics pipeline. The rules to enforce are:

• No values copied from diagnosis, medication, lab, allergy or note fields, even as hashes or truncated strings.
• No free-text inputs sent as properties, including search queries in a health content library.
• Numeric clinical values, such as a lab result, excluded entirely from analytics events.
• Automated checks in the pipeline that drop unlisted properties before storage.

The organization must confirm each event with its privacy and clinical governance owners before it goes live, and repeat that check when the tracking plan changes.

The event list should be approved by at least the privacy officer, the security lead, a clinical governance representative and the product owner, with the platform team responsible for enforcing it. Each event needs a named owner, a business purpose, the properties allowed, the retention period and the masking settings that apply. DeployOpen can help plan, configure and document this on a self-hosted OpenReplay or other open-source stack in the client's own infrastructure, under a fixed scope agreed in writing. Approval remains the client's decision, and DeployOpen does not issue compliance attestations. Ask your implementation partner to show how the approval record is stored and how changes trigger a new review.

No. There is no HIPAA certification for software or for organizations. HHS states that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private certifications, and that such certifications do not prevent HHS from later finding a violation. Any vendor claiming HIPAA certification should be asked for the specific evidence behind the claim. What matters is whether your organization meets the Security Rule for the ePHI it handles, including the risk analysis, access controls, audit controls, encryption decisions and documentation. Where a vendor will process ePHI on your behalf, a business associate contract is required under 45 CFR 164.314. Self-hosting can keep analytics data out of third-party tools, which narrows that question, but it does not remove your own obligations.

Cost comes from four places: the software itself (open source, so no license fee for the community edition), infrastructure you run in your own cloud or data center, implementation work, and internal staff time. Implementation scope drives most of the one-time cost: the number of pages and flows to instrument, how many masking rules you must write, and how much testing is needed to prove that masking holds after each front-end release. Recurring costs include hosting, storage, upgrades, monitoring and retention management. Event volume and replay volume raise storage and compute needs, and longer retention raises them further. Ask any implementation partner for a fixed-scope quote that lists these items separately, and ask what is one-time and what recurs. No published figure applies to your environment, so request the numbers from your own sizing.

The timeline depends on scope, not on a fixed duration. A rollout covering one patient portal with a short list of events and a masking policy will take less time than a rollout across a portal, a telehealth app and a mobile app with native replay. The main variables are how many applications and environments are involved, whether the hosting environment already has the required network, identity and logging controls, how long the privacy and security review takes, and how much masking testing is required before release. Ask for a written scope with milestones, and make sure the review and sign-off steps are included in the plan rather than treated as optional. DeployOpen plans and delivers implementations under fixed scopes agreed in writing before work starts.

Yes, if your team has the skills and time to handle the safeguards, not only the installation. Installing OpenReplay is a comparatively small task: the project's README describes a single virtual machine with 2 vCPUs, 8 GB of RAM and 50 GB of storage as enough to start, with deployment options including Docker, Kubernetes with Helm and several cloud providers. The harder work is configuring capture-time masking, writing and testing selectors, setting retention, restricting access by role, enabling audit trails, keeping the platform patched, and documenting how each control works for your risk analysis. Check whether your staff can own those tasks over time. If they cannot, a fixed-scope implementation followed by a support retainer is a common alternative.

HHS can impose civil money penalties under its inflation-adjusted table. For penalties assessed on or after January 28, 2026, the range runs from $145 per violation, where the entity did not know of the violation, to $2,190,294 per violation for uncorrected willful neglect, with a calendar-year cap of $2,190,294 for identical violations, according to 45 CFR 102.3. The amount actually assessed depends on the culpability tier, how quickly the problem was corrected and the circumstances. Penalties are only one part of the exposure: incident notification duties, state law, contractual claims with covered entities and reputational harm also apply. Confirm the current table with your counsel, because the figures are adjusted for inflation.

Self-hosting keeps session data in infrastructure you operate, so recordings and events are not sent to a vendor's cloud. OpenReplay's README notes that self-hosting keeps session data in the operator's own infrastructure and that first-party tracking from your own domain is not blocked by ad blockers. It does not guarantee that nothing leaves the browser. Third-party scripts, CDNs, fonts, error reporters and embedded widgets on the same pages can still transfer data. Map every script and request your app makes, and confirm that the analytics SDK does not send identifiers or payload content to other services. Ask your implementation partner for a data flow diagram that shows these paths.

The stack touches several areas of the Security Rule. Under the technical safeguards in 45 CFR 164.312, the most relevant items are:

• Unique user identification for every analyst and administrator
• Automatic logoff for dashboard sessions
• Encryption of data at rest and in transit, which is addressable and must be documented if not implemented
• Audit controls that record access to recordings

Administrative safeguards also apply, including the risk analysis, workforce access management and incident procedures. Map each control to the specific standard and document your decision, because the Security Rule treats addressable specifications as requiring a documented assessment, not optional treatment. NIST SP 800-66 Rev. 2 provides informational guidance and sample questions for each standard.

Measure behavior at the level of flows, steps and outcomes rather than the content users type or view. Useful measures include completion rate for a booking flow, drop-off between identity verification and first appointment, time to first message sent, feature adoption counts for telehealth sessions, and error rates by screen. Use coded, non-identifying event names and bucketed properties instead of diagnoses, medication names, provider names or free-text fields. Mask inputs by default and allow only an approved list of properties to be captured. Review each event in your tracking plan with your privacy officer before it ships, and test that masking still applies after front-end releases.