OpenEvidence Rollout Acceptance Gate

Overview

Turn practice requirements into a manual, evidence-backed acceptance suite for supported OpenEvidence web or mobile workflows. 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

• OpenEvidence publishes end-user web and mobile workflows, not a public CI or test API contract.
• Acceptance evidence must come from an authorized test account, synthetic scenarios, and current first-party instructions.
• A passing product check never validates the clinical correctness of a real patient decision.

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. Inventory the rollout requirements, supported devices, accountable clinical owner, and approved synthetic test scenarios.
2. Read the current OpenEvidence guide for each feature in scope; mark undocumented behavior as unverified.
3. Build a matrix covering sign-in, Ask response citations, export/copy behavior, and only the explicitly selected Visits features.
4. Execute with synthetic or properly authorized data; capture timestamps and redacted evidence, never patient identifiers.
5. Record pass, fail, blocked, and not-tested separately; route clinical-content review to a qualified professional.
6. Publish the gate result with owners, exceptions, rollback criteria, and a re-test date.

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

OpenEvidence Answer-Quality Troubleshooting

Overview

Separate access trouble, prompt ambiguity, evidence limitations, and unsafe interpretation before anyone acts on an answer. 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

• OpenEvidence answers cite sources and may expose EvidenceGrade; neither removes the need for professional review.
• Model and feature behavior can change, so the live guide and visible product state outrank cached instructions.
• Do not paste identifiable patient data into a diagnostic packet.

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. Classify the symptom as access, missing context, irrelevant evidence, conflicting evidence, citation mismatch, or product failure.
2. Reduce the question to the clinical decision, population, intervention, comparator, outcome, and time horizon that matter.
3. Compare an ordinary Ask response with an appropriate model or Snow only when the current guide supports that choice.
4. Open the cited sources and verify population, date, endpoint, recommendation strength, and applicability.
5. Ask a qualified clinician to review the result and document uncertainty or conflicting guidance.
6. Create a redacted support packet only when the behavior appears technical rather than clinical.

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, curren…

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 d…

OpenEvidence EvidenceGrade and Citation Review

Overview

Treat the displayed grade as a navigation aid, then perform a source-level review of every material claim. 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 official user guide documents lettered EvidenceGrade output and links to its methodology.
• A grade summarizes evidence strength; it is not a patient-specific recommendation or correctness guarantee.
• Citation review must consider source type, date, population, outcome, and fit to the decision.

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. List each material claim that could change diagnosis, treatment, safety, documentation, or patient communication.
2. Capture the displayed EvidenceGrade and any caveats without treating the grade as the conclusion.
3. Open the supporting citations and map each claim to the exact source or mark it unsupported.
4. Check guideline authority, publication date, study population, intervention, comparator, outcomes, and limitations.
5. Identify disagreements, indirectness, missing subgroups, or newer evidence that alters applicability.
6. Return a clinician-review table with supported, uncertain, contradicted, and not-assessed claims.

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, wor…

OpenEvidence Access and Value Review

Overview

Build a decision-ready value review from authorized local evidence and current commercial terms. 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

• Public product pages do not establish institution-specific price, quota, SLA, or entitlement terms.
• Only a current order form, MSA, or authorized account surface can establish commercial commitments.
• Clinical quality and safety outcomes must not be reduced to raw query volume.

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: pilot continuation, feature expansion, workflow retirement, or contract review.
2. Collect authorized evidence for active users, completed workflows, time saved, failure modes, and training/support burden.
3. Separate product facts from institution-specific contract terms and unverified anecdotes.
4. Measure value by workflow outcome, evidence-review quality, clinician time, and adoption friction; avoid patient-outcome causality claims.
5. Identify unused or duplicative workflows and test a reversible change with the accountable owner.
6. Return a value brief with data provenance, limitations, owner, decision date, and next measurement.

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 …

OpenEvidence PHI and Consent Boundary

Overview

Establish whether data may enter OpenEvidence, who authorizes it, and how outputs move into governed systems. 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

