Outcome 6.2 Study Notes: Protecting Health Information Through Law, Ethics, and Security Controls

Components of the Legal System in Healthcare (6.2.1)

A legal system is the structure a society uses to create rules, interpret them, and enforce them. In healthcare, this matters because patient care generates high-stakes decisions (injury, death, disability, privacy harms) and produces sensitive information (health records) that is protected by law. When something goes wrong—an incorrect medication, an improper disclosure of a diagnosis, or a cyberattack—your actions are evaluated through this system.

The three branches of government (U.S. framework)

Most healthcare law questions start with where the rule comes from:

Legislative branch makes statutes (laws passed by Congress or a state legislature). Example: HIPAA is a federal statute.
Executive branch enforces laws and runs agencies that write regulations. Example: the U.S. Department of Health and Human Services (HHS) issues regulations that implement HIPAA.
Judicial branch interprets laws through court decisions (case law). Example: court rulings about negligence standards or how a subpoena must be handled.

A common confusion is mixing up statutes (passed by legislatures) with regulations (issued by agencies under authority granted by statutes). Regulations are legally binding, but they’re not passed like bills.

Types of law that show up in healthcare

Healthcare disputes and compliance issues typically fall into:

Criminal law (government prosecutes): e.g., intentional fraud, certain wrongful disclosures, theft of controlled substances.
Civil law (private parties sue): e.g., malpractice, breach of privacy, contract disputes.
Administrative law (agencies regulate): e.g., licensing boards, CMS program rules, HIPAA enforcement.

Court structure and roles

You’ll often hear:

Trial courts: where facts are found (witnesses testify, evidence is introduced). Many malpractice cases start here.
Appellate courts: review legal errors (they usually don’t “retry” facts).

Key roles include:

Plaintiff (person/party bringing a civil lawsuit) and defendant.
Judge (rules on law and procedure) and sometimes a jury (decides facts).

Example in action

A patient alleges a nurse improperly accessed their chart out of curiosity. That can trigger:

An administrative investigation (hospital compliance + possible HIPAA investigation).
A civil claim (privacy tort, depending on state law and facts).
Employment action (discipline/termination) based on policy.

Exam Focus

Typical question patterns:
- Identify whether a scenario is criminal, civil, or administrative.
- Distinguish statute vs regulation vs case law.
- Match an issue (licensure, HIPAA complaint, malpractice) to the correct system component.
Common mistakes:
- Assuming “HIPAA is a court decision” (it’s a statute implemented by regulations).
- Treating all wrongdoing as “criminal”—many patient harms are civil/administrative.
- Forgetting agencies (administrative law) are central in healthcare compliance.

Evidence, Discovery, Negligence, and Medical Malpractice (6.2.2)

Healthcare litigation depends on evidence—information used to prove or disprove facts. Understanding evidence types matters because the medical record is not just a care tool; it becomes a legal document. The way you document and the way information is preserved can strongly influence legal outcomes.

Types of evidence used in healthcare litigation

Courts generally work with several evidence categories:

Testimonial evidence: spoken statements under oath (e.g., nurse testimony about what was observed).
Documentary evidence: written/recorded items (e.g., EHR notes, consent forms, policies, incident reports—though whether an incident report is discoverable can vary by jurisdiction and privilege rules).
Physical evidence: tangible items (e.g., a defective device, medication packaging).
Demonstrative evidence: exhibits used to explain (e.g., charts, timelines, anatomical diagrams). It supports other evidence rather than standing alone.

A frequent misconception is that “anything in the chart is automatically correct.” Legally, documentation can be challenged—so accuracy, timeliness, and clarity matter.

Discovery: how parties obtain information before trial

Discovery is the formal pre-trial process where each side can obtain evidence from the other. The goal is to prevent “trial by surprise” and allow both sides to evaluate the case.

Common discovery tools include:

Interrogatories (written questions requiring written answers).
Requests for production (asking for documents/EHR extracts, policies, logs).
Depositions (sworn out-of-court testimony, recorded and transcribed).
Requests for admissions (asking a party to admit/deny specific facts).

