A hospitalist is staring at a number. The EHR has just surfaced a risk score for the patient in bed 12: "deterioration risk, high." It is asking her, in effect, to move this patient up the queue, to call a rapid response, to change her night. And a question forms that until recently she had no real way to answer: where did this number come from, who did it learn from, and does that population look anything like the frail, dialysis-dependent, non-English-speaking patient actually in the bed? For years the honest answer was a shrug. The AI was a black box bolted into the chart, and you either trusted it or you did not. The ONC HTI-1 rule is the reason that shrug is no longer acceptable, and the reason she now has a right to look under the hood.

What ONC and HTI-1 Actually Are

Start with the players, because the acronyms hide a simple idea. ONC is the Office of the National Coordinator for Health Information Technology, the federal body that, among other things, runs the certification program for electronic health records. Certification matters because it is effectively the gate: to be used for federal programs and to be marketable to hospitals, an EHR generally has to be ONC-certified, meeting a defined set of capability and transparency criteria. ONC does not regulate you, the clinician; it regulates the software you are handed. That is the lever HTI-1 pulls.

It helps to say plainly what ONC is not. It is not the FDA, and it is not a licensing board. The FDA looks at an algorithm the way it looks at an infusion pump or a stent: as a medical device with an intended use, a risk classification, and a clearance pathway. ONC looks at the electronic health record as a whole system: does it exchange data the way it is supposed to, does it protect the record, and, since HTI-1, does it disclose what a clinician needs to know about the decision support riding inside it. A single predictive tool can therefore sit inside two separate accountability structures at once, one federal agency asking whether the algorithm is a safe device for its stated purpose, another asking whether the certified software delivering it to your screen discloses enough for you to judge that purpose yourself. Neither agency licenses you, and neither one absorbs your professional judgment. That separation is worth holding onto, because it explains why a tool can be both FDA-cleared and still risky to trust blindly at 2 a.m. on a patient who does not resemble the tool's training population.

HTI-1 stands for the Health Data, Technology, and Interoperability rule, the first in a planned series. Its final version reshaped what a certified EHR must do when it puts decision support in front of a clinician, and in particular what it must disclose when that decision support is powered by AI. The rule did not appear from nowhere: it responds directly to the problem our hospitalist felt, that predictive algorithms had been quietly embedded in the record with no consistent way for the people relying on them to know how they were built, whom they were tested on, or where they should not be trusted. HTI-1 is, at its heart, a transparency rule aimed at exactly that gap.

Picture the years before this rule existed. A vendor would sell a hospital a "deterioration index" or a "sepsis probability" module as a line item in a broader EHR contract, a feature bundled in with order sets and billing tools, no different in the sales conversation from a new flowsheet. The nurse manager who approved the purchase might never have seen a validation study. The bedside nurse who watched the score update every four hours had no way to ask what population it was built on, and often did not know that was a question worth asking at all. The number simply appeared, colored red or green, and clinical culture did the rest: a red number on a screen looks like a fact, not a claim. HTI-1 exists because that gap between "looks like a fact" and "is actually a claim with a known and limited scope" had become wide enough to hurt people.

From CDS to DSI, and the Birth of Predictive DSI

The first thing HTI-1 did was rename a familiar concept. For decades clinicians have lived with Clinical Decision Support, or CDS: the drug-interaction alert, the dosing calculator, the best-practice reminder. HTI-1 retired that label in the certification world and replaced it with Decision Support Intervention, or DSI. The change is more than cosmetic. The word intervention is deliberate: it frames these tools as things that act on care, that intervene in a decision, and therefore deserve scrutiny proportional to that influence.

Think about what "proportional to influence" means in a busy emergency department. A best-practice reminder that fires when a discharge order is missing a follow-up appointment is a DSI, but a low-stakes one; if the clinician ignores it, a patient misses a callback, which is bad but recoverable and visible. Compare that to a sepsis-prediction score that quietly raises or lowers a triage priority, or a readmission-risk number that determines whether a case manager calls a patient at all before discharge. Both are technically "decision support," but one shapes a scheduling nudge and the other shapes whether a sick patient gets seen sooner or a fragile one gets a phone call that might have caught a problem early. HTI-1's language of intervention is trying to make sure the second kind of tool cannot hide inside the same shrug clinicians give the first kind.

