The reassurance: you are not behind. The clinicians who have rushed to integrate AI without understanding what they are using are not ahead of you. They are exposed in ways they may not yet recognize. Thoughtful, late, and competent beats early, fast, and naive, especially in work where the cost of a confident error lands on a person in distress.

The reality: AI is not going away, and “I don’t really use it” will not survive much longer as a professional stance. Documentation tools, patient-facing chatbots, intake assistants, and clinical decision support systems are already arriving through administrative channels, payer requirements, and patient expectations, with or without any individual clinician’s buy-in. As David Cooper puts it in his curriculum on AI integration for clinicians, “The question is no longer whether AI will transform mental health care. It is whether clinicians will lead that transformation or be swept along by it.” ¹

So, this is a beginner’s article. Right now, you don’t need to know about which tool to download or which prompt to copy. The conceptual foundation comes first. Once you understand what these systems are and how they behave, most of the practical decisions about how to use them get easier.

You Don’t Need to Understand the Engineering. You Do Need to Understand the Behavior.

A common point of resistance I hear from clinicians is some version of “I don’t know much about technology.” That’s OK. You don’t need to understand “transformer architecture”, “attention heads”, “embedding vectors”, or “training data curation” to use a large language model (LLM) agent responsibly. You would not expect a primary care physician to understand the chemistry makeup of every medication they prescribe at the level of a pharmacologist. You would expect them to understand the clinically relevant behavior of each drug: its indications, contraindications, interactions, and failure modes.

LLMs are the same. Cooper frames it directly: “You do not need to understand transformer architecture. You do need to understand the five properties of LLMs that directly affect clinical use.”² If you know these five properties, you can reason about almost any new AI tool that crosses your desk. Otherwise, you could be vulnerable to whatever the vendor’s marketing team wants you to believe.

The five properties below are drawn directly from Cooper’s framework, with commentary on what each one means in day-to-day clinical work.

Property 1: Stochastic Output

LLMs generate text probabilistically. “Stochastic” is a technical word for something simple: the output is shaped by probability rather than by a fixed rule, so the same input can produce different responses on different attempts. Think of the difference between a calculator and a weather forecast. A calculator returns the same answer to (7 * 8) every time. A weather forecast gives you a range of likely outcomes that can shift from one run to the next. LLMs behave more like the forecast than the calculator.

As Cooper puts it, “Given the same input, they do not reliably produce the same output. This is unlike a diagnostic checklist, a validated scale, or a treatment protocol.”³ Sometimes the differences between two responses are small wording shifts. Sometimes they are meaningful shifts in clinical content.

The clinical implication is significant. A PHQ-9 produces the same score from the same responses every time. A DSM-5-TR criterion either is or is not met. An LLM asked to summarize the evidence base for a treatment may produce a useful summary on Monday and a different summary on Tuesday, with different studies emphasized, different caveats included, and different framing applied. For any clinical use that requires reproducibility, anything that resembles a measurement, a protocol, or a standardized procedure, this property alone is disqualifying. For uses where some variation is fine or even useful, like brainstorming, drafting, or exploring, it matters much less.

Property 2: Training Cutoff

LLMs are trained on a finite snapshot of text that ends at a particular date. After that date, the model knows nothing, unless it has been connected to tools that let it retrieve live information from the web or a designated database (an architecture often called retrieval-augmented generation, or RAG).

For clinicians, this matters in concrete ways. Cooper points out that “the DSM-5-TR, recent FDA guidance, and emerging treatment protocols may postdate a model’s training.”⁴ A model whose training ended before the DSM-5-TR was released will give you DSM-5 criteria when asked about current diagnostic standards, and it will do so with confidence. The model will rarely volunteer “I don’t know about anything after [date].” More often it will reach for the closest thing in its training data and present it as current.

The practical habit this requires is simple. For anything time-sensitive, check the model’s training cutoff and verify against a primary source. For anything that might have changed in the last two years, assume it has changed and confirm.

Property 3: Hallucination

This is the property most clinicians have heard about and I think the point that clinicians need to internalize. LLMs generate plausible-sounding text, and sometimes that text is wrong. Not partially wrong, not approximately wrong, but confidently and entirely fabricated. A hallucinated citation will have a real-sounding author, a real-sounding journal, a real-sounding year, and a title that fits the topic. The study does not exist. A hallucinated medication interaction will be described in the cadence of pharmacology. It may be real, partially real, or pure fiction.

