Appendix A

AI for the Nursing Informaticist: Practical Guide, Prompt Library, and Workflow Cookbook

Model landscape checked: September 15, 2026
Purpose: Help nursing informaticists use modern AI systems productively while preserving evidence, privacy, professional judgment, and organizational accountability.

How to Use This Appendix

This appendix has two layers:

• Durable layer: how to frame work, prompt models, verify output, use AI in informatics workflows, protect sensitive information, and govern automation. These principles should age relatively slowly.
• Current-model layer: examples of current model families, tools, and healthcare offerings. This layer should be reviewed several times per year because model names, capabilities, prices, context limits, and product terms change quickly.

The central rule is simple:

Use AI to increase the speed and breadth of informatics work without transferring accountable judgment to the model.

AI is most useful when it helps you structure, inspect, compare, generate alternatives, detect omissions, transform information, or automate bounded work. It is least trustworthy when you ask it to supply missing facts, make high-consequence decisions without evidence, or act autonomously across systems without controls.

A.1 — What AI Is Good At in Informatics Work

• AI compresses transformation work. Converting meeting notes into themes, translating technical language, restructuring requirements, summarizing long policies, generating test cases, or turning a workflow description into a diagram are tasks where language models can save substantial time.

• AI expands the hypothesis space. An LLM can propose failure modes, stakeholder concerns, data-quality explanations, edge cases, or competing interpretations that a human team may not initially consider. Its value is breadth; validation determines which hypotheses deserve belief.

• AI can act as an adversarial reviewer. Asking the model to attack a business case, requirement, workflow, implementation plan, or executive recommendation often produces more value than asking it to “improve” the document. Critique exposes assumptions that polished drafting can hide.

• AI can provide technical translation. A nursing informaticist can use AI to understand SQL, FHIR JSON, API errors, identity concepts, security architecture, or code without pretending to be the technical owner. The safest pattern is explain → test understanding → verify with authoritative documentation or a technical partner.

• AI can support repeatable analytical workflows. When prompts, data inputs, output formats, and validation steps are standardized, AI becomes part of a governed process rather than an improvisational chatbot.

High-value informatics uses

A.2 — Current Model Landscape: September 2026

This section is descriptive, not a ranking. Model selection should follow the task, organizational environment, data sensitivity, tool requirements, latency, cost, and validation burden.

OpenAI

As of September 15, 2026:

• GPT-6 Astra is OpenAI’s current highest-end model for complex end-to-end work and supports tools such as web search, file search, functions, and computer use in supported environments. OpenAI documents a 1.05 million-token context window for the API model.
• GPT-5.6 Sol remains a high-capability model for complex professional work.
• GPT-5.6 Terra is positioned as a balance of capability and cost.
• GPT-5.6 Luna is positioned for fast, lower-cost, high-volume work.

For healthcare organizations, OpenAI currently lists HIPAA-eligible offerings under an applicable Business Associate Agreement, including ChatGPT for Healthcare, ChatGPT Enterprise with Regulated Workspace, certain FedRAMP/Clinicians offerings, and API configurations with modified retention. Coverage is product- and feature-specific.

Anthropic

Anthropic’s 2026 portfolio includes models such as:

• Claude Fable 5.1, Anthropic’s current Fable-series release as of September 2026, with Fable 5 retained as its immediate predecessor;
• Claude Opus 5, an Opus-class model in Anthropic’s current model family;
• Claude Sonnet 5, a broadly available model designed for reasoning, tool use, coding, and agentic work.

Model positioning and pricing change quickly, so the informaticist should compare the current vendor documentation for the specific task rather than infer capability from a family name alone.

Availability and safeguards can vary by product, region, and task. Healthcare organizations should evaluate the specific enterprise agreement and data-processing terms rather than assuming a consumer account is suitable for protected information.

Google

Google’s current Gemini API lineup includes Gemini 3.8 Flash as of September 2026. Google documents multimodal input, a 1,048,576-token input limit, tool/function support, code execution, file search, search grounding, structured outputs, and other capabilities in supported configurations.

