Data Strategy Briefing — April 5, 2021
ONC’s Cures Act information blocking rules entered enforcement on 5 April 2021, obligating U.S. healthcare providers, HIEs, and certified developers to operationalise exceptions governance, FHIR API delivery, and patient access transparency under OIG oversight.
Executive briefing: The Office of the National Coordinator for Health IT’s (ONC) Cures Act information blocking provisions became enforceable on 5 April 2021 after a one-year pandemic deferral. Certified health IT developers, health information networks/exchanges, and healthcare providers must now furnish timely access, exchange, and use of electronic health information (EHI) unless one of eight regulatory exceptions applies. Compliance moves beyond policy statements: programmes must demonstrate role-based decision governance, standardised technical enablement, and auditable evidence as the HHS Office of Inspector General (OIG) ramps penalty authority of up to $1 million per violation for developers and HIN/HIEs.
Regulatory context and timeline
The 21st Century Cures Act directed ONC to curb practices that unreasonably impede interoperability. The Final Rule—published March 9 2020—aligned the go-live date with April 5 2021, narrowed the initial EHI scope to the United States Core Data for Interoperability (USCDI), and outlined staged compliance, including future expansion to the full designated record set in October 2022. Providers remain subject to information blocking investigations by OIG and potential disincentives from CMS rulemaking, while developers risk certification revocation in addition to civil monetary penalties. Programmes must therefore map obligations against ONC FAQs, the information blocking regulations in 45 CFR Part 171, and complementary CMS interoperability conditions of participation.
Governance architecture
- Exception stewardship. Organisations must maintain a single taxonomy for the eight exceptions—preventing harm, privacy, security, infeasibility, health IT performance, content and manner, fees, and licensing—with ownership assigned to clinical, privacy, security, and commercial leads. Governing bodies should ratify decision matrices that operationalise regulatory text, define thresholds for invoking exceptions, and prescribe escalation to compliance counsel.
- Policy harmonisation. Existing HIPAA right-of-access, state information-blocking laws, and contractual obligations with EHR vendors or HIE partners need consolidation to prevent conflicting guidance to frontline teams. Steering committees should review consent models, data sharing agreements, and de-identification policies to eliminate outdated prohibitions.
- Evidence management. ONC expects contemporaneous documentation explaining why an exception applied, who approved it, and what alternatives were considered. Governance teams should implement case management tooling to store policies, meeting notes, screenshots of system outages, and audit logs that demonstrate due diligence.
Implementation workstreams
- EHI inventory and classification. Compliance begins with a catalogue of systems holding EHI—from certified EHR modules to imaging archives, revenue cycle platforms, and third-party registries. Data stewards must map whether each system can export structured data, provide FHIR API endpoints, or supply view/download/transmit functionality in alignment with ONC certification criteria (§170.315).
- Request intake operations. Providers and developers should offer omnichannel intake (portal requests, email, phone, and written forms) with service-level agreements for acknowledging, fulfilling, or denying requests. Automated routing to privacy, HIM, and developer support teams ensures timely review. Denial letters must cite specific exceptions and supply alternative access pathways where feasible.
- Third-party application onboarding. The Cures Act APIs require secure registration, transparent terms of service, and OAuth 2.0/OpenID Connect authentication. Developer programmes must publish API documentation, rate limit policies, and security testing expectations while avoiding discriminatory practices that could constitute information blocking. App registration queues should include privacy reviews and attestations related to secondary data use.
- Complaint handling. OIG, ONC, and CMS accept complaints through portals and emails. Organisations must monitor submissions, coordinate responses across legal, compliance, and technical teams, and log remedial actions. Complaint metrics—including time to resolution and repeat root causes—feed governance dashboards and board reporting.
Technology enablement
- FHIR release management. Certified developers must support FHIR Release 4 APIs for the USCDI dataset. Product teams should embed regression testing for the bulk data export (Flat FHIR) standard, SMART App Launch profiles, and the US Core Implementation Guides. Change management plans should explain downtime windows and communicate with connected third parties.
- Security controls. Security exceptions only apply when practices are tailored to specific risks. Identity and access management programmes must enforce multifactor authentication, API throttling, and behaviour analytics to detect misuse. Documenting control rationales—such as rejecting an application due to lack of security assurances—supports exception defensibility.
- Monitoring and analytics. Telemetry from API gateways, EHR audit logs, and request management systems provides leading indicators of bottlenecks. Dashboards should track fulfilment timelines, exception invocation counts by type, and comparative performance across departments. Trigger thresholds can automatically alert compliance leaders when SLAs slip.
Stakeholder engagement and training
Frontline clinicians, release-of-information staff, developers, and help-desk agents make day-to-day decisions that can constitute information blocking. Programmes should deliver role-based training anchored in ONC scenarios, provide quick-reference guides, and incorporate tabletop exercises to rehearse complex cases (e.g., balancing adolescent privacy with parental access). Outreach to patient advocacy groups, regional HIEs, and digital health developers strengthens trust and identifies user experience barriers to accessing EHI.
Metrics and oversight
- Key performance indicators. Track average fulfilment time, denial rates by exception, volume of third-party app registrations, API uptime, and complaint trends. Comparing metrics before and after April 2021 enforcement clarifies whether processes have matured.
- Board and audit reporting. Quarterly updates should summarise compliance posture, highlight adverse events (such as OIG investigations), and document remediation progress. Internal audit functions can perform readiness reviews aligned to 45 CFR Part 171, testing sampled requests, exception documentation, and API functionality.
- Regulatory watch. Monitor ONC rulemaking around information blocking disincentives for providers, CMS Condition of Participation updates, TEFCA (Trusted Exchange Framework and Common Agreement) roll-out, and state privacy developments that may expand or conflict with federal expectations.
Forward-looking considerations
The compliance horizon extends past the April 2021 go-live. On October 6 2022 the definition of EHI broadened to the full designated record set, requiring organisations to remove segmentation that prevents access to clinical notes, imaging, lab results, and billing records. OIG civil monetary penalties became active June 2023, intensifying enforcement risk. TEFCA participation will add obligations to support Qualified Health Information Networks (QHINs), while CMS continues to mandate payer-to-payer and patient access APIs. Programmes should maintain multi-year roadmaps covering data governance, API scalability, and patient engagement to stay ahead of evolving policy.
Action checklist
- Validate inventory of EHI systems and ensure USCDI coverage through certified API endpoints.
- Review exception documentation processes via mock investigations, ensuring evidence sufficiency.
- Refresh patient- and developer-facing materials to explain access rights, security expectations, and complaint pathways.
- Implement dashboards connecting request intake, API metrics, and complaint data to compliance KPIs.
- Prepare for future expansions—designated record set scope, TEFCA participation, and OIG audits—through iterative capability assessments.
Zeph Tech supports Cures Act compliance by mapping exception governance, orchestrating FHIR deployment readiness, and building analytics that prove timely, equitable information sharing.
Continue in the Data Strategy pillar
Return to the hub for curated research and deep-dive guides.
Latest guides
-
Data Interoperability Engineering Guide — Zeph Tech
Engineer interoperable data exchanges that satisfy the EU Data Act, Data Governance Act, European Interoperability Framework, and ISO/IEC 19941 portability requirements.
-
Data Stewardship Operating Model Guide — Zeph Tech
Establish accountable data stewardship programmes that meet U.S. Evidence Act mandates, Canada’s Directive on Service and Digital, and OECD data governance principles while…
-
Data Strategy Operating Model Guide — Zeph Tech
Design a data strategy operating model that satisfies the EU Data Act, EU Data Governance Act, U.S. Evidence Act, and Singapore Digital Government policies with measurable…