Cooper does not soften the stakes here: “In clinical contexts, a hallucinated citation, an incorrectly described medication interaction, or a fabricated statistic is not merely embarrassing. It is potentially harmful. Verification is non-negotiable.”⁵ The point is not that LLMs are constantly wrong. On many tasks they perform well. The point is that they offer you no reliable internal signal for when they are wrong. Their confidence and their accuracy are not coupled.

Every clinically consequential claim, every citation, every statistic, every guideline reference, every dosing detail, must be checked against a primary source before it informs your work or reaches a patient.

Property 4: Context Window Dependency

An LLM only knows what is in the current conversation. It does not remember your previous chat unless you paste it back in. It has no access to your prior sessions with a patient. It has no awareness of the way this patient sat down today, the slight delay before they answered a question, the way they looked at the floor when their partner was mentioned. As Cooper observes, LLMs “do not have access to your prior sessions with a patient, your clinical intuition built over years, or the nonverbal data that fills your consulting room. They are, in a meaningful sense, radically decontextualized.”⁶

This is not a limitation to be engineered around. It is a structural feature of what these systems are. It is also, frankly, a reason the irreplaceable parts of your work remain irreplaceable. The AI can help you draft a note about a session. It cannot have the session. I emphasize this for those clinicians who think that 1. Either they will be replaced, or 2. That AI can replace the clinical intuition and skill set that you use minute by minute, on or off the clock. There is no replacement for the experiential wisdom of a clinician.

The practical implication is that the more a task depends on context the AI does not have, like relational history, nonverbal data, cultural attunement, accumulated clinical intuition, the less useful the AI will be, and the more dangerous over-reliance becomes.

Property 5: Sycophancy

LLMs are trained using human feedback, and the humans who provide that feedback tend to reward responses that are helpful, agreeable, and validating. Over millions of examples, this produces a model that leans toward telling you that your framing is good, your question is reasonable, and your tentative conclusion is probably right.

Cooper names the clinical consequence directly: “A poorly framed clinical question tends to produce a confidently wrong answer rather than a productive challenge.”⁷ If you ask an LLM “Is it reasonable to consider that this patient might have borderline personality disorder?” you are more likely to receive a thoughtful exploration of why that consideration is reasonable than a challenge to the framing of the question itself. A skilled consultant might say “Before we go there, what made you reach for that diagnosis rather than, say, complex PTSD?” An LLM is more likely to validate the path you are already on.

The countermeasure is to prompt for disagreement on purpose: to ask the model what is weak about your reasoning, what alternative framings you might be missing, and where its own response might be incorrect. The model will not generally volunteer that information. You have to ask for it. You can also build that into your daily use of a particular agent.

What These Five Properties Add Up To

If you hold these five properties in mind together, a useful picture emerges. LLMs are fast, broadly knowledgeable, and often helpful, and they are also probabilistic, time-bounded, occasionally fabricating, contextually impoverished, and structurally inclined to agree with you. That doesn’t makes them useless; agents can make you a better and more efficient clinician. These properties shape where they belong in clinical work and where they do not. However, in this writer’s humble opinion, there is no replacement for the wisdom of the clinician.

The clinicians who will use these tools well over the next five years are not the ones who are most enthusiastic about them or most skeptical of them. They are the ones who understand, at the level of behavior rather than engineering, what they are working with. That understanding is the prerequisite for everything else: every prompt, every workflow, every ethical decision, every conversation with a patient about if and how AI is part of their care.

1. David Cooper, PsyD, “How do you go from zero to 10x with AI as a therapist? A Competency-Based AI Integration Curriculum for Clinical Practice,” Something Better, March 1, 2025, https://somethingbetter.cc/essays/go-from-0to-10x.

2. Cooper, “How do you go from zero to 10x,” Module 1.2.

3. Cooper, “How do you go from zero to 10x,” Property 1: Stochastic Output.

4. Cooper, “How do you go from zero to 10x,” Property 2: Training Cutoff.

5. Cooper, “How do you go from zero to 10x,” Property 3: Hallucination.

6. Cooper, “How do you go from zero to 10x,” Property 4: Context Window Dependency.

7. Cooper, “How do you go from zero to 10x,” Property 5: Sycophancy.

We have been trying to make EHRs talk to each other for two decades. The HITECH Act poured billions into digitizing records starting in 2009, on the promise that once everything was electronic, the data would flow. It didn’t. We digitized the silos instead of connecting them. Meaningful Use, the Cures Act, information blocking rules, TEFCA, FHIR: each was supposed to be the thing that finally cracked it. And here we are, still watching critical patient data remain behind the boundary between one system and the next.

That track record should tell you something. If twenty years of regulation, funding, and genuinely good technology haven’t solved it, the problem is that it wasn’t really ever purely technical. And it may not be readily solved by people who understand the technology but not the clinical workflow.