In healthcare, discovery often involves EHR data, metadata (timestamps, authorship), audit logs, and policy/procedure documents.

Permissible use of evidence (basic principles)

Not all evidence offered is allowed. Courts apply rules that focus on:

Relevance: does it make a fact more or less likely?
Reliability/authenticity: is it what it claims to be (e.g., a true record extract, not altered)?
Privileges: some communications may be protected (for example, attorney-client privilege). Other protections can exist depending on state law (e.g., certain peer review protections).

A key operational point: if you receive a legal request (subpoena/court order), you generally should not improvise—follow your organization’s release-of-information (ROI) and legal/compliance pathway.

Negligence vs medical malpractice

Negligence is a civil claim based on careless behavior that causes harm. Medical malpractice is negligence by a healthcare professional (or organization) that involves a failure to meet the standard of care.

A common way to recognize negligence is the “four elements” (often taught as duty, breach, causation, damages):

Duty: a responsibility existed (e.g., nurse-patient relationship).
Breach: the duty was not met (care fell below the standard).
Causation: the breach caused the injury (not just “something bad happened”).
Damages: actual harm occurred (injury, additional costs, pain, etc.).

Example in action

A patient falls after a call light goes unanswered. A negligence analysis asks:

Was there a duty to respond and maintain safety?
Was there a breach (unreasonable delay, failure to follow fall precautions)?
Did that cause the fall (as opposed to an unrelated medical event)?
Were there damages (fracture, surgery, rehab)?

Exam Focus

Typical question patterns:
- Identify evidence type (testimonial vs documentary vs demonstrative).
- Put discovery steps/tools in context (what a deposition is used for).
- Recognize the elements of negligence/malpractice in a scenario.
Common mistakes:
- Forgetting causation—a breach without harm may not establish negligence.
- Assuming demonstrative evidence (like a timeline) is “proof” by itself.
- Confusing discovery with trial—discovery happens before trial to exchange information.

Regulatory Requirements, Standards of Practice, and Reporting Malpractice/Negligence (6.2.3)

Healthcare workers operate under overlapping layers of rules: laws, regulations, professional standards, and employer policies. You’re expected to know your responsibilities and also what to do when something unsafe or unlawful occurs.

What “regulatory requirements” and “standards of practice” mean

Regulatory requirements are enforceable rules issued by government agencies under legal authority (federal or state). These can involve privacy/security, licensing, and facility operations.
Standards of practice describe what competent professionals are expected to do in a given situation. They can come from state practice acts, licensing boards, accrediting expectations, and professional organizations.

Think of it like driving:

Statutes/regulations are the traffic laws.
Standards of practice are what a careful driver is expected to do (signal, check mirrors), even if not spelled out in every detail.

Legal responsibility, limitations, and implications of actions

Your scope of practice (what your license/certification allows) and job description/policy (what your employer authorizes) set boundaries. Acting outside scope or ignoring policy can create risk for patients and legal exposure for you and the organization.

Two documentation-related points often tested:

Document facts (what you saw, heard, did), not blame.
Never “fix” a record by deleting or backdating—follow your system’s amendment/correction process so the record remains trustworthy.

Appropriate avenues for reporting malpractice or negligence

When you suspect unsafe care, privacy breaches, or professional misconduct, you typically report through a structured pathway:

Immediate clinical chain of command (charge nurse, supervisor) to protect the patient now.
Risk management / patient safety office for incident evaluation and system fixes.
Compliance/privacy/security officer for potential regulatory issues (e.g., suspected HIPAA breach).
Institutional reporting tools (incident reporting systems) per policy.
External reporting may be required in some situations (e.g., to a licensing board or public health authority), but the “when and how” depends on role, state law, and organizational policy.

A common mistake is reporting to the wrong place first (or broadcasting the issue widely). The safest approach is: protect the patient, then follow the designated reporting channels.

Example in action

You notice a provider repeatedly leaving charts open on a workstation in a public area. The correct response is not to ignore it or gossip—it’s to:

Secure the immediate risk (close the session if policy allows; notify the user).
Report through your organization’s privacy/security incident pathway.

Exam Focus

Typical question patterns:
- Choose the correct internal reporting route (supervisor vs risk management vs compliance).
- Identify scope/standard-of-practice issues in a scenario.
- Interpret a policy requirement (e.g., correction of documentation, incident reporting expectations).
Common mistakes:
- Thinking “reporting” means posting details in email/text—reports must follow secure, authorized channels.
- Confusing “standard of practice” with “personal preference.” Standards are community/professional expectations.
- Attempting to secretly correct documentation rather than using proper amendment functions.

Authorized Access, Release, and Use of Personal Health Information (PHI) (6.2.4)

Personal health information—often called PHI (Protected Health Information) in U.S. contexts—is individually identifiable health information held or transmitted by covered healthcare entities and their business associates. The central idea is simple: patients share sensitive details for care, and you must only access or disclose what you are allowed to.

Authorized access: when you may look at a record

Authorized access means you have a legitimate, role-based reason connected to your job duties. In practice, organizations implement this through role-based access control (RBAC): your login permissions reflect what you need to do your work.

A useful self-check before opening a chart:

Do I have a work-related need tied to treatment or other authorized operations?
Am I accessing the minimum necessary information for the task (a common compliance principle)?

“Curiosity access” (looking up a coworker, neighbor, or public figure) is a classic example of unauthorized access—even if you never share what you saw.

Authorized uses and disclosures (high-level framework)

In many U.S. healthcare settings, certain disclosures may be allowed for core functions such as treatment, payment, and healthcare operations (often abbreviated TPO). Other disclosures may require patient authorization or may be permitted/required by law (for example, certain public health reporting). The exact rules depend on jurisdiction and organizational policy, so the operational rule is: use the approved ROI process when in doubt.

Release of information (ROI): what makes a release “authorized”

A release is typically authorized when:

The requester is verified (identity and authority confirmed).
The request is documented.
The disclosure matches a valid legal basis (patient authorization, permitted disclosure category, subpoena/court order handled through proper channels, etc.).
Only the appropriate minimum necessary data is released (when that principle applies).

Example in action

A patient’s spouse calls asking for lab results. Even if the spouse is well-meaning, you generally cannot assume they are authorized. You must follow policy—verify whether the patient has granted permission, whether the spouse is a personal representative, and what your organization requires before disclosure.

Exam Focus

Typical question patterns:
- Decide whether access is authorized (role-based need vs curiosity).
- Identify what makes a disclosure “authorized” (verification + documentation + legal basis).
- Apply the “minimum necessary” concept to a scenario.
Common mistakes:
- Believing “I’m a staff member” automatically grants access to any chart.
- Disclosing information to family without confirming authorization.
- Releasing entire records when only a limited portion is needed/allowed.

Confidential vs Non-Confidential Information & Handling Requests (6.2.5)

Privacy practice isn’t only about saying “no.” It’s about sorting information correctly, documenting requests, and responding through the right workflow so patients’ rights and legal duties are both met.

What “confidential” means in healthcare

Confidential information is information that must be protected from unauthorized access because it can identify a patient and/or reveal sensitive health details. This includes most clinical information in a patient record when it is identifiable.

Non-confidential information is information that does not identify an individual patient or is otherwise approved for release (for example, properly de-identified data, general educational materials, or publicly available facility information). In some settings, limited items like facility directories or appointment confirmations can be shared under specific rules and patient preferences—but you must follow your organization’s policy.

A common misconception is that “removing the name” automatically makes data non-confidential. Many data elements (dates, locations, unique numbers, rare diagnoses) can still identify someone.

Documenting and prioritizing requests for PHI

Requests for personal health information come from patients, insurers, attorneys, other providers, and sometimes law enforcement. The safe approach is to treat ROI like a controlled process:

Capture the request in the approved system (ticket, ROI module, form). Documentation creates traceability and helps meet timelines.
Verify identity and authority:
- Patient request: verify patient identity.
- Third party: confirm valid authorization or legal authority.
Clarify scope: what dates, what type of record, what format is needed.
Apply prioritization rules: urgent patient-care needs (continuity of care) may be handled faster than routine administrative requests, but priorities must follow policy and law.
Record the disclosure when required (who received what and when).

Example in action

A physician’s office requests records for a referred patient’s upcoming procedure. This is typically a high-priority, care-related request. By contrast, a broad request from a third party with unclear authorization should be routed through ROI staff/legal review before any release.

Exam Focus

Typical question patterns:
- Classify information as confidential vs non-confidential (and justify why).
- Choose the correct next step for an ROI request (verify identity, document, route to ROI).
- Prioritize competing requests based on patient care needs and policy.
Common mistakes:
- Treating de-identification as “easy” and doing it informally.
- Skipping documentation because a request seems routine.
- Over-releasing information (dates outside the request, unrelated diagnoses).

Using Networks (Intranet and Internet) Under Security/Privacy Policies (6.2.6)

Modern healthcare depends on networks: EHR access, imaging, labs, telehealth, patient portals, and email all move data across systems. Security failures often come from everyday actions—clicking a link, using public Wi‑Fi, or sending PHI through an unapproved app.

Intranet vs internet: why the distinction matters

Intranet: an internal organizational network. It’s typically protected by internal controls (authentication, segmentation), but it is not automatically “safe.” Insider misuse still happens.
Internet: public networks. Anything sent over the internet must use approved security controls (secure portals, encryption, VPN) per policy.

Policy-driven safe network behavior

Security and privacy policies usually address:

Authentication: use your own account; never share passwords; use multi-factor authentication if provided.
Session security: lock screens; log out; don’t leave workstations unattended.
Secure communication: use approved secure messaging/email encryption tools for PHI.
Device rules: follow policies for removable media (USB drives), personal devices, and remote access.
Phishing and social engineering: verify unexpected requests for credentials or urgent “IT” messages.

A subtle but important point: even inside the intranet, sending PHI to the wrong coworker is still an unauthorized disclosure.

Example in action

You need to send discharge paperwork to a receiving facility. The correct approach is using the organization’s secure exchange method (secure email gateway, portal, or interoperable health information exchange tool) rather than personal email or standard texting.

Exam Focus

Typical question patterns:
- Identify which communication method is compliant (secure portal vs personal email).
- Recognize phishing/red-flag scenarios and the correct response.
- Apply “least privilege” and “need-to-know” concepts to network access.
Common mistakes:
- Assuming “internal network = no privacy risk.” Insider access still requires authorization.
- Using convenience tools (personal cloud storage, texting) for PHI.
- Clicking links or opening attachments without verification.

Consequences of Inappropriate Use of Health Information (6.2.7)

Privacy and security rules are not just paperwork—they exist because misuse creates real harm. Inappropriate use includes unauthorized access, improper disclosure, alteration/destruction of records, and careless handling that leads to breaches.

Patient and clinical consequences

Loss of trust: patients may withhold information, reducing care quality.
Stigma and discrimination harms: disclosure of sensitive diagnoses can affect relationships, employment, or safety.
Care errors: altered or incomplete records can lead to wrong treatment decisions.

Organizational and legal consequences

Disciplinary action: retraining, suspension, termination.
Civil liability: lawsuits for privacy harms or negligence.
Regulatory penalties: investigations, corrective action plans, fines (depending on law and severity).
Reputation and financial impact: breach notification costs, downtime, loss of business.

Personal professional consequences

Licensing/credential consequences: boards and credentialing bodies may discipline for unethical or illegal conduct.
Career impact: loss of employment, reduced trustworthiness, future hiring difficulties.

Example in action

A staff member screenshots a celebrity’s lab results and shares them in a group chat. Even if the information is “true,” the action is an unauthorized disclosure and can trigger termination, regulatory investigation, and legal claims.

Exam Focus

