HITECH Act — Electronic Health Records & Health IT Adoption

The Health Information Technology for Economic and Clinical Health (HITECH) Act — enacted as Title XIII of the American Recovery and Reinvestment Act of 2009 and codified at 42 U.S.C. §§ 17901–17953 — is the federal law that drove the near-universal adoption of electronic health records (EHRs) across U.S. hospitals and physician practices. Before HITECH, roughly 9% of hospitals and 17% of physicians used any form of EHR. Congress appropriated $27 billion in Medicare and Medicaid incentive payments to providers who demonstrated "meaningful use" of certified EHR technology — by 2015, 96% of non-federal acute care hospitals and 87% of office-based physicians had adopted certified EHRs, one of the fastest technology adoption curves in U.S. healthcare history. HITECH also fundamentally rewrote the HIPAA enforcement landscape: it extended HIPAA's Privacy and Security Rules directly to business associates (cloud vendors, billing companies, IT providers) for the first time, created a tiered civil penalty structure with statutory per-category annual caps that have grown with inflation to roughly $2.19 million as of January 28, 2026 (OCR has voluntarily limited Tiers 1–3 to $25K/$100K/$250K under a 2019 enforcement-discretion notice), established mandatory breach notification requirements, and required HHS to conduct periodic audits of covered entities. The law established the Office of the National Coordinator for Health Information Technology (ONC) in statute, created a Health IT Policy Committee and Standards Committee, and directed HHS to develop standards for interoperability — work that culminated in the 21st Century Cures Act interoperability and information blocking rules finalized in 2020.

Current Law (2026)

Legal Authority

• 42 U.S.C. § 17901 — Congressional findings: recognition that EHR adoption improves quality, reduces costs, and requires federal investment to overcome adoption barriers
• 42 U.S.C. § 17902 — Office of the National Coordinator for Health Information Technology (ONC) established in statute; strategic plan requirements; HIT Policy Committee; HIT Standards Committee
• 42 U.S.C. § 17921 — Definitions applicable to HITECH privacy and security provisions; "business associate" definition expanded to include subcontractors
• 42 U.S.C. § 17931 — Application and enforcement of HIPAA Security Rule to business associates; business associates directly liable for Security Rule compliance, not just by contract
• 42 U.S.C. § 17932 — Notification in the case of breach (Breach Notification Rule): covered entities must notify affected individuals without unreasonable delay within 60 days; media notification for 500+ individual breaches; HHS notification
• 42 U.S.C. § 17934 — Application of Privacy Rule to business associates; business associates directly liable for Privacy Rule violations; subcontractors treated as business associates of business associates
• 42 U.S.C. § 17935 — Conditions on certain contacts as part of health care operations; restricts sale of PHI and use of PHI for marketing without individual authorization; "minimum necessary" standard applied to disclosures to business associates
• 42 U.S.C. § 17937 — Temporary breach notification requirement for vendors of personal health records (extends breach notification to PHR vendors not otherwise covered by HIPAA)
• 42 U.S.C. § 17938 — Notification by vendors of personal health records following breach (FTC enforcement of notification requirements for non-HIPAA-covered PHR vendors)
• 42 U.S.C. § 17942 — Accounting of certain protected health information disclosures required; individuals have right to accounting of EHR-facilitated disclosures
• 42 U.S.C. § 17951 — Guidance on implementation (HHS/ONC guidance, model business associate agreements)
• 42 U.S.C. § 17953 — Studies, reports, and demonstration projects (outcomes research, privacy impact of EHR adoption, interoperability measurement)
• 42 U.S.C. §§ 300jj through 300jj-38 — Health information technology provisions: Medicare and Medicaid EHR incentive programs; meaningful use criteria; ONC health IT certification; Regional Extension Centers; health IT workforce development programs

Key Numbers