Within DSI, the rule then carved out a crucial new category: the Predictive Decision Support Intervention, or Predictive DSI (sometimes written PDSI). This is the category that captures AI and machine-learning tools, the ones that generate a prediction, a probability, a risk score, or a classification rather than firing a simple rule someone wrote by hand. The distinction matters enormously. A hard-coded rule ("warn if creatinine over X") is fully inspectable; anyone can read the logic. A predictive model learned its behavior from data, and its logic is not a sentence you can read but a pattern absorbed from a training population. That is precisely why it needs a different, stronger form of transparency, and that is what Predictive DSI was created to demand.

Make the contrast concrete. A creatinine-threshold alert is a sentence: if the lab value crosses a line, fire a warning. A pharmacist reviewing that alert can trace the exact condition that triggered it in about five seconds, and can just as easily see when it is a nuisance alert firing on a chronically elevated baseline. A predictive deterioration score, by contrast, might weigh vital-sign trends, lab trajectories, nursing flowsheet entries, and a dozen other variables in a way that no single sentence describes. Ask the vendor "why did this score go from 0.2 to 0.7 in the last hour" and you will rarely get a plain-English answer, because the model itself does not reason in plain English; it reasons in weighted patterns learned from thousands of prior patients. That opacity is not a defect to be embarrassed about, it is simply the nature of a learned model, but it is exactly why the rule treats Predictive DSI as its own category requiring its own disclosure obligations, rather than folding it quietly into the same bucket as the creatinine alert.

The Source Attributes: A Nutrition Label for the Algorithm

Here is the centerpiece, the part every clinician should know by name. For certified Predictive DSI, HTI-1 requires the technology to make available a standardized set of facts called source attributes. The most useful way to picture them is as a nutrition label for the algorithm: just as a food label discloses in a consistent format what is inside, the source attributes disclose, in a consistent format, what is inside a predictive tool and how it was made.

The source attributes cover the things a thoughtful clinician would actually want to know before trusting a score. Among them: what the intervention is intended to do and for whom (its purpose and intended use); who developed it; what data it was developed and trained on; how it was validated and how well it performed; what is known about its fairness across groups and the risk of bias; how it should be used and, critically, where it may not apply. That last piece is the one clinicians most often miss and most need. A risk model validated on a general adult inpatient population may carry an explicit note that it was not validated in pregnancy, or in pediatrics, or in a particular racial or ethnic distribution, and the source attributes are where that limit is supposed to live.

Consider how this reads in practice, laid out the way a source attribute page typically presents it, so the abstraction becomes a document you can imagine actually opening.

None of these rows is exotic. Every one of them is a question a careful clinician already asks about a new drug or a new device before trusting it on a patient; the difference is that for a predictive algorithm, before HTI-1, there was no consistent place those answers were required to live, and no consistent format for finding them. A clinician might have had to email a vendor, wait a week, and receive a marketing deck instead of a validation summary. The source attributes exist so that the six rows above are not a research project, they are a lookup.

The source attributes are your right to look under the hood. They exist to let you answer one question at the bedside: does this prediction actually apply to my patient?

Understand what this changes. Before, the burden was on the clinician to somehow intuit whether a black-box score was trustworthy for a given patient, with almost no information to go on. HTI-1 shifts part of that burden onto the technology: a certified tool must surface the facts that let you make that judgment. It does not make the judgment for you, and it does not guarantee the model is good. It guarantees you can find out how the model was made and where it breaks. That is a profound and practical change in the clinician's relationship to AI, and it is the single most important thing to take from this lesson.

It is also worth being honest about the limits of this change. A source attribute disclosure is not automatically written in language a bedside nurse or a busy hospitalist finds easy to parse in ninety seconds between patients. Some are dense, written by informatics and regulatory staff for other informatics and regulatory staff. Part of the skill this lesson is teaching is not just knowing the six categories above exist, but knowing to push your own organization to translate them: ask your informatics team or CMIO to produce a one-page, plain-language version of the source attributes for every predictive tool live in your EHR, so the limitations row is something a nurse on a busy shift can actually glance at rather than something buried three clicks deep in a settings menu nobody opens.

