MIT-LCP / MIT-LCP/physionet

bxb.c: wrong strategy during VF

Open
#39 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
82
Forks
21
Avg merge
35m
Merged PRs (30d)
1

Description

Hello,

I found a wrong strategy in bxb regarding the count of beats around VF.
While reading in the annotations (reference and test) it discards simply every beat during a VF, but for every annotation file separately.
Afterwards it compares the beats of the reference and the test annotation.
This leads to an unjust increase in the counters of No' und Vo' and On' and Vn' when there is no exact overlap between the VF sections.

In my opinion bxb should ignore all beats in both annotations during the union of all VF sections in both annotation files.

Any missing or false VF detection or delay in VF detection would then be handled in epicmp.c and would not lead to falsified statistics in bxb.
Currently any non perfect match of VF detection drives up the false positive and false negative counters, which have in reality only to do with non-perfect VF detection and not with wrong beat detection per se.

Example 1:
Currently, if there is a 2 second delay between the VF detection in the test annotation against the reference annotation, then all beats detected by an algorithm during those 2 seconds are counted as false positives. This is not OK since there are "beats" during that period, thats why there is an VF.

Example 2:
Currently, if there is a 5 second delay between the VF-End detection in the test annotation against the reference annotation, then all beats in the reference during those 5 seconds are counted as false negatives. This is not OK since there are "beats" during that period in the test annotation, thats why there is an VF. This is aggravated by the fact that an algorithm may indeed produce correct beat annotations during that time (where it hasn't decided yet to announce an end to VF), but which will be ignored by bxb.c

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading bxb.c to trace how VF intervals and beats are handled in the reference and test annotations. Review epicmp.c for the separation of VF detection errors from beat-comparison errors. Done means beats are ignored across the union of VF sections from both annotations, preventing VF timing differences from changing bxb beat counters.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.