FAQs - UVA-CAMA/NICUHDF5Viewer GitHub Wiki

When I click the .bat file to run the UFC, a black command prompt flashes for a second, then disappears, and nothing else happens

First, make sure you have Java installed on your computer. (Just regular old Java will work - you don't need Java SDK or anything)

Then, make sure you have unzipped the file and extracted the contents before trying to run it.

Finally, if the .bat file still won't work, try the .jar file. Some security protocols prefer the .jar file to be run over the .bat file.

When doing a file conversion, we get an xml file. What is this file for?

Great question about the xml files! I am assuming you are talking about the .xml files that are generated when converting stp files using the UFC. When stp files are converted to hdf5, there is actually a hidden intermediate step in there. The UFC first calls a script from bedmaster to get the data out of the proprietary secretive stp file format. Bedmaster’s unpacking command expands the compressed stp file into a really big xml file. Then the UFC reads that xml file and puts it in hdf5 format. The stp to xml conversion is the slowest part of the process (and one we can’t speed up because it isn’t our code). We keep the xml file around after the process in case we ever needed you to reconvert stp files with a newer version of the UFC. In this circumstance, we could theoretically tell you that you could convert directly from xml to hdf5 to save yourself some time. However this is unlikely.

Note: Bedmaster does occasionally update their xml unpacker tool, and we hope it is unlikely that you would ever need to reconvert unless Bedmaster’s tool itself was discovered to be broken in some way that we currently have no idea about (in which case the old xml wouldn’t help you!). Again, this is unlikely.

The BAP won't generate anything for the periodic breathing algorithms

The periodic breathing algorithms only run if the QRS detection has already been run (this was actually a design choice and not a bug - as rare as it is to say that and genuinely mean it - it's true! haha).

What do the different tag columns mean in the periodic breathing result file?

First off, recall that the periodic breathing tags pull out events where the PB algorithm returns a probability of periodic breathing value above 0.6.

Duration (in milliseconds) = (stop-start)+sample period. (In most cases the sample period is 2000 ms.)

  • The short explanation of why we do this is because we assume the value is held constant for the whole 2000 ms.
  • In practice: here is an example of why we do it this way: Let’s assume we want to find all 4 second long bradycardias. Let’s assume bradycardias are any HR<100. If we have data collected every 2 seconds, we’d want to count the following as a bradycardia:
    • Time: [1 3 5 7 9]
    • HR: [105 98 98 105 111]
  • However, if we just calculated duration as stop-start, the duration of the brady would only be 2 seconds instead of 4, and it wouldn’t meet our 4 second criteria.
  • We’ve discussed this a lot with other clinicians at UVA and they decided this is the way they want it, so we oblige :)

Number of Points – this is the number of data points that meet the threshold for a given event. In the above example, the number of data points would be 2. This becomes more complicated if you have an algorithm that joins nearby events together into a single event. For example, the Pete Brady algorithm joins bradycardia events that occur within 4 seconds of one another. I believe (but need to double check – I just wanted to get this answer to you quickly), that in an event where there is a merger, the number of points only counts the actual number of data points below the threshold even if the tag is longer.

  • Example:
    • HR: [105 98 98 105 98 98 111]
    • Brady Tag: [0 1 1 0 1 1 0] (identifies two separate events)
      • Number Points for Brady Tag: 2 for first event, 2 for second event
    • Pete Brady Tag: [0 1 1 1 1 1 0] (which merges closeby events)
      • Number Points for Pete Brady Tag: 4 for the one event

Area – this makes more intuitive sense for something like a desat where we might want to look at the area of the spo2 value below a given threshold (i.e. compare a deep desat to a shallow desat). For periodic breathing, this is the area of the probability curve above the threshold of 0.6. The vague idea is that something that we are really sure is periodic breathing would have a larger area than something that we are less sure is periodic breathing. This probably won’t be used much for PB, but was in the pipeline for other algorithms, so I kept it in in case someone wanted it.

Note: The calculation is slightly weird for this version (often ending up with a decimal instead of a round number because of the weird way I initially did this), but the new version of the algorithm (coming very very soon) should calculate areas that are closer to whole numbers for things like bradys which are calculated with whole number HR’s. The net “error” on this area calculation is extremely small – and isn’t exactly an error, but it makes more sense in the new way I am doing it. Stay tuned.

Minimum – this is mislabeled. It should labeled as “extrema.” This is the max periodic breathing probability above 0.6 within the tag. Thank you for pointing this out. I should fix this. UPDATE: this has been corrected in Apnea algorithm v3.

Are the apnea tags in the BAP 2 seconds? And then for “ABD” the algorithm requires A to be 10 seconds?

The apnea tags use the following rules from Hoshik’s paper, which don’t necessarily limit the shortest possible apnea to 10 seconds. These rules are used for both the apnea algorithm as well as the ABD algorithm in the BAP.

"(1) Define the ‘weighted apnea duration’ (WAD) as the area under the probability of apnea curve P(t), beginning when that probability increases through 0.1, and ending when it decreases through 0.1. (2) Ignore all events with WAD less than 2 s. (3) Ignore all events having WAD less than 5 s unless the event is within 5 s of another event. (4) Combine events if they are separated by less than 3 s."

While the introduction to Hoshik’s paper mentions the 10 second threshold, I don’t believe (I could be wrong) that his computation sets a specific threshold at 10 seconds. He computes all possible apneas and then bins them by the duration of the apnea (ex. ABD-10, ABD-30). Since we don’t have a specific ABD-duration threshold for PreVent, I did the computation exactly the same way. We can group the apneas after the fact if necessary into duration bins (In other words, we can select for only 10 second apneas after the fact). I store the weighted apnea duration in the tags so we can easily filter by the same metric as Hoshik.

I am looking at .dat files and the vital signs signals are empty. When I ran the algorithms on the data, there are no bradys and no desats. The raw signals look weird and aren't scaled properly. What is going on?

There is a special file that needs to be in the same folder as your dat files when viewing them or doing data analysis on them. This special file is called ScalingFactors.txt. It is a super boring text file that needs to be in the same folder as your dat files for things to run properly. If your ScalingFactors.txt file is missing and you need to make a new one, just create a text file named ScalingFactors.txt with the following content:

-0.005150689743 0.001286372542

The raw signals look weird because those are NOT what is used for running the algorithms.