MD Hyperbaric HIPAA Policy Pack

Purpose

This policy pack sets the minimum HIPAA operating standards for MD Hyperbaric and for centers participating in insurance workflows.

The goal is to make the expected behavior clear enough for corporate staff, center managers, and technicians to follow during normal work, patient requests, incidents, downtime, onboarding, offboarding, and vendor review.

These documents are internal draft operational policies for review. They are not legal advice and should be reviewed by qualified counsel before final adoption or external distribution.

Read This First

Minimum Standard for Participating Centers

Centers participating in insurance workflows are required to follow the minimum MD Hyperbaric HIPAA standards in this pack. Centers may have additional obligations under their own business, franchise, employment, state law, vendor contract, or payer requirements.

The policies recognize that participating centers operate as individual businesses. They still set minimum expectations for PHI handling, workforce behavior, incident escalation, access management, device security, physical safeguards, and evidence cooperation when participating in MD Hyperbaric insurance workflows.

What This Pack Covers

• Practical PHI handling rules.
• Minimum necessary use and disclosure.
• Texting and personal-phone limits.
• Incident reporting and breach-response escalation.
• Patient record request handling.
• Access onboarding, offboarding, shared-account exceptions, and access review.
• Device, workstation, personal-phone, physical-security, and network safeguards.
• Vendor/BAA inventory, training evidence, logs, and review cadence.
• Open implementation items that are not yet fully remediated.

What This Pack Does Not Cover

• Legal advice.
• A substitute for attorney review of the Notice of Privacy Practices, website privacy policy, sanctions language, or franchise acknowledgement language.
• A substitute for signed vendor contracts, BAAs, SOC reports, or security evidence.
• A full technical backup manual. Backup and disaster recovery procedures are maintained in MDH Backup and Disaster Recovery Plan.md.
• A Part 2/SUD policy. MD Hyperbaric does not currently provide SUD treatment or maintain Part 2 records. This should be revisited only if services or record types change.
• A PCI compliance program. Payment-card processing must first be inventoried to determine whether additional PCI work is needed.

Document Map

Source Anchors

This draft was prepared from the local HIPAA investigation tracker, backup/DR plan, current policy-drafting framework, and current official HHS/eCFR source anchors checked on 2026-05-08.

Primary regulatory anchors:

• 45 CFR 164.308: administrative safeguards.
• 45 CFR 164.316: policies, procedures, documentation, six-year retention, availability, and updates.
• HHS HIPAA Security Rule summary.
• HHS right-of-access guidance.
• HHS Breach Notification Rule guidance.
• HHS model Notice of Privacy Practices page, including February 2026 Part 2/NPP updates.
• HHS HIPAA Security Rule NPRM fact sheet. The NPRM is treated as proposed direction, not final binding rule.

MD Hyperbaric HIPAA Operating Policy

1. Purpose

This policy defines the minimum HIPAA operating standards MD Hyperbaric expects people to follow when creating, receiving, maintaining, using, disclosing, or transmitting protected health information.

2. Scope

This policy applies to:

• HQ staff who handle patient, insurance, referral, billing, clinical, technical, vendor, or compliance information.
• Center managers and technicians at centers participating in insurance workflows.
• Contractors or support personnel who are approved to access MD Hyperbaric PHI or systems.
• Work done from offices, centers, homes, mobile devices, laptops, tablets, and vendor-hosted systems.

Centers participating in insurance workflows are required to follow these minimum standards. A center may apply stricter rules.

3. Key Roles

4. What Counts as PHI

PHI is individually identifiable health information connected to a patient or prospective patient.

In practical MD Hyperbaric work, PHI can include:

• Name, date of birth, phone number, email address, address, insurance details, account number, or identifiers when connected to health care.
• Diagnosis, treatment details, clearance status, protocol details, session notes, vitals, outcomes, appointment details, referral details, and medical records.
• Screenshots, photos, exports, downloads, spreadsheets, paper forms, emails, texts, portal messages, call notes, and support tickets that include patient-identifying health information.

Treat uncertain information as PHI until Operations or the technical/security owner confirms otherwise.

5. Minimum Necessary Rule

Use, access, disclose, export, print, or share only the minimum PHI needed for the task.

Do:

• Access only patients, centers, records, reports, and systems needed for your role.
• Share the smallest amount of information needed to complete the work.
• Use approved workflows for referrals, insurance, records, scheduling, clinical documentation, and support.
• Ask Operations before sending PHI to a new recipient or through a new channel.

Do not:

• Browse patient records out of curiosity.
• Export or download PHI because it is convenient.
• Send full records when a narrower record set will satisfy the request.
• Use patient examples in training, screenshots, chats, documents, or support requests unless approved and de-identified.