• $27 billion: Total HITECH EHR incentive program appropriation over the program's lifetime
• 96% / 87%: Share of non-federal acute care hospitals / office-based physicians using certified EHRs by 2015 (up from 9% / 17% pre-HITECH)
• $44,000 / $63,750: Maximum Medicare / Medicaid incentive payments per eligible professional over the program's payment period
• $2M+: Approximate maximum per-hospital Medicare EHR incentive (formula based on discharges and Medicare/Medicaid share)
• ~$2.19 million (2026 inflation-adjusted): Statutory maximum civil monetary penalty per violation category per calendar year under HITECH's tiered penalty structure (OCR enforcement caps Tiers 1–3 at $25K/$100K/$250K under its 2019 enforcement-discretion notice)
• 500: Threshold for "large breach" requiring media notification and immediate HHS reporting (vs. annual log for sub-500 breaches)
• 60 days: Maximum time from discovery to individual notification of a breach of unsecured PHI
• 45 CFR Part 170: ONC Health IT Certification Program regulations; sets technical standards EHR systems must meet to be certified

How It Works

HITECH's primary lever was the Meaningful Use incentive program: CMS created a three-stage framework where providers received payments for demonstrating progressively more sophisticated use of certified EHR technology — Stage 1 (2011–2012) focused on data capture, Stage 2 (2014) required advanced clinical processes, Stage 3 (2015+) targeted improved outcomes. Providers who failed to adopt EHRs after the incentive period faced Medicare payment reductions of 1–3%, converting the carrot into a stick. The program was folded into the Merit-Based Incentive Payment System (MIPS) under MACRA (2015), where it became the "Promoting Interoperability" performance category worth 25% of a physician's MIPS score. HITECH also permanently changed healthcare contracting: before 2009, HIPAA obligations ran only from covered entities to business associates by contract. HITECH made business associates — cloud providers, billing companies, IT vendors — directly liable under the Privacy and Security Rules at 42 U.S.C. §§ 17931 and 17934, and extended that liability to subcontractors of business associates. Every entity that touches PHI in a healthcare supply chain now has direct federal regulatory exposure, and HHS OCR has brought major enforcement actions directly against EHR vendors and billing companies.

ONC-certified EHR technology is required to qualify for incentive payments and avoid MIPS payment adjustments — a requirement that forced EHR vendors to meet federal technical standards for data representation, clinical decision support, and interoperability. The 2015 Edition Cures Update certification criteria require certified EHR vendors to support FHIR (Fast Healthcare Interoperability Resources) APIs enabling patients and third-party applications to access clinical data without special effort. The 21st Century Cures Act (2016) extended HITECH's interoperability mission by adding 42 U.S.C. § 300jj-52, which prohibits information blocking — practices by health IT developers, health information networks, or providers that interfere with access to, exchange of, or use of electronic health information. ONC's 2020 information blocking rule identified eight narrow exceptions (privacy, security, preventing harm); everything else is presumptively a violation. The OIG has civil monetary penalty authority of up to $1 million per violation for health IT developers, targeting in particular EHR vendors' historical practice of charging high fees for data export or interoperability connections.

Implementing Regulations

The CMS regulations implementing the Medicare and Medicaid EHR incentive programs created by HITECH live at 42 CFR Part 495 — Standards for the Electronic Health Record Technology Incentive Program. Part 495 defines exactly who qualifies for incentive payments, how payments are calculated, and what "meaningful use" of certified EHR technology requires. It is organized across four subparts:

Subpart A — General Provisions (§§ 495.2–495.24):

• § 495.2 — Basis and purpose: implements section 1848(o) of the Social Security Act (Medicare Part B physician incentives) and section 1886(n) (Medicare hospital incentives), and section 1903(a)(3)(F) (Medicaid incentives); the three payment streams that funded the $27 billion EHR adoption push
• § 495.20 — Meaningful use objectives and measures before 2015 (Stage 1 and Stage 2 criteria): required eligible professionals and hospitals to demonstrate use of certified EHR technology for clinical processes — recording demographics, maintaining problem lists, transmitting prescriptions electronically, and exchanging clinical summaries; used a pass/fail threshold structure (e.g., ≥ 60% of patients with clinical notes recorded electronically)
• § 495.22 — Meaningful use objectives and measures for 2015–2018: consolidated and revised the Stage 2 objectives under the "modified Stage 2" framework; reduced the number of required objectives and introduced a threshold-based scoring approach tied to the MIPS Promoting Interoperability category
• § 495.24 — Stage 3 meaningful use objectives for 2019 and subsequent years: the current performance framework for physicians still subject to MIPS Promoting Interoperability; emphasizes health information exchange, patient electronic access (FHIR-based APIs), electronic prescribing of controlled substances, and clinical decision support