• OpenEvidence terms recommend removing identifying information before submission and assign users responsibility for lawful content.
• Covered entities choosing to transmit PHI are governed by the applicable BAA or customer-specific agreement.
• Visits records conversations; required notice and consent depend on law and organizational policy.

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. Classify the workflow, data elements, users, systems, jurisdiction, retention needs, and whether recording occurs.
2. Read the current Terms, Privacy Policy, Security page, applicable BAA/MSA, and institutional policy.
3. Minimize identifiers and free text; prefer synthetic or de-identified content when patient identity is unnecessary.
4. Document authorization, recording notice and consent, role access, approved export destination, and deletion/retention owner.
5. Test the workflow with synthetic data before any authorized real-data use.
6. Produce a data-flow record with unresolved legal, privacy, security, and clinical review items.

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-part…

OpenEvidence Redacted Support Packet

Overview

Capture enough browser/app and workflow context for support while excluding PHI, credentials, and speculative API probes. 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 supported public surface is the documented product UI and mobile app, not guessed private endpoints.
• A useful packet identifies time, surface, feature, steps, expected result, actual result, and redaction method.
• Clinical disagreement belongs in evidence review; technical malfunction belongs in a support packet.

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. Classify the issue as access, browser/device, feature availability, data loss, recording, output, or clinical-content concern.
2. Reproduce with synthetic or fully de-identified content when safe; stop if reproduction could affect care.
3. Record UTC time, app/web version cues, browser/device, feature path, steps, expected behavior, and actual behavior.
4. Capture only redacted screenshots or text; remove names, dates of birth, record numbers, credentials, and hidden metadata.
5. Check the current user guide, terms, and public status/trust surfaces before labeling behavior a defect.
6. Write a packet with severity, impact, workaround, owner, consent to transmit, and clinical-safety escalation if applicable.

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 deci…

OpenEvidence Practice Rollout Plan

Overview

Treat rollout as clinical workflow change, not software API deployment. 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

• OpenEvidence is delivered through documented end-user product surfaces.
• Institution-specific availability, integrations, commitments, and data terms require written confirmation.
• A rollout needs clinical, privacy, security, operational, and training ownership.

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. Select one bounded workflow and define users, patients affected, systems touched, success criteria, and explicit exclusions.
2. Confirm account eligibility, feature availability, agreement terms, data handling, consent, and support path.
3. Design training for prompting, EvidenceGrade, citation verification, professional judgment, and failure escalation.
4. Pilot with synthetic scenarios, then a small authorized cohort under heightened review.
5. Review quality, safety signals, adoption, workflow burden, and unresolved controls before expansion.
6. Record launch/no-launch, rollback trigger, owners, training evidence, and next review date.

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 an…

OpenEvidence Institutional Access Governance

Overview

Translate institutional roles and least-privilege expectations into verifiable product and contract controls. 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

• No public RBAC, SCIM, provisioning, or administration API contract was found in the audited product documentation.
• Only the current institution agreement and authorized administration interface can establish available controls.
• Shared credentials are prohibited by the published account terms.

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. Inventory user populations, clinical roles, administrators, support staff, devices, workflows, and sensitive data exposure.
2. Read the agreement and authorized admin documentation; mark SSO, provisioning, audit, and role features confirmed or unknown.
3. Define joiner, mover, leaver, periodic review, break-glass, and compromised-account procedures.
4. Map each workflow to minimum access and an accountable approver; prohibit shared accounts.
5. Run a sample access review using authorized records without exporting unnecessary personal data.
6. Return confirmed controls, gaps, compensating controls, vendor questions, owners, and review cadence.

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 classi…

OpenEvidence Verified-User Onboarding

Overview

Verify account access and the Ask evidence-review loop using a synthetic clinical question. 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

• Full service access requires account registration and may include professional verification.
• The supported onboarding surface is the website or mobile application; no public API-key flow is documented.
• The first proof must avoid patient data and clinical action.

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. Confirm the intended user, approved device, organizational policy, and whether an institutional account path applies.
2. Register or sign in through the official product; never request or fabricate an API key.
3. Submit a synthetic, non-urgent clinical question containing no identifiable patient facts.
4. Confirm the answer displays sources and, when present, EvidenceGrade; open at least one citation.
5. Record surface, timestamp, result, and any access limitation without copying account secrets.
6. End with the product unmodified except for the authorized test history and identify the clinical-review training needed next.

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, cl…

