The Agnotic healthcare AI and interoperability glossary defines the terms teams meet when they scope AI and data exchange work, from ambient scribe and retrieval-augmented generation to FHIR, SMART on FHIR, CDS Hooks and USCDI. Each entry gives a plain definition, why it matters for a build and, where one exists, the official source.
Last reviewed by the Agnotic Technologies engineering team
15-Minute Scoping CallCDS Hooks
Standardnoun · HL7 specification
An HL7 specification for calling decision support from inside a clinician's workflow at points called hooks, such as patient-view or order-select. The service replies with cards the EHR shows to the user.
These are the AI terms that shape architecture, review steps and vendor contracts. Most of them describe how a model is used, not the model itself.
Software that listens to a clinician and patient conversation, with consent, and drafts the visit note for the clinician to review and sign. Also called ambient clinical documentation.
Why it matters for a build: The build work is in consent capture, EHR write-back and the review step, not only in the speech and language models.
A model trained on large amounts of text that generates, summarizes and answers questions in natural language.
Why it matters for a build: LLM output can read fluently and still be wrong, so clinical uses need grounding in source data, human review and evaluation on your own data.
A pattern where the application first retrieves relevant records or documents, then passes them to a language model so its answer is based on that material.
Why it matters for a build: RAG lets an answer point to the chart note or policy it came from, and keeps PHI in a retrieval layer you control.
Output from a generative model that is not supported by its input or by fact, such as a medication that was never mentioned in the visit.
Why it matters for a build: Design the review step and the test set around catching it before output reaches a chart or a patient.
A design where a person reviews, edits or approves AI output before it takes effect on a patient, a chart or a claim.
Why it matters for a build: It is the main safety control in most clinical and revenue cycle AI pilots, and it needs its own screens and audit trail.
Software that uses a language model to plan and carry out steps toward a goal, such as calling APIs or filling forms, within permissions you set.
Why it matters for a build: Every tool an agent can call needs the same access control and audit logging as a human user with that access.
A drop in a model's performance over time because the data it sees in production changes, for example new documentation habits, a new patient population or a changed form.
Why it matters for a build: Monitoring after go-live is part of the build, with a named owner and a threshold that triggers review.
ONC (ASTP) term for technology in certified health IT that supports decision-making based on algorithms or models that derive relationships from training data.
Why it matters for a build: If your model runs inside a certified EHR, expect questions about its intended use, inputs and validation.
A voluntary framework from NIST, published as NIST AI 100-1 in January 2023 and organized around four functions: Govern, Map, Measure and Manage.
Why it matters for a build: It gives a hospital AI review group a shared structure for approving and monitoring use cases.
These standards decide how an AI tool or app reads data from, and writes results back to, the systems clinicians already use.
HL7's standard for exchanging health data as resources, such as Patient, Observation and MedicationRequest, over a REST API. FHIR R4 (4.0.1) is the release named in ONC (ASTP) certification for standardized APIs.
Why it matters for a build: Most new EHR integrations start with FHIR R4, so your data model should map cleanly to its resources.
The HL7 implementation guide that sets US rules for FHIR resources, such as which elements must be supported, aligned to USCDI.
Why it matters for a build: If you build to US Core, the same code works across certified EHRs with fewer per-vendor changes.
The United States Core Data for Interoperability: a standardized set of health data classes and data elements for nationwide exchange, maintained by ONC (ASTP) in versions.
Why it matters for a build: It tells you which data a certified EHR is expected to make available through its APIs.
The HL7 SMART App Launch guide for authorizing apps against FHIR APIs with OAuth 2.0, using scopes and launch context such as the current patient.
Why it matters for a build: It is how an app launches inside the EHR, or standalone, with exactly the access it was granted.
The SMART profile that authorizes a server-to-server client with no user present.
Why it matters for a build: Use it for scheduled sync and bulk export; it needs its own key management and narrow system scopes.
An HL7 specification, also called Flat FHIR, for exporting data on many patients at once as files of FHIR resources.
Why it matters for a build: It is the usual route for population analytics and for building training or evaluation data sets.
An HL7 specification for calling decision support from inside a clinician's workflow at points called hooks, such as patient-view or order-select. The service replies with cards the EHR shows to the user.
Why it matters for a build: It is how an AI recommendation can appear inside the EHR without the clinician opening a separate app.
The message standard most hospital interfaces use for real-time events, such as ADT for admissions and transfers, ORM for orders and ORU for results.
Why it matters for a build: Many real-time AI triggers, such as a new admission or a lab result, arrive as HL7 v2 messages rather than FHIR calls.
Consolidated Clinical Document Architecture: an HL7 standard for clinical documents such as discharge summaries and continuity of care documents.
Why it matters for a build: Records received from other organizations often arrive as C-CDA documents that need parsing before an AI tool can use them.
The Trusted Exchange Framework and Common Agreement: a nationwide framework for health information sharing whose backbone is a set of Qualified Health Information Networks (QHINs).
Why it matters for a build: It is a growing route for retrieving outside records, which changes how much history an AI tool can see.
The CMS Interoperability and Prior Authorization final rule, which requires impacted payers to provide FHIR APIs including Patient Access, Provider Access, Payer-to-Payer and Prior Authorization.
Why it matters for a build: It sets the API surface that prior authorization automation and payer data tools build on.
These terms decide what data an AI tool may use, which contracts must be signed first and whether the software is regulated as a device.
Individually identifiable health information held or sent by a covered entity or business associate. Electronic PHI (ePHI) is the part the HIPAA Security Rule protects.
Why it matters for a build: Prompts, transcripts and model outputs that contain PHI need the same safeguards as the record itself.
The contract HIPAA requires before a vendor creates, receives, maintains or transmits PHI for a covered entity.
Why it matters for a build: An AI or model provider that processes PHI needs one before any PHI is sent, including during a pilot.
Removing identifiers so health data is no longer PHI. HIPAA allows two methods: expert determination, and safe harbor, which removes 18 categories of identifiers.
Why it matters for a build: De-identified data sets are how most teams test and evaluate models without moving PHI to new places.
Software intended for a medical purpose that performs that purpose without being part of a hardware medical device.
Why it matters for a build: If your AI diagnoses or treats, its intended use may make it a device, which changes how it is built, documented and released.
Clinical decision support software that meets the criteria in section 520(o)(1)(E) of the FD&C Act and so falls outside the medical device definition.
Why it matters for a build: Whether a clinician can independently review the basis for a recommendation is central to these criteria, so it shapes the user interface.
Full definition: clinical decision supportSource: FDA CDS Software guidance
Part of an FDA marketing submission for an AI-enabled device that describes planned modifications, how they will be developed and validated, and an assessment of their impact.
Why it matters for a build: It is how an AI device can be retrained or updated within agreed limits, so the plan shapes your MLOps pipeline.
A practice likely to interfere with access, exchange or use of electronic health information, as defined by the 21st Century Cures Act and regulated in 45 CFR Part 171.
Why it matters for a build: It affects how EHR vendors and providers respond to data requests from your app.
AI tools that read structured data depend on these code sets. Mapping between them is a large part of most data projects.
The US code set for diagnoses, used in billing and reporting.
Why it matters for a build: Diagnosis-based features and cohorts usually start from ICD-10-CM codes.
A code system for laboratory tests and clinical observations, maintained by the Regenstrief Institute.
Why it matters for a build: Consistent LOINC coding is what lets a model compare lab results across sites.
A clinical terminology for problems, findings and procedures, maintained by SNOMED International.
Why it matters for a build: Problem lists coded in SNOMED CT are easier to search and summarize than free text.
A normalized naming system for clinical drugs, produced by the US National Library of Medicine.
Why it matters for a build: RxNorm lets medication data from different sources be matched to the same drug.
Key facts from the standards bodies and regulators behind this glossary.
CDS Hooks describes a hook-based pattern for invoking decision support from within a clinician's workflow.
Source: HL7 CDS HooksThe SMART App Launch guide's Backend Services profile authorizes a headless or automated client application to connect to a FHIR server.
Source: HL7 SMART App LaunchUnder the HIPAA safe harbor method, data is de-identified by removing 18 categories of identifiers, with no actual knowledge that the rest could identify the person.
Source: 45 CFR 164.514(b)(2) (eCFR)HealthIT.gov describes Qualified Health Information Networks (QHINs) as the individual networks that make up the backbone of TEFCA.
Source: ONC (ASTP), HealthIT.govAgnotic Technologies builds healthcare AI and integrations for clients. These are the services where the terms above turn into delivery work.
