HIPAA Fundamentals

The Health Insurance Portability and Accountability Act (HIPAA) is the cornerstone of healthcare data protection in the United States. Understanding its requirements is essential before building any healthcare application.

Learning Objectives:

Identify the 18 HIPAA identifiers
Understand covered entities and business associates
Know the Privacy Rule vs Security Rule
Understand breach notification requirements

What is HIPAA?

HIPAA was enacted in 1996 and has been updated multiple times, most significantly with the HITECH Act in 2009. It establishes national standards for protecting health information, ensuring portability of health coverage, and reducing fraud. Real-world context: In 2015, Anthem Inc. disclosed that hackers had accessed nearly 79 million patient records — names, birthdays, Social Security numbers, and employment details. The root cause was a single phishing email that gave attackers credentials to an unencrypted database. Anthem’s

16 million settlement remains one of the largest HIPAA penalties ever. The breach was entirely preventable with controls this module teaches: encryption at rest, multi-factor authentication, and workforce security training. Every section that follows maps directly to the kind of failure that turned a phishing email into a

16 million lesson.

HIPAA Framework showing Privacy Rule, Security Rule, and Breach Notification Rule — HIPAA Framework - The Three Core Rules

Protected Health Information (PHI)

PHI is any information about health status, provision of health care, or payment for health care that can be linked to an individual.

The 18 HIPAA Identifiers

When any of these identifiers is associated with health information, it becomes PHI:

Direct Identifiers
Additional Identifiers

#	Identifier	Examples
1	Names	Full name, maiden name, alias
2	Geographic data	Street address, city (smaller than state)
3	Dates	Birth date, admission date, discharge date, death date
4	Phone numbers	Home, mobile, work
5	Fax numbers	Any fax number
6	Email addresses	Personal or work email
7	Social Security numbers	SSN
8	Medical record numbers	MRN
9	Health plan beneficiary numbers	Insurance ID
10	Account numbers	Patient account numbers

#	Identifier	Examples
11	Certificate/license numbers	Driver’s license, professional license
12	Vehicle identifiers	License plate, VIN
13	Device identifiers	Medical device serial numbers
14	URLs	Personal websites
15	IP addresses	Any IP address
16	Biometric identifiers	Fingerprints, retinal scans, voiceprints
17	Full-face photos	Any identifiable images
18	Any unique identifier	Any other unique identifying number

PHI vs PII vs ePHI

# Understanding the differences

class DataClassification:
    """
    PII (Personally Identifiable Information):
    - Any data that can identify an individual
    - Regulated by various laws (GDPR, CCPA, etc.)
    
    PHI (Protected Health Information):
    - PII + Health Information
    - Regulated by HIPAA
    
    ePHI (Electronic PHI):
    - PHI in electronic form
    - Subject to HIPAA Security Rule
    """
    
    @staticmethod
    def is_phi(data: dict) -> bool:
        """Check if data contains PHI"""
        has_health_info = any([
            'diagnosis' in data,
            'treatment' in data,
            'prescription' in data,
            'medical_record' in data,
            'lab_results' in data,
        ])
        
        has_identifier = any([
            'name' in data,
            'ssn' in data,
            'email' in data,
            'phone' in data,
            'address' in data,
            'dob' in data,
            'mrn' in data,
        ])
        
        return has_health_info and has_identifier

# Examples
patient_record = {
    "name": "John Smith",           # Identifier
    "dob": "1985-03-15",            # Identifier  
    "diagnosis": "Hypertension",     # Health info
    "prescription": "Lisinopril"     # Health info
}
# This is PHI ✅

anonymous_stats = {
    "age_range": "40-50",
    "condition": "Diabetes",
    "region": "Northeast"
}
# This is NOT PHI (de-identified) ✅

Data classification diagram showing relationship between PII, PHI, and ePHI — Data Classification: PII vs PHI vs ePHI

Covered Entities & Business Associates

HIPAA Covered Entities and Business Associates relationship diagram — Covered Entities and Business Associates

Who Must Comply with HIPAA?

Covered entities and their business associates are directly subject to HIPAA regulations:

Business Associate Agreement (BAA)

If you’re building healthcare software, you’ll need a BAA with covered entities:

# Key elements of a Business Associate Agreement

class BusinessAssociateAgreement:
    """
    Required contractual elements between 
    Covered Entity and Business Associate
    """
    
    required_provisions = [
        "Permitted uses and disclosures of PHI",
        "Prohibition on unauthorized use/disclosure",
        "Implementation of appropriate safeguards",
        "Reporting of security incidents and breaches",
        "Ensuring subcontractors agree to same restrictions",
        "Access to PHI for individual rights requests",
        "Amendment of PHI when requested",
        "Accounting of disclosures",
        "Compliance with Security Rule requirements",
        "Return or destruction of PHI at termination",
    ]
    
    # Cloud Provider BAAs
    cloud_baa_support = {
        "AWS": "Available via AWS Artifact",
        "GCP": "Available via Cloud Console",
        "Azure": "Available via Trust Center",
        "Heroku": "Available with Shield plans",
        "MongoDB Atlas": "Available with dedicated plans",
    }

Critical: Never handle PHI without a signed BAA in place! This includes:

Development and testing with real PHI
Storing PHI in cloud services
Using third-party analytics on PHI

The Privacy Rule

The Privacy Rule establishes standards for protecting PHI and gives patients rights over their health information.

Key Privacy Principles

Minimum Necessary

Only use or disclose the minimum amount of PHI necessary to accomplish the intended purpose.

Notice of Privacy Practices

Patients must receive notice of how their PHI may be used and their rights.

Patient Rights

Patients can access, amend, and receive an accounting of disclosures of their PHI.

Authorization

Most uses beyond treatment, payment, and operations require patient authorization.

Permitted Uses Without Authorization

# PHI can be used/disclosed without authorization for:

class PermittedDisclosures:
    """Uses that don't require patient authorization"""
    
    WITHOUT_AUTHORIZATION = [
        # Treatment, Payment, Healthcare Operations (TPO)
        "treatment",           # Providing care
        "payment",             # Billing, claims
        "healthcare_ops",      # Quality assessment, training
        
        # Required by law
        "legal_requirement",   # Court orders, subpoenas
        "public_health",       # Disease reporting
        "abuse_reporting",     # Child/elder abuse
        "health_oversight",    # Audits, investigations
        
        # Special circumstances
        "research",            # With IRB approval + limited data
        "organ_donation",      # Organ procurement
        "coroners",            # Death investigations
        "national_security",   # Intelligence activities
    ]
    
    REQUIRES_AUTHORIZATION = [
        "marketing",           # Marketing communications
        "sale_of_phi",         # Selling PHI
        "psychotherapy_notes", # Mental health notes
        "third_party_apps",    # Patient-authorized apps
    ]

Patient Rights

┌─────────────────────────────────────────────────────────────────────────────┐
│                       PATIENT RIGHTS UNDER HIPAA                             │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  RIGHT TO ACCESS                        RIGHT TO AMEND                      │
│  ───────────────                        ──────────────                      │
│  • Request copies of PHI                • Request corrections               │
│  • Electronic format if requested       • Response within 60 days           │
│  • Response within 30 days              • Denial must be explained          │
│  • Reasonable fee allowed               • Amendment attached if denied      │
│                                                                              │
│  RIGHT TO ACCOUNTING                    RIGHT TO RESTRICT                   │
│  ──────────────────                     ─────────────────                   │
│  • List of disclosures                  • Request limits on use             │
│  • Last 6 years                         • Not required to agree             │
│  • Excludes TPO disclosures             • Must agree if patient pays        │
│                                           out-of-pocket in full             │
│                                                                              │
│  RIGHT TO CONFIDENTIAL                  RIGHT TO COMPLAIN                   │
│  COMMUNICATIONS                         ─────────────────                   │
│  ─────────────────                      • File with covered entity          │
│  • Alternative contact methods          • File with HHS OCR                 │
│  • Must accommodate reasonable          • No retaliation allowed            │
│    requests                                                                 │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

The Security Rule

The Security Rule specifies safeguards to protect ePHI. It requires three types of safeguards:

Administrative, Physical, and Technical safeguards for ePHI — HIPAA Security Safeguards - Three Pillars

Administrative Safeguards

# Administrative safeguards implementation checklist

class AdministrativeSafeguards:
    """
    Policies, procedures, and actions to manage 
    security measures and workforce conduct
    """
    
    requirements = {
        "security_management": {
            "risk_analysis": "Identify PHI risks",
            "risk_management": "Implement security measures",
            "sanction_policy": "Consequences for violations",
            "information_system_review": "Regular audits",
        },
        
        "workforce_security": {
            "authorization": "Role-based access",
            "clearance": "Background checks",
            "termination": "Revoke access on departure",
        },
        
        "information_access": {
            "access_authorization": "Who grants access",
            "access_establishment": "How access is granted",
            "access_modification": "How access is changed",
        },
        
        "security_awareness": {
            "security_reminders": "Regular training",
            "malware_protection": "Security software",
            "login_monitoring": "Track failed logins",
            "password_management": "Strong password policies",
        },
        
        "contingency_plan": {
            "data_backup": "Regular backups",
            "disaster_recovery": "Recovery procedures",
            "emergency_mode": "Emergency operations",
            "testing": "Regular testing",
            "criticality_analysis": "Priority systems",
        },
    }

Physical Safeguards

class PhysicalSafeguards:
    """
    Physical measures to protect electronic systems 
    and buildings housing ePHI
    """
    
    requirements = {
        "facility_access": {
            "contingency_operations": "Emergency access procedures",
            "facility_security_plan": "Physical security measures",
            "access_control": "Badge systems, locks",
            "maintenance_records": "Log repairs and modifications",
        },
        
        "workstation_use": {
            "policies": "Appropriate workstation use",
            "location": "Screen positioning, secure areas",
        },
        
        "workstation_security": {
            "physical_access": "Restrict workstation access",
            "automatic_logoff": "Screen locks",
        },
        
        "device_controls": {
            "disposal": "Secure destruction of media",
            "media_reuse": "Sanitize before reuse",
            "accountability": "Track device movement",
            "backup_storage": "Secure backup locations",
        },
    }

Technical Safeguards

class TechnicalSafeguards:
    """
    Technology and policies for electronic PHI access control
    """
    
    requirements = {
        "access_control": {
            "unique_user_id": "Individual user accounts",
            "emergency_access": "Break-glass procedures",
            "automatic_logoff": "Session timeouts",
            "encryption": "Encrypt ePHI at rest",
        },
        
        "audit_controls": {
            "logging": "Record PHI access",
            "log_analysis": "Review audit logs",
            "log_protection": "Tamper-proof logs",
        },
        
        "integrity": {
            "authentication": "Verify PHI not altered",
            "checksums": "Data integrity verification",
        },
        
        "transmission_security": {
            "integrity_controls": "Verify transmission integrity",
            "encryption": "Encrypt PHI in transit",
        },
        
        "authentication": {
            "person_or_entity": "Verify identity of users",
            "mfa": "Multi-factor authentication",
        },
    }

# Implementation example
class HIPAACompliantSystem:
    """Example implementation of technical safeguards"""
    
    def __init__(self):
        self.session_timeout = 900  # 15 minutes
        self.password_min_length = 12
        self.mfa_required = True
        self.encryption_algorithm = "AES-256-GCM"
        self.tls_version = "1.3"
        
    def access_control(self, user, resource):
        """Implement access control requirements"""
        if not self.verify_user_identity(user):
            self.log_failed_access(user, resource)
            raise AuthenticationError("Identity not verified")
            
        if not self.check_authorization(user, resource):
            self.log_unauthorized_access(user, resource)
            raise AuthorizationError("Access denied")
            
        self.log_access(user, resource)
        return self.decrypt_and_return(resource)

Breach Notification Rule

When a breach occurs, specific notification requirements apply:

What Constitutes a Breach?