Subpart B — Medicare Program Requirements (§§ 495.100–495.110):

• § 495.100 — Definitions: "eligible professional" (EP) — physician, dentist, certified nurse midwife, nurse practitioner, physician assistant in a federally qualified health center; "meaningful EHR user" — met all applicable objectives for the period
• § 495.102 — Incentive payments to EPs: base payment of $15,000 in the first year, declining to $12,000, $8,000, $4,000, $2,000 in subsequent years; the maximum $44,000 over 5 years was available only to EPs who began in 2011 or 2012; Medicaid-heavy practices received a 10% bonus
• § 495.104 — Incentive payments to eligible hospitals: calculated on a formula weighting Medicare/Medicaid patient days against base amounts plus discharge additions; per-hospital maximum exceeded $2 million for large academic medical centers
• § 495.110 — Preclusion on review: the Secretary's determination of whether a provider meets meaningful use criteria is not subject to administrative or judicial review — EPs and hospitals could appeal factual determinations but not CMS's substantive meaningful use criteria

Subpart D — Medicaid Program Requirements (§§ 495.300–495.372): The Medicaid EHR incentive program operated on a parallel track with higher maximum payments ($63,750 per eligible professional over 6 years) and a broader definition of eligible providers (including pediatricians, family practitioners, and nurse practitioners). States administered the Medicaid program under CMS oversight, with CMS reimbursing 90% of incentive payments. This subpart specifies the patient volume thresholds required for Medicaid EHR eligibility (30% Medicaid patient volume for most providers, 20% for pediatricians) and the state plan amendment process.

The EHR incentive programs as originally structured concluded around 2021 — the final meaningful use payment adjustments were assessed in 2022 and 2023. The regulatory framework in Part 495 now primarily governs legacy payment adjustments, ongoing Promoting Interoperability requirements under MIPS, and the Medicaid incentive program's wind-down. The substantive technology standards that define what certified EHR technology must do have migrated to ONC's 45 CFR Part 170 (certification criteria) and the information blocking rules at 45 CFR Part 171.

The ONC regulations implementing the technical standards for certified EHR technology live at 45 CFR Part 170 — Health Information Technology Standards, Implementation Specifications, and Certification Criteria (45 sections). This is where the actual technical fabric of U.S. health data interoperability is defined. Key provisions:

• § 170.202 — Transport standards: the Secretary adopts the Direct Project (ONC Applicability Statement for Secure Health Transport) as the standard for exchanging clinical documents securely between providers via encrypted email-like messaging; this is the infrastructure behind "send your records to my new doctor" functionality in most EHR systems
• § 170.205 — Content exchange standards: the Secretary adopts HL7 CDA (Clinical Document Architecture) and FHIR (Fast Healthcare Interoperability Resources) as the standards for structuring and exchanging clinical documents; the C-CDA (Consolidated Clinical Document Architecture) is the specific document format required for transitions of care and patient summaries — structured XML that can be parsed by any certified EHR
• § 170.207 — Vocabulary standards: certified EHR technology must use specific standard code sets to represent clinical concepts — SNOMED-CT for clinical findings and diagnoses, ICD-10-CM for billing diagnoses, CPT for procedure codes, LOINC for laboratory results and vital signs, RxNorm for medications, CVX for vaccine codes; these vocabulary standards make it possible for two different EHR systems to exchange data that means the same thing in both
• § 170.210 — Security standards: EHRs must implement encryption and authentication standards to protect health information created, maintained, and exchanged electronically; specific standards include AES-128 encryption minimums and user authentication requirements
• § 170.213 — United States Core Data for Interoperability (USCDI): the Secretary adopts a minimum required data set — patient demographics, problems, medications, allergies, clinical notes, lab results, vital signs, smoking status, and other specified elements — that every certified EHR must be capable of representing and exchanging; USCDI v1 (2020) established the baseline; USCDI v3 and v4 have added data classes including pediatric vital signs, health insurance information, and sexual orientation/gender identity
• § 170.215 — API standards: the Secretary adopts HL7 FHIR Release 4 (Fast Healthcare Interoperability Resources, Version 4) and the SMART App Launch Framework as the required standards for application programming interfaces; this means every certified EHR must expose patient data through FHIR APIs that third-party apps (Apple Health, Epic MyChart, etc.) can access on the patient's behalf using OAuth 2.0 authorization — the regulatory foundation of the patient data access revolution
• § 170.315 — ONC certification criteria: the 2015 Edition Cures Update certification criteria specify dozens of specific capabilities certified EHR modules must demonstrate — clinical decision support, drug-drug interaction checking, medication list management, patient-specific education resources, view/download/transmit for patients, transition of care, and FHIR API support; EHR products must be tested by an ONC-Authorized Testing Laboratory (ONC-ATL) and certified by an ONC-Authorized Certification Body (ONC-ACB) against these criteria
• § 170.401 — Information blocking condition of certification: health IT developers must not take any action that constitutes information blocking as a condition of maintaining their ONC certification; this provision makes information blocking not just a civil penalty risk but a certification ground — a company that blocks data access could lose the certification that makes it eligible to participate in Medicare/Medicaid EHR programs
• § 170.402 — Assurances condition: health IT developers must provide satisfactory assurances to ONC that they will not engage in information blocking; assurances must be submitted at certification and updated as required
• § 170.403 — Anti-gag clause (Communications condition): health IT developers may NOT prohibit or restrict any communication about (1) the usability of their health IT; (2) the interoperability of their health IT; (3) the security of their health IT; (4) the user's experience with the health IT; or (5) the business practices of health IT developers related to exchange of health information — this provision directly targets EHR contracts that previously contained clauses prohibiting providers from publicly criticizing the EHR's design or functionality

Recent rulemakings: ONC's 21st Century Cures Act Final Rule (85 FR 25642, May 2020) implemented the information blocking prohibition, required FHIR API support, and adopted USCDI v1. ONC's HTI-1 Final Rule (89 FR 1192, January 2024) adopted USCDI v3 and updated certification criteria for AI and clinical decision support transparency.

Recent rulemakings: 83 FR 41711 (August 2018) transitioned the Medicare EHR incentive program into the MIPS Promoting Interoperability performance category under MACRA, restructuring objectives and scoring. 75 FR 44565 (July 2010) was the foundational rule establishing Stage 1 meaningful use criteria — the original 2009 rule that defined what EHR adoption would mean in practice.

ONC's national health information exchange framework lives at 45 CFR Part 172 — Trusted Exchange Framework and Common Agreement (TEFCA) (33 sections — the regulatory framework establishing the network of networks for nationwide health information exchange, enabling any authorized health system, payer, health IT developer, or patient to exchange electronic health information with any other authorized participant regardless of which EHR vendor they use):

