Engaging clinicians, researchers, and patient partners in shared biomedical resources

The problem includes more than unfamiliar software. A person may understand the clinical issue but lack time, confidence, institutional recognition, a clear place to start, or evidence that anyone will respond. Calling this a motivation deficit can obscure a reasonable assessment of the effort required and the likelihood of a useful result.

Research on newcomers to open source projects identifies social interaction, prior knowledge, finding a starting point, documentation, and technical barriers. The COM-B framework distinguishes capability, opportunity, and motivation as the conditions that shape behavior. These are useful design lenses, although they do not establish that a particular intervention will succeed in biomedical standards communities, so test the proposed program locally. [1,2]

Run a small discovery exercise before launch: interview approximately three people from each priority stakeholder group, plus several maintainers. Ask them to complete a sample task while explaining where they hesitate. Ask what they would need to contribute again. Include people who declined previous invitations. These are proposed recruitment numbers, not a representative sample.

When offering tasks, ask separately about the expertise someone wants to contribute and the interface they want to use. A senior scientist may prefer a form; a patient partner may prefer GitHub. Never assign a technical ability level solely from a professional or community role.

A disease ontology organizes disease concepts and their relationships. A phenotype ontology describes features, such as a seizure type or a physical finding. An annotation links a disease to a feature with evidence. A data model specifies how records are organized. A mapping relates concepts across systems. A research cohort definition specifies which records count for a particular study. These objects can disagree for different reasons and require different corrections.

Important boundaries. Mondo does not determine every clinical diagnostic criterion. OHDSI is a community and ecosystem, not a single terminology. OMOP disease identification depends on the vocabularies, mappings, source data, and study logic in use. GA4GH is an alliance with multiple products; Phenopackets is one relevant standard for representing phenotypic and associated information. HPO is included here because many apparent disease definition concerns are phenotype or annotation concerns. [3–10]

An edit in Mondo does not automatically change OMOP mappings, clinical records, a Phenopacket implementation, or a published analysis. Identify the actual dependency before describing an expected benefit. A study that uses a frozen concept list may be unaffected until its team explicitly updates that list.

Routing a new observation

First capture the exact page, concept identifier, file, or study rule and its version. Ask whether the problem concerns meaning, classification, missing evidence, mapping, data structure, implementation, or presentation, and then identify the owner. If the distinction is unclear, the coordinator and a domain reviewer should route it together rather than returning the problem to the contributor.

For a cross-project concern, create one local parent record with linked requests to the relevant owners. For example, a missing disease distinction might need a Mondo discussion, an HPO annotation review, and a local cohort revision. Avoid posting identical unsorted requests in several repositories.

A useful explanation connects the representation problem, the operation that uses it, the records or conclusions affected, the proposed correction, and the test that would demonstrate improvement. A broad statement that better terminology improves research is less persuasive than a reproducible example.

The pathways below are plausible mechanisms. The direction and size of any effect depend on the data set and implementation; correcting terminology does not necessarily change an estimate.

Cohort misclassification can alter prevalence estimates and the composition of exposed and comparison groups. Missing severity or subtype information can affect confounding control. Errors correlated with site or access to specialist assessment can undermine transportability. A change may increase or decrease an association; avoid promising a particular statistical direction.

Distinguish shared knowledge quality, local data quality, and study design quality. A correct ontology cannot repair information never collected. A complete record does not guarantee a valid causal analysis. A more precise disease category does not establish that a candidate drug is effective or that someone is eligible for a trial.

ALS example A: Family history is not genetic testing status

Concern. A hypothetical registry uses one field with the choices familial, sporadic, and unknown, and a downstream analyst treats sporadic as genetically negative. This conflates reported family history with the presence of an identified disease-associated variant. ALS genetic testing consensus guidance recognizes a genetic basis in some clinically sporadic cases and recommends offering testing to all people with ALS. [11]

Research consequence. A genotype-defined study may miss potentially relevant records. Comparisons of genetic and apparently non-genetic groups may be misclassified. Differences in testing access may become differences in estimated genetic frequency. A targeted therapy or natural history project may begin with an inaccurate feasibility count.

Contribution. A clinician or researcher can report the wording and suggest separate fields for family history, whether testing occurred, test scope, result interpretation, gene or variant when appropriately available, and report date, with an explicit unknown state. A disease definition concern goes to its ontology owner; a registry field or cohort error goes to the registry or study team.

Validation. Review whether people without a reported family history can still be represented as having a relevant genetic finding. Confirm that not tested, negative within the tested scope, uncertain significance, and relevant pathogenic or likely pathogenic findings remain distinguishable. Keep SOD1 visible as an explicit example without implying that all SOD1 variants have the same interpretation or prognosis.

ALS example B: Nonmotor information disappears from a motor-focused representation

Concern. A hypothetical disease summary or extraction specification includes weakness and respiratory decline but omits cognitive and behavioral features. Consensus ALS frontotemporal spectrum criteria recognize substantial clinical heterogeneity extending beyond motor manifestations. [12]

Research consequence. A study of coping, resilience, participation, caregiver burden, or survival may omit relevant covariates or misunderstand missing patient-reported information. A patient community may also find that the description excludes experiences they consider central.