6. Permitted PHI Handling

PHI may be used or disclosed only for approved work purposes, such as treatment, payment, health care operations, patient record request fulfillment, authorized vendor support, required reporting, or approved compliance activity.

Approved handling must use the least risky available workflow:

• Use approved systems and accounts.
• Use individual accounts wherever available.
• Keep PHI in approved systems rather than local files.
• Store paper records securely until uploaded, filed, shredded, or otherwise handled under local procedure.
• Keep records, logs, and policy evidence for the required retention period.

7. Prohibited PHI Handling

Do not:

• Put PHI into ordinary SMS/text messages except in a genuine emergency when no safer option is available.
• Send patient photos, screenshots, records, DOB, diagnosis, insurance details, treatment details, or record extracts through ordinary text.
• Use personal email for PHI.
• Store PHI in personal cloud drives, personal notes apps, personal messaging apps, or unapproved tools.
• Copy PHI into generative AI tools, public websites, or vendor support forms unless the tool and workflow are approved for PHI.
• Print, photograph, screenshot, or export PHI without a work need.
• Leave paper records, unlocked screens, tablets, laptops, or printed PHI visible to patients, visitors, or unauthorized staff.
• Share passwords except under a currently authorized shared-account exception.

8. Texting and Personal Phones

Ordinary SMS/text is not an approved PHI channel.

Center managers may use personal phones only for minimal non-PHI logistics, such as appointment timing or location coordination, unless an emergency requires more. Keep messages short and do not include clinical, insurance, diagnosis, DOB, record, or treatment information.

Technicians should not use personal phones for work PHI. Emergency use must be reported to Operations after the immediate risk is resolved.

If PHI is accidentally sent by text or to the wrong recipient, report it immediately under the incident SOP.

9. Patient Record Requests

Patient record requests must be escalated to Operations.

Operations must:

• Verify the requester identity.
• Log the request date, requester, records requested, requested format, due date, fulfillment date, method, and notes.
• Work toward the general 30-calendar-day HIPAA access timeline.
• Use secure delivery by default once an approved secure delivery vendor/workflow is implemented.
• Until secure delivery is implemented, avoid routine standard-email delivery of records. If a patient specifically requests standard email after a risk warning, document the request and warning.

Staff should not independently fulfill patient record requests unless Operations assigns the task.

10. Access Management

Access must match role need.

Do:

• Request access through the approved onboarding/access process.
• Use individual accounts wherever the system supports them.
• Use MFA where available or required.
• Report access that appears too broad, stale, or inappropriate.
• Notify Operations promptly when staff leave, change roles, or no longer need access.

Do not:

• Use another person's individual account.
• Let another person use your account.
• Keep access after your role changes or work ends.
• Create informal accounts, shared logins, or local workarounds without approval.

11. Shared-Account Exceptions

Individual accounts are the target state. Shared accounts remain temporary exceptions only where a system or current workflow does not yet support individual accounts.

Shared-account compensating controls:

• Limit use to assigned people and assigned workflows.
• Keep manager oversight over who is permitted to use the account.
• Change the password when staff leave or no longer need access.
• Do not use the account outside the assigned center or workflow.
• Report suspected misuse immediately.
• Track shared accounts in access review until replaced.

Shared accounts are not the desired end state.

12. Device and Workstation Security

Devices used for PHI must meet minimum safeguards:

• Managed endpoint protection where deployed.
• Full disk encryption where available.
• Current security updates and patching.
• Screen locks when unattended.
• No unattended unlocked workstations.
• Lost or stolen device reporting.
• Secure storage of laptops, tablets, and paper records.

Do not save PHI locally unless there is a specific approved reason and a secure storage method.

13. Physical Security

Centers must protect PHI from casual viewing, theft, loss, and improper disposal.

Minimum expectations:

• Position screens away from patients and visitors.
• Use privacy filters where needed.
• Lock or supervise devices.
• Store tablets/laptops securely overnight.
• Keep network equipment in staff-only or locked areas where practical.
• Separate staff and guest Wi-Fi where available.
• Keep paper records secured until uploaded, shredded, filed, or otherwise handled under procedure.
• Do not leave printed PHI at printers, desks, treatment areas, or public spaces.

14. Data Classification

Use these practical classifications:

15. Retention and Destruction

Retain HIPAA policies, procedures, assessments, logs, incident records, access review records, training records, and other required compliance documentation for at least six years from creation or last effective date, whichever is later, unless counsel or law requires longer.