Google also maintains specialized/live and other model variants. As with every vendor, exact data handling depends on the product and enterprise configuration.

Model selection without brand loyalty

Ask these questions instead of “Which AI is best?”

1. What is the task? Drafting, extraction, deep reasoning, coding, data analysis, document review, multimodal analysis, agentic work, or real-time interaction?
2. How consequential is error? A brainstorming error and a patient-facing medication error do not carry the same verification burden.
3. Does the model need current information? If yes, can it use trustworthy retrieval or web sources with citations?
4. Does it need tools? Files, code execution, database access, browser, EHR context, or other systems?
5. What data may enter the model? Public, internal, confidential, PHI, regulated, or security-sensitive?
6. What enterprise controls exist? SSO, role controls, retention, audit, residency, encryption, connector permissions, BAA/DPA, administrative monitoring?
7. How reversible is the output? Draft text is easy to correct; an autonomous system action may not be.
8. What is the cost/latency requirement? High-volume extraction may not require the most expensive reasoning model.
9. How will you validate the result? A model is useful only if the workflow can detect when it is wrong.

A practical routing pattern

• Fast routine model: classification, reformatting, simple extraction, first-pass summaries.
• General reasoning model: requirements, policy comparison, workflow analysis, meeting synthesis, executive communication.
• Deep reasoning model: ambiguous architecture, complex tradeoffs, root-cause exploration, strategic analysis, difficult debugging.
• Coding/data-oriented workflow: SQL, Python, transformation logic, reproducible analysis, test automation.
• Grounded/retrieval workflow: current regulations, organizational policy, evidence review, standards documentation.
• Agentic workflow: multi-step work that uses tools; requires the strongest permission, logging, and stop-condition design.

A.3 — The Informatics Prompt Architecture

Long prompts are not automatically better prompts. A strong prompt reduces ambiguity about the work and makes validation easier.

The seven-part structure

Use the parts that matter; omit those that do not.

1. Context — What system, workflow, organization, audience, or problem is relevant?
2. Task — What exactly should the model do?
3. Evidence — Which supplied documents/data/sources may it rely on?
4. Constraints — What must it not assume, change, disclose, or decide?
5. Reasoning objective — What should it examine: tradeoffs, ambiguity, risks, alternatives, causal hypotheses?
6. Output structure — What form should the answer take?
7. Verification requirement — What must be flagged, cited, tested, or handed back to a human?

Weak prompt

Analyze our new documentation workflow and tell me what is wrong.

Stronger prompt

You are supporting a nursing-informatics workflow review. Using only the observation notes below, reconstruct the current workflow by actor, step, system, handoff, decision, exception, and workaround. Separate observed facts from hypotheses. Identify possible duplication, delay, cognitive burden, safety risk, and data-quality risk, but do not conclude that a step should be removed unless its function is known. End with five questions that should be validated with frontline staff before redesign.

The second prompt is better because it defines evidence, separates fact from inference, and forces the model to expose uncertainty.

A.4 — Progressive Prompting: Do Not Ask for the Final Answer Too Early

For complex informatics work, use AI in stages:

1. Explore

Ask the model to identify the problem space, actors, assumptions, unknowns, and possible mechanisms.

Example: “What different mechanisms could explain a sudden increase in incomplete medication reconciliation?”

2. Structure

Turn the problem into a map, table, decision tree, requirements set, or evidence matrix.

Example: “Group these mechanisms into workflow, user, data, interface, policy, and training categories.”

3. Challenge

Ask the model to attack the working explanation.

Example: “Assume our preferred explanation is wrong. What evidence would support three competing explanations?”

4. Refine

Update the analysis with real evidence.

Example: “Here are ticket counts, timestamps, and observation notes. Which hypotheses are now more or less plausible? Show why.”

5. Verify

Require authoritative sources, reproducible calculations, known-case validation, SME review, or testing.

Example: “List every claim in this draft that requires an external source or local data validation.”

6. Produce

Only after the reasoning is stable should the model draft the requirement, brief, test plan, communication, or recommendation.

A.5 — Verification Ladder: Match Verification to Consequence