Contribution and test. Patient partners identify missing domains; clinicians distinguish supported associations from individual observations; researchers specify how each domain will be measured. Review the disease summary, annotation source, registry questionnaire, and study specification separately. Test whether the revised representation captures observed, absent, and unassessed features without labeling every person with ALS as cognitively impaired.

ALS example C: A hierarchy or mapping changes cohort membership

Concern. A hypothetical query for ALS includes all descendants of a broader motor neuron disease concept, although the protocol requires ALS specifically. Alternatively, a narrow concept list omits relevant ALS concepts. Neither problem can be resolved by assuming every related motor neuron disease is equivalent to ALS.

Research consequence. The resulting cohort can mix disease groups or exclude valid cases. Frequencies, progression patterns, survival, and biomarker associations may change because membership changed.

Contribution and test. Record the concept identifiers, vocabulary release, descendant settings, exclusions, and clinical inclusion criteria. A terminology steward checks the relationship, and a clinical reviewer checks its study use. Compare membership and adjudicate discordant examples. OMOP hierarchy behavior should be checked in the relevant vocabulary tables, including CONCEPT_ANCESTOR, rather than inferred from a Mondo diagram. [13]

ALS example D: Timing and exposure definitions change interpretation

A protocol that measures survival from symptom onset cannot substitute the first electronic health record (EHR) diagnosis date without explaining the change. Likewise, a residential proximity measure is not equivalent to an individually measured environmental exposure, and a patient's concern is not proof of causation. Contributors can identify ambiguous definitions and ask for separate variables, provenance, time windows, and uncertainty.

These corrections can improve a progression or environmental study specification, but they do not establish a mechanism or treatment target. For drug development, connect an exposure or phenotype hypothesis to biological evidence, target engagement, experimental models, and appropriate clinical evaluation. A terminology edit is one input to that sequence.

Epilepsy example A: Infantile epileptic spasms syndrome and West syndrome

Concern. A hypothetical screening rule uses West syndrome as an exact substitute for all infantile epileptic spasms syndrome, or requires documented hypsarrhythmia for every candidate. The International League Against Epilepsy (ILAE) describes infantile epileptic spasms syndrome (IESS) as encompassing West syndrome and infants with epileptic spasms who do not meet all classic West syndrome criteria. Its diagnostic guidance should be consulted directly rather than reduced to a single billing code or symptom. [14,15]

Research consequence. A literature search, registry recruitment process, or retrospective cohort may omit relevant children. A historical terminology crosswalk can also erase distinctions between a seizure type, an age-defined syndrome, an electroencephalogram (EEG) finding, and an etiologic diagnosis.

Contribution. Ask for review of synonym scope and the actual case definition. Preserve historical wording and source dates. In a cohort, distinguish documented syndrome, a possible case requiring review, and isolated evidence of spasms. A clinical lead should adjudicate the criteria; a terminology editor should decide how to represent the relationship.

Validation. Use fictional examples with different seizure, age, EEG, and developmental information. Test the intended inclusion and exclusion rules. A broader candidate search may improve sensitivity while requiring further clinical confirmation.

Epilepsy example B: SLC35A2 and tissue-specific mosaicism

Concern. A hypothetical knowledge resource presents every SLC35A2-associated presentation as having the same systemic findings and testing pathway, or an analysis treats a negative blood result as excluding a brain-limited variant. Primary research identified somatic SLC35A2 variants in resected brain that were absent from paired leukocytes. Subsequent work supports an association with mild malformation of cortical development with oligodendroglial hyperplasia in epilepsy (MOGHE), a histopathologic entity. These findings do not mean every SLC35A2-related epilepsy has MOGHE. [16,17]

Research consequence. A cohort may miss tissue-detected cases, combine distinct ascertainment groups, or confuse absence of a detected variant in a specimen with absence throughout the person. Genotype to phenotype analyses, assay performance estimates, surgery studies, and mechanism-based treatment hypotheses can then become difficult to interpret.

Contribution. A geneticist, neuropathologist, epileptologist, researcher, or family partner can request clearer distinctions between phenotype, disease label, specimen, test method, result, and interpretation. Do not assume that sharing a gene makes every presentation interchangeable. Do not frame surgery and investigation of systemic therapies as inherently mutually exclusive.

Validation. Use fictional records with blood-only testing, tissue testing, different results, and unknown test scope. Preserve links between a finding and its biosample. Phenopackets provides structures for phenotypic features, biosamples, and genomic interpretation; first test whether existing structures meet the use case before proposing a schema extension. [18,19]

Epilepsy example C: A distinctive nonseizure feature is omitted

Ng and colleagues reported inverted nipples in 8 of 30 individuals in their SLC35A2 congenital disorder of glycosylation (SLC35A2-CDG) cohort. That is a cohort-specific observation, not a population prevalence estimate, a required diagnostic sign, or evidence that the same frequency applies to brain-limited mosaic epilepsy. [20]

If a disease annotation omits a supported feature, a phenotype-based search may lose a potentially informative match. A contributor can identify the source and request an annotation review, including cohort, numerator, denominator, and ascertainment limitations. If the HPO term already exists, the task may be to add or correct an association rather than create a new term.