We all want it. Can anyone articulate exactly what they need?

Every health system says they want interoperability. It is in every strategy deck and every vendor demo. Connect our systems. Share our data. Make it work together.

Scratch the surface and the picture changes. Ask what data they need to receive and the room gets quiet. Ask what they need to send back out and people look at each other. Ask what clinical problem they are actually solving and you get a mission statement instead of an answer.

This is where EHR interoperability projects die, long before anyone writes code.

This is a clinical product problem, not just a product problem

The issue is that people think that once the problem is vague, you just need a good product manager to come in and define it. Bring in someone sharp, run discovery, write the requirements, ship it.

But EHR interoperability is not a generic product problem. A skilled product manager from fintech or e-commerce can run a flawless discovery process and still produce something dangerous, because the requirements in healthcare are not just business logic. They are clinical, based on clinical workflow and critical data points.

Consider what a non-clinical PM cannot see:

When you map problem list from one system to another, a generic PM treats it as a data field. A clinical PM knows that a reconciled problem list and an active diagnosis list are different things, that the difference can drive the wrong clinical decision, and that the integration has to preserve which one it is.

When a lab result crosses systems, a generic PM moves the value. A clinical PM knows that an INR result without its reference range, critical values, and its collection time is not just incomplete, it is potentially misleading at the point of care.

When you decide which data flows into the EHR versus living in a separate platform, a generic PM optimizes for the cleanest architecture. A clinical PM knows that if the data does not land in the clinician’s actual workflow, at the moment of the decision, it will not get used, no matter how elegant the pipe is.

These are not edge cases. This is the substance of the work. The judgment about what data matters, in what form, at what moment, for what clinical decision, is the whole game. And that judgment does not come from a requirements template. It comes from having stood at the bedside, or having sat with the clinicians who do.

A problem as old as the railroad

The structural pattern is not new. In the mid-1800s, railroads were built on different track widths. Each system worked perfectly within its own territory. The breakdown came at the boundaries, where one line ended and another began. Cargo stopped. Wheels were swapped. Time and money bled out at every handoff.

Nobody had built a broken railroad. They had each built one optimized for themselves, without agreeing on how it would connect to anything else.

EHRs are the same. Epic works beautifully inside Epic. Meditech works inside Meditech. The breakdown happens at the boundary, and twenty years of effort have mostly failed to define what crossing that boundary is actually supposed to accomplish for patient care.

When the gap costs more than money

In the early days of 911, a call that crossed a county line could end up nowhere. The infrastructure existed. The intent existed. People wanted it to work. But each jurisdiction built its own system, and nobody answered the basic questions before the wires went in: what information has to move, which direction does it go, and what does success look like for the person on the other end of that call?

That is still the mistake in EHR interoperability. The technology conversation starts before the clinical problem conversation. And you cannot engineer your way out of a question you never asked, especially when the right question is a clinical one.

The questions a clinical product manager forces onto the table

Before any integration gets a green light, these have to be answered and answered by someone who understands the medicine well enough to know when the answer is wrong.

What clinical problem are you solving? Not a goal, not a vision. A specific breakdown in care or workflow that has a name, a cost, and clinicians who feel it every day.

What data do you need, in what direction, and in what form? Receiving data from an EHR is one conversation. Sending data back in is harder, slower, and more political. Bi-directional exchange is its own category. And the form matters as much as the field: a value without its clinical context can be worse than no value at all.

Do you have the budget for what this actually takes? Not what you think it takes. Custom integration is expensive. Vendor connectors are not as turnkey as they are sold. Every EHR has its own quirks even when everyone claims to speak the same standard. Build in contingency, because something will not work the way the documentation promises.

The honest version

EHR interoperability is solvable. Some organizations do it well. But after twenty years, the pattern is clear: the ones that succeed are not the ones with the best technology or the biggest budget. They are the ones who put someone in the room who understands both the data and the clinical workflow, and who refused to let the build start until the clinical problem was actually defined.

That is the clinical product manager’s job. Not to manage the timeline. To make sure the problem is real, the data is right, the direction is set, and the clinical stakes are understood before anyone opens a single ticket.

The technology has been ready for years. What has been missing is the person who knows what to point it at.

The successful people who make it aren’t the ones with the most certifications. They’re the ones who had people they could ask the basic questions.

That’s what I want this space to be.

I’m opening up Substack Chat as a permanent community space for all Clinically Wired subscribers. Always open, where you can drop a question, share something you’ve learned, or tell us about the move you just made.

Some ways to use it:

• You’re reading a job posting and can’t figure out what “cross-functional stakeholder alignment” would mean in practice. Go ahead and ask.

• You just had a conversation with your manager about moving into IT and it went sideways. Or it went fabulously! Either way tell us what happened.

• You found a resource, a course, a conference, or a contact that helped you. Please share it.

• You’re in a hybrid clinical/IT role and figuring it out in real time. You’re the person someone else would love to hear from.

• You made the jump years ago and wish someone had told you what to expect. 👋 Tell us what you wanted to hear before.

• This is our Community. The whole point of Clinically Wired is that we don’t do this alone. I was empowered to build my career because people opened doors for me. Now I want to open them for you. Perhaps you can open them for each other.

Head to Chat and introduce yourself. Tell us where you are in the journey. Bedside and curious, mid-transition, or already on the other side. I’ll be in there too.

Stand on my shoulders. Then help someone else stand on yours.

— Colleen

Join chat

How to get started

1. Get the Substack app by clicking this link or the button below. New chat threads won’t be sent sent via email, so turn on push notifications so you don’t miss conversation as it happens. You can also access chat on the web.

Get app

2. Open the app and tap the Chat icon. It looks like two bubbles in the bottom bar, and you’ll see a row for my chat inside.

3. That’s it! Jump into my thread to say hi, and if you have any issues, check out Substack’s FAQ.

The Zoom meeting itself also has the meeting video, summary and transcript. Available in Zoom if you attended.

Clinically Wired Office Hours Session 1 Ai Transcribed Notes 04 2026

102KB ∙ PDF file

Download

Download

Clinically Wired Office Hours Session 1 Deck

464KB ∙ PDF file

Download

Download

Thank you to all that attended and those that sent regrets. I value your time and I hope you found it helpful.

We will have our next Session in 2-3 weeks. ‘Decoding the Job Posting’.

I’ll post info here and in the usual places, LI and Slack.

Stand on my Shoulders

I’m hosting my first
Clinically Wired Open Office Hours!
Session 1: From Care Delivery to System Design:
The Shift into Health IT
A live discussion with an open Q&A for clinicians exploring roles in health IT, product, and technology leadership.

Details:
April 2, 7:00 PM Eastern
Zoom session

Registration Link
Capped at 25 participants

