openevidence-core-workflow-a

Structure and review an OpenEvidence clinical consult while preserving clinician accountability and evidence traceability. Use when working with OpenEvidence in a healthcare organization. Trigger with "openevidence core workflow a", "OpenEvidence clinical-consult", or a matching workflow request.

Allowed Tools

ReadGlobGrepWebFetchWriteEdit

Provided by Plugin

openevidence-pack

Operator-grade OpenEvidence pack with 24 source-grounded skills for clinical evidence review, safe adoption, privacy, security, and product workflow governance.

saas packs v1.14.0
View Plugin

Installation

This skill is included in the openevidence-pack plugin:

/plugin install openevidence-pack@claude-code-plugins-plus

Click to copy

Instructions

OpenEvidence Clinical Consult Workflow

Overview

Convert a clinical uncertainty into a focused Ask workflow, then validate the evidence before using it in care. Keep inputs minimal, separate observed facts from assumptions, and leave consequential decisions with the named accountable owner.

Prerequisites

  • A clearly bounded workflow, accountable clinical owner, and organizational policy
  • Current first-party OpenEvidence documentation and applicable institution agreements
  • Synthetic or properly authorized minimum-necessary data

Tool Discipline

Use Read, Glob, and Grep to inspect supplied policies, plans, and evidence. Use WebFetch only for current first-party OpenEvidence documentation. Use Write or Edit only when the user requests a named deliverable with an approved destination. Never expose credentials, PHI, recordings, or unrestricted environment output.

Current Contract

  • The platform is informational and educational and does not replace diagnosis or professional clinical judgment.
  • The public guide describes Ask for evidence-based clinical questions with cited sources.
  • Only enter patient context permitted by applicable policy, agreement, authorization, and consent.

Authentication

Use only the official OpenEvidence web/mobile sign-in or an institution-approved access path. Do not invent API keys, OAuth clients, SDK credentials, service accounts, or private endpoints. Never ask a user to reveal a password, session token, cookie, or recovery code.

Instructions

  1. Define the decision to support and the minimum context needed; remove direct identifiers unless approved and necessary.
  2. Frame the question with population, intervention or exposure, comparator, outcomes, and relevant constraints.
  3. Choose the documented Ask model or workflow appropriate to complexity; use Snow for a literature investigation when warranted.
  4. Review EvidenceGrade when present, then open citations and inspect recency, study design, population, and guideline provenance.
  5. Reconcile the response with patient-specific facts, contraindications, local policy, and the clinician’s independent judgment.
  6. Record the question, evidence reviewed, uncertainty, decision owner, and any follow-up without copying unnecessary PHI.

Approval Boundaries

Do not create or share accounts; change access, roles, agreements, consent, retention, or security settings; enter PHI; record a conversation; copy content into another system; contact a patient; make a diagnosis or treatment decision; submit billing; transmit a support packet; run a production pilot; or represent vendor capabilities without explicit approval from the accountable owner. A qualified professional remains responsible for clinical decisions.

Output

Return scope, current first-party evidence and date, data classification, workflow or findings, citations reviewed, assumptions rejected, clinical and governance owners, approval state, unresolved risk, and the exact next action. Redact patient and credential data.

Error Handling

Condition Response
Evidence conflicts Surface both positions and have the clinical owner resolve applicability.
Patient context exceeds policy De-identify further or stop until authorization is confirmed.
Answer sounds definitive Restate uncertainty and verify source support before use.

Examples

This compact example shows the minimum reviewable handoff; adapt fields to the approved workflow without adding sensitive data.

Input:


decision=therapy options; population=de-identified adult; constraints=renal impairment

Expected handoff:


question=structured; sources=opened; uncertainty=recorded; decision=clinician-owned

Resources

Ready to use openevidence-pack?