Work through the ten groups in order, because later application concepts assume the foundations. For each concept, read the explanation, then test yourself by resolving the example before checking the stated decision and reasoning. The mistake field flags the error most commonly made on that distinction. Use the table of contents to find gaps, and treat every scenario as a decision to justify, not a term to recite.
Health IT and EHR Fundamentals
1. Defining the EHR by Function
An EHR is software used to securely document, store, retrieve, share, and analyze information about individual patient care. The functional test matters: a scheduling-only tool or standalone billing database lacks those record functions, so EHR-specific governance and optimization practices do not attach to it.
Example: A practice asks whether its appointment reminder app is the EHR; decision: no, because it cannot document or retrieve clinical care information, so EHR governance does not attach to it.
Mistake to avoid: Treating any health-adjacent software as an EHR and applying record-system rules to it.
Reference: ONC Health IT Playbook: Electronic health records
2. Local Hosting versus Cloud Hosting
Locally hosted EHRs place software and data on practice servers; cloud systems run remotely. Cloud reduces upfront hardware and maintenance costs but shares security responsibility with the vendor and reduces direct control, while local hosting keeps data in-house but makes the practice responsible for physical security, backups, and equipment costs.
Example: A rural practice with slow internet weighs options; decision favors local hosting, because avoiding costly high-speed connectivity upgrades is a stated local-hosting benefit.
Mistake to avoid: Choosing cloud hosting without weighing shared security responsibility and reduced data control.
Reference: ONC Health IT Playbook: Electronic health records
3. The EHR Journey Has No Endpoint
EHR adoption is an ongoing journey with no single destination or end. After installation, optimization opportunities continue, and each added technology—patient portal, health information network connection, or new payment model participation—requires revisiting workflow redesign rather than treating implementation as finished.
Example: A clinic connects to a health information network two years after go-live; decision: reopen workflow optimization, because adding a network connection is a trigger to revisit the journey.
Mistake to avoid: Declaring the EHR project complete at go-live and skipping later optimization cycles.
Reference: ONC Health IT Playbook: Electronic health records
4. ONC Certification and the Cures Act Context
Under the 21st Century Cures Act, ONC works to improve how practices share information with patients and the quality of care through technology. Optimizing EHRs for patient safety and interoperability—systems communicating easily with each other—is central to that work, which is why certification status matters during selection.
Example: A practice shortlists two systems; decision: weigh the ONC-certified product's status, because certification ties to the Cures Act interoperability and safety goals emphasized in guidance.
Mistake to avoid: Ignoring certification status when comparing functionally similar products.
Reference: ONC Health IT Playbook: Electronic health records
5. Interoperability as a Selection Criterion
Interoperability means making sure EHRs can communicate easily with each other. It is a key part of ONC's Cures Act work, so a system's ability to exchange information should be weighed alongside features, because poor exchange capability undermines care coordination and later regulatory expectations.
Example: A cardiology group evaluates a cheaper system that cannot exchange records; decision: weigh exchange capability heavily, because interoperability is a stated national optimization priority.
Mistake to avoid: Choosing on feature lists alone and discovering exchange failures after purchase.
Reference: ONC Health IT Playbook: Electronic health records
6. Who Health IT Guidance Serves
The Playbook is a source for clinicians, other healthcare providers, and practice administrators who are adopting, optimizing, upgrading, or changing an EHR system. Its tools aim to make implementation more efficient, less burdensome, and more effective, which frames the technology specialist's advisory role within a practice.
Example: An office manager asks who should lead EHR replacement planning; decision: administrators and clinicians together, since guidance names both as the audience for changing systems.
Mistake to avoid: Treating EHR planning as an IT-department-only task excluding clinical and administrative users.
Reference: ONC Health IT Playbook: Electronic health records
EHR Selection and Contracting
7. Assessing Readiness Before Selection
Before selecting, assess organizational readiness: personnel eagerness, availability of someone to champion the cause, stakeholders who perceive EHRs as useful, and ability to work as a team. These factors predict whether implementation roadblocks can be overcome, so readiness gaps should be addressed before committing to a product.
Example: A practice lacks any staff champion for adoption; decision: delay vendor selection and recruit a champion first, because readiness factors determine whether roadblocks can be overcome.
Mistake to avoid: Signing a vendor contract before evaluating eagerness, champions, and teamwork capacity.
Reference: ONC Health IT Playbook: Electronic health records
8. Naming the Common Selection Roadblocks
Common roadblocks include incomplete understanding of the organization's information needs, uncertain costs, and the effort required to identify and implement an appropriate system. Naming which roadblock applies changes the response: needs analysis, cost modeling, or project resourcing, respectively, rather than a generic fix.
Example: A group cannot state what data it must capture daily; decision: run a needs assessment first, since incomplete needs understanding is a named roadblock requiring that remedy.
Mistake to avoid: Jumping to vendor demos without diagnosing which specific roadblock is present.
Reference: ONC Health IT Playbook: Electronic health records
9. Two-Part Structure of EHR Contract Planning
ONC's contracts guide has two parts: Part A covers planning—product types, comparing vendors, prioritizing requirements, due diligence, and procurement strategy—while Part B covers negotiating terms with example language for safety, security, performance, data protection, interoperability, liability, disputes, and transition. Sequence matters: planning precedes negotiation.
Example: A practice wants to fix a data-ownership clause; decision: use the negotiation guidance, but only after planning and due diligence have narrowed the vendor field.
Mistake to avoid: Negotiating contract language before completing planning and due-diligence steps.
Reference: ONC Health IT Playbook: Electronic health records
10. Contract Terms That Protect Data and Performance
Contract topics include EHR safety and security, ensuring system performance meets expectations, managing and protecting EHR data, interoperability and integration, risk and liability, vendor-dispute resolution, and transition issues. Each is a negotiable protection rather than a vendor favor, and each should be addressed in writing before signing.
Example: A vendor offers only verbal uptime promises; decision: reject and reduce performance expectations to contract terms, since system performance is a named negotiable topic.
Mistake to avoid: Accepting verbal assurances on performance, data protection, or dispute handling.
Reference: ONC Health IT Playbook: Electronic health records
11. Cloud Vendor Service Level Agreements
For cloud-based EHRs, reduce risk by having legal contracts and appropriate service level agreements with the vendor plus ongoing monitoring. Because data security responsibility is shared with the vendor, the agreement is the mechanism that makes the shared model enforceable, and monitoring keeps the arrangement honest over time.
Example: A practice adopts a cloud EHR on a handshake; decision: require a service level agreement and monitoring plan, because cloud risk reduction depends on both.
Mistake to avoid: Assuming the cloud vendor's security posture replaces the practice's own oversight duty.
Reference: ONC Health IT Playbook: Electronic health records
12. Comparing Vendors with Structured Tools
Structured tools support selection: vendor comparison questions for demonstrations, a pricing template defining line-item costs for software, implementation, training, and support across licensing models, and a system testing plan tracking performance tests. Structured comparison prevents decisions driven by polished demonstrations alone.
Example: Two demos look equally strong; decision: score both with comparison questions and the pricing template, because line-item costs often reveal the real difference.
Mistake to avoid: Choosing a vendor based on demo polish without line-item cost and test comparisons.
Reference: ONC Health IT Playbook: Electronic health records
Implementation, Workflow, and Usability
13. Pre-Implementation versus Implementation Phases
Pre-implementation requires establishing governance and a project plan, involving and communicating with staff and patients, redesigning workflows, and providing education. Implementation then covers tailoring the system, change management, backloading patient histories, training time, support, and encouragement. Activities belong to distinct phases, so mis-sequencing wastes effort.
Example: A practice schedules system tailoring before any workflow redesign; decision: reverse the order, because redesign belongs to pre-implementation and tailoring to implementation.
Mistake to avoid: Starting system tailoring before governance, communication, and workflow redesign are done.
Reference: ONC Health IT Playbook: Electronic health records
14. Governance and the SAFER Guides
Establishing governance means creating guidance and a stewardship plan focused on data safety and integrity. The SAFER Self-Assessment Guides are a comprehensive resource of recommended practices for safe EHR use, including organizational responsibilities, contingency planning, and test results follow-up, making them a practical backbone for the governance plan.
Example: A practice writes a stewardship plan; decision: anchor it to SAFER self-assessments, which cover organizational responsibilities and contingency planning among recommended practices.
Mistake to avoid: Writing a governance plan without grounding it in SAFER recommended practices.
Reference: ONC Health IT Playbook: Electronic health records
15. Managing Change Deliberately
Change management is a distinct implementation activity: guidance explains basic change management principles and why managing change effectively matters during EHR implementation. Treating change as automatic assumes staff will adapt on their own; deliberate change management addresses resistance and role shifts instead.
Example: Front desk staff resist new check-in steps; decision: apply change management principles rather than mandating compliance, because managing change is a named implementation requirement.
Mistake to avoid: Assuming staff will adapt naturally and skipping structured change management.
Reference: ONC Health IT Playbook: Electronic health records
16. Evaluating the Implementation Afterward
After implementation, evaluate: did the process go smoothly, did everyone participate, did events go as planned, what were strengths and weaknesses, how did workflow change, and what improvements are possible? Answering these questions converts experience into planned corrections that continue the system's value.
Example: A post-go-live review finds nurses bypassed a documentation step; decision: log it as a workflow effect and plan improvement, which is the evaluation's stated purpose.
Mistake to avoid: Moving straight to daily operations without a structured post-implementation evaluation.
Reference: ONC Health IT Playbook: Electronic health records
17. Usability Depends on Implementation, Not Just Design
Usability is how easy, effective, and efficient software is to use, and it depends not only on design but also on implementation. Maximizing it requires continuous optimization, a process to gather feedback from clinicians, patients, and other users, and improvements based on that feedback and best practices.
Example: Two clinics run identical EHRs with different satisfaction; decision: examine implementation differences and feedback loops, because usability is partly an implementation outcome.
Mistake to avoid: Blaming the product alone for poor usability while ignoring local configuration and feedback processes.
Reference: ONC Health IT Playbook: Electronic health records
18. Mapping Workflows to Optimize Them
Workflow process mapping guidelines help optimize EHR efficiency, and the AHRQ workflow assessment toolkit addresses clinical and administrative concerns in ambulatory care. Mapping exposes the steps staff actually take, revealing redundancy and handoff problems that optimization should target, rather than redesigning from memory.
Example: Refill requests take four handoffs; decision: map the process first, then redesign the steps, because mapping is the tool that exposes the inefficiency.
Mistake to avoid: Redesigning a process from memory without first mapping the actual current steps.
Reference: ONC Health IT Playbook: Electronic health records
Data Migration and Health Information Exchange
19. When Data Migration Is Justified
Migration planning applies both to moving from paper to an EHR and between electronic environments. The investment is worth it when a practice is outgrowing its current EHR's capabilities, expanding, or joining another practice; careful planning ensures the new EHR can integrate and access historical data.
Example: A two-provider group merges into a larger system; decision: undertake migration planning, because joining another practice is a stated justification and history access depends on it.
Mistake to avoid: Switching systems casually without planning for historical data integration.
Reference: ONC Health IT Playbook: Electronic health records
20. Transition Issues to Negotiate When Switching
Switching-EHR guidance covers length of support, data portability, software license, transition support services, data transfer and conversion, and contract language and terms. These are the specific items to negotiate before switching, because exiting a system without them can strand data and leave the practice without support.
Example: An old vendor offers only brief post-switch support; decision: negotiate length of support and data portability terms up front using the transition guidance topics.
Mistake to avoid: Signing a new contract without securing data portability and transition support terms.
Reference: ONC Health IT Playbook: Electronic health records
21. TEFCA as the Framework for Exchange
The Trusted Exchange Framework and Common Agreement enables health information exchange. Understanding how TEFCA works positions a practice to participate in broad exchange rather than building one-off connections, which is why it anchors the exchange guidance and should shape connectivity planning.
Example: A practice asks how to reach out-of-state records; decision: explore TEFCA-based exchange participation, since the framework exists to enable that exchange.
Mistake to avoid: Building bespoke point-to-point connections while ignoring the common exchange framework.
Reference: ONC Health IT Playbook: Electronic health records
22. APIs for Access to Health Information
Application programming interfaces support access to health information and ease information exchange with certified health IT. APIs let applications retrieve data under controlled terms, so they are the technical route when a practice or a patient-facing application needs structured access to record information.
Example: A patient wants her record in a third-party app; decision: use the API route, because APIs are the supported mechanism for app access to health information.
Mistake to avoid: Exporting record files manually when an API-based access path exists.
Reference: ONC Health IT Playbook: Electronic health records
23. Sending Patient Information Securely
Exchange guidance addresses how to send patient information securely. The decision point is method: transmission must guard against unauthorized access, which pairs with organizational security safeguards rather than replacing them. Secure sending is a distinct step from deciding that a disclosure is permitted in the first place.
Example: Staff email a spreadsheet of results to a consultant; decision: switch to the secure sending method, because secure transmission is required regardless of the disclosure being appropriate.
Mistake to avoid: Treating a permitted disclosure as license to use any transmission method.
Reference: ONC Health IT Playbook: Electronic health records
24. ADT Alerts and Transitions of Care
Admission, discharge, and transfer alerts support exchange by notifying practices when patients move between care settings, and facilitating transitions of care is a distinct exchange goal. ADT alerts change follow-up decisions by surfacing events a practice would otherwise learn about late or never.
Example: A hospitalized patient discharges without any call to her clinic; decision: enable ADT alerts, because they exist to surface admission and discharge events for follow-up.
Mistake to avoid: Relying on patients or hospitals to report admissions instead of using alerting.
Reference: ONC Health IT Playbook: Electronic health records
Certified Health IT, Information Blocking, and e-Prescribing
25. Certification Criteria for Health IT
Certified health IT guidance covers learning about certification criteria and reviewing certified products. Certification criteria define what a product has been tested to do, so the practical use is checking a product's certification against the capabilities a practice actually needs rather than treating certification as a generic seal of quality.
Example: A practice needs a specific exchange capability; decision: review the certified product listing against that capability, because certification is criterion-specific.
Mistake to avoid: Treating any certification as proof of every capability the practice wants.
Reference: ONC Health IT Playbook: Electronic health records
26. Recognizing Information Blocking Concerns
Information blocking is a named topic within ONC's certified health IT guidance, and that guidance sits in the 21st Century Cures Act context, where ONC works to improve how practices share information with patients and the quality of care they provide through technology. The term itself points at interference with the exchange of health information. The decision it forces on a practice: when local routines such as release delays or access restrictions stand between a requester and the records, evaluate them against the information blocking guidance rather than dismissing them as purely internal operational matters, because the Cures Act framework treats improved information sharing as the posture expected of practices using certified health IT.
Example: A clinic's release process routinely sits on record requests for weeks with no stated policy reason; decision: evaluate the delay against the information blocking guidance before treating it as a mere workflow preference, because interference with sharing is exactly what that topic addresses.
Mistake to avoid: Treating delays and access restrictions as purely internal operational matters outside the information blocking topic.
Reference: ONC Health IT Playbook: Electronic health records
27. Reporting Issues with Certified Health IT
Guidance includes reporting issues with certified health IT. When a certified product fails to perform as its certification implies, reporting is the channel that feeds oversight of certified products, so the decision is recognizing a product-level problem as reportable rather than merely a local annoyance to work around.
Example: A certified system garbles exchanged documents; decision: report the issue through the certified health IT channel, because product-level failures belong there.
Mistake to avoid: Silently working around a certified product defect instead of reporting it.
Reference: ONC Health IT Playbook: Electronic health records
28. PDMP Integration with Health IT
Prescription drug monitoring programs can be integrated with health IT, with additional resources supporting that integration. Integration changes the prescribing workflow decision: checking the monitoring database becomes part of the record workflow rather than a separate portal visit that competes with clinical time.
Example: Prescribers skip database checks because separate logins are slow; decision: integrate the monitoring program with the EHR, since integration is the supported fix for workflow friction.
Mistake to avoid: Treating the monitoring database as forever a separate manual lookup step.
Reference: ONC Health IT Playbook: Electronic health records
29. Electronic Prescribing of Controlled Substances
Electronic prescribing of controlled substances is a named health IT capability, with alignment to regulations as a directly related topic. The distinction to hold is between adopting the technical capability and meeting the regulatory alignment that governs controlled-substance prescribing; one does not satisfy the other.
Example: A practice enables controlled-substance e-prescribing features; decision: also review regulatory alignment, because guidance pairs the capability with its alignment topic.
Mistake to avoid: Confusing having the e-prescribing feature with satisfying the governing regulations.
Reference: ONC Health IT Playbook: Electronic health records
30. Smartphone Apps in the Opioid Context
Smartphone apps appear as an opioid-and-health-IT topic, meaning app-based tools are treated as part of the technology response rather than outside it. The decision point is evaluating whether an app fits the practice's workflow and patient population before recommending it to patients.
Example: A physician wants to recommend a recovery-support app; decision: evaluate it as a health IT tool within the opioid resources, not as an informal suggestion outside any oversight.
Mistake to avoid: Recommending patient apps informally without any evaluation of fit or source.
Reference: ONC Health IT Playbook: Electronic health records
Privacy Rule Foundations
31. Who Is a Covered Entity
The Privacy Rule covers health plans, health care clearinghouses, and any health care provider who transmits health information electronically in connection with standard HIPAA transactions, directly or through a billing service. Using email alone does not make a provider covered; the transmission must connect to a standard transaction.
Example: A therapist emails appointment reminders but bills only on paper; decision: not covered on that basis, because email use is not a standard transaction.
Mistake to avoid: Assuming any email use makes a provider a covered entity.
Reference: HHS Summary of the HIPAA Privacy Rule
32. PHI Spans Every Medium
Protected health information is individually identifiable information about health, care, or payment, held by a covered entity or business associate, in any form—electronic, paper, or oral. The medium does not change protection, which distinguishes the Privacy Rule from the Security Rule's electronic-only scope.
Example: A receptionist discusses a patient's results aloud at the desk; decision: treat it as protected, because oral form is still within Privacy Rule scope.
Mistake to avoid: Applying privacy protections only to written or electronic records.
Reference: HHS Summary of the HIPAA Privacy Rule
33. Two Paths to De-Identification
De-identified information carries no use or disclosure restrictions. Two methods exist: a formal determination by a qualified statistician, or removal of specified identifiers of the individual and of relatives, household members, and employers—adequate only if the entity has no actual knowledge that the remaining information could identify someone.
Example: A registry strips names but leaves full admission dates; decision: not de-identified under the removal method, because date elements are among identifiers requiring removal.
Mistake to avoid: Removing only names and assuming the record is de-identified.
Reference: HHS Summary of the HIPAA Privacy Rule
34. Limited Data Sets and Data Use Agreements
A limited data set is PHI from which specified direct identifiers of the individual and of relatives, employers, or household members have been removed. It may be used and disclosed for research, health care operations, or public health only if the recipient enters a data use agreement promising specified safeguards.
Example: A researcher needs town-level geography retained; decision: provide a limited data set with a data use agreement, since limited data sets permit more geography than de-identification.
Mistake to avoid: Releasing a limited data set without a signed data use agreement.
Reference: HHS Summary of the HIPAA Privacy Rule
35. Treatment, Payment, and Operations Boundaries
A covered entity may use and disclose PHI for its own treatment, payment, and health care operations without authorization. Treatment includes consultation and referral between providers; payment includes obtaining premiums or reimbursement; operations include quality improvement, credentialing, audits, and general administration. Beyond these boundaries, another permission is needed.
Example: A hospital shares a chart with a consulting physician; decision: permitted as treatment without authorization, because consultation between providers is treatment.
Mistake to avoid: Requesting authorizations for routine treatment consultations the Rule already permits.
Reference: HHS Summary of the HIPAA Privacy Rule
36. Minimum Necessary and Its Exceptions
Covered entities must make reasonable efforts to use, disclose, and request only the minimum PHI needed for the intended purpose, and may not send an entire medical record unless the whole record is specifically justified. The standard does not apply to treatment disclosures, disclosures to the individual, authorized uses, HHS enforcement, or uses required by law.
Example: A payer requests a full record for a single-claim review; decision: send only the minimum necessary, because payment requests remain subject to the limit.
Mistake to avoid: Sending entire records routinely because treatment disclosures are exempt.
Reference: HHS Summary of the HIPAA Privacy Rule
Authorizations, Rights, and Special Privacy Rules
37. When Authorization Is Required
Written authorization is required for any use or disclosure not for treatment, payment, operations, or otherwise permitted or required by the Rule—for example, disclosures to a life insurer for coverage, an employer for pre-employment physical results, or a pharmaceutical firm for its own marketing. Authorizations must be plain language with specified content, including expiration and revocation rights.
Example: A life insurer requests exam results; decision: obtain written authorization first, because insurer coverage disclosures are a named authorization case.
Mistake to avoid: Releasing records to insurers or employers without a valid authorization.
Reference: HHS Summary of the HIPAA Privacy Rule
38. Psychotherapy Notes Are Separate
Psychotherapy notes—recorded by a mental health professional documenting or analyzing private counseling sessions and kept separate from the rest of the record—require authorization for most uses, including treatment, payment, and operations. They exclude medication prescribing and monitoring, session times, and treatment summaries, which remain in the regular record.
Example: A plan requests counseling notes for utilization review; decision: refuse without authorization, because payment review of psychotherapy notes requires one.
Mistake to avoid: Treating session times or treatment summaries as psychotherapy notes.
Reference: HHS Summary of the HIPAA Privacy Rule
39. Marketing Rules and Their Carve-Outs
Marketing is any communication about a product or service that encourages purchase or use, and it requires authorization—except for face-to-face communications and promotional gifts of nominal value. Carve-outs include treatment communications, case management or care coordination, and communications describing the entity's own health-related services or benefit plan.
Example: A clinic newsletter describes its new diabetes classes; decision: no authorization needed, because describing the entity's own health services is carved out.
Mistake to avoid: Treating every product or service communication as requiring marketing authorization.
Reference: HHS Summary of the HIPAA Privacy Rule
40. Individual Access and the Designated Record Set
Individuals have the right to review and obtain a copy of PHI in the designated record set—records used to make decisions about them, such as medical and billing records. Psychotherapy notes, information compiled for legal proceedings, and certain lab results are excepted, and harm-based denials must be reviewable by a licensed health care professional.
Example: A patient requests his billing file; decision: provide access, because billing records are part of the designated record set.
Mistake to avoid: Denying access to billing records as though only the clinical chart qualifies.
Reference: HHS Summary of the HIPAA Privacy Rule
41. Personal Representatives and Minors
A personal representative—someone legally authorized to make health care decisions for an individual or to act for a deceased person or estate—is treated as the individual. Parents generally act for minor children, but where state law gives minors control, or where the entity reasonably believes the representative may endanger the individual, that authority yields.
Example: A father requests a teenager's confidential visit record; decision: check state law first, because minors' records defer to state law in exceptional cases.
Mistake to avoid: Granting or denying parental access without checking the applicable state-law exception.
Reference: HHS Summary of the HIPAA Privacy Rule
42. Notice of Privacy Practices Duties
Direct treatment providers must deliver the notice of privacy practices no later than the first service encounter, post it prominently at each delivery site, and make good faith efforts to obtain written acknowledgement, documenting any failure. Health plans must distribute at enrollment and remind enrollees periodically. Entities must act in accordance with their notices.
Example: A new patient's acknowledgement card goes unsigned; decision: document the reason and continue care, because good faith effort with documented failure satisfies the duty.
Mistake to avoid: Skipping the notice at first encounters or failing to document missing acknowledgements.
Reference: HHS Summary of the HIPAA Privacy Rule
Security Rule Safeguards
43. ePHI Scope Is Electronic Only
The Security Rule protects electronic protected health information—PHI maintained or transmitted by electronic media—and does not apply to PHI on paper or conveyed verbally, unlike the Privacy and Breach Notification Rules. Classifying information correctly determines which rule's safeguards attach to a given situation.
Example: A printed census sheet is left at a workstation; decision: handle under Privacy Rule safeguards, not Security Rule technical controls, because paper is outside Security scope.
Mistake to avoid: Applying Security Rule technical safeguards to paper or oral information.
Reference: HHS Summary of the HIPAA Security Rule
44. The Administrative Safeguards Bundle
Administrative safeguards include security management with risk assessment, assigned security responsibility to a designated official, workforce security with authorization and supervision, information access management tied to roles, awareness and training with sanctions, incident procedures, contingency planning, and periodic evaluation. Each is a policy-and-procedure duty, not merely a technology purchase.
Example: A practice buys encryption but has no designated security official; decision: appoint one, because assigned security responsibility is an administrative requirement encryption cannot satisfy.
Mistake to avoid: Equating security compliance with technology purchases while omitting administrative policies.
Reference: HHS Summary of the HIPAA Security Rule
45. Physical Safeguards for Facilities and Devices
Physical safeguards cover facility access controls limiting physical access to electronic systems, workstation use and security policies, and device and media controls governing the receipt, removal, movement, and final disposition of hardware and electronic media—including procedures for removing ePHI before media are made available for reuse.
Example: A practice donates old computers; decision: clear ePHI before release, because media reuse requires prior removal of ePHI.
Mistake to avoid: Discarding or reusing devices without clearing the ePHI they hold.
Reference: HHS Summary of the HIPAA Security Rule
46. Technical Safeguards for Systems
Technical safeguards include access control allowing only authorized persons to reach ePHI, audit controls recording and examining system activity, mechanisms confirming ePHI has not been improperly altered or destroyed, authentication verifying that a person seeking access is who they claim, and transmission security guarding against unauthorized access during network transmission.
Example: A vendor proposes remote access with shared logins; decision: reject it, because authentication requires verifying the individual, which shared credentials defeat.
Mistake to avoid: Accepting shared accounts that make audit trails and authentication meaningless.
Reference: HHS Summary of the HIPAA Security Rule
47. Addressable Does Not Mean Optional
Every Security Rule standard must be met, but implementation specifications are either required or addressable. Addressable means the entity decides whether the specification is reasonable and appropriate for it; if not, the entity must adopt an alternative measure achieving the standard's purpose and document why the addressable specification was not implemented.
Example: A small clinic finds an addressable specification impractical; decision: implement a reasonable alternative and document the rationale, because skipping without documentation is noncompliance.
Mistake to avoid: Reading addressable as optional and ignoring undocumented substitutions.
Reference: HHS Summary of the HIPAA Security Rule
48. Contingency Planning for Emergencies
Contingency plan requirements call for responding to emergencies or other occurrences that damage information systems containing ePHI, including establishing plans for backing up ePHI, restoring lost data, and continuing critical business processes for protecting ePHI security while operating in emergency mode.
Example: A server room floods; decision: activate the contingency plan, because continuing critical processes in emergency mode is part of the requirement.
Mistake to avoid: Equating contingency planning with backups alone and omitting emergency-mode operations.
Reference: HHS Summary of the HIPAA Security Rule
Risk Management and Business Associate Compliance
49. Risk Analysis Drives Everything Else
An accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI is required within security management, and it affects implementation of all other safeguards by identifying which measures are reasonable and appropriate. Security decisions made without a risk analysis lack the required foundation.
Example: A practice copies another clinic's security policy set; decision: insufficient, because measures must trace to its own risk analysis results.
Mistake to avoid: Adopting security measures without conducting the entity's own risk analysis.
Reference: HHS Summary of the HIPAA Security Rule
50. Scalable, Technology-Neutral Compliance
The Security Rule is flexible, scalable, and technology neutral: entities consider their size, complexity, and capabilities, technical infrastructure, the costs of security measures, and the probability and criticality of potential risks when selecting safeguards. No specific measure is dictated, so identical products are not required across differently sized entities.
Example: A solo practice skips an enterprise monitoring suite; decision: acceptable if a smaller measure is reasonable given its size, complexity, and risks.
Mistake to avoid: Assuming one prescribed security product list fits every regulated entity.
Reference: HHS Summary of the HIPAA Security Rule
51. Business Associate Agreement Requirements
Before a business associate may create, receive, maintain, or transmit ePHI, a written agreement must document satisfactory assurances, obligate the associate to comply with the Security Rule, require subcontractor agreements imposing the same obligations, and require reporting security incidents including breaches. HITECH makes business associates directly liable for Security Rule violations.
Example: A billing service begins work before signing; decision: halt ePHI flow until the agreement is executed, because the agreement must precede access.
Mistake to avoid: Allowing contractor access to ePHI before the agreement is signed.
Reference: HHS Summary of the HIPAA Security Rule
52. Subcontractors Inherit the Chain
A business associate must obtain satisfactory assurances in writing from any subcontractor that creates, receives, maintains, or transmits ePHI on its behalf, and those agreements must meet the same requirements as agreements between covered entities and business associates. The obligation travels down the service chain, not just one level.
Example: A billing vendor hires a transcription subcontractor; decision: the vendor must secure a compliant subcontractor agreement before any ePHI moves.
Mistake to avoid: Assuming a covered entity must police second-tier subcontractors its business associate hires.
Reference: HHS Summary of the HIPAA Security Rule
53. Security Incident Response and Sanctions
Entities must identify and respond to suspected or known security incidents, mitigate harmful effects to the extent possible, and document security incidents and their outcomes. Workforce members must be trained on policies and procedures, and appropriate sanctions must be applied against those who violate them. Response and accountability are paired duties.
Example: A staffer clicks a phishing link exposing records; decision: respond, mitigate, document the incident, and apply the sanctions policy, because all duties attach.
Mistake to avoid: Documenting incidents but never applying sanctions for policy violations.
Reference: HHS Summary of the HIPAA Security Rule
54. Documentation Retention and Updates
Required documentation of policies, procedures, actions, activities, and assessments must be maintained until six years after the later of the document's creation or last effective date, kept available to those responsible for implementing it, and periodically reviewed and updated in response to environmental or organizational changes affecting ePHI security.
Example: A clinic revises access policies after adding a portal; decision: update the documentation too, because changes affecting security trigger required updates.
Mistake to avoid: Letting security documentation go stale after system or organizational changes.
Reference: HHS Summary of the HIPAA Security Rule
Value-Based Care, Population Health, and Care Settings
55. Value-Based Care and the Quality Payment Program
Value-based care links payment to value rather than volume, and the Quality Payment Program is the framework for learning about it. The distinction matters for technology planning: EHR use must support measurement and reporting activities, not only day-to-day documentation of individual encounters.
Example: A practice joins an incentive program; decision: configure the EHR for quality data capture, because value-based participation depends on measurable performance.
Mistake to avoid: Treating the EHR as a documentation tool only when payment depends on reported quality.
Reference: ONC Health IT Playbook: Electronic health records
56. MIPS as a Payment Track
The Merit-based Incentive Payment System is a Quality Payment Program component that practices are directed to stay informed about. MIPS adjusts payment based on measured performance, so the technology specialist's role is ensuring the practice's systems reliably capture the evidence that performance scoring uses.
Example: A practice cannot extract its quality measures; decision: fix data capture and reporting workflows, because performance scoring depends on extractable measure data.
Mistake to avoid: Ignoring measure data readiness until reporting deadlines arrive.
Reference: ONC Health IT Playbook: Electronic health records
57. Alternative Payment Models
Alternative Payment Models are a distinct Quality Payment Program path from MIPS, and understanding them is a named guidance topic. Models change what the practice must track—such as episode- or population-level information—so EHR configuration and reporting decisions differ from fee-for-service or MIPS setups.
Example: A group enters a model paying for episodes of care; decision: reconfigure tracking around episode data, because APM participation shifts what must be measured.
Mistake to avoid: Assuming MIPS-style reporting preparation covers Alternative Payment Model participation.
Reference: ONC Health IT Playbook: Electronic health records
58. The Promoting Interoperability Performance Category
Promoting Interoperability is a named performance category within the value-based care framework, listed alongside the Quality Payment Program, MIPS, and Alternative Payment Models. Its placement carries a planning consequence: interoperability and electronic exchange work is categorized as performance within that framework rather than as background infrastructure. The decision: when a practice invests in exchange capability or electronic patient engagement technology, recognize that this work maps to a named performance category of the value-based framework, so those capability decisions belong in performance planning rather than being treated as invisible plumbing.
Example: A practice asks whether its new health information exchange connection matters beyond daily operations; decision: yes—map the capability to the Promoting Interoperability performance category, because exchange work falls under a named performance category of the value-based framework rather than pure infrastructure.
Mistake to avoid: Treating exchange and engagement capability as background infrastructure unrelated to the framework's performance categories.
Reference: ONC Health IT Playbook: Electronic health records
59. Population Health Tools and Registries
Population health management tools, strengthening care management, participating in a patient registry, and supporting public health data reporting are linked guidance topics. These shift the EHR from individual encounters toward group-level analysis and external reporting obligations, which requires different queries and workflows.
Example: A practice wants to find all patients overdue for monitoring; decision: use population health tools rather than chart-by-chart review, because group-level identification is their purpose.
Mistake to avoid: Using visit-by-visit searches for questions that need population-level queries.
Reference: ONC Health IT Playbook: Electronic health records
60. Care Settings, Disparities, and Telehealth
Guidance addresses supporting long-term and post-acute care, improving care in rural areas, reducing health disparities, and learning about telehealth. Setting changes the technology plan: rural connectivity constraints, post-acute information exchange needs, and disparity-reduction goals each drive different EHR and exchange decisions.
Example: A rural clinic plans a telehealth launch; decision: assess connectivity first, because rural settings carry distinct infrastructure considerations named in guidance.
Mistake to avoid: Applying one uniform technology plan across rural, post-acute, and disparity-focused settings.
Reference: ONC Health IT Playbook: Electronic health records
References and further reading
Source links checked on Oct 2, 2026.