OpenEvidence Clinical-AI Safety Incident Runbook

Overview

Protect patients and data first, then preserve a minimum, redacted factual record for clinical and technical resolution. 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

• OpenEvidence output does not replace clinical judgment or emergency procedures.
• Privacy, recording, and PHI obligations depend on law, policy, consent, and applicable agreements.
• Security concerns can be reported through OpenEvidence’s published security contact; product support paths govern other issues.

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. If care may be affected, move to the organization’s clinical escalation or emergency procedure before investigating the tool.
2. Classify patient safety, privacy/PHI, unauthorized access, recording consent, availability, or evidence integrity; set severity.
3. Contain within authority: stop using the affected workflow, prevent further copying, and preserve necessary facts.
4. Notify the accountable clinical, privacy, security, legal, operational, and vendor owners according to policy.
5. Build a redacted timeline and validate citations or product behavior without replaying sensitive content.
6. Document recovery criteria, approvals, communications, corrective actions, and post-incident review.

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.

OpenEvidence Account Verification and Access

Overview

Choose the supported user access path and verify it without packages, tokens, shared accounts, or private endpoints. 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

• OpenEvidence terms require account registration for full service access and make users responsible for account confidentiality.
• The product is intended for healthcare professionals and may verify registration information.
• No public OpenEvidence SDK package, API token, OAuth, or service-account contract was found.

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. Identify individual versus institution-managed access, professional role, approved email/device, and accountable access owner.
2. Read current registration, terms, privacy, security, and institution-specific access instructions.
3. Complete only the official sign-up, sign-in, or administrator-issued path; do not install similarly named packages.
4. Enable organization-required device and account protections and keep credentials in approved user-controlled storage.
5. Verify access with a synthetic Ask workflow and record only non-secret evidence.
6. Document recovery, termination, role-change, and suspected-compromise contacts.

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…

OpenEvidence Synthetic Workflow Evaluation Loop

Overview

Replace the nonexistent local developer loop with a repeatable browser/app evaluation process. 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

• OpenEvidence does not publish a local runtime, sandbox SDK, or public test API in the audited documentation.
• Synthetic scenarios are the default evaluation input; real PHI requires the full approved data boundary.
• Evaluation tests workflow fitness and evidence review, not medical-device validation.

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 feature, user role, expected workflow outcome, unacceptable failure, and clinical reviewer.
2. Create synthetic scenarios spanning routine, ambiguous, conflicting-evidence, and failure-path cases.
3. Read the current guide and record the model, feature, and surface used for each run.
4. Execute manually through the supported product, preserving only de-identified prompts, citations, and observations.
5. Have a qualified reviewer score traceability, applicability, uncertainty, and workflow burden.
6. Iterate one variable at a time and publish a go, revise, or stop recommendation.

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 …

OpenEvidence Deep Consult to Snow Migration

Overview

Translate legacy Deep Consult use cases into Snow, which the official guide identifies as its replacement. 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 current guide says Deep Consult has been replaced by OpenEvidence Snow in the model selector.
• Legacy Deep Consult examples remain representative, but do not establish current performance, quota, or timing.
• Migration must revalidate prompts, structure, citations, review, data handling, and user training.

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. Inventory legacy Deep Consult prompts, reports, user groups, downstream decisions, and sensitive-data handling.
2. Classify each workflow as retire, move to ordinary Ask, or pilot in Snow based on complexity and value.
3. Read the current Models and Deep Consult guidance; remove obsolete navigation and invented quota assumptions.
4. Run synthetic paired evaluations and compare coverage, citation traceability, uncertainty, format, and reviewer effort.
5. Update training, templates, governance, and support documentation with a rollback path.
6. Obtain clinical and operational sign-off before retiring the legacy procedure.

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, wo…

OpenEvidence Web and Mobile Workflow Parity