class BreachAssessment:
    """
    A breach is unauthorized acquisition, access, use, or 
    disclosure of PHI that compromises its security or privacy
    """
    
    # Exceptions (NOT a breach)
    exceptions = [
        "unintentional_internal",  # Workforce member acting in good faith
        "inadvertent_disclosure",  # Internal disclosure, not further used
        "good_faith_belief",       # Unauthorized person couldn't retain data
    ]
    
    # Risk assessment factors
    def assess_breach(self, incident: dict) -> dict:
        """Perform 4-factor risk assessment"""
        
        return {
            "nature_of_phi": self._assess_phi_type(incident),
            "unauthorized_recipient": self._assess_recipient(incident),
            "phi_actually_acquired": self._assess_acquisition(incident),
            "risk_mitigated": self._assess_mitigation(incident),
        }
    
    def _assess_phi_type(self, incident):
        """What types of identifiers and health info were involved?"""
        high_risk_elements = [
            "ssn", "financial_info", "sensitive_diagnoses",
            "mental_health", "hiv_status", "substance_abuse"
        ]
        # More sensitive = higher risk
        
    def _assess_recipient(self, incident):
        """Who received the PHI?"""
        # Healthcare provider = lower risk
        # Unknown party = higher risk
        
    def _assess_acquisition(self, incident):
        """Was PHI actually viewed or just transmitted?"""
        # Encrypted and key not compromised = lower risk
        # Actually viewed = higher risk
        
    def _assess_mitigation(self, incident):
        """What steps were taken to mitigate harm?"""
        # PHI recovered and destroyed = lower risk

Notification Requirements

HIPAA breach notification timeline and requirements — Breach Notification Timeline

Key timelines and requirements vary by the scale of the breach.

Notification Content

class BreachNotification:
    """Required content for breach notifications"""
    
    required_content = [
        "description_of_breach",         # What happened
        "types_of_phi_involved",         # What info was exposed
        "steps_individuals_should_take", # Self-protection steps
        "what_entity_is_doing",          # Mitigation efforts
        "contact_procedures",            # How to get more info
    ]
    
    def generate_notification(self, breach: dict) -> str:
        """Generate compliant breach notification"""
        
        template = """
        NOTICE OF DATA BREACH
        
        Date of Notice: {date}
        
        What Happened:
        {description}
        
        What Information Was Involved:
        {phi_types}
        
        What We Are Doing:
        {mitigation_steps}
        
        What You Can Do:
        {protective_steps}
        
        For More Information:
        {contact_info}
        """
        
        return template.format(**breach)

Penalties and Enforcement

HIPAA violations can result in both civil and criminal penalties.

HIPAA violation tiers and penalty ranges — HIPAA Penalty Structure

Civil Penalties

Tier	Violation Type	Penalty per Violation	Annual Maximum
1	Did not know	$100 -$ 50,000	$25,000
2	Reasonable cause	$1,000 -$ 50,000	$100,000
3	Willful neglect (corrected)	$10,000 -$ 50,000	$250,000
4	Willful neglect (not corrected)	$50,000+	$1,500,000

Criminal Penalties

Tier	Violation Type	Maximum Penalty
1	Knowingly obtaining/disclosing PHI	Up to $50,000 + 1 year prison
2	Under false pretenses	Up to $100,000 + 5 years prison
3	For personal gain or harm	Up to $250,000 + 10 years prison

Notable HIPAA Settlements

# Real HIPAA enforcement examples

major_settlements = [
    {
        "entity": "Anthem Inc.",
        "year": 2018,
        "amount": 16_000_000,
        "violation": "Data breach affecting 79M individuals",
        "lesson": "Risk analysis and access controls",
    },
    {
        "entity": "Premera Blue Cross",
        "year": 2020,
        "amount": 6_850_000,
        "violation": "Breach affecting 10.4M individuals",
        "lesson": "Timely risk assessment updates",
    },
    {
        "entity": "Advocate Medical Group",
        "year": 2016,
        "amount": 5_550_000,
        "violation": "Unencrypted laptops stolen",
        "lesson": "Encrypt all portable devices",
    },
    {
        "entity": "Memorial Healthcare System",
        "year": 2017,
        "amount": 5_500_000,
        "violation": "Employees accessed PHI without authorization",
        "lesson": "Audit controls and access monitoring",
    },
]

