Technology, privacy & interoperability Glossary

Start with the information and the regulated role

Protected health information is individually identifiable health information held or transmitted by a HIPAA covered entity or business associate, subject to the rule's definitions and exclusions. The HHS Privacy Rule overview is a starting point. An ABA label alone does not establish covered-entity status.

A business associate agreement is the HIPAA-required contract for a covered entity or business associate and a qualifying business associate relationship. It defines permitted uses and disclosures, safeguards, incident and breach handling, subcontractors, return or destruction, and other required terms. HHS cloud guidance explains that a cloud provider maintaining ePHI on behalf of a regulated customer is a business associate even when it holds encrypted data without the key.

A BAA does not certify security, accuracy, clinical fitness, or the legality of the underlying use. Classify the entity, data, purpose, role, and disclosure route first.

An EHR is an evidence system

An electronic health record stores clinical and related information across time. AHRQ's EHR primer describes benefits and safety risks, including usability, communication, data, and workflow concerns.

Clinical records need authorship, actual service and entry times, source data, corrections, signatures when required, access controls, and audit history. Templates should support accurate work without forcing facts that did not occur.

Documentation Templates and Rules is a Da Vinci implementation guide that supports exchange of documentation requirements and questionnaires in defined FHIR workflows. A machine-readable template is not a clinical record, payer approval, or proof that every required fact applies.

Interoperability has several layers

Health data interoperability is the ability of systems to exchange and use health information with shared technical and semantic meaning. Transport alone is insufficient. Identity, authorization, terminology, profile, version, provenance, timing, and workflow must align.

Map each data flow before implementation. Record the sender, receiver, person or member match, purpose, authority, minimum data needed, format, profile, terminology, trigger, transport, authentication, acknowledgment, retry, correction, retention, and accountable owner. Test missing, stale, duplicate, conflicting, and misrouted information as well as the happy path. A successful HTTP response can still carry the wrong person, outdated rule, incomplete resource, or rejected business state.

Coverage Requirements Discovery, or CRD, is an HL7 Da Vinci FHIR implementation guide for discovering coverage requirements during clinical workflows. The official CRD guide does not itself prove coverage, prior-authorization need, endpoint availability, or rule freshness.

The Prior Authorization Support implementation guide, or PAS, defines a FHIR-based exchange pattern that connects to payer prior-authorization transactions. The PAS guide is distinct from CRD and from DTR, which addresses documentation templates and rules.

CMS-0057-F requires specified impacted payers to implement a Prior Authorization API for medical items and services excluding drugs, generally beginning January 1, 2027. The CMS fact sheet identifies the payer classes and separate 2026 process provisions. Other commercial and employer plans are outside the rule's mandatory payer scope. An API requirement does not prove a particular endpoint is live, complete, or current.

AI drafting requires accountable review

Generative AI produces new content from prompts, context, learned patterns, and system instructions. AI-assisted documentation uses an AI system to draft, summarize, structure, or suggest clinical record content.

The clinician should compare any draft with the actual service, source data, client communication, plan, and documentation rules. Preserve the accountable author, edits, approval, and final record. Never invent observation, time, response, risk, progress, or rationale to complete a template.

Automation bias is the tendency to accept or rely on automated output too readily, sometimes missing contradictory evidence or failing to act when the tool is silent. HealthIT.gov's clinical decision-support page emphasizes delivering appropriate information to the right people in usable formats. Decision support still needs workflow design and professional judgment.

Human-in-the-loop review assigns a person to inspect, approve, reject, or change an output before a defined action. Name the reviewer, competence, evidence, decision, response time, escalation, and prohibited auto-actions. A click alone is not meaningful review.

The CASP Practice Parameters for AI provide ABA-specific guidance, and the BACB Ethics Code supplies professional duties for covered behavior analysts. Neither validates a particular AI product or output.

A review example

A fictional clinician reviews 20 AI-drafted session-note fields. Sixteen match the source record, two need factual correction, one adds an unsupported interpretation, and one lacks the client's AAC response. First-pass field accuracy is 16/20, 80%. All four defects remain visible and are corrected before approval.

That rate describes one field sample and model configuration. It does not establish note-level validity, safety, privacy compliance, payer acceptance, or clinical benefit. The practice also samples omissions, subgroup performance, source traceability, access, and reviewer overrides.

The review owner pauses deployment when a material error cannot be detected or corrected within the clinical workflow.

Explore clinical roles at Finni practices. Ask how clinicians retain authorship, verify AI drafts, preserve audit history, protect PHI, and handle payer-interface uncertainty.