Not every AI output deserves the same review burden.

Verification methods

• Source-grounded verification: Open the source and confirm the claim.
• Known-case testing: Test the output against examples with known expected results.
• Reproducibility: Re-run calculations independently or inspect code/query logic.
• Cross-role review: Have the correct domain owner validate the part within their expertise.
• Adversarial testing: Try edge cases, contradictory evidence, missing data, and unusual populations.
• Prospective monitoring: Verify that performance persists after deployment.

What does not count as verification

• The model says it is confident.
• The answer sounds detailed.
• A second LLM agrees.
• The output includes citations that were not opened.
• The SQL executes without error.
• Users say the AI is usually right.

A.6 — PHI, Confidential Data, and AI: A Decision Framework

Before entering information into an AI system, classify the data and the environment.

Step 1 — What data are involved?

• Public/non-sensitive information
• Internal operational information
• Confidential business information
• Credentials/security architecture
• Patient-identifiable information/PHI
• Specially protected or highly sensitive information

Step 2 — Which AI environment is being used?

• Public consumer service
• Personal paid account
• Organization-managed enterprise workspace
• Regulated/healthcare workspace
• Approved API/application
• Locally hosted/private environment

Step 3 — Which contractual and technical controls apply?

Verify:

• Is the specific product/feature approved?
• Is a BAA required and in place where applicable?
• Is customer data used for model training?
• What is retained, for how long, and where?
• Are connectors/plugins covered?
• Are audit logs available?
• Who can access conversation/file history?
• Are there data-residency requirements?
• Can users accidentally share data externally through tools?

Step 4 — Minimize the data

Even in an approved environment, use only the information necessary for the task. An approved system does not make indiscriminate data sharing good practice.

Step 5 — Consider the output

AI-generated content can itself become sensitive when it contains patient data, internal architecture, incident details, or derived confidential information. Protect output as carefully as input.

A.7 — Prompt Library for Nursing Informatics

The prompts below are templates. Replace bracketed text and adapt them to your organization’s policy.

1. Problem Framing

Prompt — Problem Before Solution

I am evaluating this informatics request: [request]. Do not solve it yet. Rewrite it as a neutral problem statement that identifies affected users, workflow, current state, consequence, frequency, and desired outcome. List which facts are known, which are assumptions, and which information is missing. Identify whether the requested solution appears to be only one of several possible interventions.

2. Workflow Reconstruction

Prompt — Workflow Mapper

Using only the notes below, reconstruct the current-state workflow. For each step identify actor, trigger, action, system/tool, input, output, handoff, decision point, exception, and workaround. Separate observed facts from inferred steps. Then identify possible duplication, delay, interruption, cognitive burden, safety risk, and data-quality risk. End with questions that require frontline validation.

3. Observation Guide

Prompt — Workflow Observation Planner

I need to observe [workflow] without leading users toward a predetermined solution. Create an observation guide covering physical movement, screens/devices, interruptions, workarounds, handoffs, duplicate entry, waiting, memory burden, exceptions, and differences between policy and actual practice. Include neutral follow-up questions.

4. Stakeholder Interview

Prompt — Stakeholder Interview Builder

Create an interview guide for [role] about [workflow/system]. Prioritize questions that reveal goals, failure modes, workarounds, information needs, dependencies, constraints, and consequences. Avoid questions that assume the current technology is the problem.

5. Requirements Critic

Prompt — Requirements Red Team

Review the requirements below. For each one identify ambiguity, hidden assumptions, missing acceptance criteria, unmeasurable terms, dependencies, edge cases, workflow conflicts, data needs, security implications, and whether the requirement describes a need or prematurely specifies a solution. Do not rewrite until after completing the critique.

6. User Story and Acceptance Criteria

Prompt — Acceptance Criteria Builder

Convert this validated user need into a user story or requirement, then propose measurable acceptance criteria using normal, boundary, negative, permission, downtime, and exception scenarios. Flag criteria that require SME validation.

7. Test Case Generator

Prompt — Test Designer

