Agent skill · software engineering · jeremylongshore
openevidence-reference-architecture
Design a governed operating model around OpenEvidence’s supported product workflows and clinician review. Use when working with OpenEvidence in a healthcare organization. Trigger with "openevidence reference architecture", "OpenEvidence architecture", or a matching workflow request.
Why this skill is useful
Adds a complete reference architecture with executable code for clinical decision support that integrates with OpenEvidence, which is not commonly found in public resources.
What it needs
Requires bull, redis installed locally. About 2k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
OpenEvidence Human-in-the-Loop Operating Model Overview Map people, product surfaces, evidence review, governed records, and incident paths without fabricating integrations. 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 documented surface comprises product workflows such as Ask, Visits, and Dialer, subject to current availability. No public API, webhook, SDK, or infrastructure deployment contract was found. Clinical decisions and official records remain owned by qualified people and approved systems. 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. Map users, patient touchpoints, product features, source evidence, record systems, support, and governance owners. 2. Draw trust boundaries for credentials, PHI, recordings, copied outputs, citations, and third-party communications. 3. Place clinician review before any care decision and define how evidence is verified and uncertainty recorded. 4. Use only documented handoffs; label desired integrations as vendor-confirmation questions, not architecture facts. 5. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/openevidence-reference-architecture--900beb