Paper PHI must be shredded or securely disposed of after upload, filing, or retention requirements are satisfied. Electronic PHI must be deleted or archived only through approved workflows.

Do not independently delete evidence related to incidents, access reviews, requests, audits, or litigation holds.

16. Training

All required workforce groups must complete assigned HIPAA training through the approved HIPAA training portal.

Training evidence should include staff name, course name, completion date, status or certificate, and overdue escalation notes. Do not create a separate annual policy acknowledgement process unless counsel later requires it.

17. Incidents

Report suspected or known incidents immediately to Operations. Technical/security incidents must also involve the technical/security owner.

Examples include:

• Wrong patient text or email.
• Lost or stolen laptop, tablet, phone, paper record, or credential.
• Suspected unauthorized access.
• Shared-account misuse.
• Malware, ransomware, suspicious login, or vendor breach notice.
• Paper PHI left unsecured.
• PHI sent through the wrong channel or to the wrong recipient.

Do not delete messages, logs, files, or evidence. Do not self-fix quietly.

18. Vendors and BAAs

Vendors that create, receive, maintain, or transmit PHI must be tracked in the vendor/BAA register.

Before using a new vendor or system for PHI, confirm:

• Business owner.
• PHI involved.
• Access type.
• BAA status.
• Security or DR evidence needed.
• Review cadence.

Vendor names may appear in evidence registers and vendor templates, but staff-facing instructions should stay vendor-neutral unless a specific named workflow is approved for the audience.

19. Sanctions and Corrective Action

MD Hyperbaric may apply corrective action when workforce members fail to follow HIPAA policies or procedures.

Corrective action should be proportionate and may include coaching, retraining, access changes, written corrective action, disciplinary action, or other measures allowed by applicable policy, contract, and law.

Sanctions language should be reviewed by counsel before final adoption.

20. Documentation and Review

This policy pack and related evidence must be:

• Written or electronic.
• Available to people responsible for implementing the procedures.
• Retained for at least six years from creation or last effective date, whichever is later.
• Reviewed at least annually and after material operational, system, vendor, regulatory, or incident-driven changes.

21. Regulatory Source Notes

This policy is based on the current HIPAA Security Rule structure, including administrative safeguards, documentation requirements, and contingency-planning expectations. It also reflects HHS right-of-access and breach-notification guidance.

The HHS Security Rule cybersecurity update is currently treated as a notice of proposed rulemaking, not a final binding rule.

Formal HIPAA Risk Assessment Drafting Brief

Source Evidence

Use HIPAA Investigation Findings.md as the primary evidence base. Use related backup/DR, vendor, and evidence files only to confirm implementation status or open gaps.

Do not invent system details. If a system, data flow, owner, control, likelihood, impact, or residual risk cannot be confirmed from local evidence, mark it as unknown or pending evidence.

Do not include PHI, secrets, database URLs, decrypted exports, service-account keys, or patient-level examples.

Assessment Scope

The formal risk assessment should cover systems, workflows, and operational controls that create, receive, maintain, transmit, access, back up, or review ePHI for MD Hyperbaric and centers participating in insurance workflows.

Minimum domains:

• Workforce access and shared accounts.
• MFA and authentication.
• Endpoint, workstation, and mobile-device safeguards.
• Clinic network and physical safeguards.
• Patient record request handling.
• Incident reporting and breach response.
• Vendor and BAA management.
• Backup, disaster recovery, and emergency mode operation.
• Training and sanctions.
• Data classification, retention, and destruction.
• Payment-card processing inventory only to determine whether separate PCI work is needed.

Finding-to-Risk Mapping

For each open, partial, pending-evidence, or recently closed item in HIPAA Investigation Findings.md, capture:

Current High-Priority Inputs

The current investigation tracker highlights these high-priority remaining risk areas:

• Shared PHI-system accounts and user deprovisioning.
• MFA enforcement for PHI-accessing systems and Google Workspace.
• Endpoint security, full disk encryption, patching, firewall/network protection, and screen locks.
• Workforce HIPAA training and annual refresher process.
• Incident reporting and breach-response procedures.
• Patient record request handling and secure delivery.
• Formal policies and procedures.
• Location-level physical security and network checks.
• Vendor session and access evidence.
• Backup/DR tabletop exercise, paper emergency check-in forms, and cloud organization/BAA cleanup.

Output Structure

Recommended formal risk assessment sections:

1. Purpose and scope.
2. Methodology and scoring scale.
3. Systems and data-flow summary.
4. Risk register table.
5. Current controls summary.
6. Remediation plan.
7. Accepted/deferred risks.
8. Evidence index.
9. Review and update cadence.

