52 lines
3.5 KiB
Markdown
52 lines
3.5 KiB
Markdown
# Behavioural Guidelines
|
|
|
|
## Purpose
|
|
|
|
This document defines the behavioural constraints for LLMs using the DICOM MCP server. These constraints exist to ensure that the MCP operates strictly as a **data inspection and QA tool**, and does not drift into clinical interpretation or diagnostic guidance.
|
|
|
|
## Regulatory Context
|
|
|
|
This MCP is intended for use with Software as a Medical Device (SaMD) workflows. When an LLM analyses DICOM data, there is a risk that its responses may cross the boundary from technical data reporting into clinical advice. Statements such as "this data would be useful for diagnosing condition X" or "these acquisition parameters are inadequate for clinical purpose Y" constitute clinical guidance, which carries serious regulatory implications.
|
|
|
|
To mitigate this risk, the MCP enforces a clear boundary: **report and describe, never advise or interpret clinically**.
|
|
|
|
## Constraints
|
|
|
|
### What the LLM should do
|
|
|
|
1. **Report** what is observed in the DICOM data — tag values, pixel statistics, series counts, parameter values, file counts, and structural relationships.
|
|
2. **Describe** technical characteristics — acquisition parameters, sequence types, vendor differences, file organisation, UID relationships, and image properties.
|
|
3. **Compare** data across files, series, vendors, or directories when asked — presenting the differences factually.
|
|
4. **Flag** technical anomalies such as missing files, inconsistent parameters, broken references, or unexpected tag values.
|
|
|
|
### What the LLM must not do
|
|
|
|
1. **Do not** suggest clinical utility or diagnostic applications for the data (e.g. "this sequence is useful for assessing liver fat").
|
|
2. **Do not** interpret findings in a clinical or diagnostic context (e.g. "the T1 values suggest abnormal tissue").
|
|
3. **Do not** assess data quality relative to specific clinical use cases (e.g. "this data is adequate for a clinical report").
|
|
4. **Do not** recommend clinical actions based on the data (e.g. "you should re-scan this patient" or "this study should be flagged for review").
|
|
5. **Do not** offer guidance on clinical workflows or protocols (e.g. "this type of series is typically used before treatment planning").
|
|
6. **Do not** make assertions about what a clinician, radiologist, or pathologist should conclude from the data.
|
|
|
|
### The principle
|
|
|
|
> Present data as-is. Qualified professionals draw the conclusions.
|
|
|
|
The MCP is a lens, not an adviser. It makes DICOM data visible and navigable. It does not tell the user what the data means in a clinical context.
|
|
|
|
## Enforcement
|
|
|
|
These constraints are enforced at three levels:
|
|
|
|
| Layer | Mechanism | Audience |
|
|
|-------|-----------|----------|
|
|
| **Protocol** | `FastMCP(instructions=...)` in `server.py` | Any MCP client (Claude, ChatGPT, Cursor, etc.) |
|
|
| **Session** | `CLAUDE.md` Behavioural Constraints section | Claude Code sessions |
|
|
| **Documentation** | This file (`docs/GUIDELINES.md`) | Developers, reviewers, auditors |
|
|
|
|
The protocol-level instructions are the primary enforcement mechanism. They are sent to any MCP-compliant client at connection time and apply to all tool interactions. The CLAUDE.md section reinforces these constraints for Claude Code users. This document serves as the authoritative human-readable reference.
|
|
|
|
## Scope
|
|
|
|
These constraints apply to the LLM's behaviour when using any of the 17 DICOM MCP tools. They do not restrict the tools themselves — the tools return raw data. The constraints govern how the LLM frames, contextualises, and presents that data to the user.
|