Typical question patterns:
- Identify the likely consequences (patient harm, legal/regulatory, employment).
- Distinguish between unauthorized access vs unauthorized disclosure (both are violations).
- Scenario questions about “harmless” curiosity access.
Common mistakes:
- Thinking “no one found out” means “no harm/no violation.” Audit logs can reveal access.
- Focusing only on fines and ignoring patient safety and trust consequences.
- Assuming intent is required—many policies treat negligent handling as a serious violation.

Safeguards: Administrative, Physical, and Technical Controls for Data Integrity and Validity (6.2.8)

Protecting health information requires layered controls. In U.S. healthcare security language, safeguards are often grouped into administrative, physical, and technical categories. Together they protect confidentiality (only authorized people see it), integrity (information is accurate and unaltered), and availability (it’s accessible when needed for care).

Administrative safeguards (people + process controls)

Administrative safeguards are management-driven controls that shape behavior and reduce risk:

Written policies and procedures (access, passwords, device use, ROI, incident response).
Workforce training (privacy, phishing, secure handling).
Risk assessment and risk management (identifying threats and mitigating them).
Sanctions/discipline policies for violations.
Vendor management (business associate expectations, contracts, due diligence).

These matter because many breaches begin with human error—training and clear workflows prevent “workarounds.”

Physical safeguards (protecting spaces and devices)

Physical safeguards protect the environments where information is stored or accessed:

Controlled facility access (badges, locked areas).
Workstation positioning (prevent shoulder-surfing in public areas).
Secure storage and disposal (locked bins, shredding, secure media destruction).
Device security (locking carts, tracking laptops, preventing theft).

Physical controls are especially important in patient-facing areas where visitors are present.

Technical safeguards (technology controls)

Technical safeguards are system-based controls such as:

Unique user IDs and strong authentication.
Access controls (role-based permissions, least privilege).
Encryption for stored data and for transmission when required.
Automatic logoff/timeouts.
Integrity protections (controls to prevent improper alteration; validation rules; change tracking).
Backups and recovery mechanisms to preserve availability and support integrity.

Data integrity vs data validity (how they connect)

Data integrity means data remains accurate and unaltered except through authorized, traceable processes.
Data validity means data values make sense and meet rules (e.g., a blood pressure field can’t accept letters; a medication dose must fall within plausible ranges).

EHRs use validation checks, required fields, and standardized lists to support validity. Audit trails and controlled edits support integrity.

Example in action

An organization reduces charting errors by:

Administrative: training on correct patient identification.
Physical: barcode scanners available at point of care.
Technical: EHR alerts when two patients have similar names; barcode medication administration integration.

Exam Focus

Typical question patterns:
- Classify a control as administrative vs physical vs technical.
- Explain how safeguards support confidentiality, integrity, and availability.
- Identify which safeguard would prevent a given incident (e.g., theft vs phishing vs improper edits).
Common mistakes:
- Treating safeguards as only “IT things.” Administrative and physical controls are equally tested.
- Confusing integrity (unchanged/accurate) with confidentiality (secret/private).
- Overrelying on technology while ignoring workflow and training causes.

Audit Trails and Data Quality Monitoring Program Design (6.2.9)

If privacy rules are the “don’t,” audit trails and monitoring are the “prove it.” Healthcare organizations need to detect inappropriate access, investigate incidents, and improve documentation quality. That requires deliberate design.

Audit trails: what they are and what they should capture

An audit trail is a record of activity in an information system. In an EHR context, it answers: who did what, to which record, when, and from where?

Strong audit trails typically include:

User identification (unique ID, not a shared login).
Patient/record identification (which chart was accessed).
Timestamp (date/time of access and/or action).
Action type (viewed, created, edited, printed, exported, deleted).
Source/location (workstation ID, device, IP address, remote vs on-site when available).
Outcome (successful/failed login attempts; permission denied events).
Context fields when designed (reason-for-access prompts, break-the-glass events for emergency access).

A common misconception is that “audit trails are only for catching bad employees.” In reality, they also support safety investigations, cybersecurity detection, and quality improvement.