Keep the formal assessment separate from staff-facing policies. Staff-facing documents should tell people what to do; the risk assessment should document why the controls and remediation priorities are reasonable.

Review Rules

• Use current local evidence, not assumptions.
• Mark counsel, vendor, or technical evidence gaps honestly.
• Do not claim a control is complete unless evidence shows it.
• Treat the Security Rule NPRM as useful direction, not final binding law.
• Retain final assessments and updates for at least six years.

HQ Staff HIPAA Guide

Do

• Protect PHI, credentials, vendor evidence, contracts, and compliance records.
• Use approved systems and approved access methods.
• Access only the records, reports, centers, and systems needed for your role.
• Share only the minimum PHI needed for the task.
• Escalate suspected incidents to Operations immediately.
• Escalate technical or security issues to the technical/security owner.
• Use the approved HIPAA training portal for required training.
• Support vendor/BAA evidence collection, policy review, access review, and training evidence when assigned.
• Store documents containing PHI or confidential information only in approved locations.
• Report lost devices, suspicious access, wrong-recipient messages, credential exposure, or vendor breach notices immediately.

Do Not

• Export, download, email, or text PHI unless the workflow is approved.
• Put PHI into ordinary SMS/text, personal email, personal cloud storage, unapproved chat tools, generative AI tools, or public websites.
• Use another person's account or let anyone else use your account.
• Create informal workarounds for patient records, insurance documents, referrals, billing data, or clinical details.
• Delete or alter incident evidence, access records, logs, messages, or files after a suspected issue.
• Name patients or include patient-level examples in training, support, or internal documentation unless the information has been approved and de-identified.

Report

Report these immediately to Operations:

• Wrong patient email or text.
• PHI sent to the wrong person.
• Lost or stolen device.
• Suspicious login or access.
• Shared-account misuse.
• Vendor breach notice.
• Patient record request.
• Paper PHI left unsecured.
• Any situation where you are unsure whether PHI was exposed.

For technical/security issues, include the technical/security owner after reporting to Operations.

Center Manager HIPAA Guide

Do

• Enforce the minimum MD Hyperbaric HIPAA standards for insurance workflows.
• Use approved systems and approved access methods.
• Keep PHI out of ordinary SMS/text except in a genuine emergency.
• Use personal phones only for minimal non-PHI logistics unless an emergency requires otherwise.
• Report incidents, lost devices, wrong-patient messages, suspicious access, shared-account concerns, and paper-record issues to Operations immediately.
• Escalate patient record requests to Operations.
• Make sure technicians lock screens, handle paper securely, and avoid informal workarounds.
• Support onboarding, offboarding, access review, and training completion.
• Keep devices, screens, paper records, printers, and network equipment protected from patients, visitors, and unauthorized people.
• Cooperate with location reviews and corrective actions.

Do Not

• Text patient photos, screenshots, DOB, diagnosis, insurance details, treatment details, records, or clinical details.
• Ask technicians to use personal phones for PHI.
• Leave shared accounts unmanaged.
• Ignore staff departure, role change, or access changes.
• Leave paper PHI visible or unsecured.
• Let staff use another person's individual account.
• Delete messages, paper records, or other evidence after a suspected incident.

Daily Checks

• Screens are locked when unattended.
• Patient-facing areas do not expose screens or paper PHI.
• Paper records are secured, uploaded, filed, shredded, or otherwise handled under local procedure.
• Tablets and laptops are supervised or secured.
• Staff know how to report an incident.
• Staff are using only approved access methods.

Report

Report quickly even if the issue seems small. Delayed reporting creates more risk than early escalation.

Examples:

• A patient text includes PHI.
• A message goes to the wrong person.
• A device is missing.
• A staff member leaves and still has access.
• A shared password may have been misused.
• A printer, folder, tablet, laptop, or form with PHI is left unsecured.

Technician HIPAA Guide

Do

• Use only approved systems, accounts, and access methods.
• Access only the patient information needed for your assigned work.
• Lock the screen every time you step away.
• Keep paper records secure while you are using them.
• Upload, file, shred, or store paper records according to local procedure.
• Ask the center manager or Operations if you are unsure how to handle PHI.
• Report mistakes quickly.
• Report lost devices, wrong-patient messages, suspicious access, unlocked devices, or paper PHI left unsecured.

Do Not

• Text or email PHI.
• Use a personal phone for PHI except in a genuine emergency.
• Take patient photos or screenshots unless specifically approved for the workflow.
• Share passwords beyond currently authorized shared-account workflows.
• Use another person's individual account.
• Leave a workstation, laptop, tablet, or paper record unattended.
• Discuss patient details where patients, visitors, or unauthorized people can hear.
• Put PHI into personal notes, personal email, personal cloud storage, unapproved chat tools, or AI tools.

