What is Patient Privacy Monitoring and why any health app should have it

When you talk about security in medical applications, almost everyone thinks about the same thing: encryption, MFA, HTTPS, BAA with the infrastructure provider. All that is necessary. But there is a layer that almost no one publicly discusses and that, however, is the one that most real gaps stops in the day to day.

The awkward question is not "Are the data encrypted?". It is:

If we call you right now and ask you who agreed to Juan Pérez's medical records in the last 30 days, can you answer us in less than a minute?

To answer that question there is a category of systems with their own name in the industry: Patient Privacy Monitoring, a specific application of UEBA (Use & Entity Behavior Analytics) to the health context. In this article we tell you what it is, why HIPAA requires it, how it works technically and how we implement it in Brauni.

The real health threat profile

When you imagine a medical data breach, think of a hooded hacker typing commands on a dark keyboard. Reality is much less cinematic.

According to the annual reports of OCR (Office for Civil Rights, U. S. regulator HIPAA) and Verizon DBIR, most incidents of PHI do not come from an external attacker breaking encryption. They come from legitimate accounts asking questions they should not:

• A curious employee reviewing the file of a known or famous patient
• An engaged account exporting 200 tokens to 3 in the morning
• A former active-session worker who no one revoked upon discharge
• Someone trying to change IDs in the URL to see what is returned (which is called a IDOR, Insecure Direct Object Reference)
• A therapist accessing files that aren't from his assigned patients

None of these threats stop with encryption. Encryption protects against someone who gets in by force. It does not protect against someone who has the key.

What is Patient Privacy Monitoring?

It is a category of systems dedicated to observing how clinical data are used from within the application and detecting patterns that are far from normal. In the technical literature it is known by several names according to the angle:

• UEBA (Use & Entity Behavior Analytics): The large umbrella, used by Gartner and suppliers such as Splunk, Exabeam or Microsoft Sentinel
• Patient Privacy Monitoring or Patient Privacy Intelligence (PPI): the name used by health providers (Protenus, Imprivata FairWarning, Maize Analytics)
• Insider Threat Detection & Response (ITDR): name from the pure cybersecurity angle
• Audit log monitoring: the oldest and technical name, without a marketing flavour

In the HIPAA language, this type of system covers three formal requirements:

It's not optional, it's law.

How it works: the nine questions the system is asked

In Brauni, each access to protected health information (PHI) is recorded in an unchangeable audit log. On that log, a detection engine executes nine rules in parallel, each answering a specific question:

1. Is someone trying to change IDs in the URL? (IDOR_ATTEMPT)

Severity: HIGH

If an account accumulates multiple events ACCESS_DENIED in a short window, it is probably manually testing to change patient IDs to see which ones answer it. It is the classic pattern of discovery of IDOR (Insecure Direct Object Reference). The rule groups the denied by user_id and triggers when it crosses a threshold.

2. Is someone opening too many stories in a short time? (BULK_ACCESS)

Severity: HIGH

A normal therapist checks between 5 and 20 files per day, yours. If an account opens 30+ different medical records in a short window, something is not right. It can be a scraper, a committed account, or an employee curiosating. The rule counts different patients (not repeated accesses to the same patient, that is normal use).

3. Is anyone exporting massively? (BULK_EXPORT)

Severity: Critical

Exporting is the most dangerous operation: it takes PHI out of the app's controlled perimeter and turns it into a file that can live on any disk. A single legitimate export is normal. Ten in an hour is a red alarm signal. That's why this rule is the only one with CRITICAL severity.

4. Is there a brute force attack? (LOGIN_BURST)

Severity: MEDIUM

It detects when a single IP accumulates many login failures. The important technical subtlety: this rule is not indexed per user but by original IP, because an attack of brute force or of credential suffing triggers many different attempts: sometimes against emails that do not exist, sometimes with the incorrect password of a user that does exist. That is why it groups failed attempts by IP regardless of whether the email corresponds to a real user or not, and is the only rule of the engine that does not need a valid user_id to shoot.

5. Did the account make "teleport"? (IMPOSSIBLE_TRAVEL)

Severity: HIGH

If the same account enters Buenos Aires at 14:00 and ten minutes later in Madrid, there is a physical problem: nobody travels to 60.000 km/h. The system calculates the implied speed between two consecutive sessions and shoots when it exceeds a configurable threshold. It is one of the strongest indicators of compromised account.

6. Did the account enter from a new country? (NEW_GEO)

Severity: MEDIUM

An account that historically only entered from Argentina and suddenly logins from Romania deserves a review. It is not always an attack (it may be a trip), but it deserves attention.

7. Is it a new device? (NEW_DEVICE)

Severity: MEDIUM

Brauni assigns a stable identifier to each device (signed cookie + minimum footprint). If an account uses a device it has never seen before, it is registered as an event. Useful for detecting shared accounts or hijacked sessions.

8. Was there access out of schedule? (OFF_HOURS)

Severity: LOW

A reading of PHI at 3 in the morning is not necessarily suspicious, but it is useful information to correlate. If you also cross with IMPOSSIBLE_TRAVEL or BULK_ACCESS, the total score goes up.

9. Is the account in the process of decommissioning? (AFTER_TERMINATION)

Severity: LOW

If a user has a scheduled low date and continues to access PHI, it is flagged. It is one of the most common and worst covered threats: the ex-employee with live session.

How they combine: added scoring

Each rule adds points to a score by time window. A single Low rule does not scale. Three Low + a MEDIUM in the same window can cross the global alert threshold and mark the event as alerted=true, which is what triggers notification to the admin panel and CloudWatch.

