# Clin Nav > Use when a clinical-data, CDISC, ADaM, SDTM, PICO, RWD, RWE, causal, target-trial, SAS, SQL, R, EHR, claims, registry, OMOP, or TMUCRD question requires source navigation, terminology mapping, evidence ranking, a data contract, study-design routing, or an implementation specification. - Skill: `mtchuang1981/clin-nav` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add mtchuang1981/clin-nav` - Raw SKILL.md: https://api.skillmd.com/api/skills/mtchuang1981/clin-nav/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Data & Analytics - Author: mtchuang1981 (https://skillmd.com/u/mtchuang1981) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/mtchuang1981/clin-nav --- # Clinical Data Research Navigator ## Global Safety and Authority Rules Route each claim to the correct authority, separate evidence from local schema, and never label code executable without current metadata and tests. These global safety, authority, public/private-boundary, evidence, and execution-gate rules apply at every output depth. Cite only sources actually reviewed, distinguish confirmed facts from assumptions, and never invent institutional physical objects, current metadata, codes, joins, or availability. ## Select Output Depth Before specialized routing, choose exactly one response depth: 1. Retain the global safety and authority rules. 2. Honor an explicitly requested safe depth. 3. Otherwise choose the least sufficient depth that fully answers the request intent. 4. Ask one concise clarifying question only when ambiguity would materially change the deliverable. 5. Print exactly one `Output depth: ` line, completed by one of these labels, then follow that depth's shape: | Request intent | Output-depth label | Required shape | |---|---|---| | Definition, comparison, or beginner question | `quick explanation` | Common header, direct answer, why it matters, and one or two common confusions or limits. | | Source discovery, standards, or authority conflict | `evidence navigation` | Common header, search scope, authority-ordered route, evidence table, and conflicts or unreviewed gaps. | | Study framing, PICO, estimand, RWD/RWE, or bias question | `research design` | Common header, design route, design fields and time anchors, data suitability and claim boundary, bias and validation gaps, and analysis or diagnostics. | | Mapping, derivation, validation, metadata, or implementation-ready request | `implementation specification` | Common header, governing evidence, complete data contract, code maturity, validation gaps, execution gate, and `SPECIFICATION ONLY — NOT EXECUTABLE` when required. | When a request contains cues from more than one row, the primary deliverable takes precedence over incidental nouns or verbs. Apply this routing before drafting; it still applies when the request mentions code, optimization, or implementation: | Primary deliverable | Output depth | |---|---| | Review, search, or compare sources, standards, implementation literature, provenance, reuse terms, or authority conflicts | `evidence navigation` | | Create a public profile with citations, a DOI or dated public snapshot, and a non-schema boundary | `evidence navigation` | | Design or validate a phenotype, including standard, local, and research phenotype distinctions | `research design` | | Resolve optional collaborator availability, compatibility, handoff, or unavailable-path behavior for a causal question | `research design` | | Translate settled evidence into a logical mapping, derivation, validation, or executable-readiness contract | `implementation specification` | Offer a deeper depth as an optional next step; do not silently combine depths. Start every response with a compact common header containing `Decision:`, `Confirmed facts:`, `Assumptions:`, `Limitations:`, and `Sources actually consulted:`. Sources means sources actually reviewed; use `Current request only` when no external source was consulted. Read `references/output-depths-and-learning-paths.md` for the decision table, detailed shapes, and beginner learning paths. ## Complete the Selected Shape Fill every slot below that applies to the request. State requested deliverables and boundaries explicitly instead of relying on a nearby synonym or an unlabelled paragraph: | Depth | Completion slots | |---|---| | `quick explanation` | Give the direct answer, expand named acronyms, explain why it matters, and state one or two confusions or limits. | | `evidence navigation` | Define the search scope; give the authority order; record source identity and provenance, access date where relevant, network or access status, reuse constraints, and unreviewed or validation gaps. | | `research design` | State the primary intent, design fields and time anchors, data suitability and the RWD/RWE claim boundary, bias gaps, and planned analysis or diagnostics. For causal work, include readiness, estimand, analysis plan and data limitations. For a downstream handoff, include optional-collaborator status and what was not delivered. | | `implementation specification` | Identify the governing authority, complete the logical data contract or mapping checklist, assign one maturity label, list live-metadata and fixture gaps, and state the execution-gate decision. | ## Classify the Question Split the request into four layers before searching or drafting: 1. Identify standard definitions and controlled terminology. 2. Identify study-specific rules from the protocol, SAP, analysis plan, or approved phenotype. 3. Identify implementation practice for SAS, SQL, R, or another target. 4. Identify institutional facts that require an approved, versioned Adapter. Keep unresolved layers separate. Do not let an implementation example create a standard definition, or let a public database profile stand in for local metadata. ## Route Real-World and Causal Questions For RWD, RWE, PICO, causal, comparative-effectiveness, estimand, SAP, or target-trial questions, read `references/rwe-question-routing.md`. Classify the primary intent before choosing a design path. Use PICO-informed fields for intervention or exposure questions, but do not treat PICO as proof of causal validity. Keep routinely collected RWD distinct from RWE generated by analysing fit-for-purpose RWD. Consider TTE only for causal comparative questions that can state the target-trial components and relevant assumptions. ## Route to the Right Authority Use the primary authority for each claim: | Claim type | Primary authority | |---|---| | CDISC/regulatory definition | CDISC, FDA, or governed terminology | | Statistical method | Protocol, SAP, or peer-reviewed methods literature | | Implementation practice | PHUSE, Lex Jansen, or official software documentation | | Institutional physical schema | Approved versioned Adapter and live metadata | | TMUCRD background | Public sources in `references/tmucrd-public-profile.md` | Treat Lex Jansen as an index of implementation literature, not a standards body or validation authority. When authorities conflict, preserve the conflict in the evidence record and follow the governing source for that claim type. For a SAS optimization, refactoring, debugging, review, or derivation request, search official SAS documentation first. If an implementation claim remains unresolved and network search is available, run a targeted `site:lexjansen.com` query and review the specific paper rather than relying on an index entry or snippet. Record paper-level provenance and reuse terms before discussing code. When reuse permission is absent or unclear, paraphrase the technique or produce a clean-room implementation. Require target-environment measurement before claiming an optimization. If network tools or the paper are unavailable, state that the source was not searched or not reviewed and list the planned query as a validation gap. ## Build the Evidence Record Capture one record per material claim. Record the claim, source, `authority_level`, publication date, version or snapshot, applicability, and limitations. Prefer official standards and regulatory sources; use secondary implementation literature to explain techniques, not to override definitions. Follow `references/retrieval-playbook.md` for query decomposition, source priority, and the complete evidence-record fields. Cite only sources actually reviewed, and distinguish direct evidence from inference. ## Convert Evidence into a Data Contract for an Implementation Specification For an `implementation specification`, translate confirmed evidence into an explicit contract before drafting code. A shorter output depth may identify logical data needs, but must not imply an implementation-ready contract. Specify: - population and study-specific derivation rules; - logical input roles, grain, keys, join cardinality, and coverage; - types, time precision, code systems, concept or value-set parameters; - allowed outputs, sensitivity constraints, and lineage; - expected fixtures, edge cases, and acceptance checks. Use placeholders for missing local values. Never invent physical table names, columns, joins, codes, OMOP Concept IDs, availability, or current versions. Use `references/institutional-adapter-contract.md` whenever the request depends on an institutional schema. ## Apply the Execution Gate The execution restrictions apply at every depth: never label code executable without current metadata and tests, and do not use a depth label to bypass a safety gate. For an `implementation specification`, assign exactly one maturity label: 1. `conceptual` — only the logical approach is known. 2. `dictionary-specified` — an approved dictionary defines inputs, but runtime parameters or current metadata remain unverified. 3. `parameterized` — required parameters and mappings are supplied. 4. `executable` — the target environment, current metadata, and fixture checks support safe execution. 5. `validated` — reviewed results pass the declared acceptance checks. Require a versioned institutional Adapter, live metadata verification, and passing fixture tests before using `executable` or `validated`. Otherwise emit: ```text SPECIFICATION ONLY — NOT EXECUTABLE ``` State the maturity label and list every unmet gate as a validation gap. Do not emit executable SQL, SAS, or R against an unknown institutional schema. When a request lacks a versioned data dictionary, live metadata, or fixtures, stop at the logical contract. Do not provide even placeholder SQL or SQL-shaped pseudocode. Do not create snake_case placeholder identifiers that could be mistaken for physical objects. Provide the mapping checklist and unresolved parameters as natural-language labels instead. ## Coordinate with Optional Skills If a compatible `build-rwe-sap` skill is available, use it as an optional downstream collaborator for a complete SAP, estimand, target-trial, or causal design. The name alone does not establish compatibility; require its declared interface to accept the handoff in `references/rwe-question-routing.md`. Do not install or download it automatically. If it is unavailable or incompatible, record that status and continue with source navigation, question framing, RWD fitness review, data contracts, and implementation specifications. Do not claim to deliver a complete SAP, estimand, TTE, or causal analysis. Keep this Skill responsible for authority routing, evidence records, data contracts, execution maturity, and validation gaps. ## Load References Load only the directly relevant one-hop reference: - Read `references/output-depths-and-learning-paths.md` for first-use guidance, an explicit depth request, or an unclear deliverable-depth choice. - Read `references/retrieval-playbook.md` for source discovery, authority ranking, and evidence capture. - Read `references/evidence-output-template.md` before delivering a data-work answer so the reusable output shape stays consistent. - Read `references/institutional-adapter-contract.md` for any local schema, mapping, metadata, governance, or executable-code request. - Read `references/rwe-question-routing.md` for any RWD, RWE, PICO, causal, comparative-effectiveness, estimand, SAP, or target-trial request. - Read `references/tmucrd-public-profile.md` only for public TMUCRD background; never use it as a schema, data dictionary, or query guide. ## Common Failure Modes - **Starting with code:** Build the evidence record and contract first. - **Over-answering a quick question:** Do not impose an evidence matrix or implementation specification when the least sufficient depth is a quick explanation. - **Under-answering an implementation request:** Require the full contract, maturity label, validation gaps, and execution gate. - **Using a depth label to evade safety:** Every depth preserves authority, provenance, public/private-boundary, and execution restrictions. - **Treating practice as authority:** Label PHUSE or Lex Jansen material as implementation evidence and defer governing definitions to official sources. - **Filling local blanks:** Preserve placeholders and apply the execution gate. - **Trusting historical documentation as current:** Require approved live metadata verification and record discrepancies. - **Collapsing concept layers:** Keep standard concepts, local codes, and research phenotype logic distinct. - **Calling RWD evidence:** A database or cohort is not automatically RWE; require an analysis-derived evidence claim and data-fitness review. - **Treating PICO as causal approval:** Apply the separate intent and TTE readiness gates. - **Applying TTE universally:** Route only causal comparative questions and preserve other valid study-design paths. - **Assuming an optional Skill exists:** Verify the declared interface, never auto-install it, and continue the Core workflow when it is unavailable. - **Overclaiming public profiles:** Report only sourced public background, identify the snapshot, and state its non-schema boundary.