For this requirement [requirement], generate test cases covering happy path, boundary values, invalid input, missing data, duplicate data, role/permission differences, interface delay, downtime/recovery, unusual patient context, and regression risk. For each test include preconditions, steps, expected result, and risk if it fails.

8. UAT Scenario Builder

Prompt — Clinical UAT Scenarios

Create realistic end-to-end UAT scenarios for [workflow]. Use complete clinical stories rather than isolated button checks. Include at least one routine case, one complex case, one exception, and one case likely to expose an integration or role-permission problem.

9. Root-Cause Hypothesis Generator

Prompt — RCA Hypothesis Expansion

Here are the established facts from an incident: [facts]. Generate possible contributing mechanisms across people, workflow, environment, technology, interface/data, policy, training, communication, and workload. Do not label any hypothesis a root cause without evidence. For each hypothesis state what evidence would support or weaken it.

10. FMEA Assistant

Prompt — Failure Mode Expansion

Given this process map [map], propose plausible failure modes at each step. For each, describe effect, possible causes, existing controls, detectability, and suggested mitigation categories. Do not assign final severity/probability scores; leave risk scoring to the accountable team.

11. SQL Explainer

Prompt — Explain This Query Clinically

Explain the SQL below to a clinical informatics analyst. State the grain of each source table, join logic, filters, grouping, denominator, null behavior, duplicate risk, timestamps used, and assumptions. Then list five known-case tests I should run before trusting the output.

12. SQL Drafting

Prompt — Draft SQL With Assumptions First

I need a query to answer [question]. Before writing SQL, restate the intended numerator/denominator, grain, inclusion/exclusion rules, relevant timestamps, null handling, and assumed schema. Ask for any missing schema detail rather than inventing a field. Then draft the query and annotate high-risk logic.

13. Data-Quality Investigator

Prompt — Metric Anomaly Investigation

This metric changed from [baseline] to [new value] after [date/event]. Generate competing explanations in these categories: real clinical change, documentation behavior, denominator/population change, interface failure, extraction/transformation change, duplicate data, missingness, timing/refresh, and definition change. For each, specify the evidence needed to test it.

14. FHIR Resource Tutor

Prompt — FHIR Walkthrough

Explain this FHIR resource in plain clinical language. Identify resource type, identifiers, references, coded elements, timestamps, status, and any extensions. Distinguish what the JSON explicitly states from what you infer. Cite the official FHIR specification sections I should verify and do not invent missing elements.

15. Interoperability Error Triage

Prompt — Interface Failure Hypotheses

Given this de-identified interface error [error/log excerpt], organize likely causes into source data, syntax/validation, terminology, identity/matching, transformation, transport, authentication/authorization, destination workflow, and version/profile mismatch. Suggest diagnostic checks in lowest-risk order.

16. Dashboard Critic

Prompt — Dashboard Decision Review

Evaluate this dashboard specification for the decisions it is supposed to support. For each metric identify definition, numerator, denominator, time frame, source, refresh, target/comparator, action owner, drill-down need, and plausible misinterpretation. Identify visualizations that add cognitive load without decision value.

17. Executive Brief

Prompt — Executive Decision Compression

Convert the analysis below into a one-page executive brief using: Decision Needed, Current State, Evidence, Options, Tradeoffs/Risks, Recommended Next Step. Preserve material uncertainty. Move technical detail that does not change the decision into an appendix list rather than deleting it.

18. Vendor Demo Script

Prompt — Vendor Demo Stress Test

Using our requirements [requirements], create a vendor demonstration script that forces the product through realistic workflows rather than feature slides. Include routine, exception, permission, integration, downtime, reporting, data-export, and administrative scenarios. Add follow-up questions when the vendor relies on roadmap functionality or manual workarounds.

19. RFP Response Critic

Prompt — Vendor Response Gap Analysis

Compare this vendor response with our requirements matrix. Classify each item as demonstrated, documented commitment, configurable, custom development, roadmap, unclear, or unmet. Quote only the minimum language needed to support the classification. Generate clarification questions for vague responses.

20. Change-Impact Analysis

Prompt — Stakeholder Impact Map