Patient communities can identify which observations are missing from intake questions and descriptions. Their reports deserve a respectful response, with individual experiences distinguished from established disease-level associations. A symptom alone should not be used to infer a genetic diagnosis.

Epilepsy example D: Syndrome evolution and missing information

A child's current syndrome, earlier seizure types, and later etiologic findings may all be relevant. A hypothetical database that overwrites an earlier IESS diagnosis when Lennox-Gastaut syndrome (LGS) is documented loses longitudinal information. Conversely, assigning LGS to every child with severe epilepsy and intellectual disability overgeneralizes a syndrome with specific clinical and EEG criteria. [21,35]

Ask contributors to review the timeline and evidence supporting each label. Distinguish historical from current findings, syndrome from etiology, and missing EEG documentation from a normal EEG. A Phenopacket feature marked excluded represents a documented absent feature; lack of information should not be converted into exclusion. [18]

Demonstrate an effect without overstating it

Use a teaching data set with 200 fictional records: 100 independently designated eligible and 100 ineligible. Suppose a revised rule produces the following results. The numbers are invented to demonstrate evaluation, not observed outcomes or targets.

The teaching message is that a definition or mapping can change who is counted. In real evaluation, use an independent reference assessment, report uncertainty and reviewer disagreement, and examine errors by subgroup. Positive predictive value depends on the evaluated population; this balanced teaching sample does not estimate performance in routine clinical data.

Invite people to a bounded scientific or community task, state the expected time, and tell them who will respond. Prioritize participants closest to the first two use cases, while maintaining an open route for other observations. The coordinator should assemble complementary teams rather than asking each contributor to supply all needed expertise.

Clinicians and clinical trainees

Most useful contributions. Identify misleading definitions, inappropriate inclusion or exclusion rules, missing clinical qualifiers, outdated terminology, and distinctions between suspected and confirmed disease. Include nurses, therapists, genetic counselors, and allied health clinicians when the task concerns their expertise.

Invitation and first task. At an existing ALS or epilepsy case conference, present one fictional record and one proposed definition. Ask, “Would this rule include the intended person, and what information is missing?” Offer a five-minute form or a 15-minute facilitated review. The clinical champion recruits through existing departmental and professional networks.

Support and recognition. Preselect the source, explain the downstream query, and pair the clinician with a terminology steward. Offer documented service contributions and institutional protected time where feasible. Provide a short response showing whether the clinical distinction was retained. Do not advertise continuing education credit unless an accredited activity has been arranged.

Success measure. Reviewable clinical concerns and resolved clinical ambiguities per hour contributed, with evidence of a better definition or case specification.

Researchers and analysts

Most useful contributions. Report cohort inconsistencies, mapping failures, missing metadata, reproducibility problems, and discrepancies between a paper and its computable implementation. Include basic scientists who can evaluate mechanism and model-system distinctions.

Invitation and first task. Use a study design meeting or analysis seminar to ask for one example in which a concept choice changes the question or selected records. Offer a 15-minute submission containing the research question, version, expected result, observed result, and a fictional or approved aggregate example.

Support and recognition. Provide a standard evidence packet and help reproduce the issue. Recognize conceptual work, validation, and curation as well as code. Offer a contribution record suitable for a CV, report, or grant narrative. Publication authorship must follow the applicable criteria and contribution agreement.

Success measure. Reproducible problem reports, validated study improvements, and confirmed downstream adoption. A statistically different result is not itself proof of improvement.

Students and early career contributors

Most useful contributions. Check citations, compare synonyms, identify broken links, create fictional examples, test onboarding instructions, and prepare supervised evidence summaries. Advanced students can evaluate mappings or write tests with appropriate oversight.

Invitation and first task. Recruit through informatics, medicine, public health, genetics, library science, rehabilitation, and patient engagement courses. Give each student one bounded task in a practice repository or shared worksheet. Pair students with a domain mentor and a technical mentor, who may be the same person when qualified.

Support and recognition. Provide a model submission, a rubric, office hours, and a chance to revise. Award course credit for reasoning and responsiveness. A well-supported conclusion that no change is needed can be excellent work. Obtain permission before publicly identifying students or publishing their work.

Success measure. Evidence quality, correct scope, useful review, and learning gains. Do not grade students on whether an external maintainer merges a change or on the number of public issues they create.

Domain experts

Most useful contributions. Resolve difficult disease boundaries, assess inheritance or mosaicism claims, review mechanism, evaluate phenotype evidence, and distinguish a true disagreement from different purposes for classification. Relevant experts may be clinicians, researchers, curators, or community members with specialized knowledge.

Invitation and first task. Send a one-page comparison with two or three explicit questions before a 30-minute review session. Recruit through specialty societies, disease working groups, existing curation collaborations, and professional networks. Identify potential conflicts of interest.

Support and recognition. A facilitator records rationale and unresolved questions. An ontology or standards specialist explains modeling consequences. Use repeatable review rotations, agreed acknowledgment, and paid consultation when sustained effort warrants it.