Intervention Risk Management and Real-World Testing

Transparency alone is not enough, and HTI-1 knows it. The rule pairs the source attributes with two further obligations on certified developers that a clinician should recognize because they shape how safe the tool actually is in practice.

The first is Intervention Risk Management, or IRM. Developers of certified Predictive DSI must have practices to manage the risks their tools create: identifying potential harms, assessing fairness and validity, and mitigating what they find, across the life of the product rather than once at launch. IRM is the developer-side discipline that acknowledges a predictive model is not a static object; it can degrade, it can behave unexpectedly on new populations, and someone must be actively watching for that. When you hear that a tool has documented IRM practices, it means the developer is on record about how they surface and handle the model's dangers, not just its features.

Walk through what IRM looks like when it is working. A sepsis-prediction model goes live at a 400-bed hospital. Under a genuine IRM program, the developer does not simply ship the model and move on to the next customer. They monitor its alert rate and its outcomes across each new deployment, watching for signs the model is firing too often (alert fatigue, the nurses start ignoring it) or too rarely (missed cases, a false sense of security). Six months in, monitoring shows the model's false-positive rate has crept up on a unit that recently changed its charting workflow, a subtle shift in how vital signs get documented that the model was never trained to expect. A developer with real IRM catches that drift, investigates it, and either retrains the model, adjusts the threshold for that unit, or flags the issue to every hospital running the tool. A developer without IRM simply does not notice, and the score keeps firing on data it was never built to interpret, looking exactly as confident as it did on day one.

The second is real-world testing. Certification is not meant to be a one-time laboratory event; certified health IT is expected to be tested in the actual conditions of use and to maintain its capabilities over time. This is the regulatory cousin of a theme that runs through this whole program: a tool that performed well in a controlled study can still fail in the messy reality of your clinic, and someone has to keep checking. Real-world testing pushes that checking into the certification framework itself, so that "it passed once" cannot masquerade as "it works now."

The reason this matters so much in practice is a phenomenon informaticists call model drift: the slow, often invisible process by which a model's performance degrades as the real world moves away from the conditions it was trained under. A readmission model trained before a hospital adopted a new discharge-planning protocol may quietly lose accuracy once that protocol changes who gets readmitted and why, with nobody deciding to break the model, the world around it simply changed. Real-world testing is the mechanism meant to catch that kind of silent decay before it becomes a pattern of missed or misdirected care, rather than after a chart review finds it.

It helps to see how these three pieces fit together, because they are designed to reinforce each other rather than stand alone. The source attributes give the clinician visibility into how a tool was built and where it applies. Intervention Risk Management gives the developer an ongoing obligation to hunt for and fix the tool's dangers, including the bias and validity problems that source attributes might reveal. Real-world testing keeps the whole arrangement honest by demanding evidence that the tool still performs where it is actually used, not just where it was born. Take any one away and the other two weaken: transparency without ongoing risk management is a snapshot that goes stale; risk management without transparency is a private process the clinician cannot see; and either one without real-world testing is a promise that nothing has drifted. Read together, they describe a tool that is disclosed, actively watched, and continually re-checked, which is roughly what a clinician should want from any algorithm allowed to influence care.

The Timeline, USCDI, and What Comes Next

These obligations are not aspirational; they came with hard dates. Certified health IT had to meet the new DSI certification criteria by December 31, 2024, with ongoing maintenance of certification required from January 1, 2025. In practice this means that if your organization runs a certified EHR, the Predictive DSI transparency machinery has been a live requirement since the start of 2025, not a future promise. The rule also advanced interoperability foundations, setting the United States Core Data for Interoperability version 3 (USCDI v3) as the baseline by January 1, 2026, which standardizes the core data elements that must move between systems. You do not need to memorize USCDI, but you should know it is the shared vocabulary of data that makes consistent, comparable information (including the information feeding predictive tools) possible across the ecosystem.

Finally, HTI-1 is explicitly the first chapter. A follow-on rule, HTI-2, is in development and is expected to extend and refine these requirements. The direction of travel is clear and worth internalizing: transparency about clinical AI is not a passing compliance fad but an expanding, durable expectation. The clinician who learns to read source attributes now is learning a skill that the regulatory environment is actively building the rest of the system around.

