openevidence-reference-architecture
Provides a standard project layout and architecture diagram for HIPAA-compliant clinical decision support tools.
Install
mkdir -p .claude/skills/openevidence-reference-architecture && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/5949" && unzip -o skill.zip -d .claude/skills/openevidence-reference-architecture && rm skill.zipInstalls to .claude/skills/openevidence-reference-architecture
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Reference Architecture for OpenEvidence.Key capabilities
- →Structure clinical data flows for regulatory compliance
- →Implement caching strategies for evidence and citations
- →Establish audit logging pipelines for malpractice risk mitigation
- →Design event-driven feedback loops
How it works
The architecture separates the query path from the audit path, using Redis to cache evidence and citations while ensuring all queries are logged to a persistent database.
Inputs & outputs
When to use openevidence-reference-architecture
- →Designing new clinical AI integrations
- →Reviewing project structure
- →Establishing architecture standards
- →Structuring clinical data flows
About this skill
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
- Map users, patient touchpoints, product features, source evidence, record systems, support, and governance owners.
- Draw trust boundaries for credentials, PHI, recordings, copied outputs, citations, and third-party communications.
- Place clinician review before any care decision and define how evidence is verified and uncertainty recorded.
- Use only documented handoffs; label desired integrations as vendor-confirmation questions, not architecture facts.
- Add access lifecycle, monitoring, incident response, downtime alternative, retention, and rollback.
- Review the model with clinical, privacy, security, legal, operations, and records owners.
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 |
|---|---|
| Private endpoint appears in design | Remove it until a signed/current contract documents it. |
| AI output becomes system of record automatically | Insert human review and approved record controls. |
| No downtime path | Block go-live until one exists. |
Examples
This compact example shows the minimum reviewable handoff; adapt fields to the approved workflow without adding sensitive data.
Input:
workflow=Ask-to-clinical-note; systems=OpenEvidence+EHR; integration=manual-copy
Expected handoff:
boundaries=6; human-gates=2; undocumented-integrations=0; review=pending
Resources
When not to use it
- →Caching audit logs
- →Dropping audit entries during database failures
Prerequisites
Limitations
- →Audit logging must never slow clinical responses
- →Evidence cache invalidation required on guideline updates
How it compares
This architecture explicitly separates audit logging from the primary query path to ensure sub-second response times for clinicians.
Compared to similar skills
openevidence-reference-architecture side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| openevidence-reference-architecture (this skill) | 1 | 2mo | Review | Advanced |
| architecture-patterns | 55 | 4mo | No flags | Advanced |
| kotlin-multiplatform | 32 | 5mo | Review | Advanced |
| nodejs-best-practices | 28 | 8mo | No flags | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by jeremylongshore
View all by jeremylongshore →You might also like
architecture-patterns
wshobson
Implement proven backend architecture patterns including Clean Architecture, Hexagonal Architecture, and Domain-Driven Design. Use when architecting complex backend systems or refactoring existing applications for better maintainability.
kotlin-multiplatform
vitorpamplona
Platform abstraction decision-making for Amethyst KMP project. Guides when to abstract vs keep platform-specific, source set placement (commonMain, jvmAndroid, platform-specific), expect/actual patterns. Covers primary targets (Android, JVM/Desktop, iOS) with web/wasm future considerations. Integrates with gradle-expert for dependency issues. Triggers on: abstraction decisions ("should I share this?"), source set placement questions, expect/actual creation, build.gradle.kts work, incorrect placement detection, KMP dependency suggestions.
nodejs-best-practices
davila7
Node.js development principles and decision-making. Framework selection, async patterns, security, and architecture. Teaches thinking, not copying.
workflow-orchestration-patterns
wshobson
Design durable workflows with Temporal for distributed systems. Covers workflow vs activity separation, saga patterns, state management, and determinism constraints. Use when building long-running processes, distributed transactions, or microservice orchestration.
java-pro
sickn33
Master Java 21+ with modern features like virtual threads, pattern matching, and Spring Boot 3.x. Expert in the latest Java ecosystem including GraalVM, Project Loom, and cloud-native patterns. Use PROACTIVELY for Java development, microservices architecture, or performance optimization.
arm-cortex-expert
sickn33
Senior embedded software engineer specializing in firmware and driver development for ARM Cortex-M microcontrollers (Teensy, STM32, nRF52, SAMD). Decades of experience writing reliable, optimized, and maintainable embedded code with deep expertise in memory barriers, DMA/cache coherency, interrupt-driven I/O, and peripheral drivers.