Success measure. Ambiguities resolved with evidence, distinctions preserved, and clear explanations when consensus is not reached. Seniority and the number of supporters should not substitute for evidence.

People with ALS and pediatric epilepsy communities

Most useful contributions. Identify missing experiences, confusing language, stigmatizing descriptions, burdensome forms, inaccessible workflows, and research questions that omit community priorities. Parents and caregivers may contribute relevant observations; people with the condition should also be supported to participate directly when possible.

Invitation and first task. Through a trusted community partner, ask, “What is missing or misleading in this description, and what would you want a researcher to understand?” Offer a five-minute form, assisted interview, or review of three plain language statements. Never require sharing a personal medical history to contribute.

Support and recognition. Provide compensation for advisory time, accessible formats, flexible response windows, and preferred communication methods. For ALS, support typing, eye-gaze or other augmentative communication, fatigue management, and asynchronous participation. For pediatric epilepsy, accommodate caregiving schedules and distinguish caregiver observations from the child's own communication. Include youth perspectives through an appropriate supported process.

Success measure. Community priorities influence decisions, participants understand the result, and repeated participation is voluntary and feasible. Assess influence and accessibility, not just attendance. A diagnosis need not be verified to offer feedback on wording or usability.

Stakeholders who make the program sustainable

All routes should produce the same minimum evidence record and access to feedback. A contributor should be able to remain on an assisted route indefinitely.

OHDSI already offers forums, Teams, community calls, and working groups. GA4GH offers Work Streams, Communities of Interest, and open calls. Mondo describes assisted contacts and curation discussions while retaining GitHub issues for term requests. Use these routes instead of treating GitHub training as the sole entry point. [4,7,9,10]

Host monthly paired sessions: a short introduction for newcomers and a focused review for active contributors. At conferences, use QR codes linked to a specific question, such as reviewing a definition displayed on a poster. Obtain permission before recording sessions, and prepare written or captioned alternatives.

Design the entry page around one useful action

Recommended introductory text: “Help improve how ALS and pediatric epilepsy are described in shared research resources. You can report a missing feature, unclear definition, incorrect relationship, or data problem without any coding experience. A reviewer will help identify the appropriate project and explain what happens next.”

Display the choices Report something, Review a short example, and Get help contributing. Show the expected effort, whether a submission will be private or public, and the response target. Do not require choosing Mondo, OHDSI, or GA4GH before someone can describe the concern.

Recommended architecture

Google Forms can collect contributions, but a form is only the intake interface. The program also needs restricted storage, a reviewer, an integration, and status feedback. The initial implementation should follow these steps:

1. The contributor submits the form to a restricted response store. A submission identifier and receipt are created.

2. The coordinator checks relevance, duplicates, confidential content, and permission to publish a summary. A domain reviewer helps clarify the concern when needed.

3. The coordinator writes or verifies a separate publication summary. Only approved fields become an outgoing payload.

4. An integration creates an issue in the designated program repository, or in an upstream repository if that project's maintainers have agreed to the workflow. It records the issue URL and time.

5. The reviewer links any upstream request, decision, implementation, and release. A separate feedback process tells the contributor what happened in their preferred channel.

6. The downstream owner confirms whether the released change was adopted and whether a relevant test changed.

An automatically created issue is a request for review. It does not edit an ontology or merge a change. For public community submissions, moderation protects against accidental publication of identifying details and reduces avoidable work for maintainers.

Form specification

Use a short first screen and optional detail sections. Do not make citations or a proposed solution mandatory for someone reporting an observation. Collect contact information separately from the text eligible for publication.

The follow-up section for reviewers should capture the source version, current and proposed text, issue type, evidence strength, relevant identifiers, owner, status, related issues, expected impact, acceptance criteria, and next update date. This detail should not burden the initial contributor.

For a public no-account route, test the form while signed out. As of November 2026, Google’s help pages state that “Limit to 1 response” requires Google sign-in and that file upload questions also require sign-in. Organization-level settings can impose additional restrictions. Avoid file uploads in the initial public form, keep response summaries private, and do not describe a form as anonymous if email collection or other identifying fields are enabled. [22,23]

Build and operate the integration

Ownership. Use an institutionally managed account with a named owner and backup. Restrict response-store, script, and credential access. Keep the original response unchanged and store the reviewed publication text separately. Contact details should never be copied into a public issue by default.

Trigger design. An installable form-submission trigger can validate a response and assign its identifier. Google documents that installable triggers run as their creator. Use a scheduled worker or explicit reviewer action to publish rows marked approved; do not rely on every script or API change to invoke another trigger. Match event handling to the chosen Forms or Sheets trigger type. [24]

GitHub action. The worker sends the approved title and body to POST /repos/{owner}/{repo}/issues using the GitHub REST application programming interface (API), then saves the returned issue number and URL. Prefer a GitHub App for a maintained service; a narrowly scoped, expiring fine-grained token may suit a small pilot. Use only the permissions required, including issue-write permission for issue creation. Upstream repositories have their own access and automation policies. [25]