It is worth being precise about who these dates bind, because the point is easy to misread. HTI-1 places its obligations on the developers of certified health IT, not on you at the bedside. You are not personally required to file anything or to certify a model. What the timeline means for you is subtler and more useful: since the start of 2025, if your organization runs a certified EHR, the vendor has been on the hook to make source attributes available for its Predictive DSI. That converts what used to be a polite request ("could you tell us how this model was built?") into an expectation the technology is supposed to meet. When you or your informatics team go looking for a tool's source attributes and cannot find them, you are not asking for a favor; you are asking for something the certification framework says should be there. Knowing the dates, in other words, is less about compliance and more about knowing what you are entitled to expect and when that entitlement began.

Picture two versions of the same conversation, a year apart, to see the practical difference the dates make. In early 2024, a nurse informaticist asks a vendor's account manager why a new fall-risk model flags certain patients and not others. The answer is a shrug wrapped in reassurance: "our algorithm is proprietary, but it's very accurate." There is no obligation forcing a fuller answer, and the informaticist has no lever to pull. In 2026, that same question is asked of a certified Predictive DSI, and the answer has to be backed by a document: the intended use, the development population, the validation numbers, the known limitations. The tone of the vendor conversation has not necessarily gotten friendlier, but the informaticist now has something to point to, a certification requirement rather than a request for goodwill. That is the practical weight of "December 31, 2024" and "January 1, 2025" as dates: they mark the line after which the shrug stopped being an acceptable answer for a certified tool.

A Worked Example: Using the Source Attributes

Return to our hospitalist, whose name for this exercise is Dr. Alvarez, and the deterioration score on bed 12, and watch the source attributes turn a shrug into a decision. Before HTI-1, she had two bad options: defer to the score she could not interrogate, or ignore a tool that might be right, both of them guesses. Now she opens the tool's disclosed information and reads.

She finds the intended use: the model predicts clinical deterioration in adult medical-surgical inpatients within 24 hours. She finds the development data: it was trained and validated on inpatients from a set of academic hospitals over a defined period. She finds the performance summary and, crucially, the limitations: the model was not validated in patients on chronic dialysis, and its performance in populations with limited English proficiency was not separately established. Her patient is on chronic dialysis and speaks limited English. In thirty seconds, the source attributes have told her something decisive: this is a tool operating at the edge of, or outside, its validated envelope for this specific patient. The score is not worthless, but it is not the confident verdict the red "high" made it look like.

Picture the charge nurse leaning into the workroom right about now, asking the question every hospitalist has heard a hundred times: "Are we calling rapid response on bed 12 or not?" Before HTI-1, Dr. Alvarez's honest answer would have been built entirely on gut feeling and a red flag she could not interrogate. Now she has something better to say: "The score flags high, but it was never validated in dialysis patients, and that's exactly what he is. I'm going to reassess him myself in the next ten minutes and decide off that, not off the number alone." That sentence, spoken out loud to a colleague, is the entire value of the source attributes compressed into one moment of clinical communication. It is also, not incidentally, exactly the kind of sentence that turns into a strong SBAR handoff and a defensible note.

Watch what she does with that. She does not blindly escalate on a score she now knows may not apply, and she does not blindly dismiss it either. She weighs it as one input, notes to herself that the model is outside its validated population here, and leans harder on her own bedside assessment and the patient's actual trajectory to decide about escalation. She walks to bed 12, rechecks his vitals trend herself, asks him through the hospital's interpreter line how he is feeling compared with this morning, and looks at his most recent labs with her own eyes rather than through the model's summary of them. If she does escalate, and if it matters later, her reasoning is defensible: she can say she saw the score, checked where it applied, recognized her patient sat outside its validated range, and made a clinical judgment accordingly, and she can point to the specific bedside findings that drove her final call. That short chain of reasoning, made possible entirely by the source attributes, is the difference between a clinician operating a tool and a clinician operated by one. The transparency did not replace her judgment; it armed it.

