Preface¶

Developers working on clinical assistance Agents often encounter a trouble: the model can quickly provide differential diagnoses and treatment plans, but preceding institutional steps—such as first-diagnosis responsibility, three-level ward rounds, critical value reporting, and pre-operative verification—are frequently skipped. Consequently, the output may hold up logically in clinical terms but fails to stand up to quality control standards.

This Skill operationalizes the 18 Core Medical Quality and Safety Systems, medical record quality control red lines, medical safety adverse event grading, and clinical pathways & PDCA into a layer of pre-emptive checks. It ensures that “before making diagnoses or prescribing treatments,” the system first confirms that institutional protocols have been implemented. The following section introduces its capability boundaries, activation methods, and usage precautions.

What This Is¶

A core medical institution and quality control management engine, located at @user_054f2eea/clinical-governance. It is maintained by community publisher user_054f2eea, version 1.0.0, categorized under healthcare (labeled as professional on the platform side), and sourced from the community.

In one sentence: It positions institutional verification as a pre-emptive risk control layer for diagnostic systems, embedding verification points into steps like collection, integration, differentiation, diagnosis, treatment plans, and care planning, rather than waiting to supplement records after the fact.

It does not require an API key. The platform page indicates requires_api_key=false.

Core Capabilities¶

Four key capabilities, all derived from official descriptions.

18 Core Systems × Treatment Step Triggers¶

Built-in “18 Core Medical Quality and Safety Systems × Pre-emptive Treatment Step Trigger Table.” Verification points are attached to specific steps in the clinical reasoning process, rather than being a separate institutional document for users to check against themselves.

Medical Record QC Red Lines¶

Covers three categories: single-item rejection criteria, critical value handling, and verification omissions. These are mandatory stop-gaps; hitting one triggers an immediate alert, rather than acting as a mere suggestion.

Adverse Event Grading & Reporting Process¶

Handles issues according to medical safety adverse event grading, with a reporting process designed based on non-punitive principles. This dictates the tone of the output: positioned as internal quality management, not accountability assignment.

Clinical Pathways & PDCA¶

Clinical pathways are used to constrain diagnostic and treatment actions within established paths, while PDCA (Plan-Do-Check-Act) facilitates the subsequent improvement loop, giving verification results a landing point.

Built-in Caution Mechanisms¶

Two mechanisms deserve specific mention:

L5 High-Risk Scenario Caution Mechanism: When high-risk scenarios are identified, output is tightened, and no conclusions are drawn rashly.
Adversarial Review of Disconfirming Evidence: Actively seeks opposing evidence rather than just following the line of supportive reasoning.
Conclusion Confidence: Output is marked with [H/M/L] to help users gauge the strength of the verification conclusion.

Trigger Method¶

There are seven fixed trigger words: Medical Core Systems, 18 Core Systems, Medical Record QC Red Lines, Adverse Event Grading, Medical Quality Safety, Clinical Pathway, Institutional Verification.

Appearance of any of the above words in a conversation may activate this skill. For consistent activation, it is recommended to explicitly write “Verify according to the 18 Core Systems” in the initial instruction, which is clearer than simply mentioning “medical.”

Installation and Activation¶

First, a factual note: The official pages and API data retrieved do not provide specific installation commands, directory paths, or configuration fields, so installation steps are not included here. Please check the README and SKILL.md on the SkillHub page for installation methods.

The only confirmed configuration item is that it does not require an API key:

requires_api_key: false

This type of Skill is based on the general SKILL.md format, and the loading method follows the general specifications of the Agent platform used. Once activated, it can be invoked without additional configuration; specifics should be based on the platform page description.

Typical Usage¶

Usage revolves around the combination of “institutional verification + clinical reasoning.” The following examples expand on the six steps described officially.

Example 1: Perform full-process institutional verification on a clinical reasoning case.

Verify according to the 18 Core Systems: Patient presents with unilateral lower limb swelling and elevated D-dimer on post-operative day 3.
Please reason through the six steps: Collection—Integration—Differentiation—Diagnosis—Plan—Scheduling.
Mark the triggered core institutional verification point and conclusion confidence [H/M/L] at each step.

Example 2: Trigger a standalone check of medical record QC red lines.

Execute Medical Record QC Red Line check: Verify if the current progress notes contain any single-item rejection items,
if there are time records for critical value handling, and if there are any omissions in the verification steps.

Example 3: Trigger disconfirming evidence review.

Using "Medical Quality Safety" as the trigger word, perform an adversarial review of disconfirming evidence on the preliminary diagnosis above,
listing evidence that conflicts with the preliminary diagnosis and alternative explanations.

The common thread in these three examples: The trigger word must be included in the instruction, and the scope of verification must be clearly defined; otherwise, the output will degenerate into a generic listing of regulations.

Applicable Scenarios & Precautions¶

Suitable scenarios: Hospital quality control assistance, internal departmental process self-checks, and scenarios in Agent development where institutional constraints need to be front-loaded.

Three limitations should be understood in advance.

First, it does not constitute medical practice, administrative orders, or legal advice. All verification points and QC suggestions are for internal quality management reference only and do not replace the quality control systems and manual reviews established by medical institutions in accordance with the law.

Second, final authority rests with the Medical Affairs or Quality Control Department of the medical institution. Recognition involving medical damage liability, dispute handling, and administrative penalties is subject to laws, regulations, health administrative department rules, and judicial/appraisal institution conclusions.

Third, model output may differ from the institution’s actual regulations. Users must execute in accordance with their own institution’s actual regulations and the requirements of the medical/QC departments; the output cannot be directly treated as the original text of institutional regulations.

Additionally, this skill does not provide installation commands or configuration item descriptions; it is recommended to verify on the official page before integration.

Conclusion¶

Its value lies not in providing new diagnostic conclusions, but in turning the requirements already written into regulations into a check gate before every step of clinical reasoning. For developers who need to front-load compliance constraints into Agent workflows, it provides a reusable path.

Official URL: https://api.skillhub.cn/user_054f2eea/clinical-governance

Page URL: https://www.skillhub.cn/skills/user_054f2eea/clinical-governance

Core Medical System and Quality Control Management Engine: Embedding System Auditing into Clinical Workflows