What does this skill do, and when should you use it?
This is Stage 1 of NVIDIA’s Clinical ASR Flywheel, focused on environment readiness and hosted-stack access. It checks NVIDIA_API_KEY, the Python version, and required libraries, then synthesizes and transcribes one clinical sentence with Magpie TTS and Parakeet/Nemotron ASR. The workflow is designed for synthetic data generated from a curated term list, not real patient transcripts, clinical recordings, or PHI. After validation, users proceed to term curation and benchmark construction; KER (Keyword Error Rate) is the headline metric used later in the flywheel.
Checks that NVIDIA_API_KEY is present without printing its value; creates and activates .venv and installs nvidia-riva-client, pandas, soundfile, and requests, with optional jiwer; calls fixed NVCF Magpie TTS and Parakeet ASR function IDs at grpc.nvcf.nvidia.com:443; synthesizes “The patient was prescribed cefazolin.”, writes the returned audio to a temporary WAV, transcribes it, and prints the source sentence and ASR transcript; optionally checks DICTIONARY_API_KEY or Merriam-Webster medical-dictionary reachability. It does not produce an evaluation manifest, audio dataset, or model artifact.
- A clinical speech-evaluation engineer is starting the flywheel and needs to verify the API key, Python dependencies, and network path.
- A team evaluating recognition of drug names, procedures, anatomy, conditions, or laboratory terms wants to validate hosted TTS and ASR before curating terms.
- A returning user has an existing environment and needs a length-only key check plus one current TTS-to-ASR smoke test.
- An organization needs to review outbound data flows before allowing synthetic text, WAV audio, or optional clinical-term lookups to reach external services.
How do you install this skill?
- The smoke test and downstream workflow send synthetic clinical text and audio to NVCF; organizational external-API and data-governance approval is required, and real patient data or PHI must not be used.
- NVCF function IDs, client APIs, and unpinned dependencies may change; validate in a controlled virtual environment, record versions, and clean up temporary WAV files.
- Mainland-China network reachability and a Chinese-language workflow are not evidenced; validate both before relying on this skill in those environments.
- Shell / CLI
- Network access
- Local filesystem
Python 3.10+nvidia-riva-clientpandassoundfilerequestsNVIDIA_API_KEY
Install the selected skill from the repository with: npx skills add nvidia/skills --skill digital-health-clinical-asr-setup --yes. The README does not document a separate package or standalone installer for this skill. Use Python 3.10 or newer, create an environment with python3 -m venv .venv && source .venv/bin/activate, then run pip install nvidia-riva-client pandas soundfile requests; install jiwer optionally.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/NVIDIA/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/digital-health-clinical-asr-setup" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Set NVIDIA_API_KEY in the shell, for example export NVIDIA_API_KEY=nvapi-..., and perform only the documented length check. Activate .venv and run the prescribed smoke_test(api_key=...) with the current key supplied by the caller; do not let the recipe read or log the key itself. On success, continue to /digital-health-clinical-asr-build and treat KER (Keyword Error Rate) as the main Stage 3 measure. DICTIONARY_API_KEY is optional; Merriam-Webster can also be skipped, allowing Magpie G2P fallback.
What are this skill's strengths and limitations?
- Provides a concrete sequence: key check, dependency setup, and hosted TTS-to-ASR smoke test.
- Uses an explicit API-key argument pattern and prohibits logging the key value.
- Documents NVCF and Merriam-Webster data flows, optional paths, and common failure modes.
- Explicitly limits the workflow to synthetic data and excludes real patient content.
- The core validation requires NVIDIA_API_KEY and network access to NVCF.
- The default hosted dependency can be affected by stale function IDs, quotas, networking, or backend failures.
- The scope ends at environment readiness; term curation, evaluation, scoring, and fine-tuning are outside this skill.
- The supplied source does not provide a skill-specific test suite, platform matrix, or pricing information.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| Clinical ASR Flywheel: Environment Setup this page ✓ NVIDIA · Official | 54 · Use with care | ★ 3.8k | today | Apache-2.0 |
| Azure AI Transcription for Python ✓ Microsoft · Official | 49 · Use with care | ★ 2.7k | 3mo ago | MIT |
| Azure Short-Audio Speech-to-Text REST ✓ Microsoft · Official | 49 · Use with care | ★ 2.7k | 3mo ago | MIT |
| Speech Generation ✓ OpenAI · Official | 48 · Use with care | ★ 28k | today | — |
| Azure Call Automation for Java ✓ Microsoft · Official | 43 · Not recommended | ★ 2.7k | 3mo ago | MIT |
Compared with a self-hosted ASR/TTS pipeline, this skill assumes NVIDIA-hosted Magpie TTS and Parakeet/Nemotron ASR through NVCF. The source recommends a self-hosted pipeline when NVCF cannot be used for organizational data-governance reasons.
How did FollowSkills review this skill?
The skill clearly discloses NVCF and Merriam-Webster data flows, prohibits real patient data and secret echoing, and uses an explicit api_key argument; however, the smoke test sends text and audio to external services, does not clearly require per-execution confirmation, and dependency installation plus a non-cleaned temporary WAV create side effects without rollback or cleanup, so points are deducted.
The procedure includes dependencies, error codes, and troubleshooting guidance; however, dependencies are not pinned, NVCF function IDs may become stale, no committed tests cover the key paths, and the claim of read-only checks conflicts with virtualenv creation, package installation, and temporary-file creation. Static calibration therefore limits the score.
Audience, trigger phrases, non-fit cases, prerequisites, and hosted versus self-hosted boundaries are relatively clear; however, the core path depends on NVCF, assumes English en-US, gives no Chinese-language support or mainland-China network reachability evidence, and cannot operate without NVCF, so applicability is limited.
The documentation has clear sections for prerequisites, examples, artifacts, limitations, troubleshooting, version, license, ownership, and dependency boundaries; however, it lacks a formal changelog, explicit maintenance commitment, and locked dependency versions, while the benchmark reports no Tier 3 availability, so points are deducted.
The skill defines a concrete environment-readiness workflow, a round-trip smoke-test output, and a clear hand-off to the next stage; however, no static evidence verifies an actual successful run, and success depends on network access, a valid key, and current function IDs. Manual remediation remains necessary on failure, limiting directly usable value.
SKILL.md, committed evaluation cases, BENCHMARK.md, and dependency documentation provide some auditability, and the key-passing path is explicitly described; however, the benchmark has no Tier 3 results, no executed key-path test evidence, and no independent corroboration, so the static score remains conservative.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →