Review History

All reviews of published articles are made public. This includes manuscript files, peer review comments, author rebuttals and revised materials. Note: This was optional for articles submitted before 13 February 2023.

Peer reviewers are encouraged (but not required) to provide their names to the authors when submitting their peer review. If they agree to provide their name, then their personal profile page will reflect a public acknowledgment that they performed a review (even if the article is rejected). If the article is accepted, then reviewers who provided their name will be associated with the article itself.

View examples of open peer review.


  • The initial submission of this article was received on May 13th, 2019 and was peer-reviewed by 2 reviewers and the Academic Editor.
  • The Academic Editor made their initial decision on July 26th, 2019.
  • The first revision was submitted on August 30th, 2019 and was reviewed by the Academic Editor.
  • A further revision was submitted on September 10th, 2019 and was reviewed by the Academic Editor.
  • The article was Accepted by the Academic Editor on September 11th, 2019.

Version 0.3 (accepted)

· Sep 11, 2019 · Academic Editor


Thank you for making the requested changes. I enjoyed reading through your paper and hope that the PeerJ CS audience will too!

Version 0.2

· Sep 3, 2019 · Academic Editor

Minor Revisions

In my view, the submission is basically ready to be published. However, I would like to see the code in a more permanent location *before* I click the accept button. If Leuven does not have an institutional repository for software, you should look at Zenodo or Figshare:


A couple of other little remaining issues:

"Although it was developed in the eighties, it achieved comparable performance to many 52 more elaborate algorithms.” -> “… achieves … “ ??? [Also, should this be supported by a reference to Elgendi’s comparison?]

Please add a one-sentence explanation of the term "RR interval" when it is first introduced.

Please specify the role of the user-specified “Average heart rate” in your tool (it occurs in Figure 7).


"It achieved a 99.60%” -> “It achieves a 99.60%”

qrs, ecg, etc., still occur in lowercase in the bibliography!

Version 0.1 (original submission)

· Jul 26, 2019 · Academic Editor

Major Revisions

The paper is well written and presents a tool that looks potentially very useful. However, there are some problems that preclude publication at this point. Please address my comments and the reviewers' ones.

Elgendi et al. (2014) finds that there are several methods that outperform Pan-Tompkins according to both, sensitivity and positive predictive value. The tool needs to include a method that is at the state-of-the-art. Alternatively, there needs to be a convincing explanation in the paper why these other methods are not suitable for the tool.

Regardless of this issue, the paper does not make it sufficiently clear why your modified version of the Pan-Tompkins algorithm is used. The results quoted (lines 123-127) do not show an advantage. Moreover, the paper states that they were obtained using an envelope width of 300ms. How was this envelope width obtained? By choosing the value that produced the best results on the test data? This would yield optimistically biased performance estimates. Perhaps it is possible to at least show how sensitive performance is to the choice of width?

The software is available free of charge, but only "upon request". This condition makes publication of this paper significantly less attractive.

The URL for the software in the PDF does not work. I managed to guess the correct URL ( There is no licensing information in the .zip file. Please consider using an open-source license such as the GPL.

PeerJ CS is mainly targeted at a computer science audience. Please include an illustration of ECG events such as the one in Figure 1 in Elgendi et al. (2014).

"Although it was developed in the eighties, it has proven to outperform many more elaborate algorithms." -- This is misleading. There are actually a number of algorithms in Elgendi et al. (2014) that outperform this old method.

"A slightly modified version of the search-back procedure" -- Please specify the exact modification.

"necessary, because" -- Remove comma.

"In Table 1 we listed" -> "In Table 1 we list"

"PVC" -- Please explain what this is.

Please explicitly state in the text how R-peaks are represented in Figure 2 (small filled circles?).

"in the field of Holter" -- ?

"also a zero phase notch filter is included" -> "a zero phase notch filter is also included"

"however this is not always the case" -> "but this is not always the case"

"As can be seen from Fig 4" -> "In Fig 4"

"appreciate the changes" -> "enact the changes"

"from e.g. an" -> "from, e.g., an"

"on the first sheet a general overview of the file" -> "a general overview of the file on the first sheet"

"The y-axis range in both axes" -- ?

"provides the user to switch view" -> "enables the user to switch view"

Please include (a) screenshot(s) to illustrate what is described in lines 347-350.

"Note that you can also export the results as an Excel file" -> "Note that the results can also be exported as an Excel file"

"amount of analysis options" -> "number of analysis options"

"comparable to literature" -> "comparable to the state-of-the-art" ???

Please check the references, e.g., for incorrect typesetting of acronyms.

Reviewer 1 ·

Basic reporting

Overall the manuscript is well written, while I found the description of Decision (Line 97-103) is not clear, which needs to be further improved. Perhaps a figure would help.

Experimental design

As mentioned above, please provide details in the Decision step on Page3.

Validity of the findings

The authors mentioned that the software is freely available, but the provided link ( seems to be not working.

Reviewer 2 ·

Basic reporting

The paper is well written and easy to follow.

Experimental design

no comment

Validity of the findings

no comment

Additional comments

The paper presents the description of an useful open-source Matlab based graphical user
interface for the detection and correction of R-peaks, the QRS complex detection is based on and envelope-based procedure used in combination with an adapted version of a traditional threshold-based QRS detector. The paper is well written and easy to follow. The proposals are good, and the results are interesting. However, some minor sections of the paper need to be clarified.

Author stated that decrease in performance is generally due to poor signal quality. Therefore it should be interesting to have a discussion about the Noise Tolerance performance of the proposed QRS Detection
algorithm against noise. What is the effect of the SNR on the proposed tool? Can you tell us what is the threshold limit of SNR? under which SNR the tool can still have good results, and in which conditions the result may be seriously contaminated. An example illustrating this point should interesting for the reader.

Can you quantify the noise effects in the QRS detector by using the noise stress test recommended by the ANSI/AAMI EC38 standard using the records from the MIT-BIH Noise Stress Test Database?

All text and materials provided via this peer-review history page are made available under a Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.