De-identification

De-identified data is not PHI and not subject to HIPAA. There are two methods:

Expert Determination

A qualified expert determines that the risk of re-identification is very small.

Safe Harbor Method

Remove all 18 identifiers and have no actual knowledge that remaining information could identify an individual.

class DeIdentification:
    """HIPAA Safe Harbor de-identification"""
    
    identifiers_to_remove = [
        "names",
        "geographic_subdivisions_smaller_than_state",
        "dates_except_year",  # if over 89, use 90+
        "phone_numbers",
        "fax_numbers",
        "email_addresses",
        "ssn",
        "medical_record_numbers",
        "health_plan_beneficiary_numbers",
        "account_numbers",
        "certificate_license_numbers",
        "vehicle_identifiers",
        "device_identifiers",
        "urls",
        "ip_addresses",
        "biometric_identifiers",
        "full_face_photos",
        "other_unique_identifiers",
    ]
    
    def safe_harbor_deidentify(self, record: dict) -> dict:
        """Remove all 18 identifiers"""
        deidentified = record.copy()
        
        for identifier in self.identifiers_to_remove:
            if identifier in deidentified:
                del deidentified[identifier]
        
        # Handle dates - keep only year
        if "date_of_birth" in deidentified:
            year = deidentified["date_of_birth"].year
            if year < 1935:  # Over 89 years old
                deidentified["age_group"] = "90+"
            else:
                deidentified["birth_year"] = year
            del deidentified["date_of_birth"]
        
        # Handle geographic data - keep only state
        if "address" in deidentified:
            deidentified["state"] = deidentified["address"].get("state")
            del deidentified["address"]
            
        return deidentified

Key Takeaways

Know Your Data

Identify all PHI in your systems and document data flows

Sign BAAs

Never handle PHI without appropriate agreements in place

Implement Safeguards

Administrative, physical, and technical controls are all required

Plan for Breaches

Have an incident response plan before you need it

Practice Exercise

Identify PHI

Review a sample patient record and identify all 18 HIPAA identifiers present.

Classify Data

Categorize the data as PHI, PII, or non-sensitive.

De-identify

Apply Safe Harbor method to de-identify the record.

Document Controls

List the administrative, physical, and technical safeguards your system needs.

Next Steps

Encryption

Learn how to encrypt data at rest and in transit

Audit Logging

Build tamper-proof audit trails

Interview Deep-Dive

A developer on your team says: 'We anonymized the data by removing patient names and SSNs, so it is no longer PHI and HIPAA does not apply.' Is this correct? Where is the flaw in their reasoning?

Strong Answer:

This is a dangerously common misconception. Removing names and SSNs is necessary but nowhere near sufficient for de-identification under HIPAA. The Safe Harbor method requires removal of all 18 identifiers — not just the obvious ones. That includes dates (birth, admission, discharge), phone numbers, email addresses, geographic data more specific than state, IP addresses, device identifiers, medical record numbers, biometric data, full-face photographs, and any other unique identifying number or code.
Even after removing all 18 identifiers, you must also have no actual knowledge that the remaining information could be used to re-identify an individual. For example, if you have a dataset from a small rural clinic with one oncologist and your records include “Stage 4 pancreatic cancer, male, age range 60-70, state: Wyoming,” that combination might uniquely identify someone even without a name attached.
The alternative is Expert Determination (the other HIPAA de-identification method), where a qualified statistical expert certifies that the risk of re-identification is very small. This is more rigorous but allows you to retain more data elements.
The real-world gotcha: I have seen teams strip names and SSNs from a dataset but leave in medical record numbers (MRN), which are one of the 18 identifiers. Or they leave dates of service intact, which are also identifiers. The data remains PHI and HIPAA absolutely still applies.

Follow-up: The team needs to use realistic-looking data for testing. What approach do you recommend instead of using production PHI?The gold standard is synthetic data generation — tools that produce statistically realistic healthcare data without any connection to real patients. Libraries like Synthea generate complete synthetic patient records including demographics, conditions, encounters, and medications. Alternatively, you can use properly de-identified data (all 18 identifiers removed) with an expert determination letter. A third option is a formal test data policy that uses production-derived data only in environments with the same HIPAA safeguards as production — same encryption, same access controls, same audit logging. But this third option is expensive and I would exhaust the first two before going there.