AGENDA
• 10 min -- Welcome, short intros, housekeeping rules, who I am and why I'm doing this.
• 10 min -- My story: bedside nurse to SVP of Clinical Product and IT.
• 10 min -- What health IT actually means beyond informatics: the non traditional roles you may not know about about
• 5 min -- The mindset shift: from patient advocate to product owner (you're still advocating, just differently).
• 25 min -- Open Q&A and discussion.

Who should come:
• Any nurses, midlevels, therapists, clinicians curious about IT
• If you’re curious, but not sure where to start this is a good place to begin.

I was building computers before anyone called it a career.

It was the mid-1990s. I was working as an Electrophysiology Nurse at Rhode Island Hospital in Providence, the teaching hospital for Brown University. The Electrophysiology or EP lab is a specialized procedure room for cardiac electrophysiology. Think OR, but instead of a surgeon, you have a cardiologist threading catheters through blood vessels into a beating heart, guided by technology. This sophisticated technology was largely managed by outside vendors.

The technology in that lab was not plug-and-play. We ran 3D electro cardiac mapping systems, that tracked catheter position inside the heart with millimeter precision. We managed multi-channel recording systems capturing intracardiac electrograms simultaneously from a dozen electrode sites. We operated fluoroscopy and imaging equipment, programmers for implantable devices, and hemodynamic monitoring systems. All running in concert, in real time, on a patient whose heart rhythm we were actively manipulating.

At home, I was building my own computers from parts. Not as a side project, but more of a desire. I needed to understand how things worked at the component level. When I brought that same curiosity into the EP lab, something shifted: I taught myself every piece of technology we used. The 3D Intracardiac mapping systems. The rhythm recording equipment. The e-stim catheter technology. Eventually I could troubleshoot and manage the technology without waiting for anyone to fly in.

When something went wrong with the technology in the middle of a case, you didn’t have time to call a vendor. You figured it out. That environment, where the technology is mission-critical, the stakes are the patient on the table, and failure is not an option, is where I learned to think like a technologist.

Then EHRs arrived. And I said yes before I knew what I was agreeing to.

Electronic health records were beginning to take hold across the country. Most clinicians had no framework for what was coming.

An opportunity opened at a critical access hospital where I worked as an ICU nurse. Would I be willing to lead an EHR implementation in New Hampshire? And no, we weren’t starting with the practice EHR, we’d be starting with a ‘Big Bang’, documentation and CPOE (computerized physician order entry). Everything everywhere, all at once.

I was a nurse. No formal IT credentials. No project management certification. No implementation experience. What I had was clinical instincts, a stubborn need to understand systems, and the ability to translate between the language of clinicians and the language of technology.

I said yes.

What followed was eight years at The Memorial Hospital at North Conway, NH — as a department of one in Clinical Informatics. I moved from the floor to operations in the IT department, reporting to the Director of IT. I led strategic planning, implementation, and optimization of their clinical information system and CPOE. Within one year, 90% of a team of 25 physicians were using CPOE. We achieved Meaningful Use attestation in 2011, the first year federal attestation was available.

That one “yes” defined the next twenty years of my career.

Share

The path is not a straight line. Here’s what it actually looked like.

Regional Clinical Informaticist for ten hospitals across Eastern Pennsylvania. Senior Clinical Informatics Consultant, serving as Program Director for the IT transformation of a new hospital tower at UConn Health.

Director of IS Clinical Systems at Albany Medical Center — 60 inpatient clinical systems, 20 analysts and managers, full vendor contracting and budgeting accountability. A $4M Varian ARIA implementation. A $2M bedside barcode lab system that reduced draw errors by 25% in six months.

Then CIO, CHIO, and ISSO at Alliance for Better Health. One of 25 Performing Provider Systems under New York State’s $6.4B DSRIP Medicaid redesign. Alliance served six Capital Region counties, driving value-based contracting and clinically integrated networks across hospitals, community-based organizations, and FQHCs. I also served on the Board of the Health Information Exchange of New York (HIXNY), supporting the data infrastructure behind the effort.

And now SVP of Clinical Product and Technology at a behavioral health startup where I own the full product lifecycle of four proprietary applications, plus others, that power care communication and outcomes across multi-state provider networks.

That means I’m accountable for the entire software development lifecycle. From product strategy and roadmap planning through requirements, development, QA, deployment, and post-launch optimization. I manage vendor relationships, negotiate the SOWs, own the IT budget, and run the help desk operations that keep clinicians working without interruption. I lead regulatory compliance across HIPAA, security posture, and audit readiness; not as a checkbox exercise, but as an operational discipline embedded in every product decision. I drive the clinical go-live strategy for new site rollouts, provider training programs, and system adoption across organizations that didn’t build this technology and need to trust it.

At a startup, there is no “that’s someone else’s department.” The strategic planning, the operational execution, and the clinical accountability all sit in the same chair. Mine.

This is not an informatics role. This is the engineering and product side of health IT — the work most clinicians don’t know exists and almost no one is teaching them how to reach.

None of this was planned. Yet every step was a decision to walk toward the harder thing.

The moment that told me everything about why this work matters.

I was sitting in a focus group. A room full of IT executives. My nameplate in front of me read:

Colleen Russell, MSN, NI-BC Chief Health Information Officer

A male CMIO across the table looked at my nameplate, looked at me, and asked:

“Isn’t that a role reserved for a physician?”

That assumption only exists if you believe healthcare IT leadership follows a medical pecking order.

“Well, sir. I don’t work for a hospital.”

My credentials were on the nameplate in front of him. My title was on the nameplate in front of him. I was sitting at the same table, invited to the same room, for the same reason.

And still, the first instinct was to question whether I belonged there.

This is not a rare experience. This is Tuesday in healthcare IT for women in technical leadership. And it is exactly why I am building what I am building. Because you deserve to walk into those rooms prepared, confident, and armed with a response that is calm, direct, and entirely unapologetic.

Why I’m building this now.

There is almost no structured pathway for clinicians who want to move into the engineering and product side of health IT — product management, software strategy, vendor leadership, technical IT operations, and executive accountability. Not informatics certification prep. This is about working inside the IT department. Understanding the engineering, the product development, the operations, and the cross-channel between clinical and technology across the entire organization.

I’m building Clinically Wired for the clinician who is already the go-to tech person on the unit and doesn’t know there’s a career waiting for them. For the clinical analyst who wants to move into product management but can’t find the on-ramp. For the woman in an IT leadership role who is doing the work and still being asked whether she belongs there.

I still had to figure out most of it on my own. You don’t have to.

If any part of this resonates, please subscribe. I’m building this for you.

I didn’t get here alone — but I had to climb without a map.

Stand on my shoulders. Then offer yours to the next woman up.

— Colleen Russell, MSN, NI-BC

SVP of Clinical Product and Technology | Founder, Clinically Wired | 30-Year Nurse | 20-Year HIT Executive

Subscribe now