Should systemAction carry an optional field for a checkable pre-execution artifact?

[babyblueviper1]

Question: does systemAction need a standard field for a verifiable pre-execution check?

The 2.0 spec defines systemAction as an Action "not presented to the user within a card, but rather may be auto-applied without user intervention," and leaves the decision to auto-apply entirely to the CDS Client — no guidance on audit trail, logging, or a verification step before an action is applied unreviewed.

Concrete failure mode this leaves open: a CDS Service returns a systemAction that auto-applies (e.g. auto-orders a lab, auto-updates a problem list) based on a bad prefetch, a stale FHIR resource, or a service bug. Because there's no standard place to attach why the system believed the action was safe to auto-apply, or a signed record checkable by a later auditor, the only trace of that decision is whatever the CDS Client happens to log on its own — which varies per implementer and isn't currently interoperable across CDS Client implementations.

We're not proposing an implementation here — genuinely asking: has this been discussed before (I didn't find an existing issue on it), and is there appetite for an optional field on systemAction (or an extension point) that lets a CDS Service attach a checkable pre-execution artifact — e.g. a hash/signature over the action + the input state it was decided on, so a later audit can confirm the decision wasn't tampered with or fabricated after the fact, without requiring any particular verification backend? Happy to sketch a concrete proposal if that's a real gap worth closing rather than something already covered elsewhere in the ecosystem (SMART on FHIR audit event resources, etc.) that I've missed.

[isaacvetter]

Hi @babyblueviper1 ,

>the only trace of that decision is whatever the CDS Client happens to log on its own

The CDS Client is a CPOE system -- generally, it logs/audits all day everyday.

>auto-orders a lab, auto-updates a problem list

In response to some feedback from the most recent ballot, we've added more explanatory text about the use-cases in which systemAction is being used by downstream specs and some implementers: https://build.fhir.org/ig/HL7/cds-hooks/en/#system-action

It looks like this was the jira that initiated at least some of this additional content: https://jira.hl7.org/browse/FHIR-28636

Isaac

[babyblueviper1]

@isaacvetter thanks for the pointer, and useful to have the actual ballot-driven text + JIRA ticket rather than reading the spec cold.

That addition answers a different question than the one I was asking, though, and I want to be precise about the distinction rather than let it sound resolved when it is not. The new text (and FHIR-28636) clarifies WHEN/WHY a systemAction is appropriate to auto-apply — pre-coordinated scenarios, low-trust-card cases like coverage-assertion-id/pama-rating. That is a scoping answer.

"The CDS Client logs/audits all day everyday" answers a volume question, not the property I was actually asking about. An audit log kept by the CPOE system is only as trustworthy as the CPOE vendors own database integrity — if a bad systemAction` fires on stale prefetch or a service bug, the CPOE vendor's own log is also the thing a dispute would need to trust was not edited after the fact. There is no way for a THIRD PARTY (a regulator, a different vendor, the CDS Service itself) to independently confirm the log entry is what was actually acted on, versus reconstructed or altered post-hoc — that is a structurally different property from "we log a lot."

Concrete shape of what I mean, since abstract is easy to talk past: a checkable artifact would be something like a hash over (systemAction content, the exact FHIR resource state it was decided against, a timestamp), signed by whoever issued the decision, verifiable by ANYONE holding the artifact without needing API access to the CPOE vendor's own audit store. We run something with that exact shape for a different domain (pre-action review for autonomous agents) — a decision binds to a content-addressed hash of its own inputs, independently recomputable, so a dispute does not reduce to "trust the log of whoever made the call." Not proposing CDS Hooks adopt anything specific from us — just naming the property precisely so it is clear the ballot text closed the scoping question, not the verifiability one, in case anyone revisits this later.