By Eric Andrew Kristof, RN, CAHIMS | Healthcare IT Professional | HIMSS Arkansas Chapter Member
About This Series: The HIMSS Word of the Day is a running blog series drawing from the HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025) — the authoritative reference for healthcare IT professionals and the primary study resource for CAHIMS and CPHIMS certification. Each post paraphrases the term in plain language, grounds it in real-world healthcare IT context, and adds a bedside nursing perspective you won’t find in a textbook.
📖 The Term: Application Programming Interface (API)
Source: HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025)
🔍 Plain-Language Definition
An application programming interface (API) is a defined set of rules that lets one piece of software ask another for data or for a task to be done. If an application is a restaurant kitchen, the API is the menu and the server: it lists what can be requested, in what format, and returns the result without exposing everything happening in the kitchen.
The HIMSS Dictionary, which uses the older name application program interface, gives two senses. In the first, an API is a standard collection of calls, functions, interrupts, and data formats that a program uses to reach network services, devices, other applications, or the operating system. In the second, it is a library of ready-made functions developers use to build software, so a program can hand specific jobs off to the operating system or to other software. The Dictionary notes many kinds of APIs, including ones for e-mail, telephony, programming languages, and graphics, and it cross-references sockets and SSL, the plumbing and encryption that many network APIs rely on.
In healthcare today, “API” most often means a web API: a secure internet address that an app can call to read or write clinical data.
| Piece | What It Does | Healthcare Example |
|---|---|---|
| Client | The app making the request | A patient’s phone app or a clinical app launched inside the EHR |
| Endpoint | The address where the request is sent | An EHR vendor’s published FHIR server address |
| Request | What the client asks for | “Return this patient’s active medications” |
| Authorization | Proof that the client and user are allowed to ask | An OAuth 2.0 access token issued after the patient logs in |
| Response | The data that comes back, in an agreed format | FHIR resources in JSON, such as MedicationRequest |
⚠️ Exam Alert: An API is a mechanism for software-to-software requests. FHIR is a standard that defines healthcare data resources and a RESTful API for exchanging them. SMART on FHIR adds a standard way to authorize and launch apps. A traditional HL7 v2 interface usually pushes messages through an interface engine rather than answering on-demand requests. Know which term is the method, which is the standard, and which is the security layer.
🌐 Why It Matters: Real-World Healthcare IT Context
For decades, getting data out of an EHR meant custom interfaces, file exports, or printed records. APIs changed that by giving outside software a standard, on-demand way to ask for information.
Federal policy pushed hard in that direction. The 21st Century Cures Act called for certified health IT to provide APIs that let patients and others access health information without special effort. ONC’s Cures Act Final Rule then required certified EHRs to support a standardized API for patient and population services based on FHIR, along with standards such as SMART App Launch for authorization and Bulk Data for population-level exports. On the payer side, CMS’s Interoperability and Patient Access Final Rule required many health plans to offer a Patient Access API, and its later prior authorization rule extended API requirements to prior authorization and data sharing between payers and providers.
Those rules connect directly to information blocking policy. Organizations that place unreasonable barriers in front of API access risk running afoul of the information blocking provisions.
APIs also bring risk. Every endpoint is a doorway, and the OWASP API Security Top 10 highlights recurring weaknesses, with broken object-level authorization, where a user can retrieve records that belong to someone else simply by changing an identifier, at the top of the list.
Common API pitfalls:
- Weak authorization checks that expose other patients’ data
- Apps that request far more data than they need
- Patients who do not understand what an app will do with their records once they leave HIPAA‘s protection
- Inconsistent implementation of standards between vendors
- Rate limits, outages, or version changes that break connected apps
- Little monitoring of which apps are connected and how much data they pull
Characteristics of a strong API program:
- Standards-based FHIR endpoints with published documentation
- OAuth 2.0 and SMART scopes that limit apps to the minimum necessary data
- Logging, monitoring, and anomaly detection on API traffic
- Clear patient-facing information about connecting third-party apps
- Governance for reviewing and approving clinician-facing apps
🏥 The Nurse’s Perspective: Clinical, Bedside, & Workflow
Nurses rarely see the word “API” on screen, yet APIs increasingly shape what nurses can see and what patients can access.
At the Bedside
Patients may ask nurses how to get their records into a health app on their phone. In many cases, that app connects through the hospital’s patient-facing FHIR API after the patient signs in with patient portal credentials. Nurses do not need to troubleshoot the connection, but they can explain that the patient is in control of which apps receive data and can point them to the organization’s support resources.
Patients also bring information from apps and devices that connect through APIs, such as medication lists or home readings. Nurses still verify that information before relying on it, especially for medications and allergies.
In Clinical Workflow
Inside the EHR, APIs make it possible to launch outside tools in the context of the current patient. A risk calculator, a medication dosing tool, or a care coordination app can open already knowing who the patient is, without a second login or manual re-entry. Decision support services may call APIs to retrieve data and return advice into the workflow.
Nursing documentation travels through APIs as well. Vital signs, assessments, and care plans entered at the bedside may be read by population health tools, quality reporting systems, and patient apps.
In EHR Implementation (Go-Live Perspective)
During an Epic Go-Live, APIs often sit behind integrations that users simply experience as “the app works” or “the app does not open.” Third-party tools may be reconnected to the new system, and some may need new configuration or approval before they launch for every role. At-the-elbow support analysts often route these issues to integration teams rather than solving them at the workstation.
Go-Live is also a time when patients rediscover their records. As the new portal opens, connected apps may need to be re-linked to new endpoints, and nurses at the bedside may hear questions about it during discharge teaching.
🎓 CAHIMS / CPHIMS & HIMSS Perspective
CAHIMS Exam Domain Mapping
APIs show up across policy, technical, and management questions:
| CAHIMS Domain | How APIs Appear |
|---|---|
| Healthcare & Technology Environments | 21st Century Cures Act; ONC certification; CMS interoperability rules; information blocking |
| Clinical Informatics | Apps launched in clinical workflow; decision support services; patient access to records |
| Healthcare Information & Systems Management | REST, FHIR resources, OAuth 2.0, SMART App Launch, Bulk Data, API security and monitoring |
| Management & Leadership | App governance, vendor management, privacy risk, third-party integration strategy |
Key Terms to Know Alongside API
- FHIR (Fast Healthcare Interoperability Resources) — the HL7 standard that defines healthcare data resources and a web-based API for exchanging them
- SMART App Launch — a standard for authorizing apps and launching them in the context of a patient or user
- OAuth 2.0 — an authorization framework that issues access tokens so apps can call APIs without seeing the user’s password
- REST (Representational State Transfer) — an architectural style for web APIs built on standard web requests
- Endpoint — the specific network address where an API receives requests
- Bulk Data Access — a FHIR-based method for exporting data on groups of patients for population health and analytics
HIMSS Organizational Position
HIMSS treats API-based exchange as central to interoperability and engages with federal agencies on certification, information blocking, and payer interoperability rules through its public policy work. Members can find related education and research through the HIMSS Resource Center.
🔗 Explore Further: External References
- ONC — API Resource Guide https://healthit.gov/resources/api-resource-guide/
- ONC — Standardized API for Patient and Population Services (Certification Criterion) https://healthit.gov/test-method/standardized-api-for-patient-and-population-services-acb-atl/
- CMS — Interoperability and Patient Access Final Rule (CMS-9115-F) https://www.cms.gov/initiatives/burden-reduction/overview/interoperability/policies-regulations/cms-interoperability-patient-access-final-rule-cms-9115-f
- HL7 — SMART App Launch https://hl7.org/fhir/smart-app-launch/
- OWASP — API Security Top 10 https://api-security.owasp.org/
- HIMSS — Public Policy and Advocacy https://www.himss.org/public-policy-advocacy-overview
Term source: HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025). All definitions in this series are paraphrased for editorial purposes. Readers are encouraged to consult the primary source for exact language.
Eric Andrew Kristof, RN, CAHIMS is a Healthcare IT professional and HIMSS Arkansas Chapter member based in Hot Springs Village, AR, with hands-on Epic Go-Live experience and a diverse healthcare and IT background. He writes at kristof.org at the intersection of clinical care and healthcare technology.
Leave a Reply