Change Radius

Change impact analysis for regulated device software in Jira: safety class, hazards, risk controls, tests to repeat and documents to review, each with the link path that reached it.

Comment

Try it

Inspiration

Teams that build medical device software must analyse every change request before they approve and release it. IEC 62304:2006 asks for it in clauses 6.2.3 (analyse change requests) and 7.4 (risk management of software changes). The facts usually sit in Jira and Confluence already: which software item a change modifies, which requirements that item implements, which hazards those requirements control, which tests verify them. Putting them together is still a manual hunt through links, often late and differently by each engineer.

What it does

  • Change impact panel on any Jira issue labelled trace-change. It shows the software items the change modifies and their highest safety class, then the requirements, risk controls, hazards, verification to repeat and documents to review. Every row shows the link path that reached it, for example PUMP-1 → PUMP-4 → PUMP-7 → PUMP-11 → PUMP-10.
  • Findings: requirements or risk controls without verification, verification that is not done, software items without a safety class.
  • Similar changes: earlier changes that touched the same items, with the problem reports that followed them.
  • Suggestions for a change with no item linked yet, from past changes with similar wording. One click links the item and the analysis appears.
  • Impact record: writes the analysis to a Confluence page and links it to the change, ready for the assessor's decision and sign-off.
  • Re-verification tasks: one Jira task per verification to repeat, linked to the change and to the verification.
  • Release impact page: every change request in a fix version with its open verification and findings.
  • Rovo agent "Change Radius Analyst" with two actions, get-change-impact and get-release-readiness, which the app also exposes as tools on the Atlassian MCP server. An open-source SKILL.md in the repository tells third-party agents how to use them.
  • Load sample trace creates a fictional infusion pump trace (15 issues, 13 links) so a judge can try the app in two minutes.

Change Radius does not decide whether a change is safe. It assembles the trace for the person who decides.

How we built it

Forge with UI Kit for the issue panel and the project page, resolvers for the UI, and action, rovo:agent and rovo:mcp modules for Rovo. The core is plain JavaScript with no network access: it builds a graph from labelled Jira issues, their issue links and Confluence remote links, walks it breadth-first and keeps the path to every node it reaches. Item suggestions use word overlap between change summaries. Unit tests cover the core, the Jira adapter, the Confluence record, the sample loader and the re-verification flow. The app calls Jira and Confluence as the current user (asUser), stores nothing of its own and calls no language model; the Rovo agent uses Rovo on the site that runs it. We also called both actions from a third-party MCP client through the Atlassian MCP server.

Challenges we ran into

  • With "type": "module" in package.json, the bundled function failed with "out_namespaceObject is not a constructor" (a default-import interop problem). Removing it fixed the resolvers; the tests still run as ES modules.
  • Newly created sample issues all started in To Do, so every change showed open findings. The loader now moves the issues that should be done to the first done transition of the project's workflow.
  • The demo site already had a Rovo agent with the name we first chose, so we renamed ours to Change Radius Analyst.
  • Linked Confluence pages first appeared as synthetic keys; they now show as page links.
  • An impact record is linked back to its change, so the next analysis counted it as a document to review. The adapter now skips the app's own records.

Accomplishments that we're proud of

  • Every count and path on screen comes from the Jira trace, and every row shows how it was reached.
  • A judge can install the app, load the sample trace and see the full flow in a couple of minutes.
  • The same analysis works in the panel, in Confluence records and in Rovo.

What we learned

  • The impact analysis itself is a short graph walk; most of the design work went into showing each path so that a reviewer can follow it.
  • UI Kit's native rendering keeps the panel consistent with Jira's own look; we used design tokens only for spacing.

What's next for Change Radius

  • Mapping changed files in Bitbucket pull requests to software items.
  • Domain packs for ISO 26262 and other safety standards.
  • Reading and writing trace links through Teamwork Graph.

Built With

Share this project:

Updates

Submission history