For this proposed change [change], identify affected roles and how their tasks, timing, information, authority, workload, handoffs, and failure modes may change. Separate direct effects from second-order effects. Do not assume resistance is caused by attitude; identify rational reasons the change may create risk or burden.

21. Training Scenario Generator

Prompt — Scenario-Based Education

Create realistic training scenarios for [new workflow]. Teach the decision and workflow rather than menu navigation alone. Include a normal case, an exception, a common error, and a downtime/contingency case. Provide facilitator notes explaining the intended reasoning.

22. Policy Comparison

Prompt — Compare Supplied Policies

Compare only the two supplied policy versions. Identify additions, removals, changed obligations, changed role responsibilities, changed timelines, and ambiguous language. Cite the exact supplied section for every material difference. Do not infer current law unless a separate authoritative legal source is provided.

23. Regulatory Research

Prompt — Current Rule Research Plan

I need to determine the current U.S. requirements for [topic] affecting [entity/state/program]. First list the authoritative primary sources that should control the answer. Distinguish statute, final rule, proposed rule, guidance, accreditation requirement, and vendor interpretation. State effective dates and affected entities. Flag any area where legal/compliance review is required.

24. Meeting Decision Extractor

Prompt — Decisions, Not Minutes

From these meeting notes/transcript, extract: decisions made, decision owner, rationale, unresolved issue, action, owner, due date, dependency, and risk. Do not convert discussion into a decision unless the transcript clearly supports it. List ambiguous items separately.

25. Pre-Mortem

Prompt — Assume It Failed

Assume this initiative failed 12 months after go-live: [initiative]. Generate plausible failure mechanisms across clinical workflow, adoption, technical architecture, data, integration, security, staffing, finance, vendor dependency, regulation, training, governance, and unintended effects. For each, suggest an early warning indicator and mitigation.

26. AI Use-Case Intake

Prompt — AI Risk Triage

Evaluate this proposed AI use case [description]. Identify intended user, population, data inputs, output, action, autonomy, reversibility, PHI/sensitive data, patient-facing impact, clinical decision impact, model dependency, evidence required, potential bias, automation risk, monitoring needs, and conditions that should require formal governance review.

27. AI Model Evaluation

Prompt — AI Evaluation Plan

Build an evaluation plan for [AI system/intended use]. Include dataset representativeness, known-case testing, edge cases, subgroup analysis, accuracy/error taxonomy, calibration if relevant, hallucination/unsupported-claim testing, workflow usability, automation bias, latency, downtime behavior, security/prompt-injection testing, and post-deployment monitoring.

28. AI Output Verifier

Prompt — Verification Checklist

Review this AI-generated output [output]. Do not rewrite it yet. Mark each substantive claim as: supported by supplied evidence, requires external verification, inference, recommendation, or unverifiable from the provided context. Identify fabricated-looking citations, unsupported specificity, missing uncertainty, and clinical/technical claims needing SME review.

29. Downtime Tabletop Facilitator

Prompt — Adversarial Downtime Exercise

Act as a tabletop facilitator for [system/workflow] downtime. Introduce one complication at a time involving identity, interface queueing, device dependency, staffing, communication, external vendor outage, and recovery reconciliation. Do not reveal later complications in advance. After each response, challenge unclear ownership or missing contingency steps.

30. Personal Learning Tutor

Prompt — Teach Me, Then Test Me

Teach me [concept] at a graduate nursing-informatics level using a concrete clinical example first, then explain the mechanism, then show how it connects to the broader system. Keep the lesson visually chunked. End with 4 retrieval questions that require explanation and application rather than memorization. Do not give the answers unless I ask.

A.8 — AI Workflow Cookbook

A prompt is one interaction. A workflow is a repeatable sequence with evidence and checkpoints.

Cookbook 1 — AI-Assisted Requirements Development

1. Gather observation notes, stakeholder interviews, policy constraints, and current-state evidence.
2. Remove or protect sensitive data according to policy.
3. Ask AI to reconstruct needs without proposing solutions.
4. Separate facts, user requests, inferred needs, and assumptions.
5. Generate preliminary requirements.
6. Run the Requirements Red Team prompt.
7. Review with clinical and technical SMEs.
8. Add measurable acceptance criteria.
9. Generate test cases and edge cases.
10. Create traceability from need → requirement → test → approval.

