ORCA-CDS is a resilient, offline-capable viewer for Epic order sets, built to keep critical clinical decision support available during EHR and network downtimes — when clinicians need it most. It was developed and evaluated at Children's Hospital of Philadelphia (CHOP) and is described in a peer-reviewed publication (see Citation below).
ORCA-CDS is not a live connection to the EHR: it does not access, display, or store patient data, does not offer live decision support, and cannot be used to place orders. It is a read-only, offsite copy of order-set structure — the same content a clinician would see building an order set in Epic — regenerated periodically from your institution's own Clarity/data-warehouse extract. It is research software, not a certified medical device, and should be validated against your own downtime procedures before clinical use.
- Fast, fuzzy search across order sets and SmartSets
- Full offline support via a service worker — once loaded, the app and its last-synced data continue working with no network at all
- Keyboard-accessible, dark-mode-aware interface
- Printable order sheets for paper-based downtime workflows
flowchart LR
A[Epic Clarity] -->|mirrored into a warehouse,\ne.g. Snowflake| B[(SQL extract)]
B -->|sql/clarity_recent_ordersets_raw.sql| C[Raw CSV export]
C -->|python/process_chop_osq.py| D[Hierarchical JSON]
D -->|public/data_files/all_chop_osq_raw.json| E[React / Vite app]
E -->|service worker| F[(Offline cache)]
F -.works with no network at all.-> E
The published paper describes the extraction as "an Oracle SQL query"; at CHOP this pipeline actually runs against a Snowflake mirror of Clarity (lake_clarity). Wherever your own Clarity data lives, you will very likely need to adjust the SQL dialect and possibly the schema — see Step 1 below.
This repository ships with a small set of entirely fabricated example order sets (public/data_files/all_chop_osq_raw.json) — a fake sepsis pathway, asthma exacerbation, and well-child visit — so you can clone it, run it, and see the actual interface working before connecting any real data:
npm install
npm run devNone of this example content is real: it isn't affiliated with CHOP or any institution's actual order sets, and it's clearly marked as fabricated in the data itself. Once you're ready to connect your own institution's data, follow the steps below and it replaces the example content entirely.
Order sets are specific to each institution's Epic build, so getting your own real data in is a four-step process: adjust the SQL, run the pipeline once to confirm it works, schedule it to run on a recurring basis, then configure and deploy the app itself.
Open sql/clarity_recent_ordersets_raw.sql. It was written for a Snowflake warehouse mirroring CHOP's Clarity instance, and will almost certainly need changes for your environment:
- Table/column names. Clarity's core schema is fairly consistent across Epic sites, but data-warehouse mirrors (Snowflake, Oracle, SQL Server, or Clarity itself) can differ in schema naming, case sensitivity, and how they expose Clarity's tables. Compare the table names referenced in the query (e.g.
CL_OSQ_BLOCK,CL_OTL,CL_PRL_SS) against what's actually available in your own environment. - SQL dialect. This version uses Snowflake syntax (e.g.
LISTAGG(... ) WITHIN GROUP,ADD_MONTHS). If your data lives directly in Oracle, SQL Server, or another warehouse, some functions will need dialect-specific equivalents. - Test incrementally. Start by running just the first CTE (
max_dates) against a single known order set ID, confirm it returns sensible results, then work outward. Don't run the full 16-level query cold against your whole Clarity instance on the first try. - Validate row counts. The full query joins through up to 16 hierarchy levels; a schema mismatch often shows up as unexpectedly duplicated or missing rows rather than an outright error. Spot-check a few known order sets against what you see in Epic's own order-set editor.
Export the result to CSV once you're confident it's correct.
cd python
python process_chop_osq.py /path/to/your_extract.csvThis converts the flat CSV into the nested JSON structure the app expects, and writes it directly to public/data_files/all_chop_osq_raw.json — overwriting the fabricated example data mentioned above. The script also normalizes RTF-formatted description text, cleans up dose-value formatting, and preserves IDs as strings (rather than letting them get corrupted into floating-point numbers, a common pandas pitfall with CSVs). Run it once manually and open the resulting JSON to sanity-check a few order sets before moving on.
If you're contributing back to this repo (rather than just running your own deployment): don't commit your real generated JSON over the example file. Keep your institution's real data in a private fork, branch, or deployment only.
Order sets change — new ones get built, existing ones get revised. ORCA-CDS is only as useful as its data is current, so plan to re-run the extract-and-process pipeline on a schedule rather than once. How often depends on how frequently your order sets change; nightly is a reasonable starting point.
The pipeline is two steps (run the SQL, then run the Python script), so any scheduler that can run both in sequence works. A few options:
- cron (Linux/macOS), if the SQL step can be automated via a CLI tool for your warehouse:
# Nightly at 2am: extract, process, and replace the app's data file 0 2 * * * /path/to/run_extract.sh && /path/to/venv/bin/python /path/to/python/process_chop_osq.py /path/to/latest_extract.csv
- Windows Task Scheduler, if your extraction tooling runs on Windows — set up a daily trigger that runs a
.bator PowerShell script performing the same two steps. - A scheduled job in your data-warehouse platform (e.g., a Snowflake task or an Airflow DAG), if the CSV export step can be automated there directly, followed by a small serverless function or scheduled script to run the Python step and redeploy.
Whatever mechanism you use, the last step of the scheduled job should redeploy the app (see Step 4) so the newly generated JSON is actually served, and the service worker's NetworkFirst caching strategy will naturally pick up the refreshed data on each successful online load.
Edit src/config.js — this is the one file you need to touch to make the app yours:
organization— your institution's name, logo, and homepageapp.brandColor— light/dark accent colorsdata.popularOrderSetIDs— the order sets shown before any search; defaults to the three fabricated example order sets, replace with theORDERSET_IDvalues for your own most-used sets once you've generated your own dataorderTypeIconMapping— maps your Epic build'sORDER_TYPEcategory names to icons (the example mapping in this repo came from one site's build; check your own extracted data for the actual category strings)
Then build and deploy:
npm install
npm run buildDeploy the build/ output to any static host.
On where to host it. The entire point of ORCA-CDS is to remain reachable during a true downtime — which sometimes means your primary network or main domain is exactly what's unavailable. CHOP's own deployment is hosted on infrastructure outside the hospital's main domain/network for this reason, so that a network-level or domain-level outage doesn't take down the downtime tool along with everything else.
On access control. Because the generated data can include internal-facing free text (see Data & Privacy below), CHOP does not leave the deployment openly accessible. Instead, the site is protected with a login and password that is not distributed in advance — the credentials are shared with staff only as part of downtime communications when an actual outage occurs. This is a deliberate tradeoff: the tool needs to be quick to access during a downtime, without being a standing, publicly discoverable target the rest of the time. Practical ways to implement this depend on your host — static-site platforms with built-in password protection, or a basic-auth rule at your reverse proxy/CDN layer, are both straightforward options. ORCA-CDS itself does not implement authentication; that's expected to live at the hosting layer.
Because the service worker caches the app shell and the last-fetched data file, a deployed instance keeps working for users who have already loaded it, even if the host becomes unreachable after that first successful load.
The pipeline extracts order-set templates only: section structure, order names, dosing text, and similar metadata used to build the order set in Epic. It does not extract patient-identifiable data. That said, some Epic builds include free-text fields (order comments, section descriptions) that institutions have used to embed internal contact information (staff names, extensions, internal URLs). Review your own extract before publishing or widely distributing the generated JSON — this repository has no way to know what your institution's free-text fields contain, and this is also a reason to keep the deployed instance access-controlled rather than fully public (see Step 4 above).
If you use or adapt ORCA-CDS, please cite:
Proctor S, Desai B. Development and Evaluation of Offsite Repository for Clinical Assets, a Resilient Solution for Order Set Access during EHR Downtimes. Applied Clinical Informatics. 2025;16(5):1401-1412. doi: 10.1055/a-2620-6221
See CITATION.cff for a machine-readable citation.
ORCA-CDS is licensed for academic, non-commercial use — see LICENSE.md. Commercial licensing inquiries should go to CHOP's Office of Technology Transfer (techtransfer@chop.edu).
ORCA-CDS was conceived by Dr. Bimal Desai and built by Dr. Stephon Proctor at Children's Hospital of Philadelphia, motivated by the gap between documented downtime-preparedness guidance and the practical tools clinicians actually had available during real EHR outages.
See CONTRIBUTING.md for how to get involved.