Philips files not loading

[hhnguyen7]

Sorry I encountered another issue. I cannot load some Philips xml files. Please find one attached (saved as txt). Philips_4_Faulty.txt Could you please take a look and help me troubleshoot. Thank you. Hoang

[BIVectors]

The issue is that the version of Philips XML files we had access to when writing the code had the calibration signal appended on after each leads signal. This must not be standard. We had to crop this 500 sample calibration signal off.

I will fix this in version 1.1.2 which will be out sometime this week if you are running via the compiled executable.

If you are running via Matlab and can edit the source code you can fix this now by editing load_philipsxml.m line 163 and commenting out the line

assert(size(leads, 1)==5500);

With this change I was able to load and process your ecg.

Thanks for bringing this to my attention!

[BIVectors]

Just uploaded v1.1.2 which has an updated load_philipsxml.m file which should be able to load your files. Please let me know if this works.

[hhnguyen7]

This worked. Thank you very much!

What do you suggest I do when the ECGs have different quality issues? Please see the attached pictures of the quality checks.

I have ~1000 ECGs to analyze for this particular project. Do you think it is best to eliminate all the ECGs that do not pass the quality check using the preset parameters?

Thank you, Hoang [image: quality1.png] [image: quality2.png]

[BIVectors]

The attachments didnt come through.

In general, I would process the ECGs in batch with the standard quality metrics. If this is not a dataset that was collected for research, there will likely be a decent amount of "low quality" ECGs with noise etc. The nominal settings will tend to overcall ECGs with the quality check so that if an ECG passes you probably don't need to worry about it, but if it flags for quality, it may still be okay, but it wants you to verify if it is good or not. What I usually do is process the batch and then look at the ECGs that are flagged by reviewing the summary figures that are generated. You can look through them pretty quickly by arrowing through them using the windows picture viewer. I then mark down the ECGs that did not process well (tons of noise, alignment is clearly off, annotations are totally wrong due to noise etc), and then its a decision on your part if you think the ECG is too bad to salvage, or if you can manually process it to remove segments or noise etc that are throwing the automatic processing off. In general, I would estimate that you can fix about 50% of the really bad quality ECGs to get at least a few beats that work by either changing some of the parameters like maxBPM, pk threshold, filtering levels, or less commonly the % autowidth or ST End parameters if the QRST morphology is atypical. In rare cases, you may have to manually load the ECG and remove the noise segments that are causing problems.

The other thing you can look at is the check_ecg_list.csv which is generated. Section 16.4 of the userguide goes over the parameters in detail, but you can quickly sort by why the ECG was flagged. If an ECG flagged only for 'lf_noise' this means that there was some baseline wander, but its possible that this was removed by filtering, and ECGs that only have this one 'lf_noise' flag are often fine once the high-pass filtering is used, and can usually be used without issue.

However, 'median_sig_corr_error' is almost always a sign that something is very wrong with how things processed - this tells you the beat alignment was really bad, usually due to significant artifact or noise.

The other flags really depend on your dataset characteristics. Eg the flags for number of beats removed may not be important if you know you have lots of ectopy which needs to be removed.

With very large datasets manual review may not be feasible, and then can remove bad quality ECGs based on their quality score (cut off depends on what you want for sensitivity and specificity) or by the quality flags

If you upload the figures again I can take a look

thx

[hhnguyen7]

Thanks for the detailed advice. I'll batch process these ECGs and ask you how to deal with the bad ones. Hoang

On Thu, Feb 29, 2024 at 21:01 BIVectors @.***> wrote:

The attachments didnt come through.

In general, I would process the ECGs in batch with the standard quality metrics. If this is not a dataset that was collected for research, there will likely be a decent amount of "low quality" ECGs with noise etc. The nominal settings will tend to overcall ECGs with the quality check so that if an ECG passes you probably don't need to worry about it, but if it flags for quality, it may still be okay, but it wants you to verify if it is good or not. What I usually do is process the batch and then look at the ECGs that are flagged by reviewing the summary figures that are generated. You can look through them pretty quickly by arrowing through them using the windows picture viewer. I then mark down the ECGs that did not process well (tons of noise, alignment is clearly off, annotations are totally wrong due to noise etc), and then its a decision on your part if you think the ECG is too bad to salvage, or if you can manually process it to remove segments or noise etc that are throwing the automatic processing off. In general, I would estimate that you can fix about 50% of the really bad quality ECGs to get at least a few beats that work by either changing some of the parameters like maxBPM, pk threshold, filtering levels, or less commonly the % autowidth or ST End parameters if the QRST morphology is atypical. In rare cases, you may have to manually load the ECG and remove the noise segments that are causing problems.

The other thing you can look at is the check_ecg_list.csv which is generated. Section 16.4 of the userguide goes over the parameters in detail, but you can quickly sort by why the ECG was flagged. If an ECG flagged only for 'lf_noise' this means that there was some baseline wander, but its possible that this was removed by filtering, and ECGs that only have this one 'lf_noise' flag are often fine once the high-pass filtering is used, and can usually be used without issue.

However, 'median_sig_corr_error' is almost always a sign that something is very wrong with how things processed - this tells you the beat alignment was really bad, usually due to significant artifact or noise.

The other flags really depend on your dataset characteristics. Eg the flags for number of beats removed may not be important if you know you have lots of ectopy which needs to be removed.

If you upload the figures again I can take a look

thx

— Reply to this email directly, view it on GitHub https://github.com/BIVectors/BRAVEHEART/issues/5#issuecomment-1972383483, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIMRP4MJEFWVQ4NZOM7C2E3YV7VRRAVCNFSM6AAAAABDY6BT5CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZSGM4DGNBYGM . You are receiving this because you authored the thread.Message ID: @.***>

[BIVectors]

going forward it may be easier to email me at braveheart.ecg at gmail.com so dont have to deal with message board.