Your contributions are welcome

PhysioNet is growing, thanks to the generosity of our contributors around the world.

Our goal is for PhysioNet to serve as a forum for the exchange of data and software among researchers. We welcome contributions of data to PhysioBank, and of software to PhysioToolkit. If you have publications that are based on your contributed data or software (or on existing PhysioBank or PhysioToolkit materials), we encourage you to contribute copies (or citations) to the PhysioNet Publications pages. Your contributions can make this resource even better!

Rigorous review of the data and software available from PhysioNet is essential so that researchers can confidently make use of these materials. For this reason, we attempt to make explicit the extent to which all data and software have been reviewed, by assigning each item to one of three classes:

• Class 1 databases and software are fully supported. Class 1 databases have been carefully scrutinized and have been thoroughly annotated. Class 1 software has been extensively and rigorously tested. We will correct and document any remaining errors, and encourage users to bring these to our attention.
• Class 2 databases and software are archival copies of materials that support published research, contributed by authors or journals. We will maintain copies of the original data and software together with corrections submitted by the authors. We encourage users to report errors directly to the authors; if you do not receive a response from the authors after a reasonable time, please let us know.
• Class 3 databases include collections of data that may have been less thoroughly studied than those in class 1, but that may be of interest to the research community. These databases include works in progress, to which users are invited to contribute. In some cases, these databases may be archived on their creators' web sites. Class 3 software includes code that may need further testing or development; again, you are invited to dig in and help their creators transform these works in progress into robust and useful tools for research.

The PhysioBank archive index and the PhysioToolkit software index indicate which fully supported databases and software belong to class 1. We make class 2 and class 3 data and software available via PhysioNet as a service to the research community. Contributed data and software are placed in classes 2 and 3 on acceptance, and may be admitted to class 1 after review and a public comment period.

In order to establish and to maintain the highest standard of quality in the data and software available from PhysioNet, we ask that contributors follow the guidelines below, which evolve as this resource grows. Your comments and suggestions about these guidelines are welcome.

We follow these guidelines (which we develop further in consultation with our Advisory Board) in soliciting and accepting contributions of data from other researchers:

• Selection of subjects: Although data from longitudinal, population-based studies are ideal, we accept data from other types of studies provided that the method of selection has been carefully documented. At least a minimum of demographic information (age, gender, medications, diagnoses) should be available for each subject; additional demographic information (e.g., race, ethnicity) is desirable. Anonymity of all subjects must be assured. For data from experimental in vivo or in vitro studies, we favor studies where meaningful time series have been collected and detailed descriptions of the experimental conditions are provided.
• Recording and data preparation: We prefer to receive data in digital form. We may accept analog recordings if no comparable data are available to us in digital form. Technical details of the recordings (signal types, transducer types and locations, recording bandwidth, instrumentation used) must be supplied. Please consult us for recommendations before digitizing analog recordings.
• Verifiability: Databases of derived time series (such as heart rate or RR interval time series) are of limited interest and value, unless the original signals from which the time series were derived are included so that independent verification is possible. Moreover, information contained in the original signals is often useful for purposes other than those served by the derived time series. Although we will sometimes accept databases containing only derived time series (see, for example, the Gait Maturation Database), we strongly encourage contributions that include the original signals.
• Annotation: Depending on the nature of the data, annotations at varying levels of detail may be required. In most cases, an initial set of annotations should be provided or funded by the contributor. We will provide training and facilities to visiting contributors in order to accomplish this goal.

How to contribute data

• Do not submit any data that would permit us or anyone else to identify the subjects of your recordings. Please check your entire submission carefully before transmitting it. You may wish to keep such data for your own records, but do not share it with PhysioNet!
• Supply a plain text file containing a brief description of the database (no more than one page). Call this file "README". This should include:
  • The name by which you would like the database known
  • The name(s) of the creator(s) of the database
  • A paragraph or two describing the database: What are its contents? How were recordings made? How were subjects selected? How were annotations (if any) created and verified? If you defined your own annotation types, what are they? (If your annotation scheme is too complex to describe in a sentence or two, please supply a separate file describing the annotations, and include a reference to that file in your "README".)
  • References to any published works that describe or make use of the database, in the form in which these works should be cited in any future publications
  • Contact information: your name and e-mail address, and, if possible, the name and e-mail address of an alternate contact who can answer or refer technical questions about the database