Configuration and secrets. Keep repository routing in a fixed allowlist, not a user-entered destination. Never put credentials in a form, spreadsheet cell, public repository, or client-side page. For a small restricted Apps Script pilot, Script Properties can hold configuration, but they are not a security boundary against script editors. A managed secret service is preferable when the deployment warrants it. [26]

Reliability. Use a durable submission identifier, publication state, and an idempotency ledger so retries do not create duplicate issues. Include a nonidentifying submission marker in the issue. If a request times out after GitHub may have accepted it, reconcile against existing issues before retrying. Lock concurrent workers, retry transient failures with limits, and send unresolved failures to a human queue. Track token expiry and service quotas. [25,27]

Content handling. Publish an explicit allowlist of fields. Treat submitted text as data, limit length, neutralize unwanted mentions, and protect spreadsheet exports from formula interpretation. Automated screening can flag content for human review; it cannot guarantee that health information is safe to publish. Do not send raw responses to an external AI service without an approved basis and clear participant notice.

Two-way feedback. Creating issues is only half the workflow. Initially, let the coordinator reconcile status weekly and send updates. Later, use authenticated webhooks or scheduled API polling to identify changes, with a human review of messages when technical discussion needs translation. A no-account contributor should not have to monitor GitHub to learn the outcome.

Choosing an implementation approach

These are architecture options rather than a recommendation of a specific commercial vendor. If the institution uses Microsoft tools, an approved form and automation equivalent can implement the same process. A REDCap workflow may suit an institution already supporting it, but this engagement channel should not become an unplanned patient registry.

Tests before public launch

Test signed-out access, mobile use, keyboard and assistive technology use, duplicate submissions, missing links, conflicting permissions, restricted-content examples, API failure, expired credentials, retry after uncertain success, and status feedback. Confirm that a private submission remains private and that no contact details appear in the public issue. Test staff handover and a manual fallback during an outage. Use fictional content for all launch tests.

Maintain an explicit status record

A closed GitHub issue may represent a duplicate, a declined proposal, or a completed change. A merged pull request may precede a release. Keep these distinctions explicit in both the tracking record and participant messages.

Triage and review rules

Provide an automated receipt when contact is available, a proposed human triage target of five business days, and a status update at least every 30 days for active requests. These are suggested local service targets, not promises from Mondo, OHDSI, or GA4GH. Adjust recruitment if the team cannot meet them.

Prioritize demonstrated misclassification or loss of meaning, then clear evidence gaps and usability barriers. Consider affected use, severity, reproducibility, and reviewer effort. Rare or underrepresented populations should not lose priority solely because their record counts are small. Do not equate popularity with scientific validity.

Use a domain reviewer for meaning and evidence, and a technical steward for modeling and implementation. Patient partners should help review relevance, language, burden, and whether the proposed change addresses the original concern. For major definitions, hierarchy changes, or disputed claims, obtain additional independent review and use the owning project's governance process.

Turn a disagreement into a testable proposal

Ask which of these is disputed: the wording, the underlying disease boundary, the intended research use, the strength of evidence, or the classification system's modeling convention. Record current wording and identifiers, the proposed alternative, who would be included or excluded, supporting and conflicting evidence, and unresolved uncertainty.

A useful clinical distinction may belong in a research phenotype rather than a new disease class. A preferred community term may be a display label or scoped synonym rather than a replacement for a technical definition. A disagreement can be resolved by clarifying purpose, preserving alternatives, or documenting uncertainty; it need not always result in a new term.

Avoid “vote to determine truth” exercises. When consensus is not reached, retain the competing rationale, ask an independent reviewer to assess it, and document what evidence would justify reopening the request. Only authorized upstream maintainers approve upstream changes.

Preserve attribution and evidence

Record the contributor's chosen credit, the reviewers, the sources, the decision, and the implementation link. Keep source wording distinct from the coordinator's interpretation. For observational reports, record that the evidence is an individual or community observation. A literature-supported association, a hypothesis, and a classification proposal should be recognizable as different contribution types.

Agree on a retention period for private contacts and raw responses before recruitment. Explain that public contributions may be copied or retained in history and cannot be guaranteed removable everywhere. If identifiable material is posted accidentally, stop further publication and use the host's removal process with the appropriate institutional contact. This workflow is for improving shared resources, not for individual medical advice.

Explain the vocabulary in ordinary language

An issue or comment does not edit the project's files. In an ordinary public contribution workflow, maintainers review proposed file changes before incorporation. This distinction can reduce fear without implying that every click or every public post is reversible.

Read and comment without installing software

1. Open the project link and read its README and contribution guidance. Check that the repository is active and is the owner of the content.

2. Search issues using the term, identifier, or topic. Read both open and closed discussions when relevant.

3. If the concern already exists, add new evidence or explain your use case there. A brief agreement can be useful when it includes a concrete consequence.

4. To post on GitHub, sign into an individual account. Choose a public profile and username that you are comfortable associating with your contribution, and do not share accounts.

5. If no matching issue exists, open Issues and choose New issue, where enabled. Use the project's current template. [29]

6. Describe what you saw, where you saw it, the suggested change or question, and the evidence, stating uncertainty plainly.

