Mostly about building products, healthcare tech, and lessons learned along the way.
Loading articles
HTI-5 Drops the AI Model Card From Decision Support. Ship Your Own. — Clint Johnson
HTI-5 Drops the AI Model Card From Decision Support. Ship Your Own.
HTI-5 would drop the 31 model card attributes from decision support. Ship them yourself: a versioned model card, CDS Hooks links, Provenance, local validation.
HTI-5 is a proposal that keeps §170.315(b)(11) but deletes the source attributes, user access to and modification of them, and predictive-DSI risk management.
Third-party CDS tools were never required to publish source attributes under HTI-1. HTI-5 removes the EHR's place for them, not a duty on the builder.
Ship transparency as code: a versioned model card, card.source and links on CDS Hooks cards, matching Provenance on write-backs, and a validation harness the hospital reruns.
Questions people ask
Does HTI-5 remove the decision support interventions criterion?
No. The proposed rule keeps and revises §170.315(b)(11). It deletes the source attributes, user access to and modification of them, and predictive-DSI risk management. The legacy CDS criterion (a)(9) is the one removed entirely.
Were third-party CDS Hooks apps required to publish source attributes under HTI-1?
No. HTI-1 made certified developers responsible only for the predictive DSIs they supplied themselves. The certified EHR had to let users access and modify source-attribute information, and HTI-5 would remove that.
Where should a model card link go in a CDS Hooks card?
Put the versioned model card URL in card.source.url, which the spec reserves for the organization or data set behind the card, and put the version in source.label. Per-patient explanations belong in card.links, because source.url should not be used for a context-specific drill-down.
Is the HTI-5 final rule published?
The proposed rule was published December 29, 2025, and comments closed February 27, 2026. Pacific AI reported an August 2026 target, but no published final rule had been found when the article was written, so check the Federal Register.
The AI model card was a good idea in the wrong place. HTI-5 would take it out of certified EHRs. Anyone building clinical AI should ship it anyway, from their own service, as code they can test.
I build clinician-facing AI, and I've spent months getting CDS Hooks working in Epic. Read closely, this rule changes less for third-party builders than the headlines say. It changes more for the hospitals that buy from us.
Here's what I'd ship. Serve one versioned model card per model version from the CDS service. Link to it from every CDS Hooks card. Attach Provenance that names the same version to every write-back. Give the hospital a harness it can rerun on its own patients. None of it depends on what ONC finalizes.
What HTI-5 changes in decision support interventions
HHS released the HTI-5 proposed rule on December 22, 2025, and published it in the Federal Register on December 29. Comments closed February 27, 2026. Pacific AI reports that the 2026 Unified Agenda targeted a final rule for August 2026, and notes those dates have no legal force and often slip. I couldn't find a published final rule when I wrote this. Check the Federal Register before you plan around one.
Read the proposed rule text, not the headlines. Some coverage says the decision support interventions criterion is "removed." It isn't. ONC keeps §170.315(b)(11), revises it, and deletes four pieces:
(b)(11)(iv): the source attributes themselves
(b)(11)(v)(A): user access to them
(b)(11)(v)(B): user modification of them
(b)(11)(vi): predictive-DSI risk management
It also narrows what counts as a predictive DSI. HTI-1 covered models using "any data" in USCDI. HTI-5 would limit that to the data in (b)(11)(iii)(A) plus the Clinical Notes and Assessment and Plan of Treatment data classes. The legacy CDS criterion, (a)(9), is the one removed outright.
Here's the part most coverage gets wrong. Under HTI-1, certified developers were responsible only for the predictive DSIs they supplied themselves. A third-party CDS Hooks service or SMART app was never required to publish source attributes. The certified EHR had to let users access and modify source-attribute information. So HTI-5 puts no new duty on you. It removes the EHR screen where your attributes would have lived.
ONC is right about usage and wrong about value
ONC's justification is blunt. It has "no publicly available evidence indicating that a single doctor, nurse, or administrator has accessed, recorded, or modified a single source attribute" since certified (b)(11) modules began deploying in early 2025. It also has no public evidence that the requirements led anyone to pull a deficient algorithm or to test "a deployed algorithm on local data." HTI-1's impact analysis estimated up to $3 billion in 10-year sepsis-detection savings from this transparency. ONC now says those benefits "are not being realized."
Now the cost. 232 products from 183 developers were certified to (b)(11). HTI-1 estimated 2,200 to 4,600 hours to implement the criterion, plus up to 1,085 hours a year to keep source attributes current.
I believe the usage finding. I don't believe the information is worthless. A model card buried in an EHR configuration screen is a compliance artifact. Nobody opens it at 2 a.m. when a sepsis alert fires. The fix isn't to delete the information. Put it next to the prediction, in a form the hospital's informatics team can test.
Hospitals will still ask. Answer once.
ACA Section 1557, at 45 CFR §92.210, requires covered entities to make reasonable efforts to identify patient care decision support tools that use race, color, national origin, sex, age or disability as inputs, and to mitigate the discrimination risk. Those duties started May 1, 2025. Pacific AI notes that OCR guidance points covered entities to request this information from developers. It expects each hospital's AI governance committee to ask each vendor separately, in its own template.
That's the real cost of HTI-5 for builders. You'll answer the same questions in a different spreadsheet for every customer, and every copy will drift from the model you actually deployed. A stale answer about input features is worse than no answer. Publish once, version it, and link to it from everything.
How to serve a versioned AI model card endpoint
Serve the card from your CDS service at a URL that includes the version. Each version gets one immutable document. A new model gets a new URL.
The nine HTI-1 groups map onto a JSON shape. Placeholders teach nothing, so here's a filled example for a hypothetical readmission model. Every value is made up to show what a usable answer looks like:
{"model":"readmission-risk","version":"2.3.1","details":{"developer":"Example Health AI","contact":"models@example.com","outputType":"prediction","output":"30-day all-cause readmission probability, 0-1"},"purpose":{"intendedUse":"Flag adult inpatients for discharge-planning review","population":"Adults 18+ discharged from medical-surgical units","users":["case managers","discharge nurses"],"role":"informs"},"outOfScope":
Notice age and sex in inputFeatures. That's the §92.210 question, answered in a field a script can read instead of a paragraph a lawyer has to parse. The runBy field matters too. Validation by the builder and validation by someone else are different claims.
Three rules make this worth more than a PDF:
List input features explicitly. Don't write "demographic variables may be used." Name them.
Make it a contract test. CI fails if the deployed model version has no card, or if the card's inputFeatures don't match what the model consumes. The test is three lines, at the top of the harness below.
Every number links to the run that produced it. If a metric has no run URL, someone typed it into a doc, and nobody can reproduce it.
card.source is required. Its url is meant for the organization or data set behind the card, and the spec says it "should not be used to supply a context-specific drill-down." A versioned model card fits that. Per-patient explanations don't, so they go in card.links as "type": "absolute". If the explanation view is a SMART app, use "type": "smart" and pass context through appContext.
Put the version in source.label too, as in Readmission Risk v2.3.1. The label is required anyway, and it costs nothing to make it specific. A full card is in the next section, next to the Provenance it has to agree with.
Plan around two gaps. First, the discovery endpoint at /cds-services has no model-version or model-card field. Carry the version in an extension, or make the model card endpoint the source of truth. usageRequirements is human-readable, so a version there is for people, not parsers.
Second, always send uuid. The feedback endpoint at /cds-services/{id}/feedback lets the EHR post whether a card was accepted, overridden or ignored, keyed by that uuid. The spec makes service support optional. Support it anyway. It's the cheapest post-deployment monitoring signal you'll get.
How to attach FHIR Provenance to AI output written to the chart
If your tool writes anything back, such as a RiskAssessment, a drafted note or a flag, attach a Provenance resource that names the model version.
HL7's AI Transparency on FHIR IG describes two mechanisms. One is a lightweight AIAST ("AI asserted") security label in meta.security. The other is a full Provenance that references the AI as a Device, with the model card wrapped in a profiled DocumentReference. The IG doesn't force a card format. Hugging Face YAML-fronted Markdown and the CHAI schema both work.
The IG is still at ballot stage. Whether the label is required alongside Provenance was still unresolved, so don't treat its details as settled. Provenance itself is base FHIR R4, so you can ship it now. Check the AIAST code system against the current IG build before you lock it in.
Here's the card the clinician sees and the Provenance on what the tool writes back:
// CDS Hooks card returned by the service
{
"uuid": "6f1c2e9a-4b7d-4f1e-9a2c-3d5e8b7a1c04",
"summary": "Readmission risk: high (0.41)",
"indicator": "warning",
"source": {
"label": "Readmission Risk v2.3.1",
"url": "https://cds.example.com/model-cards/readmission-risk/2.3.1"
},
"links": [{ "label": "Why this score", "type": "absolute",
"url": "https://cds.example.com/explain/6f1c2e9a-4b7d-4f1e-9a2c-3d5e8b7a1c04" }]
}
// Provenance written with the RiskAssessment
{
"resourceType": "Provenance",
"target": [{ "reference": "RiskAssessment/ra-8812" }],
"occurredDateTime": "2026-10-20T14:02:11Z",
"recorded": "2026-10-20T14:02:12Z",
"reason": [{ "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/v3-ObservationValue",
"code": "AIAST" }] }],
"agent": [{ "who": { "reference": "Device/readmission-risk-2.3.1" } }]
}
The point is agreement. source.label, source.url and the Device all name 2.3.1, and the Device points at the same model card the card links to. The chart, the card and the card's source all say which model produced what. That's the audit trail a governance committee will want. For keeping a model's FHIR access narrow in the first place, see The Best FHIR MCP Server Gives the Model No FHIR Tools.
How to validate a clinical AI model on local hospital data
Remember ONC's finding that nobody tested deployed algorithms locally. Four of the 31 attributes covered exactly that: validity monitoring, validity in local data, fairness monitoring and fairness in local data. A paragraph from the vendor can't answer them. Only the hospital's data can. So ship the hospital a test, not a claim.
import json, numpy as np
from sklearn.metrics import roc_auc_score, brier_score_loss
# CI contract test: the card must describe the model actually deployed.deftest_card_matches_model(card_path, model): card = json.load(open(card_path))assert card["version"]== model.version
assertset(card["training"]["inputFeatures"])==set(model.feature_names)# Population stability index: how far today's scores moved from the reference.defpsi(ref, cur, bins=10): edges npquantileref nplinspace bins
The input is the hospital's labeled cohort, flattened from a FHIR export into one row per patient. The output uses the same metric names as the card's performance.metrics, so the hospital's numbers line up against yours row by row.
AUROC tells you whether the model still ranks patients correctly. Brier tells you whether the probabilities still mean what they say. A model can keep its AUROC and lose its calibration, and a 0.41 that should be 0.20 sends case managers to the wrong patients. Always report n. A subgroup AUROC on 40 patients is a rumor.
There's no universal drift cutoff. Pick a PSI threshold, write it in the card (the example uses 0.2), and alert on it. Pair it with the override rate from the feedback endpoint. Outcome labels take weeks to arrive. A rising override rate on one unit shows up much sooner.
Then point localResultsUrl at the site's latest run, not your benchmark. If the hospital can't reproduce your numbers on its data, find out before go-live. It's the same discipline as any eval harness: label a small set, compare against it, rerun on every change.
The model card attributes I'd keep with no rule at all
ONC's case for deletion is that the attributes didn't lead anyone to pull a bad algorithm or test one locally. Those were the right goals. Most of the 31 attributes don't serve them. Four groups do, and I'd put them on every card whether a rule requires them or not:
Intended use and decision-making role. Does the model inform, augment or replace clinical management? If you can't answer that in one word, you're not ready to ship.
Out-of-scope uses and known risks. These are the populations and settings where the model shouldn't be trusted. This field is the most likely to stop misuse, and it's the one vendors most like to leave vague.
External validation, including who ran it. Say whether you have validation by your own team or by someone else.
Validity and fairness on local data. They're the only numbers that describe the patients in front of the clinician.
Funding source and prose about training-data relevance can stay in your docs. The four above go next to the prediction.
