Ask Openmed

Ask OpenMed

Use this skill as the first pass when a request does not name a focused OpenMed workflow. It selects an existing skill identifier; it does not process input, download a model, call a service, or make a clinical decision. No mandatory network call is part of this route.

Deterministic routing contract

Apply these rules in order:

1. Normalize only the stated goal: lowercase it, trim surrounding whitespace, and collapse repeated whitespace. Do not inspect or copy the data payload.
2. Apply the intake boundary. If the goal matches an Intake row, select the first matching intake skill even when the goal also names a later stage. If sensitivity is unclear, its next handoff is the privacy gate: deidentifying-clinical-text, before extraction, exchange, or verification sees the parsed content.
3. For a goal with no intake cue, apply the privacy override. If it asks to analyze, extract, exchange, share, upload, or verify clinical or personal content and is not explicitly marked safe, start at the privacy gate. The only safe markers are synthetic input, synthetic note, synthetic record, synthetic dataset, input is synthetic, data is synthetic, already de-identified, and already deidentified. A marker does not count when no, not, never, unknown, or uncertain occurs in the four normalized words before it. Treat every ambiguous safety statement as sensitive.
4. Otherwise inspect the remaining tables in the fixed handoff order shown below. Treat each comma-separated cue as a case-insensitive substring of the normalized goal, and select the first matching row. Every cue cell is a comma-separated list of alternatives; conjunctions have no special meaning. Do not add synonyms or infer cues from the payload. This stage order and row order break every tie.
5. If no row matches, use building-with-openmed as the orientation fallback.

Route output should contain only the selected category, skill identifier, matched rule index, and next handoff. Never echo the request, input values, exception text, or detected spans into a log or report.

For a multi-stage request, route one stage at a time in this fixed handoff order: intake → privacy → extraction → exchange → verification. A later stage does not bypass the privacy gate merely because it was named first.

Intake

Choose the first skill for turning an external document or record format into local, processable input.

Privacy

Use the privacy table both for an explicit privacy goal and for the privacy override. The first row is the default gate for unspecified sensitive input.

Extraction

Choose the focused skill after intake and privacy handling when the request is about finding or structuring clinical meaning.

Exchange

Choose an exchange skill only after the source is safe to handle. These skills may use a user-supplied endpoint or terminology service; this router itself performs no network call.

Verification

Use verification routes for a stated release, safety, leakage, audit, risk, or conformance check. If the source is not explicitly safe, the privacy override still wins first.

Ambiguous goals and escalation examples

Use the privacy override and the fixed handoff order for ambiguous requests:

• “Turn this clinical note into FHIR.” The sensitivity is unstated, so start at deidentifying-clinical-text, then hand off to extracting-clinical-entities and exporting-to-fhir.
• “Extract medications from a synthetic note.” The input is explicitly synthetic, so route directly to extracting-clinical-entities.
• “OCR this image and extract findings.” Route to ingesting-clinical-documents, then apply the privacy gate before extraction.
• “Is this dataset safe to share?” If de-identification is not stated, start with deidentifying-clinical-text and then use auditing-deid-leakage.
• “Verify this clinical dataset; it is not de-identified.” The negated safety statement does not count as a safe marker, so start at deidentifying-clinical-text.
• “Which OpenMed workflow fits?” Use the orientation fallback building-with-openmed, then re-route once the goal and sensitivity status are explicit.

These are routing examples only. Keep all demonstrations synthetic or placeholder-based, and keep route diagnostics free of source content.