Healthcare has long struggled with one fundamental problem: patients rarely have easy, reliable access to their own medical records. Appointment histories, lab results, medication lists, and claims data often sit locked inside hospital systems and insurance portals that do not communicate with one another. The Patient Access API was designed specifically to address this gap. By establishing a standardized, secure method for sharing health data directly with patients and their chosen applications, this technology is reshaping how individuals interact with their own health information.
What Is a Patient Access API?
An API, or Application Programming Interface, is a communication layer that allows different software systems to exchange data in a structured, predictable way. A Patient Access API applies this concept to healthcare: it allows patients to connect third-party applications, such as personal health record apps or care coordination tools, to their insurance claims data and clinical information held by health plans and providers.
The term became especially prominent following regulations from the Centers for Medicare and Medicaid Services (CMS), which mandated that certain federally regulated health plans implement a Patient Access API. Under the CMS Interoperability and Patient Access final rule published in 2020, Medicare Advantage plans, Medicaid managed care plans, CHIP managed care plans, and plans on the federally facilitated marketplace were required to make claims and encounter data, clinical data, and formulary information available through this type of API.
The technical foundation for the Patient Access API is HL7 FHIR (Fast Healthcare Interoperability Resources), a modern standard for structuring and sharing healthcare data. FHIR uses web-based protocols that developers are already familiar with, making it significantly easier to build applications that can query and display patient data compared to older healthcare data standards like HL7 v2 or CCD documents.
The Regulatory Foundation Behind Patient Access APIs
The CMS rule did not emerge in isolation. It was part of a broader federal push toward interoperability driven by the 21st Century Cures Act, which directed the Department of Health and Human Services to take action against information blocking and to promote the open exchange of electronic health information.
The Office of the National Coordinator for Health Information Technology (ONC) also issued complementary rules requiring certified health IT developers and certain healthcare providers to support standardized APIs for patient access. Together, these regulations created a legal and technical infrastructure that health plans and developers are required to follow.
For patients, this regulatory framework translates into a meaningful right: the ability to direct their health plan to share their data with an app of their choosing. The health plan cannot block or restrict this transfer as long as the patient has authorized it, unless the plan has a documented concern about the safety or legitimacy of the receiving application.
What Data Is Included?
The scope of data available through a Patient Access API is broader than many patients expect. Health plans covered by the CMS rule must provide adjudicated claims and encounter data, including provider details, service dates, and cost information. They must also provide clinical data specified in the United States Core Data for Interoperability (USCDI), which includes diagnoses, medications, allergies, immunizations, lab results, and care team information. Drug formulary data, which outlines what medications a plan covers and at what cost tier, is also required.
This combination of claims and clinical data gives patients a more complete view of their health than any single provider or portal could offer. A patient seeing multiple specialists, for example, could use a connected app to aggregate records from all of them into a single, readable format.
How the Patient Access API Works in Practice
From a technical standpoint, the Patient Access API uses the OAuth 2.0 authorization framework to allow patients to grant access to third-party apps without sharing their login credentials. The patient logs into their health plan’s portal, selects the app they want to authorize, reviews what data the app is requesting, and approves the connection. The health plan then issues a token to the app, which the app uses to query the FHIR-based API and retrieve the patient’s data.
The FHIR standard defines specific “resources” that correspond to clinical concepts. A Condition resource holds diagnosis information. A MedicationRequest resource contains prescription data. An Explanation Of Benefit resource covers claims details. When an app queries the Patient Access API, it requests these specific resources, and the health plan’s server returns data formatted according to FHIR standards.
This standardization matters enormously for developers. Instead of building custom integrations for every health plan, developers can build a single FHIR-compliant integration that, in theory, works across all plans that follow the same standard. The HL7 Da Vinci Project, a collaborative effort among payers, providers, and vendors, has done significant work to refine implementation guides that make this practical interoperability more achievable.
The Role of SMART on FHIR
Most Patient Access API implementations also support SMART on FHIR, a profile that builds on FHIR and OAuth 2.0 to provide a standardized launch framework for clinical apps. SMART on FHIR enables apps to launch from within an existing health system portal, request specific scopes of data, and operate within a well-defined security model. The SMART Health IT project maintains open-source tools and documentation that help both developers and implementers adopt this framework correctly.
Why Patient Access APIs Matter for Consumers
The practical benefits for patients are significant. Chronic disease management is one area where consolidated data access can meaningfully change outcomes. A patient managing diabetes, for example, might use a connected app to track how their lab values have changed over time, view all their prescriptions in one place, and share a complete record with a new endocrinologist, all without requesting physical records or waiting for faxed documents.
Care coordination across providers becomes more tractable when patients can carry their own data. This is especially valuable for individuals who move between states, switch insurance plans, or receive care from multiple health systems that do not share a common electronic health record platform.
Cost transparency is another benefit. Because claims data includes provider charges, negotiated rates, and patient cost-sharing amounts, patients with access to this information can make more informed decisions about where to seek care, whether to request a generic versus brand-name medication, and how to plan for out-of-pocket expenses.
Challenges and Considerations for Implementation
Despite the regulatory mandate and technical standards, implementation has not been without friction. Health plans vary in how completely and accurately they expose data through their Patient Access APIs. Some plans provide only the minimum required data, while others offer richer datasets. Data quality is also inconsistent, with some plans returning records that have missing fields, duplicate entries, or outdated information.
Security and patient privacy remain central concerns. Patients authorizing a third-party app should understand what that app will do with their data, how long it will be retained, and whether it will be shared with advertisers or other parties. The CMS rule requires health plans to inform patients about privacy risks when connecting to apps that are not subject to HIPAA. Still, the responsibility ultimately falls on the patient to evaluate the apps they choose to use.
Provider organizations face their own challenges. While the CMS rule primarily targeted health plans, ONC’s rules require healthcare providers using certified health IT also to support patient access through APIs. Meeting both the technical and compliance requirements demands investment in infrastructure and staff training, particularly for smaller practices and community health centers.
The Future of Patient Access APIs
Federal efforts to expand and strengthen Patient Access APIs are ongoing. CMS has continued to issue guidance and update technical requirements, including efforts to align with newer versions of FHIR and expand the data elements that must be shared. The broader goal is to enable longitudinal health records that follow patients throughout their lives, across insurance changes, provider transitions, and care settings.
The private sector is also investing heavily in this space. Major technology companies, health IT vendors, and startups have built platforms and marketplaces that leverage FHIR-based APIs to aggregate, analyze, and present patient data in meaningful ways. As more of this infrastructure matures, the Patient Access API will likely become a routine part of how patients and providers interact with health data, rather than a regulatory checkbox.
Conclusion
The Patient Access API represents a meaningful shift in how health information flows between institutions and individuals. Backed by federal regulation and built on open technical standards, it gives patients a legally protected and technically accessible path to their own health data. For healthcare organizations, it is both a compliance requirement and an opportunity to support more coordinated, patient-centered care. Understanding how these APIs work, what data they expose, and how to use them responsibly is increasingly important for patients, providers, and developers alike.
FAQ
What is the Patient Access API used for? It allows patients to securely share their health plan data, including claims and clinical records, with third-party applications they choose.
Which health plans are required to have a Patient Access API? Medicare Advantage, Medicaid managed care, CHIP managed care, and federally facilitated marketplace plans are required under the CMS Interoperability and Patient Access final rule.
Is my data safe when using a Patient Access API? HIPAA may not cover data shared with third-party apps, so patients should carefully review the privacy policy of any app they authorize before connecting it to their health data.
What technical standard does the Patient Access API use? The Patient Access API is built on HL7 FHIR (Fast Healthcare Interoperability Resources), a modern, web-based standard for exchanging healthcare information.