7. Review the text for confidential content, submit it, and retain the link. Use the thread's notification controls to follow the conversation.

A contributor can do this in a browser without GitHub Desktop, a command line, or knowledge of Git. If account creation, permissions, or repository settings prevent participation, use the assisted route.

Review a pull request as a domain expert

Open the linked request and read the problem statement. In Files changed, inspect the relevant text and surrounding context. Additions and removals are marked; do not rely on color alone. Ask a steward for a before-and-after prose summary if the file is difficult to read. [30]

Check whether the proposal addresses the original concern, preserves qualifiers, cites suitable evidence, and avoids adding unsupported claims. For a hierarchy change, ask what else becomes included or excluded. For a mapping, ask whether the source and target have the same meaning. For a schema example, check the specimen, timing, uncertainty, and provenance.

Comment on the relevant line or on the conversation. State the scope of your review, for example, “I reviewed the clinical wording and cited evidence; I did not assess the code.” If you start a pending review, submit it so others can see the comments. Formal approval and blocking-review permissions depend on repository policy. The maintainer handles merge decisions. [30]

Make a small file edit when ready

For a simple documentation correction, follow the repository's instructions and use its browser editing workflow if permitted. Propose the change through a branch or fork and a pull request, link the issue, and explain the expected behavior. Specialized ontology and generated files may require dedicated tools, so ask a steward before editing them and practice in a training repository first.

Do not make a pull request a prerequisite for domain contribution. Teach only the next step the person wants to take, and offer a written one-page reference after the session.

A sequence of learning sessions

Allow approximately 45 to 60 minutes per session, with asynchronous alternatives. Offer an optional 20-minute introduction for contributors who only want to report a concern. Maintain a mentor office hour and a rotating set of small, clearly bounded tasks.

Use GitHub Education for supervised contribution

GitHub Classroom supports individual and group assignments and feedback pull requests. Create a practice repository with fictional cases, source excerpts or links, a model issue, and a review rubric. Students can work in pairs combining clinical or research expertise with informatics skills. Faculty review the work before any upstream submission. [31,32]

As of November 2026, GitHub Education's Student Developer Pack has eligibility requirements, including current enrollment in a qualifying program, an individual GitHub account, and a minimum age of 13. It is not a requirement for ordinary participation in a public repository. Verify eligibility and institutional arrangements directly; do not promise benefits to every researcher or learner. GitHub's learning resources can supplement the biomedical examples, and when this guide's sources were checked on November 9, 2026, the former GitHub Skills entry point redirected to GitHub Learn. [33,34]

Suggested assessment rubric. The proposed weights are evidence accuracy 30 percent; explanation of downstream consequences 25 percent; correct scope and routing 20 percent; quality of review and revision 15 percent; and clear, respectful communication 10 percent. Accept equivalent submissions through a document or form when required for access.

Manage upstream burden. Arrange the exercise with maintainers before the course begins. Use a practice environment, consolidate duplicate findings, send only reviewed requests, and let maintainers set a volume limit. A class of 30 students should not generate 30 unreviewed tickets for the same concern.

Support mentors and train the next facilitators

Give mentors a short checklist, sample feedback, and an escalation contact. Limit each mentor's active review load. After two rounds, invite interested participants to co-facilitate an exercise, review a first submission, or help explain a release. Progression is optional; sustained expert contribution through a familiar channel is equally valuable.

Publish a monthly plain language digest with a small number of examples. For each, show the original problem, who contributed in the form they chose, the decision, the release or implementation link, the affected downstream use, and what has or has not yet been tested. Include useful clarifications and justified no-change decisions.

Use evidence levels for impact: anticipated, demonstrated in a fictional or test example, observed in a specified implementation, and independently replicated. A change can be valuable before full downstream evaluation, but its impact claim should match the evidence.

For example: “A contributor identified that our registry combined family history with genetic testing status. The registry team separated the fields and revised the export specification, and the change is implemented locally. Its effect on study feasibility counts will be assessed after the next data refresh.” This is more informative than announcing that a ticket was closed.

Offer opt-in acknowledgment, contributor roles, ORCID where supported, certificates describing completed work, and periodic contribution summaries for supervisors. Mondo's term-request guidance includes ORCID for attribution. Do not promise that every small change will receive a DOI, publication authorship, or a specific upstream credit mechanism. [3]

Budget payment or protected effort for sustained community advice, expert review, coordination, and maintenance. Avoid leaderboards based on ticket counts. They can encourage unnecessary submissions and undervalue careful review, documentation, and resolving ambiguity.

Scope and timeline

An upstream standards decision or release may take longer than 90 days. Evaluate the quality of the submitted work and communication without treating the absence of a release as automatic failure.

Start with an ALS review focused on genetic status and nonmotor representation, and an epilepsy review focused on syndrome scope and tissue-specific evidence. Recruit through existing research meetings, clinical teaching sessions, patient community partners, and informatics courses. Seek approximately five to eight participants from each priority group, allowing overlapping roles. Recruitment targets are planning assumptions, not statistical requirements.

Roles and capacity

