How this catalog is governed
What may be published here, who checks it, how long that takes, and what happens to an entry after it goes live. Agreed by the community's data governance work group.
This catalog is a community asset, not an unmoderated list. Nothing is published automatically: every submission is checked for completeness, basic privacy hygiene and accuracy by people from member teams before it appears, and every published entry is revisited on a schedule so what you find here can be trusted to still be true. The rules on this page are the ones the reviewers apply; the contributor guide linked at the foot of the page walks through them from the submitter’s side of the form.
How review works
A submission moves through a lightweight but consistent review. The tiers exist so member jurisdictions can rely on what is listed here without turning review into a bottleneck that discourages sharing.
-
Step 1: Submit
Fill in the submission form (or the GitHub issue form — they are the same questions). It opens a GitHub issue that reviewers can see, comment on and ask questions in.
-
Step 2: Intake triage
A small rotating group confirms the entry is complete, the contact is reachable and there is no obvious personal or protected health information in the write-up, links or screenshots. Anything with a data-governance question is flagged for the committee.
-
Step 3: Substantive review
Representatives from across member jurisdictions check that the resource works as described, that the technology, licensing and portability claims are accurate, that it sits in the right category and that it meets the community’s data-governance baseline. The committee may ask for revisions or clarification.
-
Step 4: Partner review, when warranted
Higher-visibility or higher-risk submissions — anything touching identifiable data, clinical decision support or public-facing tools — may be routed through a neutral third-party reviewer for an outside check.
-
Step 5: Decision
Approved entries are published with the status Reviewed & approved. Revisions requested returns the entry to the submitter with specific feedback. Declined is rare, reserved for entries that fail the data-governance or accuracy checks, and always comes with a rationale.
-
Step 6: Publish
The approved entry is merged (a GitHub pull request, in practice) and appears on the site within a couple of minutes, with its own page and a place in the catalog.
-
Step 7: Maintain
Every entry is revisited annually, or sooner when a reader flags it, to confirm the contact is still valid, the resource is still active and the stage of development is current. An entry that is no longer current is marked Deprecated — kept for the record — rather than removed.
What reviewers look for
Reviewers apply five criteria. They are the same five a submitter can check before pressing the button.
- Completeness
- Every required field is filled in, honestly.
- Accuracy
- The technology, licensing, open-source and portability claims are correct.
- Data governance
- No personal or protected health information in the resource or its documentation; the sensitivity notes are honest and complete.
- Reuse readiness
- Enough documentation, links and contact detail that another jurisdiction could realistically evaluate or adopt it.
- Category fit
- Correctly placed in one of the community's use-case categories.
Who does what
Four roles keep the catalog running. None of them is a full-time job.
-
Governance Committee
Sets policy, conducts substantive review, resolves disputes and approves changes to the submission template or the categories.
-
Intake Team
Two or three rotating work-group members who do first-line triage of new submissions.
-
Community staff lead
Administers the repository, coordinates committee scheduling and maintains vendor and partner relationships.
-
Submitting jurisdiction
Keeps its own entries accurate, answers reuse enquiries from peers and tells the maintainers when something changes.
How the catalog is doing
Counted from this repository’s own issues and pull requests, refreshed monthly. Last 4 quarters, Oct 2025 to Aug 18, 2026.
- Submissions
- 13
- Published
- 9
- Contributing organizations
- 10all time
- Median review time
- 11 days9 in 10 within 24 days · 9 reviewed
| Quarter | Submissions | Published | Organizations |
|---|---|---|---|
| 2025 Q4 | 1 | 0 | 0 |
| 2026 Q1 | 3 | 2 | 2 |
| 2026 Q2 | 6 | 5 | 5 |
| 2026 Q3 | 3 | 2 | 2 |
New and updated entries are announced in the catalog feed and, to each submitter, on their own submission when it goes live.
No personal or protected health information
No personal information (PII) or protected health information (PHI) may appear in a submitted resource, its documentation, its example data or its screenshots. Every submitter attests to this when they submit; reviewers spot-check during intake and substantive review.
If a privacy or security issue is discovered after publication, the entry is taken down first and discussed second: email the maintainers, and the page is removed from the site while the question is worked out. The maintainer runbook describes exactly what happens.
Licensing and intellectual property
The default expectation is a permissive open-source license — MIT, Apache 2.0, or a Creative Commons license for documents — wherever the sharing jurisdiction can offer one. Jurisdictions that cannot may share on more limited terms (available on request, or government-to-government only); the entry says so in Access terms, and a peer asks before taking.
Submitting a resource does not transfer ownership. The originating jurisdiction retains authorship and credit; the catalog only points at the work and describes it.
Data governance baseline
An entry describes, in plain language, what data the resource touches, where that data comes from and who sees the output. Where a data-sharing agreement, de-identification step or approval covers the data, the Data governance notes say which. An entry that touches identifiable data, supports clinical decisions or faces the public receives closer review, and may be routed to a partner reviewer.
Accessibility and quality
Published pages are built to WCAG 2.1 AA and tested for it on every build with automated checks (axe, pa11y, Lighthouse) and keyboard-only walkthroughs. If something on this site does not work for you, email the maintainers (the address is at the foot of this page) and it will be treated as a defect, not a request.
There is a minimum documentation bar: a resource with no working link and no reachable contact is not published, because nobody could evaluate or adopt it.
Maintenance, versioning and deprecation
Every published entry is reviewed annually to confirm it is still active and accurate; the site marks any entry that has gone a year without confirmation and asks the maintainers to check. An entry that is no longer current is marked Deprecated rather than deleted, so the community keeps its institutional history — what was tried, by whom, and what it cost. Version history is kept automatically through the repository’s change tracking.
Appeals and dispute resolution
A submitter who disagrees with a review decision may appeal to the full Governance Committee by replying on the review thread or emailing the maintainers. The committee’s answer, with its rationale, is final for that submission; the submitter is always free to revise and resubmit.
Code of conduct
Member jurisdictions engage with one another’s shared work as colleagues: ask before you assume, credit what you reuse, give feedback that names the problem rather than the person, and keep questions about an entry in the open where the next reader can find the answer. The full code of conduct, linked below, is short and applies to every submission, review thread and discussion here.
Questions and appeals
Questions about any of this — or a decision you want to appeal — go to the maintainers. Proposed changes to the template, the categories or these rules go to the Governance Committee, which meets on the work group's regular cadence.