If Something Goes Wrong

Report it immediately to the center manager or Operations.

Do not:

• Delete the message.
• Throw away the form.
• Close the issue quietly.
• Try to decide by yourself whether it is a reportable breach.

Fast reporting helps MD Hyperbaric protect the patient, document what happened, and fix the problem.

Incident Reporting and Breach Response SOP

Purpose

This SOP gives the team a clear path when something goes wrong with PHI, credentials, systems, devices, paper records, vendors, or access.

Fast reporting is required. Staff should not decide alone whether an event is a breach.

What Counts as an Incident

Report any event that may involve unauthorized access, use, disclosure, loss, alteration, destruction, or unavailability of PHI or systems that hold PHI.

Examples:

• Wrong patient text or email.
• PHI sent to the wrong recipient.
• Lost or stolen laptop, tablet, phone, paper record, or credential.
• Unattended unlocked workstation with PHI visible.
• Shared-account concern or suspected misuse.
• Suspicious login, suspicious access, malware, ransomware, phishing, or credential exposure.
• Vendor breach notice or suspicious vendor activity.
• Paper record left unsecured.
• PHI placed in ordinary SMS/text, personal email, unapproved app, or unapproved AI tool.
• Inability to access critical systems during an outage.

Immediate Staff Steps

1. Stop the exposure if you can do so without destroying evidence.
2. Report first to Operations.
3. If the issue is technical or security-related, involve the technical/security owner.
4. Preserve evidence.
5. Do not delete messages, logs, files, screenshots, paper records, or emails.
6. Do not contact the patient, vendor, or recipient with legal conclusions unless Operations directs you.
7. Do not try to self-fix quietly.

Operations Intake Steps

Operations should capture:

• Date and time reported.
• Reporter.
• Location or team.
• Incident type.
• What happened.
• PHI involved, if known.
• People or systems involved.
• Immediate containment steps.
• Whether technical/security investigation is needed.
• Whether breach assessment is needed.
• Assigned owner.
• Next action and due date.

Use Incident Log Template for the log fields.

Technical/Security Investigation

The technical/security owner should assist when the incident involves:

• Suspicious login or unauthorized access.
• Device loss or compromise.
• Malware, ransomware, phishing, or credential exposure.
• Shared-account misuse.
• System logs, access logs, audit logs, or vendor technical evidence.
• Backup/DR activation.
• Data export, download, deletion, or alteration.

Technical investigation should preserve logs and avoid production-impacting actions unless needed to contain active risk.

Breach Assessment

Operations and the technical/security owner should determine whether a breach assessment is needed. Counsel should review breach determinations and notice language.

Use the HHS four-factor assessment framework when applicable:

The assessment must be documented. Do not assume a low probability of compromise without evidence.

Notification Escalation Points

Breach notification deadlines are legal escalation points, not staff-facing legal analysis.

If a breach of unsecured PHI may have occurred, escalate promptly for counsel and leadership review. Notification decisions should address affected individuals, HHS, media, state law, vendors, payers, and contractual obligations where applicable.

Corrective Action

Corrective action may include coaching, retraining, access changes, workflow change, disciplinary action, or other appropriate measures. Keep sanctions language general until reviewed by counsel.

Short Incident Report Form

Retain incident records for at least six years.

Patient Record Request SOP

Purpose

This SOP replaces ad hoc patient record request handling with a controlled process.

Requests currently arrive by email, and a secure/encrypted delivery vendor or workflow is not yet implemented. That gap is tracked in Open Implementation Items.

General Rule

Patient record requests must be routed to Operations. Staff should not independently fulfill requests unless Operations assigns the task.

HIPAA right-of-access requests generally must be handled within 30 calendar days. If a request cannot be fulfilled within that period, escalate for review before the deadline.

Intake Steps

1. Record the request date.
2. Identify the requester.
3. Identify the patient.
4. Determine whether the requester is the patient, personal representative, authorized recipient, or another party.
5. Verify identity using reasonable safeguards.
6. Record the records requested.
7. Record the requested form, format, and delivery method.
8. Calculate the due date.
9. Assign an Operations owner.
10. Log the request using Patient Record Request Log Template.

Identity Verification

Use safeguards proportionate to the sensitivity of the records and the request channel.

Do:

• Verify enough information to be comfortable the requester is authorized.
• Use existing approved contact information where practical.
• Document what verification was completed.
• Escalate uncertain requests before disclosure.

Do not:

• Send records to a new address or recipient without verifying authorization.
• Over-collect identity documents when a less intrusive verification method is sufficient.
• Fulfill a request from a third party without confirming authority.

Fulfillment

Operations should:

• Provide only the records requested unless a broader disclosure is authorized and appropriate.
• Use the requested form and format if readily producible.
• Use secure delivery by default once the secure delivery workflow is implemented.
• Document fulfillment date, method, and notes.
• Keep copies of request and fulfillment evidence according to retention requirements.

Interim Standard-Email Handling

Standard email delivery of records should not be routine while a secure/encrypted delivery workflow remains open.

If a patient specifically requests standard email after a risk warning, document the request and warning before sending.

Draft interim warning language for counsel review:

Standard email may not be encrypted or secure. If you ask MD Hyperbaric to send your records by standard email, there is a risk that your information could be read by someone other than you while it is being sent. By choosing standard email after this warning, you accept that risk for this request.

Document:

• Date/time warning was given.
• Who gave the warning.
• Patient/requester confirmation that standard email is still requested.
• Email address to be used.
• Records sent.
• Fulfillment date/time.

Denials, Delays, and Special Requests

Do not deny, delay, or narrow a patient record request without escalation. Denial grounds and legal language should be reviewed by counsel.

Escalate:

• Requests from attorneys, insurers, government agencies, or unknown third parties.
• Requests involving minor, deceased, or representative status questions.
• Requests asking for correction, amendment, restriction, or accounting.
• Requests where identity cannot be verified.
• Requests likely to miss the 30-calendar-day timeline.

Request Log Fields

Use the request log template, at minimum:

• Request ID.
• Request date.
• Patient/requester.
• Identity verified.
• Records requested.
• Requested delivery method.
• Due date.
• Fulfilled date.
• Fulfillment method.
• Risk warning documented if standard email requested.
• Notes.

Retain request records for at least six years unless counsel requires longer.

Access Onboarding and Offboarding SOP

Purpose

This SOP creates a repeatable access lifecycle for people who need access to systems, accounts, records, or workflows that involve PHI.

Access Principles

• Access must be role-based and minimum necessary.
• Individual accounts are the target state wherever supported.
• Shared accounts are temporary exceptions, not the desired end state.
• MFA must be used where available or required.
• Access must be removed promptly when no longer needed.
• Access must be reviewed periodically.

New User Access Request

Before access is granted, document:

• User name.
• Role.
• Center/team.
• Manager or business approver.
• Systems or workflows requested.
• Reason access is needed.
• PHI or confidential information involved.
• MFA requirement.
• Shared-account exception, if any.
• Start date.

Approval

Access should be approved by the relevant manager or business owner. Technical/security owner review is required for privileged access, broad access, admin access, access to multiple centers, or unusual requests.

Do not grant access based only on informal chat, convenience, or historical practice.

Provisioning Checklist

Shared-Account Exception Controls

Where a shared account still exists:

• Limit use to assigned users.
• Limit use to assigned center/workflow.
• Keep manager oversight over who may use the account.
• Change the password when staff leave or no longer need access.
• Do not reuse passwords across systems.
• Report suspected misuse immediately.
• Include the account in periodic access review.
• Track migration to individual accounts as an open remediation item.

Role Change

When a person changes role, center, team, or workflow:

1. Review current access.
2. Remove access no longer needed.
3. Add only newly approved access.
4. Update the access log.
5. Confirm shared-account permissions still match the role.

Offboarding

Offboarding applies to resignation, termination, contractor end, role ending, center transfer, or any other reason access is no longer needed.

Complete promptly:

Periodic Access Review

Perform access review at least quarterly or on another documented periodic cadence.

Review:

• Active users.
• Role and center/team.
• Whether access is still needed.
• Shared-account exceptions.
• MFA status where available.
• Admin or broad access.
• Staff departure or role-change mismatches.
• Actions required and completion dates.

Use Access Review Log Template.

Device, Workstation, and Personal Phone Standard

Purpose

This standard sets minimum safeguards for devices and workstations used to access, create, receive, maintain, or transmit PHI.

Minimum Device Safeguards

Devices used for PHI should have:

• Managed endpoint protection where deployed.
• Full disk encryption where supported.
• Current operating system and security updates.
• Screen lock timeout.
• Strong authentication.
• MFA for systems where available or required.
• Secure storage when not in use.
• Lost/stolen device reporting.

Endpoint security rollout remains an open implementation item until confirmed complete.

Workstation Rules

Do:

• Lock the screen before stepping away.
• Position screens so patients, visitors, and unauthorized people cannot view PHI.
• Use privacy filters where needed.
• Keep printed PHI away from public areas.
• Log out of systems at the end of the day or when required by workflow.
• Report malware, suspicious popups, unexpected login prompts, or device loss.

Do not:

• Leave an unlocked workstation unattended.
• Save PHI locally unless approved.
• Use unapproved USB drives or removable media for PHI.
• Photograph or screenshot PHI without an approved reason.
• Let another person use your individual login.

Personal Phones

Personal phones are not approved PHI storage or transmission tools.

Center managers may use personal phones for minimal non-PHI logistics unless an emergency requires otherwise.

Technicians should not use personal phones for PHI or work records except in a genuine emergency.

Do not put these in ordinary SMS/text:

• Patient photos.
• Screenshots.
• Records.
• DOB.
• Diagnosis.
• Insurance details.
• Treatment details.
• Session details.
• Any other identifiable clinical or insurance information.

If emergency PHI use occurs on a personal phone, report it to Operations after the immediate risk is resolved so it can be documented and mitigated.

Lost or Stolen Device

Report lost or stolen devices immediately if they may contain, access, or be logged into systems involving PHI.

Report:

• Device type.
• Owner/user.
• Last known location.
• Whether it was locked.
• Whether it had disk encryption.
• Systems it could access.
• Whether any PHI was stored locally.
• Time discovered missing.

Quick Checklist

Center Physical Security and Network Checklist

Purpose

This checklist helps center managers and Operations review location-level safeguards for PHI, devices, paper records, workstations, printers, and network setup.

Use one checklist per location review.

Review Information

Workstation and Screen Placement

Devices

Paper Records

Printer and Copier Handling

Network and Wi-Fi

Corrective Actions

Retain completed checklists and corrective-action evidence for at least six years.

Backup and Disaster Recovery Tabletop Exercise Packet

Purpose

This packet exercises the existing backup and disaster recovery plan without rewriting it.

Use MDH Backup and Disaster Recovery Plan.md as the source of truth for backup systems, recovery procedures, criticality tiers, RTO/RPO targets, and remaining DR items.

Exercise Frequency

Run a tabletop exercise at least quarterly until the first exercise is complete and the process is stable, then follow the review cadence in the backup/DR plan.

Also run an exercise after material system, vendor, infrastructure, regulatory, or incident-driven changes.

Attendees

Recommended attendees:

• Technical/security owner.
• Operations.
• Leadership as needed.
• Center manager if the scenario affects a specific location.
• Vendor or external support only if needed for the scenario.

Scenario Options

Choose one scenario per exercise:

Exercise Steps

1. Select scenario.
2. Name facilitator and note taker.
3. Confirm systems and workflows affected.
4. Walk through detection and initial reporting.
5. Decide whether incident and breach procedures run in parallel.
6. Identify recovery priorities by criticality tier.
7. Identify backup source or vendor recovery path.
8. Decide emergency mode operations.
9. Identify communication needs.
10. Capture gaps, decisions, owners, and due dates.

Evidence to Capture

Specific Open Items to Test

Include these until closed:

• Paper emergency check-in forms.
• Downtime paper handling and post-restoration data entry.
• Cloud organization/BAA cleanup awareness.
• Backup evidence and restore-drill evidence maintenance.
• Incident response coordination during technical recovery.

Debrief Questions

• Did everyone know who to notify first?
• Were RTO/RPO targets understood?
• Was the backup source or vendor recovery path clear?
• Were paper fallback steps realistic?
• Did anyone suggest an insecure workaround?
• Were communication responsibilities clear?
• What evidence would be available in an audit?
• What action items need owners and due dates?

Retain completed exercise packets for at least six years.

Vendor and BAA Register Template

Purpose

Maintain a living list of vendors and services that create, receive, maintain, access, or transmit PHI for MD Hyperbaric or centers participating in insurance workflows.

This is an evidence register, not a narrative policy. Vendor and system names may be used here.

Known Evidence Examples to Start From

Review local evidence files before populating:

• HighLevel_BAA_Signed.pdf
• WebPT_BAA_Signed.pdf
• WebPT_SOC2_HIPAA_Report_2025.pdf
• vercel-baa-dr-evidence-2026-05-08.md
• MDH Backup and Disaster Recovery Plan.md
• Backup implementation evidence files

Register

Review Instructions

For each vendor:

1. Confirm whether PHI is created, received, maintained, transmitted, or accessed.
2. Confirm business owner.
3. Confirm BAA status.
4. Retain security, privacy, SOC, DR, or backup evidence where applicable.
5. Note open evidence gaps.
6. Set next review date.
7. Escalate vendors with PHI but no BAA or unclear security posture.