Do not automate: final clinical requirement approval or acceptance of risk.

Cookbook 2 — AI-Assisted Workflow Redesign

1. Observe actual workflow.
2. Build current-state map from evidence.
3. Ask AI to identify burden and failure hypotheses.
4. Validate each hypothesis with staff/data.
5. Define design principles before designing screens.
6. Generate several future-state alternatives.
7. Run a pre-mortem on each alternative.
8. Prototype.
9. Test with representative users.
10. Measure outcomes after deployment.

Do not automate: deciding that a workaround is unnecessary before understanding its function.

Cookbook 3 — AI-Assisted SQL and Analytics

1. Define the clinical question in plain language.
2. Define numerator, denominator, grain, time period, exclusions, and expected known cases.
3. Provide the schema—not patient data unless approved.
4. Ask AI to draft query logic with assumptions.
5. Inspect joins, filters, nulls, duplicates, and timestamps.
6. Run against a development/test dataset.
7. Compare with known cases and independent counts.
8. Document query/version/definition.
9. Have an analyst or appropriate technical owner review high-impact logic.

Do not automate: treating “query executed successfully” as clinical validation.

Cookbook 4 — AI-Assisted Vendor Evaluation

1. Create requirements and weighted decision criteria before demonstrations.
2. Use AI to normalize vendor responses into the same matrix.
3. Flag unsupported “yes” answers and roadmap dependencies.
4. Generate organization-owned demo scenarios.
5. Record evidence from demonstrations.
6. Use AI to identify unresolved gaps.
7. Perform security/privacy/interoperability/legal/financial review separately.
8. Conduct reference checks and proof of concept if needed.
9. Document tradeoffs and decision.

Do not automate: selecting the vendor purely from model-generated scoring.

Cookbook 5 — AI-Assisted Policy/Regulatory Research

1. Identify the jurisdiction, organization type, program, and decision date.
2. Find authoritative primary sources first.
3. Provide or connect those sources to a grounded model.
4. Ask AI to extract requirements with effective dates.
5. Separate final rule, proposal, guidance, and interpretation.
6. Verify every material requirement in the source.
7. Obtain legal/compliance review when needed.
8. Record the “checked as of” date.

Do not automate: asking an ungrounded model “What is the law?” and operationalizing the answer.

Cookbook 6 — AI-Assisted Incident Analysis

1. Establish facts and preserve evidence before AI analysis.
2. Build a verified timeline.
3. De-identify or use an approved secure environment.
4. Ask AI to generate competing causal hypotheses.
5. For each hypothesis, identify required evidence.
6. Test against logs, interviews, configuration, and workflow.
7. Separate contributing factors from root causes.
8. Generate corrective-action alternatives.
9. Evaluate control strength and unintended effects.
10. Monitor whether corrective action actually reduces recurrence.

Cookbook 7 — AI-Assisted Executive Decision Brief

1. Define the decision the executive actually owns.
2. Gather only evidence relevant to that decision.
3. Ask AI to identify tradeoffs and missing assumptions.
4. Draft one-page brief.
5. Challenge it from finance, operations, security, clinical, and patient perspectives.
6. Restore nuance that was compressed too far.
7. Move technical evidence to appendix.
8. Present decision, not an encyclopedia.

Cookbook 8 — AI-Assisted Training Development

1. Define target role and real workflow.
2. Identify decisions/errors that matter.
3. Give AI validated content and screenshots/specifications.
4. Generate scenario-based instruction and retrieval questions.
5. Validate clinically and technically.
6. Test with representative learners.
7. Revise based on errors, not just satisfaction.
8. Update when system behavior changes.

A.9 — Using AI With Documents, Standards, and Research

• Ground the model in the actual document whenever possible. A model should compare the policy you supplied, not reconstruct a policy from generic patterns.

