Where the project gathers
Everything OIDM produces is public. The four durable entry points are the GitHub organization, the project site, the Slack channel, and the deployed tools.
| Channel | Where | What it is for |
|---|---|---|
| GitHub organization | https://github.com/openimagingdata | Code, content, specifications, issue trackers |
| Project site | https://openimagingdata.org | Articles explaining the model, project news, registration for updates |
| Slack | The Radiology Informatics workspace at https://info-rad.slack.com, channel #openimagingdata | Discussion between meetings |
| Finding Model Forge | https://fmf.oidm.org | Authoring finding models through a browser |
| IPL viewer demo | https://imaging-problem-list.pages.dev | Seeing an Imaging Problem List rendered from real sample data |
The site’s participation post also invites registration for newsletter updates and article comments, describes working groups on use cases and standards work, and asks for help identifying related projects and venues where the work would have impact.1 That post dates from August 2023 and parts of it have aged: it advertises a working group on the TypeScript reference implementation, which is now a lineage repository rather than active work, and its meeting section is a placeholder. Treat the GitHub organization and the Slack channel as the current live channels. The site also carries a contact link for general inquiries.
The largest stated organizational goal is not yet a channel you can join. The January 2026 deck proposes an “ACR-OIDM Structured Imaging Results Working Group” co-hosted with the ACR, bringing expert and vendor participants into one venue, with a use-case pipeline feeding the ACR and RSNA common data element group.2 It is a proposal, not a convened body.
Repositories to start with
Pick by what you want to do. Every repository, including the lineage ones, is listed with its status and branch of record in the repository map.
| If you want to | Start at |
|---|---|
| Read or use the finding model content | openimagingdata/findingmodels, 2,382 definitions with a prose schema mirror |
| Build against the finding model format | openimagingdata/findingmodel, the Python library, CLI tools, and MCP server |
| Understand the data structures | openimagingdata/imaging-problem-list, whose main branch holds the stable Exam Finding List and Imaging Problem List specification and sample data |
| See extraction from narrative reports | The same repository’s dev branch, which holds the extraction, coding, persistence, and review platform |
| Look up codes across terminologies | openimagingdata/med-ontology-lookup, the molu library and CLI |
| Work on the authoring application | openimagingdata/FindingModelForge |
Several of these repositories have their current state on a branch other than main. Check the repository map before assuming the default branch is the live one.
Filing issues
Each repository carries its own issue tracker, and issues are where the work edge is visible. File against the repository that owns the thing you are reporting.
- A wrong, missing, or badly scoped finding model goes to
openimagingdata/findingmodels. The public catalog site routes its “Submit Issue” link there.3 - A bug or gap in the library, CLI, or anatomic location data goes to
openimagingdata/findingmodel. - A question about the data structures goes to
openimagingdata/imaging-problem-list. Its issue #1, asking for a formal model layer with JSON Schema export for Observation, Exam Finding List, and Imaging Problem List, is open and unclaimed. - Terminology lookup behavior goes to
openimagingdata/med-ontology-lookup.
Existing open issues are the best statement of what the project knows is missing. They are summarized by area under roadmap.
Contributing content
Content means finding models and the anatomic locations they reference. There are three routes, and they differ in how much of the work you do by hand.
Through Finding Model Forge. The browser application is the supported route for authoring a single finding model without cloning anything. You sign in with GitHub, name the finding, generate and edit a description and synonyms, generate the attributes, and the draft autosaves. Submitting locks the draft for review, and a reviewer moves it through under review to added or declined.4 Editing a model after creation is an open issue on that repository, not yet available.
Through the content repository. Definitions live as one JSON file per finding, validated on commit, with identifiers issued from a registry that detects duplicates. Batch authoring and review run through agent skills held in that repository. Contributing this way means working with the schema directly; the prose mirror of the schema is the reference.5
Through staged common data elements. Candidate definitions authored informally, ahead of formal review, are staged in openimagingdata/CDEStaging before entering the ACR and RSNA review pipeline that publishes through RadElement. That path is a manual curation workflow rather than an automated one.
Identifier discipline matters in all three routes. An OIFM identifier encodes its contributing organization in its letter block, and identifiers are never reissued or regenerated on a round trip. The authoring conventions are covered in the authoring workflow.
Contributing to this knowledgebase
This repository is the canonical high-level documentation, written as an Open Knowledge Format bundle so that both people and agents can read it. It describes and links to catalogs; it does not copy them. Code documentation, install steps, and developer workflow stay with the code.
Before editing anything here, read the authoring guide. It sets the document types, the required frontmatter, the trust workflow by which a draft becomes verified, the linking conventions, and the procedure for migrating a document out of a working repository. Two checkers run on every push and must pass: an Open Knowledge Format conformance validator and a house-rules checker that enforces the type vocabulary, index coverage, link resolution, and a sweep for names and email addresses.
Two house rules catch newcomers. Facts and stated goals only, with every goal citing the deck, issue, or plan that states it, because design proposals belong to a separate workstream. And organizations, not individuals: the project lead is named as such and nobody else is named.