• § 172.100 — Basis and purpose: Part 172 implements 42 U.S.C. § 300jj-17 (added by the 21st Century Cures Act), which directed ONC to publish a Trusted Exchange Framework and Common Agreement; the Recognized Coordinating Entity (RCE) — currently Sequoia Project — administers the TEFCA on ONC's behalf, including designating QHINs and enforcing the Common Agreement
• § 172.101 — Applicability: Part 172 applies to Qualified Health Information Networks (QHINs) — entities that meet TEFCA designation requirements and agree to the Common Agreement; participation in TEFCA/QHIN network is voluntary for health systems, but once a QHIN is designated, it must connect all its Participants to the network and follow TEFCA's technical and governance rules
• § 172.102 — Key definitions: QHIN (Qualified Health Information Network) — a large-scale health information network that connects individual healthcare organizations and enables exchange among them; Participant — a health organization that connects to and exchanges information through a QHIN (hospitals, physician practices, payers, labs); Subparticipant — an entity that connects to a Participant rather than directly to a QHIN; Individual Access Services (IAS) — TEFCA's framework for allowing patients to access and direct their own health data through third-party apps
• § 172.201 — QHIN designation requirements: a QHIN must be a U.S. entity (no majority-foreign control); demonstrate technical capability to exchange health information using nationally recognized standards (FHIR, IHE profiles); maintain a governance structure with oversight protections; agree to the Common Agreement's terms; demonstrate operational readiness including scalability and security; and successfully complete ONC's onboarding process; as of 2026, designated QHINs include eHealth Exchange, Carequality, CommonWell, Kno2, and several others
• § 172.202 — Individual Access Services: QHINs that offer IAS must support patient-directed exchange — allowing patients to authorize third-party apps (health and fitness apps, insurance companies, personal health record apps) to access their clinical records held by any IAS-participating provider; the technical implementation relies on SMART on FHIR authorization; the TEFCA IAS framework is designed to complement the information blocking rules' "patient access" exception and the existing 45 CFR Part 164 (HIPAA) patient access requirements
• § 172.300–172.303 — QHIN application, review, and approval: the RCE receives applications, verifies requirements are met, conducts onboarding testing, and issues Designation; the RCE has authority to deny applications if the entity fails to demonstrate capability or compliance; ONC retains oversight authority and can override RCE decisions
• § 172.400 — Common Agreement compliance: all QHINs must execute the Common Agreement with the RCE, which establishes: technical exchange standards (HL7 FHIR R4); privacy and security baseline requirements (aligned with HIPAA); governance requirements; dispute resolution procedures; and fee structures for exchange; the Common Agreement creates a contractual network in which any QHIN can exchange with any other QHIN

TEFCA represents the federal government's attempt to create a national health information exchange network through a standards-based, voluntary approach rather than through mandated federal infrastructure. The framework explicitly preserves the existing private network ecosystem (Carequality, CommonWell, eHealth Exchange) while creating a common "on-ramp" that any of those networks can use to exchange with the others. The potential population impact is enormous: all 46 million Medicare FFS beneficiaries and 90+ million Medicare Advantage and Medicaid enrollees could have their records instantly accessible to any treating provider and to themselves through TEFCA-enabled apps. The TEFCA network began initial operations in late 2022 and expanded rapidly in 2023–2024 as major health systems and EHR vendors completed onboarding. No major Federal Register amendment to Part 172 yet — the regulation is relatively new (finalized in 2022).

The information blocking prohibition and its enforcement rules live at 45 CFR Part 171 — Information Blocking (23 sections implemented by ONC and OIG). Key provisions:

• § 171.100–171.103 — Scope and definition: Part 171 applies to all three categories of "actors" — health care providers, health IT developers of certified health IT, and health information exchanges/networks (HIEs and HINs); "information blocking" means any practice that, unless required by law or covered by an exception in Part 171, is likely to interfere with, prevent, or materially discourage the access, exchange, or use of electronic health information (EHI); the burden of proving conduct is covered by an exception falls on the actor
• § 171.102 — Definitions: "Electronic health information" (EHI) means electronic protected health information as defined under HIPAA; "access" means the ability or means necessary to make EHI available for exchange or use; the statute prohibits not just affirmative blocking but any practice that "materially discourages" information exchange — a deliberately broad definition intended to capture subtle barriers
• Subpart B — Exceptions for not fulfilling requests (8 exceptions): when an actor is not obligated to fulfill a request to access, exchange, or use EHI, information blocking doesn't occur; exceptions include: (1) Preventing Harm — declining to provide EHI when a licensed practitioner has documented concern about harm to a patient or another person; (2) Privacy — declining when consistent with HIPAA or other applicable law that protects patient privacy; (3) Security — declining when necessary to protect the security and integrity of an EHR system; (4) Infeasibility — when technically or legally infeasible to fulfill the request; actors bear the burden of documenting that these exceptions apply
• Subpart C — Exceptions for manner of fulfilling requests (3 exceptions): how, when, and at what cost an actor fulfills requests; the Fees exception allows charging reasonable fees for EHI exchange — but fees that are excessive, discriminatory, or designed to discourage access are not covered; the Licensing exception covers reasonable intellectual property licensing terms; the FTC has enforcement interest where fees appear designed to exclude competitor applications
• § 171.1001 — Disincentives for health care providers (Subpart J): CMS may apply specific disincentives to health care providers found by OIG to have committed information blocking: (a) hospitals may be found not to be "meaningful electronic health record users" — affecting MIPS payment adjustments; (b) eligible professionals may be similarly penalized; (c) providers seeking ACO participation may be denied; these disincentives are significant — a hospital found to be blocking could lose its Promoting Interoperability MIPS category points and face a payment reduction of up to 3% of its Medicare reimbursement
• Health IT developers and HIEs: while providers face CMS disincentives, health IT developers of certified health IT face OIG civil monetary penalty authority up to $1 million per violation under 42 U.S.C. § 300jj-52(b)(2)(B); OIG has begun enforcement actions and has published detailed guidance on investigation procedures; health information exchanges face similar penalty authority under separate statutory provisions

