HIPAA Compliance Guide for Keratoconus Corneal Cross-Linking Practices

Which keratoconus corneal cross-linking practices must comply with HIPAA?

A keratoconus corneal cross-linking practice generally must comply with HIPAA if it is a health care provider that electronically conducts a standard transaction for which HHS has adopted a standard. Examples include electronic claims and certain payment-related transactions. A provider may still be covered when a billing service or clearinghouse conducts the transaction on its behalf. HIPAA covered entities also include health plans and health care clearinghouses. See HHS guidance on covered entities.

HIPAA coverage depends on the organization’s activities, not its specialty or size. A practice that conducts no standard transactions electronically may not meet the provider definition of a covered entity; assess the practice’s actual billing and transaction workflows rather than assuming every clinic is covered. A practice that is a business associate of another covered entity may have separate HIPAA obligations.

What patient information qualifies as protected health information in cross-linking care?

Protected health information (PHI) is individually identifiable health information held or transmitted by a covered entity or its business associate, in any form—electronic, paper, or oral. In cross-linking care, this can include a patient-linked diagnosis of keratoconus, treatment plan, procedure notes, informed consent, appointment details, billing or insurance records, and corneal imaging or test results. A record need not contain a Social Security number to be identifiable; a name or other identifier associated with health care information can make it PHI. See HHS guidance on identifiable health information.

Electronic protected health information (ePHI) includes that information when it is created, received, maintained, or transmitted electronically—for example, in an electronic health record, imaging system, patient portal, email, or backup. Information properly de-identified under HIPAA is treated differently, but simply removing a patient’s name may not be enough to de-identify a record.

How should practices assess and reduce electronic PHI security risks?

The HIPAA Security Rule requires covered entities and business associates to conduct an accurate and thorough HIPAA Security Rule risk analysis of potential risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI they create, receive, maintain, or transmit. HHS describes the risk analysis as a foundation for selecting and improving safeguards, not as a one-time checklist or a requirement to use a particular software tool. See HHS guidance on Security Rule risk analysis.

Start by mapping where ePHI is stored, accessed, and shared across the practice. Include cross-linking records and images, treatment-room workstations, scheduling and billing systems, email, mobile devices, backups, and vendor systems. Identify who can access each system and consider risks such as lost devices, misdirected messages, inappropriate staff access, system outages, and ransomware.

Document the risks found, current protections, and actions taken to reduce risk; assign responsibility and revisit the analysis when the practice changes systems, vendors, locations, or workflows, or when an incident reveals new vulnerabilities. HHS notes that the Security Rule is scalable: safeguards should be reasonable and appropriate to the practice’s circumstances and risks.

What safeguards should protect cross-linking records and treatment workflows?

The Security Rule calls for administrative, physical, and technical safeguards to protect ePHI. The specific measures should reflect the practice’s risk analysis. The following are practical examples, not a claim that every measure is separately required in every situation. See the HHS summary of the HIPAA Security Rule.

• Administrative safeguards: Assign security responsibilities; train workforce members on the practice’s policies; establish procedures for granting and removing access; and maintain incident-response and contingency plans. Review access and safeguards as the practice’s systems and risks change.
• Physical safeguards: Control access to rooms and devices where patient information is available. Position monitors to limit casual viewing, secure workstations and paper records, and use appropriate procedures before reusing or disposing of media.
• Technical safeguards: Use individual user accounts and role-appropriate permissions, protect systems against unauthorized access, and use audit capabilities to review activity. Consider encryption for devices and data transfers based on the risk analysis; the Security Rule’s addressable specifications require an assessment and documentation, not an assumption that an “addressable” measure can simply be ignored.

Apply the safeguards to the full treatment workflow—not just the main EHR. Patient-linked corneal images, procedure-room displays, exported files, referral communications, and recovery copies can all expose ePHI if access or handling is not controlled.

When does a vendor require a business associate agreement?

A business associate agreement (BAA) is generally required when a vendor creates, receives, maintains, or transmits PHI on behalf of a covered entity to perform a service or function involving that information. Potential examples include an EHR or imaging vendor, a billing or transcription service, an IT support company with access to systems containing ePHI, and a cloud provider that stores or processes ePHI. The parties should have the required written agreement before the vendor handles PHI on the practice’s behalf. See HHS business associate guidance.

A vendor’s inability to view encrypted information does not, by itself, rule out business associate status when it maintains ePHI for the practice. HHS distinguishes these services from a limited conduit that only transmits information with transient access. Review what the vendor actually does, what information it handles, and whether it acts for the practice. See HHS guidance on cloud computing and ePHI.

A BAA should address permitted uses and disclosures, safeguards, reporting of incidents and breaches, and other required terms. It does not transfer the practice’s responsibility to protect its own ePHI or conduct its own risk analysis. An app that merely enables a patient, at the patient’s request, to access information may have a different relationship; assess the facts rather than requiring a BAA from every technology company. See HHS sample BAA provisions and its guidance on patient-directed apps.

How should a practice assess and report a suspected PHI breach?

When staff suspect an exposure, promptly follow the practice’s incident-response procedures. Limit further access or disclosure where possible, preserve relevant records and system logs, and notify the person responsible for privacy or security. Determine what information and individuals may be involved, when the incident occurred and was discovered, and whether a vendor or other organization must be engaged.

An impermissible use or disclosure of PHI is generally presumed to be a breach unless an exception applies or the practice can demonstrate a low probability that the PHI was compromised through a documented unsecured PHI breach risk assessment. The assessment must consider at least the nature and extent of the PHI, who received or used it, whether it was actually acquired or viewed, and the extent to which the risk was mitigated. Document the investigation and the basis for the decision. See the HHS Breach Notification Rule guidance.

If notification is required, the practice must notify affected individuals without unreasonable delay and no later than 60 calendar days after discovery. This HIPAA breach notification deadline is an outer limit, not a reason to wait if notice can be provided sooner. Breaches affecting 500 or more individuals also require notice to HHS within that period; smaller breaches must be reported to HHS no later than 60 days after the end of the calendar year in which they were discovered. A breach affecting more than 500 residents of a state or jurisdiction also requires notice to prominent media outlets serving that area. See HHS notification requirements.

In summary, a practice should determine whether it is a covered entity, identify and protect patient-linked information across its treatment workflows, assess ePHI risks, manage vendor relationships with appropriate agreements, and investigate suspected exposures promptly. When a breach of unsecured PHI is reportable, document the assessment and meet the applicable notification requirements.

FAQs

Does HIPAA apply to every keratoconus corneal cross-linking practice?

No. A practice is generally a HIPAA covered entity if it is a health care provider that conducts certain standard transactions electronically, such as electronic claims transactions. The practice’s activities determine whether it meets that definition; its specialty alone does not. See HHS covered entity guidance.

What information from corneal cross-linking care counts as PHI?

Patient-identifiable information relating to care or payment can be PHI. Examples include a patient-linked keratoconus diagnosis, corneal images or test results, treatment and procedure records, consent forms, appointments, and billing information. PHI can be electronic, written, or spoken.

When must a practice sign a business associate agreement?

When a vendor creates, receives, maintains, or transmits PHI on the practice’s behalf to provide a service or function involving that information, the practice generally needs a BAA with the vendor. Determine this from the vendor’s actual role and access, rather than its job title or product label.

How soon must patients be notified after a reportable breach?

Notify affected individuals without unreasonable delay and no later than 60 calendar days after discovery of the breach. Depending on the number of individuals affected and where they reside, the practice may also need to notify HHS and, in some cases, the media.