Section 2.5: Terminology Services and API Integrations

2.5.1 The “Why”: The Problem of Stale Knowledge

Throughout this module, we have built a powerful case for standardized, structured data. We’ve seen how mapping a local formulary to RxNorm and building ontologies can create intelligent, safe systems. But we have, until now, ignored a fundamental and dangerous reality: clinical knowledge is not static. The world of medicine is in a constant state of flux. New drugs are approved by the FDA every month. New black box warnings are issued. New clinical guidelines are published. New strains of bacteria develop resistance, changing antibiograms. The “truth” of today can become the dangerous misinformation of tomorrow.

This presents a massive challenge for health systems. In the traditional model of health IT, a hospital’s terminologies and knowledge bases (like its drug database or allergy-checking logic) are maintained as local, static files. The hospital licenses a large data file from a vendor, loads it onto its own servers, and that file becomes the “source of truth” for the entire institution. But the moment that file is loaded, it begins to decay. It starts to go stale. The process of getting an updated file, testing it, and deploying it across a complex hospital network can take months. In that time, a new life-saving drug might be missing from the system, or a critical new drug interaction might not be flagged.

Terminology services and APIs solve the problem of stale knowledge. They represent a fundamental architectural shift from a model of “owning the data” to one of “accessing the data.” Instead of maintaining a massive, constantly aging encyclopedia in its own basement, the hospital’s EHR can now use the internet to “call out” to a centralized, constantly updated, expertly managed library for the specific piece of information it needs, right at the moment it needs it. This ensures that the information guiding clinical care is always the most current, complete, and accurate version available. This move from local files to live, on-demand data services is one of the most significant trends in modern health informatics, transforming the role of the informaticist from a data manager to a systems integrator.

2.5.2 What is an API? The Waiter in the Restaurant

The term “API” (Application Programming Interface) can sound intimidatingly technical, but the concept is remarkably simple. An API is just a set of rules and protocols that allows one piece of software to request services or information from another piece of software. It’s the “middleman” that handles the communication.

The most common analogy is that of a restaurant. Think of the different parts of the system:

• You (The Client Application): You are the program that needs information. For example, the EHR needs to know the drug class of atorvastatin.
• The Kitchen (The Server / Terminology Service): This is the powerful system that holds all the data and the logic. It’s the RxNorm database, with its ontology and relationships.
• The Waiter (The API): You, the customer, do not go into the kitchen. You have a well-defined way to communicate with it: you talk to the waiter. The waiter takes your order (your request), brings it to the kitchen, and returns with your food (the response). The waiter is the interface between you and the complex system in the back.

The Language of APIs: Requests and Responses

This “conversation” between the client and the server happens in a structured format. While there are many types of APIs, most modern web-based services use a style called REST (Representational State Transfer), which uses the same basic language as your web browser.

{
  "idGroup": {
    "name": "Lipitor",
    "rxnormId": [
      "153165"
    ]
  }
}

In this simple exchange, our EHR didn’t need to know anything about the NLM’s servers or databases. It just needed to know the correct “waiter” to talk to (the API endpoint) and how to phrase its order (the request parameters). It received a perfectly structured, predictable response that it can now use in its own logic.

2.5.3 The NLM’s RxNav API: A Pharmacist’s Best Friend

The single most important and powerful terminology service for pharmacy informatics is the one provided for free by the U.S. National Library of Medicine (NLM). The RxNav suite of APIs provides live, programmatic access to the entire RxNorm database. It is the gold standard and the foundation upon which countless commercial and hospital-built systems are based. As an aspiring informaticist, becoming familiar with its capabilities is not optional; it is a core competency.

Masterclass Table: Essential RxNav API Functions

Below are some of the most common tasks a pharmacy informatics system needs to perform and the RxNav API function that accomplishes it. This is your playbook for leveraging real-time drug data.

2.5.4 A Modern Architecture: The Hybrid Model

While the idea of calling an external API for every single medication task is appealing, in the real world of high-volume hospital operations, it can be impractical. What if the internet connection goes down? The entire hospital pharmacy system would grind to a halt. What about the speed (latency) of making millions of API calls a day over the public internet? For these reasons, most modern health systems don’t use a purely external model. Instead, they use a sophisticated hybrid model that combines the best of both worlds.

2.5.5 The Informatics Angle: From Data Janitor to Systems Integrator

The rise of terminology services and APIs fundamentally changes the day-to-day work and the strategic value of the pharmacy informaticist. The job is no longer primarily about the painful, manual “care and feeding” of static data files. The focus shifts to higher-level, more impactful work.

In this new world, your value is not in your ability to manually manage a list. Your value is in your ability to understand both the clinical need and the technical capability of these powerful services. You are the architect who designs the bridges between the EHR and these central sources of knowledge, ensuring that every clinical decision is supported by the best, most current information science can provide. This is the future of pharmacy informatics, and it is a role of immense strategic importance in the modern health system.