Part 171 is the enforcement companion to the 45 CFR Part 170 certification conditions — the information blocking prohibition is what has teeth against EHR vendors' historical practices of charging $50,000+ "integration fees" for basic data interoperability, contractual gag clauses against criticizing EHR usability, and technical barriers that required proprietary integrations. Recent rulemakings: 88 FR 23746 (April 2023) — expanded EHI definition to cover the full scope of ePHI rather than only USCDI data elements; 88 FR 42820 (July 2023) — CMS disincentives final rule establishing the specific payment adjustments for provider information blocking.

The FTC's parallel health data breach framework lives at 16 CFR Part 318 — Health Breach Notification Rule: the breach notification requirement for entities that handle personal health records but are not covered by HIPAA — health apps, fitness trackers, period tracking apps, consumer health platforms, and other direct-to-consumer health technology companies that collect health data from individuals but have no business relationship with healthcare providers or health plans. Key provisions:

• § 318.1 — Scope: applies to "vendors of personal health records" (companies that offer or maintain PHRs directly to consumers), "PHR related entities" (companies that offer products or services through a PHR vendor's platform), and their "third party service providers"; HIPAA covered entities and their business associates are explicitly excluded — they are covered by HHS's HIPAA Breach Notification Rule (45 CFR Parts 160/164), not this rule; a health app like a fitness tracker that does not transmit data to a covered entity's systems falls under FTC Part 318
• § 318.3 — Breach notification requirement: upon discovery of a "breach of security" (unauthorized acquisition of unsecured PHR identifiable health information), a vendor must notify (1) affected individuals, (2) the FTC (if 500 or more individuals are affected), and (3) prominent media outlets in each state where 500 or more state residents are affected; third-party service providers must notify their PHR vendor/PHR related entity clients, who then notify individuals
• § 318.4 — Timeliness: all notifications must be sent within 60 calendar days of discovering the breach; law enforcement may request delay of up to 60 additional days if notification would impede a criminal investigation; the 60-day clock begins at discovery, not when the breach occurred
• § 318.6 — Content of notice: notifications must be in plain language and include: description of what happened; type of PHR information involved; steps the individual can take to protect themselves; steps the vendor is taking to investigate and mitigate; contact information for the vendor
• § 318.7 — Enforcement: violations are treated as FTC Act Section 18 rule violations — subject to civil penalties up to $51,744 per violation per day (as inflation-adjusted); the FTC may pursue enforcement in federal district court or through administrative proceedings

The FTC's Health Breach Notification Rule fills the HIPAA gap — as consumer health apps proliferated after HITECH (2009), it became clear that large repositories of sensitive health data were accumulating outside HIPAA's coverage. The FTC significantly updated the rule in 2024 (89 FR 18071, March 2024), expanding the definition of "breach of security" to include unauthorized disclosure of PHR data to third parties (including disclosure through deceptive data practices), clarifying that health apps tracking reproductive health, mental health, and substance use are covered, and strengthening the notice requirements. The 2024 update reflected FTC's concern that mobile health apps collecting sensitive health data were sharing or selling that data without meaningful disclosure — a practice the FTC characterized as a "breach of security" under the expanded rule.

How It Affects You

If you're a healthcare provider (physician, hospital, clinic): Your EHR system must be ONC-certified to avoid MIPS Promoting Interoperability payment adjustments. You are required to share patient health data through standardized APIs — patients can now connect approved third-party apps to their health records at your practice without your active assistance. Your business associate agreements must specify that your vendors are directly HIPAA-liable. If you experience a breach of 500 or more patients' PHI, you must notify HHS and local media within 60 days — not just the patients.

If you work in health IT, EHR development, or healthcare cloud services: You are a business associate or subcontractor with direct HIPAA compliance obligations regardless of what your contract says. ONC certification is required to participate in the federally-driven EHR market. Information blocking rules prohibit charging excessive fees, creating technical barriers, or delaying data access for patients and other providers. HHS OCR has brought enforcement actions against EHR vendors; OIG now has penalty authority up to $1 million per violation specifically for health IT developers.

If you're a patient: HITECH gives you the right to receive your electronic health records in electronic format within 30 days of requesting them, with fees limited to the labor cost of producing the records. Your provider cannot charge you $100 for a CD when your records are electronic. The information blocking rules and FHIR API requirements mean you can connect your Apple Health, CommonHealth, or other health app to your provider's EHR and pull your own records without the provider's intervention — a right that took more than a decade of policy work to make practical.

If you're a health plan administrator or employer sponsoring a self-insured plan: Health plans are covered entities under HIPAA and therefore subject to HITECH's enhanced enforcement, business associate rules, and breach notification requirements. If your third-party administrator, pharmacy benefit manager, or stop-loss carrier experiences a breach of your members' PHI, they have direct HIPAA liability — but you may also have notification and remediation obligations. Your business associate agreements must reflect HITECH's requirements.

State Variations

HITECH establishes federal floors; states may impose stricter requirements:

• California (CMIA — Confidentiality of Medical Information Act) imposes stricter restrictions on disclosure and private rights of action not available under HIPAA
• Texas, New York, and other states have separate breach notification laws with different timing, scope, and covered entity definitions than federal HITECH requirements
• State medical board regulations sometimes impose EHR retention and access requirements beyond federal minimums
• HITECH explicitly does not preempt more protective state privacy laws (42 U.S.C. § 17951)

Pending Legislation (119th Congress)

• HIPAA modernization proposals: Several bills have proposed updating the HIPAA/HITECH framework for mobile health apps, wearables, and consumer health technology that falls outside the covered entity structure — including direct-to-consumer genetic testing (23andMe, Ancestry) and wellness apps that handle sensitive health data without HIPAA coverage
• Information blocking enforcement: Congressional pressure for OIG to accelerate enforcement of information blocking rules; EHR vendor data-sharing practices continue to generate complaints
• AI in healthcare: Proposals to extend HITECH/HIPAA frameworks to AI-generated clinical decision support tools and secondary uses of EHR data for model training

Recent Developments

The 2020 interoperability and information blocking rules marked HITECH's most consequential evolution since the original 2009 statute. ONC's rules requiring FHIR-based APIs and prohibiting information blocking effectively mandated that EHR vendors open their data to third-party applications — reversing a decade of vendor practices that had kept patient data locked in proprietary systems. The rules came into full effect in 2022–2023, and the market for patient-facing health apps accessing EHR data through standardized APIs has grown substantially.

HHS OCR HIPAA enforcement reached record levels in 2023–2024, with settlements and civil monetary penalties totaling over $100 million. Notably, OCR has pursued business associates directly — including a $4.75 million settlement with CHSPSC LLC (a shared services organization for Community Health Systems), establishing that large healthcare service companies face the same enforcement exposure as the hospitals they serve. The expansion of remote work and cloud migration during and after COVID-19 dramatically increased the volume of business associate relationships requiring HIPAA compliance review.

The Trump administration's DOGE-driven HHS restructuring in 2025 raised questions about ONC's capacity. ONC was one of several HHS components that experienced workforce reductions; the pace of certification criteria updates and interoperability guidance slowed. The 21st Century Cures Act FHIR API requirements remain in effect, but industry observers noted reduced ONC engagement with implementation challenges.