• Ask for source-linked claims. For standards and regulation, require the model to identify the exact source, version, publication/effective date, and section.

• Search primary sources before commentary. For U.S. regulation, use agencies and official rulemaking. For FHIR, use HL7. For security frameworks, use NIST/HHS. For professional standards, use the issuing body.

• Use literature reviews to map evidence, not manufacture consensus. AI can extract study design, population, intervention, outcome, limitations, and findings. Humans should evaluate applicability and methodological quality.

• Beware citation fabrication. If the system cannot retrieve and link the source, assume any detailed citation may be wrong until verified.

Evidence extraction template

Ask AI to produce:

A.10 — AI for Data and Coding Without Becoming a Developer

AI makes technical work more accessible, but it can also make incorrect code look approachable.

Safe pattern

Describe → inspect assumptions → generate → execute in safe environment → test → review → document.

For SQL

Always inspect:

• table grain;
• join type and keys;
• filters;
• date/timestamp meaning;
• null behavior;
• duplicates;
• denominator logic;
• window functions/aggregation;
• known-case results.

For Python/R

Ask the model to:

• explain each transformation;
• preserve a clean raw dataset;
• state package dependencies;
• create reproducible steps;
• include validation checks;
• avoid silently dropping rows;
• label assumptions.

For FHIR/API work

Ask it to:

• identify the FHIR version;
• use the relevant implementation guide/profile;
• distinguish required from optional elements;
• validate example resources against authoritative tooling;
• explain authentication separately from payload design;
• show error handling.

A.11 — AI as a Thinking Partner

The most powerful personal use of AI may be improving how you think rather than how much text you produce.

Red-team your reasoning

“Assume my preferred explanation is wrong. Generate the strongest three alternatives and tell me what evidence would distinguish them.”

Steelman a stakeholder

“Represent the strongest rational case for the stakeholder who opposes this change. Avoid caricature. What risks or incentives could make their position reasonable?”

Expose assumptions

“List the assumptions that must be true for this plan to succeed. Rank them by how uncertain and consequential they are.”

Decision pre-mortem

“It is one year later and this project failed. What plausible mechanisms led to failure, and which early warning signals would we have seen?”

Evidence/inference separator

“Mark each sentence as observed fact, inference, prediction, value judgment, or recommendation.”

Reversibility check

“Which parts of this decision are easy to reverse? Which create lock-in, data migration, contractual dependency, patient expectation, or workflow dependency?”

Missing stakeholder check

“Who bears work, risk, or downstream consequences but is not represented in this decision?”

These prompts are valuable because they reduce premature convergence. AI should not decide for you; it should make the structure of the decision harder to ignore.

A.12 — AI Anti-Patterns for Informaticists

Avoid these habits:

• “Analyze this” without a defined decision. The model will choose its own frame.
• Uploading sensitive data because the vendor is well known. Product terms matter more than brand familiarity.
• Treating summaries as evidence. Summaries inherit errors from source selection and model interpretation.
• Accepting AI-written SQL because it runs. Execution proves syntax, not clinical correctness.
• Using one AI to verify another. Similar models can repeat the same misconception.
• Letting AI create fake workflow detail. If it was not observed or supplied, label it as hypothesis.
• Asking AI to decide what is “clinically appropriate” without context and accountable review.
• Automating high-impact actions before monitoring low-impact recommendations. Increase autonomy gradually.
• Creating hundreds of AI outputs that humans nominally review. Oversight must be operationally feasible.
• Failing to version prompts, retrieval sources, or model changes in production workflows. AI behavior can change even when the user interface looks the same.
• Using model memory as a source of regulation. Verify current authoritative sources.
• Writing policy around one current model name. Govern capability and risk categories so the policy survives vendor change.

A.13 — A Practical AI Governance Checklist

Before production use, answer:

Intended use

• What exact task is AI performing?
• Who uses the output?
• What decision/action follows?
• What is explicitly outside scope?

Data

• What data enter the system?
• Is PHI or confidential information included?
• Where are data stored/processed?
• Are prompts/outputs retained or used for training?

Model/system

