Sharing on PhysioNet


We invite you to share your resources with the PhysioNet community. Incentives to share include:

  • Improving the discoverability of your work through increased citations.
  • Creating opportunities for collaboration.
  • Facilitating reuse of your data and software, maximizing impact.
  • Encouraging higher-quality, transparent research.

Before submitting your work, please review our author guidelines.




Submission Overview


Submission process

Submitting data and software to PhysioNet is similar to submitting an article to a journal. Briefly, the process for submitting your work for publication in PhysioNet is as follows:

  • If you are the submitting author, create a new project using the project management system.
  • Add your project details. These will include contact information for co-authors, descriptive text, and data files.
  • Once you are satisfied, submit the project to the editorial team for review.
  • You will be notified of an editorial decision when the review process is complete.
  • Once any issues have been addressed, your data or software will be published on PhysioNet.
  • When a project is published, its content is fixed and cannot be changed.

Preparing for submission

PhysioNet helps you to ensure that your data and software is sufficiently well organized to enable reuse by the community. Before submitting your project for review, please make sure that you have:

  • Added all co-authors to the system. Co-authors will receive a notification message upon submission and must approve of the submission prior to publication.
  • Provided detailed information about the resource. This information must include a high-level background, relevant methodology on the resource creation, notes for reuse, acknowledgments, and any conflicts of interest.
  • Selected an appropriate license for releasing your data files.
  • Converted all files to an open, non-proprietary format.

Criteria for publication

Our goals are to ensure that the data is safe to share and that it is sufficiently well structured and described for it to be a valuable resource for the research community. Some of the high-level criteria that we will be considering when reviewing your project include:

Data Quality
  • The data is produced in a sound manner.
  • The data is adequately described.
  • The data files are provided in an open format.
  • The data files are machine readable.
  • All the information needed for reuse is present.
  • No protected health information is contained.
  • The content is suitable for PhysioNet.
Software Quality
  • The project follows good practice in software development.
  • The software is adequately described.
  • The software is provided in an open format.
  • No protected health information is contained.
  • All the information needed for reuse is present.
  • The content is suitable for PhysioNet.

Editorial process

Once your project is submitted to PhysioNet, it will be reviewed by one or more content specialists. Based on this review, you will be provided with an initial editorial decision within four weeks from submission. The possible decisions are:

  1. Accept: The editor is mostly satisfied with the content. The submission continues into the copyedit stage.
  2. Resubmit: The content is suitable for publication, but changes are required to make it more clear or reusable. Changes may include adding required information, restructuring files, and rewording content. Once the submitting author has made these changes, they may resubmit the project for review.
  3. Reject: The content is not suitable for publication.



Author Guidelines


Choosing a project type

When submitting a project to PhysioNet you will be asked to select one of the following project types:

  • Database: Research data with significant potential for reuse by the research community. This may include data that enables published studies to be reproduced, data for benchmarking algorithms, and data that supports novel investigations.
  • Software: Software that has been developed for research applications.
  • Challenge: Description of a challenge for the research community . Files such as datasets and software may be included as part of the challenge.
  • Model: An implementation of a statistical or machine learning model with potential for reuse by the research community. Typically models will be created by a training process and may have dependencies on specific computational frameworks

Creating the project metadata

To help the community to reuse your shared resources, we require a detailed description. The information that you provide should focus on the resource and how it might be reused. During the submission process you are asked to provide information such as a title, an abstract for distribution to search indexes, and context describing the manner in which the resource was created. Further details are outlined below:

  • Title: Your title should be no longer than 200 characters. Do not include acronyms and abbreviations, and where possible avoid leading with "The". Only letters, numbers, spaces, underscores, and hyphens are allowed.
  • Abstract: Your abstract must be no longer than 250 words. The focus should be on the resource being shared. If the resource was generated as part of a scientific investigation, relevant information may be provided to facilitate reuse. References should not be included.
  • Background: Your background should provide the reader with an introduction to the resource. The section should offer context in which the resource was created, outline your motivations for sharing, and highlight potential areas for reuse.
  • Methods & Technical Implementation: The "Methods" and "Technical Implementation" sections provide details of the procedures used to create your resource. For software, the section may cover aspects such as development process, software design, and description of algorithms. For data, the section may include details such as experimental design, data acquisition, and data processing.
  • Content description: Your content description should describe the resource in detail, outlining how files are structured, file formats, and a description of what the files contain.
  • Usage notes: This section should provide the reader with information relevant to reuse. This might include technical instructions or ideas for projects that could make use of the resource.
  • Acknowledgments: In this section, acknowledge the people who helped with the research, but who were not included as co-authors. In addition, provide funding information.
  • Conflicts of interest: A statement on potential conflicts of interest is required. If the authors have no conflicts of interest, the section should say "The author(s) have no conflicts of interest to declare".
  • Version: The version number of the resource. Semantic versioning is encouraged (major version, minor version, patch version). If unsure, put "1.0.0".
  • References: Please use the Vancouver reference style. All citations should be numbered sequentially in the text in square brackets. For example, the first citation [1], the second citation [2], and the third and fourth citations [3,4]. Entries in the reference list should be in the following style: 1. Xu YZ, Geng DC, Mao HQ, Zhu XS, Yang HL (2010). "A comparison of the proximal femoral nail antirotation device and dynamic hip screw in the treatment of unstable pertrochanteric fracture". J Int Med Res. 38: 1266–1275. PMID 20925999.

Preparing your project files

When submitting a project, you will be asked to upload relevant data and software files. Please review the following guidelines when preparing your files for submission:

  • All projects:
    • A README file should be included alongside the files. At minimum, the readme should include a title and a brief description of the package content.
    • Sensitive data and protected health information must have been removed prior to submission.
    • Files should be clearly named and must not include spaces or special characters (e.g. "/","\,".").
    • Files should be provided in non-proprietary formats (for example, CSV), except where there is a clear reason not to do so.
  • Data (general):
    • In most cases, tabulated datasets should be structured following the principles of "tidy data". For example, each variable should be in a column and each observation (or case) in a row.
  • Software:
    • Instructions for installation and usage should be clearly documented.
    • Dependencies should be clearly indicated, for example in a requirements file.
    • A testing framework should be used to demonstrate correct functioning of major features of the software.
    • Standard style guidelines should be followed where appropriate (for example, PEP8 for Python).
    • The software should be logically structured and packaged according to standard practice.



Licenses


When sharing data and software, it is important to be clear about how you intend the content to be reused. To maximize reuse potential of the content, we encourage permissive, open licenses. Currently, authors submitting content to PhysioNet are able to select the following licenses.

Database

Software

Challenge

Model



Submit your Project


Click here to create your project.