This illustrative model totals 19 staff or advisor hours per week, or 228 hours over 12 weeks, plus an estimated 30 to 50 hours for setup. Some roles may be combined, but maintain backup coverage. Upstream maintainer effort is additional and must be discussed explicitly.

Calculate the budget as each role's hours multiplied by its institutionally appropriate rate, plus advisor compensation, accessibility support, translation, platform costs, and contingency. These hours are a planning scenario rather than a market cost estimate, and they should be recalibrated after the first ten submissions.

Use a capacity rule: weekly review capacity equals available review minutes divided by the observed median handling time, allowing time for complex cases and follow-up. At 240 review minutes and 30 minutes per routine case, nominal capacity is eight cases; reserve part of that time for disputes and unfinished work. If the queue exceeds two weeks of realistic capacity, slow recruitment and tell contributors the revised timeline.

Make recurring work visible

Each week, review new submissions, blocked items, failed automation, and overdue responses. Each month, review one impact example, contributor feedback, workload, and representation gaps. Each quarter, check ownership, links, access settings, credentials, training materials, and the continued relevance of the two use cases. Maintain a short handover document so the program does not depend on a single person.

Measure the progression from invitation to participation, review, decision, release, adoption, and assessed impact. Report both denominators and time windows. A rise in submissions with no review capacity is not a successful engagement outcome.

Proposed initial process targets, set as local planning goals, are 90 percent of submissions receiving human triage within five business days, every decided request having a documented rationale, and two completed demonstrations of downstream evaluation during the pilot. Set acceptance, release, and adoption expectations after observing the types of requests and upstream review schedules.

Compare the pilot with a documented baseline when available. If comparing invitation messages or interfaces, use similar tasks and disclose differences in participant composition. Small pre-and-post comparisons can guide improvement but cannot establish that the program caused a research benefit. If the evaluation is intended as human-subjects research, obtain the institution's determination about the appropriate review and consent process before collecting research data.

For a hierarchy or mapping change, preserve the original and revised versions, run the same query, inspect added and removed records, and obtain independent clinical assessment where feasible. For a language or accessibility change, test comprehension and task completion. For a schema change, evaluate round-trip preservation of meaning and compatibility. For a disease annotation, verify evidence and assess a fixed relevant retrieval task.

Report an effect only at the level tested. An improved search example does not prove shorter diagnostic delay. A more accurate cohort does not establish improved treatment outcomes. A no-change result may reveal that a downstream tool did not depend on the corrected resource, which is useful information for the next implementation step.

Contributor submission

Title: Review the description or representation of [topic].

Where I noticed it: [URL, identifier, resource, file, or unknown].

What seems wrong or incomplete: [Brief description in your own words].

Why I think it could affect research or understanding: [Example, or request for help explaining].

Suggested wording or question: [Optional].

Evidence: [Publication, public reference, or clearly identified observation].

What I am unsure about: [Optional].

Publication and credit preferences: [Publish a reviewed summary / contact me first / keep private; chosen name or no public attribution].

Reviewer evidence packet

Record the submission ID; source and version; exact current representation; proposed change; owner and scope; supporting and conflicting evidence; example affected use; inclusion and exclusion consequences; related issues; review participants; decision rationale; validation criterion; and next action with an owner and date.

For a hierarchy request, add the current and proposed parent identifiers and expected descendants. For a mapping request, add source and target identifiers, releases, relationship type, and lost qualifiers. For a phenotype association, add disease context, evidence source, frequency denominator if known, age or onset context, and ascertainment limitations. For a schema request, add an example that the existing schema cannot represent adequately and the attempted alternatives.

Fictional worked submission for ALS

Title: Separate family history from genetic testing status in the registry export.

Current issue: The export has one field labeled familial or sporadic. Our draft analysis treats sporadic as a negative genetic test result.

Requested review: Determine whether separate variables should represent family history, test status, tested scope, and result interpretation. The concern is about our export and analysis specification; an upstream ontology defect has not been demonstrated.

Evidence and consequence: ALS genetic testing guidance recognizes genetic findings in people without a reported family history. The current rule could misclassify a genotype-defined subgroup. [11]

Acceptance criterion: Fictional cases with no reported family history and a relevant finding, no testing, and a negative result within a specified tested scope produce distinct outputs. A clinician and analyst review the revised rule.

Fictional worked submission for pediatric epilepsy

Title: Preserve the specimen associated with an SLC35A2 test result.

Current issue: Our demonstration export stores one person-level positive or negative genetic result and omits specimen information.

Requested review: Test whether existing Phenopackets structures can preserve the biosample and its linked interpretation. Use the product's implementation guidance before proposing a schema change. [18,19]

Evidence and consequence: Brain somatic SLC35A2 findings absent from paired leukocytes have been reported. A blood-only negative result should not be interpreted as excluding a variant in unsampled tissue. [16]

Acceptance criterion: A fictional example with distinct blood and brain results retains the correct specimen-result associations after export and reimport, and unknown information stays recorded as unknown.

Receipt

“Thank you for your contribution. Your reference is [ID]. [Name or role] will review it by [date]. We will help identify the appropriate project. Your submission is currently [private / approved for publication as a reviewed summary]. You can reply through [channel].”

Clarification request

“We understand your concern to be [summary]. To review it, we need [one specific detail]. If you do not have that information, we can help look for it. Our next update will be by [date].”

Decision and outcome update

“You identified [concern]. The reviewers decided [decision] because [reason and evidence]. The change is currently [status]. [Named resource or study] will need to [next adoption step]. We have demonstrated [tested effect], and have not yet assessed [remaining question]. Your contribution is acknowledged as [chosen credit].”

A respectful no change response

“Thank you for explaining [concern]. After reviewing [evidence and scope], the project will retain [current representation] because [reason]. Your suggestion has helped clarify [specific point]. We have recorded [remaining uncertainty or alternative route], and the request can be reconsidered if [new evidence or condition].”

One month impact summary

Record the question; contribution type; contributor credit preference; decision and rationale; issue and release links; original and updated versions; downstream consumer; test method; observed result; limitations; and remaining work. Separate anticipated benefits from measured outcomes. Publish only the information approved for public use.

Sources below support clinical distinctions, existing contribution routes, and platform capabilities. The proposed program design, workload estimates, fictional cases, and performance targets are recommendations developed for this guide. Web documentation can change; check the owning project's current instructions before implementation. Accessed November 9, 2026.

1. Steinmacher I, Silva MAG, Gerosa MA, Redmiles DF. A systematic literature review on the barriers faced by newcomers to open source software projects. Information and Software Technology. 2015;59:67–85. Article

2. Michie S, van Stralen MM, West R. The behaviour change wheel: A new method for characterising and designing behaviour change interventions. Implementation Science. 2011;6:42. Open access article

3. Mondo. How to Make a Good Term Request. Includes identifiers, definitions, references, relationships, and attribution. Guide

4. Mondo. Curation Workflow Overview. Describes review, assisted participation, and release stages. Workflow and repository

5. Human Phenotype Ontology. Contributing and workshops. Contribution guide

6. OHDSI. Vocabulary Request and standardized vocabulary repository. Request guidance and repository

7. OHDSI. Join the Journey and workgroups. Participation and workgroups

8. OHDSI. How to Request Changes to the CDM. Process

9. GA4GH. Get involved. Participation routes

10. GA4GH. Open calls. Check current status and deadlines rather than relying on a past call. Open calls

11. Roggenbuck J, et al. Evidence-based consensus guidelines for ALS genetic testing and counseling. Annals of Clinical and Translational Neurology. 2023. Article

12. Strong MJ, et al. Amyotrophic lateral sclerosis frontotemporal spectrum disorder: Revised diagnostic criteria. Amyotrophic Lateral Sclerosis and Frontotemporal Degeneration. 2017;18:153–174. Open access article

13. OHDSI. OMOP Common Data Model conventions, including concept relationships and ancestors. Documentation

14. Zuberi SM, et al. ILAE classification and definition of epilepsy syndromes with onset in neonates and infants. Epilepsia. 2022. Position statement

15. ILAE EpilepsyDiagnosis. Infantile epileptic spasms syndrome diagnostic criteria. Criteria

16. Winawer MR, et al. Somatic SLC35A2 variants in the brain are associated with intractable neocortical epilepsy. Annals of Neurology. 2018. Open access article

17. Bonduelle T, et al. Frequent SLC35A2 brain mosaicism in mild malformation of cortical development with oligodendroglial hyperplasia in epilepsy. Acta Neuropathologica Communications. 2021. Open access article

18. GA4GH Phenopacket schema documentation. PhenotypicFeature and Biosample. Phenotypic features, biosamples, and schema

19. Jacobsen JOB, et al. The GA4GH Phenopacket schema defines a computable representation of clinical data. Nature Biotechnology. 2022. Article

20. Ng BG, et al. SLC35A2-CDG: Functional characterization, expanded molecular, clinical, and biochemical phenotypes of 30 unreported individuals. Human Mutation. 2019;40:908–925. Open access article

21. ILAE EpilepsyDiagnosis. Lennox-Gastaut syndrome diagnostic criteria. Criteria

22. Google Docs Editors Help. Publish and share your form with responders. Settings guidance

23. Google Docs Editors Help. Fix common errors while you respond to a Google Form. File upload and sign-in guidance

24. Google for Developers. Apps Script installable triggers. Documentation

25. GitHub Docs. REST API endpoints for issues. API reference

26. Google for Developers. Apps Script Properties Service. Documentation

27. Google for Developers. Quotas for Google services in Apps Script. Current quotas

28. GitHub Docs. Configuring issue templates and issue forms. Configuration guide

29. GitHub Docs. Creating an issue. Instructions

30. GitHub Docs. Reviewing proposed changes in a pull request. Review instructions

31. GitHub Docs. About GitHub Classroom. Overview

32. GitHub Docs. Leave feedback with pull requests. Feedback guide

33. GitHub Docs. Apply to GitHub Education as a student. Eligibility and application

34. GitHub Learn. Current learning entry point linked from GitHub Skills. Learning resources

35. Specchio N, et al. International League Against Epilepsy classification and definition of epilepsy syndromes with onset in childhood. Epilepsia. 2022;63:1398–1442. Position paper