Walk me through the four-factor risk assessment you must conduct when a potential breach occurs. How does each factor influence your notification decision?

Strong Answer:

When an incident involving PHI occurs, HIPAA requires a four-factor risk assessment to determine whether it constitutes a reportable breach. The presumption is that any impermissible use or disclosure is a breach unless you can demonstrate a low probability that the PHI was compromised.
Factor one: the nature and extent of the PHI involved. What types of identifiers were exposed? A dataset with names plus SSNs plus HIV status is far higher risk than one with names plus general visit dates. Financial identifiers (SSN, account numbers) and sensitive diagnoses (mental health, substance abuse, HIV) increase the severity significantly.
Factor two: the unauthorized person who used the PHI or to whom the disclosure was made. Was it another healthcare provider (lower risk, they are bound by their own HIPAA obligations) or an unknown external party (higher risk)? A misdirected fax to another hospital is very different from data posted to a public website.
Factor three: whether the PHI was actually acquired or viewed. If an encrypted laptop is stolen but there is no evidence the thief accessed the data, the risk is lower. If audit logs show the data was opened and copied, the risk is much higher. This is where forensic evidence matters.
Factor four: the extent to which risk has been mitigated. Did you retrieve the data? Get a signed attestation of destruction? Confirm the recipient could not have retained a copy? Successful mitigation can tip the assessment toward non-reportable.
All four factors must be documented regardless of the outcome. If you determine it is not a breach, you must retain the documentation proving your analysis. OCR auditors will ask for it.

Follow-up: You determine it IS a reportable breach affecting 600 patients. Walk me through your notification obligations and timeline.Because it exceeds 500 individuals, I have three concurrent notification obligations. First, individual notification: written notice to each of the 600 affected patients within 60 days of discovery. The notice must describe what happened, what PHI was involved, what protective steps individuals should take, what we are doing to mitigate harm, and contact procedures. Second, HHS notification: submit a breach report to the HHS Office for Civil Rights via their online portal within 60 days. This goes on the public “Wall of Shame” breach portal because it exceeds 500 individuals. Third, media notification: because 600 patients likely includes 500 or more residents of a single state, I must notify prominent media outlets serving that state within 60 days. I would also consider offering credit monitoring if financial identifiers were involved, though HIPAA does not mandate it — it is a best practice that demonstrates good faith.

Your organization is a SaaS company that builds scheduling software. A hospital wants to use your product and mentions HIPAA. Are you a Covered Entity or a Business Associate? What obligations does this create?

Strong Answer:

A SaaS scheduling company is not a Covered Entity. Covered Entities are health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically. A software vendor is none of those.
However, the moment the hospital uses our scheduling software and patient information flows through it — patient names, appointment times, provider names, reasons for visit — we become a Business Associate. We are creating, receiving, maintaining, or transmitting PHI on behalf of a Covered Entity.
This triggers several obligations. First, we must sign a BAA with the hospital before any PHI enters our system. The BAA defines permitted uses, required safeguards, breach notification obligations, and data return or destruction requirements upon termination.
Second, the HITECH Act made Business Associates directly liable for HIPAA Security Rule compliance. We must implement administrative, physical, and technical safeguards for the ePHI we handle. We are subject to the same civil and criminal penalties as Covered Entities.
Third, if we use subcontractors (cloud hosting, email providers, backup services) that will access PHI, we need BAAs with each of them. The subcontractor chain must be fully covered.
The practical impact on our product: we need encryption at rest and in transit, access controls, audit logging, a risk assessment, workforce training, and an incident response plan. Our infrastructure must be HIPAA-eligible (not all cloud service tiers qualify). We need a designated security officer.

