6.2 Healthcare IT Vocabulary

6.2 Healthcare IT Vocabulary

Quick Answer: Task A.2 is workplace English for informatics. An EHR stores the longitudinal record. CPOE is electronic order entry. CDS is decision support. HIE shares data across organizations. ADT announces movement events. MPI keeps one person identity. An interface moves messages; an API exposes a callable contract. Downtime is unavailability; uptime is availability.

If task A.1 is how clinicians talk, task A.2 is how analysts, interface engineers, and nursing informatics coordinators talk in the same meeting. CPHIMS will not award points for using the words as decorations. It will ask who owns the failure when “ADT is down,” whether a new alert is CPOE or CDS, and whether a FHIR query is the same thing as the lab interface.

CPHIMS practicePractice questions with detailed explanations

EHR — the system of clinical record

An electronic health record (EHR) is the organization’s (and, at its best, the person’s) longitudinal clinical record: problems, allergies, medications, immunizations, history, notes, results, orders, and often the visit and inpatient stay around them. People still say EMR (electronic medical record) for a single-organization chart. In CPHIMS conversation, do not waste time on a purity debate. Do lock the operational meaning: the EHR is the system of record clinicians document in, not the data warehouse, not the HIE, and not the billing system that happens to store a diagnosis.

Related modules you will hear in the same breath: eMAR (electronic medication administration record), BCMA (barcode medication administration), inpatient versus ambulatory charts, and the patient portal or personal health record view. Those are functions or layers. They are not substitutes for the word EHR when the stem is about the legal medical record.

CPOE and CDS — entry versus advice

Computerized provider order entry (CPOE) is the electronic capture of orders by a licensed ordering clinician—or, in some workflows, by a protocol or verbal-order entry with the right authentication. Medications, labs, imaging, diets, nursing orders, and referrals all sit in CPOE. The point of CPOE is a legible, structured, authenticated order that can drive pharmacy, laboratory, radiology, and nursing worklists. CPOE is not automatically safe. A complete CPOE catalog can still let a user order a fatal dose if no knowledge sits on top of it.

Clinical decision support (CDS) is the knowledge, logic, and presentation that help a clinician decide or act: drug-allergy checking, dose range, duplicate therapy, corollary orders (“you ordered a CT with contrast—check creatinine”), preventive reminders, order sets, infobuttons, and predictive flags. CDS can fire inside CPOE, inside documentation, at results review, or at handoff. CPOE without CDS is electronic handwriting. CDS without a workflow is a PDF of guidelines nobody opens.

Exam trap: a stem that says “build CPOE so the potassium cannot be given IV push” is really asking for product/route constraints plus CDS or hard stops, not for “more CPOE.” A stem that says “providers refuse to use order entry because of alerts” is a CDS design and governance problem, not proof that CPOE should go back to paper.

HIE — exchange across boundaries

A health information exchange (HIE) is the capability—and often the organization—that moves clinical data across unaffiliated or separately governed entities: hospital to independent clinic, emergency department to primary care, public-health reporting, or a regional query for outside encounters. HIE may use an interface engine, FHIR APIs, a record-locator service, and consent rules. The EHR can participate in HIE. The EHR is not itself “the HIE” just because two clinics share a vendor.

If the stem is about a patient arriving from another health system with no local history, the first vocabulary word is HIE (or at least external query), not “open a bigger EHR.”

ADT and MPI — movement versus identity

ADT means admission, discharge, and transfer. In operations it is both a set of real-world events and the classic HL7 v2 message family that announces them (and related updates such as cancel admit, change patient location, or merge). ADT messages keep downstream systems honest: lab needs a location, dietary needs a bed, radiology needs a visit, the bed board needs occupancy, the portal needs an encounter. When people say “ADT is down,” they usually mean the event feed is not updating subscribers. The EHR chart may still be open.

The master patient index (MPI)—and its enterprise form, EMPI—is the register of who the person is: identifiers, demographics, and the links among medical record numbers across facilities. MPI answers “is this the same human?” ADT answers “what just happened to an encounter or location for a human we think we know?” ADT demographics can update the MPI. They are not the MPI.

MPI failures have two famous shapes. A duplicate is two charts for one person—split history, missed allergies, repeated labs. An overlay is two people crushed into one chart—the worse safety event. Informatics language should keep those words distinct from “the ADT interface failed.”

Interface versus API

An interface in health-IT speech almost always means a message-based, often asynchronous connection: HL7 v2 ORM/ORU/ADT, X12 for claims, sometimes a vendor-specific feed, usually mediated by an interface engine. You reason about acknowledgements, queues, gap fills, and “the feed is backed up.”

An application programming interface (API) is a callable contract: a client requests a resource and gets a response. In current U.S. interoperability policy the usual clinical API is HL7 FHIR over HTTP, often with SMART-on-FHIR authorization. You reason about endpoints, scopes, rate limits, and versioned resources (Patient, Encounter, Observation, MedicationRequest).

Both move data. They fail differently. An interface engine can queue ADT while the EHR stays up. An API can return 401 Unauthorized while the lab interface is healthy. Saying “just build an interface” when a third-party app needs a patient-facing FHIR API is the wrong vocabulary and the wrong security model.

Downtime and uptime

Downtime is the period when a system or a critical function is unavailable. Planned downtime is a scheduled maintenance window. Unplanned downtime is an incident. Read-only downtime may still allow chart review from a replica or downtime viewer. Total downtime means document and medicate from downtime procedures—paper, downtime codes, or a backup device. Domain 3 will treat business continuity more fully; task A.2 only needs you to use the words correctly and to know that every production EHR needs a downtime procedure, not a hope that outages will not happen.

Uptime is availability—the complement of downtime, often discussed as a percentage over a month or year. CPHIMS does not publish an official uptime formula or a required 9’s target. Operationally, a vendor or internal SLA may state a percentage, and operations will still count minutes that mattered (CPOE down at 07:00 is not the same as a report server down at 02:00). Do not treat a high uptime slide as proof that barcode administration or ADT never failed. Partial functional outages are still downtime for the people who needed that function.

Scenarios and exam traps

Scenario. Nurses report “the EHR is down” because labels are not printing and dietary does not know the new room. The chart is open, CPOE works, and BCMA works. Vocabulary: the ADT interface (or a subscriber) is down, not the entire EHR. Page the integration on-call, not a full downtime paper chart—unless your procedure says otherwise for that failure mode.

Scenario. A quality committee wants “more CPOE” to stop duplicate CT scans. Providers already enter orders electronically. The gap is CDS (duplicate-study checking, indication capture) and perhaps HIE visibility of outside imaging—not a second order-entry module.

Scenario. A digital vendor asks for “an ADT interface so the patient can download their record in the app.” That request mixed three words. Patient access is usually an API (and a portal), identity is MPI, and ADT might still notify the vendor of encounters. Design the contract that matches the use case.

Watch these traps:

1. Calling shared-EHR visibility an HIE.
2. Treating CPOE and CDS as one word.
3. Using MPI and ADT interchangeably.
4. Calling every integration an interface, including SMART-on-FHIR apps.
5. Declaring uptime “fine” because the login page loaded while CPOE was frozen.
6. Skipping downtime procedures because last quarter’s availability slide looked green.

When a stem piles on acronyms, translate each one to a job: record, order, advice, exchange, event, identity, message, call, outage, availability. The right owner and the right fix follow the right noun.