• Which model/version?
• Is the model fixed or automatically updated?
• Is RAG used? Which sources?
• Which tools can it call?
• Can it take actions?

Evidence

• How was accuracy/quality measured?
• Are error types clinically meaningful?
• Which populations were represented?
• How does local performance compare?

Workflow

• When is output shown?
• Who reviews it?
• How are missing/failed/uncertain outputs displayed?
• What is the fallback workflow?

Security

• Authentication/authorization?
• Prompt-injection defenses?
• Audit logs?
• Connector/tool permissions?
• Incident response?

Monitoring

• What performance signals are tracked?
• How are complaints and near misses captured?
• How will subgroup effects be monitored?
• What triggers suspension or revalidation?

Lifecycle

• Who owns the use case?
• Who approves changes?
• What happens when the vendor changes the model?
• How is the system retired?

A.14 — Personal AI Operating Rules for the Informaticist

A concise working code:

1. Start with the problem, not the prompt.
2. Give the model evidence; do not ask it to invent organizational facts.
3. Separate fact, inference, and recommendation.
4. Use AI to widen options before narrowing them.
5. Verify in proportion to consequence.
6. Never confuse fluency with truth.
7. Keep PHI and confidential information inside explicitly approved environments.
8. Use authoritative sources for standards, law, and regulation.
9. Treat generated code and calculations as drafts until tested.
10. Preserve human accountability for consequential decisions.
11. Grant agents the minimum tools and permissions needed.
12. Design stop conditions before autonomy.
13. Record important AI-assisted decisions and assumptions.
14. Revalidate when models, prompts, data, or workflow change.
15. Prefer durable reasoning methods over loyalty to one model.

A.15 — Sources and Update Notes

Current model/product sources checked September 15, 2026

• OpenAI. GPT-6 Astra model documentation and launch materials. https://developers.openai.com/api/docs/models and https://openai.com/index/gpt-6-astra/
• OpenAI. GPT-5.6 family launch and model documentation. https://openai.com/index/gpt-5-6/ and https://developers.openai.com/api/docs/models
• OpenAI. HIPAA eligible products and functionality; ChatGPT for Healthcare. https://help.openai.com/en/articles/20001069 and https://help.openai.com/en/articles/20001046-chatgpt-for-healthcare
• Anthropic. Claude Fable 5.1, Opus 5, and Sonnet 5 product documentation and model reports. https://www.anthropic.com/claude/fable and https://www.anthropic.com/transparency
• Google. Gemini 3.8 Flash model documentation and September 2026 release notes. https://ai.google.dev/gemini-api/docs/models and https://ai.google.dev/gemini-api/docs/changelog

Durable governance/evaluation sources

• Tabassi, E. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0) (NIST AI 100-1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.100-1
• Autio, C., Schwartz, R., Dunietz, J., Jain, S., Stanley, M., Tabassi, E., Hall, P., & Roberts, K. (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.600-1
• Assistant Secretary for Technology Policy / Office of the National Coordinator for Health Information Technology. HTI-1 Final Rule: Health Data, Technology, and Interoperability. https://healthit.gov/regulations/hti-rules/hti-1-final-rule/
• U.S. Food and Drug Administration. Artificial Intelligence-Enabled Medical Devices. https://www.fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-enabled-medical-devices
• U.S. Food and Drug Administration. Good Machine Learning Practice for Medical Device Development: Guiding Principles. https://www.fda.gov/medical-devices/software-medical-device-samd/good-machine-learning-practice-medical-device-development-guiding-principles
• National Academy of Medicine. (2025). An Artificial Intelligence Code of Conduct for Health and Medicine: Essential Guidance for Aligned Action. https://nam.edu/our-work/programs/leadership-consortium/health-care-artificial-intelligence-code-of-conduct/

Appendix Takeaway

The informaticist who gains the most from AI will not be the person who memorizes the most prompts. It will be the person who can define the problem, give the model appropriate evidence, recognize where uncertainty enters, verify proportionately to risk, and integrate AI into a governed workflow.

AI can make weak reasoning faster. Nursing informatics must make the reasoning better.