Work through the ten groups in order, because later application builds on earlier foundations. Each concept pairs a rule with a short resolved example and a mistake to avoid, so read the explanation, predict the example's outcome, and check yourself before moving on. References below identify the source texts behind each rule. This guide supports subject mastery for the CEHRS credential; pair it with official preparation materials and current regulations, since federal guidance and payer rules evolve over time.
EHR Fundamentals and System Architecture
1. Defining the EHR Beyond Digital Paper
An EHR is software used to securely document, store, retrieve, share, and analyze information about individual patient care. The analytic and sharing functions separate it from a scanned chart archive, which only stores images without structured, searchable data.
Example: A practice scans ten years of paper charts into the system. Decision: those images are stored documents, not structured data, so registry and reporting queries cannot read them.
Mistake to avoid: Treating a scanned paper archive as if it were fully functional, analyzable EHR data.
Reference: ONC Health IT Playbook: Electronic health records
2. Choosing Between Local and Cloud Hosting
Locally hosted systems keep software and data on practice servers, making the practice responsible for physical security, backups, and equipment costs. Cloud systems reduce upfront costs and share security responsibility with the vendor but offer less direct control over the data.
Example: A rural clinic lacking reliable high-speed internet keeps its system local, because cloud access depends on connectivity the clinic cannot guarantee.
Mistake to avoid: Assuming the cloud vendor single-handedly handles every security obligation for the practice's hosted data.
Reference: ONC Health IT Playbook: Electronic health records
3. Certified Health IT as a Purchasing Criterion
ONC certifies health IT products against established criteria, and most office-based clinicians and hospitals use certified systems. Certification signals that a product meets defined technical capabilities, which matters especially when a practice plans to exchange records with other organizations.
Example: A group joining a regional hospital network rejects an otherwise attractive uncertified product because the network's exchange arrangements require certified technology.
Mistake to avoid: Equating a well-known or expensive product with one that actually holds certification.
Reference: ONC Health IT Playbook: Electronic health records
4. Locating Your Practice on the EHR Journey
EHR adoption moves through planning and selection, adoption and implementation, optimization with workflow redesign, and replacement with data migration. Identifying the current phase determines which tools apply, because selection aids, implementation guides, and optimization resources answer different problems.
Example: Two years past go-live with sluggish workflows, a practice selects workflow mapping tools, correctly recognizing it is optimizing rather than implementing.
Mistake to avoid: Applying vendor selection checklists to a practice that actually needs optimization support.
Reference: ONC Health IT Playbook: Electronic health records
5. The Specialist's Big-Picture Impact
The credential is designed for people who see how their EHR work affects patients and the institution, and it adds value across administrative and clinical roles. Every entry task connects to downstream care coordination, patient safety, and reimbursement outcomes.
Example: A specialist verifying insurance details at registration prevents claim rejections later, because accurate entry at the front end drives payment downstream.
Mistake to avoid: Viewing each record task as an isolated clerical entry with no downstream clinical or financial consequence.
Reference: NHA CEHRS implementation guide
6. Go-Live as a Milestone, Not an Endpoint
Implementing an EHR is an ongoing journey with no final destination. Each new technology added later, such as a patient portal, a network connection, or participation in new payment models, should trigger a fresh review of workflows and system use.
Example: After connecting a patient portal, a practice re-examines message triage workflows instead of assuming original procedures still fit the new channel.
Mistake to avoid: Declaring the project finished at go-live and never revisiting workflows as technology changes.
Reference: ONC Health IT Playbook: Electronic health records
EHR Selection, Contracting, and Data Migration
7. Assessing Readiness Before Shopping
Common roadblocks include incomplete understanding of information needs, uncertain costs, and the effort of identifying a system. Before evaluating products, assess organizational readiness, staff eagerness, availability of a champion, stakeholder buy-in, and the team's ability to work together.
Example: A practice with reluctant staff names a respected clinical champion before scheduling vendor demos, because resistance is a recognized implementation roadblock.
Mistake to avoid: Booking vendor demonstrations before anyone has assessed the practice's readiness and internal support.
Reference: ONC Health IT Playbook: Electronic health records
8. Requirements First, Products Second
Selection succeeds when the practice identifies and prioritizes its technical and operational requirements before comparing products. EHR systems are not one-size-fits-all, so clinicians and staff must weigh their specific needs and resources rather than adapt the practice to a popular system.
Example: A specialty group ranks lab interfacing and e-prescribing as priorities, then scores every vendor demo against that written list for a fair comparison.
Mistake to avoid: Choosing a system first and forcing the practice's needs to fit it.
Reference: ONC Health IT Playbook: Electronic health records
9. Contract Terms That Protect the Practice
EHR contracts should address safety and security, system performance expectations, data management and protection, interoperability and integration, risk and liability allocation, vendor dispute resolution, and transition issues. Negotiating these terms up front prevents problems far harder to fix after deployment.
Example: A contract lacking data portability language gets renegotiated before signing, because future migration depends on the practice's ability to retrieve its data.
Mistake to avoid: Signing the vendor's standard agreement without negotiating performance, data protection, and exit terms.
Reference: ONC Health IT Playbook: Electronic health records
10. Service Level Agreements for Cloud Systems
Cloud-based EHRs reduce upfront and maintenance costs and can improve availability, but responsibility for data security is shared and direct control is reduced. Practices should secure legal contracts and appropriate service level agreements with the cloud vendor and establish ongoing monitoring.
Example: Repeated afternoon slowdowns prompt the practice to invoke the service level agreement's performance terms rather than absorb the downtime silently.
Mistake to avoid: Relying on a purchase order where a monitored service level agreement is needed.
Reference: ONC Health IT Playbook: Electronic health records
11. Structured Vendor Demonstrations and Comparisons
Published demonstration scenarios, vendor question sets, comparison tools, and pricing templates let a practice test vendors on equal footing. Line-item pricing templates covering software, implementation, training, and support expose costs a single quote hides, for both licensing and cloud models.
Example: Three vendors demonstrate the same patient-visit scenario, and the team scores each against identical criteria, keeping the comparison objective.
Mistake to avoid: Comparing vendors based on separate, unstructured demonstrations and headline prices alone.
Reference: ONC Health IT Playbook: Electronic health records
12. Planning Data Migration Deliberately
Migration is warranted when a practice outgrows its system, expands, or joins another practice, and it demands careful planning so the new system can integrate and access historical data. A chart migration and scanning checklist guides which paper content gets imported.
Example: Two merging practices decide before go-live which paper elements are scanned versus summarized, preventing record gaps discovered months after conversion.
Mistake to avoid: Treating data migration as a technical afterthought handed entirely to the incoming vendor.
Reference: ONC Health IT Playbook: Electronic health records
Implementation, Workflow, and Usability
13. Pre-Implementation Versus Implementation Work
Pre-implementation covers governance, communication with staff and patients, workflow redesign, and training. Implementation covers tailoring the system, change management, backloading patient histories, allowing training time, and support. Redesign belongs in the earlier phase, before habits form around the new system.
Example: A practice redesigns its prescription refill workflow before go-live, correctly placing redesign in pre-implementation rather than after staff adapt to old habits.
Mistake to avoid: Postponing workflow redesign until after go-live, when staff have already built workarounds.
Reference: ONC Health IT Playbook: Electronic health records
14. Governance and Data Stewardship
A governance process creates guidance and a stewardship plan focused on data safety and integrity, ensuring sustainable, appropriate data management. The SAFER self-assessment guides offer recommended practices for safe EHR use, including organizational responsibilities, contingency planning, and test results follow-up.
Example: During pre-implementation, a practice names a data steward and works through the SAFER guides to assign safety responsibilities before any records go live.
Mistake to avoid: Installing a system without a governance structure or anyone designated as data steward.
Reference: ONC Health IT Playbook: Electronic health records
15. Workflow Mapping Before Automation
Workflow process mapping documents the steps staff take to complete tasks, revealing redundancy and bottlenecks. Mapping current and future states before configuration prevents automating a broken process, since an EHR faithfully reproduces inefficiency when bad workflows are simply carried over.
Example: Mapping shows patients give medication history at three separate stops; the practice consolidates intake before configuring the system around one step.
Mistake to avoid: Configuring the new system to replicate an inefficient paper workflow step for step.
Reference: ONC Health IT Playbook: Electronic health records
16. Usability Depends on Implementation Choices
Usability means how easy, effective, and efficient software is to use, and it depends on how the system is implemented, not only on vendor design. Continuous optimization, structured feedback from clinicians and patients, and improvements based on that feedback keep usability high.
Example: Two practices run the same product; the one that configures order sets to its specialties reports better usability, showing local choices matter.
Mistake to avoid: Blaming only the vendor for usability problems that local configuration and feedback could fix.
Reference: ONC Health IT Playbook: Electronic health records
17. Evaluating the Implementation Afterward
Once live, the practice should evaluate whether the process went smoothly, whether everyone participated, what the strengths and weaknesses were, and how workflow was affected. The answers identify improvement opportunities and shape how the next technology change should be run.
Example: A post-go-live review finds staff skipping a registration step; the practice fixes the step itself rather than retraining around it.
Mistake to avoid: Skipping evaluation because the system is live and the team is tired.
Reference: ONC Health IT Playbook: Electronic health records
18. Managing Change, Not Just Installing Software
Change management principles address the human side of implementation. A multidisciplinary approach, training, mock go-lives, and system testing prepare staff before real patients are affected, and encouraging staff along the way sustains adoption through the difficult early weeks.
Example: A practice runs a mock go-live weekend with fake patients, surfacing registration problems before real patient encounters begin on day one.
Mistake to avoid: Announcing a go-live date without any change management or rehearsal plan.
Reference: ONC Health IT Playbook: Electronic health records
Interoperability and Health Information Exchange
19. Interoperability as a Core Expectation
Under the 21st Century Cures Act, ONC works to improve how practices share information with patients and the quality of care through technology. Interoperability, meaning EHRs that communicate easily with each other, is a key objective rather than an optional feature.
Example: A practice prioritizes a product that exchanges records with the regional hospital, recognizing easy communication as a core requirement, not a luxury.
Mistake to avoid: Treating the ability to exchange records as an optional feature deferred to later.
Reference: ONC Health IT Playbook: Electronic health records
20. Health Information Networks and TEFCA
The Trusted Exchange Framework and Common Agreement enables health information exchange across networks. Connecting to a health information network is itself a new technology adoption, so the practice should revisit workflows and policies at the same time it establishes the connection.
Example: On joining an exchange network, a practice updates its records-release workflow rather than simply adding a technical connection and moving on unchanged.
Mistake to avoid: Connecting to an exchange network without reviewing the release workflows it changes.
Reference: ONC Health IT Playbook: Electronic health records
21. APIs as an Access Pathway
Application programming interfaces ease information exchange and support access to health information. An API allows approved outside software to interact with the EHR's data under controlled terms, giving patients and practices alternatives to portal-only or print-based record access.
Example: A patient asks for records in a health app; the practice enables API-based access instead of printing and mailing paper copies.
Mistake to avoid: Assuming the patient portal is the only legitimate route to record access.
Reference: ONC Health IT Playbook: Electronic health records
22. Evaluating Record Requests Instead of Blanket Denials
ONC's Health IT Playbook lists information blocking as a distinct topic within its certified health IT guidance, so a practice that exchanges electronic health information should not run requests through blanket refusal policies. The operative check comes from the Privacy Rule: classify each incoming request as a required disclosure (to the individual or to HHS), a permitted disclosure (treatment, payment, health care operations, or a public interest category), or one needing written authorization, and refuse only what the Rule allows refusing.
Example: A staffer wants to deny an electronic records request citing a general office policy; the correct step is classifying the requester first — an individual asking for her own record must receive it — before any refusal is issued.
Mistake to avoid: Blanket-denying record requests to stay safe, which blocks disclosures the Privacy Rule requires or permits.
Reference: ONC Health IT Playbook: Electronic health records; HHS Summary of the HIPAA Privacy Rule
23. Transmission Security for Sent Records
Practices must send patient information securely, and the Security Rule requires technical measures guarding against unauthorized access to ePHI transmitted over electronic networks. Ordinary email lacks these safeguards, so transfers should use the EHR's secure channels or equivalent protected methods.
Example: Asked to send a results summary, a specialist uses the EHR's secure messaging rather than standard email, which lacks transmission protection.
Mistake to avoid: Emailing identifiable patient data unencrypted because it is faster for the staff.
Reference: ONC Health IT Playbook: Electronic health records; HHS Summary of the HIPAA Security Rule
24. ADT Alerts and Care Transition Documents
Admission, discharge, and transfer alerts notify practices when patients move between care settings, supporting timely follow-up. During transitions of care, clinical documents exchanged between systems can be checked with a standards-based scorecard to identify and resolve interoperability problems in the information received.
Example: A discharge alert prompts the primary care office to schedule follow-up, closing a care gap the practice would otherwise miss entirely.
Mistake to avoid: Ignoring discharge alerts because no one is assigned to act on them.
Reference: ONC Health IT Playbook: Electronic health records
HIPAA Privacy Rule Foundations
25. Who Is a Covered Entity
The Privacy Rule covers health plans, health care clearinghouses, and providers that transmit health information electronically in connection with standard HIPAA transactions, such as claims and eligibility inquiries. Using email alone does not make a provider covered; the transmission must involve a standard transaction.
Example: A provider who bills through an electronic billing service is covered, because the rule counts transactions sent on the provider's behalf by a third party.
Mistake to avoid: Assuming that any email use, by itself, makes a practice a covered entity.
Reference: HHS Summary of the HIPAA Privacy Rule
26. PHI Exists in Every Medium
Protected health information is individually identifiable information about health, care, or payment that identifies the individual, in any form: electronic, paper, or oral. Common identifiers include name, address, birth date, and Social Security number, so hallway conversations are covered alongside database records.
Example: A staff member discusses a patient's condition within earshot of the waiting room; that oral disclosure involves PHI and falls under the Privacy Rule.
Mistake to avoid: Believing privacy obligations attach only to information stored electronically in the EHR.
Reference: HHS Summary of the HIPAA Privacy Rule
27. Identifying Business Associates
A business associate is a non-workforce person or organization performing functions for a covered entity involving PHI, such as claims processing, billing, data analysis, or utilization review, or providing legal, accounting, consulting, or financial services. Incidental access alone does not create business associate status.
Example: A shredding service that never sees identifiable data is not a business associate; the billing service that handles claims data is.
Mistake to avoid: Labeling every contractor as a business associate regardless of any PHI access.
Reference: HHS Summary of the HIPAA Privacy Rule
28. De-Identified Data Versus a Limited Data Set
De-identified information has identifiers of the individual and of relatives, household members, and employers removed, with no actual knowledge the remainder identifies anyone, and carries no use restrictions. A limited data set retains dates and town-level geography but requires a data use agreement for permitted purposes.
Example: An outcomes study needs admission dates, which de-identification removes, so the practice supplies a limited data set under a signed data use agreement.
Mistake to avoid: Treating a limited data set as freely shareable, de-identified information with no agreement.
Reference: HHS Summary of the HIPAA Privacy Rule
29. The Notice of Privacy Practices
Covered entities must maintain a notice describing how they may use and disclose PHI, their duties, individual rights including complaint routes to the entity and HHS, and a contact point. Direct treatment providers deliver it at the first service encounter, post it at each site, and make good faith efforts to obtain written acknowledgement.
Example: For a first telephonic service encounter, the provider mails the notice promptly and documents why no signed acknowledgement was obtained that day.
Mistake to avoid: Skipping documentation of the reason whenever a signed acknowledgement is not obtained.
Reference: HHS Summary of the HIPAA Privacy Rule
30. Personal Representatives and Minors
A personal representative, someone legally authorized to act for the individual or the estate, is treated as the individual for uses, disclosures, and rights. Parents generally act for minor children, but exceptions defer to state law, and where state law is silent, a licensed professional's judgment governs access.
Example: A divorced father requests his adolescent's records; staff verify his status as personal representative and check applicable state law before releasing anything.
Mistake to avoid: Releasing a minor's records to any parent without checking the applicable exceptions.
Reference: HHS Summary of the HIPAA Privacy Rule
Permitted Uses, Disclosures, and Individual Rights
31. Treatment, Payment, and Operations
A covered entity may use and disclose PHI without authorization for its own treatment, payment, and health care operations. Treatment includes coordination and consultation between providers, so referrals flow freely; payment includes obtaining premiums or reimbursement; operations include quality assessment, credentialing, audits, and administration.
Example: A referring physician sends the consult note to a specialist without an authorization, because disclosure for another provider's treatment is permitted.
Mistake to avoid: Demanding a signed patient authorization for every routine referral between treating providers.
Reference: HHS Summary of the HIPAA Privacy Rule
32. Minimum Necessary in Practice
Covered entities must make reasonable efforts to limit uses, disclosures, and requests to the amount needed for the purpose. The standard does not apply to treatment disclosures to providers, disclosures to the individual, disclosures under an authorization, disclosures to HHS, or those required by law.
Example: A payer requests records for one encounter; the practice sends that encounter only, because the whole chart is not justified as minimum necessary.
Mistake to avoid: Sending the entire medical record by default whenever any request arrives.
Reference: HHS Summary of the HIPAA Privacy Rule
33. Authorizations and Marketing
Uses or disclosures outside permitted categories require written authorization in plain language, specifying the information, the parties, expiration, and the right to revoke in writing. Marketing generally requires authorization, and when the entity receives remuneration for it, the authorization must reveal that fact.
Example: A practice paid to send letters about a manufacturer's product must obtain patient authorizations that disclose the payment to patients upfront.
Mistake to avoid: Using one generic authorization form for every nonstandard disclosure or marketing effort.
Reference: HHS Summary of the HIPAA Privacy Rule
34. Informal Permission and Incidental Disclosures
For facility directories and involvement of family or friends in care, informal agreement suffices: the individual is asked, or circumstances clearly give the chance to agree or object. Incidental disclosures flowing from a permitted use are allowed when reasonable safeguards and minimum necessary limits are in place.
Example: A hospital may confirm a patient's general condition and room to someone asking by name, but not share clinical details, under directory practice.
Mistake to avoid: Giving detailed clinical information to a directory inquirer who asked only by name.
Reference: HHS Summary of the HIPAA Privacy Rule
35. Public Interest Disclosures and Exposure Notification
Twelve national priority purposes permit disclosure without authorization under specific conditions, including required-by-law, public health, oversight, judicial, and law enforcement situations. Public health disclosure can include notifying individuals who may have contracted or been exposed to a communicable disease, but only when authorized by law.
Example: A health department authorizes notifying people exposed at a clinic; staff share the authorized exposure information, not entire charts, since exposure notification is not illness confirmation.
Mistake to avoid: Releasing full records when the authorization covers only exposure notification of named individuals.
Reference: HHS Summary of the HIPAA Privacy Rule
36. Access, Amendment, and Accounting Rights
Individuals may review and copy PHI in the designated record set, with exceptions like psychotherapy notes and information compiled for legal proceedings, and may request amendment of inaccurate information through a documented denial and disagreement process. They may also obtain an accounting of disclosures, which excludes treatment, payment, and operations.
Example: A patient requests an accounting; the practice lists reportable disclosures from the prior six years but omits routine treatment and payment disclosures.
Mistake to avoid: Treating the accounting as a list of every treatment conversation in the chart.
Reference: HHS Summary of the HIPAA Privacy Rule
HIPAA Security Rule Safeguards
37. Security Rule Scope and Direct BA Liability
The Security Rule protects only ePHI, meaning PHI maintained or transmitted by electronic media, and does not reach paper or verbal information. Under the HITECH Act, business associates must meet the safeguards directly and face direct enforcement, rather than being bound only through contracts.
Example: A transcriptionist handling digital dictation files must implement the safeguards personally as a business associate, not merely promise the practice compliance.
Mistake to avoid: Applying Security Rule technical safeguards to paper files and purely spoken conversations.
Reference: HHS Summary of the HIPAA Security Rule
38. Three Families of Safeguards
Regulated entities must implement administrative, physical, and technical safeguards that are reasonable and appropriate. Administrative measures govern people and process, physical measures protect facilities and equipment, and technical measures control systems, so a complete program requires all three working together.
Example: A practice with strong passwords but no staff training has a technical control without the administrative safeguard that makes it effective.
Mistake to avoid: Equating security compliance with technical controls while ignoring administrative and physical measures entirely.
Reference: HHS Summary of the HIPAA Security Rule
39. Administrative Safeguards in Detail
Administrative safeguards require a designated security official, workforce security with appropriate authorization and supervision, access management tied to roles and the minimum necessary principle, security awareness training with sanctions for violations, incident procedures, contingency planning, and periodic evaluation of the program.
Example: A practice designates its office manager as security official and limits record access by job role, matching the access management requirement.
Mistake to avoid: Granting every staff member identical record access regardless of their actual role.
Reference: HHS Summary of the HIPAA Security Rule
40. Contingency Planning for Emergencies
Entities must establish procedures responding to emergencies or occurrences that damage systems containing ePHI, including backing up data, restoring lost data, and continuing critical business processes while operating in emergency mode. A backup that has never been tested for restoration does not satisfy the intent.
Example: After a server failure, a practice restores from tested backups and keeps scheduling running on paper per its emergency mode plan.
Mistake to avoid: Maintaining backups without ever testing whether lost data can actually be restored.
Reference: HHS Summary of the HIPAA Security Rule
41. Physical Safeguards for Facilities and Devices
Physical safeguards cover facility access control, proper workstation use and protection, and device and media controls governing hardware moving into, out of, and within the facility. Procedures must address the final disposition of ePHI and the removal of data from media before that media is reused.
Example: Before surplus tablets are reused by another department, staff wipe the stored patient data, satisfying the requirement for cleared media.
Mistake to avoid: Donating or reusing devices that still hold patient data from prior use.
Reference: HHS Summary of the HIPAA Security Rule
42. Technical Safeguards for System Access
Technical safeguards require access controls limiting ePHI to authorized persons, audit mechanisms recording and examining system activity, measures confirming data is not improperly altered or destroyed, authentication procedures verifying identity, and transmission security protecting data sent over electronic networks.
Example: Audit logs show a retired employee's account was never deactivated; the practice corrects access controls and reviews what was viewed after departure.
Mistake to avoid: Leaving a departed employee's account active because deactivation feels awkward or unnecessary.
Reference: HHS Summary of the HIPAA Security Rule
Security Risk Management and Organizational Duties
43. Risk Analysis Drives Everything Else
An accurate, thorough assessment of risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI anchors the security program. Identified risks determine which measures are reasonable and appropriate, considering the entity's size, complexity, technical infrastructure, costs, and the probability and criticality of potential risks.
Example: A risk analysis finds unencrypted laptops; encryption becomes the priority because the assessment, not habit, selects the next safeguard.
Mistake to avoid: Buying security tools first and writing a risk analysis to match them.
Reference: HHS Summary of the HIPAA Security Rule
44. Confidentiality, Integrity, and Availability
Confidentiality means data is not available or disclosed to unauthorized persons or processes; integrity means it has not been altered or destroyed in an unauthorized manner; availability means it is accessible and usable on demand by an authorized person. Each failure mode demands different protections.
Example: Ransomware that locks records is primarily an availability failure, so the response centers on restoration and continuity, not just secrecy.
Mistake to avoid: Designing protections for secrecy alone while ignoring data alteration and system downtime.
Reference: HHS Summary of the HIPAA Security Rule
45. Security Incident Response
Entities must identify and respond to suspected or known security incidents, mitigate their harmful effects to the extent possible, and document incidents and their outcomes. Procedures should also track access to ePHI through regular record review so incidents are detected rather than discovered by accident.
Example: A phished account triggers the incident procedure: access is cut, harmful effects are mitigated, and the event plus outcome are documented for review.
Mistake to avoid: Fixing a security incident quietly without documenting the event and its outcome.
Reference: HHS Summary of the HIPAA Security Rule
46. Required Versus Addressable Specifications
Every standard must be met, but some implementation specifications are required while others are addressable. Addressable does not mean optional: the entity decides whether the specification is reasonable and appropriate, adopts it if so, and otherwise implements a documented alternative achieving the same purpose.
Example: A small practice finds an addressable measure impractical, adopts a workable alternative, and documents why, which is compliant rather than noncompliant.
Mistake to avoid: Skipping addressable specifications as optional without adopting or documenting any alternative.
Reference: HHS Summary of the HIPAA Security Rule
47. Business Associate Agreements and Flow-Down
Before a business associate may create, receive, maintain, or transmit ePHI, a written agreement must document satisfactory assurances, obligate compliance with the Security Rule, require subcontractors to sign equivalent agreements, and require reporting of security incidents, including breaches of unsecured PHI.
Example: A practice signs the agreement before the billing service touches any data, because the safeguard must precede the sharing, not follow it.
Mistake to avoid: Letting a contractor begin work while the agreement is still in negotiation.
Reference: HHS Summary of the HIPAA Security Rule; HHS Summary of the HIPAA Privacy Rule
48. Documentation Retention and Periodic Evaluation
Policies, procedures, and required actions must be documented and retained for six years after the later of creation or last effective date, kept available to those implementing them, and updated when environmental or organizational changes affect ePHI security. Periodic technical and nontechnical evaluations verify the program still works.
Example: After adopting a new patient portal, the practice updates its security documentation and schedules a fresh evaluation, since the environment changed.
Mistake to avoid: Filing security policies away at go-live and never reviewing them as systems change.
Reference: HHS Summary of the HIPAA Security Rule
Clinical Operations and the EHR Workflow
49. Psychotherapy Notes Are Not Ordinary Chart Entries
Psychotherapy notes are a mental health professional's notes documenting or analyzing the contents of a private counseling session, kept separate from the rest of the medical record; they exclude medication prescription and monitoring, session start and stop times, treatment frequency, and summaries of diagnosis, symptoms, prognosis, or progress. They require the individual's written authorization for most uses and disclosures — even for payment and health care operations — with narrow exceptions such as the originating provider's own treatment, and they are excepted from the individual's right of access to the designated record set.
Example: A payer requests the visit documentation to process a claim; staff release the encounter record but not the psychotherapy notes, because payment is a purpose for which those notes still require the patient's authorization.
Mistake to avoid: Treating psychotherapy notes like any other progress note and releasing them with the routine chart.
Reference: HHS Summary of the HIPAA Privacy Rule
50. Test Results Reporting and Follow-Up
Recommended safe-EHR practices address test results reporting and follow-up as an organizational responsibility. The practice must define who reviews incoming results, how abnormal findings reach the responsible provider, and how patients are notified, so results never sit unowned in a queue.
Example: A practice assigns result review to named clinical staff with a backup, because follow-up without a named owner is a recognized safety gap.
Mistake to avoid: Leaving result follow-up to whichever staff member happens to notice the alert.
Reference: ONC Health IT Playbook: Electronic health records
51. Family Disclosures When the Patient Cannot Agree or Object
For disclosures to family, relatives, friends, or other persons the individual identifies as involved in care, informal agreement suffices — asking outright, or circumstances that clearly give the individual the opportunity to agree or object. Where the individual is incapacitated, in an emergency situation, or not available, the covered entity generally may still disclose information directly relevant to that person's involvement in care, if in the exercise of professional judgment the disclosure is determined to be in the individual's best interests.
Example: An unconscious patient's friend, identified in the record as involved in her care, asks about the discharge plan; because the patient cannot agree or object, the nurse applies professional judgment that sharing the discharge-relevant information is in the patient's best interest and limits it to what the friend needs for care.
Mistake to avoid: Refusing all communication with involved family or friends whenever the patient is unconscious, or sharing the full history when only care-relevant information is needed.
Reference: HHS Summary of the HIPAA Privacy Rule
52. PDMP Integration Into Prescribing Workflow
Prescription drug monitoring programs can be integrated with health IT so prescribers review a patient's controlled-substance history within the EHR rather than through a separate portal. Integration turns the review into a routine step of prescribing instead of an optional detour.
Example: Before renewing a controlled medication, the prescriber checks the integrated monitoring program during the same encounter, keeping review inside the workflow.
Mistake to avoid: Skipping monitoring review because the separate portal login feels like a detour.
Reference: ONC Health IT Playbook: Electronic health records
53. Portals Change Workflows, Not Just Access
Adding a patient portal is a new technology adoption on the EHR journey, so it should trigger workflow review. Practices must decide who triages incoming messages, how quickly responses go out, and how portal requests route to clinical versus administrative staff.
Example: A portal launch includes assigning message triage to trained staff, preventing patient messages from piling up in an unmonitored inbox.
Mistake to avoid: Launching a portal without staffing or triage rules for the messages it generates.
Reference: ONC Health IT Playbook: Electronic health records
54. Telehealth and Electronic Notice Delivery
Telehealth changes both care delivery and privacy practices. For electronic service delivery, a direct treatment provider satisfies notice distribution through an automatic and contemporaneous electronic response at the first encounter, rather than the personal delivery used for in-person visits.
Example: A patient's first telehealth visit triggers an automatic electronic privacy notice, replacing the paper handout used at in-person first encounters.
Mistake to avoid: Applying only in-person, paper notice practices to encounters delivered electronically through telehealth.
Reference: ONC Health IT Playbook: Electronic health records; HHS Summary of the HIPAA Privacy Rule
Revenue Cycle, Reporting, and Value-Based Care
55. Workers' Compensation Disclosures Without Authorization
Covered entities may disclose protected health information as authorized by, and to comply with, workers' compensation laws and other similar programs providing benefits for work-related injuries or illnesses. This is a permitted disclosure that needs no patient authorization, but it is bounded by what the workers' compensation law authorizes, so the release should match the program's request rather than exceed it.
Example: An employer's workers' compensation carrier requests documentation for a reported workplace back injury; the practice sends the injury-related encounter records under the state workers' compensation authorization, without waiting for a signed patient authorization.
Mistake to avoid: Delaying a lawful workers' compensation disclosure because no patient authorization is on file, or releasing unrelated history beyond what the program's authorization covers.
Reference: HHS Summary of the HIPAA Privacy Rule
56. Clearinghouses and Claims Processing
Health care clearinghouses convert nonstandard information they receive into standard format, or the reverse, and include billing services and switches. Because claims processing involves PHI on the provider's behalf, the clearinghouse functions as a business associate handling data under a written agreement.
Example: A practice sends claims through a clearinghouse that standardizes them for the payer, with a signed business associate agreement already in place.
Mistake to avoid: Exchanging identifiable claims data with a clearinghouse before any written agreement exists.
Reference: HHS Summary of the HIPAA Privacy Rule
57. Disclosing to Another Entity for Its Payment or Operations
Beyond its own treatment, payment, and operations, a covered entity may disclose protected health information for the payment activities of another covered entity or of any health care provider, and for another covered entity's health care operations when those are limited to quality or competency assurance activities or fraud and abuse detection — but only if both entities have or had a relationship with the individual and the protected health information pertains to that relationship.
Example: The health plan covering a practice's patient requests encounter records to adjudicate the claim; the practice may disclose under the plan's payment activity because both hold a relationship with the patient and the records pertain to it, while a data firm with no treatment or coverage relationship asking for the same charts cannot rely on this provision.
Mistake to avoid: Treating any payer or provider request as a permitted payment disclosure without checking the relationship condition and the purpose of the request.
Reference: HHS Summary of the HIPAA Privacy Rule
58. Value-Based Care and EHR Data Quality
Value-based care ties payment to the value of care rather than volume alone, including through alternative payment models. Because performance measurement depends on EHR data, the accuracy of structured entry becomes a financial and clinical concern, not merely a billing convenience.
Example: A practice joining an alternative payment model audits its structured data entry, because measured outcomes now drive its revenue directly.
Mistake to avoid: Assuming EHR data quality matters only when submitting claims for individual encounters.
Reference: ONC Health IT Playbook: Electronic health records
59. MIPS and Promoting Interoperability
The Quality Payment Program includes the Merit-based Incentive Payment System, whose Promoting Interoperability performance category measures EHR use. This is Medicare program policy, distinct from ONC certification of the product itself, so a certified system does not automatically satisfy program scoring.
Example: A clinician in MIPS tracks the Promoting Interoperability category separately, knowing certification of the software alone does not complete program requirements.
Mistake to avoid: Conflating holding a certified EHR with meeting Medicare program performance requirements.
Reference: ONC Health IT Playbook: Electronic health records
60. Registries, Population Health, and Reporting
Population health management tools and patient registries query structured EHR data to identify groups needing care, such as patients due for follow-up, and practices can also support public health data reporting. Structured entry during routine visits is what makes these later queries possible.
Example: A registry flags patients overdue for follow-up because past visits were entered as structured data, not free-text narrative notes.
Mistake to avoid: Relying on free-text notes and expecting registry queries to find the patients.
Reference: ONC Health IT Playbook: Electronic health records
References and further reading
Source links checked on Oct 2, 2026.