Contrast that with the version of this shift that goes wrong. Imagine a different hospitalist on a different night, equally busy, who sees the same red "high," never opens the source attributes at all, and simply calls the rapid response because the screen told her to. Nothing in HTI-1 stops that from happening; the rule creates the information, it does not force anyone to read it. If that patient turns out fine and the rapid response was unnecessary, the cost is a burned-out team and an unnecessary escalation. If, in a different case, the same reflexive trust leads a clinician to under-react because a score reads reassuringly low in a population it was never built to assess, the cost can be a missed deterioration. The rule handed clinicians a tool for verification; it is still each clinician's job to actually pick that tool up.

Now flip the case to see the other half of the value. Suppose the source attributes had instead shown that the model was developed and validated on a population closely matching her patient, with strong reported performance and no relevant exclusion. The same red "high" now means something different and stronger, and she can act on it with more confidence, still verifying against the bedside, but with real justification for taking it seriously. The source attributes do not always tell you to distrust the tool. They tell you how much trust the tool has earned for this patient, which is exactly the calibration good clinical AI use requires.

This calibration is not a one-time skill you learn and then forget; it is a habit that has to survive a busy shift, a short-staffed unit, and the fourteenth alert of the day. The realistic failure mode for an experienced clinician is not ignorance, it is fatigue: knowing exactly how to check a source attribute in principle, and simply not doing it on patient nine of fourteen because the shift is drowning. That is precisely why building the habit of checking the limitations section, specifically, rather than reading the whole document every time, matters: it is the fastest single check that catches the highest proportion of dangerous mismatches, and it is realistic to do even on a hard night.

What to Do With This as a Clinician

You do not need to become an informaticist to benefit from HTI-1, but you should change three habits. First, when a certified tool surfaces a prediction that will influence care, remember that you now have a right to its source attributes, and learn where your EHR exposes them. The mere knowledge that this information is supposed to exist changes how you relate to the number; you stop treating it as an oracle and start treating it as a claim with a provenance you can check. Second, make the limitations section your first stop. The most valuable line in a source attribute is often the one that says where the model does not apply, because that is precisely where an over-trusted score does its damage. Third, carry this into governance: if your organization deploys a predictive tool and cannot produce its source attributes, that is a question worth raising, because the whole point of the rule is that those facts should be available to the people relying on the tool.

The deeper point is that HTI-1 is not really about compliance paperwork. It is the regulatory expression of the same principle this entire program is built on: a prediction touching a patient must be verifiable, and "the model said so" is not verification. The source attributes are the mechanism that makes verification possible for a black-box tool you could not otherwise inspect. They put the clinician back in the loop with actual information, which is where a licensed, accountable human belongs. Learn to read them, and you turn a mysterious number into a claim you can evaluate, which is the whole of the skill.

Key Takeaways

• ONC certifies the EHRs you use; the HTI-1 final rule reshaped what a certified system must disclose about AI-driven decision support, shifting part of the transparency burden from the clinician onto the technology.
• HTI-1 renamed Clinical Decision Support (CDS) to Decision Support Intervention (DSI) and created the Predictive DSI category for AI/ML tools that generate predictions, probabilities, risk scores, or classifications.
• A predictive model needs stronger transparency than a hard-coded rule because it learned its behavior from a training population rather than from logic you can simply read.
• The centerpiece is the source attributes: a standardized, nutrition-label-style set of facts a certified Predictive DSI must disclose about its purpose, developer, training data, validation and performance, fairness and bias, and, critically, where it may not apply.
• The source attributes are your right to look under the hood, existing to answer one bedside question: does this prediction actually apply to my patient? The limitations section is often the most valuable line.
• HTI-1 pairs transparency with Intervention Risk Management (developer practices to identify and mitigate a tool's risks over its life) and real-world testing (so a tool that passed once must keep proving it works).
• The timeline is live: DSI criteria had to be met by December 31, 2024, with maintenance of certification from January 1, 2025, and USCDI v3 as the baseline by January 1, 2026; HTI-2 is in development, so this transparency expectation is expanding, not fading.
• Source attributes do not make the judgment for you and do not guarantee a good model; they tell you how much trust the tool has earned for this patient, arming your judgment rather than replacing it.