Retain vendor review evidence for at least six years.

Training Evidence SOP

Purpose

This SOP documents that the approved HIPAA training portal is the system of record for HIPAA training completion.

Do not create a separate annual policy acknowledgement process unless counsel later requires it.

Required Groups

Training should be assigned to:

• HQ staff who handle PHI, credentials, patient, insurance, clinical, vendor, or compliance workflows.
• Center managers at centers participating in insurance workflows.
• Technicians at centers participating in insurance workflows.
• Contractors or support personnel with approved PHI access.
• Technical/security owner and other system/data handlers who require role-specific technical or security training.

Cadence

• New workforce members: assign training during onboarding or before PHI access where practical.
• Annual refresher: assign through the approved HIPAA training portal.
• Material change: assign targeted refresher training after material policy, workflow, system, incident, or regulatory changes where needed.
• Incident follow-up: assign retraining when appropriate as corrective action.

Evidence to Retain

The approved HIPAA training portal should retain:

• Staff name.
• Role or group.
• Course name.
• Assignment date.
• Completion date.
• Status.
• Certificate or completion evidence.
• Overdue status and escalation notes.

Overdue Escalation

Operations should periodically review portal completion status.

For overdue training:

1. Send reminder.
2. Notify manager or center manager.
3. Escalate persistent overdue status to leadership or the appropriate business owner.
4. Consider access restriction for users who require training before PHI access.
5. Document action taken.

Records Retention

Retain training records for at least six years unless counsel requires longer.

Incident Log Template

Use this table to track reported incidents, investigation status, breach assessment need, outcomes, and corrective action.

Notes

• Do not include unnecessary patient-level details in this log.
• Link or reference secure evidence locations instead of pasting PHI.
• Retain incident documentation for at least six years.

Patient Record Request Log Template

Use this table to track patient record requests and fulfillment.

Notes

• Avoid unnecessary patient-level detail in the log.
• Store request documents and fulfillment evidence in an approved secure location.
• Use the patient record request SOP before fulfilling requests.
• Retain request documentation for at least six years unless counsel requires longer.

Access Review Log Template

Use this table for quarterly or periodic access reviews.

Notes

• Include individual accounts, shared-account exceptions, admin access, and broad access.
• Use role titles rather than personal commentary in findings.
• Retain access review records for at least six years.

Location Review Log Template

Use this table to track location physical security, network, paper handling, and corrective-action reviews.

Notes

• Use the center physical security and network checklist for detailed review.
• Retain location review records for at least six years.

Payment Card Processing Inventory Template

Purpose

Document payment processing flows enough to answer insurance and PCI-scope questions without creating an unnecessary PCI policy.

Do not draft a PCI compliance program unless the inventory shows MD Hyperbaric stores, processes, or transmits card data directly outside a compliant third-party processor.

Inventory

Instructions

For each location:

1. Identify how payments are taken.
2. Identify whether staff see full card numbers.
3. Identify whether card numbers are written down, stored, emailed, texted, photographed, or entered into any MD Hyperbaric-controlled system.
4. Identify whether phone payments occur.
5. Identify the payment processor or terminal category.
6. Note open questions for follow-up.

Keep this inventory separate from HIPAA staff-facing policies unless the payment workflow creates PHI handling risk.

Policy Review Schedule

Purpose

Define how the HIPAA policy pack is reviewed, updated, retained, and escalated for counsel review.

Review Cadence

Review Owners

Counsel Review Checkpoints

Counsel should review before final adoption or external distribution:

• Franchise acknowledgement language.
• Notice of Privacy Practices and website privacy policy language.
• Sanctions and corrective-action language.
• Patient record request denial, delay, and risk-warning language.
• Breach notification determinations and notice language.
• Any state-law or franchise-specific privacy obligations.

Documentation Retention

Retain policies, procedures, updates, assessments, logs, evidence registers, incident records, training records, request records, access reviews, and review notes for at least six years from creation or last effective date, whichever is later, unless counsel requires longer.

Review Log

Open Implementation Items

Purpose

This tracker keeps the policy pack honest by separating current requirements from items that are not yet fully implemented.

Open gaps should be centralized here unless people need an operational instruction.

Open Items

Closed Technical Backup Context

The current investigation tracker says known technical backup implementation for MDH-controlled systems is substantially complete as of 2026-05-08. Remaining backup/DR implementation items tracked here are:

• Tabletop exercise.
• Paper emergency check-in forms.

Do not rewrite the backup/DR plan here. Use MDH Backup and Disaster Recovery Plan.md.