[mogoodrich]

UHM-9643: adds a manually triggered GitHub Action so the PIH dictionary can be released in OCL, checked, and put into pihemr without checking out the repo.

Usage

Actions → Update OCL export → Run workflow. The options:

Input	Meaning
Release a new version first	Release a new version of the PIH source in OCL before updating pihemr. Check with the dictionary maintainers first: a release includes everyone's unreleased edits.
Release notes	Required when releasing.
Version	The version to use (e.g. 1.8.43). Leave it blank for the latest release, or, when releasing, for the next number (e.g. 1.8.50 → 1.8.51).
Skip the release check	For emergencies only. The PR then says the check was skipped.

What it does

1. Release (only if "Release a new version first" is ticked). This runs in the ocl-release GitHub environment, so admins can require an approval.
   • It works out the version and refuses one that already exists.
   • It runs the PIH OCL release check on everything changed since the last release (--unreleased). If there are errors, nothing is released.
   • It creates the release in OCL, with the notes plus "released by via PIH/pihemr GitHub Actions".
2. Download. It downloads the export, waiting up to about 20 minutes while OCL builds it, and checks the zip's export.json is the right version.
3. Swap the zip in content/configuration/backend_configuration/ocl/ (orgs_PIH_sources_PIH_<version>_<timestamp>.zip). It does nothing if the repo already has that version.
4. Check the export. It runs the release check again on the new export, comparing it with the zip that was in the repo (--export … --baseline …), so only changed concepts are checked. If there are errors, or the check can't run, the run fails and no PR is opened.
5. Open a PR on ocl-export-<version>. The description has the OCL release notes, both check summaries, and who started the run. The check summaries also go on the run's summary page.

The release check is ocl_release_check.py from the PIH/claude-plugins ocl plugin (PIH/claude-plugins#8). The workflow downloads it from claude-plugins' main branch, so it's the same check the Claude skill runs before a release, and new or retired checks apply here automatically.

• Today it has two checks:
  • name-uuids: catches the UHM-9656 failure, a name UUID already used on PIH servers.
  • clone-mappings: catches ICD-10/LOINC codes lost by OCL's $clone bug (UHM-9636).
• The check reports two severities: errors block the run; warnings are only reported.

Setup

• OCL_API_TOKEN: a PIH organization secret, shared with this repo only. For now it's Mark's personal OCL token (noted in the workflow), so releases made by the workflow show up in OCL as made by him. OCL has no service accounts, so the plan is a dedicated OCL user in the PIH org.
• GHA_WRITE_TOKEN: an organization secret, available to this repo. It opens the PR, so Verify PRs runs on it.
• ocl-release environment: created with required reviewers (Mark, Ellen, Mike Seaton) and deployment branches = master only. A release run pauses until one of them approves it under Review deployments, and a modified copy of the workflow on another branch can't release.

Testing

• Checks: actionlint (including shellcheck) is clean.
• Download and swap: tested locally against OCL earlier.
• The check step, simulated locally (GitHub's environment variables, the real 1.8.46 and 1.8.50 exports):
  • A real name clash: blocked, with the error summary and no PR.
  • A clash that's already handled: passes.
  • Skip: passes, with a "SKIPPED" summary.
  • The script can't be downloaded: blocked.
• The version step, simulated locally: blank works out 1.8.51; an existing version is refused; missing release notes are refused.
• Not tested yet: the step that creates the release in OCL, and a full run on GitHub. The first real run will release 1.8.51 (the DICOM modality codes from UHM-9634), which tests the whole path.

🤖 Generated with Claude Code

[mogoodrich]

@lnball @mseaton haven't reviewed this yet, but this was something Claude suggested when I was working on an OCL skill... basically a one-step button to update the OCL dictionary. The goal was to get the point that we could build and release a new OCL library without to do any manual git work. If we think this is valuable I could try getting it set up and tested.

[lnball]

LGTM. But another timesaver would be that it tries to deploy the new OCL package on a server, it passes the OCL validation, and approves the PR. If it did that, Fiona or others without an SDK could make changes to the concept dictionary.

[mseaton]

Seems like a cool idea to me @mogoodrich !