Overview

Define which surface supports each step and test handoff, device, consent, and export behavior. 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 official guide documents web and mobile experiences for Ask and Visits workflows.
• No public dev or staging domains are documented; environment separation belongs to the institution’s test-data and rollout process.
• Browser-specific capabilities, such as some recording inputs, must be checked against current guidance.

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 the workflow steps, user role, device, browser/app, data class, and expected handoffs.
2. Read the current feature page for web/mobile differences and supported-browser notes.
3. Test with synthetic data on each authorized surface; record unavailable or divergent behavior.
4. Verify that copied notes, citations, recordings, and notifications stay within approved systems.
5. Define the supported surface, fallback, training note, and re-test trigger for each step.
6. Return a parity matrix with evidence date, owners, gaps, and rollout impact.

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 …

OpenEvidence Quality and Adoption Audit

Overview

Create a human-centered review loop without claiming access to private product telemetry. 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

• No public observability API or standard metrics export is documented.
• Measurements must come from authorized account/institution records and redacted quality samples.
• Volume and speed are insufficient without citation, applicability, and safety review.

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 monitored workflow, cohort, period, data authority, clinical owner, and escalation thresholds.
2. Select measures for completion, citation traceability, unsupported claims, reviewer overrides, time burden, incidents, and training gaps.
3. Sample the minimum authorized records and de-identify evidence used outside the care record.
4. Have qualified reviewers score outputs with a stable rubric and record inter-reviewer disagreement.
5. Trend results without inferring patient outcomes or vendor-wide performance from a local sample.
6. Publish findings, limitations, actions, owners, thresholds, and the next review date.

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…

OpenEvidence Prompt Refinement

Overview

Tune context and question structure while holding clinical accountability and source review constant. 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 official guide publishes prompt guidance and dedicated workflows for complex cases and Snow.
• More detail is not always safer; include only relevant, authorized context.
• Performance means decision usefulness and evidence traceability, not fastest answer or longest response.

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. State the decision, intended user, population, outcome, constraints, and what uncertainty must remain visible.
2. Remove identifiers and irrelevant narrative; separate known facts from assumptions.
3. Run a baseline synthetic or authorized de-identified question and score relevance, citations, applicability, and reviewer effort.
4. Change one prompt element at a time: specificity, timeframe, comparator, output structure, or request for conflicting evidence.
5. Open citations and have a qualified clinician compare versions using the same rubric.
6. Save a reusable pattern only if it improves the defined outcome across multiple representative cases.

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, c…

OpenEvidence Clinical Go-Live Checklist

Overview

Produce a binary, owner-signed readiness decision for one clearly bounded workflow. 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

• Go-live approval belongs to the accountable institution, not this skill or the product output.
• Current first-party terms, privacy, security, feature guidance, and institution agreements all matter.
• A successful technical test does not waive clinical review or data obligations.

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. Freeze workflow scope, users, surfaces, data classes, dependencies, success measures, and exclusions.
2. Verify account/access lifecycle, agreements, PHI boundary, consent, retention, approved exports, and security review.
3. Complete synthetic acceptance tests and clinician-led evidence/citation review across normal and failure cases.
4. Verify training, support contacts, incident response, downtime alternative, and rollback authority.
5. Record unresolved items as blockers or explicitly accepted risks with named decision owners.
6. Issue go, conditional-go, or no-go with evidence links, signatures, launch window, and first review date.

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, …

OpenEvidence Access and Capacity Triage

Overview

Distinguish local connectivity, account/feature access, service behavior, and clinical urgency using safe evidence. 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

• No public numeric request limit or API retry contract was found for OpenEvidence.
• Browser/app symptoms must not be translated into invented HTTP limits.
• Urgent care needs must use an independent clinical fallback.

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. Record UTC time, surface, feature, user cohort, duration, impact, and whether patient care is time-sensitive.
2. Move urgent work to the approved clinical fallback before diagnosis.
3. Check local network/browser/device conditions and current first-party status/support information.
4. Reproduce once with synthetic content if safe; do not hammer the service or probe private endpoints.
5. Compare affected users/surfaces and capture a redacted support packet.
6. Report observed capacity symptoms, not a guessed quota, with workaround, owner, and escalation state.

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…

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. Add access lifecycle, monitoring, incident response, downtime alternative, retention, and rollback.
6. 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 da…

