Introduction
The role of standardization in advancing biomedical science
Our incessant pursuit of biomedical progress, from fundamental research to clinical application, increasingly relies on the effective management and interpretation of large, complex datasets whose analysis and interpretation offer the potential to unlock answers to critical research questions and ultimately improve human lives [1]. However, this data’s heterogeneity and scale present formidable challenges. Precision medicine aims to tailor treatments to individual patient characteristics, but depends on shared processes and data interoperability. Current data limitations undermine efforts toward this vision [Reference Sriram, Conard, Rosenberg, Kim, Saponas and Hall2].
The NIH’s Bridge to Artificial Intelligence (Bridge2AI) program aims to propel biomedical research by preparing data for widespread AI adoption. It focuses on generating new “flagship” datasets that are ethically sourced and suitable for machine learning. Bridge2AI also develops software, standards, and best practices to make data findable, accessible, interoperable, and reusable. Ultimately, the program seeks to help solve complex biomedical challenges previously beyond reach by fostering collaboration between AI experts and biomedical researchers. The data generating projects (DGPs) addressing the NIH’s Grand Challenges through Bridge2AI seek to scaffold their data on existing biomedical data standards to improve interoperability and advance the goal ofAI-readiness [Reference Clark, Caufield and Parker3]. In the process, all groups have encountered gaps and mismatches among existing standards. In most cases, these could be addressed by extending an existing standard to embrace the scope of data generated in the DGPs.
Navigating the challenges of biomedical data: heterogeneity, volume, and sensitivity
The lifecycle of biomedical data, from generation to actionable insight, is loaded with complexities that call for standardization. The sheer volume of biomedical data, particularly in ‘omics fields, can overwhelm local computational resources, demanding specialized infrastructure and sophisticated management strategies for analysis, storage, and debugging [Reference Sriram, Conard, Rosenberg, Kim, Saponas and Hall2]. Biomedical data is inherently sensitive, often containing personally identifiable information and protected health information (PHI), which mandates stringent adherence to privacy regulations like HIPAA and GDPR. This requires robust security measures, encryption, access controls, and careful ethical consideration [4]. Emerging techniques such as federated learning hold promise for analyzing sensitive data while preserving privacy [Reference Alqudah and Moussavi5]. Initial data capture and curation processes also face difficulties. Procuring appropriate data often requires significant funds and time. Data curation, especially if unstructured, can be lengthy and compounded by inconsistent quality control standards across organizations. These inefficiencies are substantial: estimates suggest that 97% of hospital data goes unused [6], and researchers may spend 45% [7] to 80% [8] of their time cleaning and organizing data rather than on discovery, partly due to a lack of knowledge in rapid standardization. Such early-stage hurdles result in poor data quality, inconsistencies, and incomplete metadata, leading to data silos and ultimately impeding interoperability.
Consequences of an unstandardized data landscape
The absence of robust data standards across the biomedical field leads to a fragmented and inefficient data landscape, with profound negative consequences for research, healthcare delivery, and innovation. One of the most significant outcomes is the proliferation of data silos and a pervasive lack of interoperability. Without common standards, biomedical data frequently becomes trapped within disparate information systems, such as proprietary Electronic Medical Record (EMR) systems from different vendors, each potentially using unique data formats and coding structures [Reference Walker, Tarver, Jonnalagadda, Ranbom, Ford and Rahurkar9, 10]. This fragmentation prevents healthcare providers from obtaining a complete view of a patient’s medical history, leading to redundant testing, diagnostic errors, or incomplete and suboptimal treatment plans. Precision medicine relies on integrating diverse data types from multiple sources, and the dearth of data standards leaves this promise largely unfulfilled. The following table (Table 1) summarizes the impact of lacking standardization across various stages of the biomedical data lifecycle.
Impact of lacking standardization on biomedical data lifecycle stages [1, Reference Sriram, Conard, Rosenberg, Kim, Saponas and Hall2, Reference Walker, Tarver, Jonnalagadda, Ranbom, Ford and Rahurkar9, 10]

Table 1. Long description
A table with six rows and three columns. The columns are labeled ‘Data lifecycle stage’, ‘Challenges without standards’, and ‘Consequences for research/healthcare’. The rows are labeled ‘Data capture’, ‘Data curation and organization’, ‘Data storage’, ‘Data sharing and exchange’, ‘Data analysis & interpretation’, and ‘Data reuse & reproducibility’. Row 1: Data capture, Inconsistent terminologies, heterogeneous coding and collection practices, lack of defined data elements., Inaccuracy, difficulty aggregating data, risk of downstream quality issues, time-consuming data entry. Row 2: Data curation and organization, Absence of common data models, inconsistent metadata tagging, difficulty structuring unstructured data, lack of consistent quality control., Difficulty interpreting and integrating data, poor data quality, incomplete contextual information, significant time spent on data cleaning and harmonization. Row 3: Data storage, Proprietary storage formats, lack of standardized schemas, data silos, inefficient storage use due to redundancy. Difficulty accessing and retrieving data across systems, increased storage costs, risk of data becoming unusable over time. Row 4: Data sharing and exchange, Lack of interoperable exchange formats and protocols, incompatible EMR systems, privacy/security concerns with ad-hoc sharing methods. Inability to share data between providers or researchers leading to fragmented patient care, duplicated efforts, and hindered collaboration; potential for data breaches. Row 5: Data analysis & interpretation, Difficulty combining heterogeneous datasets, ambiguous data elements, challenges in applying consistent analytical methods, bias in datasets. Reduced statistical power, erroneous or skewed analytical results, inability to perform large-scale or comparative analyses, amplification of biases leading to unfair outcomes. Row 6: Data reuse & reproducibility, Poorly documented data, non-standard formats hindering re-analysis, incomplete metadata making context unclear for future use. Difficulty replicating research findings, wasted resources as data cannot be effectively reused, erosion of scientific trust, inability to build upon previous work effectively.
Standards development organizations offer a path to coherent biomedical data
Standards Development Organizations (SDOs) are entities dedicated to formulating and maintaining standards. In health and biomedicine, a “standard” encompasses various technical works, including prescribed rules, guidelines, best practices, specifications, test methodologies, and design or installation procedures such as implementation guides. The primary mission of SDOs in the healthcare sector is to develop and uphold standards that meet pressing industry needs. These organizations often seek accreditation from national or international bodies like the American National Standards Institute (ANSI) to validate their processes and outputs [11, 12]. Their overarching goals frequently include promoting public health, ensuring safety, and protecting the environment [13].
SDOs have emerged in recent years to enable interoperability across the intricate landscapes of biomedical data. The structure of SDOs, often member-supported with standards built by volunteer members (where members are sometimes organizations), underscores the necessity of proactive participation [11]. They are tasked with creating the common language, frameworks, and protocols essential for capturing, organizing, sharing, and leveraging biomedical data effectively. Many Bridge2AI DGP participants have experience working with SDOs, and some have direct experience expanding the scope and terminologies of SDO scope. Engagement with these organizations is not a passive act of adoption but rather an active, strategic imperative for any institution or individual committed to advancing biomedical science or enhancing healthcare outcomes. SDOs effectively summon the vast expertise available outside the regulatory bodies themselves, something achievable only through the active engagement of these experts.
SDOs initially emerged as organizations applying formal processes for community consultation to drive development of data standards. We refer to such organizations as “traditional SDOs;” they include examples in clinical and health data such as HL7 [14], the OMOP project within OHDSI [15], and GA4GH [16]. However, many established community standards develop in smaller organizations, where leaders are also directly responsible for developing and maintaining the community standards. These “quasi-SDOs” include researcher-led community efforts such as the Monarch Initiative [Reference Putman, Schaper and Matentzoglu17] and VICC [Reference Horak, Griffith and Danos18]. In some cases, a single standard and its community can be thought of as an SDO unto itself; for example, DICOM [19], SNOMED [20], LOINC [21], and RxNorm [22]. In this work, we consider general strategies for interacting with all of these forms of SDOs.
The quality and pace of biomedical innovation are intrinsically linked to the maturity and responsiveness of its data standards. With the following set of recommendations, we aim to explain why proactive engagement with SDOs is crucial for the effective capture, organization, and sharing of biomedical data. We underscore the critical importance of providing continuous, constructive feedback to SDOs to ensure that standards evolve to meet the specific and dynamic needs of the biomedical community. The inherent complexities of biomedical data inform our perspective and the role of SDOs in mitigating these challenges. We detail the mechanisms through which feedback is provided and incorporated, and the broader strategic advantages of such engagement. This responsiveness, in turn, requires robust SDO engagement and effective feedback loops. Poor health data standardization is a barrier to research progress. SDOs adapt based on user needs, so insufficient engagement and feedback slows the evolution of data standards and in turn delays the innovation that relies upon them.
Why engage an SDO
SDOs’ ability to define common schema, mange hinges on the collective expertise and active participation of their membership. They draw participants from a broad spectrum of the biomedical ecosystem, including healthcare providers (clinicians, hospitals), insurers, health information technology developers, academic researchers, pharmaceutical companies, medical device manufacturers, patients and their caregivers, clinical informaticists, software engineers, and government and regulatory agencies representatives. The broad range of knowledge, expertise, and perspectives represented informs the standards development process, helping to ensure that the resulting standards are technically sound and meet critical business, clinical, and research needs [11].
Researchers seeking to engage with an SDO should consider their goals and purposes before identifying the SDO partner(s) and developing their engagement strategy. This guide is motivated and informed by the experiences of Bridge2AI Project members who hold deep domain expertise in the clinical and physiologic areas relevant to the DGPs. As such, they can contribute thoughtfully to the content and structure of biomedical data standards specifications. Common engagement goals are described further in this section.
Correction
SDO-generated specifications may be established and managed by parties with varying degrees of expertise. It is probable that DGP investigators will encounter content that does not reflect current understanding in a field of research. For example, ontological relationships in a vocabulary specification may be obsolete, or the syntactic relations between elements in a data model may not reflect a clinical reality. Such oversights can be corrected, and most SDO organizations welcome well-documented proposals for specification corrections.
Enrichment/enhancement
In the course of generating data for DGP protocols, many projects extend beyond the scope of general-purpose biomedical standards. Yet, such domain-specific extensions reflect real-world clinical circumstances; adding such content to SDO specifications in turn makes those specifications more complete. Many semantic standards support the creation of temporary codes or concepts, intended for “one of” use within a specific project. Proposing to make official (canonical) changes or extensions to the standard is the focus of this report.
An example is the ophthalmological detail of the AI-READI DGP; the OHDSI OMOP specification does not have the syntactic or semantic content to adequately capture these domain elements. Thus, detailed extensions to the OMOP data model and vocabulary have been proposed to OHDSI by Bridge2AI content experts in ophthalmology, working together with OHDSI OMOP experts. Together, they seek to establish canonical enhancement of the OMOP specification.
Maintenance of biomedical standards effectively reduces to combinations of correction, enrichment, or enhancement as above in addition to Alignment below.
Alignment
Sometimes, SDO specifications may need more than correction or content enhancement. Standards are often created for specific use-cases, such as clinical practice, decision support, or administrative billing. Novel or rapidly developing use-cases, such as AI research, may stretch the content and structure of a standards specification in ways not anticipated [Reference Richesson and Krischer23].
Modifying an SDO specification to accommodate a new use-case is an “alignment” of that standard to the required needs. The research use-case often requires data provenance, granular detail, and unambiguous representation beyond those use-cases for which a standard was initially developed. A standard may require more extensive syntactic adaptation to accommodate these requirements.
Determination of implementation guidance needs
A critical and often overlooked mode of engagement involves determining whether the community requires a new conceptual standard specification or practical implementation guidance to deploy an existing one. Historically, some SDOs have operated to provide schemas, conceptual models, and documentation for their standards, without necessarily providing additional necessary tooling, such as API frameworks, ingestion pipelines, and database backends.
This operational bottleneck can result in highly siloed implementations. When standards are defined but the software execution is left entirely to the community, different institutions might end up independently writing their own parsers and data pipelines for the exact same standard. This leads to duplicated effort and a fragmented software ecosystem that hinders the interoperability the standard was meant to achieve.
Engaging an SDO to assess implementation readiness allows researchers to flag when a standard specification alone is insufficient. By participating in this determination process, researchers can advocate for and help co-develop implementation guides, reference architectures, and open-source tooling. This ensures that standards transition effectively from theoretical blueprints to practically deployable solutions, reducing the friction of adoption across diverse clinical and research environments.
Identifying SDO partners
Several SDOs are particularly influential in shaping the biomedical data landscape. Understanding their specific roles and contributions provides a clearer picture of how standardization efforts are operationalized. The following table (Table 2) summarizes key relevant SDOs and their roles. A more complete characterization of more relevant standards is in the appendix.
Key standards development organizations in the biomedical domain

Table 2. Long description
A table comparing standards development organizations in the biomedical domain. The table has 9 rows and 4 columns. Column headers are SDO name, Primary focus/domain, Key standard(s) examples, and Typical feedback/participation channels. Row 1: SDO name, CDISC; Primary focus/domain, Clinical and non-clinical regulated research data standards; Key standard(s) examples, SDTM, ADaM, CDASH, ODM, SEND, Controlled Terminology; Typical feedback/participation channels, Continuous feedback loops, Project-based community engagement (e.g., 360i), Collaboration with EVS, Public review of draft standards, Member input. Row 2: SDO name, DICOM (NEMA/ACR); Primary focus/domain, Medical imaging standards (storage, transmission); Key standard(s) examples, DICOM Standard (multi-part); Typical feedback/participation channels, Working Groups (e.g., WG-6 for base standard), Change Proposals (CPs), Supplements development, Public comment, Letter ballots by DICOM Standards Committee. Row 3: SDO name, GA4GH; Primary focus/domain, Technical standards, policy frameworks, and tools to expand responsible, voluntary, and secure use of genomic and related health data; Key standard(s) examples, VCF, BED, SAM/BAM, CRAM, VRS, Cat-VRS, VA-Spec, DUO, Phenopackets, Consent Clauses for Genomic Research; Typical feedback/participation channels, Work Streams, Product Development and Approval Process, which includes work with Study Groups, a Product Review Committee (PRC), and the Product Steering Committee (PSC). Row 4: SDO name, HL7 International; Primary focus/domain, Health data exchange & interoperability; Key standard(s) examples, FHIR, HL7 v2/v3, CDA, C-CDA; Typical feedback/participation channels, Workgroups, Balloting (Comment, Informative, STU, Normative), Jira feedback system, Connectathons, Mailing lists, Community forums (e.g., chat.fhir.org). Row 5: SDO name, International Standards Organization (ISO) TC 215 (Health Informatics); Primary focus/domain, Broad health informatics standardization (international); Key standard(s) examples, ISO 5477 (Public Health Emergency Preparedness), ISO 13,606 (EHR Communication), various security and interoperability standards; Typical feedback/participation channels, National member body participation (e.g., ANSI in the US), Expert contributions to working groups, Formal ISO balloting processes, Review of draft international standards. Row 6: SDO name, Regenstrief Institute; Primary focus/domain, Laboratory tests, anthropometrics, surveys; Key standard(s) examples, LOINC; Typical feedback/participation channels, Open sessions, public submission forms, rich implementation tooling. Row 7: SDO name, Open mHealth; Primary focus/domain, Mobile health (mHealth) data interoperability and standardization; Key standard(s) examples, Open mHealth Data Schemas (e.g., heart rate, physical activity, blood glucose); Typical feedback/participation channels, GitHub issue tracking, Open developer community, Open-source contributions, Direct contact via info@openmhealth.org. Row 8: SDO name, SNOMED International; Primary focus/domain, Global clinical healthcare terminology; Key standard(s) examples, SNOMED CT; Typical feedback/participation channels, National Release Centers (NRCs), SNOMED CT Content Request Service (CRS), Online feedback forms for specific proposals, Appeals process. Row 9: SDO name, World Health Organization; Primary focus/domain, Disease Classification and clinical terminology; Key standard(s) examples, ICD11, ICF, ICHI; Typical feedback/participation channels, National and academic collaborating centers, Public proposal process.
Major standards development organizations from the perspective of Bridge2AI Data Generation Projects (DGPs). This is a partial list, augmented by the Supplementary materials.
ONC and the USCDI for clinical data
The spectrum of biomedical data standards is broad, and multiple standards often overlap. Historically, a lack of unified oversight allowed different SDOs to generate multiple, sometimes conflicting, standards for the same or similar data elements – rendering redundancy, non-interoperability, and confusion. The emergence of the Office of the National Coordinator (ONC) in 2004 largely remedied this situation for clinical data; the vital role of the ONC was recognized by its brief elevation to the level of the Assistant Secretary for Technology Policy in HHS [32] in 2024. Beginning with the Meaningful Use standards through the present United States Core Data for Interoperability (USCDI) [33], the ONC has regulatory authority to mandate specifications for EHR vendors and health systems operating in the United States. The full scope of ONC includes EHR adoption, standards, alignment of market incentives, patient privacy, and national scale governance for clinical data exchange.
The United States Core Data for Interoperability (USCDI) is “a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange [33].” A DGP seeking to extend EHR-related standards to accommodate translational research content would engage with the SDO overseeing the corresponding USCDI specification. USCDI has both semantic (terminologies for consistent meaning) and syntactic (schema for consistent structure) components. The syntactic component is Health Level 7 (HL7) FHIR [34]. For example, all EHRs must support exporting data on demand and in bulk using the FHIR specification. FHIR was developed to support data transmissions, but constitutes a de facto syntactic specification for clinical health data. Nevertheless, legacy HL7 specifications such as V2 (version 2) [35] are still widely used within health systems, and HL7 C-CDA (Consolidated Clinical Document Architecture) [36] is still the dominant system for HIE transfers.
USCDI semantic specifications are broad, but highlight the International Classification of Diseases [37] and SNOMED for diagnoses and procedures, LOINC for laboratory and diagnostic tests, and RxNorm for drugs and medicinals.
HL7 has established a spectrum of FHIR accelerators [38] to better align the evolving FHIR specification to multiple use cases and promote FHIR adoption and implementation. Among these is the Vulcan FHIR Accelerator [39], created to address the translational research use case in FHIR. Others include Argonaut for clinical EHR data, CodeX for cancer data, Da Vinci for administrative and reimbursement data, Gravity for social determinants data, and Helios for public health. Researchers seeking SDO content enhancement is those domains should join the corresponding FHIR accelerator community.
While ONC defines the regulated clinical data standards for clinical activities, the scope of biomedical data remains very broad. Nevertheless, all ONC standards are required to have open, transparent processes, and their specifications must be public and free from intellectual property (IP) restrictions. Factors involving SDO-specific attributes that DGP programs considered include:
-
• content domain
-
• openness/limits/requirements for collaboration
-
• policy on intellectual property as it pertains to the research use of the standard
-
• requirements/guidance for a properly formed augmentation/correction
-
• institutional workflows for managing collaborations/contributions
These factors vary from organization to organization, though we include some attributes in our sampling of SDOs below.
The previously mentioned HL7 is the dominant health IT specification for EHR data transmission used throughout the world. All of its products are developed by a global community of volunteers using transparent methodologies supported by the ANSI. Notably, HL7 is incorporated as a non-profit organization in the United States; ANSI is the US member of ISO. All HL7 products are also now open-access without IP restrictions. These include the legacy V2 and C-CDA specifications, as well as the next-generation FHIR specification.
Standards development organizations beyond the ONC mandate
Syntactic (mostly) standards
ONC and USCDI do not yet cover all EHR never mind biomedical content. Nevertheless, data in those domains remain important for most translational research. Imaging data, as manifest in radiology plain films, CTs, MRIs, and other 3–4 dimensional clinical imaging practices, is generally covered by the Digital Imaging and Communications in Medicine (DICOM) standard developed by the radiology and imaging vendor communities. The DICOM specification is comprehensive and free for use without royalties or subscriptions. DICOM is widely used across various medical domains, including radiology, cardiology, dentistry, oncology, and ophthalmology.
Wearable data from watches, rings, and personal monitors covering heart rate, sleep, temperature, and related skin-derived metrics has suffered from a range of proprietary data representations across a spectrum of vendors. The Open mHealth [40] organization is the most active and highest-profile organization seeking to align vendors and developers to a common specification, though at present, this is mostly cross-functional API specifications. Open mHealth overlaps with HL7 FHIR personal health device, patient-generated health data, and vital-signs specifications in its representation of data from wearables, apps, and home monitoring devices, including heart rate, activity, sleep, glucose, blood pressure, and other physiologic measurements. This overlap illustrates a broader standards-landscape problem, as implementers may need to choose between native Open mHealth schemas, HL7/FHIR representations, or mappings between them, which can make research data alignment more difficult.
Process for engaging with SDOs
The authors’ collective experience working with SDOs in the context of the Bridge2AI DGPs motivated us to develop a set of recommendations and best practices for individual investigators and clinicians interested in engaging to augment or improve data standard specifications. These recommendations are based on a century of collective experience among us with SDOs in a range of biomedical data areas, including ontology, clinical informatics, and bioinformatics.
The SDOs discussed here vary in their degree of openness to participation across a spectrum from open participation to closed fora. HL7 exemplifies the open participation model: any person or organization may become a member of HL7 and participate in specification drafting and balloting, the formal process that HL7 uses to gather feedback and comments on specifications prior to publication. The International Standards Organization (ISO) is an example of a closed organization, where membership requires acceptance by the national body (e.g., ANSI in the United States) and the ISO Technical Advisory Group (TAG) for that specific ISO Technical Committee, such as TC215 for Health Informatics [27]. ISO limits draft and document sharing to TAG members. The approach to engaging SDOs therefore depends on their level of openness. In general, it is much more effective for some translational team members to join the relevant SDO before requesting or contributing to specification changes, or partner with established SDO members in extension requests.
Framing the request
Many SDOs have specific templates for content expansion or extension. For example, LOINC has a detailed knowledge base entry on how to make changes to LOINC [28], with a pointer to their change submission request page [41]. Many organizations similarly offer simple, explicit procedures to manage change requests. Other organizations employ more complex procedures, such as commenting or voting in a ballot during a scheduled review period (ranging from 6 months to 5 years). Our appendix materials provide more details and contact information that may help discern processes for various organizations.
Generating and shepherding SDO extension requests is generally a team sport, involving clinical users that understand workflow and researchers that may be end users of data. In all cases, some general background research and preparation can facilitate the process and speed the request. This typically includes:
-
Highly specified request – The more detailed a request, the more likely it will be considered seriously and efficiently. Proponents should state explicitly whether they are seeking a correction, clarification, addition, or deletion of an existing specification. Context for such a change should also be provided, such as whether the requested new term or concept should be a child of an existing term or concept. Complete metadata, including supporting evidence as citable publications, synonyms of a term or concept, and concise definitions, should accompany the request.
-
Compelling justification – Changing standards entails cost and overhead to an SDO, and therefore requires a clearly documented need. Justification is often framed as a motivating use case to accommodate a defined community of users and consumers of a standard. Estimating the impact on that user community if the change is not made can be persuasive. Detailing the anticipated advantages resulting from the change provides the most compelling evidence.
-
Alignment with existing standard – Requested changes must align with the domain and intent of the SDO. For example, one should not attempt to add a laboratory test name to RxNorm, whose domain is clinical drug names, when LOINC is the USCDI-designated SDO for laboratory test names. As a syntactic example, one should not make requests of HL7 for transmission of a medical image when DICOM addresses that domain. Even within a domain, proponents should familiarize themselves with spheres of emphasis. For example, LOINC addresses laboratory test names, but does not address laboratory test result codes. Be sure your request falls within the domain and scope of the SDO you approach.
-
Absence of standards-based alternative – Ideally, standards and terminologies would be mutually exclusive and exhaustive in their coverage. In reality, neither is true; the need for extensions belie the latter. In some cases a requested term or syntax may already exist in another SDO’s specification. Nevertheless, translational researchers should verify that data elements important for their research do not already exist in a complementary standard within the domain.
-
Evidence of community consensus – SDOs seek to serve communities of users; thus, testimony or attestations of the need for a specification change from a larger community should accompany any request or update.
Process
Most SDOs at their heart are a community of technically knowledgeable people working in the domain of that SDO. The most effective approach to engaging an SDO is to collaborate with a member of that SDO who can guide you in the lore and procedure of that organization. Even better, a person with high domain knowledge, for example, an academic ophthalmologist, may choose to join an SDO like OHDSI [15] (who maintain the OMOP [42] common data model) to facilitate the expansion of OMOP to include ophthalmological data elements. While adding a simple LOINC term may be undertaken on a web form, expanding the domain of an existing standard will involve deeper engagement with the SDO or at least a partner engaged in the SDO. While the processes and procedures are specific to each SDO, they typically involve variations on these mechanisms:
-
• Change request submission form (as outlined above for LOINC)
-
• Standards renewal reviews
-
• Domain working group deliberations and recommendations
-
• Tracking and ticketing systems (Jira, GitHub)
-
• Proposal solicitation calls
-
• Scheduled community engagement meetings
Pitfalls to avoid
Successful engagement with SDOs will be far more likely if one avoids behaviors that may be regarded as uncivil within their developer communities. These include:
-
• Don’t ignore their concerns
-
• Understand their constraints
-
• Be kind with what limitations or critiques you might have
-
• Don’t be too pushy about timelines or urgency
-
• Don’t seek comprehensiveness for its own sake
-
• Don’t make perfect the enemy of good
Conclusion
The progress of biomedical science is inextricably linked to the collaborative development, adoption, and refinement of high-quality data standards, particularly in realizing the transformative potential of fields like precision medicine, artificial intelligence-driven discovery, and global public health initiatives [Reference Sriram, Conard, Rosenberg, Kim, Saponas and Hall2]. Standards Development Organizations provide the essential scaffolding – the common languages, formats, models, and protocols – that allows the biomedical community to manage, interpret, and leverage the ever-expanding ocean of health-related information. However, the true power of these standards is unlocked not just through their existence but through active, sustained, and collaborative engagement with the SDOs that create and nurture them. Feedback from various users – researchers, clinicians, informaticists, industry developers, and patients – is an indispensable factor in this evolutionary process. This dynamic, participatory process is crucial to ensure that standards are technically sound, fit-for-purpose, practically implementable, and sufficiently robust to support the rigorous demands of biomedical research and healthcare delivery.
Effectively harnessing biomedical data standards demands a collective commitment from all stakeholders – researchers, clinicians, industry, patient groups, and regulators – to transcend passive adoption. Instead, these communities must actively shape standards through their creation, rigorous testing, refinement, and real-world validation. Accelerated biomedical innovation, vital for the health and well-being of future generations, hinges on a steadfast and collective commitment to collaborative standardization. This shared dedication involves continuously developing, implementing, and improving the data standards vital for the health and well-being of future generations.
Stakeholders can contribute to standards development and optimization by engaging directly with SDOs. SDOs are agile, continuously enhancing their processes to incorporate feedback effectively and proactively address emerging data challenges and ethical considerations. SDOs exist to serve their communities and are generally receptive to well-formed requests for correction, extension, or enhancement. Not unreasonably, these requests are invariably more successful if they are complete, coherent, and aligned with the SDO specification scope and domain. An ideal approach is to engage a member of the SDO in the process, or even better, become a member of that SDO community to work through the process. Patience is always required, as SDOs, by the nature of defining a standard, rarely work as quickly as constituents might hope. Respect for SDO processes and procedures will optimize any SDO enhancement request.
Robust SDO engagement and widespread adoption of high-quality standards offer profound social benefits beyond technical efficiency. These collaborative efforts build essential public trust in biomedical science by fostering reliable, reproducible, and equitable research while ensuring data privacy and security. This trust is crucial for societal acceptance of medical advancements that improve and save lives worldwide.
Our recommendations foster dynamic collaboration between researchers, DGPs, and SDOs to dismantle barriers to data interoperability and research progress. Proactive SDO engagement and continuous feedback will be pivotal in shaping more responsive and effective biomedical data standards. Dedicated SDO engagement promises to cultivate a more agile and robust data ecosystem, accelerating the pace of biomedical innovation and translating research into improved health outcomes.
Supplementary material
The supplementary material for this article can be found at https://doi.org/10.1017/cts.2026.10836.
Author contributions
Christopher G. Chute: Conceptualization, Funding acquisition, Methodology, Project administration, Supervision, Writing – original draft, Writing – review & editing; Amir Bahmani: Investigation, Writing – review & editing; Alex Handler Wagner: Conceptualization, Investigation, Methodology, Writing – review & editing; Timothy W. Clark: Investigation, Writing – review & editing; Nayoon Gim: Investigation, Writing – review & editing; Jessica Mitchell: Investigation, Project administration, Writing – review & editing; Andrew Williams: Conceptualization, Investigation, Writing – review & editing; Monica C. Munoz-Torres: Conceptualization, Funding acquisition, Investigation, Supervision, Writing – review & editing.
Funding statement
This work was supported by NIH Awards 5 U54 HG012513-04 (NGHRI), and 3 OT2 OD032701-01S2, 3 OT2 OD032742-01S3 (Common Fund).
Competing interests
There are no conflicts of interest.
Use of AI statement
AI tools were not used to create the body of this manuscript. AI tools did facilitate the synthesis of the abstract from the body of the manuscript.