Data quality monitoring programs: what they measure

A data quality monitoring program looks for patterns that reduce the reliability of records and reports. Typical dimensions include:

Accuracy: are entries correct (e.g., correct patient, correct medication)?
Completeness: are required fields filled (allergies documented, discharge instructions present)?
Timeliness: are notes entered promptly (to support current clinical decisions)?
Consistency: do data match across modules (problem list vs medication list)?
Uniqueness: are there duplicate patient records?

Programs often use chart audits, automated reports (missing documentation), and targeted reviews of high-risk workflows (medication reconciliation, abnormal results follow-up).

Example in action

A data quality team notices frequent missing allergy documentation in a clinic. They investigate:

Workflow (are staff rushed at intake?)
EHR design (is the allergy field hard to find?)
Training (do staff know “unknown” is different from “no known allergies”?)

Exam Focus

Typical question patterns:
- Identify required audit trail elements (user, time, action, patient record).
- Explain how audit logs support investigations of improper access.
- Choose appropriate data quality metrics for a scenario (completeness vs accuracy vs timeliness).
Common mistakes:
- Forgetting that “view-only” access should also be logged.
- Assuming monitoring is optional—many compliance programs rely on routine audit review.
- Confusing data quality monitoring (documentation correctness) with cybersecurity monitoring (malware/network attacks). They overlap but are not identical.

Federal, State, and Private Sector Initiatives Shaping Health IT Privacy/Security (6.2.10)

Privacy and security in health IT are influenced by multiple initiatives—laws, regulations, guidance frameworks, and accreditation standards. Understanding “who sets the expectations” helps you know why your organization has specific rules and why they keep changing.

Federal initiatives (U.S.)

Common federal drivers include:

HIPAA (Health Insurance Portability and Accountability Act) and its implementing regulations, which establish baseline privacy and security expectations for covered entities and business associates.
HITECH Act (Health Information Technology for Economic and Clinical Health), which strengthened breach notification expectations and promoted adoption of electronic health records.
21st Century Cures Act initiatives related to interoperability and restrictions on improper blocking of information sharing (often discussed as “information blocking” rules). These efforts connect privacy/security with patient access and appropriate data exchange.

The key idea: federal rules set a floor for protections and also push systems toward secure, patient-centered access.

State initiatives

States commonly influence privacy/security through:

Professional licensing laws (scope and discipline related to confidentiality breaches).
State privacy laws and breach notification laws (requirements may differ by state).
Special protections for certain information categories may exist in some states (the details vary widely), which is why organizations maintain state-specific compliance guidance.

Operationally, this means your organization may apply stricter rules than the federal minimum when state law or policy demands it.

Private sector initiatives

Private initiatives matter because healthcare organizations often pursue accreditation, certifications, and best practices beyond legal minimums:

Accreditation standards (e.g., The Joint Commission) often require strong information management, patient rights protections, and secure processes.
Industry frameworks and guidance (e.g., NIST cybersecurity guidance) help organizations structure risk management and technical controls.
Certification and assurance programs (e.g., security assessment frameworks used by payers/partners) may set expectations for vendors and networks.

A common mistake is thinking “private standards aren’t important because they aren’t laws.” They can still be powerful because accreditation, contracts, and reimbursement relationships may depend on meeting them.

Example in action

A hospital updates its patient portal workflow to allow faster patient access to test results (patient-centered access) while also adding identity verification and monitoring for unusual account activity (security). This kind of change is typically driven by a combination of federal access expectations, security risk management, and accreditation/industry best practices.

Exam Focus

Typical question patterns:
- Sort initiatives into federal vs state vs private sector categories.
- Explain why an organization might adopt controls stricter than the legal minimum.
- Scenario questions connecting interoperability/patient access with privacy and security controls.
Common mistakes:
- Assuming only federal law matters—state rules and contracts often change what you must do.
- Treating interoperability as the opposite of privacy; in practice, the goal is secure sharing.
- Ignoring the role of accrediting bodies and frameworks in shaping real-world policies.