This avoids two bad extremes: alert fatigue (everything is urgent, then nothing is) and subdetection (each rule separately does not alarm, but the sum should).

Break-glass auditing: the other half of the problem

Detecting the suspect is only half the job. The other half is to rebuild the story after.

In any health institution there are times when it is necessary to break the normal rule of access: an emergency, an internal investigation, a court order. This is called break-glass access, "break the glass." HIPAA allows it, but demands that it be registered who did it and when.

Brauni displays a break-glass view per patient. Given a patient_id, it returns who accessed its medical records, on what date and time, from which IP, from which device, and what operation it performed (READ, EXPORT, UPDATE...).

The problem of the observed observer

There is an easy technical detail to overlook that we learned quickly: the system you look at also has to be looked at.

When an administrator consults a patient's timeline, that query is itself an access to PHI. If it is not audited, the admin panel becomes the only place where data can be accessed without leaving a trace. That is exactly the hole that the system comes to plug.

In Brauni, each break-glass query:

1. It is recorded as an audit log of its own (READ over audit_timeline)
2. It is excluded from its own detection statistics, so that an administrator investigating 30 different timelines does not self-incriminate with a BULK_ACCESS
3. Validate the patient's existence before writing, to avoid "ghost" logs on patients who do not exist

Immediate response: four actions from the panel

Detecting is necessary but not sufficient. If the administrator sees a CRITICAL alert at 2 in the morning, he needs to act now, not to open three different tabs.

That is why four response actions can be fired from the event itself:

1. Revocation of all user sessions - invalidates the active JWT (bump of the token_version) and deletes all refresh tokens. The next request from the attacker receives a 401.
2. Reset 2FA - deletes TOTP, WebAuthn and backup codes. The legitimate user will have to reconfigure; the attacker with the stolen physical key is left out.
3. Unlock account - useful in the reverse scenario: after an accidental LOGIN_BURST on the account of a legitimate user.
4. Force password reset - triggers email flow with mandatory change link.

Each action requires explicit confirmation (confirm: true), CSRF token and leaves a trace at the event. An administrator cannot act on its own user_id (self-defense against committed admin accounts).

Event Lifecycle

An event goes through states: OPEN → ACKNOWLEDGED → RESOLVED or FALSE_POSITIVE. The first successful action automatically moves it to ACKNOWLEDGED (so the team sees that someone is working it). A closed event rejects new actions until an admin reopens it. This avoids "reopening the wound" unintentionally after the incident was formally closed.

How it fits in the Brauni architecture

The system runs on two levels:

• Capture plan: each operation on PHI writes a AuditLog in an append-only table. This happens in a synchronic manner with the user request, in the same transaction: it is a deliberate decision to ensure atomicity (if access is not recorded, the change on PHI is not concrete) and zero loss of events by worker drop. Cost is an extra write on the critical path of each request; if the volume comes to justify it, the natural step is to derive that record to an intermediate persistent tail, without resigning durability or immutability.
• Detection plan: An APScheduler job runs the detection engine over configurable time windows. It is executed by the worker process (separate from the API), with PostgreSQL leader choice by advisor lock, so that only one instance runs it at a time even if there are multiple replicas.

Each detected event also emits a metric to CloudWatch via metric filter, which triggers SNS alarms to the guard team. Thus a CRITICAL event does not depend on someone looking at the panel at 3 in the morning: the panel notifies the phone, not the other way around.

Monitoring system data does not contain PHI: only internal IDs, IPs, geolocation, device identifiers and counting. The rule is strict: the system that monitors access to sensitive data cannot itself be a second copy of that data.

How to choose a clinical software provider by looking at this

If you are evaluating a platform for your clinical or practice, ask this before signing:

1. Do they keep an unchangeable audit log of each access to clinical data? If the answer is "logs are in CloudWatch", it's not enough: CloudWatch is operational, it's not an audit log retained six years as HIPAA requires.
2. Do you have active detection rules on that log or just keep it? Saving without looking is like having security cameras off.
3. Can you show me whose timeline accessed a particular patient's file? If the answer takes more than a minute, they don't have actual break-glass.
4. What if an employee of mine resigns today? How do I know that no data was taken before leaving? The rule BULK_EXPORT and the answer revoke-sessions should be part of the answer.
5. Does the monitoring system audit itself? If the question takes them by surprise, I assumed not.

What does this mean to you?

It means that when you keep a session note in Brauni, that act is permanently recorded. If tomorrow you suspect that a data leaked, there is a way to reconstruct exactly what happened, who saw it and from where. If a computer account behaves strangely, the system detects it before someone checks the logs by hand. And if an incident is confirmed, access can be cut in seconds.

Encryption, BAA with infrastructure provider, do not use data to train AI, field-by-field encryption. All these are necessary conditions. Patient Privacy Monitoring is the layer that makes trust verifiable.

Because in the end, in health, the right question is not "Are the data safe?". It is "How do you know they are?" And that question is only answered with evidence.

Do you have any doubts about how we protect privacy or do you want to delve into some technical aspect of this system? Write to soporte@brauni.io. We are here to give you peace of mind.

---

Brauni complies with the principles of Argentina's Personal Data Protection Act 25.326 and is aligned with the international standards of HIPAA for the management of protected health information (PHI). The Patient Privacy Monitoring system covers the requirements of Audit Controls (45 CFR §164.312(b)), Information System Activity Review (§164.308(a)(1)(ii)(D)) and Security Incident Procedures (§164.308(a)(6)). Brauni provides the infrastructure and monitoring tools compatible with these standards; responsibility for data processing and activation of response protocols rests with each professional or institution, in its role as controller.