• Supply a plain text file containing a list of the records by record name, with one record name per line. Record names may contain digits, underscores, and lower-case letters only. Call this file "RECORDS".
• For any signals of types not listed in wfdbcal, please supply additional one-line entries to be added to that calibration file, in a plain text file named "CALIBRATION". Details of the format are at the top of wfdbcal, and also in wfdbcal(5).
• For each recording in your database:
  • Supply a header file, formatted as described in header(5) (see examples in PhysioBank). Header files must have names of the form RECORD.hea, where RECORD is the record name. Be sure to include a signal description in each signal specification line (see the reference above), and use standard signal names as given in the calibration file (or in your supplemental calibration file entries). At the end of each header file, please include an info string (a comment line beginning with '#') that describes (at a minimum) the age, gender, diagnoses, and medications of the subject (other information is also welcome). Example:

    # <age>: 35  <sex>: M  <diagnoses>: (none)  <medications>: (none)
    	

    Please use this format to permit indexing software to parse this information reliably. This string may extend over multiple lines if necessary, but begin each such line with '#'.
  • Supply a signal file, using any of the formats described in signal(5). Multiple signals may be combined in one file as is done for existing databases, or they may be supplied in separate files if you prefer. If your records are long (more than an hour or two), you may wish to segment them as in the MIMIC database, but this is not required. The name of a signal file must begin with the name of the record to which it belongs; names of the form RECORD.dat are recommended.
  • Supply an annotation file if available, using the format in annot(5). If you submit multiple annotation files for a record, please note in your README the purpose and contents of each type of annotation file. The name of an annotation file must begin with the name of the record to which it belongs. For reference annotation files, names of the form RECORD.atr are recommended.
  • If your database contains derived measurements taken at non-uniform intervals (e.g., once per cardiac cycle), supply them in an annotation file as above (and note how you have done this in your README). If the measurements were obtained at uniform intervals (e.g., once per 10 seconds), you may supply them in a signal file as above (with a separate header file to describe its format and contents), or in an annotation file as you prefer. The programs wrann(1) and wrsamp(1) may be useful for preparing annotation and signal files from text files.
  • Optional: please include or give a reference to any accompanying clinical information for a record in a file named RECORD.txt.
  If your data are in EDF (European Data Format), it may not be necessary to reformat them as described above. Please contact us to make arrangements for transfer of EDF files.

We seek contributions of software to PhysioToolkit, with emphasis on applications that are of potential value to users of PhysioBank. Our guidelines for contributors of software, which we continue to develop in consultation with our Advisory Board, are similar in scope and intent to our guidelines for contributors of data.

