Building and Maintaining Skills Assessments in Epic's Platform
I spent three years working on Epic's internal skills assessment infrastructure before moving on to other projects. The platform has specific quirks that aren't obvious from the documentation, and most people building for it hit the same walls. The assessment engine lives inside Epic's broader training and certification framework. You're not writing standalone applications — you're building modules that integrate with their existing assessment pipelines, which handle scheduling, proctoring, scoring, and credentialing all in one system. The developer portal gives you access to a sandbox environment, but the sandbox doesn't fully replicate the production behavior, especially around timing and concurrent test delivery. I've seen teams spend weeks debugging issues that only appear when the assessment runs under actual load. My workaround was to write a parallel stress test harness that simulates hundreds of simultaneous examinees hitting the API at once. The sandbox throttles requests differently than production does, so any validation you run only in the dev environment will miss a significant class of failures.
When you register as a developer on Epic's platform, you get scoped API credentials. Those credentials are tied to a specific organization unit, which means your assessments can't be deployed across departments without going through their change management process. This isn't a technical limitation — it's by design. Healthcare certification data has compliance requirements that make cross-departmental deployment a governance conversation, not an engineering one. One thing the docs don't emphasize enough: the scoring engine in Epic's assessment software runs asynchronously. You submit responses, the platform queues them, and scoring happens on a separate thread with its own failure modes. I spent about two weeks tracking down why certain answers weren't being scored correctly. The root cause was that our response format included trailing whitespace in selected options, and the scoring logic did exact string matching rather than trimmed comparison. The fix was preprocessing the response payload before submission. That kind of detail only shows up when something breaks, not in any guide I've seen. The versioning system is another area where people get tripped up. When you publish an assessment update, Epic doesn't automatically roll it out to all active test sessions. Existing examinees who started the assessment before the update will continue on the old version until they complete it or until their session expires. If you're building assessments where question order or content changes meaningfully between versions, you need to handle version attribution in your scoring pipeline manually. The platform metadata will tell you which version a submission came from, but it won't route your scoring logic — you build that yourself.
Architecture and integration patterns
Most of the work you'll do involves the assessment lifecycle APIs: creating an exam, defining question banks, managing examinee enrollments, and retrieving results. The response objects are moderately verbose. A single completed assessment with twenty questions can return fifteen thousand characters of JSON on the results call. If you're aggregating scores across multiple departments or building dashboards, you'll want to implement pagination and selective field retrieval from day one rather than refactoring later. The question bank system supports several types — multiple choice, numeric entry, scenario-based ordering, and drag-and-drop. Each type has different validation rules and scoring parameters. The drag-and-drop type is particularly finnicky because the scoring tolerance is configured per item and defaults to exact ordering, which means any partial credit setup requires explicit configuration. I built an assessment that looked correct in the sandbox but awarded full credit when it should have given partial credit, simply because the tolerance parameter was left at its default value. Integration with Epic's identity management is straightforward if you're already in their ecosystem. SSO flows use their standard token issuance, and examinee authentication is handled through the same mechanism. The problem area is external examinees — contractors, vendors, or partners who don't have existing Epic credentials. You can provision temporary identities through the admin API, but these accounts expire after a configurable window, and if an assessment session is interrupted mid-exam, resuming requires re-authentication which can trigger the expiration logic in unexpected ways. We solved this by implementing a checkpoint-and-pause feature that saves progress and reuses the original session token rather than creating a new authentication flow on resume.
Get the Full Details
What doesn't work well
The platform isn't designed for high-frequency lightweight quizzes. It's built for formal certification assessments that run on schedules with proctoring oversight. If you're trying to use it for rapid skill checks or continuous assessment throughout a workflow, you'll fight the architecture the entire time. The minimum setup overhead for a new assessment — question authoring, review cycles, scheduling, and approval — takes roughly two to three weeks even with an experienced team. For something like a weekly skills drill, that's not viable. The reporting APIs are also limited in scope. You can pull individual exam results and aggregate pass rates, but anything beyond that requires exporting raw data and doing your own analysis. There's no built-in item response theory calculation, no discrimination index generation, and no automated question quality monitoring. If your assessment program grows beyond a few dozen exams, you'll need to build or buy a separate analytics layer. One more practical constraint: Epic reviews every custom assessment before it goes live in production. The review process typically takes five to ten business days, and they will reject submissions that don't meet their accessibility and formatting standards. I've had assessments bounced back because the color contrast on answer options didn't meet WCAG 2.1 AA requirements, or because the time limit calculation didn't account for all question types equally. Plan for at least two revision cycles in your timeline.
If you need something lighter weight for internal team use, evaluating whether a dedicated assessment platform like Examity, ProctorU, or even a custom solution on top of something like Moodle might serve you better. Epic's system is overkill for casual use and rigid enough that fighting it is usually more expensive than working around it.