Follow-up: If a patient’s appointment reason says “HIV screening” — is the appointment time alone considered PHI, or does it need to be combined with health information?This is a nuance people miss. The appointment time alone with a patient name is not PHI — it is PII. But the moment you add “reason for visit: HIV screening,” you have combined an identifier (name) with health information (the screening). That combination is PHI. Even without the explicit reason, if the scheduling system routes certain appointment types to specific departments (say, all HIV-related appointments go to the infectious disease clinic), then the appointment metadata itself could reveal health information by inference. This is why scheduling software that handles any healthcare context typically falls under HIPAA — it is very difficult to guarantee that no health information leaks into scheduling data.

A patient requests a complete copy of all their PHI under their HIPAA right of access. Your engineering team says it will take 6 months to build an export feature. How do you handle this?

Strong Answer:

HIPAA gives patients the right to access their PHI, and you must respond within 30 days of the request (with a possible 30-day extension if you notify the patient in writing with a reason). Six months is not an option.
The immediate fix is a manual process. Even without an automated export feature, you can have authorized staff compile the patient’s records from your systems and provide them in the requested format. If the patient requests electronic format and your system stores data electronically, you must provide it electronically. A paper printout when electronic was requested is a violation.
For the engineering roadmap, I would prioritize building a self-service export feature, but in the interim, create a documented manual procedure: who receives the request, who compiles the data, who reviews it for completeness, what format it is delivered in, and how we track the 30-day clock. This procedure gets documented in your policies and procedures.
You can charge a reasonable cost-based fee for the copy, but it must be limited to the cost of labor for copying, supplies, and postage. You cannot charge for searching or retrieving the records.
The penalty for denying or unreasonably delaying access is real. OCR has pursued enforcement actions specifically for right-of-access violations, with penalties ranging from $15,000 to over$ 200,000 per violation under their Right of Access Initiative.

Follow-up: The patient requests their data in a specific electronic format your system does not support. What are your obligations?If you can readily produce the data in the requested format, you must do so. If you cannot, you must offer an alternative electronic format that the patient agrees to. The key word is “readily” — you are not required to build entirely new export capabilities, but you must make a good-faith effort. Common acceptable formats include PDF, CSV, or a CDA (Clinical Document Architecture) file. If you truly cannot produce any electronic format the patient agrees to, you must offer a hard copy. But given that most healthcare data is stored electronically, an inability to export it in any electronic format would raise serious questions about your system’s design and would be difficult to defend in an audit.

​HIPAA Fundamentals

​What is HIPAA?

​Protected Health Information (PHI)

​The 18 HIPAA Identifiers

​PHI vs PII vs ePHI

​Covered Entities & Business Associates

​Who Must Comply with HIPAA?

​Business Associate Agreement (BAA)

​The Privacy Rule

​Key Privacy Principles

Minimum Necessary

Notice of Privacy Practices

Patient Rights

Authorization

​Permitted Uses Without Authorization

​Patient Rights

​The Security Rule

​Administrative Safeguards

​Physical Safeguards

​Technical Safeguards

​Breach Notification Rule

​What Constitutes a Breach?

​Notification Requirements

​Notification Content

​Penalties and Enforcement

​Civil Penalties

​Criminal Penalties

​Notable HIPAA Settlements

​De-identification

​Expert Determination

​Safe Harbor Method

​Key Takeaways

Know Your Data

Sign BAAs

Implement Safeguards

Plan for Breaches

​Practice Exercise

​Next Steps

Encryption

Audit Logging

​Interview Deep-Dive

HIPAA Fundamentals

What is HIPAA?

Protected Health Information (PHI)

The 18 HIPAA Identifiers

PHI vs PII vs ePHI

Covered Entities & Business Associates

Who Must Comply with HIPAA?

Business Associate Agreement (BAA)

The Privacy Rule

Key Privacy Principles

Permitted Uses Without Authorization

Patient Rights

The Security Rule

Administrative Safeguards

Physical Safeguards

Technical Safeguards

Breach Notification Rule

What Constitutes a Breach?

Notification Requirements

Notification Content

Penalties and Enforcement

Civil Penalties

Criminal Penalties

Notable HIPAA Settlements

De-identification

Expert Determination

Safe Harbor Method

Key Takeaways

Practice Exercise

Next Steps

Interview Deep-Dive