• Open-source licensing: We accept contributions of software only if sources are included and made available under a license compliant with the Open Source Definition. We have adopted this policy to protect all users of PhysioToolkit, including ourselves. By adhering to this policy, we ensure that users can verify that the software is performing its intended functions and no others, and that the software can be modified to suit the varying requirements of its users.
• No access control: We will not undertake to maintain access control over contributed software. Such contributions, if accepted, will be made freely available to the research community.
• Conformity to stated use: The software must be demonstrated to perform the task intended for it. If its performance is dependent on its input data (as, for example, a QRS detector), such dependencies must be characterized with reference to relevant data from PhysioBank.
• Conformity to interface standards: We encourage the use of common interfaces. PhysioToolkit software tends to follow the ``toolbox'' approach as pioneered in the UNIX environment. Relatively small applications that perform well-defined tasks can be designed, implemented, and rigorously tested at reasonable cost. With careful attention to interfaces, they can be designed to inter-operate predictably and usefully with other tools. By contrast, the ``Swiss Army chainsaw'' approach, exemplified by the massive, monolithic applications common in the commercial software industry, is ill-suited to rapid development of software for leading-edge research.
• Portability: Software accepted for inclusion in PhysioToolkit should be portable across supported operating environments. Currently, these environments include GNU/Linux, MacOS/X (Darwin) 10.2 and later, MS-Windows 9x and later (using the freely available Cygwin package), and Unix (including FreeBSD and Solaris). We favor software that conforms to open systems standards (POSIX and, for interactive software, X11). Most existing PhysioToolkit software is written in the C programming language, for performance and portability. Non-portable software may be accepted provisionally if comparable portable software is unavailable.
• Source-level documentation: Sources for all PhysioToolkit software must be deposited in the PhysioToolkit software source archive. The sources for each package must include a working makefile (a formal description of the dependencies of the source files on each other and on any external sources, used by the make utility to manage the compilation process). Each source file must include comments at the beginning of the file to identify (at least) the name of the file, the author, and the date of last revision.
• User documentation: Each application (or independently usable component, such as a subroutine library) must be documented by a UNIX-format man (manual) page (see the WFDB Applications Guide for examples). This requirement is to ensure that the contents of the PhysioToolkit library can be searched using a wide variety of standard search engines; man pages are mechanically reformatted as hypertext for use on PhysioNet (see, for example, the WFDB Applications Guide). At a minimum, the man page for each application must include:
  • the name of the application and a one-line description of its intended use
  • a synopsis of its use and of any run-time options
  • any relevant cross-references to other software in PhysioToolkit or elsewhere
  • references to any other relevant documentation (e.g., tutorial materials)
  • the names and e-mail addresses of the original author(s), and of the current maintainer
  Where appropriate, additional material (examples, descriptions of algorithms used, etc.) may be included in the man page. A very useful resource for writing man pages is the Linux Man Page HOWTO.

• LaTeX sources and PostScript (PS or EPS) figures suitable for reformatting using LaTeX2HTML
• HTML, with figures in PNG or JPEG format
• Plain text, with figures in PS, EPS, PNG, or JPEG format; we can also accept figures in AVS, BIE, BMP, CGM, DCX, DIB, DICOM, EPDF, EPI, EPT, FIG, FITS, FPX, GIF, GIF87, HDF, HPGL, JBIG, MIFF, MNG, MTV, PBM, PCD, PCL, PCX, PDF, PGM, PICT, PIX, PSD, RLE, SGI, Sun rasterfile, TGA, TIFF, TIM, UYVY, VIFF, XBM, XCF, XPM, XWD, and YUV formats.

Other formats

Please do not send manuscripts in proprietary word processor formats. If your manuscript was written using MS Word, please use Word to convert it to plain text. Do not send us HTML files produced by MS Word (these generally cannot be indexed or searched except by Word itself), or files in Word's native DOC format.

You may also send us PostScript or PDF versions of your manuscript if they are available, but please send a version in one of our preferred formats as well (unlike PostScript and PDF, these formats can be indexed and searched so that PhysioNet users can find your work, they are accessible using text-only web browsers on low-speed links, and they are usable by visually impaired readers using text-to-speech or text-to-Braille translators). Our requirement for text in an accessible format, which has been in effect since PhysioNet was established, has more recently become a legal requirement for publication on this site, because PhysioNet is supported by US federal funding.

If your paper includes GIF images, please convert them to PNG format, and update the links in your manuscript accordingly, before submitting your work. The free gif2png utility can be used to do this.

Please also note that we cannot use WMF (Windows metafile format) figures.

How you can contribute

Please send e-mail to webmaster@physionet.org with a subject of "Contribution" and a brief description of what you wish to contribute, and we will be in touch with you.

Contributions are irrevocable

Just as readers of a printed journal expect to be able to read articles at any time after they have been published, users of PhysioNet must be able to depend on future availability of materials published here. For this reason, we must refuse requests to withdraw contributed materials or to restrict their distribution once they have been posted here (although updates are always welcome and encouraged).

Send feedback about this page to PhysioNet

Your comments and suggestions are welcome. We encourage you to use our feedback form to comment on this page. If you would like to receive a reply, please send your comments by email to webmaster@physionet.org, or post them to: PhysioNet MIT Room E25-505A 77 Massachusetts Avenue Cambridge, MA 02139 USA

Updated Wednesday, 10-Mar-2004 11:41:53 EST