OpenEvidence Supported Interaction Patterns

Overview

Convert an SDK-shaped request into a documented product workflow or a vendor-confirmation question. 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 audited first-party materials do not publish an OpenEvidence SDK or developer API.
• Similarly named npm and PyPI packages are not an authenticated OpenEvidence integration path.
• Supported patterns include end-user Ask and documented feature workflows, subject to current guide and account availability.

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. Identify the desired outcome and why the requester thinks code integration is required.
2. Search current first-party documentation for an explicit developer contract, package, authentication method, and terms.
3. If absent, reject package installation, private-endpoint probing, browser automation, and credential extraction.
4. Map the outcome to a supported product pattern: focused Ask, Snow literature investigation, Collections, Dotflows, Visits, or approved manual handoff.
5. If automation remains necessary, write precise vendor questions covering API, auth, scope, PHI, limits, SLA, and support.
6. Return the supported pattern, rejected assumptions, evidence date, and approval owner.

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, curr…

OpenEvidence Security and Contract Due Diligence

Overview

Separate public vendor assertions from the controls and commitments actually governing the institution’s use. 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 public security page states HIPAA handling, SOC 2 Type II, encryption in transit and at rest, annual penetration testing, and a disclosure contact.
• The Trust Center provides current security-program evidence, while access to detailed artifacts may be controlled.
• Institution commitments are governed by applicable MSA, BAA, SLA, and other written agreements.

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. Scope workflow, users, data classes, recording, communications, devices, exports, and downstream systems.
2. Collect the dated security page, Trust Center evidence, terms/privacy, and current institution agreements.
3. Map vendor claims and contract commitments separately to required controls; mark absent evidence unknown.
4. Review identity lifecycle, minimum necessary data, encryption boundaries, retention/deletion, subprocessors, incident notice, availability, and exit.
5. Route gaps to security, privacy, legal, clinical, procurement, and vendor owners.
6. Issue approve, conditional, or reject with evidence dates, exceptions, compensating controls, and reassessment trigger.

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…

OpenEvidence Feature-Change Adoption

Overview

Prevent silent workflow drift when navigation, models, outputs, or product features change. 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

• OpenEvidence features and model choices can change; current first-party guidance is the baseline.
• Deep Consult-to-Snow is one documented replacement, but other changes require their own evidence.
• Saved prompts and procedures must be revalidated when model or output behavior changes.

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. Capture the change source, evidence date, affected users, workflows, data, templates, records, training, and controls.
2. Separate documented facts from assumptions and determine whether the change is mandatory, optional, or unavailable to the account.
3. Run synthetic before/after scenarios using a stable rubric for citations, applicability, uncertainty, format, and effort.
4. Review privacy, consent, security, clinical, operational, and records impacts.
5. Update procedures and training, define rollback or fallback, and obtain accountable approval.
6. Monitor the first cohort and close only after acceptance evidence and residual risks are recorded.

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 findin…

OpenEvidence Workflow Handoffs and No-Webhook Guard

Overview

Translate event-driven integration requests into supported manual or contract-confirmed handoffs. 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

• No public OpenEvidence webhook endpoint, signing method, event catalog, or retry policy was found.
• Private network behavior is not a supported integration contract.
• Documented product features and institution agreements define allowable handoffs.

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 business event, source feature, destination, latency need, data class, failure impact, and accountable owner.
2. Search current first-party and institution-specific documentation for an explicit webhook or integration contract.
3. If none exists, block endpoint creation, secret generation, signature code, and guessed event names.
4. Design the minimum approved manual handoff, product-native workflow, or vendor-confirmation request.
5. For any confirmed integration, require written event, auth, verification, replay, ordering, retention, PHI, and support contracts before implementation.
6. Return the supported handoff, rejected assumptions, risks, owner, and approval state.

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, w…