fsi-smoke-test

Tests FSI Interface patient retrieval end to end against live Epic and Oracle sandboxes.

Updated Jul 7, 2026
One-click install
npx skills add https://github.com/bbenefield89/skills --skill fsi-smoke-test-bbenefield89
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fsi-smoke-test
Source: https://github.com/bbenefield89/skills/tree/main/skills/fsi-smoke-test
Command: npx skills add https://github.com/bbenefield89/skills --skill fsi-smoke-test-bbenefield89

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve? Verifying that a running FSI Interface stack actually retrieves real patient data end to end is slow and error-prone when done manually, since full-chart orchestration jobs can take over 12 minutes and failures have many distinct causes. This Skill automates the entire smoke test and classifies every failure by reason. ## Core Features & Use Cases - Stub-sourced request generation: Parses local WireMock stubs (MockData/Stubs) to build the request set automatically, with no hand-maintained patient list. - Concurrent orchestration polling: Submits all requests to the non-mock /v1/patients endpoint first, then polls /v1/orchestration/{jobId} concurrently against one wall-clock budget so slow jobs never stall the rest. - Classified failure reporting: Emits machine-readable JSON plus a clean terminal table, tagging each failure as stale-data, empty-data, orchestration-error, slow, auth-401, or submit-fail. - Use Case: After starting the local FSI stack with docker compose, ask the agent to run the FSI smoke test to confirm Epic Sandbox and Oracle/Cerner Sandbox patient retrieval works before merging a change. ## Quick Start Ask the agent to run the FSI smoke test against the locally running stack to confirm patient data retrieval works end to end.

Frequently Asked Questions about fsi-smoke-test

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I smoke test FSI Interface patient retrieval?

Run the Invoke-FsiSmokeTest.ps1 script with pwsh while the FSI stack is running locally on port 8076. It submits stub-sourced requests to /v1/patients, polls the orchestration jobs concurrently, and writes a results JSON plus a summary table.

How do I test only Epic or only Oracle/Cerner sandbox retrieval?

Pass the -Set parameter with Epic or Oracle to limit the run to one sandbox, or use Both (the default) for both. Add -All to test every stub-sourced encounter instead of the default sample of three per EMR.

Why does the FSI smoke test report stale-data failures?

A stale-data failure means the orchestration completed but the sandbox identifier from the stub no longer resolves because live sandbox data rotated. It indicates outdated stub identifiers, not a code regression in the FSI stack.

Why do FSI smoke test results show slow instead of pass or fail?

A slow result means the job was still running when the wall-clock poll budget expired, which is common since full-chart jobs can exceed 12 minutes. Raise -PollTimeoutSeconds above the default 600 and re-run to get a final verdict.

Does the FSI smoke test use the mock endpoint or WireMock stubs?

It deliberately targets the non-mock /v1/patients endpoint to test the real retrieval path. The WireMock stubs are only read as a source of request identifiers, since mock requests complete with empty data.

Why does the FSI smoke test return auth-401 errors?

An auth-401 means the submit was rejected as unauthorized, usually because the wrong OID header was sent. The local container runs in Development mode where the only authorized consumer OID is the literal local-dev value.