How Does Athena Protects Patient Data in Epic & Cerner Integrated Deployments

What Epic data does Athena receive?

Athena receives a minimal, standard HL7 feed from the hospital's Epic (or Cerner) system containing only five data elements per patient: patient name, phone number, DOB, room number, and the list of visitors authorized to enter the room.

That is the complete feed. The interface is configured so that no medical records, diagnoses, treatment information, orders, schedules, or any other clinical data are ever transmitted. Athena also has no query access to the EHR — it is structurally limited to those five fields and cannot retrieve anything else.

What happens to that data?

Athena never retains raw patient data. The moment the feed is received, identifying data is protected with hardened one-way hashing that goes well beyond industry-standard practice, and the original plaintext is immediately and permanently deleted. The protected data is additionally encrypted before storage.

The result: plaintext patient census data never persists anywhere on Athena infrastructure. Patient data at rest exists only in hashed-and-encrypted form.

How does check-in work?

When a visitor arrives, they enter the name of the patient they're visiting. The system protects that entry the same way, matches it against the protected dataset, and returns the room number — and, where configured, verifies the visitor against the authorized-visitor list — so a badge can be printed.

The hospital's Epic system is never touched by the check-in transaction. Nothing is ever written back to the EHR, and the check-in stations have no connection path to the EHR environment.

What visitor data does Athena touch?

Beyond the five HL7 elements, Athena processes the visitor's driver's license information scanned at check-in — and the hospital controls exactly how much of it is kept. Every driver's license field is individually configurable: your compliance team chooses which fields are retained and which are permanently deleted the moment the badge is printed.

Visitor records are encrypted at the point of capture in such a way that Athena's servers cannot decrypt them — decryption is possible only on hospital-controlled devices.

Cloud reports expose only a visitor's first name and last initial.

How is the connection secured?

• All EHR data travels over a dedicated, encrypted site-to-site VPN
• Data flows one direction only — from the hospital to Athena, never back
• Network access is restricted so only known, pre-authorized devices can participate
• The EHR environment is fully insulated from Athena's cloud services and check-in stations

What about hospitals without Epic or Cerner?

For deployments without an EHR integration, no connection to the EHR environment exists at all. Front-desk staff enter the room number manually, and the same field-level retention controls apply to visitor data.

Deployment flexibility

For hospitals whose policies require it, Athena's integration layer can be deployed on-premise inside the hospital network. The standard cloud configuration, built on the hash-and-delete architecture described above, has satisfied most customers' compliance reviews.

The bottom line

• Only five non-clinical data elements ever leave Epic
• Raw patient data is protected and deleted on receipt — plaintext never persists in the Athena cloud
• The EHR is never queried and never written to
• The hospital controls visitor data retention field by field
• Visitor records can only be decrypted on hospital-controlled devices