Proposed Additions

For the wiki builder and the curriculum committee. Everything below is a recommendation, not a decision taken. Each item gives the options and the reasoning.

1. Do these before anything else

1. Decide whether the site is public or department-only. Hospital network and provider contact details should not be world-readable. Cloudflare Pages can gate the whole site behind an email check (Cloudflare Access) at no cost for a small team.
2. Confirm the Ophthalmology & ENT grouping. It is marked as proposed on that page. If the committee says no, the eye and ENT topics move back under MSK/Trauma.
3. Name a reviewer per system. Each system already carries an owner. Pages need a named clinical reviewer before anything is marked reviewed.

2. Structure gaps

• No symptom-first index. An APP arrives with “abdominal pain”, not “pancreatitis”. Recommendation: add a chief-complaint index that links into the systems. The curriculum already contains most of the right topics, so this is a layer on top rather than new content.
• No medications section in the curriculum. Drug doses are the most-looked-up item in an emergency department. Recommendation: keep the Medications section, but fill it only with doses that carry a source. If the committee objects, drop it — no content is lost.
• No ECG or image library. Pattern recognition is taught with examples. Recommendation: add later, under Clinical Tools. Needs a licensing check before any tracing is published.
• No quick cards. These are the pages that actually get printed and taped inside a locker. Recommendation: build six to ten one-screen cards once the clinical pages have content.
• No curriculum status on the page. Reviewers cannot see what is done. Recommendation: already generated — the map carries status per topic, and the same field can drive a badge on each page.

3. Functional gaps

• Browser editing with approval. Use Decap CMS or Sveltia CMS, git-backed, with an editorial workflow (draft → review → publish). Because it is free, needs no database, and satisfies “editable by anyone, approved by administrators” without a server to maintain. It does require a GitHub account for the department.
• Login and roles. Use Cloudflare Access plus git permissions. Because real user accounts with in-app roles are a much larger build — do that only if the department asks.
• Offline use on a phone. Done — an installable app with an offline cache. Pages load in under a second on hospital wifi, and anything already opened stays readable with no signal at all. Verified by scripts/check-pwa.mjs.
• Knowing what gets used. Use privacy-respecting analytics (Cloudflare Web Analytics, no cookies). Because it tells the committee which pages are worth maintaining.
• Broken links inside clinical pages. Use a link checker in the build. Because the site has 170+ pages, and link rot is the failure reviewers never catch.

4. Content-safety gaps

1. Every dose needs a citation. The site currently states this rule and enforces it by convention. It cannot yet enforce it mechanically.
2. No “review due” date. A clinical page with no expiry silently becomes wrong. Add a review-by date per clinical page, and surface anything overdue.
3. No conflict flag. Where a page disagrees with a department policy, there is no marker. The content standards ask contributors to report conflicts; nothing records them yet.
4. Licensing. FOAMed material is not uniformly free to reproduce. Link and attribute; never paste from a non-commercial or no-derivatives source.

5. Things I would not add

• A comment section. It becomes a second, unreviewed source of clinical advice.
• User accounts with in-app approval. Start with the git-based workflow; the larger build is only worth it if the department commits to maintaining it.
• Anything requiring a server. A static site has no login to break, no database to lose, and no patching. That is the main reason it will still work in two years.

See Also

• Content Standards
• Review & Approval
• Curriculum Map